Fix CONTRIBUTING.md's "Getting write access" section - it contradicts the fork bot and the wiki
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- github-actions, markdown
- Domain
- devops, documentation
Research direction
Start at the “Getting write access” heading in CONTRIBUTING.md and compare it with the wiki’s “Joining the DevOps team” section and the comment text in .github/workflows/close-fork-prs.yml. Rewrite only the paragraph, preserving the permission-error explanation and existing links while linking to the canonical wiki guidance. Done means the rendered CONTRIBUTING.md section, wiki, and fork-bot text agree.
Written by the indexing model from the issue text.
Description
Overview
We need to rewrite CONTRIBUTING.md's "Getting write access" section, because it tells contributors that a rejected git push means asking a DevOps CoP Lead in #ops — which reads as a request you can make on its own — while both the fork bot and the wiki landing page say the opposite. A new contributor gets a different answer depending on which one they happen to read first.
Action Items
- Rewrite the paragraph under the Getting write access heading (line 65 when this was written; find it by the heading if the line has moved) so it agrees with the other two sources: write access is not something you request on its own, it comes with joining the Community of Practice — say hello in #ops, start coming to the weekly CoP meeting, and a lead adds you once you are taking part.
- Keep the useful half of the current text — that a
git pushrejected with a permission error is the symptom of missing write access. That is the question the reader arrives with and the section should still answer it. - Keep the existing links to the DevOps CoP Leads page and the #ops channel. Those are correct; it is the instruction around them that is wrong.
- Do not restate the whole joining process here. Link to the wiki landing page's "Joining the DevOps team" section, which is now the canonical statement, so there is one place to change when it next changes.
- After the PR merges, read the rendered section on
masteralongside the wiki landing page and the fork bot's comment text in.github/workflows/close-fork-prs.yml, and confirm all three now say the same thing. The point of the ticket is agreement between the three, so checking only the file you edited does not verify it.
Resources/Instructions
- The file and section: CONTRIBUTING.md → Getting write access
- The wording to match, from the fork bot's auto-close comment in
.github/workflows/close-fork-prs.yml: "Write access is not something you can request on its own, and asking a lead for it will not get you added. It comes with actually being part of the team..." - The wiki's version of the same statement, added while delivering #211: Home → Joining the DevOps team
- Scope is this repository only — checked 2026-09-07, so this does not need re-deriving.
devops-security/CONTRIBUTING.mdhas no "Getting write access" section at all, andincubator/CONTRIBUTING.mdis a three-line stub pointing at the incubator wiki. Neither carries the contradiction. Whether those two files ought to cover this at all is a separate question — do not widen this ticket into it.
- Dominant language
- PowerShell
- Stars
- 8
- Forks
- 10
- Avg merge
- 7h 30m
- Merged PRs (30d)
- 22
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hackforla/devops
-
complexity: small feature: maintenance role: DevOps Engineer size: 1pt
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
complexity: small feature: maintenance role: DevOps Engineer size: 1pt
Difficulty 3/5 1-2 days Newbie friendliness 58/100
-
complexity: medium feature: security role: DevOps Engineer size: 3pt
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Migrate the Terraform S3 backends off dynamodb_table onto use_lockfile and delete the lock tables Opencomplexity: medium feature: maintenance role: DevOps Engineer size: 2pt
Difficulty 5/5 Over a week Newbie friendliness 45/100
-
complexity: large epic feature: project terraform setup role: DevOps Engineer size: 13+pt
Difficulty 5/5 Over a week Newbie friendliness 30/100
All issues in hackforla/devops
Similar issues
-
kind/bug needs-triage
Difficulty 1/5 Under an hour Newbie friendliness 72/100
matrixorigin/matrixone#29223 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
copse-dev/agent-pane#2953 ·
-
bug ci-failure high priority
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
vllm-project/vllm-omni#7972 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
simonw/sqlite-utils#872 ·
-
bug good first issue
Difficulty 1/5 Under an hour Newbie friendliness 88/100
amponce/archive-movie-browser#166 ·