Define a permission scheme for maintainers

For the few formal teams we have as well as generally on NixOS/nixpkgs the process is mostly implicit and unstructured.

Nixpkgs uses a magic issue where @domenkozar essentially hands out commit bits based on comments. The Nix team got into working mode after pestering @edolstra into setting up permissions. This

We are currently blocked on that in the @NixOS/documentation-team where we have to make up the process as we go, and have to resort to ask org owners ad hoc. It would be good to have something written down that the next generation of community members and team leads can refer to.

Proposal

1. Implement NixOS/foundation#21 and make team leads maintainers for their GitHub team
2. Give team leads merge access to all repositories their team is concerned with
3. Give each team triage access to the same repositories
4. Give team leads write access to the NixOS Calendar
5. Use teams for CODEOWNERS and establish the practice of team leads merging PRs approved by team members

The advantage of this is what amounts to a hierarchy of responsibilities, where team leads can decide themselves who they trust with curating project boards and how much energy to spend on double checking their team members' reviews, but are ultimately responsible for merging changes.

Related:

• https://github.com/NixOS/rfcs/pull/55 (retire related committers)
• Discourse: Nix deserves great governance (comment by @infinisil)
• https://github.com/NixOS/nix.dev/issues/365

Start by reviewing foundation#21, the linked RFC, the Discourse discussion, and nix.dev#365 to understand the existing governance context. Document the agreed permission scheme for team leads and teams, including repository access, Calendar access, and CODEOWNERS practice, with the resulting responsibilities clear for future team leads.