rfcs
rfcs copied to clipboard
re-organise the compiler team
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
@rust-lang/compiler @rust-lang/compiler-contributors
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?
- 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.
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.
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?
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?
These are all important questions - I've been thinking of them more as implementation details that we can work out after the RFC lands. Wesley and I will make sure that the team have a chance to give us feedback on however we end up representing this in the teams repo.
Will there be a single place where I can see which people are signed up for which maintenance tasks? How will alumni be recorded?
I would expect that the Compilers team page would look roughly similar to how it does currently except that there would be a clear delineation between individuals who are Maintainers or Members and there would also be indications as to what maintenance activities each individual participates in. I agree there is a lot of value in making that information easy to find!
There may be additional sources for some of that information so there will probably not be a single place you can find it. For example, I would expect that while there will probably be some kind of marker in rust-lang/team toml for the review rotation, that information will also be duplicated in triagebot.toml.
At this point, I believe all outstanding feedback has been responded to and there seems to be general consensus so:
@rfcbot fcp merge
Team member @wesleywiser has proposed to merge this. The next step is review by the rest of the tagged team members:
- [x] @Aaron1011
- [x] @cjgillot
- [x] @compiler-errors
- [x] @davidtwco
- [x] @eddyb
- [x] @estebank
- [x] @jackh726
- [x] @lcnr
- [x] @matthewjasper
- [x] @michaelwoerister
- [x] @nagisa
- [x] @oli-obk
- [x] @petrochenkov
- [x] @pnkfelix
- [x] @wesleywiser
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
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.
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.
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.
:bell: This is now entering its final comment period, as per the review above. :bell:
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.
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 :)
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