This looks great. I wonder what the best way to get the rest of the mechanical work done is? I'd suggest merging this PR once any kinks or details are worked out, and then dividing up the gallery examples among some volunteers on the mailing list to update to the new conventions and organization.

This is awesome! I think this is going to help users a lot. Thanks for doing this work.

@NelleV Thanks. Good luck on MEP10. (PS. We miss you over at scikit-image:)

@mdboom Thanks for the feedback. I'm not certain what you mean by mechanical work. The mechanical part for me was checking for and renaming references to examples that I moved. Other than that, I didn't find anything too mechanical. Unless you mean the clean up itself. It might be nice to just have a script that automates some of the more common clean ups. That said, I don't remember anything that was very common amongst the examples that I cleaned up.

As for kinks: I still think the section names that I added could be improved. Some of the sections are too coarse, some are too fine. I guess that's unavoidable. It might also be nice to have more succinct section names. (For example, "lines, bars, and markers" probably deserve a better name. Also, do they really go together? I'd say yes, but I'm not completely convinced.)

@tonysyu I don't do vision anymore: . But you've got Andy contributing now

One thing I would love to see, but probably adds a large amount of work, is titles to examples like there is on scikit-image. I think it helps the user (and sometimes the developper itself) understanding why the example is there, and it makes the page easily searchable.

@tonysu: Yes, I meant what you thought. Mainly the work of categorizing the rest of the examples and putting them in to shape that satisfy the new guidelines in MEP 12. It's not terribly mechanical, I guess -- and least not easy to automate. But it's a lot of work, and if there's an easy way to divide the work, that might be the best way to get it done.

As for the category names: they didn't strike me as terribly bad, and anything is an improvement over the current situation where many are grouped only by implementation style. I think perfect might be the enemy of the good on this one, and maybe we proceed with these and further divide the categories later if the need arises.

@mdboom Good point on the category names. They'd be easy to change, and if nothing better jumps out, it's probably best just go with what's here.

As for automation, I think any mechanical work would be small compared to everything else. For example, I think most of the work is removing unnecessary customization, writing a good summary of the demo in the module docstring, combining/splitting examples from/into multiple files, etc.

Uh, oh - I'd forgotten about this big PR. Looks like there could be a couple of nasty merges as a result of this going stale.@tonysyu - are you going to be able to pick this up before release date (end of May)?

Thanks for pinging me on this. I should have some time to work on this (depending on the amount of work). Any hints on what changes may cause merge issues? Also, do the matplotlib-devs prefer merging changes from master (and resolving conflicts) or rebasing?

I generally prefer rebasing -- it makes the resulting history in the main project look cleaner. I hope the conflicts aren't too disastrous, but I haven't really looked.

Sounds good. I'll try rebasing tonight. Let's hope it's not too painful. :P

Let's hope it's not too painful. :P

I find that rebasing, when a conflict is identified with multiple commits, results in conflictsat each of the commits during rebase (I hope that makes sense). If you find this is the case, I'd be prepared to accept a merge in this PR, or alternatively a PR for each commit here (or you could squash the commits into just a few commits)...

Sorry for the brain dump! HTH

@pelson: Yes, that's true. When I run into that case (where a rebase causes conflicts at each step), I squash commits first, then rebase on master. I still think that's better than doing a merge in terms of the end result.

See PR#1924

Closed in favor of#1924.