Third-party contributions are essential for keeping senaite.sync
continuously
improving. We want to keep it as easy as possible to contribute changes that get
things working in your environment. There are a few guidelines that we need
contributors to follow so that we can have a chance of keeping on top of things.
The following is a set of guidelines for contributing to senaite.sync, which is hosted in the SENAITE Organization on GitHub. These are just guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior.
Have you found a bug in the code which is not in the list of known bugs? Do you have a suggestion for improvement? Then by all means please submit a new issue, and do not hesitate to comment on existing open issues.
When filling a new issue, please remember to:
-
Use a clear and descriptive title for the issue to identify the problem.
-
Describe the exact steps which reproduce the problem in as many details as possible. For example, start by describing your computing platform (Operating System and version, how did you installed senaite.core and its dependencies, what file or front-end are you using as a signal source, etc.). You can also include the configuration file(s) you are using, or a dump of the terminal output you are getting. The more information you provide, the more chances to get useful answers.
-
Please be patient. This organization is run on a volunteer basis, so it can take some time to the Developer Team to reach your issue. They will do their best to fix it as soon as possible.
-
If you opened an issue that is now solved, it is a good practice to close it.
The list of open issues can be a good starting point and a source of ideas if you are looking to contribute to the source code.
-
If you still have not done so, create your personal account on GitHub.
-
Fork senaite.sync from GitHub. This will copy the whole
senaite.sync
repository to your personal account. -
Then, go to your favourite working folder in your computer and clone your forked repository by typing (replacing
YOUR_USERNAME
by the actual username of your GitHub account):$ git clone https://github.com/YOUR_USERNAME/senaite.sync
-
Your forked repository https://github.com/YOUR_USERNAME/senaite.sync will receive the default name of
origin
. You can also add the originalsenaite.sync
repository, which is usually calledupstream
:$ cd senaite.sync $ git remote add upstream https://github.com/senaite/senaite.sync.git
To verify the new upstream repository you have specified for your fork, type
git remote -v
. You should see the URL for your fork as origin
, and the URL
for the original repository as upstream
:
$ git remote -v
origin https://github.com/YOUR_USERNAME/senaite.sync.git (fetch)
origin https://github.com/YOUR_USERNAME/senaite.sync.git (push)
upstream https://github.com/senaite/senaite.sync.git (fetch)
upstream https://github.com/senaite/senaite.sync.git (push)
Checkout the master
branch of the git repository in order to get synchronized
with the latest code:
$ git checkout master
$ git pull upstream master
Now you can do changes, add files, do commits (please take a look at how to write good commit messages!) and push them to your repository:
$ git push origin my_feature
If there have been new pushes to the master
branch of the upstream
repository since the last time you pulled from it, you might want to put your
commits on top of them (this is mandatory for pull requests):
$ git remote update
$ git pull --rebase upstream master
Alternatively, you can merge senaite.sync
's master
into your branch:
$ git remote update
$ git merge --no-ff upstream master
Although a merge is safer than rebase, the latter eliminates the unnecessary
merge commits required by git merge
and makes the project history easier to
navigate. We strongly encourage the developer to know in detail the differences,
pros and cons between doing a git rebase
or git merge
. Good documentation on
this regard can be found in the Atlassian's Merging vs. Rebasing tutorial.
Note this git rebase
or git merge
is required for keeping your branch
aligned with the latest code from the repos. The incorporation of your work into
master
through a Pull Request will always be done using git merge
.
When the contribution is ready, you can submit a pull
request. Head to your
GitHub repository, switch to your my_feature
branch, and click the
Pull Request button, which will do all the work for you. Ensure the
comparison is done with the master
branch unless you forked from another one.
Once a pull request is sent, the Developer Team will review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.
Some things that will increase the chance that your pull request is accepted:
- Write tests.
- Follow Plone's Python styleguide.
- Write a descriptive and detailed summary. Please consider that reviewing pull requests is hard, so include as much information as possible to make your pull request's intent clear.
- Do not address multiple bugfixes or features in the same Pull Request.
- Include whitespace and formatting changes in discrete commits.
- Add a changelog entry in CHANGES.rst
For more details about Git usage, please check out Chapters 1 and 2 from Pro Git book.
All suggestions and proposals are welcome. We strongly believe that the feedback of the community is an important asset to make a better project. With the aim to get the most of these contributions, but without interfering with the undergoing work regarding to issues and Pull Requests, we've created a Community discussion board on Github. This is the right place if you are willing to discuss about new ideas, further steps or improvements.
If you are interested on contributing and participating in these discussions, please ask for membership through our Gitter community channel and one of the SENAITE org members will give you access.