You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of #448 — Block A, the landing surface. This is A5: it comes after #402, #403, #291 and #390, because those are cheaper and more direct, and because a public board pointing at an unbranded repository does not help.
What exists today
Poveste Launch private 15 items last updated 2026-08-12
Worth being precise about its state, because "abandoned board" is the wrong diagnosis. It holds issues #1–#15, of which fourteen are closed and one is open (#14, now in Backlog). It is a completed board for a launch that happened — not a board someone stopped maintaining mid-flight. It was left open and private afterwards, and nothing has been added since 12 August.
So the work is not "revive it". It is: close that one out, and build the thing it was never trying to be.
Why this belongs in Block A rather than in tooling
The four upstream threads in #372 carry 43 upvotes between them asking one question — is this maintained? — and none was ever answered by a maintainer.
A public project board with the current week's activity on it answers that question structurally. Prose claiming a project is active is exactly what a reader discounts; a board showing eleven things closed in the last two days is not. This is the same job as #402 and #291 — replace a claim with evidence a visitor can check in ten seconds.
Shape
A new public Projects v2, org-level, with a Roadmap view — the timeline layout driven by a date or iteration field — plus a board view grouped by milestone.
It must be auto-maintained, or it should not be built. The failure mode to design against is the one that already happened here: a board that needs a human to remember it, which lasted nine days. Projects v2 has built-in workflows — auto-add every new issue in the repository, set status on close, archive when done. If keeping it accurate is a manual step, it will go stale, and a stale public roadmap is a worse signal than no roadmap at all, which makes this issue actively harmful if half-done.
Group by milestone, not by sprint. The twelve milestones each say one thing and are public-facing; the sprint labels are an internal execution order and would need explaining.
Two deliberate non-goals
Do not set milestone due dates. They are all unset on purpose. Version numbers were stripped from milestones after one feat turned 0.6.2 into 0.7.0 and a second turned 0.7.1 into 0.8.0 — dates we cannot commit to would recreate exactly that churn in a different field. If the roadmap view needs a time axis, an iteration field that is allowed to slip is honest in a way a due date is not.
Do not reproduce the reasoning. A board is good at state — open, in flight, closed. It is bad at judgment: why this order, what a metric means, which conclusions were drawn and later disproved. Keeping that out avoids two sources of truth that drift apart, which is the failure this repository has hit twice already.
Part of #448 — Block A, the landing surface. This is A5: it comes after #402, #403, #291 and #390, because those are cheaper and more direct, and because a public board pointing at an unbranded repository does not help.
What exists today
Worth being precise about its state, because "abandoned board" is the wrong diagnosis. It holds issues #1–#15, of which fourteen are closed and one is open (#14, now in Backlog). It is a completed board for a launch that happened — not a board someone stopped maintaining mid-flight. It was left open and private afterwards, and nothing has been added since 12 August.
So the work is not "revive it". It is: close that one out, and build the thing it was never trying to be.
Why this belongs in Block A rather than in tooling
The four upstream threads in #372 carry 43 upvotes between them asking one question — is this maintained? — and none was ever answered by a maintainer.
A public project board with the current week's activity on it answers that question structurally. Prose claiming a project is active is exactly what a reader discounts; a board showing eleven things closed in the last two days is not. This is the same job as #402 and #291 — replace a claim with evidence a visitor can check in ten seconds.
Shape
A new public Projects v2, org-level, with a Roadmap view — the timeline layout driven by a date or iteration field — plus a board view grouped by milestone.
It must be auto-maintained, or it should not be built. The failure mode to design against is the one that already happened here: a board that needs a human to remember it, which lasted nine days. Projects v2 has built-in workflows — auto-add every new issue in the repository, set status on close, archive when done. If keeping it accurate is a manual step, it will go stale, and a stale public roadmap is a worse signal than no roadmap at all, which makes this issue actively harmful if half-done.
Group by milestone, not by sprint. The twelve milestones each say one thing and are public-facing; the sprint labels are an internal execution order and would need explaining.
Two deliberate non-goals
Do not set milestone due dates. They are all unset on purpose. Version numbers were stripped from milestones after one
featturned 0.6.2 into 0.7.0 and a second turned 0.7.1 into 0.8.0 — dates we cannot commit to would recreate exactly that churn in a different field. If the roadmap view needs a time axis, an iteration field that is allowed to slip is honest in a way a due date is not.Do not reproduce the reasoning. A board is good at state — open, in flight, closed. It is bad at judgment: why this order, what a metric means, which conclusions were drawn and later disproved. Keeping that out avoids two sources of truth that drift apart, which is the failure this repository has hit twice already.
Done when
Poveste Launchis closed, with Remaining histoire references (Tier C: external / deferred) #14 removed or carried over