Warestack teams group members, repositories, active rules, and automations. They are scope, not a Slack DM target. Propose a team when one engineering team clearly owns many in-scope repos. Propose repository scope when repos must stay isolated.
Propose team-scoped when
- One GitHub team (or Warestack team) reviews and merges across several production repos.
- They want one live-card chain and one rule pack, not a copy per repo.
- Overview, Events, metrics, and the weekly digest should roll up that team, then the space.
Propose repository-scoped when
- Two repos have different owners, channels, or blast radius.
- They asked for isolation (start with 1–2 repos).
- An inherited team rule would pollute a sensitive repo — suppress it with a disabled repository configuration; do not edit the team rule.
Always name a person
| Role | Object | Can receive Slack DM? |
|---|---|---|
| Repository owner | Individual GitHub identity + Slack binding | Yes — Review SLA second hop |
| Team | Coverage and dashboards | No |
| Requested reviewer | GitHub login with Slack binding | Yes — Review SLA first hop |
Do not propose a GitHub team or a Slack channel as the Review SLA owner. See People, Repositories, and Repository or team.
What to output
For each in-scope repo: GitHub full name, proposed Warestack team (or none), individual owner login, Slack identity confirmed / unknown, why this repo (one real PR). Extra repos are later, not a bigger day-one blast radius.
Last updated on