Repository navigation
QEP-2: replace the priority labels with the Priority issue field? #42
Description
Per QEP-1, an optional discussion issue preceding an amendment. The question: should QEP-2's high-priority and low-priority labels be replaced by GitHub's organisation-level Priority issue field? Raised 2026-09-30 while the QEP-6/7 redesign (QuantEcon/project-qep7#1) proposes putting a project's priority in that field. The design stops at planned work and keeps the labels for everything else; this issue asks whether the labels should go entirely.
Where priority lives today
| Level | Carrier | Live count (2026-09-30) |
|---|---|---|
| Project tracker | priority: in the status-projects registry, hand-edited |
15 now · 19 next · 5 later · 18 unset |
| Work item in a plan | List position under QEP-6, and sometimes a label as well | 19 of 42 open high-priority and 10 of 78 low-priority issues have a parent |
| Unplanned issue | high-priority / low-priority, "label only the outliers" |
91 labelled issues across 25 repositories |
The org's Priority field exists with Urgent / High / Medium / Low, is organization_members_only, and holds no values outside the sandbox (verified in the 2026-09-28 review, design/design-spec.md § 4.0 in QuantEcon/project-qep7).
The redesign's recommendation P5 (design/recommendations.md § 8.1) redefines the field as Now / Next / Later on Project trackers, replacing the registry key, and narrows the labels to issues in no plan. That leaves two carriers for one concept, split by whether an issue has a parent.
The case for the field
Single-valued and structured. A label set can carry high-priority and low-priority on one issue with nothing to stop it; a single-select field holds one value. The field is read over REST and every change leaves a timeline event with actor and time, which labels also do, but a field's value is the fact itself rather than a string a manifest keeps in step across repositories (the drift #28 measured).
One mechanism to learn. A contributor who has met the field on a tracker meets the same control on a triage issue. Two carriers means two rules and a lint to police the boundary between them.
The lockstep shrinks. Two labels leave the QEP-2 yml and the qe manifest, and every repository's label set, and nothing has to be kept in step.
The case against
One field, one option set. An org field has one list of options everywhere it appears. Trackers want Now / Next / Later, a focus vocabulary. Triage wants a heat scale, High / Low with unlabelled as normal. Serving both from one field means either one vocabulary for both, which reads oddly on one of them, or a second field, which is affordable (25 per organisation) but is a second carrier again, only by another name.
Labels are visible and searchable everywhere, today. label:high-priority across the organisation returns the 42 urgent items in one query, for anyone, and the colour shows in every issue list. Whether a field value can be filtered in the issues list or in org-wide search, and whether it renders in lists, is unverified. A field's visibility is also a setting: members-only hides it from outside collaborators and anonymous readers, where a label never does.
Who may set it. Labels need triage permission. Whether a field needs the same, or more, is unverified. If it needs write access, drive-by triage by outside collaborators gets harder.
Migration. 120 open labelled issues convert, and the labels are deleted from 25 repositories through the manifest. Closed issues keep their labels as history either way.
Options
| Trackers | Planned work items | Unplanned issues | Labels | |
|---|---|---|---|---|
| A. The design's P5 | Priority field, Now / Next / Later |
List position | high-priority / low-priority |
Kept, narrowed to issues in no plan |
| B. One field, one vocabulary | Priority field |
List position | The same field, same options | Retired |
| C. Two fields | Priority, Now / Next / Later |
List position | A second field, for example Urgency: High / Low |
Retired |
| D. Status quo | Registry key | List position, plus labels | Labels | Kept |
What a decision needs to settle
- Whether a field value can be filtered in a repository's issue list and in org-wide search, and whether it renders in lists the way a label chip does. Testable in QuantEcon/test-project-qep7.
- What permission sets a field value, compared with the triage permission a label needs. Testable there with a collaborator account.
- Whether one vocabulary can serve trackers and triage (option B), or whether the heat scale needs its own field (option C).
- If the labels go: the QEP-2 v2 change to the label set and the yml, which the redesign currently says is unchanged, and the manifest lockstep in the
qeskill.
Sequencing
The redesign routes QEP-2's v2 amendment through the QEP-6/7 acceptance PR (design/recommendations.md § 9, stage 2). If this settles before that PR, its priority row carries the outcome. If not, the row lands as option A and the labels question becomes a later QEP-2 v3.
Assisted-by: Claude Code (Claude Fable 5.1)
Activity