blob: f4576679fb40c2a6fe3dc95f02e4c206751e34e2 [file] [log] [blame]
= Gerrit Code Review - Supporting Roles
As an open source project Gerrit has a large community of people
driving the project forward. There are many ways to engage with
the project and get involved.
== Supporter
Supporters are individuals who help the Gerrit project and the Gerrit
community in any way. This includes users that provide feedback to the
Gerrit community or get in touch by other means.
There are many possibilities to support the project, e.g.:
* get involved in discussions on the
mailing list (post your questions, provide feedback, share your
experiences, help other users)
* attend community events like user summits (see
community calendar])
* report link:[issues]
and help to clarify existing issues
* provide feedback on
releases and release candidates]
* review
and help to verify that they work as advertised, comment if you like
or dislike a feature
* serve as contact person for a proprietary Gerrit installation and
channel feedback from users back to the Gerrit community
Supporters can:
* post on the
mailing list (Please note that the `repo-discuss` mailing list is
managed to prevent spam posts. This means posts from new participants
must be approved manually before they appear on the mailing list.
Approvals normally happen within 1 work day. Posts of people who
participate in mailing list discussions frequently are approved
* comment on
and vote from `-1` to `+1` on the `Code-Review` label (these votes
are important to understand the interest in a change and to address
concerns early, however link:#maintainer[maintainers] can
overrule/ignore these votes)
* download changes to try them out, feedback can be provided as
comments and by voting (preferably on the `Verified` label,
permissions to vote on the `Verified` label are granted by request,
see below)
* file issues in the link:[
issue tracker] and comment on existing issues
* support the
design-driven contribution process] by reviewing incoming
link:dev-design-docs.html[design docs] and raising concerns during
the design review
Supporters who want to engage further can get additional privileges
on request (ask for it on the
mailing list):
* become member of the `gerrit-verifiers` group, which allows to:
** vote on the `Verified` and `Code-Style` labels
** edit hashtags on all changes
** edit topics on all open changes
** abandon changes
* approve posts to the
mailing list
* administrate issues in the
link:[issue tracker]
Supporters can become link:#contributor[contributors] by signing a
contributor license agreement and contributing code to the Gerrit
== Contributor
Everyone who has a valid link:dev-cla.html[contributor license
agreement] and who has link:dev-contributing.html[contributed] at least
one change to any project on
link:[] is a contributor.
Contributions can be:
* new features
* bug fixes
* code cleanups
* documentation updates
* release notes updates
* propose link:#dev-design-docs[design docs] as part of the
design-driven contribution process]
* scripts which are of interest to the community
Contributors have all the permissions that link:#supporter[supporters]
have. In addition they have signed a link:dev-cla.html[contributor
license agreement] which enables them to push changes.
Regular contributors can ask to be added to the `gerrit-verifiers`
group, which allows to:
* add patch sets to changes of other users
* propose project config changes (push changes for the
`refs/meta/config` branch
Being member of the `gerrit-verifiers` group includes further
permissions (see link:#supporter[supporter] section above).
It's highly appreciated if contributors engage in code reviews,
link:dev-design-docs.html#review[design reviews] and mailing list
discussions. If wanted, contributors can also serve as link:#mentor[
mentors] to support other contributors with getting their features
Contributors may also be invited to join the Gerrit hackathons which
happen regularly (e.g. twice a year). Hackathons are announced on the
mailing list (also see
community calendar]).
Outstanding contributors that are actively engaged in the community, in
activities outlined above, may be nominated as link:#maintainer[
== Maintainer
Maintainers are the gatekeepers of the project and are in charge of
approving and submitting changes. Refer to the project homepage for
the link:[
list of current maintainers].
Maintainers should only approve changes that:
* they fully understand
* are in line with the project vision and project scope that are
defined by the link:dev-processes.html#steering-committee[engineering steering
committee], and should consult them, when in doubt
* meet the quality expectations of the project (well-tested, properly
documented, scalable, backwards-compatible)
* implement usable features or bug fixes (no incomplete/unusable
* are not authored by themselves (exceptions are changes which are
trivial according to the judgment of the maintainer and changes that
are required by the release process and branch management)
Maintainers are trusted to assess changes, but are also expected to
align with the other maintainers, especially if large new features are
being added.
Maintainers are highly encouraged to dedicate some of their time to the
following tasks (but are not required to do so):
* reviewing changes
* mailing list discussions and support
* bug fixing and bug triaging
* supporting the
design-driven contribution process] by reviewing incoming
link:dev-design-docs.html[design docs] and raising concerns during
the design review
* serving as link:#mentor[mentor]
* doing releases (see link#release-manager[release manager])
Maintainers can:
* approve changes (vote `+2` on the `Code-Review` label); when
approving changes, `-1` votes on the `Code-Review` label can be
ignored if there is a good reason, in this case the reason should be
clearly communicated on the change
* submit changes
* block submission of changes if they disagree with how a feature is
being implemented (vote `-2` on the `Code-Review` label), but their
vote can be overruled by the steering committee, see
link:dev-processes.html#project-governance[Project Governance]
* nominate new maintainers and vote on nominations (see below)
* administrate the link:[
mailing list], the
link:[issue tracker]
and the link:[homepage]
* gain permissions to do Gerrit releases and publish release artifacts
* create new projects and groups on
* administrate the Gerrit projects on
link:[] (e.g. edit ACLs, update project
* create events in the
community calendar]
* discuss with other maintainers on the private maintainers mailing
list and Slack channel
In addition, maintainers from Google can:
* approve/reject changes that update project dependencies (vote `-1` to
`+1` on the `Library-Compliance` label), see
link:dev-processes.html#upgrading-libraries[Upgrading Libraries]
* edit permissions on the Gerrit core projects
Maintainers can nominate new maintainers by posting a nomination on the
non-public maintainers mailing list. Nominations should stay open for
at least 14 calendar days so that all maintainers have a chance to
vote. To be approved as maintainer a minimum of 5 positive votes and no
negative votes is required. This means if 5 positive votes without
negative votes have been reached and 14 calendar days have passed, any
maintainer can close the vote and welcome the new maintainer. Extending
the voting period during holiday season or if there are not enough
votes is possible, but the voting period should not exceed 1 month. If
there are negative votes that are considered unjustified, the
link:dev-processes.html#steering-committee[engineering steering
committee] may get involved to decide whether the new maintainer can be
accepted anyway.
To become a maintainer, a link:#contributor[contributor] should have a
history of deep technical contributions across different parts of the
core Gerrit codebase. However, it is not required to be an expert on
everything. Things that we want to see from potential maintainers
* high quality code contributions
* high quality code reviews
* activity on the mailing list
== Engineering Steering Committee Member
The Gerrit project has an Engineering Steering Committee (ESC) that
governs the project, see link:dev-processes.html#project-governance[Project Governance].
Members of the steering committee are expected to act in the interest
of the Gerrit project and the whole Gerrit community. Refer to the project
homepage for the link:[
list of current committee members].
For those that are familiar with scrum, the steering committee member
role is similar to the role of an agile product owner.
Steering committee members must be able to dedicate sufficient time to
their role so that the steering committee can satisfy its
responsibilities and live up to the promise of answering incoming
requests in a timely manner.
Community members may submit new items under the
link:[ESC component]
in the issue tracker, or add that component to existing items, to raise them to
the attention of ESC members.
Community members may contact the ESC members directly using[this mailing list].
This is a group that remains private between the individual community
member and ESC members.
link:#maintainer[Maintainers] can become steering committee member by
election, or by being appointed by Google (only for the seats that
belong to Google).
== Mentor
A mentor is a link:#maintainer[maintainer] or link:#contributor[
contributor] who is assigned to support the development of a feature
that was specified in a link:dev-design-docs.html[design doc] and was
approved by the link:dev-processes.html#steering-committee[steering
The goal of the mentor is to make the feature successful by:
* doing timely reviews
* providing technical guidance during code reviews
* discussing details of the design
* ensuring that the quality standards are met (well documented,
sufficient test coverage, backwards compatible etc.)
The implementation is fully done by the contributor, but optionally
mentors can help out with contributing some changes.
link:#maintainer[Maintainers] and link:#contributor[contributors] can
volunteer to generally serve as mentors, or to mentor specific features
(e.g. if they see an upcoming feature on the roadmap that they are
interested in). To volunteer as mentor, contact the
link:dev-processes.html#steering-committee[steering committee] or
comment on a change that adds a link:dev-design-docs.html#propose[
design doc].
== Community Manager
Community managers should act as stakeholders for the Gerrit community
and focus on the health of the community. Refer to the project homepage
for the link:[
list of current community managers].
* act as stakeholder for the Gerrit community towards the
link:dev-processes.html#steering-committee[steering committee]
* ensure that the link:dev-contributing.html#mentorship[mentorship
process] works
* deescalate conflicts in the Gerrit community
* constantly improve community processes (e.g. contribution process)
* watch out for community issues and address them proactively
* serve as contact person for community issues
Community members may submit new items under the
link:[Community component]
backlog, for community managers to refine. Only public topics should be
issued through that backlog.
Sensitive topics are to be privately discussed using[this mailing list].
This is a group that remains private between the individual community
member and community managers.
The community managers should be a pair or trio that shares the work:
* One Googler that is appointed by Google.
* One or two non-Googlers, elected by the community if there are more
than two candidates. If there is no candidate, we only have the one
community manager from Google.
Community managers must not be link:#steering-committee-member[
steering committee members] at the same time so that they can represent
the community without conflict of interest.
Nomination process, election process and election period for the
non-Google community manager are the same as for
link:dev-processes.html#steering-committee-election[steering committee
== Release Manager
Each major Gerrit release is driven by a Gerrit link:#maintainer[
maintainer], the so called release manager.
The release manager is responsible for:
* identifying release blockers and informing about them
* creating stable branches and updating version numbers
* creating release candidates, the final major release and minor
* announcing releases on the mailing list and collecting feedback
* ensuring that releases meet minimal quality expectations (Gerrit
starts, upgrade from previous version works)
* publishing release artifacts
* ensuring quality and completeness of the release notes
* cherry-picking bug fixes, see link:dev-processes.html#backporting[
Backporting to stable branches]
* estimating the risk of new features that are added on stable
branches, see link:dev-processes.html#dev-in-stable-branches[
Development in stable branches]
Before each release, the release manager is appointed by consensus among
the maintainers. Volunteers are welcome, but it's also a goal to fairly
share this work between maintainers and contributing companies.
Part of link:index.html[Gerrit Code Review]