Update/expand Contributing.rst regarding pull requests

develop
lethosor 2020-08-06 02:30:17 -04:00
parent 7c2af344a1
commit bdb9433822
No known key found for this signature in database
GPG Key ID: 76A269552F4F58C1
1 changed files with 36 additions and 9 deletions

@ -13,7 +13,7 @@ Contributing Code
================= =================
Several things should be kept in mind when contributing code to DFHack. Several things should be kept in mind when contributing code to DFHack.
Code Format Code format
----------- -----------
* Four space indents for C++. Never use tabs for indentation in any language. * Four space indents for C++. Never use tabs for indentation in any language.
* LF (Unix style) line terminators * LF (Unix style) line terminators
@ -26,18 +26,45 @@ Code Format
* #includes should be sorted. C++ libraries first, then dfhack modules, then df structures, * #includes should be sorted. C++ libraries first, then dfhack modules, then df structures,
then local includes. Within each category they should be sorted alphabetically. then local includes. Within each category they should be sorted alphabetically.
How to get new code into DFHack Pull request guidelines
-----------------------
* Pull requests should be based on (and submitted to) the default branch of the
relevant repo, which is the branch you see when you access the repo on GitHub
or clone the repo without specifying a branch. As of 0.47.04-r1, this is
``develop`` for the main DFHack repo and ``master`` for other repos.
* Use a new branch for each feature or bugfix so that your changes can be merged
independently (i.e. not the ``master`` or ``develop`` branch of your fork).
* An exception: for a collection of small miscellaneous changes (e.g.
structures research), one branch instead of many small branches is fine. It
is still preferred that this branch be dedicated to this purpose, i.e. not
``master`` or ``develop``. Your pull request may be merged at any point
unless you indicate that it isn't ready (see below), but you can continue to
push to the same branch and open new pull requests as needed.
* Try to keep pull requests relatively small so that they are easier to review
and merge.
* If you expect to make a large number of related additions or changes (e.g.
adding a large new plugin), multiple PRs are preferred, as they allow more
frequent (and easier) feedback. If development of this feature is expected
to take a while, we may create a dedicated branch to merge your pull
requests into instead of the repo's default branch.
* If you plan to make additional changes to your pull request in the near
future, or if it isn't quite ready to be merged, mark it as a
`draft pull request <https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests>`_
or add "WIP" to the title. Otherwise, your pull request may be reviewed and/or
merged prematurely.
General contribution guidelines
------------------------------- -------------------------------
* Submit pull requests to the ``develop`` branch, not the ``master`` branch. * If convenient, compile on multiple platforms when changing anything that
(The ``master`` branch always points at the most recent release) compiles. Our CI should catch anything that fails to build, but checking in
* Use a new branch for each feature or bugfix so that your changes can be merged independently advance can be faster.
(i.e. not the master or develop branch of your fork).
* If possible, compile on multiple platforms when changing anything that compiles
* It must pass CI - run ``python travis/all.py`` to check this.
* Update documentation when applicable - see `docs-standards` for details. * Update documentation when applicable - see `docs-standards` for details.
* Update ``changelog.txt`` and ``docs/Authors.rst`` when applicable. See * Update ``changelog.txt`` and ``docs/Authors.rst`` when applicable. See
`build-changelog` for more information on the changelog format. `build-changelog` for more information on the changelog format.
* Create a GitHub pull request once finished
* Submit ideas and bug reports as :issue:`issues on GitHub <>`. * Submit ideas and bug reports as :issue:`issues on GitHub <>`.
Posts in the forum thread can easily get missed or forgotten. Posts in the forum thread can easily get missed or forgotten.
* Work on :issue:`reported problems <?q=is:open+-label:idea>` * Work on :issue:`reported problems <?q=is:open+-label:idea>`