New™ Libs Meeting 2021-06-16

# New™ Libs Meeting 2021-06-16 ###### tags: `Libs Meetings` `Minutes` **Attendees**: Josh, Jane, Mara ## Agenda **Main topic: Responsibilities of this new team, and how we are going to handle them.** - Handling critical issues and regressions (https://github.com/rust-lang/libs-team/issues/15) - Compiler team now does that for `T-libs-impl`. We should take over. - (Rename label `T-libs` to `T-libs-api`?) - MCPs (https://github.com/rust-lang/libs-team/issues/8) - (e.g. pthread/mutex overhaul, restructuring `sys/`, new platform support, large cleanups, etc.) - We should define a process and template for this, basing it on the lang and compiler MCP process. - Std dev guide: https://std-dev-guide.rust-lang.org/ - Incomplete. Has been standing still since KodrAus left. - necessary step to increasing team size / reviewers - Add things to this document as people ask questions that don't have documented answers - Expanding the number of reviewers - New `library-contributors` team. - Need more documentation first? (See next item.) - Expanding this team - What do we need? - What's the expected path onto the team? - Ensuring official rust-lang crates are maintained - See also "Rust-lang crate ownership policy" RFC: https://github.com/rust-lang/rfcs/pull/3119 Organisational: How often and where/how do we meet? ## Meeting notes and conclusions Weekly meetings. New meeting link every time, post publicly. Jane to add T-critical, regressions, beta-nominated etc. to agenda. Labels: Josh: I think this will lead to some confusion in the broader Rust project. Better for us to have to work out what `T-libs` means than for other Rust folks to figure out which label they should apply. Mara: We need separate labels to keep the FCPs separate. Josh: We're unlikely to need FCPs for the top-level libs team, so `T-libs` can just be for the libs-api team, and then if library-contributors will need to do FCPs we can make a label for that team (renaming `T-libs-impl`?) Josh: willing to go along with the consensus to use `T-libs` for impl and `T-libs-api` for api. Would eventually like the project triaging properly into those two buckets rather than dumping everything on T-libs, though. `T-libs-api` + `T-libs`. Might be confusing, people are used to `T-libs` for api. `T-libs` on RFC repo almost always means "api" RFC repo only has `T-libs-api` now. Try `T-libs-api` + `T-libs` for now. We relabel `T-libs` → `T-libs-api` when needed. Let's see how it works. Take over triage from compiler? Yes, starting next week. Ask compiler to let us know if anything slips through the cracks. Want the dev guide to help us add more people. MCP process: MCP for libs-impl would be just like compiler MCP, to coordinate larger changes. libs-impl can decide whether to charter a group, ask for more detailed design work, or just ask for a PR. MCP for libs-api would be like lang MCP: propose a problem to be solved and a general solution path, libs-api can decide whether to charter a group, ask for an RFC, or just ask for a PR. Would libs-api use MCP at all? We need: - Github issue template on libs-team repo - rustbot (handles seconds and posting to Zulip) - ?? Josh to set it up (github template, label, bot config). Jane to extend the agenda generator, to also include MCPs. Josh to set up action item document agenda generator should be documented in std-dev-guide unstable-api collector tool should be documented in std-dev-guide Any other useful tools should be documented in std-dev-guide Could we have a page that's auto-generated using unstable-api for every nightly feature we have? Other thing for the std dev guide: List of allowed unstable features in std. get 'permission' from the compiler team for each, with potential pitfals/warnings Consider restricting allowed features via rustc option so that you *can't* use them in std/alloc/core Start with specifically the ones we're using now. Ask for permission every time a new one gets added. Review the existing list and see which ones concern the compiler team. Should we namespace features, so that we can distinguish lang features and lib features by name? (We might not want to force that on the broader ecosystem, but it'd be nice in the compiler and standard library.)