GitHub labels

A reference for every label in the repo. The first group has direct automation behind it — applying or removing the label triggers a workflow. The rest are for human triage.

Automation labels

These labels are load-bearing — applying or removing them causes a GitHub Actions workflow to run.

Label	Colour	Effect	Workflow
`deploy-preview`	Blue (`#1D76DB`)	Apply: provisions a DigitalOcean app for the PR branch, pointed at the shared `IBA-DEV` database. Remove: tears the app down.	`pr-preview-create.yml` + cleanup
`deploy-preview-with-db`	Orange (`#D93F0B`)	Apply: same DO app plus an isolated database cloned from the latest production S3 backup, with firewall rules and DB lifecycle handled by the workflow. Remove: tears down the app and drops the isolated DB.	`pr-preview-create.yml` + cleanup

You can have at most one of those two active at a time per PR — applying one while the other is set tears down the previous preview first.

See Deploy previews for the user-facing walkthrough, including cost considerations.

Triage labels

Used by the team for prioritisation in GitHub’s project board and issue triage. No automation reacts to these.

Label	Meaning
`Urgent`	Drop everything — production incident or hard external deadline.
`High`	Top of the next-up queue.
`Medium`	Default for non-trivial work that isn’t urgent.
`Low`	Nice-to-have / cleanup / not blocking anything.

Classification labels

Describe what kind of work the PR/issue represents. Useful for git log archaeology later.

Label	Colour	Meaning
`bug`	Red	Something isn’t working as designed.
`enhancement`	Light blue	New feature or capability.
`documentation`	Blue	Docs-only change (anything under `docs/`).
`dependencies`	Blue	Dependency update — typically from Dependabot.
`javascript`	Green	Touches JS/TS code (usually auto-applied).
`question`	Pink	Issue is a question, not a defect.
`help wanted`	Green	Maintainer is looking for outside help on this.
`good first issue`	Purple	Suitable for someone new to the codebase.
`duplicate`	Light gray	Already tracked elsewhere — link in the issue.
`invalid`	Yellow	Not actually a bug / not actionable as filed.
`wontfix`	White	Deliberate decision not to address.

Internal-process labels

Coordinating internal work that isn’t quite a feature or a bug.

Label	Meaning
`internal`	Internal-only concern — refactors, tooling, infra changes.
`time-report`	Related to time-tracking / reporting features.
`user-report`	Reproduces something a user reported.
`projects`	Touches the projects subsystem.
`setup`	Onboarding / new-environment setup work.
`error`	Tracks a specific error condition in production.

Adding a new label

Two things to keep in mind:

If the label is just for human triage, just create it via the GitHub UI (Issues → Labels). Document it here in the same PR.
If the label drives automation, you also need to wire the workflow trigger — deploy-preview is the model: pr-preview-create.yml lists it under if: contains(...labels...), and pr-preview-cleanup.yml reacts to its removal under on: pull_request: types: [unlabeled].

Don’t reuse colours between automation and triage labels — the colour is a visual hint that the label does something.