CONTRIBUTING states about maintainer guidelines

[benoitbryon]

In order to ease maintenance of the project, as a maintainer, I want to share the release and merging guidelines.

[benoitbryon]

What I do at the moment about merging:

• make sure the PR passes the tests, i.e. previous features are not broken
• in the review:
  • tests matter
  • documentation and demo project matter
  • docstrings matter (I'm quite a PEP-287 psycho).
  • the PR should focus on a single thing
  • optimizations and refactoring are good, but they should be related to the scope of the PR. Avoid collateral changes whenever possible.
  • no CHANGELOG in the review.
  • no matter how many commits in the topic branch, i.e. no need to alter topic branch's history.
• merge via the command line:
  • do not use github's UI
  • git merge --no-ff --no-commit TOPIC-BRANCH
  • update CHANGELOG
  • optionally correct minor typos or minor refactoring => things that cannot break the tests and that you don't want the contributor to bother with
  • commit using a nice message. Usually, the CHANGELOG is a good inspiration. Add some Closes #XXX at the end of the commit message. Think about git log --first-parent when writing the message : this is the one that summarizes changes introduced by the pull-request. Things like "Merge topic-branch" do not help!
  • push master (it closes the PR and issue)
  • do not delete the topic branch on github (since they are prefixed by issue number).

[benoitbryon]

What I do at the moment about releasing:

• priorize issues into special milestones "soon", "later" and "maybe one day"
• create a new milestone as soon as I know I want to make a release, and move issues in the milestone
• merge only issues that are in a version milestone (i.e. not in "soon")
• release often. Releases may have a single feature/bugfix.
• release on PyPI
• build version on readthedocs and change default version (redirect for https://django-docusign.readthedocs.org/)