|
1 | 1 | # DipDup contribution guide |
2 | 2 |
|
3 | | -> 🚧 **UNDER CONSTRUCTION** |
4 | | -> |
5 | | -> This page or paragraph is yet to be written. Come back later. |
| 3 | +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). |
6 | 4 |
|
7 | | -## Preparation |
| 5 | +## General |
8 | 6 |
|
9 | | -* To set up the development environment, you need to install [Poetry](https://python-poetry.org/docs/#installation) package manager and GNU Make. |
10 | | -* Run `make help` to get available commands. |
| 7 | +* All code in this repository MUST be licensed under the [MIT License](LICENSE). |
| 8 | +* Python code in this repository MUST run on Python 3.10. It also SHOULD run on Python 3.11. Using modern language features is encouraged. |
| 9 | +* Python code in this repository MUST run in Linux, macOS, Docker, and `amd64`/`arm64` environments. Windows SHOULD be supported as well. |
| 10 | +* We use the [Poetry](https://python-poetry.org/docs/#installation) package manager and GNU Make to set up the development environment. You SHOULD install both tools and run `make help` to see available shortcuts. |
| 11 | +* Developers SHOULD have fun while contributing to the project. |
11 | 12 |
|
12 | | -## Git |
| 13 | +## GitHub |
13 | 14 |
|
14 | | -* Branch names MUST follow `prefix/short-descriptions` format. Prefixes we currently use: `feat` for features, `fix` for bugfixes, `docs` for documentation, `aux` for miscellaneous, `exp` for experiments. |
| 15 | +* Branch names MUST follow `prefix/short-description` format. Prefixes currently in use: `feat` for features, `fix` for bugfixes, `docs` for documentation, `aux` for miscellaneous, `exp` for experiments. |
| 16 | +* Commits in pull requests MUST be squashed when merging to `master`. |
| 17 | +* Issues and pull requests MUST have a descriptive title; they SHOULD be linked to each other, appropriately labeled, and assigned to maintainers while in progress. |
15 | 18 |
|
16 | 19 | ## Codestyle |
17 | 20 |
|
18 | | -* We use the following combo of linters and formatters: `isort`, `black`, `flake8`, `mypy`. All linter checks MUST pass before merging code to master. |
| 21 | +* We use the following combo of linters and formatters: `isort`, `black`, `flake8`, `mypy`. All linter checks MUST pass before merging code to `master` (CI will fail otherwise). |
| 22 | +* Single quotes are RECOMMENDED for string literals. |
| 23 | +* Meaningful comments are highly RECOMMENDED to begin with `# NOTE:`, `# TODO:`, or `# FIXME:`. |
| 24 | +* f-string formatting is RECOMMENDED over other methods. Logging is an exception to this rule. |
19 | 25 |
|
20 | 26 | ## Releases |
21 | 27 |
|
22 | | -* Release versions SHOULD conform to [Semantic Versioning](https://semver.org/). Releases that introduce breaking changes MUST be major ones. |
23 | | -* Only the latest major version is supported in general. Critical fixes CAN be backported to the previous major release. To do so, git checkout from the latest stable tag, bump DipDup version manually and add a new tag. |
| 28 | +* Release versions MUST conform to [Semantic Versioning](https://semver.org/). Releases that introduce breaking changes MUST be major ones. |
| 29 | +* Only the latest major version is supported in general. Critical fixes MAY be backported to the previous major release. To do so, create an `aux/X.Y.Z` branch from the latest stable tag, bump the DipDup version manually, and add a new tag. |
24 | 30 |
|
25 | 31 | ## Documentation |
26 | 32 |
|
27 | | -* All changes that affect user experience MUST be documented in CHANGELOG.md file. |
28 | | -* Changelog formatting SHOULD stick to GitLab changelog [guidelines](https://docs.gitlab.com/ee/development/changelog.html). |
| 33 | +* All changes that affect user experience MUST be documented in the CHANGELOG.md file. |
| 34 | +* Changes that significantly affect DipDup maintainers' experience MAY be documented in the CHANGELOG.md file. |
| 35 | +* The changelog MUST conform to the "Keep a Changelog" specification (CI will break otherwise). |
| 36 | +* A page in Release Notes SHOULD accompany all major releases. |
| 37 | +* All internal links MUST be created with `{{ #summary ...` shortcodes. |
| 38 | +* All values used in project templates MUST be replaced with `{{ #cookiecutter ...` shortcodes. |
| 39 | + |
| 40 | +> 🚧 **UNDER CONSTRUCTION** |
| 41 | +> |
| 42 | +> This page or paragraph is yet to be written. Come back later. |
| 43 | +
|
| 44 | +## Demo Projects |
| 45 | + |
| 46 | +## Installer |
| 47 | + |
| 48 | +## Docker Images |
| 49 | + |
| 50 | +## Tests |
| 51 | + |
| 52 | +## Code Review |
0 commit comments