setop
/
python-escpos
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

DOC improve CONTRIBUTING 

based on the feedback by @mike42 and @DavisGoglin
This commit is contained in:
Patrick Kanzler 2016-04-14 00:16:06 +02:00
parent df77b7dec3
commit eadd9f7583
No known key found for this signature in database
GPG Key ID: F07F07153306FCEF
1 changed files with 12 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
CONTRIBUTING.rst
View File

@ -10,7 +10,7 @@ In order to reduce the amount of work for everyone please try to adhere to good
The pull requests and issues will be prefilled with templates. Please fill in your information where applicable. The pull requests and issues will be prefilled with templates. Please fill in your information where applicable.
This project uses `semantic versioning <http://semver.org/>`_ and tries to adhere to the proposed rules as This project uses `semantic versioning <http://semver.org/>`_ and tries to adhere to the proposed rules as
good as possible. well as possible.
Style-Guide Style-Guide
----------- -----------
@ -44,20 +44,19 @@ The checks by Landscape and QuantifiedCode that run on every PR will provide you
GIT GIT
^^^ ^^^
The master-branch contains code that always builds. Releases are tags on the master branch. The master-branch contains code that has been released to PyPi. A release is marked with a tag
Currently, development happens in a separate branch, because we refactored basically the whole code. corresponding to the version. Issues are closed when they have been resolved in a released version
Please branch of the HEAD of the current development-branch and create a pull request to development with your changes. of the package.
Try to group your commits into logical units. Before creating your pull request consider rebasing your branch to the When you have a change to make, begin by creating a new branch from the HEAD of `python-escpos/development`.
HEAD of the branch that you developed against. You can also regroup your commits during this rebase with the Name your branch to indicate what you are trying to achieve. Good branch names might
feature `squash` of interactive rebasing. You may also do so after creating your PR, but please put up a notice be `improve/text-handling`, `feature/enable-color-printing`.
that you have force-pushed your changes into your feature-branch.
A force-push should never occur directly on the master- or development-branch.
When you create a branch please name your branch after what you are trying to achieve, e.g. when you add a new Please try to group your commits into logical units. If you need to tidy up your branch, you can make use of a
feature that enables color printing, you could name the branch `feature/enable-color-printing`. This makes the log more git feature called an 'interactive rebase' before making a pull request. A small, self-contained change-set is
readable. easier to review, and improves the chance of your code being merged.
Imagine you improve text handling, then you could name your branch `improve/text-handling`. Please also make sure that before creating your PR, your branch is rebased on a recent commit or you merged a recent
commit into your branch. This way you can ensure that your PR is without merge conflicts.
Docstrings Docstrings
^^^^^^^^^^ ^^^^^^^^^^