RFC: Refactor the libs team#3984
Conversation
nia-e
added
T-libs-api
|
|
||
| After some member of libs has been inactive for at least twelve months, they may be asked if they wish to remain on the team; otheriwse, they may be moved into alumni, with privileges revoked. An alum may at any point self-nominate to be reinstated, requiring a second and 10 day period without any objections as if they had been nominated by a team member in order to be reinstated. | ||
|
|
||
| #### ACP process |
There was a problem hiding this comment.
This is I guess more of a plan for the std dev guide than this RFC (I.e., not blocking the RFC), but I do think we should encourage all major libs changes to go through the ACP process even if they don't necessarily change the API surface. Stuff like changing behaviour that we're allowed to change (ex. platform-specific stuff) or large refactors should be encouraged to go through the ACP process instead of going straight to a PR as they sometimes do today.
We should also feel encouraged to open ACPs just to track other discussions happening on places like Zulip just for visibility etc.
(I think that the definition of the ACP process here is broad enough to allow changing all that, just, I think it's important enough to mention here in case it does affect the RFC wording slightly.)
There was a problem hiding this comment.
a philosophical point @joshtriplett raised in private conversation that somewhat informed the way i wrote this rfc was to try to only change processes that are directly impacted by the team restructure. the acp process has admittedly partly been an exception since the changes are moderately broader. i think something like what you're suggesting would be interesting direction to go in but shouldn't explicitly be enshrined in rfc (as then changing it would take an rfc). does any of the wording in that section prevent expanding the scope as you suggest? if so i'm happy to loosen said wording ofc
There was a problem hiding this comment.
So, I would interpret the RFC as the ACP being a broad process the libs team has the right to change, though it presumably would require an FCP like anything else on the std dev guide. I just am not 100% confident in that interpretation which is why I kind of wanted to express that interpretation and just kind of confirm it fits in line with what is written.
There was a problem hiding this comment.
To the extent we changed the ACP process here, much of it was an attempt to make sure that process made sense with the new team structure. We can always change it more as needed.
|
|
||
| This fuzzy overlap between top level teams results in occasional friction during their respective team meetings, with time often spent attempting to determine whether a given agenda point is indeed relevant for said meeting or should be discussed in the other top level team's meeting. Attendance of these meetings also does not necessarily follow either the distinction between the teams or the separation between libs/libs-api and libs-contributors, with the FCP rights of the top-level teams not matching either those involved in conversations or those doing work on various aspects of libraries. | ||
|
|
||
| Furthermore, the libs-contributors team now numbers 20 members, alongside auxiliary teams that strongly overlap in responsibilities such as crate-maintainers and libc. The permissions afforded to the members of these teams are approximately equal between each other, and the distinction moreso represents the historical circumstances whereby a given member entered the broader libs team family than their concrete current areas of involvement. |
There was a problem hiding this comment.
libc is just under crate-maintainers, for what it's worth
|
|
||
| The top-level team consists of all members of any team previously under the libs team family. That is, all former members of libs, libs-api, and libs-contributors are to be consolidated into a new libs team. Members of the crate-maintainers team are automatically extended an invitation to join the new libs team should they so desire. Members are granted *umbrella privileges* as above, with the possibility of adding themselves to *review rotation*. | ||
|
|
||
| It is expected that the libs-fcp team schedules at least one weekly libs team meeting, wherein at least items nominated for the libs team are discussed. The libs-fcp team is free to decide internally when its meetings are held, their duration, and which topics are or are not relevant to any given meeting, so long as they are held on a consistent schedule which reasonably accomodates for the availabilities of all libs-fcp members and enables participation from other libs members. All meetings are to be open to the public unless the libs-fcp team decides by consensus to restrict attendance for some particular meeting. Minutes and agendas from public meetings must also be posted publicly on Zulip. |
There was a problem hiding this comment.
Should this be s/libs-fcp/libs? This is the first time libs-fcp is mentioned in the doc.
There was a problem hiding this comment.
no, the responsibility is on libs-fcp to schedule said meeting, but I'll clear up wording
There was a problem hiding this comment.
That might be worth a mention in the libs-fcp section, just to point out if they're kind of the ones to steer the team and handle things like scheduling
There was a problem hiding this comment.
reworded to match intent better
|
|
||
| #### Selection process | ||
|
|
||
| Anyone whose addition may be valuable to the development of the Rust standard library or related crates under the purview of the libs team may be nominated for membership in the team by an extant member. This nomination does not necessarily have to be expansive, but should be sufficient to assure the team that the nominee can be trusted with *umbrella privileges*. This may be as brief as a single sentence if there is no serious ground for concerns. Note that contributions need not necessarily consist of code, but also include documentation, productive engagement in complex conversations, and anything that could be seen as facilitating the work of other members. |
There was a problem hiding this comment.
May want to mention where this takes place. I assume a "Nominating Ferris Jr." thread on Zulip similar to t-compiler?
There was a problem hiding this comment.
id leave the details there to be decided ad hoc, but we should clarify that yes. just unsure that should go into this rfc ig
|
|
||
| Anyone whose addition may be valuable to the development of the Rust standard library or related crates under the purview of the libs team may be nominated for membership in the team by an extant member. This nomination does not necessarily have to be expansive, but should be sufficient to assure the team that the nominee can be trusted with *umbrella privileges*. This may be as brief as a single sentence if there is no serious ground for concerns. Note that contributions need not necessarily consist of code, but also include documentation, productive engagement in complex conversations, and anything that could be seen as facilitating the work of other members. | ||
|
|
||
| Any preexisting member may issue an objection to a nominee. Objections are considered blocking in the nomination process, and are to be accompanied by motivating reasoning. The criteria which may justify an objection are left intentionally unspecified, so as to allow for flexibility in the decision-making process. By courtesy, objections are to be sent privately to the team leads instead of being announced publicly; however the motivation should, if possible, be made public. |
There was a problem hiding this comment.
What exactly is an objection vs. its motivation that should be shared separately?
For t-compiler you can just mention any concerns on the (team-private) nomination thread. It seems helpful if they are at least visible to team members so others can agree or disagree.
There was a problem hiding this comment.
the intent was effectively, "X particular person objects to Y's nomination" stays private but the anonymised rationale in the form of "there is an outstanding objection to Y on the grounds of $foo" should be made public. again happy to edit wording to make that clearer but this is moreso a guideline
There was a problem hiding this comment.
For the compiler threads, objections tend to lead to follow up like "that's been my experience too", "how long ago was this?", "can you link that PR?", "I have some concerns that I don't want to list here, I'll bring it up with the leads", etc. If it winds up similar for libs then I expect that's going to be difficult to anonymize, especially given the smallish team size, and IMO probably not worth it.
But if a mechanism has already been figured out then it doesn't hurt to try.
| Members may also second a nominee if they believe them to be a valuable addition to the team, without necessarily requiring any motivation. | ||
|
|
||
| If a period of 10 days has passed within which a nominee has been seconded and has no outstanding objections, the nominee is automatically added to the team and granted the relevant privileges. If the nominee was not previously part of the Rust project, moderation will first be asked to ensure there are no potential issues with their joining, with the addition to the team only taking effect after moderation signoff. | ||
|
|
||
| If on the contrary, 20 days after a nomination, no seconds are outstanding and/or there are still outstanding objections, a countdown of 10 days begins. If objections persist, or, lacking objections, no seconds are put forward, the nomination is automatically withdrawn. Note that this similarly requires that there exists some singular objection which is outstanding for the entirety of these 10 days. |
There was a problem hiding this comment.
10 days seems a bit fast, some people would probably wind up missing out on discussion. I'm not sure how to qualify this but it would be nice if it could wait until e.g. about half of active team members had left a 👍 or some other indication that they'd at least seen it.
There was a problem hiding this comment.
added a bit about checking there's been enough discussion (cc @Amanieu since this counts as making your job harder)
| Any libs team member may approve an [API change proposal][acp] that has been submitted (excepting the author of the ACP). It is highly recommended, though not explicitly required, that a waiting period of ten days from submission be observed between an ACP being submitted and it being approved. | ||
|
|
||
| Approval of an ACP does not necessarily guarantee that it will be included stably in the standard library, but signals that the relevant proposal may be of interest to the team, and seems *reasonably likely* in the judgment of a libs member to pass a subsequent libs-fcp team FCP without objecions. It is left to the judgement of individual team members whether some given ACP has received the necessary amount of scrutiny before being approved, and approval should signal confidence from the approver in the ACP's chances of future stabilisation. Note that ACPs proposing a [breaking change][breaking] require a subsequent FCP. | ||
|
|
||
| An ACP should *not* be approved if its author does not appear to have thoroughly explored alternative solutions and there appear to be, or will be in the near future, outstanding conflicting proposals that have not also been given due consideration. |
There was a problem hiding this comment.
There are some existing concerns about accepting ACPs without team discussion - this expands upon that by opening the number of people that may second. Would it be reasonable to maybe require at least 2-3 seconds or a discussion?
... but signals that the relevant proposal may be of interest to the team, and seems reasonably likely in the judgment of a libs member to pass a subsequent libs-fcp team FCP without objecions
For what it's worth, I don't think I've ever felt this heh. With the exception of completely trivial things like constifications (which tend not to get ACPs) there's always some design surface area that the synchronous discussion seems to bring up.
There was a problem hiding this comment.
If the (informal) meeting requirement is being removed, I wonder if there would be value in creating Zulip threads to discuss ACPs similar to compiler MCPs, rather than discussing on the GH thread. That tends to be a bit more conversational than discussion on an issue.
There was a problem hiding this comment.
a heavier mechanism was originally suggested here but the result of the discussion in t-libs/meta on zulip was that even this suggested ACP process constitutes a compromise, with some voices being in favour of relaxing it more. personally i think it's an acceptable failure mode if "bad ACPs" make it through so long as they aren't stabilised, and slowing down discussion or requiring multiple seconds can be demotivating to new contributors
There was a problem hiding this comment.
hopefully clarified language here to signal better the intent of "ACP accepted" = "we want an API that is vaguely this shape, modulo bikeshed and nitpicks"
There was a problem hiding this comment.
Is it really more contributor-friendly to accept an ACP and ask for followup changes later, or to potentially delete their work after they've gone through the effort? :)
Currently the bar for a ACP acceptance is loose consensus from libs-api, which typically seems to mean 2/5 or 3/5 people agree. The libs team is about to grow to ~35 people: needing two of them to second would still be a significantly lower bar than we currently have.
A bias for action is good but I think it needs to be balanced with the fact that std doesn't need every ACP, even though you could probably find at least one person who likes each idea.
There was a problem hiding this comment.
The bar actually isn't loose consensus from libs-api; we still require only one person to accept it, although inject more scrutiny if something isn't obviously useful. The general idea is that ACP acceptance means we won't just straight-up delete someone's work; it may dramatically change shape and ship-of-theseus itself into something else, but it's unlikely to be deleted.
Also, more scrutiny generally gets applied for larger changes. Here's an example of a small change where one person's acceptance was totally possible and we actually questioned it a bit because we weren't sure: rust-lang/libs-team#252
The proposal? Add char::MIN, which is just \0, but similarly usize::MIN is just 0 and we have that. Seems reasonable, one person needed to accept it, no controversy.
There was a problem hiding this comment.
this is approximately my thought process. the listed relaxed acp process certainly puts more trust in team members, but mostly only brings it in line with the acp process that had been used in the past (where the acp section of meetings was moreso sitting in a call and separately sorting thru acps, giving approvals or rejections based on individual opinion and nominating for group discussion as an exception). and if something is controversial, that can always be brought up for sync discussion.
i will also cc @BurntSushi here since the language around objections was minimally tightened since the last public draft, per more feedback i received
5 participants
Restructure and simplify the libs team, per conversations with @Amanieu as the lead & broader team membership.
cc @rust-lang/libs @rust-lang/libs-api @rust-lang/libs-contributors
Rendered