This team discusses membership in the compiler team. There are currently two levels of membership:
- contributors: regular contributors with r+ rights, bot privileges, and access to infrastructure
- full members: full members who vote on RFCs
People who are looking to contribute to the compiler typically start in one of two ways. They may tackle “one off” issues, or they may get involved in some kind of existing working group. They don’t know much about the compiler yet and have no particular privileges. They are assigned to issues using the triagebot and (typically) work with a mentor or mentoring instructions.
Once a working group participant has been contributing regularly for some time, they can be promoted to the level of a compiler team contributor (see the section on how decisions are made below). This title indicates that they are someone who contributes regularly.
It is hard to define the precise conditions when such a promotion is appropriate. Being promoted to contributor is not just a function of checking various boxes. But the general sense is that someone is ready when they have demonstrated three things:
- “Staying power” – the person should be contributing on a regular basis in some way. This might for example mean that they have completed a few projects.
- “Independence and familiarity” – they should be acting somewhat independently when taking on tasks, at least within the scope of the working group. They should plausibly be able to mentor others on simple PRs.
- “Cordiality” – contributors will be members of the organization and are held to a higher standard with respect to the Code of Conduct. They should not only obey the letter of the CoC but also its spirit.
Being promoted to contributor implies a number of privileges:
- Contributors have r+ privileges and can do reviews (they are expected to use those powers appropriately, as discussed previously). They also have access to control perf/rustc-timer and other similar bots.
- Contributors are members of the organization so they can modify labels and be assigned to issues.
- Contributors are a member of the rust-lang/compiler team on GitHub, so that they receive pings when people are looking to address the team as a whole.
- Contributors are listed on the rust-lang.org web page.
It also implies some obligations (in some cases, optional obligations):
- Contributors will be asked if they wish to be added to the reviewer rotation.
- Contributors are held to a higher standard than ordinary folk when it comes to the Code of Conduct.
As a contributor gains in experience, they may be asked to become a compiler team member. This implies that they are not only a regular contributor, but are actively helping to shape the direction of the team or some part of the compiler (or multiple parts).
- Compiler team members are the ones who select when people should be promoted to compiler team contributor or to the level of member.
- Compiler team members are consulted on FCP decisions (which, in the compiler team, are relatively rare).
- There will be a distinct GitHub team containing only the compiler team members, but the name of this team is “to be determined”.
- Working groups must always include at least one compiler team member as a lead (though groups may have other leads who are not yet full members).
Promotion decisions (from participant to contributor, and from
contributor to member) are made by having an active team member send
an e-mail to the alias
firstname.lastname@example.org. This e-mail
- the name of the person to be promoted
- a draft of the public announcement that will be made
Compiler-team members should send e-mail giving their explicit assent, or with objections. Objections should always be resolved before the decision is made final. E-mails can also include edits or additions for the public announcement.
To make the final decision:
- All objections must be resolved.
- There should be a “sufficient number” (see below) of explicit e-mails in favor of addition (including the team lead).
- The nominator (or some member of the team) should reach out to the person in question and check that they wish to join.
We do not require all team members to send e-mail, as historically these decisions are not particularly controversial. For promotion to a contributor, the only requirement is that the compiler team lead agrees. For promotion to a full member, more explicit mails in favor are recommended.
Once we have decided to promote, then the announcement can be posted to internals, and the person added to the team repository.
It is worth emphasizing that becoming a contributor or member of the compiler team does not necessarily imply writing PRs. There are a wide variety of tasks that need to be done to support the compiler and which should make one eligible for membership. Such tasks would include organizing meetings, participating in meetings, bisecting and triaging issues, writing documentation, working on the rustc-dev-guide. The most important criteria for elevation to contributor, in particular, is regular and consistent participation. The most important criteria for elevation to member is actively shaping the direction of the team or compiler.
If at any time a current contributor or member wishes to take a break from participating, they can opt to put themselves into alumni status. When in alumni status, they will be removed from Github aliases and the like, so that they need not be bothered with pings and messages. They will also not have r+ privileges. Alumni members will however still remain members of the GitHub org overall.
People in alumni status can ask to return to “active” status at any time. This request would ordinarily be granted automatically barring extraordinary circumstances.
People in alumni status are still members of the team at the level they previously attained and they may publicly indicate that, though they should indicate the time period for which they were active as well.
If desired, a team member may also ask to move back to contributor status. This would indicate a continued desire to be involved in rustc, but that they do not wish to be involved in some of the weightier decisions, such as who to add to the team. Like full alumni, people who were once full team members but who went back to contributor status may ask to return to full team member status. This request would ordinarily be granted automatically barring extraordinary circumstances.
If a contributor or a member has been inactive in the compiler for 6 months, then we will ask them if they would like to go to alumni status. If they respond yes or do not respond, they can be placed on alumni status. If they would prefer to remain active, that is also fine, but they will get asked again periodically if they continue to be inactive.