Move contribution-related information from Compile.rst to Contributing.rst

docs/Compile.rst

@@ -88,21 +88,9 @@ assistance.
 
 
 Contributing to DFHack
-======================
-To contribute to DFHack on GitHub, you will need a GitHub account. Only some
-DFHack developers can push directly to the DFHack repositories; we recommend
-making a fork of whatever repos you are interested in contributing to, making
-changes there, and submitting pull requests.  `GitHub's pull request tutorial
-<https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests>`_
-is a good resource for getting started with pull requests (some things to note:
-our work mainly happens on the ``develop`` branch, and you will need to use
-your own fork, assuming that you don't have write access to the DFHack repos).
-
-Most development-related discussion happens on IRC or in individual GitHub
-issues and pull requests, but there are also other ways to reach out - see
-`support` for details.
-
-For more details on contributing to DFHack, including pull requests, code
+----------------------
+
+For details on contributing to DFHack, including pull requests, code
 format, and more, please see `contributing-code`.
 
 

docs/Contributing.rst

@@ -11,7 +11,30 @@ How to contribute to DFHack
 
 Contributing Code
 =================
-Several things should be kept in mind when contributing code to DFHack.
+
+DFHack's source code is hosted on GitHub. To obtain the code, you do not need an
+account - see the `compilation instructions <compile-how-to-get-the-code>` for
+details. However, to contribute code to DFHack, you will need a GitHub account
+to submit pull requests. DFHack consists of several repositories, so you will
+need to fork the repository (or repositories) containing the code you wish to
+modify. GitHub has several documentation pages on these topics, including:
+
+* `An overview of forks
+  <https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/working-with-forks>`__
+* `Proposing changes with pull requests
+  <https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests>`__
+  (note: see `contributing-pr-guidelines` for some DFHack-specific information)
+
+In general, if you are not sure where or how to make a change, or would like
+advice before attempting to make a change, please see `support` for ways to
+contact maintainers - DFHack-specific channels such as IRC or Bay12 are
+preferred. If you are interested in addressing an issue reported on the
+:issue:`issue tracker <>`, you can start a discussion there if you prefer.
+
+The sections below cover some guidelines that contributions should follow:
+
+.. contents::
+  :local:
 
 Code format
 -----------
@@ -23,15 +46,21 @@ Code format
 
   * Opening and closing braces on their own lines or opening brace at the end of the previous line
   * Braces placed at original indent level if on their own lines
-  * #includes should be sorted. C++ libraries first, then dfhack modules, then df structures,
+  * ``#include`` directives should be sorted: C++ libraries first, then DFHack modules, then ``df/`` headers,
     then local includes. Within each category they should be sorted alphabetically.
 
+.. _contributing-pr-guidelines:
+
 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.
+* We often leave feedback as comments on pull requests, so be sure that you have
+  `notifications turned on <https://github.com/settings/notifications>`__ or
+  that you check back for feedback periodically.
 * 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).
 
@@ -61,7 +90,7 @@ General contribution guidelines
 -------------------------------
 * If convenient, compile on multiple platforms when changing anything that
   compiles. Our CI should catch anything that fails to build, but checking in
-  advance can be faster.
+  advance can sometimes let you know of any issues sooner.
 * Update documentation when applicable - see `docs-standards` for details.
 * Update ``changelog.txt`` and ``docs/Authors.rst`` when applicable. See
   `build-changelog` for more information on the changelog format.