radiation-tagger/CONTRIBUTING.md

35 lines
2.2 KiB
Markdown
Raw Normal View History

# 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.
2020-04-16 10:42:20 +02:00
* Bugs? [Gitlab](https://git.commander1024.de/Commander1024/radiation-tager/issues) is where to report them.
## Submitting changes
2020-04-16 10:55:06 +02:00
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