Replace the TBD stub on the Permission Levels for Team Members wiki page

[ale210]

Dependency

Satisfied 2026-09-07 — #224 is closed. The permission model is now uniform across all four repos, so this page describes one rule rather than an inconsistency.

• Align devops and devops-security with incubator's permissions: only devops-* teams, and devops-merge on the push allow-list #224 — Align devops and devops-security with incubator's permissions: only devops-* teams, and devops-merge on the push allow-list

Overview

We need the "Permission Levels for Team Members" wiki page to actually have content, because it
is the only link under "Joining the DevOps team" on the wiki landing page and it currently reads
TBD followed by two bullet points describing what someone intended to write. A new member who
follows the one signposted path into the team lands on an empty page.

Action Items

• Document the GitHub team structure as it actually is: one devops-* ladder of five teams
  that each grant across all four DevOps repos at once — devops, devops-security,
  incubator and check-ghpages-versions. There is no per-repo split. After Align devops and devops-security with incubator's permissions: only devops-* teams, and devops-merge on the push allow-list #224 lands these
  are the only teams on any of the four repos, so the page can state that flatly; until then
  hackforla/devops also grants to product-managment* and guides*. Give the level each
  team grants (devops-read → read, devops-write → write, devops-merge → write,
  devops-maintain → maintain, devops-admin → admin) and say which one a new member starts
  on. Membership nests: read ⊃ write ⊃ maintain = admin ⊃ merge.
• Warn that the incubator-* teams are unrelated to hackforla/incubator. They grant on
  VRMS, HomeUniteUs and ballotnav — the project application repos — and on none of the
  DevOps repos. The names invite exactly the wrong conclusion, so the page should say so
  explicitly rather than staying silent. Worth noting they are also not a parallel ladder:
  the read-level team is called incubator with no suffix, incubator-maintain and
  incubator-admin both grant plain write, and incubator-merge grants on no repository at
  all.
• Cover the difference between devops-security and incubator access. It is not a team
  difference — it is branch protection. Write this against the state that exists after
  Align devops and devops-security with incubator's permissions: only devops-* teams, and devops-merge on the push allow-list #224 lands, which is the reason this issue is blocked on it: all four repos will restrict
  pushes to their default branch to the devops-merge team, so the page describes one rule
  rather than an inconsistency. All of them require one approving review and dismiss stale
  reviews, and those settings are already identical.
• Note that enforce_admins is false on all four repos, so the four devops-admin members
  bypass both the review requirement and the push restriction. State on the page that this is
  deliberate (decided 2026-09-07, recorded on Align devops and devops-security with incubator's permissions: only devops-* teams, and devops-merge on the push allow-list #224) rather than leaving it to read as an
  oversight, and do not imply the protections are absolute. This page is the agreed home for
  that decision — see Align devops and devops-security with incubator's permissions: only devops-* teams, and devops-merge on the push allow-list #224's last action item.
• Cover AWS access separately from GitHub access — they are different systems with different
  levels, and conflating them is a likely source of confusion. Scope is the incubator
  account 035866691871 only; the org/payer account is deliberately out of scope for this
  page. Document the three IAM groups (ops-leads, project-leads, read-only-group) and
  what each grants.
• Add a dated caveat to the AWS section saying the group model is being reworked, so a reader
  who finds it stale knows it was accurate when written rather than never checked. The
  per-project read/write groups with tag-conditioned policies will replace these three.
• Say who to ask for an access change and how, so the page ends with an action rather than a
  description.
• After pushing, follow the path a new member would take — wiki landing page → "Joining the
  DevOps team" → this page — and confirm it now answers "what can I do and how do I get more".

Resources/Instructions

• The page: Permission Levels for Team Members
• Linked from the "Joining the DevOps team" section of Home
• Teams: https://github.com/orgs/hackforla/teams
• Related but separate: Break-glass Account Guide
  covers emergency AWS access and should be linked, not duplicated
• The wiki is a separate git repo. git pull immediately before starting and again before pushing.
• Action items were rewritten twice on 2026-09-07 against live GitHub. The original body
  described "five teams per repo family ... and the same pattern for incubator-*", which is not
  how the org is set up — the devops-* teams are not per-repo, and the incubator-* teams grant
  on the project repos rather than on hackforla/incubator. The pre-edit body is preserved outside
  this repo. Re-derive with gh api repos/hackforla/<repo>/teams and
  gh api orgs/hackforla/teams/<slug>/repos before writing the page, since membership and grants
  drift.
• A second correction, same day: the first rewrite claimed devops and devops-security have
  no push restriction on their default branch. They do — the restriction is enabled with an empty
  allow-list, which is a different state from the toggle being off and is visible only in the API
  (restrictions present with users=[] teams=[] apps=[], versus the key being absent entirely).
  That is what Align devops and devops-security with incubator's permissions: only devops-* teams, and devops-merge on the push allow-list #224 fixes and why this issue now depends on it. Do not describe those two repos as
  unprotected.
• Follow-on: #222 is blocked on this issue. Once
  this page answers how someone gets added, the landing page's inline "How you get access"
  paragraph gets cut back to a link. Make sure the page actually answers that question, not only
  what the levels are.