GitHub Community
Which maintainer improvements would help you most? #210360
Replies: 12 comments 13 replies
|
1. Scoped and hierarchical labels Organize labels into groups or parent–child relationships to make issues and PRs easier to classify and filter. Optionally make a group mutually exclusive so that applying one priority label replaces the previous one. |
|
I like this a lot |
|
I like this generally, but it can get out of hand quickly. I've worked with some GitLab projects that had such a complex label setup that it was hard to make sense of it. I think scoped labels are often used to represent some kind of key-value data and would be better as distinct fields as opposed to a collection of labels. For example, I'd prefer to set priority by selecting the value of the "priority" field (with admin-definable options) or the affected OSes by setting "OS" to one or more values from a list. |
|
🤔 is this different from 
You cannot currently (easily) filter by them, so maybe that is a better feature request instead? |
|
Another problem with fields is they're not available on PRs :/ |
|
2. Shared organization-wide labels Define and manage a shared set of labels at the organization level, keeping names, colors, and descriptions synchronized across selected existing and new repositories. Update a shared label once instead of maintaining it separately in every repository. |
|
3. Restrict comments to collaborators only Add a repository-level setting that restricts comments on all contributions to collaborators, remaining in effect indefinitely until a maintainer turns it off. This would control commenting separately from opening issues or PRs, without requiring individual thread locks or renewing temporary limits. |
|
4. Private comments in repositories Allow maintainers to leave private comments on issues, PRs, and discussions that only authorized repository collaborators can read, even when the contribution is public. This would provide a place for internal coordination without moving the discussion to another tool. |
|
My concern here is accidentally saying something in public that was meant for a private comment. The UI has to be really clear in order to keep this from being a footgun. |
|
Being able to transition a comment freely between public and private would also help with this. |
|
It will be very useful to us. |
|
FYI if someone has a strong need for this it's already possible with comments in private projects. |
|
5. Unlisted repositories Add an unlisted visibility option so a repository can be accessed through a direct link without appearing in GitHub search or public discovery surfaces. Anyone with the link could access and share it, so this would support low-discoverability sharing rather than protect confidential content. |
|
6. More granular temporary interaction limits Let maintainers choose which activities to restrict, for which audiences, and for how long—for example, temporarily pausing new PRs from non-collaborators while keeping issues and existing conversations open. Each activity could be controlled independently rather than applying a bundled restriction which the current temporary interaction limits require. |
|
The ability to temporarily ban a contributor for a given duration would also be useful for moderation purposes. |
|
@SableRaf this is on the roadmap! |
|
IMO this only becomes really helpful once there's a more granular distinction in the audience. Right now it's along the line of privileges on the repository, but most of the spam comes from people who are not members or collaborators, and are from a pool where, even for legitimate purposes, giving them such a status isn't appropriate. For example, if you impose a general or temporary PR limit on a repo and I want to, legitimately, contribute a PR, you should not be required to make me a member or external collaborator for this. It should be possible to be as specific as saying "PRs are turned off, but this repo-external user may open any / a number of PRs". Otherwise it's just a "stop the flood because we're overwhelmed" thing and not a general way forward to help navigate collaborative development with these new challenges. |
|
I've wanted what SableRaf asked for quite recently: someone's vacation auto-responder started leaving comments on our repos. A 1- or 2-week temporary ban was exactly what I reached for and didn't find in the context menu. |
|
7. Filter pull requests by contributor role Let maintainers filter the PR list by the contributor's relationship to the repository, such as |
|
8. Configurable length limits for issue and PR descriptions Let maintainers set maximum lengths for issue and PR descriptions to encourage concise, focused submissions. Maintainers have reported very lengthy, often AI-generated descriptions that add volume without useful context. A character counter and clear guidance before submission would help contributors stay within the limit and focus on the information maintainers need. |
|
Maybe separate total and per-field template length limits? eg. https://github.com/yt-dlp/yt-dlp/issues/new?template=1_broken_site.yml setting a length limit here might be less helpful if a full debug log is desired while it would be useful to have a 300 word limit on the description field, etc |
|
👍, especially the mutually exclusive groups. Use case: we classify issues and PRs by What would help:
|
|
@godotengine i'm not sure any of the listed ideas would solve a problem we have in day-to-day triage and dev. We are mainly bottlenecked by review capacity (aside from feature stability, like label changes sometimes taking days to apply), so we'd mainly be interested in features addressing that. |
|
With unwanted AI stuff coming in, we have a rule that says you should be assigned an issue before you raise a PR. I believe many others have the same rule. Would be nice to able to enforce that directly in the Moderation section. Should be able to separate between external people and internal (members). |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
We’re exploring ideas that have been requested by the community, and we’d love your feedback on which would make the biggest difference to your work as a maintainer.
Each idea has its own comment below. Upvote or add a 👍 reaction to the ideas you’d find useful, and reply directly to that comment to share your use case, how you handle the problem today, or anything we should consider. You can support as many ideas as you like and feedback about why something wouldn’t help is welcome too.
The ideas are:
Your feedback will help us understand the problems behind these requests and where improvements could be most valuable.
All reactions