Feature request: Role-based Issues section access control

[ufukty]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Issues

Body

Requested feature

Ability for repository owners to manage accesses to a repository's Issues section based on the user role (eg. contributor, collaborator and member) and the access type (eg. read-only and read-write).

Need

1. This feature can enable sanitizing the Issues section from informal, poorly written (yet unavoidable) user reports by directing users into the Discussions section.
   • The Discussions section is better medium for community engagement than Issues as it supports avoiding context lost as it allows hierarchical threads.
   • It makes more sense to receive user feedback first in Discussions and officially opening one Issue per valid points as the users who have the crucial information are not obligated or forced to be bothered by following the style of repository and maintainers have better understanding of Issue policy of a repository than product users.
   • User post Issues clutter the Issues section and makes tracking relation between first party Issues harder.

Related

• Only allow issues to be created by contributors or people who have created pull requests dear-github/dear-github#293 is a similar feature request with 100 upvote.

Guidelines

• I have read the above statement and can confirm my post is relevant to the GitHub feature areas Issues and/or Projects.

[ufukty]

Maybe there is a misunderstanding. This already is the feature request you suggested me to send to the feedback URL. It redirects here. Other hand, thanks for the suggestions.

Best,

[Und3rTakerOPS]

This is a well-motivated request, and it highlights a real limitation in the current repository management model.

Restricting issue creation based on user roles (e.g., allowing only collaborators or trusted contributors to open issues) would help maintain a cleaner and more actionable issue tracker. In many repositories, maintainers already rely on Discussions as a first layer of triage, but enforcing this workflow is currently not possible.

That said, such a feature should be designed carefully to avoid discouraging legitimate bug reports from new users. A possible approach could be:

• Allowing maintainers to define rules (e.g., only users with prior contributions or approved discussions can open issues)
• Providing automated prompts that redirect users to Discussions before opening an issue
• Introducing moderation queues for first-time issue creators instead of hard blocking

This would strike a balance between keeping the issue tracker clean and preserving accessibility for new contributors.

[davex-ai]

hey @ufukty

You are essentially calling for Granular Issue Permissions, a feature that would treat the "Issues" tab more like a curated task tracker for maintainers and the "Discussions" tab as the community's front porch.
Currently, GitHub's permission model is relatively "all-or-nothing": if a user has read access to a public repo, they can open an issue. To achieve what you're describing, GitHub would need to decouple Repository Read Access from Issue Creation Access.

Why This Workflow Makes Sense

Your logic aligns with how many high-traffic projects (like Next.js or Tailwind CSS) attempt to operate, though they currently have to use "soft" enforcement:

• Noise Reduction: It prevents the "I have a question" or "It doesn't work" posts from burying actual, reproducible bug reports.
• Discussion as a Triage Layer: Moving informal chat to Discussions allows for threading, which is far better for troubleshooting than the linear, flat structure of an Issue.
• Maintaining "Signal": Issues become a high-signal backlog of work rather than a messy inbox of user support requests.

The Current "Workaround" (and its flaws)

Since the feature you're requesting doesn't exist natively, maintainers currently use:

1. Issue Templates: Using blank_issues_enabled: false to force users into a template, but users often ignore the prompts.
2. GitHub Actions: Some repos use bots to automatically close issues from non-contributors and post a comment saying "Please move this to Discussions." This is effective but feels "hostile" to new users.
3. Interaction Limits: You can limit interactions to "Prior Contributors," but this is a temporary 24-hour/1-week/6-month toggle, not a permanent permission setting.

The "Sudo" Issue vs. Granular Control

Building on our previous talk about npm’s security gaps, this is another example of "half-hearted" implementation. GitHub provides the Discussions tool but hasn't provided the access controls necessary to force the traffic into it.
If GitHub implemented a "Contributor-Only" write-access for Issues, it would solve the "prioritization problem" you mentioned earlier regarding spam; a bot couldn't just flood a repository with issues if it didn't have a specific role.
Should we outline a feature request specifically for "Role-Based Issue Creation" to submit to the GitHub Feedback repository?

pls upvote if this helps

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[gbakeman]

Any way we can get this turned into a genuine feature request to make the bot happy?

[ufukty]

I doubt the bot is triggered by the content. Although feel free to reply if you think the main post can be improved in any direction. I've initially intended to come back to add more examples where this feature is needed, but could not get the opportunity.

[gbakeman]

My understanding is that the bot is looking at the "🏷️ Discussion Type: Question 💬 Feature/Topic Area: Issues" part of the post (or some metadata not in the OP body). I guess since this in a Q&A structure too, it wants a definitive answer to close it. Any way you can convert this into a full feature request type or change some metadata on your post?

[ufukty]

Thanks, I've created #198113 now.

[v-coder247]

Hi @ufukty.

So we don't overwhelm the community with duplicate discussions, I have gone ahead to close and lock this discussion in place of the new version that you have created. Thanks for understanding!

The Community Discussions Team