This document defines the roles associated with contributing to the Fuchsia project.
Roles within the Fuchsia project seek to embody the following principles:
The following are the contributor roles associated with the Fuchsia project:
Anyone who contributes to the project by providing patches to code or documentation, and agrees to the Google Developers' Contributor License Agreement{:.external}.
Members are responsible for acting in accordance with the Fuchsia Code of Conduct.
To become a Member you must do the following:
A Committer is a person who has write access to the Fuchsia repository{:.external}. A Committer can submit their own Gerrit changes or Gerrit changes from any other member.
A Committer is not just someone who can make changes, but also someone who demonstrated the ability to collaborate effectively with other Members of the Fuchsia community. Example collaboration activities include but are not limited to:
Members can become Committers with different kinds of contributions. For instance, those working on documentation or toolchain can meet the requirements to become Committers by contributing high-quality documentation or configuration changes, which would not meet the “traditional” bar for well-tested code.
In order to submit Gerrit changes, Committers need to either be Owners of the affected files or receive approval from an Owner of the affected files.
Committers are responsible for the following:
To become a Committer you must do the following:
A current Committer nominates you by sending email to committers@fuchsia.dev containing the following information. Please do not CC the nominee on the nomination email.
Two other Committers need to second your nomination. If no one objects in 5 working days (U.S.), you‘re a Committer. If anyone objects or wants more information, the Committers discuss and usually come to a consensus (within the 5 working days). If issues can’t be resolved, there's a vote among current Committers.
That's it! There is no further action you need to take on your part. The Committers will get back to you once they make a decision.
In the worst case, this can drag out for two weeks. Keep writing patches! Even in the rare cases where a nomination fails, the objection is usually something easy to address like “more patches” or “not enough people are familiar with this person's work.”
Once you get approval from the existing Committers, a Fuchsia Community Manager will add you to committers@fuchsia.dev and reach out with some additional information on submitting contributions as an external contributor.
If you are contributing patches but not (yet) a Committer, you may wish to be able to run jobs on the try servers directly rather than asking a Committer or reviewer to do so for you.
The process to obtain try job access is the following:
An Owner is responsible for files or directories within the Fuchsia project and has comprehensive knowledge of the code in that subtree. Owners are listed in OWNERS
files. For directories or files that are outside of an Owner's responsibility, that Owner has the same privileges as a Committer.
Committers are encouraged to keep OWNERS
files up to date.
In addition to the responsibilities of a Committer and Member, Owners are responsible for the following:
To become an Owner you must do the following:
OWNERS
file of your desired repository. Current Owners will evaluate your change and either accept or reject your request.A Global Approver is a member of the owners-override@fuchsia.dev group. A Global Approver can invoke the Owners-override bit in Gerrit, which waives OWNERS
requirements for a change.
While Global Approvers are empowered to provide an Owners-override +1 to large-scale changes, Global Approvers are not expected to have comprehensive knowledge of the entire Fuchsia codebase. It is expected that global approval will be used primarily in cases where the changes systematic, largely mechanical, and impacts a large fraction of the codebase.
Currently, members of Fuchsia Engineering Council are global approvers, as well as a small number of reviewers to cover timezones with no FEC member. Committers that encounter cases where existing code owners are can't provide review coverage are encouraged to first send a change to update the local OWNERS
file, or to add a top-level, per-file rule to cover a certain type of file, like **/BUILD.gn
or **/*.md
. For cases where this proves insufficient, committers should send email to owners-override@fuchsia.dev to discuss the issue.
In addition to the responsibilities of a Member, Committer, and Owner, Global Approvers are responsible for the following:
The types of code review actions you can provide depend on your role within the Fuchsia project.
A CQ Dry Run runs your change against the available tests in the Commit Queue. Committers, Owners, and Global Approvers can initiate a CQ Dry Run.
After you request a code review, reviewers can score your change.
Reviewers can label your change with a score of -2, -1, 0, +1, or +2. For more information on review label definitions, see Gerrit Code Review - Review Labels{:.external}.
Committers, Owners, and Global Approvers can score code reviews but only a Global Approver or repository Owner can provide a +2.
You need a Code Review Label +2 to submit your change. A Code-Review Label +2 score can only be applied by a repository Owner or Global Approver.
When a change is submitted, the change is moved to the Commit Queue (CQ). The Commit Queue verifies, commits, and merges changes to the master branch.
This table summarizes the actions that each Fuchsia contributor role can perform.
The following diagram depicts the high-level stages of what happens to a change after its pushed to Gerrit.
Areas within the Fuchsia repository may have their own unique requirements, defining their own sets of roles and responsibilities, in addition to the ones detailed above.
An API Reviewer is accountable for the quality and long-term health of the Fuchsia API surface. API Reviewers collectively form the API Council.
Any change that modifies the Fuchsia API Surface must receive an API-Review+1. from a member of API Council in addition to the usual Code-Review+2.
For more details about the responsibilities of an API Reviewer and how the API Council operates, see the API Council Charter.
To become an API Reviewer you must do the following:
The Fuchsia Eng Council is a small group of senior technical leaders responsible for providing a coherent technical vision for Fuchsia. The Eng Council largely operates by delegation and ratification, communicating engineering standards, values, and objectives throughout the community and then reviewing and ratifying concrete engineering proposals from project contributors.
There is no predetermined number of people on the Eng Council. However, in order to provide a coherent technical vision, the council has a small number of members. Eng Council members are appointed by the governing authority for the project. For more information, see Membership in the Fuchsia Eng Council Charter.
When contributors no longer meet requirements, their role and corresponding privileges can be revoked.
Example scenarios for having privileges revoked include, but are not limited to, the following:
The process for revoking an individual’s role within the Fuchsia project involves the following steps:
community-managers@fuchsia.dev
to revoke someone’s role, specifying the rationale. Revoking an Owner role needs to be approved by an Owner in the same subtree or above.Revoking a Committer role should be a rare action and requires approval by the governance authority. Community managers should be involved in the process of revoking the Committer role.
As a Fuchsia Member, you might have the following questions about requesting a code review: