[RFC]: Libs Team Governance

[KodrAus]

• Formally adopts (pilfers) the project group and major change processes used by the Compiler team for Libs.
• Commits to triaging unstable Libs features in the standard library.

Rendered

Thanks @XAMPPRocky @Dylan-DPC @timClicks for reviewing drafts of this RFC ❤️

[KodrAus]

cc @rust-lang/libs @rust-lang/wg-governance

[nikomatsakis]

Oooh, I hadn't heard about this RFC!

[KodrAus]

Ah I must've forgotten to actually tell anybody that it was up 🙂

We have actually made some pretty good progress on these things since the RFC was posted. We do have the Error Handling and Portable SIMD project groups running, and have space for regular sync time again.

Something that's come up is whether or not we should try put together an experts map like the Compiler has to cover areas like Iterator and the IETF RFC backed IpAddr and friends.

[nikomatsakis]

@KodrAus so I sat down and read this RFC and it's super inspiring. Thank you for putting the time and care to create it! I love that it's building on some of the compiler team processes etc. I do think we should sit down and explicitly go over and harmonize the conventions for project groups and the like between compiler/libs/lang.

I have a few questions that I had while reading:

• In terms of making project groups discoverable, I'd like to align the lang-team process and libs-team process (and then move the compiler-team to use the same). Lang-team is currently using representative issues tagged with project-group like ffi-unwind lang-team#19, where the idea is that we post updates and things but avoid general chatter. If libs team used a similar convention, it'd be neat because we could start to expose these kind of things on a general web page as well I imagine. (We also use the issues as part of a project board, which .. I have mixed feelings about, but which I think can be good.)
• I was surprised to see the process for adding new APIs begin with an RFC and then an MCP. I think we should align this with lang-team proposal process perhaps? The idea being that you first make a lightweight proposal that creates the group and then the group collaborates on the RFC (versus starting with the RFC). I'm curious if you considered that as an alternative.

[nikomatsakis]

Side note that on my "to do" list is to close the existing lang team proposal procedure RFC and open a fresh one. I think I will model it more on this RFC, I love the way you've structured this.

[KodrAus]

Thanks for the feedback @nikomatsakis! 🙇 It's been on my backlog to respond for a couple weeks 😅

Lang-team is currently using representative issues tagged with project-group like rust-lang/lang-team#19, where the idea is that we post updates and things but avoid general chatter.

We've been doing something very similar in the libs repo with our project groups: rust-lang/libs-team#3 and rust-lang/libs-team#4. I've been posting meeting summaries in there, but am wondering if that's a bit too noisy to be useful and making updates a kind of delta would be quicker to scan through. I'm not sure what granularity our groups will end up working at. Both Portable SIMD and Error Handling are tackling quite large tasks.

I was surprised to see the process for adding new APIs begin with an RFC and then an MCP.

I'd love to understand the lang team's process for this more! I think the RFC then MCP probably reflects our current mode of working more than trying to come up with something new. RFCs for new language features appear as PRs in rust-lang/rfcs "out-of-the-blue" (but usually after a lot of discussion in forums) and we decide through a MCP-like process whether we like the general idea enough to accept an unstable implementation ahead of accepting the RFC itself. That's not the case for @withoutboats's idea of revisiting the Pattern API though. I don't think we would expect an RFC for that first.

[KodrAus]

Just dropping a comment here that we’re also working on defining a proper Libs Impl team, which should get some mention in this RFC because it affects the way Libs works. It should probably also be a Compiler MCP since they’re currently handling critical libs impl things.

[KodrAus]

Another change to make here is to try align the charter with the format outlined in #3037

[KodrAus]

I no longer have the bandwidth to carry this forward but if somebody else would like to pick it up sometime in the future then please feel free!