makiolaj/calendula
1
0
Fork 1
Code Actions Releases 32 Activity

docs: drop the roadmap and state snapshot, superseded by the tracker

Browse Source 
ROADMAP.md and STATE.md predate the issue tracker. They were how planning
worked before issues and milestones existed, and keeping them means
maintaining a second copy of that information by hand — which is why
STATE.md still described release/v2.8.0 as the next release, eight minors
ago.

Issues and milestones say the same thing and can't drift: a milestone maps
to its release/vX.Y.Z branch, which is now also how a contributor learns
where to target a PR. Both files stay in git history if a past decision
needs looking up.

Repointed the six references at the tracker: the README's docs list, two
rows in the docs map, PROJECT.md's Current Milestone, and REQUIREMENTS.md's
idea-backlog pointer. ARCHITECTURE.md's "see the roadmap's idea backlog"
now cites the crash reporter's web-issue path instead — a worked example of
the no-network rule beats a pointer to a deleted backlog.
This commit is contained in:
Jean-Luc Makiola
2026-07-30 10:25:19 +02:00
parent b93f9759d2
commit 03cb767f72
7 changed files with 13 additions and 774 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/README.md
View File

@@ -9,15 +9,16 @@ Where to look for what:
| [`ARCHITECTURE.md`](ARCHITECTURE.md) | Orientation tour: principles, layers, navigation, recurring-write / conflict / reminder pipelines, testing |
| [`RELEASING.md`](RELEASING.md) | Release process: versioning, the merge-driven pipeline, the two-forge split, secrets, key custody |
| [`../CHANGELOG.md`](../CHANGELOG.md) | Release history (Keep a Changelog, SemVer) |
| [`../.planning/ROADMAP.md`](../.planning/ROADMAP.md) | Living roadmap: shipped milestones, current scope, idea backlog |
| [Issues](https://codeberg.org/jlmakiola/calendula/issues) + [milestones](https://codeberg.org/jlmakiola/calendula/milestones) | **The roadmap.** What's planned, in progress, and shipped — a milestone maps to its `release/vX.Y.Z` branch |
| [`../.planning/PROJECT.md`](../.planning/PROJECT.md) | What the project is, stack, naming, infrastructure |
| [`../.planning/REQUIREMENTS.md`](../.planning/REQUIREMENTS.md) | Requirement checklist per milestone |
| [`../.planning/STATE.md`](../.planning/STATE.md) | Snapshot of where development currently stands |
| [`../.planning/REQUIREMENTS.md`](../.planning/REQUIREMENTS.md) | Historical V1/V2 requirement checklist, plus the stack/platform constraints |
| [`design/`](design/) | Per-feature design notes kept for features whose provider behaviour is worth recording |
| [`../fastlane/metadata/android/`](../fastlane/metadata/android/) | Store metadata (single source of truth): descriptions, title, icon, screenshots (DE + EN). Harvested directly by the official F-Droid repo; transformed into the self-hosted repo layout at release time by [`../scripts/fastlane_to_fdroid_localized.sh`](../scripts/fastlane_to_fdroid_localized.sh) |
| [`../fdroid-metadata/`](../fdroid-metadata/) | App-level F-Droid control file (`*.yml`: Categories, License, links) for the self-hosted repo's `fdroid update` |
| [`fdroid-official/`](fdroid-official/) | Recipe + notes for publishing to the **official** F-Droid repo (reproducible build + developer-signed binary) |
Conventions: the `.planning/` files are living documents and should stay current.
`ARCHITECTURE.md` is the authoritative orientation tour — it is updated with the
Conventions: planning lives in the **issue tracker**, not in this repository. The
`.planning/` files that predated it (a roadmap and a development-state snapshot)
are gone — issues and milestones say the same thing without going stale.
`ARCHITECTURE.md` is the authoritative orientation tour: it is updated with the
code, and is the right place for a lesson learned about the calendar provider.