PHEP 1: PHEP Purpose and Guidelines #22
Conversation
* Version discussed on PyHC telecon 2023-10-16, with all "suggestions" applied * Does not incorporate discussion from the telecon
* Use 'replace' consistently instead of 'supersede'
* Includes rewriting to make sure 'revise' refers only to this process
|
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). |
pheps/phep-0001.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
Found a typo: "data of acceptance, as appropriate" --> "date of acceptance"
There was a problem hiding this comment.
New split keyboard, very good for neck and shoulder pain, not so good for accuracy right now. Thanks for the catch.
|
@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. |
|
Sounds good to me.
…On Thu, Feb 8, 2024 at 2:48 PM Shawn Polson ***@***.***> wrote:
@jtniehof <https://github.com/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.
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALX7QXWOZCWZ2HKGJOBRWVDYSUTW7AVCNFSM6AAAAAA6N54NPGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZUHAZDQNJRGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I've made minor cleanups per comments here; those are pushed, and the template in PHEP-2 is also updated in #25. |
|
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. |
|
I will make the changes with approval and DOIs and push, then request merge. I'll update #26 as necessary. |
* Some folding of headers as well
|
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 |
|
We are done! Zenodo record and GitHub release |
11 participants
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.
phep-editorsGH groups, commit access, etc. which might be overkill. Maybe there are other things we should use.Other notes
Input on nice Markdown editors is always welcome; here are a few: