Skip to content

Commit 49ac194

Browse files
nikomatsakisnikomatsakis
authored
document compiler member and contributors (#348)
This mostly just adds material from RFC 2689
1 parent 5453fa4 commit 49ac194

File tree

3 files changed

+212
-0
lines changed

3 files changed

+212
-0
lines changed

‎src/SUMMARY.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,8 @@
1313
- [Compiler](./compiler/README.md)
1414
- [Cross Compilation](./compiler/cross-compilation/README.md)
1515
- [Windows](./compiler/cross-compilation/windows.md)
16+
- [Review policies](./compiler/reviews.md)
17+
- [Membership](./compiler/membership.md)
1618
- [Triage Meeting](./compiler/triage-meeting.md)
1719
- [Steering Meeting](./compiler/steering-meeting.md)
1820
- [Submitting a proposal](./compiler/steering-meeting/submit.md)

‎src/compiler/membership.md

Lines changed: 165 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,165 @@
1+
# Membership
2+
3+
This team discusses membership in the compiler team. There are currently two levels of membership:
4+
5+
* [contributors]: regular contributors with r+ rights, bot privileges, and access to [infrastructure]
6+
* [full members]: full members who vote on RFCs
7+
8+
[compiler-team full members]: https://www.rust-lang.org/governance/teams/compiler
9+
[compiler-team contributors]: https://www.rust-lang.org/governance/teams/compiler#compiler-contributors
10+
11+
## The path to membership
12+
13+
People who are looking to contribute to the compiler typically start
14+
in one of two ways. They may tackle "one off" issues, or they may get
15+
involved in some kind of existing working group. They don't know much
16+
about the compiler yet and have no particular privileges. They are
17+
assigned to issues using the triagebot and (typically) work with a
18+
mentor or mentoring instructions.
19+
20+
## Compiler team contributors
21+
22+
Once a working group participant has been contributing regularly for
23+
some time, they can be promoted to the level of a **compiler team
24+
contributor** (see the section on [how decisions are made][hdam]
25+
below). This title indicates that they are someone who contributes
26+
regularly.
27+
28+
It is hard to define the precise conditions when such a promotion is
29+
appropriate. Being promoted to contributor is not just a function of
30+
checking various boxes. But the general sense is that someone is ready
31+
when they have demonstrated three things:
32+
33+
- "Staying power" -- the person should be contributing on a regular
34+
basis in some way. This might for example mean that they have
35+
completed a few projects.
36+
- "Independence and familiarity" -- they should be acting somewhat
37+
independently when taking on tasks, at least within the scope of the
38+
working group. They should plausibly be able to mentor others on simple
39+
PRs.
40+
- "Cordiality" -- contributors will be members of the organization and
41+
are held to a higher standard with respect to the [Code of
42+
Conduct][CoC]. They should not only obey the letter of the CoC but
43+
also its spirit.
44+
45+
[CoC]: https://www.rust-lang.org/policies/code-of-conduct
46+
47+
Being promoted to contributor implies a number of privileges:
48+
49+
- Contributors have r+ privileges and can do reviews (they are
50+
expected to use those powers appropriately, as discussed
51+
previously). They also have access to control perf/rustc-timer and
52+
other similar bots.
53+
- Contributors are members of the organization so they can modify
54+
labels and be assigned to issues.
55+
- Contributors are a member of the rust-lang/compiler team on GitHub,
56+
so that they receive pings when people are looking to address the
57+
team as a whole.
58+
- Contributors are listed on the rust-lang.org web page.
59+
60+
It also implies some obligations (in some cases, optional obligations):
61+
62+
- Contributors will be asked if they wish to be added to highfive rotation.
63+
- Contributors are held to a higher standard than ordinary folk when
64+
it comes to the [Code of Conduct][CoC].
65+
66+
## Full members
67+
68+
As a contributor gains in experience, they may be asked to become a
69+
**compiler team member**. This implies that they are not only a
70+
regular contributor, but are actively helping to shape the direction
71+
of the team or some part of the compiler (or multiple parts).
72+
73+
- Compiler team members are the ones who select when people should be
74+
promoted to compiler team contributor or to the level of member.
75+
- Compiler team members are consulted on FCP decisions (which, in the
76+
compiler team, are relatively rare).
77+
- There will be a distinct GitHub team containing only the compiler
78+
team members, but the name of this team is "to be determined".
79+
- Working groups must always include at least one compiler team member
80+
as a lead (though groups may have other leads who are not yet full
81+
members).
82+
83+
## How promotion decisions are made
84+
[hdam]: #how-promotion-decisions-are-made
85+
86+
Promotion decisions (from participant to contributor, and from
87+
contributor to member) are made by having an active team member send
88+
an e-mail to the alias `compiler-private@rust-lang.org`. This e-mail
89+
should include:
90+
91+
- the name of the person to be promoted
92+
- a draft of the public announcement that will be made
93+
94+
Compiler-team members should send e-mail giving their explicit assent,
95+
or with objections. Objections should always be resolved before the
96+
decision is made final. E-mails can also include edits or additions for the
97+
public announcement.
98+
99+
To make the final decision:
100+
101+
- All objections must be resolved.
102+
- There should be a "sufficient number" (see below) of explicit
103+
e-mails in favor of addition (including the team lead).
104+
- The nominator (or some member of the team) should reach out to the person
105+
in question and check that they wish to join.
106+
107+
We do not require all team members to send e-mail, as historically
108+
these decisions are not particularly controversial. For promotion to a
109+
contributor, the only requirement is that the compiler team lead
110+
agrees. For promotion to a full member, more explicit mails in favor
111+
are recommended.
112+
113+
Once we have decided to promote, then the announcement can be posted
114+
to internals, and the person added to the team repository.
115+
116+
## Not just code
117+
118+
It is worth emphasizing that becoming a contributor or member of the
119+
compiler team does not necessarily imply writing PRs. There are a wide
120+
variety of tasks that need to be done to support the compiler and
121+
which should make one eligible for membership. Such tasks would
122+
include organizing meetings, participating in meetings, bisecting and
123+
triaging issues, writing documentation, working on the
124+
rustc-guide. The most important criteria for elevation to contributor,
125+
in particular, is **regular and consistent** participation. The most
126+
important criteria for elevation to member is **actively shaping the
127+
direction of the team or compiler**.
128+
129+
## Alumni status
130+
131+
If at any time a current contributor or member wishes to take a break
132+
from participating, they can opt to put themselves into alumni status.
133+
When in alumni status, they will be removed from Github aliases and
134+
the like, so that they need not be bothered with pings and messages.
135+
They will also not have r+ privileges. **Alumni members will however
136+
still remain members of the GitHub org overall.**
137+
138+
People in alumni status can ask to return to "active" status at any
139+
time. This request would ordinarily be granted automatically barring
140+
extraordinary circumstances.
141+
142+
People in alumni status are still members of the team at the level
143+
they previously attained and they may publicly indicate that, though
144+
they should indicate the time period for which they were active as
145+
well.
146+
147+
### Changing back to contributor
148+
149+
If desired, a team member may also ask to move back to contributor
150+
status. This would indicate a continued desire to be involved in
151+
rustc, but that they do not wish to be involved in some of the
152+
weightier decisions, such as who to add to the team. Like full alumni,
153+
people who were once full team members but who went back to
154+
contributor status may ask to return to full team member status. This
155+
request would ordinarily be granted automatically barring
156+
extraordinary circumstances.
157+
158+
### Automatic alumni status after 6 months of inactivity
159+
160+
If a contributor or a member has been inactive in the compiler for 6
161+
months, then we will ask them if they would like to go to alumni
162+
status. If they respond yes or do not respond, they can be placed on
163+
alumni status. If they would prefer to remain active, that is also
164+
fine, but they will get asked again periodically if they continue to
165+
be inactive.

‎src/compiler/reviews.md

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
# Review policies
2+
3+
Every PR that lands in the compiler and its associated crates must be
4+
reviewed by at least one person who is knowledgeable with the code in
5+
question.
6+
7+
When a PR is opened, you can request a reviewer by including `r?
8+
@username` in the PR description. If you don't do so, the highfive bot
9+
will automatically assign someone.
10+
11+
It is comment to leave a `r? @username` comment at some later point to
12+
request review from someone else. This will also reassign the PR.
13+
14+
## bors
15+
16+
We never merge PRs directly. Instead, we use bors. A qualified
17+
reviewer with bors privileges (e.g., a [compiler
18+
contributor](./membership.md) will leave a comment like `@bors r+`.
19+
This indicates that they approve the PR.
20+
21+
People with bors privileges may also leave a `@bors r=username`
22+
command. This indicates that the PR was already apporved by
23+
`@username`. This is commonly done after rebasing.
24+
25+
Finally, in some cases, PRs can be "delegated" by writing `@bors
26+
delegate+` or `@bors delegate=username`. This will allow the PR author
27+
to approve the PR by issuing `@bors` commands like the ones above
28+
(but this privilege is limited to the single PR).
29+
30+
## Expectations for r+
31+
32+
bors privileges are binary: the bot doesn't know which code you are
33+
familiar with and what code you are not. They must therefore be used
34+
with discretion. Do not r+ code that you do not know well -- you can
35+
definitely **review** such code, but try to hand off reviewing to
36+
someone else for the final r+.
37+
38+
Similarly, never issue a `r=username` command unless that person has
39+
done the review, and the code has not changed substantially since the
40+
review was done. Rebasing is fine, but changes in functionality
41+
typically require re-review (though it's a good idea to try and
42+
highlight what has changed, to help the reviewer).
43+
44+
45+

0 commit comments

Comments
 (0)