update CONTRIBUTING.md
This commit is contained in:
parent
a02ed98c7e
commit
a08d4a74e8
|
@ -0,0 +1,65 @@
|
|||
There are many ways to contribute, you can find out all the ways on our
|
||||
[Contribute](https://f-droid.org/contribute/) page. Find out how to get
|
||||
involved, including as a translator, data analyst, tester, helping others, and
|
||||
much more!
|
||||
|
||||
## Contributing Code
|
||||
|
||||
We want more contributors and want different points of view represented. Some
|
||||
parts of the code make contributing quick and easy. Other parts make it
|
||||
difficult and slow, so we ask that contributors have patience.
|
||||
|
||||
To submit a patch, please open a merge request on GitLab. If you are thinking of
|
||||
making a large contribution, open an issue or merge request before starting
|
||||
work, to get comments from the community. Someone may be already working on the
|
||||
same thing, or there may be reasons why that feature isn't implemented. Once
|
||||
there is agreement, then the work might need to proceed asynchronously with the
|
||||
core team towards the solution.
|
||||
|
||||
To make it easier to review and accept your merge request, please follow these
|
||||
guidelines:
|
||||
|
||||
* When at all possible, include tests. These can either be added to an existing
|
||||
test, or completely new. Practicing test-driven development will make it
|
||||
easiest to get merged. That usually means starting your work by writing tests.
|
||||
|
||||
* See [help-wanted](https://gitlab.com/fdroid/fdroidserver/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=help-wanted)
|
||||
tags for things that maintainers have marked as things they want to see
|
||||
merged.
|
||||
|
||||
* The amount of technical debt varies widely in this code base. There are some
|
||||
parts where the code is nicely isolated with good test coverage. There are
|
||||
other parts that are tangled and complicated, full of technical debt, and
|
||||
difficult to test.
|
||||
|
||||
* The general approach is to treat the tangled and complicated parts as an
|
||||
external API (albeit a bad one). That means it needs to stay unchanged as much
|
||||
as possible. Changes to those parts of the code will trigger a migration,
|
||||
which can require a lot of time and coordination. When there is time for large
|
||||
development efforts, we refactor the code to get rid of those areas of
|
||||
technical debt.
|
||||
|
||||
* We use [_black_](https://black.readthedocs.io/) code format, run `black .` to
|
||||
format the code. Whenever editing code in any file, the new code should be
|
||||
formatted as _black_. Some files are not yet fully in _black_ format (see
|
||||
_pyproject.toml_), our goal is to opportunistically convert the code whenever
|
||||
possible. As of the time of this writing, forcing the code format on all files
|
||||
would be too disruptive.
|
||||
|
||||
* Many of the tests run very fast and can be run interactively in isolation.
|
||||
Some of the essential test cases run slowly because they do things like
|
||||
signing files and generating signing keys.
|
||||
|
||||
* Some parts of the code are difficult to test, and currently require a
|
||||
relatively complete production setup in order to effectively test them. That
|
||||
is mostly the code around building packages, managing the disposable VM, and
|
||||
scheduling build jobs to run.
|
||||
|
||||
* For user visible changes (API changes, behaviour changes, etc.), consider
|
||||
adding a note in _CHANGELOG.md_. This could be a summarizing description of
|
||||
the change, and could explain the grander details. Have a look through
|
||||
existing entries for inspiration. Please note that this is NOT simply a copy
|
||||
of git-log one-liners. Also note that security fixes get an entry in
|
||||
_CHANGELOG.md_. This file helps users get more in-depth information of what
|
||||
comes with a specific release without having to sift through the higher noise
|
||||
ratio in git-log.
|
Loading…
Reference in New Issue