Say on the wiki that contributors do not fork

[ale210]

Overview

We need the DevOps wiki to tell a new contributor, before they start work, that they branch inside the Hack for LA repository rather than working from a fork. Today neither wiki mentions forking at all, a fork PR cannot produce a Terraform plan, and a bot now closes fork PRs automatically — so someone who guesses wrong has their work closed by automation with nothing on the wiki having warned them.

Action Items

• Settle what the rule actually is before writing the page, because the two readings produce different text. Either forking is disallowed as policy, in which case the page states it as a rule and gives the reason; or forking does not work, in which case the page explains the failure and the reader can infer the rest. Ask a CoP lead rather than choosing. The rest of this ticket assumes whichever answer comes back.
• Add the statement to the DevOps wiki so a new person meets it before they clone anything. The natural home is the "Joining the DevOps team" section of the wiki landing page, which is currently one link and is the only signposted path into the team.
• Say that repository write access is a prerequisite, and link to Permission Levels for Team Members for how to get it rather than describing the access levels here. That page is being filled in separately by Replace the TBD stub on the Permission Levels for Team Members wiki page #196 — link to it, do not duplicate it.
• Say that fork pull requests are closed automatically, and that this is expected behaviour rather than a rejection of the work. The close-fork-prs.yml workflow runs in all three repos and closes fork PRs on open and reopen.
• Explain briefly why, because "because we said so" invites people to try anyway: a pull request from a fork gets no repository secrets and no OIDC token, so the Terraform plan cannot run, and the plan comment is the entire review artifact. A reviewer would have nothing to look at.
• Link to devops/CONTRIBUTING.md, which already carries the long-form version, rather than repeating the git instructions on the wiki.
• After pushing, load the rendered wiki page in a browser and follow the path a new member takes — landing page, then "Joining the DevOps team" — and confirm the statement appears before any instruction that would have them clone or fork. The wiki has no PR flow, so this post-push check on the live page is the only verification available.

Resources/Instructions

• The wiki is a separate git repository (hackforla/devops.wiki.git), cloned alongside the code repo. There is no PR and no review — pushes go straight to the live page. git pull immediately before you start and again immediately before you push; other people edit these pages through the web UI and a concurrent edit will reject your push.
• Landing page: Home, the "Joining the DevOps team" section.
• Verified 2026-09-04: none of the 19 pages in devops.wiki mentions forking, and neither does incubator.wiki. This is a gap, not a correction.
• Background on the mechanism: GitHub withholds repository secrets and the OIDC token from a pull_request run originating in a fork, and downgrades GITHUB_TOKEN to read-only. devops-security needs AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY for its plan; incubator needs OIDC plus TF_VAR_PGPASSWORD/TF_VAR_PGHOST. Neither is available to a fork.
• CONTRIBUTING.md used to teach the opposite and was corrected in Remove the fork workflow from CONTRIBUTING.md #204 — it now opens with a "Do not fork" callout. This ticket is the wiki half of that same fix.
• The automation is close-fork-prs.yml, added to all three repos in Close pull requests opened from a fork #205, devops-security#177 and incubator#172.
• Scope note: this is about the contribution workflow. The permission levels themselves belong to Replace the TBD stub on the Permission Levels for Team Members wiki page #196 and the team-side onboarding checklist to Write the checklist of what the team does for a new member, and publish it on the wiki #194 — link across, do not absorb either.