We are really glad that you are reading this contribution guide. This means you care about the quality of your contributions.
Basic knowledge about how to use Github:
- Properly setup your git client.
- Know how to create a commit (for details see below).
- Know how to work with git history (rebasing your commits).
- Know how to create Pull Requests.
- Check whether the change you want to introduce is not already present in the base repository. Main base repository can be cloned from: https://github.com/leliuga/datrin
- Check whether the change you want to introduce has not been already submitted by someone else.
- If you've found that someone already did what you wanted to do, then be patient. The change should be applied soon in the main repository, unless maintainers are busy or the patch needs to be improved. If it seems that your change won't be duplicating already done work, then please continue.
- Fork our Leliuga base repository.
- Clone your copy of base
git clone git@github.com:leliuga/datrin.git
. - Create a feature branch
git checkout -b my_new_feature
. - Make your desired changes and commit them with a correct commit message.
- If needed provide a proper formatted (line wrapped) description of what your patch will do. You can provide a description in the PR, but you must include a message for this specific commit in the commit description. If in the future we would like to distance ourselves from Github the PR information could be lost.
- Open your copy of the base repository at github.com and switch to your feature branch. You should now see an option to create your PR. More info
- Wait for an Leliuga author to review your changes.
- If all is ok your PR will be merged but if a author asks for changes please do as follows:
- Make the requested changes.
- Add your file(s) to git and commit (we will squash your commits if needed).
- Push your changes
git push origin my_new_feature
.
- Goto #6.
When you want to submit a package including its new dependencies to our repository, you should bundle these commits into a single PR. This is needed so our CI will first build the dependencies after which it will build the parent package. Failing to include new dependencies will fail the CI tests.
If by some mistake you end up with multiple commits in your PR and one of our authors asks you to squash your commits please do NOT create a new pull request. Instead please follow this rebase tutorial.
Pull Requests that have not been updated in the last 180 days will automatically be labeled S-stale. After 7 days of additional inactivity the PR will automatically be closed except if one of the Leliuga authors will label it with S-WIP (Work In Progress).