Fix CONTRIBUTING.md's "Getting write access" section - it contradicts the fork bot and the wiki

Open Beginner friendly
#221 0 comments 0 reactions 0 assignees View on GitHub

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

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

complexity: small feature: Onboarding good first issue role: DevOps Engineer size: 1pt
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 push rejected 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 master alongside 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.md has no "Getting write access" section at all, and incubator/CONTRIBUTING.md is 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from hackforla/devops

All issues in hackforla/devops

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.