Reporting on a commitment
Everything on the roadmap is owned, and owning it means three things: the work is tracked where anyone can check it, its owner posts an update every month, and it closes with a retrospective.
Track the work where anyone can check it
Keep a GitHub project board with every active task and issue on it. Milestones are the delivery checkpoints — the phases of the proposal, its deliverables, or quarterly checkpoints — each with a due date, and every issue belongs to one. Keep task status current as things move.
Share the board's address in the proposal thread. The commitment's page on the roadmap links to the board beside the thread and the repo, so anyone can check a claim against the work itself.
Post an update every month
At the end of each month, or when a milestone lands, whichever comes first, as a reply in the proposal's thread on the forum. Keep it short and easy to scan. Tie every claim to something a reader can open — a pull request, a repository, documentation, a deployment, a demo — and map it to the proposal's milestones. Outcomes, not narrative.
An update carries:
- Project and update number
- Period covered
- Status: On track, At risk (say what could push it out) or Off track (say what changes)
- Summary, one or two sentences, on outcomes
- Completed deliverables, grouped by milestone, each with its link
- What is planned for the next update, and when it is due
The roadmap shows each post as one line, its status, and a link to the post, and each month's changelog entry lists who posted and who did not. Write the summary so its first sentence stands alone; that is the line the roadmap shows. After six weeks with nothing posted the card reads No update, whatever the last one said. If you have access to the roadmap's Notion workspace, you can post the update there instead of the forum, with the write-up in the page body.
When the work ships, say so in the update. The commitment moves to Shipped with the date, and the retrospective is the next post.
Close with a retrospective
When the scoped work is done, the commitment owes one more post in the same thread, written while the context is fresh. Factual and about outcomes: what was committed, what was delivered, and the gap between them. Any structure works as long as it covers:
- Introduction — the work in brief, and its scope
- Commitments delivered — with their artifacts, and what was learned making them
- Delivered beyond the commitment — why it was taken on, and what it added
- Commitments not delivered — why, and what to do about it next time
- Impact — what changed for the network, with evidence
- Key learnings — what should shape the next proposal
- Conclusion and what is next — follow-up work, handoffs, recommended next steps
On the roadmap, the retrospective is the record's closing post: a shipped record leads with it, and until one is posted the card says No retrospective.