Set an issue type on every template - #8
Merged
Merged
Conversation
Issue types make kind a first-class field instead of something inferred from which form was used and then re-encoded as a label at triage. The org now has five: Bug, Enhancement, Documentation, Chore, Decision. The mapping follows what each form already means. A syntax spec change asks for the language surface to move, so it is an Enhancement rather than a defect; a grammar sync re-aligns with a spec that already moved, so it changes no behaviour of its own and is a Chore. mux-context's two forms are both Decision - a cross-repo question and an ADR proposal are the same act at different stages of confidence. Labels keep the axes types cannot: area (stdlib, frontend, playground), state (blocked, needs testing), and disposition (duplicate, wontfix). What retires is the kind label applied at triage, which now duplicates the field.
This was referenced Aug 21, 2026
|
|
| Filename | Overview |
|---|---|
| templates/mux-context/ISSUE_TEMPLATE/adr_proposal.yml | Adds the Decision issue type to ADR and cross-repository design work as described by the PR. |
| templates/mux-context/ISSUE_TEMPLATE/cross_repo_question.yml | Adds the Decision issue type to cross-repository questions without changing existing form behavior. |
| templates/mux-syntax-highlighting/ISSUE_TEMPLATE/syntax_spec_change.yml | Classifies proposed canonical syntax changes as Enhancement. |
| templates/tree-sitter-mux/ISSUE_TEMPLATE/grammar_sync.yml | Classifies synchronization with the existing canonical syntax specification as Chore. |
| templates/mux-compiler/ISSUE_TEMPLATE/bug_report.yml | Adds the Bug issue type while retaining the existing triage label and assignee. |
| templates/mux-website/ISSUE_TEMPLATE/documentation_fix.yml | Adds the Documentation issue type while retaining the existing documentation and triage labels. |
Reviews (1): Last reviewed commit: "Set an issue type on every template" | Re-trigger Greptile
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of muxlang/mux-context#19 ("add issue types back").
The org now has five issue types, created and backfilled onto all 15 open issues:
Every template now sets one, so kind is recorded at filing time rather than inferred from the form and re-encoded as a label during triage.
The two mappings worth questioning
mux-context's two forms are both Decision: a cross-repo question and an ADR proposal are the same act at different stages of confidence.
What happens to labels
Types take kind. Labels keep the axes a single-select type cannot express:
stdlib,frontend,playground,grammar,ffiblocked,needs testing,needs triageduplicate,invalid,wontfix,good first issueWhat retires is applying a kind label at triage, since it now duplicates the field.
enhancementanddocumentationare the two that overlap; they are left inlabels.ymlfor now rather than deleted out from under existing issues - worth a follow-up once the types have been in use for a bit.