Anyone is welcome to contribute to the app. Either by just reporting a bug or making a feature request or by actually contributing code. This document explains the practical process and guideline for contribution.
To contribute a patch, the workflow is as follows:
- Clone the repository
git checkout master; git pull- Create a topic branch
- Commit patches
- Push commit
- Open a pull request
For more details about the development process have a look to the developer notes.
For a better overview, follow the branch naming scheme
<feature|bug>/<issue_id>_<short_description>.
E.g. bug/123_app_crash_during_export
A general rule is that commits should be atomic (squash commits if necessary) and diffs should be easy to read. For this reason, do not mix any formatting fixes or code moves with actual code changes.
Commit messages should consist of a short subject line of max 50 chars, a blank line and a detailed explanation of the commit, unless the subject line alone is self-explanatory (like "Fix typo in CONTRIBUTING.md") in which case the subject line is sufficient. For a more detailed explanation about this topic, see this post.
If a commit references an issue, please add the reference. For
example: refs #1234 or fixes #4321. Using the fixes or closes
keywords will cause the corresponding issue to be closed when the pull
request is merged.
The description of the pull request should contain sufficient information of what the patch does. You should include references to any discussions (for example, other issues or mailing list discussions).
At this point you should expect comments and feedback from other contributors. You can add more commits to your pull request by committing them locally and pushing to your fork until you have satisfied all feedback.
If your pull request contains fix-up commits or commits which address too many things at once, you shall either squash or split these commits.
By contributing to this repository, you agree to license your work under the GPL-3.0 license.