@@ -5,9 +5,12 @@ and pull requests are all welcome.
55
66## Before you start
77
8- - For a bug, open an issue with the registry, the package, the two versions and what you expected.
9- - For a larger change, open an issue first so we can agree on the approach.
10- - Security problems go through [ SECURITY.md] ( SECURITY.md ) , not through an issue.
8+ Every change starts with an issue. Open one first — a bug, a registry quirk, a feature or a chore —
9+ using the matching issue template, so the work has a tracked rationale before any code is written.
10+
11+ - For a bug, include the registry, the package, the two versions and what you expected.
12+ - For a feature or a larger change, describe the approach in the issue so we can agree on it first.
13+ - Security problems go through [ SECURITY.md] ( SECURITY.md ) , never a public issue.
1114
1215## Setting up
1316
@@ -16,7 +19,13 @@ a PostgreSQL and Redis you can reach on `localhost`.
1619
1720## Branches and pull requests
1821
19- - Branch from ` develop ` and open the pull request into ` develop ` . ` master ` only receives releases.
22+ We work issue-first, with the pull request opened alongside the issue rather than at the end:
23+
24+ - Once an issue exists, branch from ` develop ` and open the pull request into ` develop ` early — a
25+ draft is fine — so the work is visible while it is still in progress. ` master ` only receives
26+ releases.
27+ - Link the pull request to its issue with a closing keyword (` Closes #123 ` ) so merging the pull
28+ request closes the issue. A pull request without a linked issue will be asked to add one.
2029- Keep a pull request about one thing and fill in the pull request template, in English. CI
2130 (backend tests, frontend build and tests, dependency gate) must be green.
2231- Commit messages follow Conventional Commits: ` feat(scope): ... ` , ` fix(scope): ... ` , ` docs: ... ` .
0 commit comments