Maintainer Month Update: Tackling Contribution Noise and Giving Maintainers More Control

[moraesc]

As Maintainer Month draws to a close, we want to take one more moment to celebrate the open source community and the maintainers who keep it running. Your work is what makes GitHub matter. Thank you.

But celebration without action isn't enough. We've been listening, and this month we want to be transparent about a problem we've been focused on since the start of the year, what we've already shipped, and where we're headed next.

The Problem: AI Slop at Scale

Earlier this year, we opened a discussion about a trend that's been making maintainers' lives harder: a flood of low-quality contributions that existing tools and workflows weren't built to handle. If you haven't seen that thread yet, you can check it out here.

It’s become drastically easier to generate pull requests, issues, comments, and reports, but the work required to review them still depends on limited maintainer time and attention. As contribution volume rises, the pressure on maintainers rises with it. Generative AI has accelerated this shift, but the underlying challenge is broader than AI alone. Existing workflows were not designed for this level of volume, uncertainty, and repetition. Before maintainers can even evaluate the code itself, they often need to determine whether a contribution is relevant, whether it follows project guidelines, and whether the contributor is likely to stay engaged.

Tackling this problem has been our primary focus this year. We’ve had ongoing conversations with maintainers across the ecosystem to understand their pain points, workarounds they’ve tried, and controls they need, and we’re translating that directly into what we build.

What We've Already Shipped

Over the past several months, we've rolled out a set of targeted tools to help maintainers manage contribution noise:

• Disable PRs entirely on a repo - This gives maintainers a way to turn off PRs entirely if they want to share their code without accepting contributions.
• Restrict PRs to collaborators only - Rather than shutting the door entirely, this limits who can open PRs to trusted collaborators, blocking the flood of unknown external contributors while keeping the contribution pipeline open.
• Disable commit comments on 3 levels: the user level, the repo level, the org level – Commit comments have long been a source of noise, and that noise has increased alongside overall contribution volume. Users can now disable commit comments by default at the personal or organization level, or for a specific repository, giving maintainers more granular control over where discussion happens.
• Hide comments as low quality - Spam and low-quality comments are fundamentally different. This new option gives maintainers a way to explicitly mark low-quality comments, improving our ability to track these patterns today and helping lay the groundwork for better detection over time.
• Repo member role label in the PR list view - Having more context on a contributor has become especially important when triaging a long list of PRs. This label shows whether a PR author is a known repo member directly in the list view, giving maintainers a quick signal to help prioritize without clicking into every PR.
• Consistent notes field when blocking users - When blocking a user, maintainers now have a consistent place to record why. This keeps context from getting lost and makes decisions easier to audit.
• Sort notifications from oldest to newest - As contribution volume grows, maintainers need more control over how they work through an increasingly crowded inbox. This option makes it easier to process notifications in a deliberate order and work through a backlog on their own terms.

These are real tools maintainers can use today. But they're not enough on their own.

What's Coming Next: More Controls for Managing Contributions

Here's the full roadmap:

Archiving PRs (shipping soon)
We’re adding the ability for repository admins to archive PRs so maintainers can remove low-quality or spammy PRs. Archived PRs will only be visible to admins, and admins will be able to filter them out of the main list view.

We’re intentionally taking an archive-first approach rather than full deletion because some organizations cannot permanently delete PRs due to legal or compliance requirements, and many maintainers have told us they want to retain PRs for historical context.

PR Limits + Bypass list (shipping soon)
One of the simplest and highest-impact controls we can ship is a per-repository cap on the number of concurrent open PRs a user without write access can have.

Here’s how it works:

• Repository admins can set a maximum number of concurrent open PRs for users without write access directly from repository settings.
• If a user without write access has already reached that limit, they won’t be able to open another PR until one of their existing PRs is closed or merged.
• Maintainers can create a bypass list so trusted contributors can exceed the limit without needing full collaborator access.

This approach targets one of the clearest patterns behind contribution noise: a small number of users opening many PRs to the same repository in a short period of time. For most contributors, the experience remains unchanged. For maintainers, it creates a practical middle ground between fully open PRs and collaborators-only restrictions.

Issues Limits
The next phase brings similar controls to issues. This work includes two releases:

• Per-repository issue caps - Maintainers will be able to limit how many open issues a user without write access can have at a time. As with PR limits, trusted contributors can be added to a bypass list.
• Restrict issues to collaborators only - After shipping the ability to restrict PRs to collaborators only, we heard strong demand for the same control on issues. We’re now working on adding that capability.

Global Rate Limits
We’re also exploring a complementary global rate limit to address cross-repository spray. A per-repository cap can help with repeated activity in a single project, but it doesn’t help when someone opens PRs across hundreds of repositories. A global layer would help cover that gap.

Adding More Granularity to Interaction Limits
We want to give maintainers more control over how contributions are accepted in their repositories. The goal is to make these rules configurable, so maintainers can spend less time manually managing trust and have more control over how limits are applied.

For example, contributors could automatically bypass limits based on signals such as:

• A previously merged PR in the repository
• Account age
• Organization membership status

We’d love to hear from the community - What other signals would you want to use?

Building better incentives, not just better limits

We know this problem is not solved by restrictions alone. Maintainers need better controls, but they also need healthier contribution patterns and better ways to encourage the kinds of participation they actually want.

We’ve been discussing ways we could better recognize and reward valuable non-code contributions - things like issue triage, documentation, testing, reproduction steps, design feedback, and community support. These contributions are often just as important to a project’s health as writing code, but they are not always as visible in today’s contribution model.

As we think about longer-term improvements, we’d love to hear from the community: what kinds of contributions do you want GitHub to better recognize, reward, or encourage? And what product changes would help steer more contributors toward the work maintainers actually find most useful? Feel free to leave your thoughts below or in this discussion post we recently opened to have a dedicated space to talk through these ideas.

We’d love your feedback

These changes are just the beginning. We’re committed to building tools that make maintainers’ lives easier while keeping open source collaboration thriving, and there’s much more on the way.

We’d love to hear what you think about the whole direction we’ve laid out here and the roadmap we’re building toward. Let us know what resonates, what feels missing, and where you think we should go next.

Thank you again for the time, care, and judgment you bring to maintaining open source projects, and for continuing to share your feedback with us. We’re grateful for this community, and we’re committed to building alongside you.

[garagon]

Thanks!

[yoeltapia83-dot]

Necesitaría ayuda con un temita pero no puedo contactar con soporte

[ghostinhershell]

Hi @yoeltapia83-dot, thanks for participating!

Unfortunately, we don’t currently have moderators for languages other than English. Until that changes, we need to ask that everyone use English here in the GitHub Community when posting to ensure discussions are adhering to our Code of Conduct.

Please create a new discussion in English if you still need support, and include more details about the issue that you're running into here.

[RyanCavanaugh]

I keep seeing contributors, both internal and external, commenting and meaningfully engaging with bot-driven content. Folks that have worked with our project for years are spending 10, 20, 30 minutes writing explanations as to why a PR or issue report is wrong.

Per-repo caps on PRs or Issues do nothing to address this, because these bots are very deliberately spreading out their activity over the entire site.

I'm just genuinely upset at the enormous waste of human capital going on here because GitHub isn't even putting up a UI indicator for an account that is opening a dozen PRs in the span of 20 minutes, or log 45 issues in 43 projects in a single day.

We don't need complicated controls, allowlists, caps, or anything like that. Just put a "High Activity" label next to someone's name when they've opened more than ~30 PRs/Issues in the last week. This is enough clue for maintainers/responders to have a hint that it's a possible bot, and is harmless to well-known good actors.

[instantcodes]

Ok be next time will come

[ferdidwikristiawan22-art]

197319

[gamer191]

Would be great if PRs supported issue forms instead of markdown-based templates that can be easily deleted or filled out by an LLM

(One of the biggest advantages of issue forms is that users need to manually tick boxes and answer questions instead of copying the template into an LLM)

[zaman66vpn]

Ok

[charlieforward9]

Archiving PRs (shipping soon)

So this could be searched via status:archived?

If so, please fix the boolean operations of this status, to fix the handful of open problems around this filtering! Thank you.

• Incident: closed pull requests are not showed in list page #193388
• bug(boolean operators): `state:merged OR state:open` #200085

[projekta2]

The contributor role label is a genuinely useful signal. Having that context
before you open the PR is better than discovering it inside — especially when
you're looking at a queue of 30+ and trying to decide where to start.

One thing I've noticed working on my own repos: the triage bottleneck isn't
usually "which PRs are low quality" (that becomes obvious fast). It's more
"of the PRs that deserve attention, which one do I review first?"

The signals that have helped me most for that decision:

• CI status (a failing PR rarely becomes easy to merge later)
• Time since last author activity (dead PRs compound debt silently)
• File types touched (migrations and config changes deserve more caution than
  isolated component updates)
• PR size relative to what it claims to fix (a 400-line PR for a "minor bug"
  is a flag worth surfacing early)

None of these require AI — they're just deterministic. I ended up building a
small tool for myself that combines them into a single priority order, with an
optional AI summary layer on top for context. The deterministic part is what
I actually rely on daily; the AI part is useful when I need to explain why
a PR scored the way it did.

Curious whether GitHub is exploring anything in this direction — the member
role label is a step toward surfacing contributor signals pre-review, and it
seems like the natural next layer is surfacing PR-level signals the same way.

[moritajavier239-rgb]

Gracias