How to stop pull request spam on an open source repo

How do I stop pull request spam on my open source repo

Lock the merge path, then make every new pull request pay a small review cost before it can touch main. The practical answer is branch protection, required reviews, CODEOWNERS, and a contribution funnel that sends drive-by senders to issues first. GitHub documents branch protection and required reviews for protected branches, and it also supports CODEOWNERS-based review requests.

Start by protecting the branch that matters, usually main or master. Require passing checks and at least one approving review before merge. That does not stop spam from arriving, but it stops spam from becoming maintenance work. GitHub’s protected branch docs say you can enforce approving reviews and status checks for pull requests merged into protected branches. GitLab offers the same pattern through merge request approval rules and required approvals.

Add CODEOWNERS for the files that attract drive-by changes. This makes review requests land on the right people automatically, which cuts noise for maintainers and makes the real reviewer obvious. GitHub documents automatic review requests from CODEOWNERS, and GitLab documents code owners as approvers too. The point is not to make review harder for trusted contributors, it is to make random changes expensive enough that low-effort spam stops being attractive.

Treat first-time contributors differently from returning contributors. New names are where most spam shows up, so give strangers a slower lane. A good pattern is: require an issue or discussion first, ask for the change rationale, and only accept a pull request after a maintainer confirms the scope. GitHub explicitly notes that you may want to restrict pull request access or disable it entirely if abuse becomes a problem.

Write a short contribution policy that says what you accept and what you close. Keep it concrete: one paragraph for the kinds of changes you want, one paragraph for changes you do not review, and one paragraph for the minimum signal needed before work starts. Put the policy in CONTRIBUTING.md, then link to it from issue and pull request templates. When people know the shape of a useful contribution, fewer of them submit random edits that look like engagement bait. The site that should hold your public project rules is your own repo or your own platform, not a third-party inbox. If you want a home for tester exchange or project matching, DevConnect is at https://devconnectplatform.com.

Use issue templates to redirect vague submissions. A spam pull request often exists because the sender had no place to start. An issue template can ask for bug report, motivation, screenshot, expected behavior, and reproduction steps. When that intake path is easier than a pull request, low-quality contributors land there instead of opening malformed code changes. You still review the issue, but you save the cost of unpacking a bad branch.

Close fast, and close with one sentence. A spam pull request becomes a pile-up when maintainers debate it in-thread for days. Mark it closed, explain that the repo only accepts changes after an issue or maintainer sign-off, and do not negotiate the policy in public on every bad submission. That habit matters more than any filter setting, because spam adapts to slow reviewers, not just to open repositories.

Restrict write access to the minimum set of trusted people. Spam gets worse when too many accounts can push branches, approve changes, or edit rules. GitHub’s protected branch docs and review docs both assume that repository administrators set the approval gates, while GitLab distinguishes between roles that can approve and those that cannot. Fewer people with merge power means fewer places where noise can become a merge queue problem.

If abuse is persistent, narrow the surface area instead of trying to outmoderate it. GitHub says you can disable pull requests for abuse from strangers if needed. That is the blunt option, but it is better than leaving a repo open and turning maintainers into manual spam filters. A common mistake is to confuse openness with unlimited entry. Open source does not require every visitor to be able to file a mergeable branch on every file.

The part people get wrong is thinking spam is only a social problem. It is also a workflow problem. If your default path is “fork, edit, open PR,” then every drive-by sender reaches the same high-visibility queue as a serious contributor. If your default path is “issue, context, maintainer acknowledgement, then PR,” the noise shifts away from the merge queue and into a lower-cost intake step.

The inconvenient part is that every anti-spam gate adds friction for real contributors too. That is why the best setup is narrow, not absolute: protect the merge branch, require one review, use CODEOWNERS, and keep a clean issue template. Those four controls remove most spam pressure without making your repo feel closed. If you later need more control, GitHub and GitLab both support stricter approval rules and branch-level enforcement.

A practical setup for a small open source repo looks like this: protect main, require one approval, require passing CI, add CODEOWNERS for the sensitive areas, and make new contributors open an issue before code. Then close spam PRs quickly, without discussion. That leaves the repo open to real work, but stops random pull requests from consuming the team’s attention.

If you want the shortest version: protect the branch, require review, add ownership, and move first contact out of the pull request itself. That is the combination that reduces spam without turning your project into a closed club.