This document describes the set of roles individuals may have within the Istio community, the requirements of each role, and the privileges that each role grants.
Transient roles
Here is the set of roles we use within the Istio community, the general responsibilities expected by individuals in each role, the requirements necessary to join or stay in a given role, and the concrete manifestation of the role in terms of permissions and privileges.
| Role | Responsibilities | Requirements | Privileges |
| Collaborator | Casual contributor to the project | n/a |
Outside collaborator of the GitHub Istio organization Can submit PRs Read and commenting permission on the Istio Team drive |
| Member | Regular active contributor in the community |
Has pushed at least one PR to an Istio repository |
Member of the GitHub Istio organization Edit permission on the Istio Team drive Triage permission on the Istio repos, allowing issues to be manipulated. |
| Maintainer | Approve contributions from other members | Highly experienced and active reviewer and contributor to an area | Like a member, plus:
Able to approve code changes in GitHub Voting rights in the context of working group decision-making |
| Triager |
Triage incoming issues, set milestones, set labels |
Appointed by the technical oversight committee | Triage permissions on the Istio repos, allowing issues to be manipulated. |
| Lead |
Set priorities for a functional area and approve proposals Triage incoming issues, set milestones, set labels Run their working group Write permission on the Istio repos. |
Appointed by the technical oversight committee as documented in Istio Working Group Processes | Like a maintainer |
| Administrator | Manage & control permissions | Appointed by the technical oversight committee |
Admin privileges on varous Istio-related resources, as defined in ADMINS-FOR-ISTIO |
| Release manager | Sheperd a release through to general availability | Appointed by the technical oversight committee | Admin privilege over the GitHub repos |
| Sponsor | Vouch for another GitHub user in order to let the user get more privilege within the project |
Must have close interactions with the user |
n/a |
Individuals may be added as an outside collaborator (with READ access) to a repo in the Istio GitHub organization without becoming a member. This allows them to be assigned issues and PRs until they become a member, but will not allow tests to be run against their PRs automatically nor allow them to interact with the PR bot.
-
Working on some contribution to the project that would benefit from the ability to have PRs or Issues to be assigned to the contributor
-
Sponsored by 1 member
Established community members are expected to demonstrate their adherence to the principles in this document, familiarity with project organization, roles, policies, procedures, conventions, etc., and technical and/or writing ability.
Members are continuously active contributors in the community. They can have issues and PRs assigned to them, participate in working group meetings, and pre-submit tests are automatically run for their PRs. Members are expected to remain active contributors to the community.
All members are encouraged to help with the code review burden, although each PR must be reviewed by one or more official maintainers for the area before being accepted into the source base.
-
Has pushed at least one PR to the Istio repositories within the last 6 months.
-
Subscribed to contributors
-
Actively contributing to 1 or more areas.
Members are expected to be active participants in the project on an on-going basis. If an individual doesn't contribute to the project for a 180 day period, than that individual may lose membership. On-going contributions include:
- Successfully merging pull requests
- Triaging issues or pull requests
- Commenting on issues or pull requests
- Closing issues or pull requests
-
Responsive to issues and PRs assigned to them
-
Active owner of code they have contributed (unless ownership is explicitly transferred)
-
Code is well tested
-
Tests consistently pass
-
Addresses bugs or issues discovered after code is accepted
-
Members who frequently contribute code are expected to proactively perform code reviews for the area that they are active in.
Maintainers review and approve code contributions. While code review is focused on code quality and correctness, approval is focused on holistic acceptance of a contribution including: backwards / forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, etc. Maintainer status is scoped to a part of the codebase and is reflected in a CODEOWNERS file.
The following apply to the part of the codebase for which one would be a maintainer:
-
Member for at least 3 months
-
Contributed at least 30 substantial PRs to the codebase
-
Must remain an active participant in the community by contributing code, performing reviews, triaging issues, etc.
-
Knowledgeable about the codebase
-
Sponsored by a working group lead with no objections from other leads
If a maintainer becomes inactive in the project for an extended period of time, the individual will transition to being an emeritus maintainer. Emeritus maintainers lose their ability to approve code contributions, but retain their voting rights for up to one year. After one year, emeritus maintainers revert back to being normal members with no voting rights.
Maintainers contribute to the parts of the project they are responsible for by:
- Successfully merging pull requests
- Triaging issues or pull requests
- Closing issues or pull requests
The following apply to the part of the codebase for which one would be a maintainer:
-
Maintainer status may be a precondition to accepting large code contributions
-
Demonstrates sound technical judgement
-
Responsible for project quality control via code reviews
-
Focus on code quality and correctness, including testing and factoring
-
Focus on holistic acceptance of contribution such as dependencies with other features, backwards / forwards compatibility, API and flag definitions, etc
-
-
Expected to be responsive to review requests as per community expectations;
-
May approve code contributions for acceptance
-
Maintainers in an area get a vote when a working group needs to make decisions.
Triagers are members that help triage issues. They can set priority, assignment, milestones, and labels.
Triagers are appointed by the technical oversight committee
The following apply to the area / component for which one would be an owner.
-
Perform issue triage on GitHub
-
Apply/remove/create/delete GitHub labels and milestones
Working group leads, or just ‘leads’, are maintainers of an entire area that have demonstrated good judgement and responsibility. Leads accept design proposals and approve design decisions for their area of ownership, triage issues, and run regular working group meetings.
Getting to be a lead of an existing working group:
-
Recognized as having expertise in the group’s subject matter
-
Maintainer for some part of the codebase for at least 3 months
-
Member for at least 1 year
-
Primary reviewer for 20 substantial PRs
-
Reviewed or merged at least 50 PRs
-
Appointed by the technical oversight committee
Establishing the leads for a new working group:
-
Originally authored or contributed major functionality to an area
-
A maintainer in the CODEOWNERS file for the group’s code
-
Maintainer for some part of the codebase for at least 3 months
-
Member for at least 1 year
-
Primary reviewer for 20 substantial PRs
-
Reviewed or merged at least 50 PRs
-
Appointed by the technical oversight committee
The following apply to the area / component for which one would be an owner.
-
Run their working group as outlined in the Working Group Processes document.
-
Strive for consensus on technical matters within the working group.
-
Design/proposal approval authority over the area / component, though escalation to the technical oversight committee is possible
-
Perform issue triage on GitHub
-
Apply/remove/create/delete GitHub labels and milestones
-
Expected to work to holistically maintain the health of the project through:
-
Reviewing PRs
-
Fixing bugs
-
Mentoring and guiding maintainers, members, and contributors
-
Administrators are responsible for the bureaucratic aspects of the project.
- Appointed by the technical oversight committee
-
Manage a variety of infrastructure support for the Istio project as described in ADMINS-FOR-ISTIO
-
Although admins may have the authority to override any policy and cut corners, we expect admins to generally abide by the overall rules of the project. For example, unless strictly necessary, admins should not approve and/or commit PRs they aren't entitled to if they were not admins.
Individual responsible for a particular release of the product. This person takes ownership of the release processes and knocks down obstacles in order to drive to a successful timely general availability of the release.
- Appointed by the technical oversight committee
-
Get a release out the door.
-
Admin privilege over the GitHub repos.
A sponsor is a member that wishes to vouch for another user to support a user being assigned a specific role.
-
Sponsors must have close interactions with the user - e.g. code/design/proposal review, coordinating on issues, etc.
-
Sponsors are responsible for assessing whether a new potential user behaves in accordance to our contribution guidelines.