diff --git a/text/0000-compiler-team-member-reorg.md b/text/0000-compiler-team-member-reorg.md new file mode 100644 index 00000000000..5a4a4dd9317 --- /dev/null +++ b/text/0000-compiler-team-member-reorg.md @@ -0,0 +1,416 @@ +- Feature Name: N/A +- Start Date: 2024-01-19 +- RFC PR: [rust-lang/rfcs#3599](https://github.com/rust-lang/rfcs/pull/3599) +- Rust Issue: N/A + +# Summary +[summary]: #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 +[motivation]: #motivation + +Compiler team contributors were introduced [in 2019 with RFC 2689][rfc2689], +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][review_queue_analysis], 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. + +[rfc2689]: https://rust-lang.github.io/rfcs/2689-compiler-team-contributors.html +[review_queue_analysis]: https://borrowed.dev/p/on-the-compiler-teams-review-queue + +# Definitions +[definitions]: #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][expectations] 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][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. + +[expectations]: https://forge.rust-lang.org/compiler/reviews.html#expectations-for-r +[triagebot]: https://forge.rust-lang.org/triagebot/index.html + +# Guide-level explanation +[guide-level-explanation]: #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][team-members] and then [Maintainers][maintainers]. + +## Team Members +[team-members]: #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][coc] but its spirit. + +Team members can choose to take on additional maintenance activities, such as +those listed in the [maintenance activities][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. + +[Compiler Development Guide]: https://rustc-dev-guide.rust-lang.org/ + +## Maintainers +[maintainers]: #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][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][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. + +[coc]: https://www.rust-lang.org/policies/code-of-conduct + +### Maintenance activities +[maintenance-activities]: #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]: #team-leads + +Team leads are defined in [RFC 3262][rfc3262] and is unchanged by this RFC. It is +not required but anticipated that those elected for team leads would be or have been +maintainers. + +[rfc3262]: https://rust-lang.github.io/rfcs/3262-compiler-team-rolling-leads.html + +# Drawbacks +[drawbacks]: #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 +[rationale-and-alternatives]: #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 +[prior-art]: #prior-art + +- [Maintenance activities][maintenance-activities] are similar to [an + unsubmitted proposal by Niko Matsakis in December 2020 to have "elected + officers"][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. + +[officers]: https://hackmd.io/S9xqmwJbSI-a9mFdK9yQBA + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +None! + +# Future possibilities +[future-possibilities]: #future-possibilities + +- Maintenance activities could be formalized further - see references in + [Prior art][prior-art]. +- Minimum requirements of maintainers could be elaborated further.