Jean-Luc Makiola
fbb14f9334
Codeberg became canonical for issues, PRs and releases, but there was nothing telling a contributor how any of it works — no CONTRIBUTING.md at all, and no contributor entry point in the README. The workflow it documents is issue-first: a feature needs a yes-or-no before it needs code, since whether Calendula should do a thing is the one decision a patch cannot make. Both features and bugs get a milestone, and that milestone names the branch a PR targets (2.18.0 -> release/v2.18.0), because main is a release trigger rather than a staging area. Typo and docs fixes skip straight to a PR — an issue-per-typo helps nobody. Two traps get their own sections because both waste a contributor's whole afternoon: translations never go through PRs (Weblate owns every values-* file, German included, and overwrites hand-edits on the next sync), and a clone without --recurse-submodules cannot configure at all, since floret-kit is a composite build compiled from source. The rules section is the invariants that actually turn into review comments — no network, no second database, no hand-patching UI state after a write, domain/ free of Android imports, JVM-first tests, and the reproducible-build flags that the official F-Droid repo depends on.
42 lines
1.3 KiB
Markdown
42 lines
1.3 KiB
Markdown
<!--
|
|
Thanks for contributing to Calendula!
|
|
|
|
Please skim CONTRIBUTING.md if you haven't:
|
|
https://codeberg.org/jlmakiola/calendula/src/branch/main/CONTRIBUTING.md
|
|
|
|
Two things it's easy to get wrong:
|
|
• Features need a discussed issue first — an undiscussed feature PR may be
|
|
closed unmerged even when the code is good.
|
|
• Target the release branch for your issue's milestone (milestone 2.18.0 →
|
|
release/v2.18.0), not main. If you targeted main, just say so below and it
|
|
will be retargeted.
|
|
-->
|
|
|
|
### What this changes
|
|
|
|
|
|
### Why
|
|
|
|
<!-- Closes #123 — link the issue this implements or fixes. -->
|
|
|
|
|
|
### How it was tested
|
|
|
|
<!--
|
|
Which of these ran green, and anything you exercised by hand. On-device notes
|
|
are especially useful for UI changes.
|
|
|
|
./gradlew lint test assembleDebug
|
|
python3 scripts/check_translations.py
|
|
-->
|
|
|
|
|
|
### Checklist
|
|
|
|
- [ ] There's an issue for this, and (for a feature) it got a go-ahead
|
|
- [ ] Targeting the release branch for that issue's milestone — or `main`, noted above
|
|
- [ ] `./gradlew lint test assembleDebug` passes locally
|
|
- [ ] No `values-*/strings.xml` touched (Weblate owns those; new English strings in `values/` are fine)
|
|
- [ ] `CHANGELOG.md` updated under `## [Unreleased]`, if the change is user-visible
|
|
- [ ] No planning or design documents committed
|