QEP-2: add `feature` to the software extension — the software counterpart of `new-lecture`

The gap

QEP-2's Type group has enhancement — "Improvement to existing content or functionality" — and the lecture extension sharpens the marquee case out of it: a brand-new lecture is new-lecture, used instead of enhancement, because a new lecture and a better exercise are different outcomes that reports should not sum together. The software extension has no equivalent. A brand-new capability in a tool — a new command, mode, integration or workflow — can only be enhancement, which its own description reserves for improving what already exists. Software repos are the one place where "we shipped something that did not exist" is the marquee outcome, and it is the one place the schema cannot say so.

The asymmetry is visible in practice. In action-translation, authors reach for the conventional-commit prefix instead: 7 issues are titled feat: / Feature: (#136, #70, #66, #58, #56, #55, …); only 3 of them carry enhancement, 3 are unlabelled, one is documentation. The title is doing the work the label should. The same happened on 2026-08-21 filing the first seven issues on QuantEcon/textstrata: four are new capabilities (a source-diff prose strategy, a PR-API collection channel, engine-version strata, scheduled runs) and three improve existing metrics — and the distinction is exactly what a release note or activity report wants.

Proposal

Add one label to the software extension, mirroring new-lecture:

Policy additions, in QEP-2's own register:

• One Type per issue gains the pair feature instead of enhancement, alongside new-lecture instead of enhancement and refactor instead of infrastructure.
• The feature / enhancement boundary is existence, not size — the same test the QEP already applies to new-lecture, and consistent with its own software example: adding --dry-run to a command that never offered one is an enhancement (the command exists; it got better), whereas adding a review subcommand to a tool that had none is a feature. A capability's surface — command, mode, integration — decides, not the line count.

Counts: software / tooling repos go from 20 to 21 (core 19 + refactor + feature), matching lecture repos' 21; the core 19 and the org default are unchanged. Colour: feature takes new-lecture's blue because they are the same semantic slot — "new content to publish", which the QEP reserves blue for — in two scopes that never share a repository; if the panel prefers the two to be distinguishable in org-wide queries, any unused blue works. Machine-readable appendix: one entry (group: software, scope: software), and a QEP-2 version bump per QEP-1 since this is a substantive amendment.

Alternatives considered

• Keep using enhancement for new capabilities. Rejected for the reason the QEP gives for new-lecture: reports that read enhancement as "improved what exists" would sink "shipped a new capability" into the same bucket. The feat: title convention shows the need is real; a label is the machine-readable form.
• Promote feature to the core. Rejected for the reason refactor was kept out of the core: on lecture repos it is dead weight (new-lecture already owns the slot). An extension label costs nothing where it does not apply.
• Rename enhancement to feature org-wide. Rejected: enhancement is GitHub-canonical and already migrated across the lecture estate; the need is an extra distinction on software repos, not a rename.

A related observation — the org default is still the legacy set

QEP-2 says the org-level default for new repositories is the core 19, "a manual settings change — there is no public API for org defaults." That change has not been made, or did not stick: QuantEcon/textstrata, created 2026-08-21, received blocked, bug, duplicate, editor, good first issue, help wanted, high priority, in-work, maintenance, question, ready, testing, wontfix — the pre-QEP set, including the retired status labels and high priority with a space. Every new repository starts non-conformant until someone runs qe gh labels sync. Worth fixing in the org settings (a separate, mechanical step) and noting in the QEP's adoption section that new repos need a sync until then.

Start by reading QEP-2 and its machine-readable appendix, then inspect how the software extension's labels and version are recorded. Add the feature label, the one-Type policy, and the version update described here; done means the QEP consistently documents the new label and the org-default observation is recorded or handled separately.