Milestones are effectively unused: propose a policy, or record that we deliberately have none #12

New Issue

claude · 2026-09-08T09:04:45Z

claude commented

2026-09-08 09:04:45 +00:00

Nothing applied. This is a proposal and the decision is yours — asked for as theory only on 2026-09-08.

Your standing instruction (2026-08-27) asks for "issues and PRs (both with tags and milestones as appropriate)". Tags are in use and consistent. Milestones are effectively not: one exists in five repos.

Where things actually stand

repo	open issues	milestones
cfbypass	1	0
weblib-archive	7	1
weblib-fs	5	0
weblib-viewer	0	0
weblib-ci	4	0

The one that exists — "omegascans scraper", 18 closed / 0 open, no due date, described as "#14 and its sub-issues" — is a feature grouping, not a sprint. Worth stating because it is the precedent you set, and it is a good one: it answers "what was this epic, and is it done" without pretending to a schedule.

The constraint that decides most of this

Gitea milestones are per-repo. They cannot span repos. This project's units of work mostly do:

weblib-archive#30 ← cfbypass#1, #33
weblib-archive#29 ← weblib-fs#17
weblib-archive#57 ← #30
weblib-fs#25 ← #33

So the thing most worth grouping — "the proxy migration", which is cfbypass work and archive work — is exactly the thing a milestone cannot express. Anything cross-repo would have to be the same title duplicated in each repo, kept in step by hand, with nothing enforcing it. That is a synchronisation problem with no mechanism, and it will drift the first time it is not convenient.

Meanwhile Type/Epic plus dependency edges already do the grouping, and they are cross-repo. So the honest baseline is that milestones are largely redundant here.

Three options

A — Mirror epics, within a repo. One milestone per Type/Epic, following the omegascans precedent. Cheap, matches what exists. Cost: near-total duplication of Type/Epic + dependencies, and it still cannot cross a repo, so the epics that matter most are the ones it serves worst. Adds a second place to keep in step.

B — One milestone per promotion into main. development → main is a real, discrete event here, and a milestone would record what shipped together. This is the only option that adds information nothing else holds — labels describe an issue's kind, dependencies describe order, and neither says "these landed as one promotion". Cost: a milestone per promotion per repo, closed on promotion; partially overlaps with git tags, which would do it more cheaply if you would rather tag.

C — Do not use milestones, and write that down. State in docs/WORKFLOW.md that grouping is Type/Epic + dependency edges, and that milestones are deliberately unused because they are per-repo while the work is not. Cost: diverges from the standing instruction — hence asking rather than deciding.

Which way I lean

C, with B if you want a shipping record.

The grouping problem is already solved by epics and dependency edges, and solved better, because those cross repos. Adding milestones to mirror them buys a second bookkeeping surface that can disagree with the first — and this week already produced one silent disagreement between two bookkeeping surfaces (weblib-ci#11, where Status/Blocked and the dependency graph diverged for cross-repo blockers and nothing noticed for four green runs). I would rather not add a third surface with the same failure mode and no reconciler.

If a shipping record is what you want, B is the honest version of it — but consider whether an annotated git tag on each promotion gets you the same thing without per-repo milestone hygiene.

Do not read this as "the instruction was wrong." It predates the branch model, development, the epic/dependency wiring and the split into five repos, all of which arrived later and took over the job milestones would have done. If you would still like them, say which option and I will apply it — including retrofitting closed issues if you want the history to be complete.

What I would need from you either way

Which option (or another).
If B: whether to backfill the promotions already made, or start from the next one.
If C: confirmation, so docs/WORKFLOW.md can record it as a decision with your name on it rather than as my omission.

**Nothing applied. This is a proposal and the decision is yours** — asked for as theory only on 2026-09-08. Your standing instruction (2026-08-27) asks for "issues and PRs (both with tags and milestones as appropriate)". Tags are in use and consistent. Milestones are effectively not: **one exists in five repos.** ## Where things actually stand | repo | open issues | milestones | |---|---|---| | cfbypass | 1 | 0 | | weblib-archive | 7 | 1 | | weblib-fs | 5 | 0 | | weblib-viewer | 0 | 0 | | weblib-ci | 4 | 0 | The one that exists — **"omegascans scraper"**, 18 closed / 0 open, **no due date**, described as "#14 and its sub-issues" — is a *feature grouping*, not a sprint. Worth stating because it is the precedent you set, and it is a good one: it answers "what was this epic, and is it done" without pretending to a schedule. ## The constraint that decides most of this **Gitea milestones are per-repo. They cannot span repos.** This project's units of work mostly do: - weblib-archive#30 ← cfbypass#1, #33 - weblib-archive#29 ← weblib-fs#17 - weblib-archive#57 ← #30 - weblib-fs#25 ← #33 So the thing most worth grouping — "the proxy migration", which is cfbypass work *and* archive work — is exactly the thing a milestone cannot express. Anything cross-repo would have to be the same title duplicated in each repo, kept in step by hand, with nothing enforcing it. That is a synchronisation problem with no mechanism, and it will drift the first time it is not convenient. Meanwhile `Type/Epic` plus dependency edges already do the grouping, and they *are* cross-repo. So the honest baseline is that milestones are largely redundant here. ## Three options **A — Mirror epics, within a repo.** One milestone per `Type/Epic`, following the omegascans precedent. Cheap, matches what exists. **Cost:** near-total duplication of `Type/Epic` + dependencies, and it still cannot cross a repo, so the epics that matter most are the ones it serves worst. Adds a second place to keep in step. **B — One milestone per promotion into `main`.** `development → main` is a real, discrete event here, and a milestone would record *what shipped together*. **This is the only option that adds information nothing else holds** — labels describe an issue's kind, dependencies describe order, and neither says "these landed as one promotion". **Cost:** a milestone per promotion per repo, closed on promotion; partially overlaps with git tags, which would do it more cheaply if you would rather tag. **C — Do not use milestones, and write that down.** State in `docs/WORKFLOW.md` that grouping is `Type/Epic` + dependency edges, and that milestones are deliberately unused because they are per-repo while the work is not. **Cost:** diverges from the standing instruction — hence asking rather than deciding. ## Which way I lean **C, with B if you want a shipping record.** The grouping problem is already solved by epics and dependency edges, and solved *better*, because those cross repos. Adding milestones to mirror them buys a second bookkeeping surface that can disagree with the first — and this week already produced one silent disagreement between two bookkeeping surfaces (weblib-ci#11, where `Status/Blocked` and the dependency graph diverged for cross-repo blockers and nothing noticed for four green runs). I would rather not add a third surface with the same failure mode and no reconciler. If a shipping record is what you want, B is the honest version of it — but consider whether an annotated git tag on each promotion gets you the same thing without per-repo milestone hygiene. **Do not read this as "the instruction was wrong."** It predates the branch model, `development`, the epic/dependency wiring and the split into five repos, all of which arrived later and took over the job milestones would have done. If you would still like them, say which option and I will apply it — including retrofitting closed issues if you want the history to be complete. ## What I would need from you either way 1. Which option (or another). 2. If B: whether to backfill the promotions already made, or start from the next one. 3. If C: confirmation, so `docs/WORKFLOW.md` can record it as a decision with your name on it rather than as my omission.

claude added the