xESMF
xESMF copied to clipboard
Sustainability Plan for xESMF
I just had a nice chat with @JiaweiZhuang and we agreed that a new model is needed to keep xESMF sustainable. The main elements are
-
Move xESMF to an organizational repo. Some options are:
- pangeo-data - As an owner, I'm happy to volunteer this.
- esmf-org - Would make a lot of sense, if we have support form an esmf owner.
-
Develop a simple governance plan for xESMF. This will likely be Jiawei as BDFL, but it's useful to formalize this and write it down.
-
Add a code of conduct and update contributor guide.
-
Solicit volunteers for xESMF maintainers from the community. This is probably the most important part. Some possible candidates, based on recent activity are:
- @huard
- @raphaeldussin
- @raspstephan
- @bekozi
- @jhamman
- @stefraynaud
- @RondeauG
We would like to have at least two additional maintainers, committed to responding to issues, reviewing PRs, and generally keeping things moving. Any volunteers?
If we can accomplish all of these things, we will set xESMF on a good course for future development and broad adoption in the python geospatial community.
xref #28
Happy to help with code reviews.
xesmf is a code that I use very regularly and I want to see maintained so I'll help as well if you need me
Sadly, I can't guarantee enough availability to become a maintainer, as my need (and available time) for xESMF greatly depends on which projects I'm working on. However, I will be happy to contribute to PRs when my projects require features that are not yet implemented.
💯 ! Thanks @rabernat and @JiaweiZhuang for working on this.
@bekozi or @rsdunlapiv would be the best to ask about the ESMF org option. There is also a third option: xarray-contrib.: https://github.com/pydata/xarray/issues/1850 (see also https://github.com/JiaweiZhuang/xESMF/issues/28#issuecomment-415257488). I'll note I don't have strong feelings either way.
I will say that before I sign up to be a maintainer, I'd want to go through a road mapping process. It's unclear to me at this point what is or should be in/out of scope for this project and I think that the primary thing holding back the project. If we had something like http://xarray.pydata.org/en/latest/roadmap.html in place, I think it would be much easier to solicit maintainers from the community.
Thanks for your initiative @rabernat. After switching from CDAT to xarray, I naturally came to xesmf for regridding tasks. I would like this excellent package to be in a more sustainable development context to make sure it is the right choice to adopt it in other libraries, such as the ones I'm personally coding.
I agree with @jhamman with the development roadmap, at least to make things clear about how this library must evolve in the future and where it must not go.
Anyway and despite my limited availability, I am at your disposal if you need me.
Yes, the idea of a roadmap is a very good one. Let's try to schedule a call about this.
I have created a Doodle poll for this, with times later this week and next week. Please fill in if you're interested in participating:
https://doodle.com/poll/tee2mk7qe8q3ggan
Based on the results of the poll, the best time is Mon, May 18, 3:00 PM - 4:00 PM ET. We can use https://whereby.com/pangeo.
The respondents were @JiaweiZhuang, @bekozi, @stefraynaud, @jhamman, @raphaeldussin, and @huard. I look forward to seeing you at the meeting. Please bring your ideas for xESMF's roadmap.
I'm looking forward to seeing everyone online at 3. I don't have all your emails, so I am hoping github notifications are enough to keep everyone in the loop.
-R
Thanks for the great meeting today everyone! The notes are published in read-only form here: https://docs.google.com/document/d/e/2PACX-1vQ3Tt4rDj00JWrpdrJIUqO62mJGrD5J7imN_f5q6l8N1eWcPTD3v0BW0sC4CmVYiLSoEmOmr_Am8zgm/pub
Our next meeting will be Monday, June 15, 3pm-4pm EDT.
@bekozi - let us know when you hear back about the possibility of transferring to esmf-org so we move forward with that item.
@rabernat - I think it will be okay provided the GitHub permissions investigation by @jhamman doesn't reveal any blockers. I'll also take a look at the permissions question today as well.
I created a temporary repository for testing permissions: https://github.com/esmf-org/temp-for-permissions. I added @rabernat, @jhamman, and @JiaweiZhuang as admins. So far I don't see any issues. Feel free to experiment in there if you like.
I just checked it out. Looks like, with owner-level permissions, we can do everything we need to do (add new maintainers, etc.) So I favor the idea of moving xESMF to esmf-org/xESMF.
This plan sounds good to me BUT I don't seem to have any permissions on the test repo. Perhaps @rabernat can try adding me as a good test?
NM. my invitation had gone to spam. I now see that I have permissions.
That's good to hear. I'll be working on this with @esmf-org and will be in touch!
I am happy with moving the repo to esmf-org. Let me know when I can transfer it.
@JiaweiZhuang I'll coordinate with you once we get the go ahead. The transition is looking likely at this point, but we need to make sure the relationship between the repositories is well-defined per a discussion with @rsdunlapiv. It was something we also discussed in the meeting.
How do these text snippets look for the README headers (please suggest changes/additions)? For clarity, I added the sentence about "official support" which is meant to align user expectations. ~~"Disclaimer" seems a little strong, but it is important that the text is noticed. Maybe folks have some suggestions on this.~~
For xESMF
:
xESMF is a community-supported xarray wrapper for ESMPy and is not officially supported by ESMPy. If you are looking for ESMPy/ESMF support, see https://github.com/esmf-org/esmf.
For esmf
:
Support and source code for xESMF (the community-supported ESMPy xarray wrapper) is handled in a separate repository: https://github.com/esmf-org/xESMF.
I would simplify to
xESMF is a community-supported xarray wrapper for ESMPy, and is not officially supported by ESMPy. If you are looking for ESMPy/ESMF support, see https://github.com/esmf-org/esmf.
I edited the text.
Hi all, I know there is interest in bringing xESMF under the esmf-org organization. We are currently talking about the ramification of this within the ESMF team. No decision has been made about this. For the current time, I hope the xESMF repository can remain under @JiaweiZhuang and associated forks.
@rsdunlapiv - thanks for your message! Our desire is to move xESMF soon to an organizational repo, rather than a personal one. Since the package is essentially just a wrapper around pyesmf, the maintainers felt esmf-org would be a good fit. Keep in mind that hosting a repo under your org has no formal legal implications. If esmf-org doesn't work, then we will move it to pangeo-data.
According to my calendar, we are due for another xESMF dev meeting today at 3pm EDT.
Are folks still up for this? I think we should do a quick check in if people are available.
We can use https://whereby.com/pangeo.
We me today with myself, @stefraynaud, @huard, and @raphaeldussin. Our next meeting will be Monday, July 13, 3pm EDT.
One outcome of the meeting was a decision to wait one more week for ESMF to make a decision about hosting the repo under their org. @rsdunlapiv - please let us know your decision by Monday, June 22. If esmf_org
can't take over ownership of the repo, we will move it to pangeo-data
on that date.
Other action items are mostly blocking on the repo transfer.
@JiaweiZhuang Would it be possible to make the transfer before the next meeting ?
any update from @rsdunlapiv or esmg_org about taking xESMF under their organization?
We need @JiaweiZhuang to take some action to move this to pangeo-data. ESMF appears unresponsive.
@JiaweiZhuang - I have changed you to an "owner" on pangeo-data so you can transfer the repo there.
Hi All, I'm not sure I have the authority to speak on behalf of the ESMF project, but I can tell you that we have been talking about this in our technical meetings over the last few weeks as time allows. My impression is that the general feeling is that of hesitation to commit to maintaining a project for which we do not have sufficient resources, and for which development and releases happen at a faster cadence than the other products within our tenure. This is not to say that we have made a definitive decision not to host this project within our organisation, but that the parties responsible for our project planning have not yet had sufficient time and information to make a well-informed decision. I apologise for the delay in this response, as I know this is a matter of importance to this group. However, please understand that the ESMF team has many customers with many different interests, and unfortunately our priorities tend to follow our funding and do not allow for much engagement with our open-source partners.
You could put it on xarray-contrib which is gaining momentum nowadays