Contributing Guidelines¶
Welcome to theNiPreps project!We're excited you're here and want to contribute.
Imposter's syndrome disclaimer
Imposter's syndrome disclaimer1: We want your help. No, really.
There may be a little voice inside your head that is telling you thatyou're not ready to be an open-source contributor; that your skillsaren't nearly good enough to contribute. What could you possibly offer aproject like this one?
We assure you - the little voice in your head is wrong. If you canwrite code at all, you can contribute code to open-source. Contributingto open-source projects is a fantastic way to advance one's codingskills. Writing perfect code isn't the measure of a good developer (thatwould disqualify all of us!); it's trying to create something, makingmistakes, and learning from those mistakes. That's how we all improve,and we are happy to help others learn.
Being an open-source contributor doesn't just mean writing code, either.You can help out by writing documentation, tests, or even givingfeedback about the project (and yes - that includes giving feedbackabout the contribution process). Some of these contributions may be themost valuable to the project as a whole, because you're coming to theproject with fresh eyes, so you can see the errors and assumptions thatseasoned contributors have glossed over.
Driving principles¶
NiPreps are built around three overarching principles:
- Robustness - The pipeline adapts the preprocessing steps depending on the input dataset and should provide results as good as possible independently of scanner make, scanning parameters or presence of additional correction scans (such as fieldmaps).
- Ease of use - Thanks to dependence on the BIDS standard, manual parameter input is reduced to a minimum, allowing the pipeline to run in an automatic fashion.
- "Glass box" philosophy - Automation should not mean that one should not visually inspect the results or understand the methods. Thus,NiPreps provides visual reports for each subject, detailing the accuracy of the most important processing steps. This, combined with the documentation, can help researchers to understand the process and decide which subjects should be kept for the group level analysis.
These principles distill some design and organizational foundations:
- NiPreps only and fully support BIDS and BIDS-Derivatives for the input and output data.
- NiPreps are packaged as a fully-compliantBIDS-Apps, not just in its user interface, but also in the continuous integration, testing, and delivery.
- The scope ofNiPreps is strictly limited to preprocessing tasks.
- NiPreps are agnostic to subsequent analysis, i.e., any software supporting BIDS-Derivatives for its inputs should be amenable to analyze data preprocessed with them.
- NiPreps are thoroughly and transparently documented (including the generation of individual, visual reports with a consistent format that serve as scaffolds for understanding the underpinnings and design decisions).
- NiPreps are community-driven, and contributors (in any sense) alwaysget credited with authorship within relevant publications.
- NiPreps are modular, reliant on widely-used tools such asAFNI,ANTs,FreeSurfer,FSL,NiLearn, orDIPY [7-12] and extensible via plug-ins.
Practical guide to submitting your contribution¶
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 anissue!
Before you start, you'll need to set up a freeGitHub account and sign in.Here are someinstructions.
Already know what you're looking for in this guide? Jump to the following sections:
- Joining the conversation
- Contributing through Github
- Understanding issues
- Making a change
- Structuring contributions
- Licensing
- Recognizing contributors
Joining the conversation¶
NiPreps is maintained by a growing group of enthusiastic developers—and we're excited to have you join!Most of our discussions will take place on openissues.
We also encourage users to report any difficulties they encounter onNeuroStars,a community platform for discussing neuroimaging.
We actively monitor both spaces and look forward to hearing from you in either venue!
Contributing through GitHub¶
git is a really useful tool for version control.GitHub sits on top of git and supports collaborative and distributed working.
If you're not yet familiar withgit
, there are lots of great resources to help yougit started!Some of our favorites include thegit Handbook andtheSoftware Carpentry introduction to git.
On GitHub, You'll useMarkdown to chat in issues and pull requests.You can think of Markdown as a few little symbols around your text that will allow GitHubto render the text with a little bit of formatting.For example, you could write words as bold (**bold**
), or in italics (*italics*
),or as alink ([link](https://youtu.be/dQw4w9WgXcQ)
) to another webpage.
GitHub has a really helpful page for getting started withwriting and formatting Markdown on GitHub.
Understanding issues¶
Every project on GitHub usesissues slightly differently.
The following outlines how theNiPreps developers think about these tools.
Issues are individual pieces of work that need to be completed to move the project forward.A general guideline: if you find yourself tempted to write a great big issue thatis difficult to describe as one unit of work, please consider splitting it into two or more issues.
Issues are assignedlabels which explain how they relate to the overall project'sgoals and immediate next steps.
Issue Labels¶
The current list of issue labels arehere and include:
These issues contain a task that is amenable to new contributors because it doesn't entail a steep learning curve.
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 and improvements to be considered by the project.
Please try to make sure that your requested feature is distinct from any othersthat 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.
In order to define priorities and directions in the development roadmap,we have two sets of special labels:
Label | Description |
---|---|
Estimation of the downstream impact the proposed feature/bugfix will have. | |
Estimation of effort required to implement the requested feature or fix the reported bug. |
One way to understand these labels is to consider how they would apply to an imaginary issue.For example, if -- after a release -- a bug is identified that re-introduces a previously solved issue(i.e., its regresses the code outputs to some undesired behavior), we might assign it the following labels:.Its development priority would then be "high", since it is a low-effort, high-impact change.
Long-term goals may be labelled as a combination of: and
or
since they will have a high-impact on the code-base, but require a medium or high amount of effort.Of note, issues with the labels:
or
are less likely to be addressed because they are less likely to impact the code-base, or because they will require a very high activation energy to do so.
Making a change¶
We appreciate all contributions toNiPreps,but those accepted fastest will follow a workflow similar to the following:
Comment on an existing issue or open a new issue referencing your addition.
This allows other members of theNiPreps 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.Fork the particularNiPrep repository (e.g.,fMRIPrep) with your GitHub user.
This is now your own unique copy of that particularNiPreps component. Changes here won't affect anyone else's work, so it's a safe space to explore edits to the code!Clone your forked NiPreps repository to your machine/computer.
While you can edit filesdirectly on github, sometimes the changes you want to make will be complex and you will want to use atext editor that you have installed on your local machine/computer. (One great text editor isvscode).
In order to work on the code locally, you must clone your forked repository.
To keep up with changes in the NiPreps repository, add the"upstream" NiPreps repository as a remote to your locally cloned repository.Make sure tokeep your fork up to date with the upstream repository.gitremoteaddupstreamhttps://github.com/nipreps/fmriprep.git
For example, to update your master branch on your local cloned repository:gitfetchupstreamgitcheckoutmastergitmergeupstream/master
Create anew branch to develop and maintain the proposed code changes.
For example:Please consider using appropriate branch names as those listed below, and mind that some of them are special (e.g.,gitfetchupstream# Always start with an updated upstreamgitcheckout-bfix/bug-1222upstream/master
doc/
anddocs/
):fix/<some-identifier>
: for bugfixesenh/<feature-name>
: for new featuresdoc/<some-identifier>
: for documentation improvements. You should name all your documentation branches with the prefixdoc/
ordocs/
as that will preempt triggering the full battery of continuous integration tests.
Make the changes you've discussed, following theNiPreps coding style guide.
Try to keep the changes focused: it is generally easy to review changes that address one feature or bug at a time. It can also be helpful to test your changes locally, using aNiPreps development environment. Once you are satisfied with your local changes,add/commit/push them to the branch on your forked repository. Note that that each commit must include changes that serve a coherent purpose only (e.g. documentation, feature, bug fix) and that have a clear scoped. They should be prefixed as indicated below.Submit apull request.
A member of the development team will review your changes to confirm that they can be merged into the main code base.
Pull request titles should begin with a descriptive prefix (for example,ENH: Support for SB-reference in multi-band datasets
):ENH
: enhancements or new features (example)FIX
: bug fixes (example)TST
: new or updated tests (example)DOC
: new or updated documentation (example)STY
: style changes (example)REF
: refactoring existing code (example)CI
: updates to continuous integration infrastructure (example)MAINT
/MNT
: general maintenance (example)- For works-in-progress, add the
WIP
tag in addition to the descriptive prefix. Pull-requests tagged withWIP:
will not be merged until the tag is removed.
Have your PR reviewed by the developers team, and update your changes accordingly in your branch.
The reviewers will take special care in assisting you address their comments, as well as dealing with conflicts and other tricky situations that could emerge from distributed development.
NiPreps coding style guide¶
Whenever possible, instances of NipypeNode
s andWorkflow
s should use the same namesas the variables they are assigned to.This makes it easier to relate the content of the working directory to the codethat generated it when debugging.
Workflow variables should end in_wf
to indicate that they refer to Workflowsand not Nodes.For instance, a workflow whose basename ismyworkflow
might be defined asfollows:
fromnipype.pipelineimportengineaspemyworkflow_wf=pe.Workflow(name='myworkflow_wf')
If a workflow is generated by a function, the name of the function should takethe forminit_<basename>_wf
:
definit_myworkflow_wf(name='myworkflow_wf):workflow=pe.Workflow(name=name)...returnworkflowmyworkflow_wf=init_workflow_wf(name='myworkflow_wf')
If multiple instances of the same workflow might be instantiated in the samenamespace, the workflow names and variables should include either a numericidentifier or a one-word description, such as:
myworkflow0_wf=init_workflow_wf(name='myworkflow0_wf')myworkflow1_wf=init_workflow_wf(name='myworkflow1_wf')# ormyworkflow_lh_wf=init_workflow_wf(name='myworkflow_lh_wf')myworkflow_rh_wf=init_workflow_wf(name='myworkflow_rh_wf')
Recognizing contributions¶
We welcome and recognize all contributions regardless their size, content or scope:from documentation to testing and code development.You can see a list of current developers and contributors in the.zenodo.json
fileof the corresponding repository. Seezenodo file for an example.Note that the.zenodo.json
file is generated automatically, digesting datafrom themaint/MAINTAINERS.md
andmaint/CONTRIBUTORS.md
files (and fromthemaint/PIs.md
andmaint/FORMER.md
files, if applicable).New contributors should add their names to themaint/CONTRIBUTORS.md
file.Contributors are promoted to themaint/MAINTAINERS.md
list following theNiPreps governance model.Governance information can be found in theGOVERNANCE repository.Before every release, a new.zenodo.json
will be generated through the.maint/update_authors.py
script that dwells in the repository at issue.The script will also sort creators and contributors by the relative size of theircontributions, as provided by thegit-line-summary
utility distributed with thegit-extras
package. Seeupdate script foran example of the script.Last positions in both thecreators andcontributors list will be reserved tothe project leaders.These special positions can be revised to add names by punctual request and revised forremoval and update of ordering in an scheduled manner every two years.All the authors enlisted ascreators participate in the revision of modifications.
Publications¶
Anyone listed as adeveloper or acontributor can start the submission process of a manuscriptas first author (please seeMembership, where these concepts aredescribed).To compose the author list, all thecreators MUST be included (except for those people whoopt to drop-out) and all thecontributors MUST be invited to participate.First authorship(s) is (are) reserved for the authors that originated and kept the initiativeof submission and wrote the manuscript.To generate the ordering of your paper, please runpython .maint/paper_author_list.py
from theroot of the repository, on the up-to-dateupstream/master
branch.Then, please modify this list and place your name first.All developers and contributors are pulled together in a unique list, and last authorships assigned.NiPreps and its community adheres to open science principles, such that a pre-print shouldbe posted on an adequate archive service (e.g.,ArXiv orBioRxiv) prior publication.
Licensing¶
NiPreps is licensed under the Apache 2.0 license.By contributing toNiPreps,you acknowledge that any contributions will be licensed under the same terms.
Thank you!¶
You're awesome.
— Based on contributing guidelines from theSTEMMRoleModels project.
The imposter syndrome disclaimer was originally written byAdrienne Lowe for aPyCon talk, and wasadapted based on its use in the README file for theMetPy project. ↩