Migrate proplot repo to be housed under another open-source development group?

[riley-brady]

I'm wondering if the proplot repo here could be moved to another organization, e.g. https://github.com/matplotlib or https://github.com/pangeo-data or elsewhere that it would fit.

This wonderful package now has > 1,000 stars and a lot of passionate users, but no releases or commits have been posted in 9-12 months. This is causing incompatibility issues with latest versions of core packages. I think there's a lot of eager folks submitting issues and PRs that would help to maintain a community-based version of this package! I certainly don't want to rewrite my stack to exclude proplot, as it has been immensely helpful in my work.

I know @lukelbd is busy with a postdoc. I'm wondering if you're open to this idea!

[lukelbd]

Hi Riley, thanks for the PR and the issue threads, appreciate the help! Yep the past year has been a bit intense -- the original plan was to try to build some sort of more sustainable community-oriented development plan by:

1. Switching away from my personal account to this "proplot-dev" group.
2. Submitting a stable release with this huge testing suite I've built up + matplotlib compatiability fixes
3. Applying for NumFocus affiliation both to attract interest and open up possible funding opportunities to justify the time committment (e.g. a small development grant). However that hasn't happened yet.

Re: #2 I really just have to get off my butt and finish these tests / compatibility issues (I'll check out your PR this weekend -- would love to get a new release with CI testing before summer). I still use proplot for virtually all of my plotting and expect to continue to do so indefinitely, but right now I'm just doing what others are doing and sticking to older versions.

Re: #3 I'm still open to the NumFocus-affiliated route, but really no strong preference -- if matplotlib or pangeo-data are open to housing the project I'd be 100% supportive of that, anything that helps us shift toward more community-oriented development. I suspect pangeo-data might be a better fit, since proplot almost comes across as a "pseudo-fork" of matplotlib, and obviously its development is heavily motivated and informed by the needs of geoscientists. It might also be informative to ask the seaborn author how they opperate, since it's a pretty analogous project (although seems seaborn is still under the personal account of the creator and mainly developed through his herculean efforts).

Anyway open to further discussion here or in any other threads. Also, while I don't intend to ever make big bucks from this, if we can get a small amount of funding toward development labor from NumFocus / matplotlib's grant / PanGeo's grant, that would be hugely motivating for myself and any future regular contributors or maintainers :). Not sure how PanGeo operates but I know NumFocus helps fund development labor (though I'm fuzzy on the details)

[riley-brady]

Totally understand. I had to abandon https://github.com/pangeo-data/climpred upon taking an industry job, and despite being under pangeo-data, it's still suffered from very limited community contribution. It takes a lot to offboard a personal project like this into a stable community-developed tool.

Awesome testing suite! I think if you can get that merged with some automated CI on unit tests + nightly upstream testing suite, that should go a long way to ensuring compatibility with matplotlib releases. That would be a great leap forward before having to try to port this over to the community.

I think NumFocus is the best of all of the options based on what you've shared. Hopefully that can come through! I wish I had more personal time to develop on packages like this as well. The least I can do is try to get a PR in to make it more stable in the meantime.

I'll be working on a forked branch of my PR on our stack at work. The imports are passing at the highest level. I'll let you know if I come across any deeper incompatibilities that aren't caught at import time.

[beckermr]

My 0.02 here is that if you want dev to move ahead, you might consider

• adding (more) maintainers to the repo who can help review and merge PRs
• releasing versions more often with only minor enhancements, bug fixes, etc.

These are difficult steps for sure, especially given how much work and time you've put into proplot over the years (thank you!), but they would help improve the experiences of users and developers (i.e., you!).

I am more than happy to help take on maintenance work myself. You don't know me of course which is the biggest barrier. If it helps, I am a long-time member of the conda-forge core team (https://github.com/orgs/conda-forge/teams/core). I know ~nothing about the internals of matplotlib etc., but am happy to do my best and be very cautious.

I use proplot almost everyday, it is by far the best plotting software I've used, and I have a strong interest in moving the project ahead.

[riley-brady]

releasing versions more often with only minor enhancements, bug fixes, etc.

I think this is key.

Getting proper unit tests/snapshot tests (the latter potentially more important for a viz package) could go a long way, along with a nightly or weekly CI test suite that checks against a set of python and matplotlib upstream versions. This would ensure stability and consistency.

Then incremental small releases with fixes and feature changes from the community would be a cherry on top.

I think most folks (or at least myself) would be thrilled with the existing feature set being stable against newer cartopy/matplotlib/python releases.

[riley-brady]

Any movement or thinking on this @lukelbd? I think getting your help on #450 to get higher matplotlib version support is much needed right now.

From there, getting that testing suite integrated would be helpful so you can just run nightly upstream tests and make sure no new core package releases break things.

[cvanelteren]

Would be happy to help if needed to execute a transition and provide support for forming a stable organization. Love the work that has been done on the package @lukelbd