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

Overview

We need devops and devops-security to match incubator's repository permissions, because incubator is the only one of our repos configured the way we want and the other two diverge in two ways: hackforla/devops grants access to four teams outside the CoP, and neither repo has the devops-merge team on its default branch's push allow-list. The devops-* teams should be the only teams on any of our repos, and they should mean the same thing on all of them.

Action Items

• Remove the four non-DevOps teams from hackforla/devops, so it carries only the five devops-* teams like the other three repos do. DELETE orgs/hackforla/teams/<slug>/repos/hackforla/devops for each:
  - product-managment — read, 416 members
  - product-managment-write — write, 319 members
  - guides — read, 46 members
  - guides-write — write, 7 members
• Add the devops-merge team to the default branch push allow-list on devops/master and devops-security/main, so all four repos read teams=["devops-merge"]. incubator and check-ghpages-versions already do.
• Confirm the starting state before changing anything, so this is done against fact rather than against this issue. Per repo, gh api repos/hackforla/<repo>/branches/<branch>/protection and read .restrictions:
  - devops (master) and devops-security (main) — restriction on, users=[] teams=[] apps=[]
  - incubator (main) and check-ghpages-versions (main) — restriction on, teams=["devops-merge"]
  An absent restrictions key means the toggle is off; an empty list means the toggle is on and nobody is allowed. Those are different states, the difference is visible only in the API, and getting them the wrong way round is easy.
• Change nothing else about branch protection. Correction, found 2026-09-07 while capturing state: they are not all identical. devops-security carries a bypass_pull_request_allowances naming chelseyklein individually, which devops and incubator do not; an earlier comparison flattened that object and missed it. It was deliberately left in place (Alex, 2026-09-07), and is redundant anyway since chelseyklein is in devops-admin and enforce_admins is false. The remaining settings are identical across the three main repos — one required approving review, dismiss stale reviews on, block_creations on, required_conversation_resolution on, no required status checks, no force pushes, no deletions, enforce_admins off. restrictions.teams is the only axis that was changed.
  Method note for anyone repeating this: it was done through the sub-resource endpoints (DELETE orgs/.../teams/<slug>/repos/... and POST repos/.../branches/<br>/protection/restrictions/teams), never PUT .../protection. A full PUT replaces the whole object and would have silently dropped devops-security's bypass allowance.
• Confirm enforce_admins is false on all four repos and leave it that way. This is deliberate and settled — repo admins are meant to bypass the push restriction and the required review. Nothing to change; the item exists so the state is checked rather than assumed.
• Carry the admin-bypass decision forward to where a reader of the permission model will meet it, rather than leaving it only on this issue — it reads as a weakness to anyone auditing branch protection, and without a record someone will eventually "fix" it. Done by making it a requirement on Replace the TBD stub on the Permission Levels for Team Members wiki page #196 rather than by writing the page here, which would have deadlocked the two issues against each other. Replace the TBD stub on the Permission Levels for Team Members wiki page #196's action items now require the page to state that the bypass is deliberate; the page itself is Replace the TBD stub on the Permission Levels for Team Members wiki page #196's deliverable, not this one's.
• None of this leaves a PR or a diff for anyone to review. Capture the current team list and the full protection JSON for every affected repo before touching anything, and attach them to this issue. Reversal: re-add a team with PUT orgs/hackforla/teams/<slug>/repos/hackforla/devops and {"permission":"pull"} or "push" as captured; remove an allow-list entry with DELETE repos/hackforla/<repo>/branches/<branch>/protection/restrictions/teams and body ["devops-merge"].
• Verify afterwards, with the negative assertions as the important half: gh api repos/hackforla/<repo>/teams returns exactly the five devops-* teams on all four repos; .restrictions names devops-merge and nothing else — no users, no apps; and the other fifteen protection axes are unchanged on the two repos you touched, diffed against the capture.

Resources/Instructions

• Verified live 2026-09-07; re-derive before acting. Neither team grants nor branch protection carry any change history in GitHub, so nothing here can be dated from the API afterwards.

• Current team grants — devops is the only outlier:

  Repo	Teams with access
  devops	the five devops-* plus product-managment, product-managment-write, guides, guides-write
  devops-security	the five devops-*
  incubator	the five devops-*
  check-ghpages-versions	the five devops-*

• The two read grants convey nothing and can go without further thought. All four repos are public, so product-managment (416 members) and guides (46) grant read access that every person on the internet already has.

• The two write grants are the real finding: 326 people hold push on hackforla/devops, where the CoP's own write team is 12. Branch protection stops them merging to master, but push is still push.

• These four teams are in scope only because they appear on our repository's access list, and the rule is that our repos carry the devops-* teams and nothing else. Removing a grant does not touch the team itself — each keeps existing and keeps its access to every other repo in the org. No coordination with Product or Guides is needed and none should be sought.

• Removing them is safe, checked three ways rather than assumed. In 37 pull requests ever opened on hackforla/devops, zero came from someone in product-managment-write or guides-write who is not also in devops-read. Of the five distinct assignees across all open issues, four are in devops-read and the fifth (VAntonina, on Document our "break-glass" account details #71) is in none of these four teams, so nobody loses an assignment. The guides-labelled issues are authored and assigned by DevOps people rather than by the Guides team.

• On the push allow-list, the change is a no-op in practice today, and that is what makes it safe rather than what makes it pointless. devops-merge is {RSkuma, ale210, chelseyklein} and devops-admin is {ExperimentsInHonesty, RSkuma, ale210, chelseyklein} — a strict superset — and since enforce_admins is false, admins already bypass the restriction. What changes is that the permission stops depending on that coincidence: today, adding someone to devops-merge who is not also an admin gives them no ability to merge on two of the four repos.

• This is the org's established pattern, not a new invention. hackforla/website restricts gh-pages to website-merge, with two required reviews.

• The incubator-* teams are not in scope and must not be touched. Despite the name they have nothing to do with hackforla/incubator — they grant on VRMS, HomeUniteUs and ballotnav, and 9 of their members are in no devops-* team, i.e. they are project people. Removing them would cut project contributors off from their own repositories.

• enforce_admins: false is intended and stays — decided 2026-09-07 (Alex). Repo admins are not subject to the push restriction or the required approving review, on all four repos. That is the desired configuration rather than drift. No rationale was recorded and none should be reconstructed. Do not re-raise it as a finding, and do not set it to true as part of this work.

• Blocks Replace the TBD stub on the Permission Levels for Team Members wiki page #196, which documents the permission model on the wiki. Doing this first means that page describes one rule for all four repos and one set of teams, instead of documenting inconsistencies and then needing an edit when they are fixed.