Is your feature request related to a problem? Please describe.
A company has no way to group its projects, so with a large number of projects the Projects dashboard is a flat, unclassifiable list.
We run a GitHub Enterprise with two collaborating organizations — one for platform services, one for games — and 100+ repositories between them. Our test projects map to repositories, so the Projects dashboard needs to answer "show me the platform projects" or "show me the games projects". Today it cannot: every project in the company sits in one undifferentiated grid, and the only way to tell them apart is to encode the owner into each project's title and read it by eye. A naming convention is not a real answer at this scale — it is unenforceable, it makes titles long and repetitive, and it still leaves no way to filter.
The only structural workaround is to create a separate Company per organization, which is what we ended up doing, and it is a poor fit:
- company-level configuration has to be duplicated for each one (SSO, labels and fields, templates, report notifications, custom statuses)
- SSO is the sharp edge: a verified domain can only be claimed by one company, so a second company cannot auto-provision the same users and signups have to keep pointing at the original company
- licence seats, permissions and user management fragment across companies for people who legitimately work on both sides
- it models an organization as a tenant boundary, when in our case the two organizations are one tenant that collaborates
So the choice today is a flat unnavigable list, or a tenant split with real administrative cost.
Describe the solution you'd like
A grouping dimension for projects inside a company — an "organization", "group" or "category" that a project belongs to, mirroring how GitHub nests Enterprise → Organization → Repository.
Concretely:
- a company can define groups, and each project optionally belongs to one
- the Projects dashboard shows projects split by group, either with a divider per group or a selector/filter next to the existing company selector
- if a company has no groups, or only one, nothing changes — no divider, no filter, no extra control in the UI. The feature should be invisible until it is useful
- ideally the group is exposed on the project in the API (
GET /api/projects) so automation can resolve or report per group
This keeps one company as the tenant — one SSO configuration, one seat pool, one set of company settings and users — while giving navigation and reporting a boundary that matches how the work is actually organized.
Describe alternatives you've considered
- A naming convention in project titles (e.g.
platform - <service>, games - <service>). Works for a handful of projects, but with 100+ it is unenforceable, cannot be filtered, and duplicates the same prefix across every title.
- A separate Company per organization. Structurally correct but administratively expensive, for the reasons above — duplicated company configuration, and SSO in particular does not split cleanly because a domain can only be claimed once.
- Labels or tags on projects. Labels exist at test and suite level, not project level, so they cannot classify the dashboard.
- Living with the flat list. Viable only while the project count is small; it degrades exactly as adoption grows.
Additional context
The single-vs-multiple company decision is the one we keep returning to, and a project group would remove the need to make it. For anyone mapping projects to repositories — which is the natural layout once test reporting is wired into CI — the project count tracks the repository count, so the dashboard reaches this limit quickly.
Related: we also filed a request for a project-creation endpoint (#1663), which comes from the same direction — projects tracking repositories automatically. A group field on create would pair naturally with it.
Is your feature request related to a problem? Please describe.
A company has no way to group its projects, so with a large number of projects the Projects dashboard is a flat, unclassifiable list.
We run a GitHub Enterprise with two collaborating organizations — one for platform services, one for games — and 100+ repositories between them. Our test projects map to repositories, so the Projects dashboard needs to answer "show me the platform projects" or "show me the games projects". Today it cannot: every project in the company sits in one undifferentiated grid, and the only way to tell them apart is to encode the owner into each project's title and read it by eye. A naming convention is not a real answer at this scale — it is unenforceable, it makes titles long and repetitive, and it still leaves no way to filter.
The only structural workaround is to create a separate Company per organization, which is what we ended up doing, and it is a poor fit:
So the choice today is a flat unnavigable list, or a tenant split with real administrative cost.
Describe the solution you'd like
A grouping dimension for projects inside a company — an "organization", "group" or "category" that a project belongs to, mirroring how GitHub nests Enterprise → Organization → Repository.
Concretely:
GET /api/projects) so automation can resolve or report per groupThis keeps one company as the tenant — one SSO configuration, one seat pool, one set of company settings and users — while giving navigation and reporting a boundary that matches how the work is actually organized.
Describe alternatives you've considered
platform - <service>,games - <service>). Works for a handful of projects, but with 100+ it is unenforceable, cannot be filtered, and duplicates the same prefix across every title.Additional context
The single-vs-multiple company decision is the one we keep returning to, and a project group would remove the need to make it. For anyone mapping projects to repositories — which is the natural layout once test reporting is wired into CI — the project count tracks the repository count, so the dashboard reaches this limit quickly.
Related: we also filed a request for a project-creation endpoint (#1663), which comes from the same direction — projects tracking repositories automatically. A group field on create would pair naturally with it.