Docs outline

Proposed chapters for the docs, who has responsibility for them, and who reviews them. The "unit" doesn't have to be a full chapter (though in some cases it will be), it may be a chapter or a section in a chapter.

Here is the ouline for the dev guide, much less fleshed out

We also have some work to do converting docstrings to ReST for the API Reference. Please be sure to follow the few guidelines described in :ref:`formatting-mpl-docs`. Once it is converted, please include the module in the API documentation and update the status in the table to "converted". Once docstring conversion is complete and all the modules are available in the docs, we can figure out how best to organize the API Reference and continue from there.

And we might want to do a similar table for the FAQ, but that may also be overkill...

If you agree to author a unit, remove the question mark by your name (or add your name if there is no candidate), and change the status to "has author". Once you have completed draft and checked it in, you can change the status to "submitted" and try to find a reviewer if you don't have one. The reviewer should read your chapter, test it for correctness (eg try your examples) and change the status to "complete" when done.

You are free to lift and convert as much material from the web site or the existing latex user's guide as you see fit. The more the better.

The UI chapters should give an example or two of using mpl with your GUI and any relevant info, such as version, installation, config, etc... The backend chapters should cover backend specific configuration (eg PS only options), what features are missing, etc...

Please feel free to add units, volunteer to review or author a chapter, etc...

It is probably easiest to be an editor. Once you have signed up to be an editor, if you have an author pester the author for a submission every so often. If you don't have an author, find one, and then pester them! Your only two responsibilities are getting your author to produce and checking their work, so don't be shy. You do not need to be an expert in the subject you are editing -- you should know something about it and be willing to read, test, give feedback and pester!