Proposed PMIx Standards Process

[rhc54]

Signed-off-by: Ralph Castain [email protected]

[SteVwonder]

Thanks @rhc54 for putting this together. After an initial, late night pass, I think this looks good, and I do not have any major objections. Mainly just clarifying questions at this point (see below). I plan to give it another look with fresher eyes :)

[tonycurtis]

@rhc54 very nice.

[jjhursey]

I think this looks good. It's a lot more process than we have had before which is a little intimidating, but I think this is workable. The quarterly meetings should keep modifications flowing.

[jjhursey]

I tried to organize a timeline sketch of the process below. Is this an accurate summary of the process?

Provisional Status timeline (Shortest path to acceptance - 1 quarterly meeting)
(1) Open a Draft PR while writing
(2) Remove Draft PR status when ready for discussion
(3) Discuss PR - only add new commits
(4) Label "RFC" and announce to mailing list it's ready for formal review
(5) Add a "Straw Poll to move to Reading" comment
(6) ASC Co-Chairs schedule proposal for "Reading" at next quarterly meeting
(7) Proposal read at quarterly meeting
(8) Add a "Straw Poll to move to Acceptance" comment
(9) After 2 weeks, based on Straw Poll the PR is either "Accepted" or "Pushed Back"
(10) Accepted proposals merged by Release Managers

Stable Status timeline (Shortest path to acceptance - 2 quarterly meetings)
(1) Open a PR with justification for status change
(2) Add a "Straw Poll" comment
(3) If passes Straw Poll then ASC Co-Chairs label it as "Eligible" in next quarterly meeting
(4) Author presents Eligible PR in quarterly meeting
(5) Formal vote taken to designate as "Pushed Back" or "First Pass"
(6) If passes, then author presents it again in the following quarterly meeting.
(7) Formal vote taken to designate as "Pushed Back" or "Accepted as Stable"
(8) Accepted proposals merged by Release Managers

Deprecation timeline (Shortest path to acceptance - 1 quarterly meeting)
(1) Open an Issue for discussion
(2) PR filed to mark API as deprecated
(2) Add a "Straw Poll" comment
(3) If passes Straw Poll then ASC Co-Chairs label it as "Eligible" in next quarterly meeting
(4) Author presents Eligible PR in quarterly meeting
(5) Formal vote taken to designate as "Pushed Back" or "Deprecated"
(6) Deprecated proposals merged by Release Managers

[rhc54]

Provisional Status timeline (Shortest path to acceptance - 1 quarterly meeting)
(1) Open a Draft PR while writing
(2) Remove Draft PR status when ready for discussion
(3) Discuss PR - only add new commits
(4) Label "RFC" and announce to mailing list it's ready for formal review
(5) Add a "Straw Poll to move to Reading" comment
(6) ASC Co-Chairs schedule proposal for "Reading" at next quarterly meeting
(7) Proposal read at quarterly meeting
(8) Add a "Straw Poll to move to Acceptance" comment
(9) After 2 weeks, based on Straw Poll the PR is either "Accepted" or "Pushed Back"
(10) Accepted proposals merged by Release Managers

Not exactly - I see no reason for two straw polls. The author(s) should simply put it up for review at the next quarterly meeting whereupon a straw poll commences. After the presentation at the meeting, members can either revise their prior poll votes or, if they haven't already voted, can cast their vote. No reason to make people re-vote if their opinion didn't change.

[jjhursey]

Where I got confused, maybe, is that the first straw poll (5) is open to everyone whereas the second iteration (8) is worded such that only ASC members can adjust their votes. That indicated in my mind that they are two different things. I'm fine (and prefer) with (8) being open to anyone since it's not an official voting mechanism. Here is the sentence:

At the end of the agenda item, those members wishing to adjust their straw votes will be given an opportunity to do so. Members who did not attend the meeting will also have a chance to adjust their votes based on the published minutes of the meeting.

So that timeline looks like this then - modified (5) and (8)?

Provisional Status timeline (Shortest path to acceptance - 1 quarterly meeting)
(1) Open a Draft PR while writing
(2) Remove Draft PR status when ready for discussion
(3) Discuss PR - only add new commits
(4) Label "RFC" and announce to mailing list it's ready for formal review
(5) Add a "Straw Poll" comment to move the PR to Reading
(6) ASC Co-Chairs schedule proposal for "Reading" at next quarterly meeting
(7) Proposal read at quarterly meeting
(8) ASC Members may adjust their straw votes to move to the PR to Acceptance
(9) After 2 weeks, based on Straw Poll the PR is either "Accepted" or "Pushed Back"
(10) Accepted proposals merged by Release Managers

Note that I'm not advocating for more language here, or even a change is what is here (I think it's fine). I am just finding this difficult to read in such a way that I know what the "next step" in the process is (e.g., Do I send an email at this stage? What labels do I need to apply now? Am I responsible for creating the Straw Poll comment or is someone else?). So I tried to create a timeline for clarity at least in my mind.

There are a number of places in here that add justification for the process mixed with the process itself. Maybe we can separate those two so that the timeline and expectations are clearer? Or have a high-level bulleted list in each section for guidance before the body of text. I'm not sure I have a firm suggest yet.

[rhc54]

Okay, I gave it a try to clarify who does what when:

The process for acceptance to Provisional status begins when the author(s) assign an "RFC" label to the GitHub PR, add an empty "Straw Poll" comment to it, and send an announcement of the PR to the PMIx community mailing list requesting consideration of the PR for Provisional status. The announcement shall include a link to the PR, a brief description of the proposed change, and indicate any desired timeline for approval. It is especially important that proposals tied to contractual milestones be so designated to ensure that members are alerted to potential time pressures.

The "Straw Poll" comment is used by the ASC as a mechanism for obtaining a sense of how many people have viewed the PR and are following the discussion. This serves no official purpose other than to help define participation in the consensus building process and record the following tally:

I would recommend leaving the justification with the process - otherwise, we are bound to get a constant barrage of "but why" questions as nobody will look elsewhere for the justification.

Note that I am unaware of any mechanism by which we could restrict the "straw poll" to only ASC members (at least, as currently constructed). Thus, the polls always have to be considered informal. However, the Co-Chairs can easily distinguish who cast each vote if that ever becomes a major issue, or could execute a "straw poll" via email if someone requests a secret ballot.

I have no objection to including a timeline in the doc if that helps delineate what needs to be done and when.

[mike0042]

Suggestion: Rather than the second weak of the month for quarterly meetings, the third week may be better to avoid conflicts with holidays (e.g. Easter).
Suggestion: Provide a nomination process that allows members to nominate other strong contributors as members. The members then vote on adding the individual.

[SteVwonder]

Note from the call today: There should be a line added about how the release cycle is tied to the quarterly meeting cycle (at most there is 1 minor release per quarterly meeting). So an interface that is going to change after two minor releases will have at least 6 months of runway before being changed/removed.

[gvallee]

Question: Assuming an API or an attribute is already provisional. Now let's assume that a modification is accepted to that provisional API or attribute, I would assume it resets the timer to be eligible for becoming stable. Correct? So every time a modification in the context of a provisional functionality is made, it should the eligibility by a minimum of two quarterly meetings. Is too slow? The right speed? The concern here is in the context of refining the definition and semantics of a provisional functionality: it may take a few iterations to "get the text right" and that may potentially drastically slow down the process if everything it resets the timer for stable eligibility, even if these modifications remain minor. I am not arguing that this is necessarily a bad thing (we want good text to become stable) but is it our intent and if so should that be explicitly spelled out in the document?

[jjhursey]

Per Teleconf Friday, June 28, 2019

• I captured a few notes from the discussion in the meeting minutes here - most suggestions have already been posted here (please continue to do so).

[rhc54]

Note from the call today: There should be a line added about how the release cycle is tied to the quarterly meeting cycle (at most there is 1 minor release per quarterly meeting). So an interface that is going to change after two minor releases will have at least 6 months of runway before being changed/removed.

Made the following modification to the Release Manager section:

The Release Managers shall notify the Co-Chairs when a given release is complete and ready for publication. The Co-Chairs will add an item to the agenda of the next quarterly meeting (subject to the one month deadline) for final approval to publish the document. Once the ASC has voted its approval, the Release Managers shall post the new release on the community's web site and send an email announcing the release to the community mailing list.

[rhc54]

Suggestion: Rather than the second weak of the month for quarterly meetings, the third week may be better to avoid conflicts with holidays (e.g. Easter).

Done - moved to 3rd week of month

Suggestion: Provide a nomination process that allows members to nominate other strong contributors as members. The members then vote on adding the individual.

Made following change:

All new Members must either request membership or be nominated by an existing ASC Member, and be approved by the ASC according to the voting rules described below.

[rhc54]

Suggestion: Add sentence like “informal members are encouraged to attend quarterly meetings” to make it clear that the meetings are not exclusive to members.

Modified as below:

Informal participants do not have voting privileges on administrative matters, but are encouraged to attend the quarterly meetings and participate in those discussions.

[rhc54]

Note from the call today: There should be a line added about how the release cycle is tied to the quarterly meeting cycle (at most there is 1 minor release per quarterly meeting). So an interface that is going to change after two minor releases will have at least 6 months of runway before being changed/removed.

Made the following modification to the Release Manager section:

The Release Managers shall notify the Co-Chairs when a given release is complete and ready for publication. The Co-Chairs will add an item to the agenda of the next quarterly meeting (subject to the one month deadline) for final approval to publish the document. Once the ASC has voted its approval, the Release Managers shall post the new release on the community's web site and send an email announcing the release to the community mailing list.

Actually, I have revised this a bit more to provide some requested emphasis on the annual f2f meeting as a means of promoting attendance:

The Release Managers shall notify the Co-Chairs when a minor release candidate is complete and ready for publication. The Co-Chairs will add an item to the agenda of the next quarterly meeting (subject to the one month deadline) for final approval to publish the document. Once the ASC has voted its approval, the Release Managers shall post the new release on the community's web site and send an email announcing the release to the community mailing list. Minor releases, therefore, can occur on an at most a quarterly basis.

Major release candidates must be approved during the ASC's annual face-to-face meeting. Release Managers must notify the Co-Chairs of a major release candidate a minimum of two quarters before the target approval meeting. The Co-Chairs will add an item to the agenda of each quarterly meeting for discussion and review of the document, and on the face-to-face meeting for vote on final approval. Once the ASC has voted its approval, the Release Managers shall post the new release on the community's web site and send an email announcing the release to the community mailing list. Should the ASC not approve the release, subsequent release candidates can be considered at upcoming regular ASC meetings - i.e., the major release candidate does not have to wait for the next annual face-to-face meeting for reconsideration. However, no subsequent major release may begin the approval process until after the current candidate has been published. Major releases, therefore, can occur no more than once per year.

[artpol84]

Overall looks good.

[jjhursey]

I captured some notes from the teleconf today in the meeting notes on the wiki.

The general sense of the room is that this PR is a good path and nearly complete. For those that contributed comments please indicate those that have been resolved so we can focus on closing those unresolved discussion items.

Hope is that we stabilize this PR in the next week. Then during the following teleconf we can start the formal process of acceptance.

[rhc54]

I have updated the text per the comments from the telecon of 7/12/2019. Please take a look when you can!

[rhc54]

Dear all:

I have updated the document based on everyone's comments and squashed the results to allow for clean review of its current state. The only significant changes from this morning were:

• added election of two Secretaries to take minutes of meetings and maintain the web site - elections mirror the Co-Chairs
• moved the election to the last meeting of each calendar year, with new officers taking their positions at the beginning of the upcoming year
• modified the emoji list for the straw poll. Turns out that GitHub has restricted the number and type of the emojis one can assign to a comment.
• cleaned up some language per people's comments

Please carefully review the final doc. As per the telecon, I have attached a "straw poll" for your use, and we intend to take a formal vote on the governance document during the telecon of Aug 2nd

[rhc54]

Please use emoji reactions ON THIS COMMENT to indicate your position on this proposal.

* You do not need to vote on every proposal
* If you have no opinion, don't vote - that is also useful data
* If you've already commented on this issue, please still vote so
      we know your current thoughts
* Not all proposals solve exactly the same problem, so we may end
      up accepting proposals that appear to have some overlap

This is not a binding majority-rule vote, but it will be a very
significant input into the corresponding ASC decision.

Here are the meanings for the emojis:

* Hooray or Rocket: I support this so strongly that I
      want to be an advocate for it
* Heart: I think this is an ideal solution
* Thumbs up: I'd be happy with this solution
* Confused: I'd rather we not do this, but I can tolerate it
* Thumbs down: I'd be actively unhappy, and may even consider
      other technologies instead

If you want to explain in more detail, feel free to add another
comment, but please also vote on this comment.

outdated

[jjhursey]

Ref pmix/governance#1 (LaTeX translated version)

[jjhursey]

Vote Passed on Aug. 2, 2019 Teleconf (recorded in the meeting minutes ):

Yes:
 - Intel (sent via email to Co-Chair)
 - Argonne National Laboratory (sent via email to Co-Chair)
 - IBM
 - Altair
 - LLNL
 - ORNL
 - Microsoft
 - Cray
 - TU Munich
 - Sylabs
 - UTK

No:
 - 

Abstain:
 - 

[jjhursey]

Approved on teleconf.