re-organise the compiler team

[davidtwco]

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
• Establish mechanism for scaling additional responsibilities that team members take on and recognising these contributions

Rendered text

@rust-lang/compiler @rust-lang/compiler-contributors

[oli-obk]

By what mechanism do we prevent growth beyond the desired range? Like, what if someone wants to be on FCP duty, but we already got 8 folk on the list?

[BoxyUwU]

Does a 4-8 limit actually matter in practice if all the members are responding "timely". We'd still have the problem of "FCPs span a wide variety of required knowledges and we dont want to encourage mindlessly checking a box because its not your area" but honestly maybe that's fine and if we are explicitly sayign to Not Do This we'd encourage growing the amount of documentation we have for areas so that people can more accurately evaluate fcps

[oli-obk]

"by signing up for FCPs you opt-in to start getting pinged after a week if you haven't reacted to the FCP. Contributors are encouraged to ping FCP folk if there are no more outstanding concerns."

[davidtwco]

I've added some wording here - we don't want a hard upper limit, the goal is just to have a reasonable amount of diversity of opinion in the FCP list; make sure that everything gets a thorough look; and doesn't take too long. We want the FCP list to be populated by people who are committing to never mindlessly checking their box, they're on the list because they're interested in engaging with all of the FCPs we get. Team members who aren't on the FCP list and have an opinion can still register concerns and things like that to be heard.

[davidtwco]

"by signing up for FCPs you opt-in to start getting pinged after a week if you haven't reacted to the FCP. Contributors are encouraged to ping FCP folk if there are no more outstanding concerns."

GitHub hadn't shown me this comment when I was posting mine, I can change the wording to be closer to this if that's preferred.

[wesleywiser]

I think specifying expectations for how frequently you're going to be pinged for reviews if you are an FCP reviewer is a good idea!

As David said, the upper limit is really just a suggestion, after ~8 people just collecting reviews from everyone in the group tends to take a while even when no major issues are raised. It's certainly possible that a larger group could also work if the FCP reviewers respond in a very timely manner.

[WaffleLapkin]

What do we do if we feel that there are too many people on FCP? (and it gets too long) It feels trickly, it's not like we can just kick someone, there needs to be some process...

[davidtwco]

I think the issue wouldn't be that there are too many people, but that some people on the list aren't reviewing promptly.

If we had twenty people on the list and everyone reviewed within a day, I think that would be okay, it's about making sure things move forward and setting expectations about promptness in FCP participation, rather than the number of people (unless maybe it meant that there was always some objection so nothing would progress - but that's a separate problem that we can deal with if we run into it).

[BoxyUwU]

I'm a big fan of these changes, thank you for working on this <3

[WaffleLapkin]

I like this. Thanks for working on this <3

I have some some comments and nitpicks though.

[lqd]

Thanks for working on this!

[tmandry]

This seems like a really positive change, thanks for the thought you've put into the RFC.

I have two questions that weren't directly answered:

• What happens to the current groups? Are all current contributors going to become team members? Are all current team members going to become FCP reviewers?
• Is the process for seconding and objecting to MCPs impacted at all?

[lcnr]

really happy with this RFC ❤️ was a pleasure to read

[davidtwco]

• What happens to the current groups? Are all current contributors going to become team members? Are all current team members going to become FCP reviewers?

Contributors would become team members and we'll go through the contributor list, see who would be eligible for maintainer and ask everyone if they want to be. After that, we'll work out who is involved in each activity.

• Is the process for seconding and objecting to MCPs impacted at all?

It isn't, I've added some wording about this.

[davidtwco]

I've also renamed "responsibilities" to "maintenance activities". I was never happy with "responsibilities" as the term and I think maintenance activities is better, but can change back if there is disagreement.

[jackh726]

This is amazing. Thank you @davidtwco (and everyone who has provided input).

[nnethercote]

This generally sounds good. My main thoughts are about how the various roles are recorded. I often look at the Compiler team and Compiler team contributors lists, which I view as the canonical source for the current memberships. The RFC doesn't mention those lists. What would they look like? Will there be a single place where I can see which people are signed up for which maintenance tasks? How will alumni be recorded?

[jackh726]

Thinking about it: Is it worth distinguishing FCPs like this (i.e. FCPs about the team itself) from "typical" FCPs in regards to who is involved?

I actually don't know the right answer here! I think there are a few options, like "all Maintainers would be involved" or "team leads are responsible for ensuring consensus", and they have their own tradeoffs.

[davidtwco]

Is it worth distinguishing FCPs like this (i.e. FCPs about the team itself) from "typical" FCPs in regards to who is involved?

I've added a little bit of wording saying that we have the option to include more people, such as the whole team or all maintainers, if it makes sense to do so, like on an FCP such as this.

[fee1-dead]

noticed typo :)

[inquisitivecrystal]

Before merging this, it would probably be worth changing the title of the RFC file to reflect the terminology currently used (rather than trusted contributor, which is from an earlier version). Actually, something based on the title of this PR, like compiler_team(_membership)_reorganization or reorganize_compiler_team(_membership), might be clearest.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[davidtwco]

Before merging this, it would probably be worth changing the title of the RFC file to reflect the terminology currently used (rather than trusted contributor, which is from an earlier version). Actually, something based on the title of this PR, like compiler_team(_membership)_reorganization or reorganize_compiler_team(_membership), might be clearest.

Renamed this now :)

[wesleywiser]

Hooray! The @rust-lang/compiler team has decided to accept this RFC.

To track further discussion, subscribe to the tracking issue here:
rust-lang/compiler-team#757