Skip to content
Permalink
Browse files
Update CONTRIBUTING.rst, add issue and PR templates
Signed-off-by: Chris Warrick <kwpolska@gmail.com>
  • Loading branch information
Kwpolska committed Feb 17, 2017
1 parent 41bf2ae commit 232ae69b352e0c8be51e2d1fe3ddf907f95aa46c
Showing with 46 additions and 20 deletions.
  1. +17 −0 .github/ISSUE_TEMPLATE.md
  2. +9 −0 .github/PULL_REQUEST_TEMPLATE.md
  3. +20 −20 CONTRIBUTING.rst
@@ -0,0 +1,17 @@
<!-- IMPORTANT: Before creating an issue:
* make sure you are using an up-to-date version of Nikola
* search for existing issues that might be related
* provide information about your environment (below) if you are reporting a bug
Nikola v7.6.4, as provided by Debian/Ubuntu, is NOT SUPPORTED.
If you are on this version, you should upgrade: https://getnikola.com/getting-started.html
If you are making a feature request, there is no need to provide environment info.
-->

**Python Version:**

**Nikola Version:**

**Operating System:**

**Description:**
@@ -0,0 +1,9 @@
### Pull Request Checklist

- [ ] I’ve read the [guidelines for contributing](https://github.com/getnikola/nikola/blob/master/CONTRIBUTING.rst).
- [ ] I updated AUTHORS.txt and CHANGES.txt (if the change is non-trivial) and documentation (if applicable).
- [ ] I tested my changes.

### Description

<!-- tell us what your changes are about! -->
@@ -4,11 +4,11 @@ Patch submission guidelines [1]_
Here are some guidelines about how you can contribute to Nikola:

* First, make sure there is an open issue for your change. Perhaps,
if it's a new feature, you probably want to
if its a new feature, you probably want to
`discuss it first <http://groups.google.com/group/nikola-discuss>`_

* **Create a new Git branch specific to your change(s).** For example, if
you're adding a new feature to foo the bars, do something like the
youre adding a new feature to foo the bars, do something like the
following::

$ git checkout master
@@ -26,38 +26,38 @@ Here are some guidelines about how you can contribute to Nikola:

.. admonition:: A corollary:

Please **don't put multiple fixes/features in the same
branch/pull request**! In other words, if you're hacking on new feature X
and find a bugfix that doesn't *require* new feature X, **make a new
Please **dont put multiple fixes/features in the same
branch/pull request**! In other words, if youre hacking on new feature X
and find a bugfix that doesnt *require* new feature X, **make a new
distinct branch and PR** for the bugfix.

* You may want to use the `Tim Pope’s Git commit messages standard
<http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html>`_.
It’s not necessary, but if you are doing something big, we recommend
describing it in the commit message.
* While working, **rebase instead of merging** (if possible). We encourage
using ``git rebase`` instead of ``git merge``. If you are using
``git pull``, please run ``git config pull.rebase true`` to prevent merges
from happening and replace them with rebase goodness. There is also an
“emergency switch” in case rebases fail and you do not know what to do:
``git pull --no-rebase``.
* While working, rebase instead of merging (if possible).
* **Make sure documentation is updated** — at the very least, keep docstrings
current, and if necessary, update the reStructuredText documentation in ``docs/``.
* **Add a changelog entry** at the top of ``CHANGES.txt`` mentioning issue number
and in the correct Features/Bugfixes section. (while creating the new
changelog entry, put it in the version that does not exist (consult
setup.py) or create a new section)
* **Run flake8** for style consistency. Use ``flake8 --ignore=E501 .``
* **Add a CHANGELOG entry** at the *top* of ``CHANGES.txt`` mentioning issue number
and in the correct Features/Bugfixes section. Put it under *New in master*.
Create that section if it does not exist yet. Do not add an entry if the
change is trivial (documentation, typo fixes) or if the change is internal
(not noticeable to end users in any way)
* Add your name to ``AUTHORS.txt`` if the change is non-trivial.
* If you are fixing an issue, **include the issue number in commit** and/or pull
request text (eg. ``fix #1234``) so the issue `is automatically closed
<https://help.github.com/articles/closing-issues-via-commit-messages/>`_.
* **Run flake8** for style consistency. Use ``flake8 nikola``
* **Try writing some tests** if possible — again, following existing tests is
often easiest, and a good way to tell whether the feature you are modifying is
easily testable. You will find instructions in ``tests/README.rst``.
(alternatively you can push and wait for Travis to pick up and test your changes,
but we encourage to run them locally before pushing.)
* Make sure to mention the issue it affects in the description of your pull request,
so it's clear what to test and how to do it.
* There are some quirks to how Nikola's codebase is structured, and to how
some things need to be done [2]_ but don't worry, we'll guide you!
so its clear what to test and how to do it.
* There are some quirks to how Nikolas codebase is structured, and to how
some things need to be done [2]_ but dont worry, well guide you!

.. [1] Very inspired by `fabric's <https://github.com/fabric/fabric/blob/master/CONTRIBUTING.rst>`_ thanks!
.. [1] Very inspired by `fabrics <https://github.com/fabric/fabric/blob/master/CONTRIBUTING.rst>`_ thanks!
.. [2] For example, logging, or always making sure directories are created using ``utils.makedirs()``

0 comments on commit 232ae69

Please sign in to comment.