SciPy modules: maintainers & status
===================================

This document gives an overview of who the maintainers of modules within Scipy
are, what their responsibilities are and what (in their view) are the current
state and possible future directions for the modules.

Maintainers will aim to:

    - Respond to tickets, PRs and mailing list questions within a reasonable
      time frame.
    - Keep an overview of the current status and future directions of the
      module up to date in this document.
    - Indicate whether PRs are ready to be merged or not, and try to resolve
      any differences of opinion on merging code if necessary.

The above are listed as "aims" on purpose.  All developers work on Scipy in
their free time and therefore, while we intend to do the best we can in the
limited time available for our open source work, it is possible that we don't
have the bandwidth to respond to every single issue.  The goal is to have more
than one maintainer for each module, in which case this should rarely be an
issue.


Some unwritten rules of SciPy development, written down
-------------------------------------------------------

Any significant decisions on adding (or not adding) new features, breaking
backwards compatibility or making other significant changes to the codebase
should be made on the scipy-dev mailing list after a discussion (preferably
with full consensus).

Any non-trivial change (where trivial means a typo, or a one-liner maintenance
commit) has to go in through a pull request (PR).  It has to be reviewed by
another developer.  In case review doesn't happen quickly enough and it is
important that the PR is merged quickly, the submitter of the PR should send a
message to mailing list saying he/she intends to merge that PR without review
at time X for reason Y unless someone reviews it before then.

Changes and new additions should be tested. Untested code is broken code.

Who gets commit rights is decided by the core development team; changes in
commit rights will then be announced on the scipy-dev mailing list.

Who the core development team is comprised of is a little fuzzy - there are
quite a few people who do have commit rights and would like to keep them but
are no longer active.  To get an idea, look at the output of::

    $ git shortlog --grep="Merge pull request" -a -c -s <current_release_minus_2>..upstream/master|sort -n

and apply some common sense to it (and don't forget people who are still active
but for some reason never merge PRs).


Guidelines for committers
-------------------------

- When merging contributions, a committer is responsible for ensuring that
  those meet the requirements outlined in `HACKING.txt`_. Also check that new
  features and backwards compatibility breaks were discussed on the scipy-dev
  mailing list.
- New code goes in via a pull request.
- Merge new code with the green button.  In case of merge conflicts, ask the PR
  submitter to rebase (may require providing some git instructions).
- Backports and trivial additions to finish a PR (really trivial, like a typo
  or PEP8 fix) can be pushed directly.
- For PRs that add new features or are in some way complex, wait at least a day
  before merging it. That way, others get a chance to comment before the code
  goes in.
- Squashing commits or cleaning up commit messages of a PR that you consider
  too messy is OK. Make sure though to retain the original author name when
  doing this.
- Make sure that the labels and milestone on a merged PR are set correctly.
- When you want to reject a PR: if it's very obvious you can just close it and
  explain why, if not obvious then it's a good idea to first explain why you
  think the PR is not suitable for inclusion in Scipy and then let a second
  committer comment or close.


FAQ
---
Q: How can I keep track of pull requests (PRs) and comments on Github?

A: Only people listed as committers get email notifications for new PRs. And
they don't get it for comments unless they have commented themselves on that PR
before.  Github does have a "Watch" feature that can be used to monitor
activity on the repo.


Q: How is this list of maintainers maintained, and how does one become a
maintainer?

A: This list is kept in the Scipy git repository.  Changes to it should be made
by sending a pull request.  For major changes it is expected that these are
discussed on the scipy-dev mailing list first.
To become a maintainer, someone should have an understanding of the code, have
contributed at least a few features or bug fixes to that code, and express an
interest in being a maintainer.


Q: What is the relationship between the list of maintainers and the list of
people with commit rights?

A: Due to the distributed nature of git, it is easily possible to be a
maintainer without having commit rights.  It is also very well possible to be a
committer without being a maintainer for a specific module.  In practice
however, there will naturally be a large overlap between the group of
maintainers and committers.


Modules
-------

scipy.cluster
`````````````

Maintainers:

    - David Warde-Farley

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.cluster>`__


scipy.constants
```````````````

Maintainers:

    - Vincent Davis

Status:

The constants module is up-to-date (NIST 2010 CODATA) and has no known bugs.

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.constants>`__


scipy.fftpack
`````````````

Maintainers:

    - David Cournapeau

Status:

The fftpack module is stable, with few known bugs and little development
happening currently.

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.fftpack>`__


scipy.integrate
```````````````

Maintainers:

    - Pauli Virtanen

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.integrate>`__


scipy.interpolate
`````````````````

Maintainers:

    - Evgeni Burovski
    - Pauli Virtanen

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.interpolate>`__


scipy.io
````````

Maintainers:

    - Matthew Brett (io.matlab)
    - Thomas Robitaille (io.idl)
    - David Cournapeau (io.harwell_boeing)
    -                  (io.arff)
    -                  (io.netcdf)
    -                  (io.wavfile)

Status:

The io.idl module is stable and has no known bugs. It will need to be updated
as needed if the IDL file format evolves, or if there are any bugs discovered.
There is no real need for any new features.

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.io>`__

scipy.linalg
````````````

Maintainers:

    - Pauli Virtanen
    - Alex Griffing

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.linalg>`__


scipy.misc
``````````

Maintainers:

    - Ralf Gommers

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.misc>`__


scipy.ndimage
`````````````

Maintainers:

    - Stefan van der Walt
    - Thouis (Ray) Jones

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.ndimage>`__


scipy.odr
`````````

Maintainers:

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.odr>`__


scipy.optimize
``````````````

Maintainers:

    - Denis Laxalde
    - Pauli Virtanen

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.optimize>`__


scipy.signal
````````````

Maintainers:

    - Ralf Gommers
    - Eric Moore

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.signal>`__


scipy.sparse
````````````

Maintainers:

    - Pauli Virtanen
    - Alex Griffing

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.sparse>`__


scipy.sparse.csgraph
````````````````````

Maintainers:

    - Jake Vanderplas

Status:

`Open tickets
<https://github.com/scipy/scipy/issues?labels=scipy.sparse.csgraph>`__


scipy.sparse.linalg
```````````````````

Maintainers:

    - Pauli Virtanen
    - Alex Griffing
    - Jake Vanderplas

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.sparse.linalg>`__


scipy.spatial
`````````````

Maintainers:

    - Pauli Virtanen (Qhull wrappers)

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.spatial>`__


scipy.special
`````````````

Maintainers:

    - Pauli Virtanen

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.special>`__


scipy.stats
```````````

Maintainers:

    - Josef Perktold
    - Ralf Gommers
    - Evgeni Burovski

Status:

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.stats>`__


scipy.weave
```````````

Status:

Weave is deprecated and will be removed before the 1.0 release.  It is now
packaged as a separate (unmaintained) package: https://github.com/scipy/weave. 
For new code, it is recommended to use Cython instead of Weave.

`Open tickets <https://github.com/scipy/scipy/issues?labels=scipy.weave>`__



Infrastructure and web presence
-------------------------------

Websites
````````

Maintainers:

    - Pauli Virtanen
    - Ralf Gommers
    - Thomas Kluyver
    - Scott Sinclair

Status:

The scipy.org site has been redesigned and is currently in good shape.
It is hosted on a server maintained by Enthought.  Issues and pull requests 
should be opened or sent to https://github.com/scipy/scipy.org


Continuous Integration server
`````````````````````````````

TravisCI is the only CI server used at the moment; it tests with all Python
versions on Ubuntu.


Build tools
```````````

Maintainers:

    - Ralf Gommers (Bento support)
    - David Cournapeau
    - Pauli Virtanen


Other
`````

    - Release manager: rotating role, Pauli Virtanen for 0.15.x
    - Planet SciPy: Gael Varoquaux


.. _HACKING.txt: https://github.com/scipy/scipy/blob/master/HACKING.rst.txt
