RFC: Refactor the libs team#3984
Conversation
nia-e
added
T-libs-api
|
|
||
| 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.
There was a problem hiding this comment.
FWIW, I wouldn't really call libs a small team; there are currently 29 people on libs-contributors and that's not even combining with the other libs-related teams. Granted, there are 74 in compiler, so definitely more, but I think that the size has passed the point where everyone would be able to identify everyone else based upon small snippets for something like this. YMMV of course.
| 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
There was a problem hiding this comment.
I think this LGTM.
I continue to like the idea that ACPs should generally be a lightweight pulse check on whether libs-fcp would likely be willing to accept a particular change or not. The original problem they were trying to solve was to avoid contributors doing a bunch of work only to get a "no we don't want that" response.
There will certainly always be some risk that an ACP gets accepted but that the change ultimately doesn't pass FCP. I think that's okay and it should hopefully be pretty rare.
I don't know if it's intentional or not, but this RFC also doesn't explicitly require an ACP for every API change. I kind of think that's a good thing.
There was a problem hiding this comment.
semi-intentional. i've been of the opinion that there is such a thing as "too small to need an ACP" but that's not a universal opinion. either way, leaving that out means we can determine this internally in libs{-fcp} ^^
|
This looks fantastic btw. |
|
As per the dicussion in today's meeting. @rfcbot merge libs,libs-api |
|
@Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: 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. |
rust-rfcbot
added
proposed-final-comment-period
10 participants
View all comments
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