Populate GitHub community docs

[effigies]

Code of conduct and contributing should at minimum be populated. I think there's a nipy-wide CoC that we can refer to.

I'm mixed on issue/PR templates, as my experience in other projects is that people mostly ignore them, and so the incomplete boilerplate ends up acting as clutter.

[matthew-brett]

Tne nipy-wide CoC is fine with me. I would also, personally, prefer it to be called something less school-rulesy than Code of Conduct, like "Guidelines for contributors" or "Guidelines and procedures".

I agree, I don't like the PR templates, I tend to delete them myself.

[yarikoptic]

I find templates useful especially when contributing to new new to me project - they outline expectations and hints from the developers.
For the regular victims, I already know the hints and expectations, so quite often I just condense relevant information. Deleting the template while composing a PR in those cases is a no brainier ;-)

[yarikoptic]

I would second Matthew's idea of nipy-wide or even more widerly used/popularized uniformized code of conduct (I don't like the name too but that is what they call it the days).
Per project code of conduct is IMHO just a "formality" to pet yourself on the back and to use as a official document if need arises. I really doubt that any of us reads those every time you decide to contribute. And I don't think we really need much of project specific lines in each CoC.
It is similar to licenses to some degree - we really benefit from being able to just say - that is MIT or GPL licensed code.
So is there a nipy-coc we could (all) embrace in our projects? Ideally also versioned ;-)

[satra]

there is one here: https://github.com/nipy/nipy.github.com/blob/master/conduct.html

and i don't remember why we have a separate one in nipype. convergence and being able to simply point to a common place would be great.

[yarikoptic]

Cool, what about creating nipy/coc repo, and render it in common formats, give it a version. Can do it later if noone else does but we agree on the way forward.

[effigies]

That approach sounds good to me, Yarik. Happy to review.

Now that the conversation is in this vein, I want to link in nipy/nipy.github.io#44, as well. In light of that conversation, @satra, I suspect the primary reason for the separate CoC is enforcement contacts (nipype has them, nipy doesn't). I'm not sure whether separate contacts per project is really desirable (more familiarity with the project norms vs inconsistency across projects). If we prefer a community-wide set of contacts, a nipy/conduct team or something would satisfy that.

[satra]

we should in that case reach out to each project listed under the nipy umbrella. at least ping a maintainer if a new conduct team and repo are created. they don't have to be part of the conduct team, but at least acknowledge the conduct statement. one way of doing this is to submit a PR on each project.

[effigies]

So just to update from the nipy-wide discussion, it looks like there's no consensus for a community-wide code with enforcement procedures, so it does devolve to the projects. After reading through the Jupyter and Scipy codes (Jupyter, and Scipy 1, 2) and conversations (jupyter/governance#23 and scipy/scipy#7963), my inclination is to draw heavily from the Scipy code.

I don't have a specific timeline for this. If anybody does have the time and energy to give it a shot, I'm happy to play reviewer, but otherwise I hope to get a start on it within the next month.

[matthew-brett]

I'm not against the Scipy doc - I think it's the best current compromise, but we are much smaller than them, so we might need to adjust numbers for committee etc.

[effigies]

Definitely. My inclination is two points of contact, as setting up a single point of contact makes things touchy if someone feels that person is themselves harassing them.

I was planning to get into more details once I started working on the draft, but might as well put a few cards on the table:

I think we should have the .github/CODE_OF_CONDUCT.md (or whatever the filename is that lets GitHub know to point at it), and this can be very short and link to the documents we want. I think those docs should go somewhere in https://nipy.org/nibabel, and that there we are not obligated to call it a "code of conduct".

I'm hopeful we can thread this needle, and in the smaller scope of nibabel, this should hopefully be less fraught, as we aren't necessarily speaking for the whole nipy community. I'd suggest we also give the documents an explicit trial period and return to them at the end of that period and re-assess how we feel about them, perhaps seeking outside input on whether people find them off-putting in either the "not enough teeth" or "too overbearing" direction.