| = 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]] |
| == 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 |
| * support the |
| link:dev-processes.html#design-driven-contribution-process[ |
| 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 |
| 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 |
| * propose link:#dev-design-docs[design docs] as part of the |
| link:dev-contributing.html#design-driven-contribution-process[ |
| 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 |
| done. |
| |
| 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. Refer to the project homepage for |
| the link:https://www.gerritcodereview.com/members.html#maintainers[ |
| 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 |
| 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 |
| * supporting the |
| link:dev-processes.html#design-driven-contribution-process[ |
| 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: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] |
| * 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 |
| |
| [[maintainer-election]] |
| 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 |
| include: |
| |
| * high quality code contributions |
| * high quality code reviews |
| * activity on the mailing list |
| |
| [[steering-committee-member]] |
| == 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:https://www.gerritcodereview.com/members.html#engineering-steering-committee[ |
| 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:https://bugs.chromium.org/p/gerrit/issues/list?q=component:ESC[ESC component] |
| in the issue tracker, or add that component to existing items, to raise them to |
| the attention of 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]] |
| == 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 |
| committee]. |
| |
| 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 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:https://www.gerritcodereview.com/members.html#community-managers[ |
| list of current community managers]. |
| |
| Tasks: |
| |
| * 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:https://bugs.chromium.org/p/gerrit/issues/list?q=component:Community[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 |
| mailto:gerritcodereview-community-managers@googlegroups.com[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 |
| members]. |
| |
| [[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 |
| --------- |
