Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th

From: Eliot Lear <[email-masked]>
Date: Thu, 1 Apr 2021 09:14:34 +0200

> On 1 Apr 2021, at 00:23, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Eliot,
> 
> I'm fine with this text, provided that we can file issues against this text and expect to have them seriously considered by the group. In other words, I'm interpreting your question here as what we'd consider a Call for Adoption in the WGs I participate in regularly -- this text is a good starting point, but isn't sacrosanct, and doesn't have any higher bar for changes than usual.

Correct.

> 
> If your intent differs from that (e.g., we need some sort of consensus to even consider an issue), please say so.
> 

It does not.

As new proposals come through, from you or from others, as a co-chair, I expect everyone to show give and take.  Also, I don’t think any of us want the process to drag out indefinitely.  What I’m hoping is that PRs can get generated within a month or so of the adoption of this work.  Then we’ll see where we are in terms of timing.

That means people should be thinking now in terms of what PRs they would like to create.

Eliot

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 02 Apr 2021 07:30:21 +1100

As a starting point, this is good.  Let's get this somewhere we can collaborate on it properly.

On Wed, Mar 31, 2021, at 04:51, Eliot Lear wrote:
> The chairs appreciate comments received, and we now believe that it is 
> ok to start a  consensus call on the chairs’ proposal on both the draft 
> evolution process and the RSE hire and accountability text, taken as a 
> whole.  If you have already indicated your support for the proposal, 
> the chairs will note this.  *We would like to hear from all interested 
> participants*.  If you would like to indicate either support or 
> objection, please feel free to do so by Tuesday, April 13th.
> 
> If there is rough consensus, this text will be included in the editor’s 
> draft.  It can be further amended with rough consensus, and the chairs 
> expect there to be some of that.  Again, we see this as compromise 
> text, and so we are hoping that this is a good enough starting point 
> for further modifications.
> 
> As a reminder, we have an interim meeting scheduled for next Tuesday, 
> April 6th, 2021, at 20:00 GMT, when of course this proposal will be on 
> the agenda for people to discuss.  More about that agenda in the next 
> day or two.
> 
> The text can be found on GitHub in two parts at the following URLs:
> 
> https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md
> https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md
> 
> And it is below for your consideration as well.
> 
> Brian and Eliot
> 
> 
> DRAFT RFC Evolution Process
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#scope>
> 
> 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.
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#structure>
> 
> 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.
> Each group is described below.
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#the-rfc-working-group-rfcwg>
> 
> 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.
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#the-rfc-approval-board-rfcab>
> 
> 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.
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#update-process>
> 
> Update Process
> 
> The following procedure is used to update the RFC process:
> 
>  1. Someone writes a draft proposal in the form of an Internet-Draft.
> 
>  2. 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.
> 
>  3. The RFCWG will then further develop the proposal. All members of 
> the RFCAB are expected to participate in discussion relating to all 
> proposals.
> 
>  4. 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.
> 
>  5. 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.
> 
>  6. 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.
> 
>  7. Should substantial changes be made, additional community calls for 
> comment should be issued, and again comments considered.
> 
>  8. Once all comments have been been addressed, the working group 
> chairs will transmit the latest proposal to the RFCAB.
> 
>  9. 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.
> 
>  10. If a CONCERN exists, discussion will take place within the RFCWG. 
> Again, all RFCAB members MUST participate.
> 
>  11. 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.
> 
>  12. 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.
> 
>  13. When a proposal is approved, a notification is sent to the 
> community, and it is published as an RFC.
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#the-roles-of-the-llc-board-and-ed>
> 
> 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.
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#appeals>
> 
> 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.
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#discussion>
> 
> 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.
> 
> DRAFT DRAFT DRAFT
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md#rsea-selection>
> 
> 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.
> 
>  
> <https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md#rsea-ongoing-performance-evaluation>
> 
> 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.
> 
> -- 
> Rfced-future mailing list
> [email-masked] <mailto:Rfced-future%40iab.org>
> https://www.iab.org/mailman/listinfo/rfced-future
> 
> Attachments:
> * signature.asc

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 2 Apr 2021 18:30:29 -0600

> As a starting point, this is good.  Let's get this somewhere we can collaborate on it properly.

It's here:

I'm working on a first draft of an I-D we can work from, as well, and
will have that ready by Monday so that we can discuss on Tuesday.

Peter

---

From: Eliot Lear <[email-masked]>
Date: Sat, 3 Apr 2021 10:52:11 +0200

And while it’s okay to generate a PR to that text in GitHub, all discussion about the change should occur here, please.

> On 3 Apr 2021, at 02:30, Peter Saint-Andre <[email-masked]> wrote:
> 
> [email-masked]