35 lines
2.2 KiB
Markdown
35 lines
2.2 KiB
Markdown
# How to contribute
|
|
|
|
I'm really glad you're reading this, if you are willing to contribute to this project in some form.
|
|
This is a quite small project with relatively low complexity so conventions are not as strict as they might be elsewhere. I am keen to learn whether and how this thing was useful to you, where you had problems and what you think could be improved.
|
|
|
|
Here are some important resources:
|
|
|
|
* This [Blogpost](https://www.commander1024.de/wordpress/2020/03/fotos-mit-daten-zu-radioaktiver-strahlung-taggen) tells you about intention and scope for this tool (in German).
|
|
* For questions and suggestions, you can [E-Mail](mailto:commander@commander1024.de) me directly.
|
|
* Bugs? [Gitlab](https://git.commander1024.de/Commander1024/radiation-tager/issues) is where to report them.
|
|
|
|
## Submitting changes
|
|
|
|
Please send a [Pull Request to radiation_tagger](https://git.commander1024.de/Commander1024/radiation-tager/pulls) in the develop branch with a clear list of what you've done (read more about [pull requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request)). Please follow our coding conventions (below) and make sure all of your commits are atomic (one feature per commit).
|
|
Keep in mind that I am a bloody beginner and probably make more mistakes than you, so I am always open for improvements.
|
|
|
|
Always write a clear log message for your commits. One-line messages are fine for small changes, but bigger changes should look like this:
|
|
|
|
$ git commit -m "A brief summary of the commit
|
|
>
|
|
> A paragraph describing what changed and its impact."
|
|
|
|
## Coding conventions
|
|
|
|
Start reading the code and you'll get the hang of it. We optimize for readability:
|
|
|
|
* We indent using 4 spaces (soft tabs).
|
|
* We use "describing" variables with underscores like 'position_list'.
|
|
* Classes and functions go to functions.py to keep the main program small and easy to understand.
|
|
* We generally follow the Python 3 coding style guidelines.
|
|
* This is open source software. Consider the people who will read your code, and make it look nice for them. It's sort of like driving a car: Perhaps you love doing donuts when you're alone, but with passengers the goal is to make the ride as smooth as possible.
|
|
|
|
Thanks,
|
|
Commander1024
|