|
| 1 | +--- |
| 2 | +name: Tracking Issue |
| 3 | +about: Implementation context for work likely to span multiple PRs. |
| 4 | +title: "Tracking Issue: " |
| 5 | +labels: tracking-issue |
| 6 | +--- |
| 7 | + |
| 8 | +<!-- |
| 9 | +Tracking issues are for work that needs shared implementation context and is |
| 10 | +likely to span multiple PRs. Use this template when the issue should track |
| 11 | +planning, implementation, stabilization, and follow-through. |
| 12 | +
|
| 13 | +Route discussion elsewhere: |
| 14 | +
|
| 15 | +- New ideas, fit questions, or early design feedback: start with a GitHub |
| 16 | + Discussion. |
| 17 | +- Bug reports surfaced while implementing: file a bug issue and reference this |
| 18 | + tracking issue. |
| 19 | +- A design thread big enough to need its own page: spawn a tracking issue (as |
| 20 | + a sub-issue of this one if it is narrow) and discuss it there. |
| 21 | +
|
| 22 | +Tracking issues should be understandable a year from creation. Short clarifying |
| 23 | +comments are fine. Long threads should be redirected. |
| 24 | +--> |
| 25 | + |
| 26 | +This is a tracking issue for ... |
| 27 | + |
| 28 | +<!-- |
| 29 | +One or two sentences. State what the feature is and where it lives in the |
| 30 | +codebase (crate, module, file format, encoding). Link the parent Epic, design |
| 31 | +doc, prototype PR, or external reference. |
| 32 | +--> |
| 33 | + |
| 34 | +## Design |
| 35 | + |
| 36 | +<!-- |
| 37 | +Optional but recommended. Size to fit the work: |
| 38 | +
|
| 39 | +- API additions: a stripped-down signature block. Rust traits or functions, |
| 40 | + file-format struct, or wire-format message. Drop doc comments and bodies. |
| 41 | +- Behavioral changes: a short before / after description, ideally with a small |
| 42 | + example. |
| 43 | +- Architectural changes: a paragraph explaining the new shape, or a link to a |
| 44 | + design doc. |
| 45 | +
|
| 46 | +Skip only if the change is fully obvious from the title. The Design section is |
| 47 | +what lets a reviewer judge whether the Steps below are the right ones. |
| 48 | +--> |
| 49 | + |
| 50 | +## Steps |
| 51 | + |
| 52 | +<!-- |
| 53 | +Major checkpoints required to call this feature done. A handful of milestones, |
| 54 | +not every PR. Tick steps as they land; do not delete them. |
| 55 | +
|
| 56 | +Steps are milestones, not PRs (initial implementation, documentation, |
| 57 | +stabilization). If a step is itself a separable shippable unit, promote it to |
| 58 | +a sub-issue. |
| 59 | +--> |
| 60 | + |
| 61 | +- [ ] Initial implementation |
| 62 | +- [ ] Documentation |
| 63 | +- [ ] Public API stabilization |
| 64 | + |
| 65 | +## Unresolved questions |
| 66 | + |
| 67 | +<!-- |
| 68 | +Open design or implementation questions blocking progress. Link discussions |
| 69 | +and conclusions so a future reader can see how each question was settled. |
| 70 | +
|
| 71 | +If a question is large enough to need its own thread, spawn a tracking issue |
| 72 | +or Discussion and link it. |
| 73 | +--> |
| 74 | + |
| 75 | +- [ ] None yet. |
| 76 | + |
| 77 | +## Implementation history |
| 78 | + |
| 79 | +<!-- |
| 80 | +A running log of every PR that touched this feature: initial implementation, |
| 81 | +follow-ups, fixes, reverts. Grows continuously and is never ticked off. The |
| 82 | +archaeology trail for someone reading this issue a year later. |
| 83 | +
|
| 84 | +Add PRs as they merge, in chronological order. A one-line description per PR |
| 85 | +is helpful but not required. |
| 86 | +--> |
0 commit comments