MAINT: Add a base of CONTRIBUTING guidelines

[oesteban]

To be discussed in tomorrow's telecon (Close #12)

There are some descriptions I'll be working on today and tomorrow
morning before finishing the proposal.

This is related (sideways) to #7 too.

[arokem]

This looks good to me! Thanks for bringing in all the knowledge from your previous experience with fmriprep. I agree that scope should be limited, but as indicated by my questions, I am not 100% sure that we are ready to limit it just to the things you mentioned here. Should we take that as a separate discussion, after merging this here?

[richford]

LGTM. The only minor change I'd recommend is the inclusion of the "imposter syndrome disclaimer" from the nipy/dmriprep repo. I think the extra language can help to further foster inclusion. If the disclaimer is contentious, I'm happy to move that to another issue so that we can have that discussion without holding up this PR.

I agree with the "recognizing contributions" section and I tend to lean more towards maximal authorship inclusion (though my physics bias might be showing here).

[oesteban]

Would love to hear opinions from @josephmje and @dPys

[richford]

Looks good to me. I really appreciate you lending your experience on fmriprep to help make dmriprep a success!

[josephmje]

Apologies for the late reply. I think this looks fantastic! I saw the contributing guide from tedana and noticed that this is inspired by the same place. Some additional thoughts:

1. There was talk about running black and potentially a developer setup? Is that still the case? If so, that should be mentioned here.
2. Including a blurb on the Style Guide and writing in ReStructuredText for the docstrings.

[dPys]

I agree with the contributing guidelines as outlined. Some notes:
*The numbering of principles seem to all be labeled as '1.' -- I'm guessing this is a typo?
*Should we mention 'parsimony' as a general principle? i.e. if a purely-pythonic tool is available to replace a third-party equivalent, all else being equal, then pure-python is preferred to minimize external dependencies. e.g. preference for dipy's gibbs suppression over and above mrtrix's mrdegibbs which does the equivalent but demands mrtrix be added as a dependency. Now if it were the case that mrtrix was already a dependency, and mrdegibbs was a faster option or consumed less memory resources, then that would require different consideration. But I think the overarching principle would be that parsimony, whenever possible, is preferred. And that wouldn't just be a dmriprep principle, since it is fundamentally a pythonic one.

Curious to hear thoughts on this,
@dPys

[oesteban]

*The numbering of principles seem to all be labeled as '1.' -- I'm guessing this is a typo?

Nope, that's the formatting recommendation of markdown - it will reassign numbers when rendering.

*Should we mention 'parsimony' as a general principle? i.e. if a purely-pythonic tool is available to replace a third-party equivalent, all else being equal, then pure-python is preferred to minimize external dependencies. e.g. preference for dipy's gibbs suppression over and above mrtrix's mrdegibbs which does the equivalent but demands mrtrix be added as a dependency. Now if it were the case that mrtrix was already a dependency, and mrdegibbs was a faster option or consumed less memory resources, then that would require different consideration. But I think the overarching principle would be that parsimony, whenever possible, is preferred. And that wouldn't just be a dmriprep principle, since it is fundamentally a pythonic one.

I agree with this principle in general (not just for dMRIPrep), so for me there is no need to have it in writing. I'm happy including some of the language you proposed if others think we have to make this explicit.