docs: delete irrelevant noise from the roadmap

Author: tobixen

docs/ROADMAP.md

@@ -1,6 +1,6 @@
 # Roadmap: plann
 
-**This document is a draft** - it was generated by Claude Opus 5.0.  As of 2026-08-25 significant parts of it has been reviewed and edited by Tobias Brox.  In any case, **an estimate is an estimate** - the only way to know for sure how much time a task will take is to actually do it.
+**This document is a draft** - it was generated by Claude Opus 5.0.  Parts of it has still not been through human scrutiny.  In any case, **an estimate is an estimate** - the only way to know for sure how much time a task will take is to actually do it.
 
 ## Funding
 
@@ -35,9 +35,7 @@ task list, the code references and the acceptance criteria, and is kept current
 the work proceeds.
 
 This document holds what an issue tracker is bad at: the shape of the whole, why the
-hours are distributed the way they are, what depends on what, what gets released
-when, and what is deliberately *not* funded.  Where this document and an issue
-disagree on a detail, the issue wins.
+hours are distributed the way they are, what depends on what, and what is deliberately *not* funded.  Where this document and an issue disagree on a detail, the issue wins.
 
 Every item has a status: `[x]` done, `[ ] wip` partly done (the text around the
 table says what is left), `[ ]` not started.  The hours are the estimates as made
@@ -110,7 +108,7 @@ config file.
 
 | Status | Item | Deliverable | h | € | Issue |
 |---|---|---|---|---|---|
-| [ ] wip | 1.0 Release v1.2.0 | The `[Unreleased]` work finished, [PR #43](https://github.com/pycalendar/plann/pull/43) landed, changelog closed, released to PyPI | 10 | 500 | |
+| [x] | 1.0 Release v1.2.0 | The `[Unreleased]` work finished, [PR #43](https://github.com/pycalendar/plann/pull/43) landed, changelog closed, released to PyPI | 10 | 500 | |
 | [ ] | 1.1 CalDAV server compatibility | Fixes, or a documented verdict that the fault is `caldav`'s or the server's, with issues filed there | 8 → **4** | 200 | [#25](https://github.com/pycalendar/plann/issues/25), [#26](https://github.com/pycalendar/plann/issues/26) |
 | [ ] | 1.2 Multi-calendar mass-edit | Mass-editing that is correct across calendars, or refuses to run when it cannot be | 4 → **3** | 150 | [#48](https://github.com/pycalendar/plann/issues/48) |
 | [ ] wip | 1.3 Improving the configuration helper logic | `interactive update-config` resolved one way or the other (it was dropped in v1.2.0 rather than implemented), a `plann configure` without its "here be dragons" warning, and documented non-plaintext credential options | 4 → **3** | 150 | [#49](https://github.com/pycalendar/plann/issues/49) |
@@ -252,28 +250,6 @@ duck.
 
 ---
 
-## Release plan
-
-| Release | Contents | After |
-|---|---|---|
-| 1.2.0 | Code-review fixes, the config-delegation refactor, community patches - the baseline everything else is measured against | 1.0 |
-| 1.3.0 | Server-compatibility fixes, multi-calendar fixes, usable configuration | 1.1-1.3 |
-| 2.0.0 | calendaring-client backend | Phase 3 |
-| 2.1.0 | Time tracking in the calendar, `sum_hours` | 4.1, 4.2 |
-| 2.2.0 | Milestone reporting | 4.3 |
-| 2.3.0 | Documented, typed, covered | Phases 2, 5 |
-
-The 2.0 number is reserved for the `calendaring-client` migration because that is
-where a backward-incompatible change is most likely - and because
-[`CHANGELOG.md`](../CHANGELOG.md) commits to "not breaking backward compatibility
-unless I really have to (and then under a 2.0-release)".
-
-Note what the reordering costs: the migration now gates every release after 1.3.0.
-If Phase 3 slips (see Risks), Phases 2 and 5 still ship - as 1.4.0 - but time
-tracking and reporting do not ship at all.
-
----
-
 ## Effort summary
 
 Per-item hours are in the phase tables above.
@@ -287,141 +263,6 @@ Per-item hours are in the phase tables above.
 | 5 - Documentation | 42 | 2100 | 29% |
 | **Total** | **144** | **7200** | |
 
-### Changes from the original five-bucket plan
-
-The original plan was 156 hours (7800 EUR).  It is now **144 hours (7200 EUR)**: 600
-EUR was moved to the `calendaring-client` grant to fund the library work that 1.3 and
-4.1 shed.  The total across the two grants is unchanged.
-
-| Original bucket | Was | Now | Why |
-|---|---|---|---|
-| Bug fixes and downstream improvements | 12 | 20 | Two open user-reported server-compatibility bugs, an unmerged community PR, a multi-calendar data-integrity bug found during this review, and the configuration/credentials path - which is where a new user meets plann and where an advertised command raises `NotImplementedError`.  The v1.2.0 release is now charged here too, at 10 hours, which is why the four bug-fixing items are funded at 10 against a 20-hour estimate |
-| QA | 48 | 48 | Unchanged in the end, and still the largest bucket by a wide margin: coverage is 50%, there are no type annotations at all, and two of the 88 TODO comments turned out to be unreported bugs.  It was briefly raised to 54 before 300 EUR - six hours - moved to the sibling grant |
-| Migration to calendaring-client | 16 | 16 | Unchanged in size, but moved ahead of the time-tracking work, which now depends on it.  The library-side APIs that plann became a consumer of are funded in the `calendaring-client` grant rather than here.  It buys a partial port and a design critique, not a completed migration |
-| Milestone reporting | 32 | 18 | The iCalendar representation of "time spent" is library work, not plann's.  And the report itself is an export format over an aggregated task list rather than a feature of its own - once the aggregation groups a selection into budget lines and totals each one, the rendering is a template |
-| Documentation | 48 | 42 | Six hours moved to Phase 1.  Documentation is still the second-largest block |
-
----
-
-## Risks
-
-### Phase 3 depends on a sibling project that does not exist yet - and now Phase 4 does too
-
-`calendaring-client` currently consists of a README and a roadmap.  No code has
-been written.  Its own funded scope is 248 hours and its CalDAV backend lands at
-roughly hour 100 of that plan.
-
-This is the largest scheduling risk in this roadmap.  The two projects' estimates
-for the same work also disagree: `calendaring-client`'s roadmap budgets 6 hours for
-its side of the port while estimating the full migration at 24-40 hours in its
-"beyond the funded scope" table.
-
-That disagreement is an artefact of the two plans having been written months apart,
-not a structural problem.  **Neither roadmap is final, and `calendaring-client` has
-not started, so it can still be reprojected** - including moving hours from this
-grant to that one where the work turns out to belong there.  See the scope note
-below.
-
-**This risk grew when time tracking was made to depend on the migration.**  The
-migration was originally last and load-bearing for nothing; it is now a prerequisite
-for all 18 hours of Phase 4.  That puts **34 hours - 24% of the grant** behind an
-external project that has not yet written a line of code, and it removes the release
-valve: dropping the migration now drops time tracking and milestone reporting with
-it.
-
-**Mitigation:** Phase 3 is scheduled as early as its dependency allows, and Phases 1,
-2 and 5 (110 hours, 76%) are deliberately independent of it, so the grant keeps
-delivering while it is blocked.  Its own deliverable stays defined as *evidence and a
-critique* rather than a finished port, so partial delivery is still delivery.
-
-**Contingency, to be decided rather than discovered:** if `calendaring-client` is not
-usable once Phases 1 and 2 are done, Phase 4 is implemented against the `caldav`
-library as it stands and ported afterwards.  That costs rework, but 4.1's core
-question - how to represent time spent in iCalendar - is a data-model decision rather
-than a backend one, and the chosen storage format survives the port even when the
-plumbing does not.  The alternative, waiting, risks the grant ending with neither the
-migration nor the feature it now blocks.
-
-### Work shed upstream needs a home in the upstream budget
-
-Two items here concluded that logic belongs in the library rather than in plann:
-1.3 (configuration and credentials) and 4.1 (the iCalendar representation of time
-spent).  That is the right call on the merits - see guiding constraint 2 - but it
-moves work rather than removing it, and the receiving budget has to actually have
-room for it.
-
-- **Configuration and credentials is already funded upstream.**
-  `calendaring-client`'s item 1.4 (8 hours) covers config format, discovery, and
-  "credential handling: keyring integration, and never requiring secrets in
-  plaintext config".  Nothing needs to move; the scope just needs confirming.
-- **Time-tracking storage is not.**  Only the *research* is funded, inside
-  `calendaring-client`'s item 0.1, whose task-model survey covers "time estimate and
-  time spent".  There is no implementation line for a time-tracking API, and 4.1
-  depends on one existing.
-
-**Resolved:** `calendaring-client` has been reprojected, with an explicit
-"Time-tracking model and API" item (12 h), funded by moving 600 EUR from this grant.
-plann's scope drops from 156 to 144 hours accordingly, and the total across the two
-grants is unchanged.  The work is the same work; which grant pays for it was an
-accounting question rather than a technical one.
-
-The failure mode this avoids is both roadmaps assuming the other is paying - which is
-how 4.1 would have ended up blocked on an API nobody had budgeted to write.
-
-### Milestone reporting has an audience of one
-
-Phase 4.3 is 9% of the funded period spent on a feature whose most obvious user is
-the author, producing reports for this very grant.
-
-**Mitigation:** the aggregation layer (3.2) is generic and useful on its own, and
-the NLnet layout is a template on top of it rather than hard-coded logic.  Anyone
-who bills by the hour gets the same feature.  If it turns out otherwise, the item
-is at least self-evaluating: the milestone reports for this grant are produced with
-it, so a failure is visible immediately rather than at the end.
-
-### Time tracking rests on a standard that does not support it
-
-[`NEXT_LEVEL.md`](../NEXT_LEVEL.md) is explicit that iCalendar has no place to
-record time spent: a VJOURNAL cannot carry a DURATION, and the three candidate
-workarounds (an illegal DTEND on a journal, `PARTSTAT=X-ATTENDED`, or a new
-`VTIMESPENT` component) are all compromises.  Whatever Phase 4 picks, other
-calendaring tools will not understand it.
-
-**Mitigation:** the representation is documented (3.1) so that it is at least
-*legible* to another implementation, and the `timewarrior` export path is kept so
-users who need interoperable time tracking have somewhere to go.  This is a known
-gap in the standards, not a defect in plann, and saying so plainly in the
-documentation is part of the deliverable.
-
-### The QA phase has no visible output
-
-Forty-six hours of tests, annotations and TODO triage produce nothing a user can
-see.  It is the item most likely to be cut when time runs short, and the item whose
-absence caused the fifteen correctness bugs that Phase 1 is releasing fixes for.
-
-**Mitigation:** it is scheduled early, its deliverables are numeric (coverage
-thresholds, mypy in CI, TODO counts) rather than subjective, and CI enforcement
-means the gains cannot silently erode afterwards.
-
-### Maintainer bandwidth
-
-The primary maintainer has several packages to juggle - several of them NLnet-funded -
-as well as other priorities and concerns in life.  It is a real risk that time will
-run out before the allocated funds do.
-
-**Mitigation:** Phases 1, 2 and 5 are independent of everything else,
-so partial delivery is meaningful in any order.  Phase 1 alone leaves users better
-off than today.  There are other developers in the pycal pool who may pick up
-pieces.
-
-### Peer review is a dependency on other people
-
-Phase 5.5 requires reviewers who are not the author, and the most valuable reviewer
-is someone who has never used plann.
-
-**Mitigation:** approach reviewers during Phase 1, not when the documentation is
-ready.
-
 ---
 
 ## Beyond the funded scope