= Gerrit Code Review - Supporting Roles

As an open source project Gerrit has a large community of people that
are driving the project forward and there are many ways to engage with
the project and get involved.

[[supporter]]
== 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
  link:https://groups.google.com/d/forum/repo-discuss[repo-discuss]
  mailing list (post your questions, provide feedback, share your
  experiences, help other users)
* attend community events like user summits (see
  link:https://calendar.google.com/calendar?cid=Z29vZ2xlLmNvbV91YmIxcGxhNmlqNzg1b3FianI2MWg0dmRpc0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t[
  community calendar])
* report link:https://bugs.chromium.org/p/gerrit/issues/list[issues]
  and help to clarify existing issues
* provide feedback on
  link:https://www.gerritcodereview.com/releases-readme.html[new
  releases and release candidates]
* review
  link:https://gerrit-review.googlesource.com/q/status:open[changes]
  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
  link:https://groups.google.com/d/forum/repo-discuss[repo-discuss]
  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
  automatically)
* comment on
  link:https://gerrit-review.googlesource.com/q/status:open[changes]
  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:https://bugs.chromium.org/p/gerrit/issues/list[
  issue tracker] and comment on existing issues

Supporters who want to engage further can get additional privileges
on request (ask for it on the
link:https://groups.google.com/d/forum/repo-discuss[repo-discuss]
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
  link:https://groups.google.com/d/forum/repo-discuss[repo-discuss]
  mailing list
* administrate issues in the
  link:https://bugs.chromium.org/p/gerrit/issues/list[issue tracker]

Supporters can become link:#contributor[contributors] by signing a
contributor license agreement and contributing code to the Gerrit
project.

[[contributor]]
== 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:https://gerrit-review.googlesource.com/[
gerrit-review.googlesource.com] is a contributor.

Contributions can be:

* new features
* bug fixes
* code cleanups
* documentation updates
* release notes updates
* 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 and
mailing list discussions.

Contributors may also be invited to join the Gerrit hackathons which
happen regularly (e.g. twice a year). Hackathons are announced on the
link:https://groups.google.com/d/forum/repo-discuss[repo-discuss]
mailing list (also see
link:https://calendar.google.com/calendar?cid=Z29vZ2xlLmNvbV91YmIxcGxhNmlqNzg1b3FianI2MWg0dmRpc0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t[
community calendar]).

Outstanding contributors that are actively engaged in the community, in
activities outlined above, may be nominated as link:#maintainer[
maintainers].

[[maintainer]]
== Maintainer

Maintainers are the gatekeepers of the project and are in charge of
approving and submitting changes.

Maintainers should only approve changes that:

* they fully understand
* seem to be in scope for what Gerrit should do
* meet the quality expectations of the project (well-tested, properly
  documented, scalable, backwards-compatible)
* implement usable features or bug fixes (no incomplete/unusable
  things)
* 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
* 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
* veto changes if they disagree with a feature or with how it is being
  implemented (vote `-2` on the `Code-Review` label)
* nominate new maintainers and vote on nominations (see below)
* administrate the link:https://groups.google.com/d/forum/repo-discuss[
  mailing list], the
  link:https://bugs.chromium.org/p/gerrit/issues/list[issue tracker]
  and the link:https://www.gerritcodereview.com/[homepage]
* gain permissions to do Gerrit releases and publish release artifacts
* create new projects and groups on
  link:https://gerrit-review.googlesource.com/[
  gerrit-review.googlesource.com]
* administrate the Gerrit projects on
  link:https://gerrit-review.googlesource.com/[
  gerrit-review.googlesource.com] (e.g. edit ACLs, update project
  configuration)
* create events in the
  link:https://calendar.google.com/calendar?cid=Z29vZ2xlLmNvbV91YmIxcGxhNmlqNzg1b3FianI2MWg0dmRpc0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t[
  community calendar]

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 are approved by
consensus among the maintainers. This means maintainers can veto a
nomination.

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
include:

* high quality code contributions
* high quality code reviews
* activity on the mailing list

[[release-manager]]
== 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
  releases
* 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.

GERRIT
------
Part of link:index.html[Gerrit Code Review]

SEARCHBOX
---------