Skip to content
Open
Changes from 3 commits
Commits
Show all changes
30 commits
Select commit Hold shift + click to select a range
beb0c9e
adding in draft for the PyHC package tiering PHEP
jibarnum Jul 9, 2024
4827407
had wrong order for silver vs bronze
jibarnum Jul 9, 2024
10b6add
Update pheps/phep-9999.md
jibarnum Jul 9, 2024
0ebfa4b
updating PHEP text to reflect comments, suggestions, and concerns fro…
jibarnum Aug 27, 2024
5f6a9a6
forgot info on software licenses
jibarnum Aug 27, 2024
60620dd
adding in some updates based on PR comments
jibarnum Aug 27, 2024
c44670c
Update pheps/phep-9999.md
jibarnum Sep 4, 2024
fa310db
addressed review comments
jibarnum Sep 11, 2024
367748b
addressing rebecca comments
jibarnum Sep 13, 2024
8fd8859
Several updates to reflect community discussions and decisions from t…
jibarnum Apr 25, 2025
67667c9
quick typo fixes
jibarnum Apr 25, 2025
e17796b
some updates based on PR comments and needed clarifications
jibarnum Jun 5, 2025
bd1c717
Assign PHEP number
sapols Jun 26, 2025
042e382
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
6883539
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
41b641b
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
b44bd0f
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
a09b690
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
445ba8a
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
22ea912
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
bad5368
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
e7d8486
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
61bd00e
Update pheps/phep-0004.md
jibarnum Oct 19, 2025
02111b4
Update pheps/phep-0004.md
jibarnum Oct 20, 2025
1e18523
Update pheps/phep-0004.md
jibarnum Oct 20, 2025
4cafcbb
Update pheps/phep-0004.md
jibarnum Oct 20, 2025
99e07c2
Update pheps/phep-0004.md
jibarnum Oct 20, 2025
2a92f46
removed unneeded line and added more info to TSC
jibarnum Nov 20, 2025
7f06d79
small tweaks to the wording for the TSC
jibarnum Nov 20, 2025
1f0eb7d
removed trailing whitespace
jibarnum Nov 20, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
112 changes: 112 additions & 0 deletions pheps/phep-9999.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,112 @@
```
PHEP: 9999
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sapols can you formally assign the number?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PHEP number assigned and DOI reserved.

Title: PyHC Package Tiering
Author: Julie Barnum <[email protected]> <https://orcid.org/0000-0001-8755-0694>
Discussions-To: https://github.com/heliophysicsPy/standards/pull/25
Revision: 1
Status: Draft
Type: Process
Content-Type: text/markdown; charset=UTF-8; variant=CommonMark
Created:
Post-History: 09-July-2024
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be updated with the April push (and then with the date of whatever push adds the April push :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ope, good catch... I kind of forgot this section existed!

```

# Abstract
<a name="abstract"></a>
This PHEP establishes a new tiering structure to PyHC projects, which will automatically affect PyHC packages once it goes into effect. Included herein is information on requirements for each of the new four tiers of PyHC projects (Gold, Silver, Bronze, and Honorable Mention), as well as benefits accrued at each tier.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe "Honorable Mention" should be renamed to "Copper" here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks!


# Motivation
<a name="motivation"></a>
Currently, PyHC is at a crossroads for how to push forward as a community. There are two main schools of thought—originating from bi-annual meeting discussions, telecon chats, and further sidebar converstaion—with regards to what PyHC is and should be: 1) a basic interpretation where PyHC is a collection, and listing, of open-soure Python packages with a relevance to Heliophysics and space physics, and 2) a standards-based interpretation where PyHC strives for compliance with our set standards, package interoperability, and standardization around one or more tools. There is utility and validity to both approaches. A new PyHC package tiering system is intended to find a "best of both worlds" with the two ideas. Older, out-of-date, unmaintained, or specific use-case code (e.g., associated with a publication) could still have a place for listing and findability, while also allowing nuance between other packages that are more robust, trustworthy, maintained, and work toward the standards-based interpretation of being a PyHC package. Further, this tiering system also allows users to get a clearer picture on what each PyHC package has to offer, and the state of the package's condition and development. Creation of a PyHC package tiering system also allows for justification for a myriad of benefits, for example, consideration for funding from a community travel fund, or extra help with improving a standards grouping grade.

# Rationale
<a name="rationale"></a>
Decisions for tiering levels, requirements for each tier, and benefits accrued at each tier are based on conversations with the community (bi-annual meetings, telecons, etc.), and are listed here as a starting point for more discussion, likely to be refined in the future. Initially, ideas were presented to the community in a pyramid format. To make the differences between tiers more visible and understandable, it has been transformed into a spreadsheet format.

# PyHC Package Tiering Specifications
<a name="specification"></a>
There are four tiers proposed in this PHEP: Honorable Mention, Bronze, Silver, and Gold. See the table below for requirements associated with each tier:

| Tier | Self Evaluation Status | PyHC Standard Grades | pyOpenSci Review Status | PyHC Env Installation Conflicts | DOI | Interoperability Status | pip Installable? | conda Installable? |
| :--: | :--------------------: | :------------------: | :---------------------: | :-----------------------------: | :-: | :---------------------: | :--------------: | :----------------: |
| **Gold** | Completed | Mostly green, some yellow allowed | Completed | No conflicts allowed | Required | Interoperable with all other PyHC core packages | Yes | Yes |
| **Silver** | Completed | Several yellow, no red | In Progress | A couple conflicts exist | Required | Interoperable with most PyHC core packages | Yes | No |
| **Bronze** | Completed | Red grades allowed | Not Completed | Major conflicts exist | Required | Interoperable with 1-2 PyHC core packages | Yes | No |
| **Copper** | Not Done | N/A | N/A | Major conflicts exist | Not required | Does not interoperate with core packages | No | No |

Descriptions for each heading are as follows:
- Self Evaluation Status: indicates whether a package has completed a self evaluation against PyHC's standards
- PyHC Standard Grades: indicates status of each standards grouping within a package's self evaluation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be standards, or PHEPs, or "standards and their replacements?"

As I noted in #33, #34, #35 it would be nice to replace our standards columns on the package page with PHEP compliance. More below.

Then instead of standards grades it would be more "compliance with standards-track PHEPs" and something like:

  • Gold: Complies with all "must" and many "should" requirements from applicable standards-track PHEPs (potentially exclude the "should"...)
  • Silver: Complies with most "must" requirements from applicable standards-track PHEPs
  • Bronze: Complies with some "must" requirements from applicable standards-track PHEPs
  • Copper: N/A

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer the table approach so the requirements for each level are more specific and clearly laid out.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I am understanding correctly, in the end this would still be a kind of stoplight system like what we have now, but pointing to compliance to... PHEPs? I didn't see your issues before submitting my code here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, stoplight system but the columns are PHEPs instead of categories of standards.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to go along with that. But, does that also mean this PHEP has to sit in limbo until those other complimentary PHEPs get passed? @jtniehof

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I like leaving the "many should requirements" in the Gold-level packages. We really should have only the cream of the crop and those putting in the effort to fully comply requiring our highest tier.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, put this in a related but different discussion thread, so now subjecting you to copy/paste:
I wouldn't think we need to hold this up until all standards PHEPs are done. If we have something like "when new standards-track PHEPs are approved packages have 6 (12?) months to self-evaluate and update their tiers", then we could in theory approve this with no new standards lined up. There's going to be a transition period regardless.

- pyOpenSci Review Status: indicates status of a pyOpenSci review
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this anything unique to PyHC, or just being in a pyOpenSci review? If the latter, can this link the appropriate pyOpenSci page?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be specifically for the PyHC-pyOpenSci pairing review process (checking against both pyOpenSci reqs + PyHC-specific reqs). No link for that, yet. That's part of why I'm trying to get the community to chat about what we'd need to define "yes, fits in with the PyHC" during the pyOpenSci process.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe explicitly say "to be defined in the future" or something? It feels a bit weird to be approving a standard that requires something that's not yet in place but I understand we can't do everything at once. Or this could be made more vague of "future collaborations" or something and the PHEP defining the pyOpenSci process would say "modifies PHEP 4 by adding...."

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That kind of modification plan could work nicely. In that pathway, this PHEP would become the skeleton (most of) the other PHEPs would map to using a stoplight or yes/no system as appropriate.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some items, we can flesh it out here and not wait for another PHEP. Others will need this approach or something similar.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'm going to modify the wording a bit here based on this feedback.

- PyHC Env Installation Conflicts: indicates state of installation conflicts within the PyHC software environment
- DOI: indicates whether or not a package has a DOI (e.g., from Zenodo or a publication)
- Interoperability Status: indicates the level of interoperability a package has with PyHC core packages
- pip Installable: indicates whether a package is pip installable
- conda Installable: indicates whether a package is conda installable

The following table shows the benefits that are associated with each tier:

| Tier | Summer School Inclusion | PyHC Software Env Inclusion | PyHC-Chat Bot Inclusion | pyOpenSci Verified badge | Standards Compliance Assistance | Listing on Main PyHC Project Page | Listing on Secondary PyHC Project Page | Software Search Interface Inclusion | Consideration for Conference Travel Funding |
| :--: | :---------------------: | :-------------------------: | :---------------------: | :----------------------: | :-----------------------------: | :-------------------------------: | :------------------------------------: | :---------------------------------: | :-----------------------------------------: |
| **Gold** | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | Yes |
| **Silver** | No | No | No | No | Yes | Yes | No | Yes | Yes |
| **Bronze** | No | No | No | No | No | Yes | No | Yes | No |
| **Honorable Mention** | No | No | No | No | No | No | Yes | Yes | No |

Descriptions for each heading are as follows:
- Summer School Inclusion: indicates whether a package will be included in summer school teaching materials
- PyHC Software Env Inclusion: indicates whether a package will be included within the PyHC software environment
- PyHC-Chat Bot Inclusion: indicates whether a packages will have up-to-date information included within the ChatGPT4-powered PyHC-Chat bot
- pyOpenSci Verified Badge: a badge that shows whether a package has completed the pyOpenSci review process
- Standards Compliance Assistance: indicates whether a package will receive extra help and/or advice from PyHC leadership in conforming to the PyHC standards
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, this seems counterintuitive to me. Shouldn't the packages that are less up-to-snuff receive more help? Perhaps a better way of splitting time would be having a pool of volunteers that could give time for things like code reviews and then receive code reviews from other people. That would be a nice way of creating more of a community environment in PyHC, but is not directly related to the tiers.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point. There's also an idea that packages who've done the work to be at a higher level get more help if there's extra funding for someone to poke around their code base (e.g. work through bug issues or solve long-standing open PRs).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point! We should have community support mechanisms for packages to level up, as you suggest.

📌 I'm wondering if something like an annual unstructured Helio Hack Week (like Astro Hack Week) would provide good opportunities for us to support each other in this way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a potential use case, having a path forward to help packages be pip/conda-installable would be a good support. A Hack Week could be useful here.

- Listing on Main PyHC Project Page: indictes whether a package's information will be displayed on a new, main PyHC Project page
- Listing on Secondary PyHC Project Page: indicates whetheer a package's information will be displayed on a new, secondary PyHC Project page
- Software Search Interface Inclusion: indicates whether a package will be included within a Heliophysics software search interface
- Consideration for Conference Travel Funding: indicates whether developers from a package will be considered for travel funding assistance to relevant science conferences (e.g. SHINE, CEDAR, or GEM)

Packages are evaluated against level of compliance with each requirement, as shown in the PyHC tiering chart. To be accepted for a tier, a package must meet **all** the requirements for said tier. Therefore, should a package fall into different tiers depending on the specific requirement, the package will be accepted at the lowest tier of requirements it meets. For example, if a package meets some requirements for the Silver tier, but other requirements only meet the Bronze tier, the package will be considered a Bronze tier package.

Once the tier specifications are set, the PyHC website will be updated to reflect the new tiers. Next, packages will self evaluate their PyHC package tier level. Similar to self evaluation of standards grading, packages will then submit a PR to [the PyHC website GitHub](https://github.com/heliophysicsPy/heliophysicsPy.github.io), modifying their package to fall under a certain tier. From there, the PyHC Leadership team-currently the PI (Julie Barnum) and the PyHC Tech Lead (Shawn Polson)-will give a final vote of approval and either merge the PR, or begin a discussion on the PR with reasons for a tier regrade. Note that a package is allowed to move between tiers. If a package upgrades their status to match that of Silver, instead of Bronze, tier, for example, they can submit a new PR to have their tier updated. The flip side is also true; should a package become defunct or drop in status, they may be downgraded to a lower tier. Packages will receive ample notification before this takes place (no less than three months' notice), with opportunity given to rectify any issues with their current tier level.


# Backwards Compatibility
<a name="backwards-compatibility"></a>
This PHEP does not propose a direct change to PyHC package code, simply the inclusion or not of packages within the various tiers, thus it introduces no compatibility concerns.

# Security Implications
<a name="security-implications"></a>
This PHEP raises no security implications as it does not interact with any executing code.

# How to Teach This
<a name="how-to-teach-this"></a>
This PHEP's contents and changes will be presented on, discussed, and hacked at various PyHC bi-weekly telecons and PyHC bi-annual meetings. Additionally, explanations for tiering, the process of obtaining a PyHC tier, etc. will be posted on the new main Projects page, as well as communicated within a blog post under the PyHC Blog page.

# Rejected Ideas
<a name="rejected-ideas"></a>
None yet to note.

# Open Issues
<a name="open-issues"></a>
None yet to note.

# Footnotes
<a name="footnotes"></a>
None yet to note.

# Revisions
<a name="revisions"></a>
Revision 1 (pending): Initial draft.

# Copyright
<a name="copyright"></a>
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. It should be cited as:
```
@techreport(phep2,
author = {Julie I. Barnum},
title = {PHEP Package Tiering},
year = {2024},
type = {PHEP},
number = {9999},
doi = {10.5281/zenodo.xxxxxxx}
)
```