# 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 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 up 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`