Feature request: Role-based access control for Issues

[ufukty]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Issues

Body

Requested feature

Ability for repository owners to manage access 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).

Justifications

1. Discussions. Users are better served in the discussions section. This feature would help declutter the issues section of informal, poorly written (yet unavoidable) user reports by directing users to the discussions section and closing the issues section for writes¹. Opening issues officially would solve the limited cardinality problem between user reports and internally tracked issues². Also, the hierarchical-thread concept provides a better medium for omnidirectional discussions³. After the separation, we would invite users to share their feedback inside the discussions section. Then maintainers would open one issue per valid user point or combine points from one or more user reports into one internally tracked issue.

2. Noise. Since most of the noise currently comes from poorly categorized and irrelevant yet genuine and human-made contributions, this problem is a minor one. But I expect the frustration with low-quality contributions to only increase from this point on, as LLM inference gets cheaper.

3. Roadmap. Organizations that open their code should not be forced to open their roadmaps too. Many believe the roadmap is the product of customer discovery and where the real value lies. It should be possible to open source a project without revealing the roadmap.

Mainly, GitHub users need this feature to solve the same problem that this separate "community" repository solves for GitHub itself.

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 upvotes.

Edit history

• I'm posting this for the second time, this time selecting the "Product Feedback" type instead of "Question". The first post Feature request: Role-based Issues section access control #191479 got marked as dormant by the bot, claiming 60 days of inactivity.
• Added additional justifications.

Guidelines

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

Footnotes

1. Guidelines are hard to enforce beyond the core team. Maintainers understand their repository's issue guidelines better than their users do. The users have very critical information that would be a loss to discard yet are under no obligation to conform to the repository's style and cannot be forced to. Also, the users cannot be expected to have the motivation or drive to follow a project's instructions. Of course this doesn't make their feedback less important to collect and keep organized for later. ↩

2. The clutter of mixing user-posted and internally-tracked issues makes the work harder. One reason is that the issues opened by users and tracked by maintainers don't align on a 1:1 basis. The user posts often mix a bug report with a suggested alternative: two things with different paths forward. The bug report needs immediate reaction or comparison to other users' reports while the suggested feature would be one of many that needs to be discussed in the greater scope and justified. ↩

3. The hierarchical-thread concept mitigates context loss by allowing users to expand discussion in different directions without shadowing each other or annoying others with what many perceive as noise. ↩

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[gbakeman]

Thanks for remaking the post! I'd still like to see this feature as well. Discussions make sense as a way to triage user reports or requests that can later be converted in a formal issue.

[ufukty]

Thanks for your warning!

Indeed. Also the fact that GitHub has created a separate (community) repository for user discussions almost makes me think that they internally recognized the problem.

[gbakeman]

It may not be exactly the granularity you were hoping for, but...

https://github.blog/changelog/2026-06-29-restrict-issue-creation-to-collaborators-only/

[ufukty]

I have seen this and started to use it. It works fine for my case to the degree I can’t find enough motivation to pursue this one further.

I can close this topic solely based on my needs but not sure if I should keep it open for the other people who would like to see this implemented. There were many in both my previous discussion topic and the long-running issue that I’ve linked in the previous discussion topic.

Maybe they can re-open?

[gbakeman]

When I saw that blog headline scroll across my feed, I couldn't believe my eyes for a second! 😄 Your topic was the first one I thought of, and my search ended up leading me through the old dear-github topic and into the next one before this. I can see now reading your OP here that your idea is more granular than the binary option GitHub has introduced. IMO, I would leave this topic open (unanswered?) so that more people who want the same level of control can participate and GitHub can still register the request.

If I may make a suggestion, perhaps you may want to revise the OP to mention the update GitHub has posted, and also elaborate on how your idea goes beyond that and in a more granular way. I honestly had forgotten/didn't realize there were more roles in a repository besides owner/maintainer, contributor (thought was interchangeable with collaborator) and everyone else. Does GitHub describe the different roles?

Edit: Here's what I've found: personal account repositories have the least amount of roles, being owner and collaborator (where my original notion came from.) Organization repositories get more complex, then organizations themselves have the most complexity as far as roles go. Would any of this information be helpful to attach to the OP as well?

[ufukty]

Actually I was surprised when I saw too, and equally surprised that no GitHub employee has responded to this thread yet even just to mention blog posts you did. I haven't had the chance to read the linked documents thoroughly, but as far as I can tell you've already made the point clear in your response.

You may well be right that the current role selection already covers my entire request. The only distinction is the ability to set read and write access separately per role. Considering the current options, it might be too niche to prioritize. As for leaving the topic open, I think someone closer to the target profile would probably make the case better than I have.

Thanks again for your time, much appreciated.