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.
3 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