You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
31 lines
1.4 KiB
Markdown
31 lines
1.4 KiB
Markdown
+++
|
|
title = "Investigate: filtering tickets by project / stream of work"
|
|
priority = 3
|
|
status = "backlog"
|
|
ticket_type = "task"
|
|
dependencies = []
|
|
+++
|
|
## Problem
|
|
|
|
When multiple streams of work coexist (e.g., refactoring vs. new feature), there is no way to select tickets for one stream only. `nbd next` and `nbd list` operate across all tickets.
|
|
|
|
## Questions to answer
|
|
|
|
1. Does the existing `project`-type ticket + `deps` mechanism serve this need? Could a project ticket act as a grouping node, and filtering by `--filter type=project` or by the project ticket's subtree (`nbd graph <project-id> --json`) provide what is needed?
|
|
|
|
2. Are there cases where a ticket belongs to multiple projects? If so, a single-parent `deps` tree cannot represent the relationship.
|
|
|
|
3. Is a dedicated `project` or `label` field (multi-valued) preferable? What are the trade-offs?
|
|
|
|
4. How does this interact with `nbd ready` and `nbd next`? Would a `--project <id>` flag on these commands be sufficient?
|
|
|
|
## Approach
|
|
|
|
Investigate by:
|
|
1. Manually modelling two parallel workstreams using `project`-type tickets and `deps`.
|
|
2. Evaluating whether `nbd graph <project-id> --json` provides enough to extract a project-scoped ticket list.
|
|
3. Writing up findings and creating actionable implementation tickets.
|
|
|
|
## Expected output
|
|
|
|
Create one or more follow-up tickets with a concrete implementation plan, or close this ticket with a rationale if the existing tools are sufficient. |