Adopt PHEP(s) on core projects or project levels

[namurphy]

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]

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]

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]

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]

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!