Welcome to the FMRIPREP repository! We're excited you're here and want to contribute.
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!
Before you start you'll need to set up a free GitHub account and sign in. Here are some instructions.
The current list of labels are here and include:
-
These issues contain a task that a member of the team has determined we need additional help with.
If you feel that you can contribute to one of these issues, we especially encourage you to do so!
-
These issues point to problems in the project.
If you find new a bug, please give as much detail as possible in your issue, including steps to recreate the error. If you experience the same bug as one already listed, please add any additional information that you have as a comment.
-
These issues are asking for new features to be added to the project.
Please try to make sure that your requested feature is distinct from any others that have already been requested or implemented. If you find one that's similar but there are subtle differences please reference the other request in your issue.
We appreciate all contributions to FMRIPREP, but those accepted fastest will follow a workflow similar to the following:
1. Comment on an existing issue or open a new issue referencing your addition.
This allows other members of the FMRIPREP development team to confirm that you aren't overlapping with work that's currently underway and that everyone is on the same page with the goal of the work you're going to carry out.
This blog is a nice explanation of why putting this work in up front is so useful to everyone involved.
2. Fork the FMRIPREP repository to your profile.
This is now your own unique copy of FMRIPREP. Changes here won't effect anyone else's work, so it's a safe space to explore edits to the code!
Make sure to keep your fork up to date with the master repository.
3. Make the changes you've discussed, following the FMRIPREP coding style guide.
Try to keep the changes focused. If you feel tempted to "branch out" then please make a new branch. It can also be helpful to test your changes locally, using an FMRIPREP development environment.
4. Submit a pull request.
A member of the development team will review your changes to confirm that they can be merged into the main codebase.
Whenever possible, instances of Nodes and Workflows should use the same names as the variables they are assigned to. This makes it easier to relate the content of the working directory to the code that generated it when debugging.
Workflow variables should end in _wf to indicate that they refer to Workflows
and not Nodes.
For instance, a workflow whose basename is myworkflow might be defined as
follows:
from nipype.pipeline import engine as pe
myworkflow_wf = pe.Workflow(name='myworkflow_wf')If a workflow is generated by a function, the name of the function should take
the form init_<basename>_wf:
def init_myworkflow_wf(name='myworkflow_wf):
workflow = pe.Workflow(name=name)
...
return workflow
myworkflow_wf = init_workflow_wf(name='myworkflow_wf')If multiple instances of the same workflow might be instantiated in the same namespace, the workflow names and variables should include either a numeric identifier or a one-word description, such as:
myworkflow0_wf = init_workflow_wf(name='myworkflow0_wf')
myworkflow1_wf = init_workflow_wf(name='myworkflow1_wf')
# or
myworkflow_lh_wf = init_workflow_wf(name='myworkflow_lh_wf')
myworkflow_rh_wf = init_workflow_wf(name='myworkflow_rh_wf')We welcome and recognize all contributions from documentation to testing to code development. You can see a list of current contributors in our zenodo file. If you are new to the project, don't forget to add your name and affiliation there!
You're awesome. 👋😃
— Based on contributing guidelines from the STEMMRoleModels project.