-
Notifications
You must be signed in to change notification settings - Fork 12
PHEP 4: PyHC Package Tiering #31
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
base: main
Are you sure you want to change the base?
Changes from 1 commit
beb0c9e
4827407
10b6add
0ebfa4b
5f6a9a6
60620dd
c44670c
fa310db
367748b
8fd8859
67667c9
e17796b
bd1c717
042e382
6883539
41b641b
b44bd0f
a09b690
445ba8a
22ea912
bad5368
e7d8486
61bd00e
02111b4
1e18523
4cafcbb
99e07c2
2a92f46
7f06d79
1f0eb7d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,112 @@ | ||
| ``` | ||
| PHEP: 9999 | ||
| Title: PyHC Package Tiering | ||
| Author: Julie Barnum <julie.barnum@lasp.colorado.edu> <https://orcid.org/0000-0001-8755-0694> | ||
| Discussions-To: https://github.com/heliophysicsPy/standards/pull/25 | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
| Revision: 1 | ||
| Status: Draft | ||
| Type: Process | ||
| Content-Type: text/markdown; charset=UTF-8; variant=CommonMark | ||
| Created: | ||
| Post-History: 09-July-2024 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 :)
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe "Honorable Mention" should be renamed to "Copper" here.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
|
|
||
| # 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? | | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
| | :--: | :--------------------: | :------------------: | :---------------------: | :-----------------------------: | :-: | :---------------------: | :--------------: | :----------------: | | ||
| | **Gold** | Completed | Mostly green, some yellow allowed | Completed | No conflicts allowed | Required | Interoperable with all other PyHC core packages | Yes | Yes | | ||
| | **Bronze** | Completed | Several yellow, no red | In Progress | A couple conflicts exist | Required | Interoperable with most PyHC core packages | Yes | No | | ||
| | **Silver** | Completed | Red grades allowed | Not Completed | Major conflicts exist | Required | Interoperable with 1-2 PyHC core packages | Yes | No | | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
| | **Honorable Mention** | Not Done | N/A | N/A | Major conflicts exist | Not required | Does not interoperate with core packages | No | No | | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
|
|
||
| Descriptions for each heading are as follows: | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
| - 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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: |
||
| - pyOpenSci Review Status: indicates status of a pyOpenSci review | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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...." There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
| - 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 | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
| - 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 | | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
| | **Bronze** | No | No | No | No | Yes | Yes | No | Yes | Yes | | ||
| | **Silver** | 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 | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
| - 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 | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
jibarnum marked this conversation as resolved.
Outdated
|
||
| - 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} | ||
| ) | ||
| ``` | ||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.