Which maintainer improvements would help you most?

[moraesc]

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:

1. Scoped and hierarchical labels
2. Shared organization-wide labels
3. Restrict comments to collaborators only
4. Private comments in repositories
5. Unlisted repositories
6. More granular temporary interaction limits
7. Filter pull requests by contributor role
8. Configurable length limits for issue and PR descriptions

Your feedback will help us understand the problems behind these requests and where improvements could be most valuable.

[moraesc]

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.

[ntindle]

I like this a lot

[moraesc]

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.

[moraesc]

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.

[moraesc]

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.

[moraesc]

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.

[moraesc]

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.

[moraesc]

7. Filter pull requests by contributor role

Let maintainers filter the PR list by the contributor's relationship to the repository, such as First-time contributor, Contributor, or Member. This could help maintainers find contributions that need onboarding support or focus on a particular contributor group.

[moraesc]

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.

[antunesdv]

👍, especially the mutually exclusive groups.

Use case: we classify issues and PRs by priority and type. Today nothing stops an issue from having both priority: high and priority: low, or ending up with no priority at all, so filters and boards become unreliable unless someone manually cleans them up.

What would help:

• A label group (e.g. priority) marked as exclusive, so applying one value replaces the previous one, both in the UI and via the API.
• Filtering by the group itself, e.g. label:priority/* or "has no label in group priority", to find untriaged items.
• Works well together with idea 2: defining these groups once at the org level and reusing them across repos.