Summary

Re-organise the compiler team:

  • Re-define and rename the tiers of membership
  • Change how team members and contributors are promoted
  • Document expectations of team members and maintainers
  • Establish mechanism for scaling additional maintenance activities that maintainers take on and recognising these contributions

Motivation

Compiler team contributors were introduced in 2019 with RFC 2689, the last significant change to the compiler team’s structure. A lot has changed in the project and compiler team since that time: we receive approximately twice as many pull requests each week, there are more responsibilities that team members choose to take on, and many members of the team are now employed to work on the project.

Given these increased demands on the team, it is important that the compiler team’s structure can grow while maintaining high-quality output and remaining sustainable for team members. Ensuring that team members aren’t assigned an untenable number of reviews each week requires that the team onboard new contributors and team members at a rate which keeps pace with project growth.

Furthermore, the day-to-day operations of the team are composed of more varied tasks than was the case when RFC 2689 was drafted, now including prioritisation and issue triage, performance triage, meeting agenda preparation, and review of major change proposals. Team members who choose to contribute to these efforts should have those additional activities recognised.

As the team gets larger, our processes need to remain efficient. Final comment periods (FCPs) have traditionally required sign-off from all team members, which can become onerous with more team members. As the number of compiler team members has grown from ~10 to ~15 since RFC 2689, the team has already noticed scaling issues with our FCP process.

Processes which scale poorly with team size have acted as a unconscious disincentive to promote compiler team contributors to compiler team members. Similarly, the team has found that nominations being the primary mechanism for promotion to compiler team contributor or member tends to result in contributors falling through the cracks and being considered team members in the minds of the team but not actually having been nominated for promotion.

Since RFC 2689, the compiler team contributor role’s purpose has become confused. It is often beneficial to be able to grant the infrastructure and merge permissions to trusted contributors quickly so they can work more efficiently. However, it is also desirable for the compiler team contributor role to act as recognition for those contributors who have shown staying power and that the team would like to recognise. These goals are in tension, adding new contributors early and regularly improves the efficiency of the compiler team while watering down the recognition and sense of achievement that the role would ideally confer.

In addition, as compiler team contributors and members increasingly leverage their contributions to gain employment/contracts to contribute to the project full-time (or otherwise), the naming of the compiler team contributor role can be confusing. An employer unfamiliar with the project may not realise that a compiler team contributor is a role within the project which recognises regular contribution and trust rather than just having made a handful of contributions and thus being a contributor.

Definitions

There are various permissions/privileges/responsibilities which will be referenced in later sections of this RFC, defined here:

  • r+
    • Contributors with r+ privilege are able to approve pull requests to be merged by bors. Contributors should not merge their own pull requests (with the exception of re-approving their own work on behalf of another contributor after a rebase or similarly trivial change). r+ permissions apply to the whole repository, but it is expected that contributors limit themselves to only those parts of the rust-lang/rust repository that are under the purview of the compiler team (unless granted r+ from other teams too), and for subsystems/pull requests that they are confident reviewing.
  • try
    • Contributors with try permissions are able to trigger complete toolchain builds for a pull request or commit, which are then used by rustc-perf and crater. try permissions aren’t available to everyone because try builds can pose a security risk: try builds have access to secrets and the resulting builds are hosted on static.rust-lang.org where we would never want malicious code.
  • review rotation
    • Contributors on the review rotation will be randomly assigned to new pull requests submitted to the compiler. Being on the review rotation is one of the best ways for contributors to help the compiler team and learn new parts of the compiler. Review capacity is one of the most important resources that the team has, as it enables our progress in the compiler’s continued development and maintenance.
  • organization membership
    • Contributors that are added to the rust-lang/compiler team in the GitHub organization can be assigned to issues/pull requests, modify labels, receive group mentions and receive a “Member” badge next to their name.
  • rustc-perf
    • Contributors with permissions to use rustc-perf can request benchmarking of their pull requests (and pull requests they are reviewing). rustc-perf permissions are useful for regular contributors as it is common to need to request benchmarks from contributors with permissions. rustc-perf permissions only make sense alongside try permissions.
  • crater
    • Contributors with permissions to crater can request crater runs to check whether their code breaks any public ecosystem code. crater permissions only make sense alongside try permissions.
  • dev desktops
    • Contributors with access to developer desktops are able to connect to shared development servers that they can do their contributions from.
  • triagebot
    • triagebot is a GitHub bot that can perform helpful tasks on issues and pull requests. Many of its functions are available to everyone, such as issue claiming, but some functions may be restricted to project/team members.

Guide-level explanation

Contributors start without any particular privileges, permissions or responsibilities and can contribute whatever they’d like. Contributors can progress to Team Members and then Maintainers.

Team Members

Being able to grant permissions to trusted contributors quickly is beneficial to enable them to contribute to the project more efficiently and review and approve work of their collaborators.

Any contributor can request to become a team members by contacting the compiler team’s leads, or current maintainers and team members can nominate a contributor. Team leads will check for a reasonable contribution history, and will check if the current team have any serious concerns related to contributor conduct (waiting approximately one week).

When evaluating a candidate’s contribution history, length of time and consistency of contributions and interactions with other contributors and maintainers will be taken into account. It is important to note that many kinds of contributions will be considered such as code contributions, helping with issue triage and bisection, running meetings and creating minutes, documentation contributions for rustc internals or the Compiler Development Guide, etc.

Team member is a mix of RFC 2689’s “working group participant” and “compiler team contributor” roles. It is explicitly intended to be granted more liberally to contributors who have demonstrated competence and trustworthiness, for whom they would be able to work more effectively with these permissions and can be trusted to use them responsibly. Team members do not need to have experience with most of the compiler, and can be specialised to specific subsystems of the compiler.

Team members are granted r+, try, triagebot, rustc-perf, and crater permissions; organization membership; and dev desktop access. Team members can second major change proposals. Team members are considered members of the Rust project as a whole, and are automatically eligible for any benefits that incurs (e.g. invitations to meetups of project members). As representatives of the Rust project, team members are expected to obey not just the letter of the Code of Conduct but its spirit.

Team members can choose to take on additional maintenance activities, such as those listed in the maintenance activities section. Participating in the team’s review rotation is encouraged.

If a team member becomes inactive (the contributor’s prior contributions and other interactions with the project cease) for six months or more, the team member will be moved into alumni status. At any point in the future, they can ask to be re-instated at the team member level if they desire.

Maintainers

Team members are eligible to become maintainers after they have continued to contribute actively for a year. Team members can contact team leads or will be contacted by team leads to enquire about promotion to maintainership. Team members who are eligible for maintainership do not have to become maintainers.

Unlike team members, maintainers are a subset of the team expected to consider themselves as exactly that, maintainers, of the compiler - put otherwise, to be invested in the quality of the compiler codebase and overall health of the compiler team, independent of their own projects. Maintainership is primarily intended to recognise and encourage participation in activities which are vital to the success of the compiler team and broader project.

Maintainers are expected to participate in the ongoing maintenance tasks that the compiler team is responsible for (with all of the expected caveats for vacation time, mental health breaks, etc) - listed as maintenance activities below. However, not all maintainers need to participate in these responsibilities to an equal degree. Maintainers should participate in these tasks to the degree that they are able

  • volunteers are not expected to participate as much as those employed to work on the compiler, for example. It is the responsibility of the compiler team leads to ensure that the ongoing maintenance tasks of the team can be completed sustainably.

Maintainers aren’t expected to make more contributions than team members or be more active, just participate in maintenance activities in addition to regular contributions.

Like team members, after inactivity for six months or more, a maintainer will be moved to alumni status. Maintainers who are no longer able to or are not helping to maintain the compiler but otherwise wish to continue contributing to the compiler can also be moved to alumni status and retain their team member status. Alumni can ask to be reinstated in the future.

Maintenance activities

There are various maintenance activities that a maintainer could take on to help the team.

Maintainers are expected to participate in maintenance activities - if they are unable to participate in at least one activity then it makes sense to step back from maintainership and just focus on their contribution. It isn’t possible to put a number on how many activities a maintainer should be involved in (and this isn’t an exhaustive list of activities), it depends on the contributor. Maintainers ideally wouldn’t be just-doing-the-minimum, but instead acting as a maintainer because they are genuinely invested in the health of the team and project. For most maintainers, it is anticipated that this will be a handful of activities that interest them, but that the specifics will vary with time.

Maintainers can get involved in any of these by contacting the team leads, by asking maintainers currently involved in these activities, or by asking in any venue where these activities are conducted (e.g. a Zulip stream). Team members can participate in activities too - these aren’t exclusively the purview of maintainers.

  • Final comment period (FCP) reviewer

    • Final comment periods are the process by which the team signs-off on a change before it is made, like stabilizing a feature.

      FCPs have always required whole team to sign-off, but this doesn’t scale as the team grows. As described above, this acts as a disincentive for the team to grow. Furthermore, not all FCPs are relevant to all team members and a diffusion of responsibility means that most team members just sanity-check and then sign-off. This isn’t ideal, as it doesn’t guarantee that someone on the team has thoroughly considered a FCP.

      Instead, have FCPs require sign-off from maintainers who opt-in to being an “FCP reviewer”, with the expectation that they will spend time reviewing an FCP thoroughly. FCP reviewers should also consider reaching out to relevant domain experts and soliciting their opinions whenever possible. Any project member can raise concerns with an FCP, which will be considered by the FCP reviewers.

      To function effectively, it is recommended that there be 4 - 8 FCP reviewers at any time, so that there is sufficient diversity of perspective. This is not a strict upper bound, as long as FCP reviewers are prompt in their reviews and the process isn’t unnecessary delayed due to the number of reviewers. If less than 4 FCP reviewers are available, the compiler team co-leads will act as FCP reviewers until the reviewers can be found - this lower bound is necessary to ensure that FCPs are reviewed thoroughly.

      FCP reviewers are expected to be able to review FCPs promptly (within a couple of weeks) - this could be checking their box, registering a concern or just commenting to say they’re still working on their review. FCP reviewers who consistently aren’t able to review FCPs promptly may be removed from the FCP reviewer activity - given that the purpose of the FCP activity is to ensure that FCPs are thoroughly reviewed by those engaged in doing so and that the team’s work isn’t unnecessarily delayed, FCP reviewers who aren’t doing this defeat the point of the activity existing rather than being something all maintainers do. Any reviewer removed can ask to be re-added when they have the bandwidth to participate in FCP reviews.

      An FCP can include more of the team (all maintainers or all team members, for example) if it makes sense to do so, such as FCPs for changes to the team’s structure.

  • Performance triage

    • There is a rotation of maintainers and other project members who check all of the interesting performance benchmarks from the last week to produce a report summarizing the improvements and regressions. This is valuable to keep track of the compiler’s performance over time and make sure that regressions are being addressed.

  • Issue prioritisation

    • The compiler team has a prioritisation procedure and policy to identify and label issues according to their importance. These labels feed into the backport procedure (what’s worth being backported) and work priorities of maintainers.

  • Backport reviews

    • On a regular basis, some maintainers participate in a review of pull requests which have been nominated for backporting to the beta or stable release. This involves a judgement call on the risk of backporting a particular fix versus the severity of the issue being addressed.

      Once those maintainers interested in backport reviews are identified, this function could be performed in a separate meeting or asynchronously, allowing the triage meeting to be streamlined and focused on nominated issues or other tasks requiring broader discussion.

      To establish a reasonable quorum of triage members, it is recommended that at least 4 members participate in triage meetings. In the event there are not enough triage members, the compiler team co-leads will act as triage members until additional members are found.

  • Review rotation

    • Every week, lots of pull requests are submitted to the compiler which need to be reviewed. Being on the review rotation is one of the primary ways that maintainers can help keep the wheels turning in the compiler team.

      It is strongly encouraged that all maintainers be a part of the review rotation.

  • Operations

    • There are various operations tasks like agenda preparation and taking meeting notes which are very useful for the team.

  • Tool development

    • There are various tools that the compiler team uses in support of its work, such as the performance tracking infrastructure, agenda generation tooling, etc. These tools are vital to the ongoing functioning of the team and their continued development is useful to the team.

  • RFC/MCP participation

    • Participation and review of RFCs and MCPs is important to ensure that these proposed changes/features are thoroughly considered.

  • Mentoring/working group leadership

    • Mentoring new and experienced contributors in changes is important to help onboard team members, retain contributors, and implement new features - keeping our work sustainable.

This list isn’t exhaustive, and this RFC shouldn’t be considered the canonical list of these activities. Similarly, this RFC isn’t intended to define how these activities are conducted (in meetings or asynchronously, etc), that should be decided and documented by those involved in each.

However activity participation is tracked, it should be easy for the team leads to have visibility into the participation in each to ensure that it is sustainable.

Team Leads

Team leads are defined in RFC 3262 and is unchanged by this RFC. It is not required but anticipated that those elected for team leads would be or have been maintainers.

Drawbacks

  • Granting permissions earlier may be a risk
    • We haven’t had any issues with contributors having staying power to the extent that we would trust them with permissions and then having those be used inappropriately. We can always revert changes if necessary.
  • Expectations of team members
    • This RFC formally establishes expectations which come with team membership. Some team members already assume that these expectations are there, but this wasn’t made explicit when current team members were made team members.

Rationale and alternatives

  • Get better at doing nominations
    • A lot of this proposal’s simplification of the way that promotions are granted is based on the premise that our current system doesn’t work well for us
      • but we could just try and do the current system better.
  • Only change review responsibilities
    • We could instead try to increase the number of reviewers on the review queue by just amending the current compiler team membership policy to include review rotation duty. This does not improve our ability to correctly promote contributors or recognize the ways individuals contribute to the maintenance of the compiler but could be reasonable if implementing all of the changes described here will take too long.

Prior art

  • Maintenance activities are similar to an unsubmitted proposal by Niko Matsakis in December 2020 to have “elected officers” within the compiler team responsible for different team functions. This RFC shares many of the goals of Niko’s earlier proposal, but is slightly less formal - activities are loosely-defined groups of contributors rather than elected positions, and there are no rotations or term limits.

    In this RFC’s proposal, it is expected that activites are shared amongst a group of team members, and that team members do less of other activities so that their workload is sustainable, but this isn’t enforced. Team leads are instead responsible for ensuring that the team is large enough to perform each activity sustainably.

Unresolved questions

None!

Future possibilities

  • Maintenance activities could be formalized further - see references in Prior art.
  • Minimum requirements of maintainers could be elaborated further.