Skip to content

Commit

Permalink
Merge pull request #29 from jjhursey/rfc-errata
Browse files Browse the repository at this point in the history
Errata Changes Process
  • Loading branch information
jjhursey authored Jul 26, 2021
2 parents 80833f6 + e7ecc10 commit 6bd6b41
Showing 1 changed file with 98 additions and 0 deletions.
98 changes: 98 additions & 0 deletions pmix_governance.tex
Original file line number Diff line number Diff line change
Expand Up @@ -1349,4 +1349,102 @@ \subsubsection{Major Text Changes}%
accepted and that actual publication of the accepted proposal must be
included in the next major release of the standard.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\hypertarget{errata-changes}{%
\subsubsection{Errata Changes}%
\label{errata-changes}}
Errata changes are defined as ``small'' changes that correct errors or clarify ambiguities in the document.
The definition of ``small'' is determined by the members of the ASC.
As such, any errata item may be deemed by an ASC member as a major change (e.g., because it changes semantics in a subtle, but significant way) and thus need to go through a more formal process such as the \hyperlink{provisional-acceptance}{Provisional acceptance} process.
Note that for typos or grammar edits the \hyperlink{administrative-changes-guidance}{Minor Document Changes Guidance} applies.
The process for errata changes begins with a GitHub Draft PR while writing the proposal, optionally proceeded by a GitHub Issue for more general discussion and guidance.
When the GitHub PR is ready for discussion the authors(s) must remove the Draft PR status, add the ``RFC'' and ``Errata'' labels, and add the Straw Poll Comment to it.
Then the author(s) must send an announcement of the PR to the PMIx community mailing list requesting consideration of the PR as an errata change.
This starts the more formal discussion and Straw Poll voting process.
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 tally of votes per emoji category, as defined above.
The author(s) must engage with any concerns raised on the PR in an attempt to
resolve those concerns before moving to the next stage in the process.
The ASC Co-Chairs shall monitor the status of discussion on the PR. Once
discussion appears to have consolidated (either measured by
participation in the Straw Poll, rate of comments, or a combination of
both), or at the request of the proposal's author(s), the Co-Chairs will
schedule the proposal for a reading at the next quarterly meeting of the
ASC. The proposal shall be included in the announced agenda for the
meeting along with a link to the PR.
The Co-Chairs shall label the PR as ``Eligible'' to indicate that the proposal is
eligible for formal consideration by the ASC at the next quarterly meeting.
At least one proposal author must attend the quarterly meeting to
present the PR and participate in discussion regarding its approval. A
\textit{Reading} of the proposal shall be conducted at the meeting with the
author(s) reviewing any questions/concerns raised and how they were
addressed. During the presentation, someone designated by the Co-Chairs
will take notes on the PR (and/or Issue) on behalf of the presenter.
At the conclusion of the reading, a formal vote of the ASC shall be held
(per the above voting rules) to determine if the proposal is accepted or
pushed back for further modification.
The Co-Chairs shall set a GitHub label indicating the
result as either ``Accepted' or ``Pushed Back''.
Accepted proposals can be committed to the next minor release version by
the Release Manager in accordance with their schedule.
Proposals that are pushed back for further work can be brought forward
again at a later date, or can be withdrawn by the author(s) by
closing the PR.
\hypertarget{process-flow-for-errata-changes}{%
\paragraph{Process Flow for Errata Changes.}%
\label{process-flow-for-errata-changes}}
In summary, the flow for proposing and gaining approval of a errata change consists of the following steps:
\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\tightlist
\item
Optionally, open an Issue describing the proposed change to serve as a discussion
forum
\item
Open a Draft PR while writing the proposal itself
\item
When the PR is ready for discussion:
\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\tightlist
\item
Remove the Draft PR status
\item
Label the PR ``RFC'' and ``Errata''
\item
Add the Straw Poll Comment to request feedback
\item
Send announcement to the mailing list that it is ready for formal review
\end{enumerate}
\item
Discuss PR - only new commits can be added
\item
ASC Co-Chairs will schedule the proposal for Reading at next quarterly
meeting and label the PR with ``Eligible''
\item
Author(s) present proposal for review at quarterly meeting
\item
Formal ASC vote taken to designate as ``Pushed Back'' or ``Accepted''
\item
Accepted proposals merged by Release Managers
\item
Any corresponding Issue(s) are closed
\end{enumerate}
Note that an errata changes proposal could be accepted in as little as one quarterly
meeting.
\end{document}

0 comments on commit 6bd6b41

Please sign in to comment.