Investigate a "what is this release waiting on" view, by milestone or channel #797

New issue

Open

opened 2026-10-17 19:47:18 +00:00 by hexajon · 0 comments

hexajon commented

2026-10-17 19:47:18 +00:00

Owner

What happens now

madtea already computes a dependency graph over issues. madt_issues action=rank reports keystones, the ready work-front, and what each blocked issue waits on. Milestones exist too, but only as a flat bucket.

What is missing is the question I ask most on a large backlog: "what is this release waiting on?" At a few dozen issues I can read the whole rank output and trace it by eye. At thousands I cannot. I want to point at a planned release, or at a channel such as dev, stable, or latest, and get back only that set: what is ready to start now, what is blocked and by exactly what, and the one item that unblocks the most.

Today I hand-filter a milestone, then cross-read the rank graph to see which members are blocked and by what. The data is all there. The view is not.

What I want out of this

A read, computed from the dependencies that already exist. No new ritual. The structure has to come from work I already do, wiring a dependency or tagging a milestone, never from a checklist I keep green by hand. If using it well needs ceremony, it is the wrong design.

Rough shape, to argue about:

rank gains a scope: rank the members of one milestone, or one channel, and report ready / blocked-by / keystone / critical-path for just that set.
A channel (dev, stable, latest) names a release line. "What is latest waiting on" and "what is the next stable waiting on" are the daily questions.

Open questions

What defines a release set here: a milestone? And is a channel (dev / stable / latest) the same thing as a milestone, or a different concept that maps to tags and branches? A release is already a git tag, and madt_status already counts "N commits since the last tag", so "latest" may just be the unreleased range, not a milestone.
New surface, or a scope on the existing rank (milestone= / channel=)? I lean a scope on rank, because the engine already exists. That is a lean, not a decision.
At thousands of issues, what is the useful output: the blocking frontier (what is ready, plus the nearest blockers), not the whole transitive tree? A wall of 200 lines is the problem, not the answer.
How does the tool make this the normal pattern without forcing anything? I lean nudge, never gate: surface the view, and reward a wired dependency with a better answer, rather than refuse work that has no milestone. The "force" is that the low-effort path is also the one that lights up the view. Whether that is enough is the real question.
Does this sit on the model I already use, epics plus native dependencies for the graph and a milestone as a flat release tag, or does it need its own structure? I think it reuses it, but that needs checking against the channel idea.

Not in scope

Any required process: a mandatory milestone on every issue, a required label, branch protection, or a status ritual. This is a read that rewards good structure, not a gate that punishes its absence.
Changing how milestones or dependencies are stored.

## What happens now madtea already computes a dependency graph over issues. `madt_issues action=rank` reports keystones, the ready work-front, and what each blocked issue waits on. Milestones exist too, but only as a flat bucket. What is missing is the question I ask most on a large backlog: "what is this release waiting on?" At a few dozen issues I can read the whole `rank` output and trace it by eye. At thousands I cannot. I want to point at a planned release, or at a channel such as dev, stable, or latest, and get back only that set: what is ready to start now, what is blocked and by exactly what, and the one item that unblocks the most. Today I hand-filter a milestone, then cross-read the `rank` graph to see which members are blocked and by what. The data is all there. The view is not. ## What I want out of this A read, computed from the dependencies that already exist. No new ritual. The structure has to come from work I already do, wiring a dependency or tagging a milestone, never from a checklist I keep green by hand. If using it well needs ceremony, it is the wrong design. Rough shape, to argue about: - `rank` gains a scope: rank the members of one milestone, or one channel, and report ready / blocked-by / keystone / critical-path for just that set. - A channel (dev, stable, latest) names a release line. "What is latest waiting on" and "what is the next stable waiting on" are the daily questions. ## Open questions 1. What defines a release set here: a milestone? And is a channel (dev / stable / latest) the same thing as a milestone, or a different concept that maps to tags and branches? A release is already a git tag, and `madt_status` already counts "N commits since the last tag", so "latest" may just be the unreleased range, not a milestone. 2. New surface, or a scope on the existing `rank` (`milestone=` / `channel=`)? I lean a scope on `rank`, because the engine already exists. That is a lean, not a decision. 3. At thousands of issues, what is the useful output: the blocking frontier (what is ready, plus the nearest blockers), not the whole transitive tree? A wall of 200 lines is the problem, not the answer. 4. How does the tool make this the normal pattern without forcing anything? I lean nudge, never gate: surface the view, and reward a wired dependency with a better answer, rather than refuse work that has no milestone. The "force" is that the low-effort path is also the one that lights up the view. Whether that is enough is the real question. 5. Does this sit on the model I already use, epics plus native dependencies for the graph and a milestone as a flat release tag, or does it need its own structure? I think it reuses it, but that needs checking against the channel idea. ## Not in scope - Any required process: a mandatory milestone on every issue, a required label, branch protection, or a status ritual. This is a read that rewards good structure, not a gate that punishes its absence. - Changing how milestones or dependencies are stored.

hexajon added the

enhancement

label

2026-10-17 19:47:18 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#797

No description provided.

Rows
Columns