Skip to content

docs: state what contributions the project accepts - #29

Merged
higagan merged 1 commit into
mainfrom
docs/contribution-policy
Jul 30, 2026
Merged

docs: state what contributions the project accepts#29
higagan merged 1 commit into
mainfrom
docs/contribution-policy

Conversation

@higagan

@higagan higagan commented Jul 30, 2026

Copy link
Copy Markdown
Owner

Why

Within 40 minutes of the tracker being populated, two automated PRs arrived (#27, #28) β€” both fork-to-PR in under four minutes, one from an account created three days earlier whose bio reads "AI-assisted contributor … Tips: buymeacoffee.com/…". Separately, #25 was claimed by an account that posted the same claim on five unrelated repos inside seven minutes.

Both PRs were closed. Neither was malicious, and #27's patch was reasonable work β€” but there was no written policy to point at, which made closing them feel arbitrary. Now there is one.

Root cause of the inflow: the good first issue labels feed public scrapers, which is how both PRs found a brand-new repo minutes after the issues were filed. Those labels have been removed from the tracker (separate action, no code change).

What this adds

A What This Project Accepts section at the top of CONTRIBUTING.md:

  • Discuss before you build; unsolicited PRs will usually be closed
  • Automated/AI-generated drive-by PRs are not accepted β€” with the explicit carve-out that using an assistant while you work is fine and expected
  • Claiming an issue means working on it; stale claims return to the pool, and saying you got stuck is fine
  • Changes to rules.py / engine.py / decorator.py need to state what they change about blocking behavior and prove bad input is still blocked

And three things contributors were previously left to discover on their own:

  • CI doesn't auto-run for first-time contributors β€” it needs maintainer approval. Absent checks are expected, not something they broke. (Both closed PRs sat at action_required.)
  • Security reports go to SECURITY.md, not the tracker
  • Bypasses of the default keyword filter are documented behavior, not vulnerabilities β€” links to the Limitations section, so the inevitable "I bypassed it with base64" reports have somewhere to land

Tone

Deliberately firm but not hostile, and it closes by saying the rules aren't meant to discourage genuine contributors. The goal is to have something fair to point at, not to look unwelcoming β€” #25 is still open and assigned to the contributor who asked for it.

Docs only. No code, no version bump.

Two automated pull requests arrived within 40 minutes of the tracker being
populated, both fork-to-PR in under four minutes, one from a self-described
"AI-assisted contributor" account created three days earlier. Separately, an
issue was claimed by an account that posted the same claim on five unrelated
repositories inside seven minutes.

None of it was malicious and one of the patches was reasonable work, but
reviewing generated drive-by changes to a security library costs more than the
changes are worth, and there was no written policy to point at when closing
them. Now there is.

Also documents three things contributors were left to discover:
  - CI needs maintainer approval for first-time contributors, so absent
    checks are expected rather than a problem with their PR
  - security reports belong in SECURITY.md, not the tracker
  - bypasses of the default keyword filter are documented behaviour, not
    vulnerabilities

The good-first-issue labels have been removed from the tracker as well; they
were being scraped, which is how both PRs found the repo minutes after the
issues were filed.
@higagan
higagan merged commit 4a70bf1 into main Jul 30, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant