Subteams

Ideas

• office hours
• zulip stream
• ping groups (zulip & mailing list)
• maintainer entries for documentation, mailing list & keyword

"subteam" principles

• A subteam is an extension of Rust maintainers on a particular topic/subject, the subject is across kernel subsystems, e.g. unsafe code, type design, macro, etc.

• A subteam (or working group or name TBD) generally should maintain documentation or tools regarding the corresponding subject owned by it. The maintainship of such items establish the expertise and the ownership of the subteam.

• Compared to usual subsystem maintainer groups, the scope of "subteam" is usually across muliptle subsystems, but leave the subsystem-specific decision-making to the subsystem maintainers.

Team suggestions

• safety <- Benno (assigned)

  • Also taking co-leaders :) @Alice? @Gary?

• docs

• format

• macros

• driver-design?

  • Does this mean design of APIs provided to drivers, the design of driver internals, driver lifecycle or something else? (Danilo)
    • I think one interesting part is guidance for subsystems how to incorporate device / driver infrastructure for their bus and class devices, driver APIs, etc. But this is something that I see as part of the responsibilities of the driver-core maintainers (as well).
    • Generally, I really like the idea of having a working group for that – gonna think about the scope a bit more.

  Boqun: I agree with the scope mentioned by Danilo here, I think what fits into a "driver-design" subteam scope is something from a safe-API-design PoV but specific for drivers.

• safe-API-design