Update compiler team membership page

src/compiler/mcp.md

@@ -40,7 +40,7 @@ If you would like to make a [major change] to the compiler, the process is as fo
     * Alternatively, you can submit a [design meeting proposal] to have a longer, focused discussion.
 * To be accepted, a major change proposal needs three things:
     * One or more **reviewers**, who commit to reviewing the work. This can be the person making the proposal, if they intend to mentor others.
-    * A **second**, a member of the compiler team or a contributor who approves of the idea, but is not the one originating the proposal.
+    * A **second**, a member of the compiler team who approves of the idea, but is not the one originating the proposal.
     * A **final comment period** (a 10 day wait to give people time to comment).
         * The FCP can be skipped if the change is easily reversed and/or further objections are considered unlikely. This often happens if there has been a lot of prior discussion, for example.
 * Once the FCP completes, if there are no outstanding concerns, PRs can start to land.
@@ -99,7 +99,7 @@ Note that whether something is a major change proposal is not necessarily relate
 
 The MCP "seconding" process is only meant to be used to get agreement
 on the technical architecture we plan to use. It is not sufficient to
-stabilize new features or make public-facing changes like adding a -C
+stabilize new features or make public-facing changes like adding a `-C`
 flag. For that, an `rfcbot fcp` is required (or perhaps an RFC, if the
 change is large enough).
 
@@ -124,7 +124,7 @@ changes that affect cargo.
 
 Please direct technical conversation to the Zulip stream.
 
-The compiler-team repo issues are intended to be low traffic and used for procedural purposes. Note that to "second" a design or offer to review, you should be someone who is familiar with the code, typically but not necessarily a compiler team member or contributor.
+The compiler-team repo issues are intended to be low traffic and used for procedural purposes. Note that to "second" a design or offer to review, you should be someone who is familiar with the code, typically but not necessarily a compiler team member.
 
 * Announcing that you "second" or approve of the design.
 * Announcing that you would be able to review or mentor the work.

src/compiler/membership.md

@@ -2,11 +2,9 @@
 
 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
+* members: regular contributors with r+ rights, bot privileges, and access to [infrastructure]
+* maintainers: members who have committed themselves to invest in the quality of the compiler and health of the compiler team
 
-[full members]: https://www.rust-lang.org/governance/teams/compiler
-[contributors]: https://www.rust-lang.org/governance/teams/compiler#compiler-contributors
 [infrastructure]: ../infra/index.html
 
 ## The path to membership
@@ -18,16 +16,16 @@ 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.
 
-## Compiler team contributors
+## Compiler team member
 
-Once a working group participant has been contributing regularly for
+Once an individual 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][hdam]
+member** (see the section on [how decisions are made][hdam]
 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
+appropriate. Being promoted to member is not just a function of
 checking various boxes. But the general sense is that someone is ready
 when they have demonstrated three things:
 
@@ -38,16 +36,16 @@ when they have demonstrated three things:
   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
+- "Cordiality" -- compiler team members will be part of the Rust organization and
   are held to a higher standard with respect to the [Code of
   Conduct][CoC]. They should not only obey the letter of the CoC but
   also its spirit.
 
 [CoC]: https://www.rust-lang.org/policies/code-of-conduct
 
-Being promoted to contributor implies a number of privileges:
+Being promoted to member implies a number of privileges:
 
-- Contributors have `r+` (approve a pull request) privileges and can do reviews
+- Members have `r+` (approve a pull request) 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. See the documentation for `bors` and `r+`
@@ -57,29 +55,32 @@ Being promoted to contributor implies a number of privileges:
   unless you have done a check for malicious code first and don't `r+` unless
   you are reasonably confident that you can effectively review the code in
   question.
-- Contributors are members of the organization so they can modify
+- Compiler team members are members of the Rust organization so they can modify
   labels and be assigned to issues.
-- Contributors are a member of the rust-lang/compiler team on GitHub,
+- Members become a part 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.
+- Members 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
+- Members will be asked if they wish to be added to the reviewer rotation.
+- Members may take part in various other [maintainer activities] to help the team. 
+- Members are held to a higher standard than ordinary folk when
   it comes to the [Code of Conduct][CoC].
 
-## What it means to be a compiler contributor
+[listed]: https://www.rust-lang.org/governance/teams/compiler
 
-Once you're a member of the compiler team contributors, a number of events will
+## What it means to be a compiler member
+
+Once you're a member of the compiler team, a number of events will
 happen:
 - You will gain access to a private Zulip stream, where internal discussions
 happen or ideas in very draft state are shared. Come and say hello to your new
 team members!
 - You will be subscribed and gain write access to a number of Github
   repositories. Check [this GitHub
-  page](https://github.com/orgs/rust-lang/teams/compiler-contributors/repositories)
+  page](https://github.com/orgs/rust-lang/teams/compiler/repositories)
   to see which repositories you have now access to. Some of them are pretty
   quiet or obsolete, so don't worry about all of them.
 
@@ -93,72 +94,49 @@ check how subscriptions to mailing lists work. It's a very low-volume mailing
 list (maybe a few emails per year), it's a way to communicate things to all
 contributors. We will not send you spam from this address.
 
-## Full members
+## Maintainers
 
-As a contributor gains in experience, they may be asked to become a
-**compiler team member**. This implies that they are not only a
+After being a compiler team member for a year, members can request or be asked to become a
+**compiler team maintainer**. 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).
+- Compiler team maintainers are expected to participate in at least one [maintenance activities].
+- Compiler team maintainers are identified with the "Maintainer" role on the rust-lang website.
 
 ## How promotion decisions are made
 [hdam]: #how-promotion-decisions-are-made
 
-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 `[email protected]`. This e-mail
-should include:
-
-- the name of the person to be promoted
-- a draft of the public announcement that will be made
+After an individual has been contributing to the compiler for a while,
+they may be nominated by an existing compiler team member or they may
+ask the compiler team leads if their contribution history is sufficient
+for team membership.
 
-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.
+The compiler team leads will check with the rest of the compiler team
+to see if there are concerns with extending a membership invitation to the
+individual and after a week (barring no objections), an invitation will be extended.
 
-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.
+If the invitation is accepted by the individual, the compiler team leads
+will update the [team] repository to reflect their new role.
 
-Once we have decided to promote, then the announcement can be posted
-to internals, and the person added to the team repository.
+[team]: https://github.com/rust-lang/team
 
 ## Not just code
 
-It is worth emphasizing that becoming a contributor or member of the
+It is worth emphasizing that becoming a 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,
+The most important criteria for elevation to compiler team member,
 in particular, is **regular and consistent** participation. The most
-important criteria for elevation to member is **actively shaping the
+important criteria for elevation to maintainer is **actively shaping the
 direction of the team or compiler**.
 
 ## Alumni status
 
-If at any time a current contributor or member wishes to take a break
+If at any time a compiler team member or maintainer 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.
@@ -174,20 +152,34 @@ they previously attained and they may publicly indicate that, though
 they should indicate the time period for which they were active as
 well.
 
-### Changing back to contributor
+### Entering or leaving the Maintainer role
 
-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
+After a compiler team member has committed to actively maintaining the
+compiler by becoming a Maintainer, they may wish to take a break from
+these ongoing responsibilities either temporarily or indefinitely.
+In either case, the Maintainer can let the compiler team leads know or
+open a PR themselves to the [team] repo, removing themselves from the 
+Maintainer marker team and placing themselves in the alumni list.
+
+In the future, if the former Maintainer would like to resume maintenance
+duties, they can request re-instatement from the compiler team leads.
+This request would ordinarily be granted automatically barring
 extraordinary circumstances.
 
+### Compiler team alumni
+
+Likewise, if any member of the compiler team would like to take an
+extended break from contribution and interaction with the team,
+they can let the compiler team leads know or open a PR themselves
+to the [team] repo, moving themselves to alumni status.
+
+If an alumni member would like to resume compiler team membership
+in the future, they can request re-instatement from the compiler team
+leads and this will normally be granted.
+
 ### Automatic alumni status after 6 months of inactivity
 
-If a contributor or a member has been inactive in the compiler for 6
+If a member or maintainer 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