Adopt ghostty-style triage

[TeamDman]

ghostty-org/ghostty#3558

https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md

Goals:

• Clearly separate issues from feature requests

are labels insufficient for that? Kinda, the bit "206" issue count is conflating problems with not-quite-problems

---

Planning update: 2026-09-14

Concrete direction: public planning, documented bugs

Use GitHub as the durable planning surface for projects we own and administer. Capture summaries, feature ideas, design choices, and implementation plans in Discussions while the context is fresh. Use Issues for bugs with enough documentation to understand and reproduce the observed failure.

For SFM, this means:

• Issues: defects with expected/actual behavior, minimal SFML, exact Minecraft/loader/SFM versions, relevant mod versions, layout/labels/sides/slots, reproduction steps, and logs or other evidence where needed. Include regression references and distinguish confirmed reproduction from an unverified report.
• Ideas Discussions: feature proposals and their design/implementation checklists.
• General Discussions: maintained summaries and reference indexes.
• Q&A Discussions: usage questions. A dedicated Issue Triage category and form is a possible later addition for uncertain bug reports.

Ghostty is the reference for clarity and triage, but its current policy is broader: it admits actionable accepted feature work to Issues too. SFM's stated direction here keeps feature planning in Discussions and reserves new Issues for documented bugs. Ghostty contribution policy

How a summary stays useful

The top-level Discussion body is the maintained reference. Include a review date, source links, current behavior, accepted decisions, unresolved questions, and concrete next work. Edit that body when a reply resolves a question. Link to the summary from related work instead of scattering independent versions of it.

Current examples:

• Redstone support summary — aggregates existing requests and partial implementation evidence.
• Terraform for Minecraft design — module boundaries, world compilation, builder lifecycle, and resource transformations.

Use existing categories and labels initially. Pin a reference/index when it becomes a central navigation point; do not require a new category for every topic.

Label and template plan

GitHub shares one label namespace across Issues, PRs, and Discussions. Categories determine the kind of conversation; labels can mark topics and evidence status. GitHub documentation

Metadata	Proposed use
Existing language feature, mod compat, new block, new resource type	Reuse for relevant feature Discussions and implementation PRs.
Existing bug, needs reproduction, reproduced, could not reproduce, needs test	Apply according to the evidence; requesting a feature is not proof of a bug.
Candidate redstone	Cross-cutting topic label if the aggregated work warrants a dedicated filter.
Candidate summary	Mark maintained reference Discussions if category/title alone becomes insufficient.
enhancement	Retain for historical links and feature Discussions/PRs; audit any automation before changing its description or use.

[ ] 1. Define intake forms

Work: Design a bug form using the evidence fields above and an Ideas/summary form with problem, current behavior, proposal, scope, open decisions, and source links. Decide whether unconfirmed reports start in a new Issue Triage category or can enter Issues with needs reproduction.

Validation: Walk one real SFM bug report, one question, and one feature idea through the proposed intake. Do not add Ghostty's unrelated contributor-vouch policy.

Complete when: Each example reaches the intended destination and collects the evidence a maintainer needs.

[ ] 2. Audit and introduce metadata

Work: Inspect existing issue/discussion forms, labels, saved searches, bots, and workflows; then decide whether the candidate labels and triage category are useful. Repository configuration changes remain a follow-up to this plan.

Validation: Search both Issues and Discussions with each adopted topic label; verify templates refer to existing labels/categories and automation does not misroute them.

Complete when: Names and automation behavior are documented and independently verifiable.

[ ] 3. Review historical feature Issues individually

Work: Keep existing links and discussion history while deciding whether each old feature Issue stays as historical context or is individually converted. Mixed reports such as #170 need separate treatment for each request; #591 is a test task and does not itself prove a bug.

Validation: Check destination, references, attachments, and remaining bug content for each item. No bulk relabelling, closure, or conversion is part of this planning update.

Complete when: Each migrated item has an explicit disposition and working links. GitHub removed label-triggered bulk conversion in 2025, so do not build a workflow around it. GitHub change notice