Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopt PHEP(s) on core projects or project levels #30

Open
namurphy opened this issue Jun 13, 2024 · 8 comments · May be fixed by #31
Open

Adopt PHEP(s) on core projects or project levels #30

namurphy opened this issue Jun 13, 2024 · 8 comments · May be fixed by #31

Comments

@namurphy
Copy link
Contributor

namurphy commented Jun 13, 2024

Back in 2019, the PyHC projects list was modified so that "core projects" were organized separately (heliophysicsPy/heliophysicsPy.github.io#61). Since then we've added a few core PyHC projects, though the process has been somewhat ad hoc. It would be helpful to have a PHEP that addresses the following questions:

  • What constitutes a core project? This could include elements of:
    • 🌱 Project maturity
    • ☀️ Applicability to heliophysics
    • 🔌 Interoperability with the heliopythoniverse
    • 👥 Size of the user and contributor base
    • 🔧 Actively maintained
  • How are core projects added or removed?
    • ⚖️ Vote by community, or from representatives from core projects, or perhaps both?
    • 🚧 What is the process if a core package stops meeting requirements?
  • What are the most vital requirements that all core projects must meet? This could include elements of:
    • 📥 Availability on PyPI so that it can be installed with pip install core-package
    • 📥 Availability on conda-forge so that it can be installed with conda install core-package -c conda-forge
    • 🤔 Supports versions of Python as laid out by SPEC 0 and the possible PHEP being written in PHEP 3: PyHC Python & Upstream Package Support Policy #29
    • ❤️ Code of conduct
    • 📚 Sufficient (use of emojis in) documentation
    • 🧪 Sufficient tests

If we do have explicit requirements, we should make them relatively timeless so that it's less likely we'll need to submit a replacement PHEP. (For example, we should avoid specifying specific packaging tools, but it's probably safe to mention pip and perhaps conda-forge as well.) We'd probably also want a grace period of perhaps six months for current core projects to meet any requirements.

All of the above is a brainstorm at this point, and we'd probably want to have a discussion at an upcoming PyHC meeting to dive into this a bit more.

@jameswilburlewis
Copy link
Collaborator

I would propose an additional core project requirement: A succession plan to permit someone else to step in and take over maintenance of project assets (github, readthedocs, pypi, etc), in the event that a "sole proprietor" package maintainer is suddenly unable or unwilling to continue in that role.

@namurphy
Copy link
Contributor Author

A succession plan to permit someone else to step in and take over maintenance of project assets

Thank you for bringing this up! I wonder if we should have a larger discussion about this, and software sustainability more generally, at a PyHC meeting in the future. Along those lines, it seems a good practice for a core project to have a few core maintainers if at all possible.

This reminds me also about successors for GitHub accounts.

@rebeccaringuette
Copy link

The term 'core projects' is not a permanent one. It is about to be replaced by the different levels coming in a PHEP Julie mentioned today in the telecon. I would rather see this discussion happen in that context so that it can have a longer lasting effect. For instance, "What is the process if a package stops meeting the requirements of the package level it currently has?"
Other important things that are missing here are:

  • community contribution rules
    • at what package level is this required?
    • does it describe what process is needed for a contribution to the community to be allowed?
    • what complexity of the contribution process is allowed at what package levels? (e.g. legal processes not allowed at higher levels)
  • is a version specific DOI available for the software package? can users access that DOI from within the package in a uniform way (e.g. a citation("some package") call as done in R)? example in R
  • what metadata requirements are needed at each package level?
    ...and so on.

@namurphy namurphy changed the title Adopt PHEP(s) on core projects Adopt PHEP(s) on core projects or project levels Jun 17, 2024
@namurphy
Copy link
Contributor Author

The term 'core projects' is not a permanent one. It is about to be replaced by the different levels coming in a PHEP Julie mentioned today in the telecon.

That sounds cool! I updated the title to reflect the idea of levels. Thank you for bringing this up!

@jibarnum
Copy link

So, I think the "having a succession plan" will come automagically through a partnership with pyOpenSci, which is being suggested as a result of the PHEP I have up for package tiering. pyOpenSci works with package to find new maintainers in the events suggested above by @jameswilburlewis . But we should discuss if that in itself is sufficient for the community. Adding to my ever-growing list of questions for the community.

Related, since there is a PHEP that directly touches on this, do we need this issue to stay open?

@jibarnum
Copy link

So, I think the "having a succession plan" will come automagically through a partnership with pyOpenSci, which is being suggested as a result of the PHEP I have up for package tiering. pyOpenSci works with package to find new maintainers in the events suggested above by @jameswilburlewis . But we should discuss if that in itself is sufficient for the community. Adding to my ever-growing list of questions for the community.

Related, since there is a PHEP that directly touches on this, do we need this issue to stay open?

Based on Shawn's response on the other PHEP-writing issue, I amend the above to instead ask, should the issue be connected to the PHEP I wrote, such that when that closes, this issue closes?

@namurphy
Copy link
Contributor Author

Based on Shawn's response on the other PHEP-writing issue, I amend the above to instead ask, should the issue be connected to the PHEP I wrote, such that when that closes, this issue closes?

Yes, that sounds great!

@jtniehof
Copy link
Contributor

So, I think the "having a succession plan" will come automagically through a partnership with pyOpenSci, which is being suggested as a result of the PHEP I have up for package tiering. pyOpenSci works with package to find new maintainers in the events suggested above by @jameswilburlewis . But we should discuss if that in itself is sufficient for the community. Adding to my ever-growing list of questions for the community.
Related, since there is a PHEP that directly touches on this, do we need this issue to stay open?

Based on Shawn's response on the other PHEP-writing issue, I amend the above to instead ask, should the issue be connected to the PHEP I wrote, such that when that closes, this issue closes?

To be explicit, this is being addressed in #31.

@jtniehof jtniehof linked a pull request Sep 13, 2024 that will close this issue
@jibarnum jibarnum linked a pull request Sep 13, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants