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

PHEP 1: PHEP Purpose and Guidelines #22

Merged
merged 84 commits into from
May 20, 2024
Merged

Conversation

jtniehof
Copy link
Contributor

@jtniehof jtniehof commented Oct 24, 2023

tl;dr

If this is all a bit overwhelming, you can look at the file view to see the full proposed text. You can comment line-by-line and reply to others' line-by-line comments there. The Markdown source is pretty human-readable without rendering.

Overview

This PR proposes a process by which the PyHC community makes collective decisions. Ideally everything needed to understand this is within the document itself. This incorporates changes due to the conversation on the PyHC call 2023-10-16 (slides) and 2023-11-27 (slides)

There are some ongoing conversations in comments on the applicable lines. Some are linked below, as well as some questions not relating to specific lines.

@sapols, I ask that you take the role of editor for this one, just check for formatting and consistency as described herein?

Renders, diffs, etc.

I am no longer doing the diffs back to the dawn of time, as they're basically unreadable anyway.

The diffs were wrapped after diffing, so the columns don't line up perfectly...hopefully it's still readable.

Models

PHEP-1 was primarily based on PEP-1, with consideration of NEP-0 and SEP-1. Similar processes:

Open questions and comments

Also see #25 for discussion of a template.

Resolved questions and comments

I believe these issues have been resolved in discussion, but they can be revisited if anybody objects to the resolution.

  • We should have an index of PHEPs. I can add the initial (nearly degenerate) table as part of this PR, or we can take a different approach (automatically indexed? if so, just on the website and not in the repository?) (Deferred to Automation/process support needed for PHEPs #24)
  • Do we want to have an autobuilder that renders PHEPs to the website or just link the index to this repository? (Deferred to Automation/process support needed for PHEPs #24)
  • Handling of the PHEP header (Considered resolved, marking off with code fence).
  • Do we need/want an explicit sign-on mechanism? (decision is No)
  • I use explicit HTML anchors for internal links. I don't think there's another way of doing so in CommonMark. This results in funtional HTML and PDFs from ReText and GitHub viewing, at least. (EDIT: It looks like GH's renderer automatically inserts anchors based on heading names, which I've seen in a few others, but this does not appear to be universal.) (Resolution is we should go ahead and put in explicit anchors, but probably doesn't need to be in the PHEP instructions as such.)
  • PEP-1 has a lot of numbered or bulleted lists that contain multiple paragraphs. This doesn't really work in Markdown (as far as I can tell)--basically you can have the numbered item, then an indent block, then a new numbered list that starts at a new number. In some renderers this results in weirdly inconsistent spacing between items, depending on if they're multi-paragraph. This can be worked around by always putting a blank line between each list item, or just not worrying about it. (Resolution is we mostly don't care, up to the author. I was picky enough to put in the blank lines.)
  • What GitHub machinery should we make use of, e.g. there's a lot of phep-editors GH groups, commit access, etc. which might be overkill. Maybe there are other things we should use.
  • A draft template is in PR PHEP 2: PHEP template #25.
  • Should there be a quorum requirement on the votes to accept PHEPs?
  • Should we vote before a reference implementation is complete, or just require a single round of acceptance voting straight to Final status that includes the standard and the reference implementation?
  • Should finalized PHEPs be immutable? I.e. are they open to revision or must they be replaced (potentially by a very similar PHEP)?

Other notes

Input on nice Markdown editors is always welcome; here are a few:

  • ReText has side-by-side preview and is available in the Ubuntu repositories.
  • CommonMark has a web widget so you can see how things render.
  • PyCharm supports Markdown.

pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
@BaptisteCecconi
Copy link
Contributor

Hi @jtniehof, you can add: VEP in you list (IVOA Vocabulary Enhancement Proposal).

pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
pheps/phep-0001.md Outdated Show resolved Hide resolved
@jtniehof
Copy link
Contributor Author

jtniehof commented Feb 7, 2024

I've added the revision process. It probably makes most sense to look at the full diff because the effects are pretty wide-ranging, but you can also see the elements of:

I've also made sure "revise" and "revision" refer only to this process.

I am not entirely satisfied with this. It's not clear that it saves much effort, as there's still PR, status updates, DOI minting, etc.--a lot of that was probably implicit in just being able to replace a PHEP, made explicit here. (Although maybe those were dodgeable--do we need to mint a new DOI for a PHEP just to indicate it's been replaced?)

If there are really non-controversial changes, one would also think they'd sail through two rounds of voting and we wouldn't hurt much for the two months' wait.

I've honestly done the best I can on this, and I'm just not seeing a good path for substantive changes. For the most part, if somebody wants to see something different, I'm going to need suggested wording. I'd also be open to input on the summary in the "open issues" section on this, which will hopefully eventually go back into rejected ideas (in some form, based on what exactly gets rejected).

@rebeccaringuette
Copy link

Thanks, @jtniehof. Your effort has been substantial and worthwhile. This work is definitely ready for an in-depth discussion at the next PyHC meeting towards the goal of adoption. @jibarnum is there room in the schedule for this?


If a PHEP fails to find consensus, the author may choose to modify it for reconsideration. The PHEP may be "Withdrawn" if the PHEP author themself decides that the PHEP is actually a bad idea, or has accepted that a competing proposal is a better alternative. A PHEP can also "Rejected" if it fails to find consensus and the author is not willing or able to modify it. Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.

When a PHEP changes state, the PHEP preamble must be updated accordingly. In addition to updating the Status field, the Resolution header must be added with a direct link to the minutes of the telecons and meetings where a decision on the PHEP was made. The Revision section must be updated with the data of acceptance, as appropriate. The editors must post announcements of PHEP resolution to the PyHC mailing list.
Copy link
Contributor

Choose a reason for hiding this comment

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

Found a typo: "data of acceptance, as appropriate" --> "date of acceptance"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

New split keyboard, very good for neck and shoulder pain, not so good for accuracy right now. Thanks for the catch.

@sapols
Copy link
Contributor

sapols commented Feb 8, 2024

@jtniehof I'm completely satisfied with the new language, thanks for all your work. I think keeping them "largely immutable" with the revision process you outlined for trivial changes is perfect. Once that one typo gets fixed ("data" instead of "date"), I'm finally ready to hit the approve button.

If others are satisfied, I'd suggest we move to discuss formally voting on this PHEP.

@rebeccaringuette
Copy link

rebeccaringuette commented Feb 9, 2024 via email

@jtniehof
Copy link
Contributor Author

I've made minor cleanups per comments here; those are pushed, and the template in PHEP-2 is also updated in #25.

@jtniehof
Copy link
Contributor Author

Mea culpa...I announced on the PyHC list and Slack that we will be voting on this at the spring meeting, but didn't mention it here. See the spring meeting agenda.

@jtniehof
Copy link
Contributor Author

I will make the changes with approval and DOIs and push, then request merge. I'll update #26 as necessary.

@jtniehof
Copy link
Contributor Author

I believe we are now ready to merge and mark a release. @sapols, please merge and tag a release. See line 27 of https://github.com/heliophysicsPy/standards/pull/26/files#diff-2b1b69303b927a484e02c7fad9fc87d0d3ff0dc22ae1da0ecd0dc935d922a23c for the release creation. Attached is the final PHEP to use as the release file: phep-0001.pdf

@jtniehof
Copy link
Contributor Author

We are done! Zenodo record and GitHub release

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 this pull request may close these issues.

None yet