You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+30-19Lines changed: 30 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,9 @@ Welcome to the Nipype repository! We're excited you're here and want to contribu
4
4
5
5
These guidelines are designed to make it as easy as possible to get involved. If you have any questions that aren't discussed below, please let us know by opening an [issue][link_issues]!
6
6
7
-
Before you start you'll need to set up a free [GitHub][link_github] account and sign in. Here are some [instructions][link_signupinstructions].
7
+
Before you start you'll need to set up a free [GitHub][link_github] account and sign in, here are some [instructions][link_signupinstructions].
8
+
If you are not familiar with version control system and Git,
9
+
you will find introduction and links to tutorials [here](http://www.reproducibleimaging.org/module-reproducible-basics/02-vcs/).
8
10
9
11
Already know what you're looking for in this guide? Jump to the following sections:
10
12
*[Understanding issue labels](#issue-labels)
@@ -47,30 +49,35 @@ This allows other members of the Nipype development team to confirm that you are
47
49
48
50
**2. [Fork][link_fork] the [Nipype repository][link_nipype] to your profile.**
49
51
50
-
This is now your own unique copy of Nipype.
52
+
This is now your own unique copy of Nipype repository.
51
53
Changes here won't affect anyone else's work, so it's a safe space to explore edits to the code!
52
54
53
-
Make sure to [keep your fork up to date][link_updateupstreamwiki] with the master repository.
55
+
You can clone your Nipype repository in order to create a local copy of the code on your machine.
56
+
In your local Nipype directory, run `pip install -e .[dev]`.
57
+
This will add your version of nipype to your local python environment and
58
+
install dependencies needed for development.
54
59
55
-
**3. Make the changes you've discussed.**
60
+
Make sure to [keep your fork up to date][link_updateupstreamwiki] with the original Nipype repository.
56
61
57
-
If you're adding a new tool from an existing neuroimaging toolkit (e.g., 3dDeconvolve from AFNI), check out the [guide for adding new interfaces to Nipype][link_new_interfaces].
62
+
**3. Make the changes you've discussed.**
58
63
59
-
To confirm that your changes worked as intended, [clone your fork][link_cloning] to create a local directory.
60
-
In this local directory, run `python setup.py develop`.
61
-
This will add your version of nipype to your local python environment.
64
+
If you're adding a new tool from an existing neuroimaging toolkit (e.g., 3dDeconvolve from AFNI),
65
+
check out the [guide for adding new interfaces to Nipype][link_new_interfaces].
62
66
63
-
Then, in this local nipype directory, run `make check-before-commit`. If you get no errors, you're ready to submit your changes!
67
+
When you are working on your changes, you should test frequently if you are not breaking the existing code,
68
+
more on testing you will find [the testing section of Nipype documentation](http://nipype.readthedocs.io/en/latest/devel/testing_nipype.html).
64
69
65
-
**4. Submit a [pull request][link_pullrequest].**
70
+
It's a good practice to create a new branch of your Nipype repository for a new set of changes.
66
71
67
-
Submit a new pull request for your changes, using the tags outlined in the [tagging pull requests section](#tagging-pull-requests).
72
+
Before pushing your changes to GitHub run `make check-before-commit`, this will remove trailing spaces, create new auto tests,
73
+
test entire package and build the documentation.
74
+
If you get no errors, you're ready to submit your changes!
68
75
69
-
A member of the development team will review your changes to confirm that they can be merged into the main codebase.
76
+
**4. Submit a [pull request][link_pullrequest].**
70
77
71
-
## Tagging Pull Requests
78
+
A new pull request for your changes should be created from your GitHub account.
72
79
73
-
Pull requests should be submitted early and often! When opening a pull request, please use one of the following prefixes:
80
+
When opening a pull request, please use one of the following prefixes:
74
81
75
82
76
83
***[ENH]** for enhancements
@@ -81,11 +88,14 @@ Pull requests should be submitted early and often! When opening a pull request,
81
88
***[REF]** for refactoring existing code
82
89
83
90
<br>
84
-
85
-
If, when you submit, your pull request is not yet ready to be merged, please also include the **[WIP]** prefix. This tells the development team that your pull request is a "work-in-progress", and that you plan to continue working on it.
91
+
Pull requests should be submitted early and often (please don't mix too many unrelated changes within one PR)!
92
+
If your pull request is not yet ready to be merged, please also include the **[WIP]** prefix (you can remove it once your PR is ready to be merged).
93
+
This tells the development team that your pull request is a "work-in-progress", and that you plan to continue working on it.
86
94
87
95
Review and discussion on new code can begin well before the work is complete, and the more discussion the better!
88
-
In the worst case scenario, if the development team decides to pursue a different path than you've outlined, they'll close the pull request. That's really not so bad! :smile:
96
+
This provides the opportunity to check with the development team the path you've outlined.
97
+
98
+
One your PR is ready a member of the development team will review your changes to confirm that they can be merged into the main codebase.
89
99
90
100
## Notes for New Code
91
101
@@ -98,8 +108,9 @@ Do not log this, as it creates redundant/confusing logs.
98
108
99
109
#### Testing
100
110
New code should be tested, whenever feasible.
101
-
Bug fixes should include regression tests, and any new behavior should at least get minimal exercise.
102
-
If you're not sure what this means for your code, ask!
111
+
Bug fixes should include an example that exposes the issue.
112
+
Any new features should have tests that show at least a minimal example.
113
+
If you're not sure what this means for your code, please ask in your pull request.
0 commit comments