Across 200 GitHub repos in one org, how do you keep issue triage consistent?

## The structural problem GitHub's issue primitives were designed for one repository. **Labels** are repository objects — two repos with a `bug` label have two unrelated labels that share a name and probably not a colour. **Milestones** are repository objects with no organisation-level counterpart. **Issue templates** are read from a repository's default branch. Nothing inherits by default. At two hundred repositories, that means two hundred independently drifting configurations unless something pushes against the drift. So the design question is not "which labels should we use" but "which of GitHub's few org-scoped mechanisms carry the weight, and what must be scripted". ## Lever one: the .github repository An organisation can own a repository literally named `.github`. Files placed there act as **defaults** for every repository in the organisation that does not define its own: `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md`, `SUPPORT.md`, and — the one that matters here — `.github/ISSUE_TEMPLATE/` including `config.yml`. This is genuine inheritance rather than a copy: change the bug form once and every repository without a local override serves the new one. It shapes **intake**, which is where consistency is cheapest to buy. A form that requires a version and a severity dropdown produces comparable issues across two hundred repositories without any triager doing extra work. Repositories with genuinely different needs override locally, and that override is visible as a file in their tree. Caveat worth stating: defaults apply only where the repository has no file of its own, and the picker still reads from each repository's default branch. ## Lever two: organisation-level Projects A Project owned by the organisation can contain issues and pull requests from **any** repository in it, and the fields you define — `Status`, `Priority`, `Team`, iteration, target date — live on the project item. That makes an org Project the only native cross-repository view GitHub offers, and the only place a question like "what is every P0 across the platform group" has an answer. Two patterns work at scale. A **triage project** with an auto-add rule per repository, filtered to `is:issue is:open label:needs-triage`, gives one queue for the rotation to work down. A **per-programme project** aggregates the work for an initiative regardless of which repositories it touches. Both compose with the repositories' own labels, since `Labels`, `Milestone` and `Repository` are built-in read-through fields on the item. The limit is honest: auto-add rules are configured per project per repository, so wiring two hundred of them is itself a scripting job, and project field values are invisible to anyone reading the plain issue list. ## Lever three: scripted normalisation For labels there is no inheritance, so the taxonomy has to be *applied*. The durable pattern is to store the canonical set as a file in one repository and reconcile it with a scheduled job that calls the labels API — `POST /repos/{owner}/{repo}/labels` to create, `PATCH` to fix colour and description drift. Deletions want a human in the loop, because deleting a label silently strips it from every issue that carried it. Reconcile only the **shared** subset: the labels triage and reporting depend on. Every repository will grow local labels, and that is fine — the mistake is trying to own all of them centrally, which produces a taxonomy so large nobody can hold it in their head and therefore nobody applies it correctly. ## Newer surfaces, stated carefully GitHub has been adding organisation-scoped issue metadata — notably organisation-level **issue types**, which define a shared set of types (such as bug, feature, task) usable across the organisation's repositories rather than per-repo labels. This area is actively evolving, so treat any specific capability as something to verify against current documentation rather than to assert in an interview. The durable point stands regardless: prefer whatever GitHub scopes to the organisation over anything you must replicate two hundred times. ## What actually decides success Mechanism is the smaller half. At this scale the constraints are social: - **Ownership of the queue.** A triage rotation with a named owner per area beats any label scheme. Without it, a perfectly normalised backlog still ages. - **A response contract, not a resolution contract.** Commit to triaging within a window, not to fixing. It is keepable, and it is what reporters actually want. - **Small taxonomy, ruthlessly pruned.** If a label has not been filtered on in a quarter, it is decoration. - **Measure the queue, not the labels.** Time-to-first-triage and untriaged age tell you whether the system works; label counts tell you nothing. A candidate who reaches for the `.github` repository, org Projects and a reconciliation script — and then says the hard part is owning the rotation — has done this before.