Reorganize the developer docs #1512
Conversation
|
This is exactly what I needed when I started contributing. Thank you so much for taking your time to put this together. |
|
|
||
| * Keep the maintenance branches and master in sync where it makes sense. | ||
| * No tabs (only space). No trailing whitespace. |
There was a problem hiding this comment.
Should this be a main bullet, or a sub-bullet for the PEP8 bullet?
There was a problem hiding this comment.
PEP8 doesn't address trailing whitespace. The "no tabs" rule is in PEP8, but I'd rather make it really prominent here.
|
Might want to add to the bullet list a reference to the section on what to do if adding a new plotting function. |
| from nose.tools import assert_equal | ||
|
|
||
| def test_simple(): | ||
| '''very simple example test''' |
There was a problem hiding this comment.
This should probably be a "proper" docstring, with """ instead of '''
|
I didn't take the time to checkout the code and building the documentation, but it seems to me like a huge improvement on the documentation. Nice job ! |
We should add a |
|
@pelson: Cool: I didn't know about that feature of github. I agree, this content should go in there. But maybe contributing should just link to this page on matplotlib.org? I'm not sure keeping this documentation in sync in multiple places is a good idea. |
|
|
||
| Nose determines which functions are tests by searching for functions | ||
| beginning with "test" in their name. | ||
|
|
There was a problem hiding this comment.
A note in here would be useful regarding @cleanup.
|
Bravo! 👍 with the few suggestions I made. Thanks @mdboom . |
|
I (believe) I have addressed all of the comments above. |
All looks good to me. Thanks @mdboom. |
Reorganization of the developer docs to make it easier to get up to speed with the matplotlib development process.
This is a reorganization of the developer docs. The main thrust here is to add a "pull request checklist" which is intended to be a concise and easy-to-follow checklist of things to ensure before a pull request is merged. Some larger sections of coding_guide.rst have been separated out into their own chapters.
There are a lot of instances where we (myself included) have said "oops -- forgot to document this feature committed a while back" or "forgot to add a CHANGELOG entry" etc. I thought that having a place to refer to every time would be helpful, and should also help new contributors understand what's expected, and take some burden off of the seasoned developers to say "please add tests, documentation, etc." in the pull request review -- we now have something we can just point to.
I don't necessarily want to get into an elaborate discussion about coding standards -- and I've tried to keep this simple so as to not seem overly rigid and daunting -- but if there's anything that should go on this list that isn't there already, please mention it here.