[DOC] Adds developer guideline start

[jbteves]

Closes #268, #479

Changes proposed in this pull request:

• Adds Developer Guidelines to RTD
• Moves monthly call to RTD
• Adds worked example to RTD
• Adds more information on git branching to CONTRIBUTING
• Updates some information in CONTRIBUTING
• Increases required reviewer count to 2

[codecov]

Codecov Report

Merging #446 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #446   +/-   ##
=======================================
  Coverage   81.63%   81.63%           
=======================================
  Files          39       39           
  Lines        2587     2587           
=======================================
  Hits         2112     2112           
  Misses        475      475

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 043a04c...f9a7295. Read the comment docs.

[emdupre]

First pass 😸

[rmarkello]

Hey @jbteves! Looks like you're still working on the Worked Example portion of the developing.rst but I took a poke around this, otherwise. Overall it's looking good! I made a few comments, but broadly there are two formatting things that would be great if you could address:

1. In all .md files please try and have each sentence on one line. That is, only use line breaks in between sentences (or for the start of lists, code blocks, etc). As it is, there doesn't seem to be much consistency (from what I can tell) to when line breaks occur---though please let me know if I'm missing something. If you'd be willing to update other instances of the CONTRIBUTING.md where we don't follow this format that would be awesome 🙌
2. In all .rst files it would be great to try and keep line breaks around ~99 characters. There's a lot more inconsistency here, since the documentation has had so many different eyes, but in chatting with @emdupre it seems this was the original intention. Right now you have some pretty variable line lengths (again, not sure if I'm missing something obvious!) so making them a bit more consistent would be awesome!

Let me know if you have any thoughts/concerns/whathaveyou.

[jbteves]

@rmarkello
Example: Yes, I think I had originally intended to add it and then got so excited that I finished some other bits that I forgot about it. My current plan is to close #252 and use it as an example, unless somebody has an alternative suggestion.
MD file: We can change that if you like. I think @KirstieJane would also like that. I don't know what conventions others have, but mine is breaks at commas, periods, and 75 characters (editor width).
RST file: Breaks follow the same convention as MD file for me. I can adjust, and did so in the commits I just pushed.
The comma-period-75 rule is a habit from running lots of LaTeX with vim because MacTex was (is?) abysmally slow, but the underlying CLI wasn't (isn't?). Sorry about that, I'm sure it looks insane to everyone else using fancy new editors.
There's nothing in any style guide here about line widths as far as I can tell, and we tell people to use PEP8 even though flake8 is set to 99; should we add that, too?
I don't have an issue with long line lengths in marked-up text such as MD and RST, however...
I think that 99 characters for code is incredibly long. 75-80 is much more standard because 80 is the standard terminal width and some people like to use smaller widths in case editors with line numbers are used (like me). It's also not PEP8 compliant, since the PEP8 standard is 79.
Tagging @emdupre and @KirstieJane to weigh on line length.

[jbteves]

We could also use doc8 to enforce style, however the default is 80.

[Islast]

This is a very useful section, I think there are a couple of other points in the document readers might want to quickly navigate to, so I would add:

• installing in editable mode
• testing and linting
• updating the documentation after changes to the code

I would also link to the developer docs here with a brief description of the contents, say:
See also our Developing Guidelines on [readthedocs][link_developing_rtd] for additional information, particularly on our monthly developer calls and writing tests for tedana.

[Islast]

This is really fantastic work 👍

There's a lot of work in this guide, and i think you've done a really good job of breaking down the development process and explaining each step. It's thorough, well organised, well communicated; if I wanted to contribute to tedana tomorrow, I'm sure this guide would make me feel very confident in doing so.

I like the high level of detail, because when I try to put myself in the position of someone inexperienced in contribution to open source projects, I think I would want more detail, rather than less. The one thing I would add to simplify things for the reader is a few more navigation links.

[Islast]

I would add a link to your contributing guide somewhere up here

[jbteves]

@Islast thanks for your review! For some reason it's not letting me request a re-review but hopefully you see this note; I think I addressed your concerns.

[Islast]

@jbteves I see them, I think the changes you've made are perfect.

[emdupre]

✨ 🌟 ✨

Excited to see this merged !

[jbteves]

D'oh, sorry @Islast looks like it didn't render the re-request on my end but it sent it to you anyway. Sorry 😬
@all-contributors please add @Islast for reviewing pull requests.
@rmarkello Once I have your approval we'll merge this.

[allcontributors]

@jbteves

I couldn't determine any contributions to add, did you specify any contributions?
Please make sure to use valid contribution names.

[jbteves]

@all-contributors add @Islast for review

[allcontributors]

@jbteves

I've put up a pull request to add @Islast! 🎉

[rmarkello]

Wooo!! Excited to see this merged in 🎉 🙌