Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight

["Martin J. Dürst" <[e-mail]>]

Hello Eliot, everyone,

On 2021/03/24 22:02, Eliot Lear wrote:
> Everyone,
> 
> Thanks for your patience.  As promised at our meeting, the chairs are putting forward a proposal to move forward.
> 
> This proposal comes in two parts.  The first part is the process for how drafts are developed and approved – or not.  It is loosely based on what Joel presented at IETF 110, but also incorporates earlier agreed text about the RFCWG.  In this proposal, the RS[EA] does get a say on the Approval Board.  However, that person’s is one voice out of five.
> 
> As a companion part of this proposal, and as discussed at IETF 110, the second part discusses the hiring and oversight of the RS[EA].

Many thanks for your proposals. I have read them, and agree with the 
general direction.



> A few points:
> 
> The first part in particular is intended as a compromise between very different points of view.  We do not expect anyone to be perfectly happy with what is written, but we do ask everyone at this late stage to withhold objections unless they positively cannot live with what is written.
> Assuming there is rough consensus for this base text, changes can be made again based on rough consensus.  Surely some will be needed here and there.
> The second part of the proposal is something on which we have spent less time.  It provides a fair amount of freedom to the LLC to set timing and working method of the role.  We expect this text to evolve a bit more, but again ask that it be accepted as base text.
> 
> Our proposal is that people take a day or so to read through and consider both texts, and then ask questions or comment on list.  When commenting settles down, we will open a consensus call.  Because there was a specific request for the accountability text as part of all of this, the consensus call will be to take both parts as a whole as base text.
> 
> Without further ado, please see the text below, which can also be found on GitHub:
> 
> https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md>
> 
> And
> 
> https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md <https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md>
> 
> Eliot & Brian
> 
> —
> Part 1
> 
> 
> DRAFT RFC Evolution Process
> Scope
> This procedure is applicable to the evolution processes relating to the management and evolution of the RFC series, including format, tooling, publication, dissemination, and overall management of the series.
> 
> Structure
> The RFC evolution process is governed as follows:
> 
> The RFC Working Group, whose job it is to develop proposed changes, and establish community consensus of those changes.
> The The RFC Approval Board, whose job it is to provide final review of proposals.

Nit: Superfluous 'The'. I noticed at least one other place where there 
were repeated words.

> Each group is described below.
> 
> The RFC Working Group (RFCWG)
> 
> All RFCWG meetings are open to any participant, subject to intellectual property policies which must be consistent to those of the IETF [Note Well]. At body's initial formation, all discussions are to take place on open mailing lists, and anyone is welcome to comment / discuss. The RFCWG may decide by rough consensus to use additional forms of communication (for example, Github as specified in [RFC8874]) that are consistent with [RFC2418]. The group will conform itself to an anti-harassment policy consistent with [RFC7154,RFC7776].
> 
> IETF chair and the Independent Submissions Editor shall each appoint and oversee a co-chair of the RFCWG.
> 
> The RFC Approval Board (RFCAB)
> 
> The RFC Approval Board consists of representatives from each RFC stream (at the time of this writing, the IAB, the IETF, the IRTF, and the Indepenent Series), as well as the RS[EA]. The sole function of this group is to review draft proposals approvedby the RFCWG. The RFCAB may choose its chair as it sees fit. The group is primarily expected to operate via email and through any necessary tooling. A record of all proceedings (no matter the form) will be kept.
> 
> Update Process
> The following procedure is used to update the RFC process:
> 
> Someone writes a draft proposal in the form of an Internet-Draft.
> If there is sufficient interest in the proposal, RFCWG will adopt the proposal as a working draft, much the same way a working group of the IETF would.
> The RFCWG will then further develop the proposal. All members of the RFCAB are expected to participate in discussion relating to all proposals.
> At some point, if the chairs believe there may be rough consensus exists for the proposal to advance, they will issue a working group last call.
> After a suitable period of time, the chairs will determine whether rough consensus for the proposal exists. If comments have been received and substantial changes have been made, it is expected that additional last calls may be made.
> Once working group consensus is established, a community call for comments will be issued. Should substantial comments be received, the working group will again consider those comments and make revisions as they see fit. At this same time, the RFCAB will consider the proposal.
> Should substantial changes be made, additional community calls for comment should be issued, and again comments considered.
> Once all comments have been been addressed, the working group chairs will transmit the latest proposal to the RFCAB.
> Within a reasonable period of time, the RFCAB will then poll on the proposal. Positions may be as follows:
> 
> "YES": the proposal should be approved
> "CONCERN" : the proposal raises substantial concerns that must be addressed.
> "RECUSE" : the person holding the position has a conflict of interest.
> Anyone holding a "CONCERN" position MUST explain their concern to the community in detail. The explanation may or may not be actionable.
> 
> A CONCERN may be made for two reasons:
> 
> The proposal represents a serious problem for the group a particular member represents.
> The member believes that the proposal would cause serious harm to the overall series, including harm to the long term health and viability of the series.
> No CONCERN should ever come as a surprise to the RFCWG.
> 
> If a CONCERN exists, discussion will take place within the RFCWG. Again, all RFCAB members MUST participate.
> 
> If all CONCERN positions are addressed, then the proposal is approved. Again, if substantial changes have been made, an additional call for community input should be made.
> 
> If, after a suitable period of time, any CONCERN positions remain, a formal vote of the RFCAB is taken. If a majority of RFCAB members vote to approve, the proposal is approved. Otherwise, it is returned to the RFCWG. In the case of a tie, the proposal is approved.
> 
> When a proposal is approved, a notification is sent to the community, and it is published as an RFC.
> 
> The roles of the LLC Board and ED
> 
> LLC Board members, staff, and the Executive Director, are invited to participate as community members in the RFCWG to the extent permitted by any relevant LLC policies.
> 
> Appeals
> Appeals of RFCAB decisions may only be made based on process failures, and not on the substance of a proposal. These appeals SHALL be made to the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY decide only whether a process failure occurred, and what if any corrective action should take place.
> 
> Discussion
> The intent of this policy is to provide an open forum by which policies and procedures of the RFC series are evolved. The general expectation is that all interested parties will participate in the RFCWG, and that only under extreme circumstances should the RFCAB members have to hold "CONCERN" positions. To avoid that situation, WG members are encouraged to take RFCAB concerns seriously, and RFCAB members are encouraged to make those concerns known early, and to be responsive to the community. In particular, people are encouraged to respect the value of each stream, and the long term health and viability of the RFC series.
> 
> This process is intended to be one of continuous consultation. In particular, RFCAB members should be consulting with their constuent groups on an ongoing basis, so that when the time comes to consider a proposal, there should be no surprises. Appointing bodies are expected to establish whatever processes they deem appropriate to facilitate this goal.

The main points that I'd like to discuss further (after in general 
adopting the above proposal!) are:

- "In the case of a tie, the proposal is approved.": That would 
essentially mean 2 for, 2 against, and 1 recuse. I think that's a very 
thin base for a change.

- There are various pointers to IETF process and the relevant RFCs. In 
order to avoid future discussions and hairsplitting, I think it would be 
good to somewhere state that where there are accidental differences in 
wording, the intent is to align with IETF process.


> Part 2
> 
> DRAFT DRAFT DRAFT
> RS[EA] Selection
> The RS[EA] will be searched for and vetted by a committee formed by the ED, taking into account the role definition <https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-RSE-role.md> and any detailed job description that we further develop. The search committee may ask others to take part in the selection process in confidence. The initial length of service shall be for one year, but then further extensions will be for three to five years.
> 
> RS[EA] Ongoing Performance Evaluation
> Periodically, the ED will send out to the community a call for input on the performance of the RS[EA]. The evaluation will be based on criteria specified in the role definition. Was the RS[EA] an active participant in all/most meetings? Did the RS[EA] provide useful advice to the RPC and to the WG? Did the RS[EA] exercise good judgment in terms of any role he or she would have had on the Approval Body? Was the RS[EA] effective in advising the community on appropriate actions to take or not take?
> 
> The ED will then review the feedback, consulting with stream manager representatives, and then produce a recommendation to the LLC Board. The LLC will then make a decision, taking into account that recommendation.
> 
> Whether the RS[EA] role is structured as a contractual or employee relationship is left to the LLC and ED to determine.

This excludes all the day-to-day activity that past and current role 
holders have had. I think that's the direction this group has been 
moving towards, and I can live with it, but I think we need to work this 
out much more carefully, to avoid gaps or overlaps (with the potential 
of conflict) especially in areas such as style guide,...

Regards,    Martin.