Merge pull request #7590 from astrofrog/contributing-performance

Added section in CONTRIBUTING.md about performance benchmarks
astropy · Jun 25, 2018 · 51c619e · 51c619e
2 parents 91fc183 + 901fa45
commit 51c619e
Showing 1 changed file with 43 additions and 38 deletions.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -4,26 +4,27 @@ Contributing to Astropy
 Reporting Issues
 ----------------
 
-When opening an issue to report a problem, please try and provide a minimal
-code example that reproduces the issue, and also include details of the
-operating system, and the Python, Numpy, and Astropy versions you are using.
+When opening an issue to report a problem, please try and provide a minimal code
+example that reproduces the issue, and also include details of the operating
+system, and the Python, Numpy, and Astropy versions you are using.
 
 Contributing code
 -----------------
 
 So you're interested in contributing code to Astropy? Excellent!
 
 Most contributions to Astropy are done via pull requests from GitHub users'
-forks of the [astropy repository](https://github.com/astropy/astropy). If 
-you're new to this style of development, you'll want to read over our [development workflow](http://docs.astropy.org/en/latest/development/workflow/development_workflow.html).
+forks of the [astropy repository](https://github.com/astropy/astropy). If you're
+new to this style of development, you'll want to read over our
+[development workflow](http://docs.astropy.org/en/latest/development/workflow/development_workflow.html).
 
-You may also/instead be interested in contributing to to an 
-[astropy affiliated package](http://www.astropy.org/affiliated/). 
+You may also/instead be interested in contributing to to an
+[astropy affiliated package](http://www.astropy.org/affiliated/).
 Affiliated packages are astronomy-related software packages that are not a part
 of the astropy core package, but build on it for more specialized applications
 and follow the astropy guidelines for reuse, interoperability, and interfacing.
-Each affiliated package has its own developers/maintainers and its own 
-specific guidelines for contributions, so be sure to read their docs. 
+Each affiliated package has its own developers/maintainers and its own specific
+guidelines for contributions, so be sure to read their docs.
 
 Once you open a pull request (which should be opened against the ``master``
 branch, not against any of the other branches), please make sure that you
@@ -44,28 +45,32 @@ include the following:
   detailed [documentation guidelines](http://docs.astropy.org/en/latest/development/docguide.html)
   to help you out.
 
-- **Changelog entry**: whether you are fixing a bug or adding new
-  functionality, you should add an entry to the ``CHANGES.rst`` file that
-  includes the PR number and if possible the issue number (if you are
-  opening a pull request you may not know this yet, but you can add it once
-  the pull request is open). If you're not sure where to put the changelog
-  entry, wait at least until a maintainer has reviewed your PR and assigned
-  it to a milestone.
+  **Performance improvements**: if you are making changes that impact Astropy
+  performance, consider adding a performance benchmark in the
+  [astropy-benchmarks](https://github.com/astropy/astropy-benchmarks)
+  repository. You can find out more about how to do this
+  [in the README for that repository](https://github.com/astropy/astropy-benchmarks#contributing-a-benchmark).
+
+- **Changelog entry**: whether you are fixing a bug or adding new functionality,
+  you should add an entry to the ``CHANGES.rst`` file that includes the PR
+  number and if possible the issue number (if you are opening a pull request you
+  may not know this yet, but you can add it once the pull request is open). If
+  you're not sure where to put the changelog entry, wait at least until a
+  maintainer has reviewed your PR and assigned it to a milestone.
 
   You do not need to include a changelog entry for fixes to bugs introduced in
-  the developer version and therefore are not present in the stable releases.
-  In general you do not need to include a changelog entry for minor
-  documentation or test updates.  Only user-visible changes (new features/API
-  changes, fixed issues) need to be mentioned.  If in doubt ask the core
-  maintainer reviewing your changes.
+  the developer version and therefore are not present in the stable releases. In
+  general you do not need to include a changelog entry for minor documentation
+  or test updates.  Only user-visible changes (new features/API changes, fixed
+  issues) need to be mentioned.  If in doubt ask the core maintainer reviewing
+  your changes.
 
 Other Tips
 ----------
 
-- To prevent the automated tests from running you can add ``[ci
-  skip]`` to your commit message. This is useful if your PR is a work
-  in progress and you are not yet ready for the tests to run.  For
-  example:
+- To prevent the automated tests from running you can add ``[ci skip]`` to your
+  commit message. This is useful if your PR is a work in progress and you are
+  not yet ready for the tests to run.  For example:
 
       $ git commit -m "WIP widget [ci skip]"
 
@@ -74,30 +79,29 @@ Other Tips
 
         $ git commit --amend
 
-- To skip only the AppVeyor (Windows) CI builds you can use ``[skip
-  appveyor]``, and to skip testing on Travis CI use ``[skip travis]``.
+- To skip only the AppVeyor (Windows) CI builds you can use ``[skip appveyor]``,
+  and to skip testing on Travis CI use ``[skip travis]``.
 
 - If your commit makes substantial changes to the documentation, but no code
   changes, the you can use ``[docs only]``, that will skip all but the
   documentation building jobs on Travis.
 
-- When contributing trivial documentation fixes (i.e. fixes to typos,
-  spelling, grammar) that do not contain any special markup and are
-  not associated with code changes, please include the string ``[docs
-  only]`` in your commit message.
+- When contributing trivial documentation fixes (i.e. fixes to typos, spelling,
+  grammar) that do not contain any special markup and are not associated with
+  code changes, please include the string ``[docs only]`` in your commit
+  message.
 
       $ git commit -m "Fixed typo [docs only]"
 
 Checklist for Contributed Code
 ------------------------------
 
 A pull request for a new feature will be reviewed to see if it meets the
-following requirements.  For any pull request, an astropy maintainer can
-help to make sure that the pull request meets the requirements for inclusion
-in the package.
+following requirements.  For any pull request, an astropy maintainer can help to
+make sure that the pull request meets the requirements for inclusion in the
+package.
 
-**Scientific Quality**
-(when applicable)
+**Scientific Quality** (when applicable)
   * Is the submission relevant to astronomy?
   * Are references included to the origin source for the algorithm?
   * Does the code perform as expected?
@@ -125,7 +129,8 @@ in the package.
 
 **Documentation**
   * Are the [documentation guidelines](http://docs.astropy.org/en/latest/development/docguide.html) followed?
-  * Is there a [docstring](http://docs.astropy.org/en/latest/development/docrules.html) in the function describing:
+  * Is there a [docstring](http://docs.astropy.org/en/latest/development/docrules.html)
+    in the function describing:
     * What the code does?
     * The format of the inputs of the function?
     * The format of the outputs of the function?
@@ -139,7 +144,7 @@ in the package.
   * Is the astropy license included at the top of the file?
   * Are there any conflicts with this code and existing codes?
 
-**astropy requirements**
+**Astropy requirements**
   * Do all the Travis CI, AppVeyor, and CircleCI tests pass?
   * If applicable, has an entry been added into the changelog?
   * Can you checkout the pull request and repeat the examples and tests?