|
| 1 | +--- |
| 2 | +name: Tracking Issue |
| 3 | +about: A tracking issue for a feature or initiative in Vortex. |
| 4 | +title: "Tracking Issue: " |
| 5 | +labels: tracking-issue |
| 6 | +--- |
| 7 | + |
| 8 | +<!-- |
| 9 | +Thank you for opening a tracking issue. Tracking issues record a feature's |
| 10 | +progress from design to landing and connect related bugs, PRs, and design |
| 11 | +questions. They should stay readable a year from now. |
| 12 | +
|
| 13 | +Route discussion elsewhere: |
| 14 | +
|
| 15 | +- Bug reports surfaced while implementing: file a bug issue and reference this |
| 16 | + tracking issue. |
| 17 | +- A design thread big enough to need its own page: spawn a tracking issue (as |
| 18 | + a sub-issue of this one if it is narrow) and discuss it there. |
| 19 | +
|
| 20 | +Short clarifying comments are fine. Long threads should be redirected. |
| 21 | +--> |
| 22 | + |
| 23 | +This is a tracking issue for ... |
| 24 | + |
| 25 | +<!-- |
| 26 | +State what the feature is and where it lives in the codebase (crate, module, |
| 27 | +file format, encoding). Link the parent Epic, design doc, prototype PR, or |
| 28 | +external reference if any. |
| 29 | +--> |
| 30 | + |
| 31 | +## Motivation |
| 32 | + |
| 33 | +<!-- |
| 34 | +Optional. Skip if this is a sub-issue of an Epic that already covers the why. |
| 35 | +
|
| 36 | +For standalone tracking issues, cover: |
| 37 | +
|
| 38 | +- The concrete problem and who hits it. Examples: a downstream integration |
| 39 | + (DataFusion, DuckDB, Python, Java), a benchmark gap (TPC-H, ClickBench, |
| 40 | + vortex-bench), a regression against Parquet or Arrow, or a file format or |
| 41 | + encoding limitation. |
| 42 | +- What is currently blocked, slower, or larger than it should be. Link the |
| 43 | + benchmark numbers, profile output, or related issues. |
| 44 | +--> |
| 45 | + |
| 46 | +## Design |
| 47 | + |
| 48 | +<!-- |
| 49 | +Optional but recommended. Size to fit the work: |
| 50 | +
|
| 51 | +- API additions: a stripped-down signature block. Rust traits or functions, |
| 52 | + file-format struct, or wire-format message. Drop doc comments and bodies. |
| 53 | +- Behavioral changes: a short before / after description, ideally with a small |
| 54 | + example. |
| 55 | +- Architectural changes: a paragraph explaining the new shape, or a link to a |
| 56 | + design doc. |
| 57 | +
|
| 58 | +Skip only if the change is fully obvious from the title. The Design section is |
| 59 | +what lets a reviewer judge whether the Steps below are the right ones. |
| 60 | +--> |
| 61 | + |
| 62 | +## Steps |
| 63 | + |
| 64 | +<!-- |
| 65 | +Major checkpoints required to call this feature done. A handful of milestones, |
| 66 | +not every PR. Tick steps as they land; do not delete them. |
| 67 | +
|
| 68 | +Steps are milestones, not PRs (initial implementation, documentation, |
| 69 | +stabilization). If a step is itself a separable shippable unit, promote it to |
| 70 | +a sub-issue. |
| 71 | +--> |
| 72 | + |
| 73 | +- [ ] Initial implementation |
| 74 | +- [ ] Documentation |
| 75 | +- [ ] Public API stabilization |
| 76 | + |
| 77 | +## Unresolved questions |
| 78 | + |
| 79 | +<!-- |
| 80 | +Open design or implementation questions blocking progress. Link discussions |
| 81 | +and conclusions so a future reader can see how each question was settled. |
| 82 | +
|
| 83 | +If a question is large enough to need its own thread, spawn a tracking issue |
| 84 | +or Discussion and link it. |
| 85 | +--> |
| 86 | + |
| 87 | +- [ ] None yet. |
| 88 | + |
| 89 | +## Implementation history |
| 90 | + |
| 91 | +<!-- |
| 92 | +A running log of every PR that touched this feature: initial implementation, |
| 93 | +follow-ups, fixes, reverts. Grows continuously and is never ticked off. The |
| 94 | +archaeology trail for someone reading this issue a year later. |
| 95 | +
|
| 96 | +Add PRs as they merge, in chronological order. A one-line description per PR |
| 97 | +is helpful but not required. |
| 98 | +--> |
0 commit comments