Files
calendula/docs
Jean-Luc Makiolaandmakiolaj a1ed010963
Release — F-Droid repo + Gitea/Codeberg release + Play / detect (push) Successful in 8s
Release — F-Droid repo + Gitea/Codeberg release + Play / release (push) Skipped
Release — F-Droid repo + Gitea/Codeberg release + Play / play (push) Skipped
docs(privacy): point the controller contact at support@ (#307)
The Controller section of `docs/PRIVACY.md` names the address a reader writes
to in order to exercise their rights under Art. 15-21 GDPR. That is a different
kind of mail from a project enquiry, so it now points at
`support@jeanlucmakiola.de` instead of `business@jeanlucmakiola.de`.

Same change is going into Agendula, and the website's own Datenschutzerklärung
already names `support@` in its § 1. `business@` stays reachable — it is just no
longer the published address anywhere.

`updated:` bumped to 2026-09-15, since the published policy changes.

Two notes for review:

- **Target branch.** CONTRIBUTING says to target the release branch named by the
  issue's milestone. The open milestones (2.21.0 and later) have no branches
  yet, so per the same section this targets `main` and says so — retarget it if
  you would rather it waited for one.
- **No changelog entry.** The entries in `CHANGELOG.md` describe what changed
  for the person using the app, and nothing about the app changed here. Happy to
  add one under a new `## [Unreleased]` if you want the contact change to show
  up in the release notes.

`business@` needs to keep accepting mail until this is live on
jeanlucmakiola.de/calendula/privacy and the Play Console listing has caught up.

Co-authored-by: Jean-Luc Makiola <business@jeanlucmakiola.de>
Reviewed-on: https://codeberg.org/jlmakiola/calendula/pulls/307
2026-09-15 16:10:29 +02:00
..
2026-09-02 12:44:40 +02:00
2026-09-07 21:25:35 +02:00

Documentation map

Where to look for what:

Document What it is
../CONTRIBUTING.md How to contribute: issue-first workflow, which branch to target, translations, the rules a change is reviewed against
BUILDING.md Building from source: submodule, JDK/SDK requirements, Gradle tasks, what CI runs
ARCHITECTURE.md Orientation tour: principles, layers, navigation, recurring-write / conflict / reminder pipelines, testing
RELEASING.md Release process: versioning, the merge-driven pipeline, the two-forge split, secrets, key custody
../CHANGELOG.md Release history (Keep a Changelog, SemVer)
Issues + milestones The roadmap. What's planned, in progress, and shipped — a milestone maps to its release/vX.Y.Z branch
../.planning/PROJECT.md What the project is: core value, stack + version pins, constraints, naming, forge/release infrastructure
design/ Per-feature design notes kept for features whose provider behaviour is worth recording
../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
../fdroid-metadata/ App-level F-Droid control file (*.yml: Categories, License, links) for the self-hosted repo's fdroid update
fdroid-official/ Recipe + notes for publishing to the official F-Droid repo (reproducible build + developer-signed binary)

Conventions: planning lives in the issue tracker, not in this repository. The .planning/ files that predated it (a roadmap, a development-state snapshot, and a per-milestone requirement checklist) are gone — issues and milestones say the same thing without going stale. PROJECT.md is what remains, and it describes the project rather than its plan. 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.