Compiler team reorg

Summary

We will structure the compiler team as a set of members as well as a set off elected officers.

Membership. The compiler team "members" and "contributor" levels are merged and simply called members; being a member gives you the same benefits as a contributor today (r+ rights, review privileges, membership in the rust org, etc) as well as the right to serve as an officer and to vote in officer elections.

Officers. We have a number of officers with specific roles. These officers are typically elected from the set of compiler team members, though the leads may agree to permit a non-member in exceptional cases. One person may fulfill multiple offices but this is discouraged. The roles include:

• Team leads (2): Overall team leadership
• The technical leads (4): These are the people who decide on FCP requests and who make other sorts of contentious technical decisions.
  • The team leads are also included on FCP requests.
• The prioritization working group lead (2): Leads of the prioritization working group, which judges which issues are important and prepares the agenda
• The performance triage leads (2): Responsible for preparing weekly performance triage comparisons.
• The secretaries (2): They create the minutes from design and steering meetings
  • They could also do things like run/organize Zoom meetings, post records of any meetings to the Youtube account, potentially handling scheduling for teamwide meetings, etc.
• Other ideas
  • managing the review queue?

Rotation and outgoing officers. Note that each office has an "even number" of people occupying it. The idea is that each election we elect one new person to the office, and they will serve for two terms. During the second term, they are termed the "outgoing officer", and they have the responsibility of mentoring and training the new officer (as well as helping out). In the case of the technical leads, there are two outgoing officers.

Motivation

Goals

• Avoid leader burnout:
  • from doing the same job for too long
  • from doing too many jobs
• Normalize leadership transitions.
  • We want to have many people on the compiler team that could step into a leadership position if required.
  • We want a regular cadence of transitions with overlapping coleads who can provide mentoring to the new colead.
• Help the team decision making scale as our team grows
• Provide more oportunity for individuals to recieve recognition for the work they do on Rust, not just the "writing code" activities.
  • For example: technical design and steering, code reviews, prioritization, etc.

Elections and terms

We hold elections every year. The term of office is therefore two years in total, with the second year being in "outgoing" capacity.

How we hold elections

The slate of candidates is selected via nomination. There is a 1 week nomination period in which members of the team can nominate other members for a particular office. The nominee must agree to the nomination. The same person can be nominated for any number of offices.

Elections are held by "approval voting". This means that each member may vote for any number of candidates within a given election. The candidate with the highest number of votes wins. Ties are resolved via random selection or by mutual agreement of the candidates.

If the same person wins multiple offices, then they will typically resign from all but one, and the next highest vote count will be selected as winner. – what happens if there is no next highest vote in more than one election?

Special elections

In cases where an office resigns or is removed from office, we hold a special election. The procedure is the same as above except that the election is held for only one office. The winner will serve out the remainder of the term for the officer that they replaced.

Term limits

Outgoing officers are strongly discouraged from running for the same office again, but it is not strictly forbidden. This policy does not apply if the outgoing officer was voted into the office in a special election owing to resignation or removal of the previous officeholder.

??? – should we forbid it, at least in cases where there is another candidate? Requires the team leads to sign off on it? Forbid it completely for team leads, perhaps?

Resignation and removal

Officers may resign at any time, in which case a special election is held to select their replacement. That replacement will serve out the remainder of their term and may then run again as normal in the ordinary elections.

If an officer is removed from the compiler team because of Code of Conduct violations or any other reason, they are also removed from their post as officer and a special election is held to select their replacement. If the officer leaves the compiler team in an amicable fashion, however, the team leads may opt to permit them to serve out their term.

XXX do we need a policy for removing an officer that is not tied to code of conduct? Maybe. If we see that someone is not doing their duty, I think we would first encourage them to resign. The question is what they refuse to do so but still continue not to do their duty.

Rough ideas

• Perhaps we have designated term durations with the possibilty of doing multiple terms in a row. Colead terms would be offset from each other so that we don't have two new coleads both starting at the same time.

  • Example policy:
    • Term lengths are 1 year
    • One colead starts 1/1, the other starts 6/1.
    • You can serve up to 3 terms in a row, no restriction on total number of terms served.
  • Downsides:
    • Making hard rules can cause issues down the line (what if we no one available to serve other than a person who's already done so 2 or 3 times in a row?)
    • It seems better to create a culture that wants the overall goals achieved rather than enforcing via fiat.

• We could also define a series of recomendations that still align with our goals but are not hard rules.

  • To do this well, I think we would need to flesh out the goals we want to achieve and publish them.
  • Recomendations would be one path to achieve the goal but many such paths probably exist. .