Skip to content

Additions to contrib guide PR #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
drammock merged 3 commits into from
Nov 23, 2021
Merged

Additions to contrib guide PR #6

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
aa03920
make line about fork clearer
britta-wstnr Nov 23, 2021
47bc976
minimize white space and improve wording
britta-wstnr Nov 23, 2021
f2e75ae
improve some wording
britta-wstnr Nov 23, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 9 additions & 13 deletions doc/install/contributing.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ Overview of contribution process
Changes to MNE-Python are typically made by `forking`_ the MNE-Python
repository, making changes to your fork (usually by `cloning`_ it to your
personal computer, making the changes locally, and then `pushing`_ the local
changes up to your fork), and finally creating a `pull request`_ to incorporate
changes up to your fork on GitHub), and finally creating a `pull request`_ to incorporate
your changes back into the shared "upstream" version of the codebase.

In general you'll be working with three different copies of the MNE-Python
Expand Down Expand Up @@ -357,7 +357,7 @@ related changes that are grouped together based on common goals (so that it's
easier for their colleagues to understand and review the changes). For example,
you might want to group all the code changes together in one commit, put new
unit tests in another commit, and changes to the documentation in a third
commit. Git makes this easy(ish) with something called the `stage`_ (or
commit. Git makes this possible with something called the `stage`_ (or
*staging area*). After you've made some changes to the codebase, you'll have
what git calls "unstaged changes", which will show up with the `status`_
command::
Expand Down Expand Up @@ -594,7 +594,7 @@ almost every PR).

Lastly, make sure that your name is included in the list of authors in
:file:`doc/changes/names.inc`, otherwise the documentation build will fail.
To add an author name, simply append a line with the following pattern (note
To add an author name, append a line with the following pattern (note
how the syntax is different from that used in the changelog):

.. code-block:: rst
Expand All @@ -618,7 +618,7 @@ where ``0000`` must be replaced with the respective GitHub pull request (PR)
number. Mind the Oxford comma in the case of multiple contributors.

Sometimes, changes that shall appear as a single changelog entry are spread out
across multiple PRs. In this case, simply name all relevant PRs, separated by
across multiple PRs. In this case, name all relevant PRs, separated by
commas:

.. code-block:: rst
Expand Down Expand Up @@ -828,22 +828,18 @@ to both visualization functions and tutorials/examples.
Running the test suite
~~~~~~~~~~~~~~~~~~~~~~

Running the full test suite is as simple as running ::

$ make test

.. sidebar:: pytest flags

The ``-x`` flag exits the pytest run as soon as the first test fails; this
can save some time if you are running an entire file's or module's worth of
tests instead of selecting just a single test as shown here.
The ``-x`` flag exits the pytest run when any test fails; this can speed
up debugging when running all tests in a file or module.

The ``--pdb`` flag will automatically start the python debugger upon test
failure.

from the ``mne-python`` root folder. Testing the entire module can be quite
The full test suite can be run by calling ``make test`` from the
``mne-python`` root folder. Testing the entire module can be quite
slow, however, so to run individual tests while working on a new feature, you
can run, e.g.::
can run the following line::

$ pytest mne/tests/test_evoked.py::test_io_evoked --verbose

Expand Down