PHEP process items to monitor

[jtniehof]

In the spirit of "kill your darlings", I'm opening this issue to track concerns brought up in the PHEP-1 discussions (#22). The text was not modified because these are concerns where there was no clear good solution, and/or "watch and see how it goes" seemed a better approach. The "things to watch":

• The consensus requirement opens itself to the possibility of a bad actor problem where one determined individual could block process (short-term answer: consider this a code of conduct issue).
• The process seems heavy and could inhibit innovation.
• The chosen balance between immutability and flexibility is pretty close to immutability and may not work out.
• PyHC leadership is loosely defined.
• Applicability (i.e. what holds packages to standards) is not defined.
• The annual review / checkup process is required in PHEP-1 but not defined, and it's not clear how it will work in practice.

The goal is not to solve these here, but capture them as topics for future discussion once we have experience with the process.

Additional items

This is a running list of other issues / concerns that have come up after the PHEP-1 discussions; I'll update it occasionally

• Revisit strict CommonMark in PHEPs #38
• References to "accepted" status (thread)
• Need to vote at both a meeting and a telecon (thread)

Consensus implementation

The following list is things where we seem to be converging on a consensus of implementation that is neither directly required by policy nor forbidden by it, i.e. candidate for potential future policy PHEPs.

• Allow a PHEP to have minor violations of procedure if clearly called out. Came up from table discussion of PHEP 4: PyHC Package Tiering #31 , see also Revisit strict CommonMark in PHEPs #38 .
• The first vote on a PHEP should be recorded in a GH comment thread on the PHEP's PR (either comment on a thread, or thumbs up / thumbs down on a comment designated for voting?). Second vote should be via "Approval" in a GH PR review.

[jtniehof]

#38 is the first major thing that's come up to revisit.

[jtniehof]

Noting @Cadair's proposal here:

• First round voting happens on a comment thread
• Second round voting should be done by explicit approval / request changes on the github PR

Consensus from fall 2024 meeting is to adopt this procedure.

PHEP 1 is (intentionally) squishy on this point, only suggesting using GH review as a way of expressing approval. Nothing to keep us from continuing to do this on a not-particularly-formal basis and decide if it should be included in future PHEP1 replacement. (Or make existing language even squishier).

[jtniehof]

Relative to PEP-1, we eliminated the "Accepted" status, which is for PEPs that are accepted but don't have a complete reference implementation. If a reference implementation is appropriate, we require that it be complete before the vote and moving the PHEP to "Final".

Unfortunately I missed these lines in the "What Belongs In A Successful PHEP" section: 'Reference Implementation - The reference implementation must be completed before any PHEP is given status "Final", but it need not be completed before the PHEP is accepted.' This is a little ambiguous now. There are a few other instance of "Accept" in PHEP1 which should probably be scrubbed (there's also the weirdness of "approval" meaning assignment of a number, not a vote to approve). So there's some language refinement to be done there.

This strikes me as something where we can probably do a revision rather than a new PHEP. Also applicable to PHEP 2.

[jtniehof]

PHEP-1 requires votes at "both a PyHC regular telecon and a regular PyHC meeting". We might want to revisit this to allow both votes to be at a meeting. I think we had decided not to allow that because the telecons are in theory a lower barrier to entry, particularly when meetings are in person.