1. Jon Waltman
  2. sphinx-devguide


Jon Waltman  committed a5009a3

devguide: Add guidelines for core developers

  • Participants
  • Parent commits a246415
  • Branches default

Comments (0)

Files changed (1)

File doc/devguide.rst

View file
  • Ignore whitespace
 The recommended way for new contributors to submit code to Sphinx is to fork
 the Mercurial repository on BitBucket and then submit a pull request after
-committing the changes.
-Developers with write access to the main repository are also encouraged to
-create pull requests for non-trivial changes so they may be reviewed before
-being committed.
+committing the changes.  The pull request will then need to be approved by one
+of the core developers before it is merged into the main repository.
 Getting Started
 These are the basic steps needed to start developing on Sphinx.
-.. todo::
-   Recommend using named branches?
 #. Create an account on BitBucket.
 #. Fork the main Sphinx repository (`birkenfeld/sphinx
 #. Submit a pull request from your repository to ``birkenfeld/sphinx`` using
    the BitBucket interface.
-   The pull request will be reviewed and if approved, merged by one of the
-   Sphinx developers.
+#. Wait for a core developer to review your changes.
+Core Developers
+The core developers of Sphinx have write access to the main repository.  They
+can commit changes, accept/reject pull requests, and manage items on the issue
+You do not need to be a core developer or have write access to be involved in
+the development of Sphinx.  You can submit patches or create pull requests
+from forked repositories and have a core developer add the changes for you.
+The following are some general guidelines for core developers:
+* Questionable or extensive changes should be submitted as a pull request
+  instead of being committed directly to the main repository.  The pull
+  request should be reviewed by another core developer before it is merged.
+* Trivial changes can be committed directly but be sure to keep the repository
+  in a good working state and that all tests pass before pushing your changes.
+* When committing code written by someone else, please attribute the original
+  author in the commit message and any relevant :file:`CHANGES` entry.
+* Using Mercurial named branches other than ``default`` and ``stable`` is not
+  encouraged.
 Coding Guide
 * Use the included :program:`utils/check_sources.py` script to check for
   common formatting issues (trailing whitespace, lengthy lines, etc).
+* Add appropriate unit tests.
 Debugging Tips