Subject: [Rfced-future] Going forward - some issues

From: Eliot Lear <[email-masked]>
Date: Thu, 28 May 2020 12:30:43 +0200

Hi everyone,

We’ve had a very free ranging discussion over the last few weeks.  I thought yesterday’s call was very helpful.  A few points that I would like to address going forward:

Bike shedding

We have a tendency to get into a lot of details about how the series is formatted, and I have received several complaints.  Formatting is not something that this group should discuss.  The only issue for this group is who gets to decide that question.  Nothing more.  Lower than that I now propose to rule out of scope.  In general, when you post, please relate the note to governance or definition of one or more of the roles in the system, and avoid doing that person’s job in this WG.

Relationship between series evolution and governance

Mike made a key observation yesterday in support of independence that I want to highlight, because I think it goes to the heart of governance:  he said that our rough consensus processes can paralyze decision making.  I think we have all seen that happen at the IETF in particular.  There is value in moving slowly in evolutionary terms, but there is also value in recognizing that filibustering can entirely stop evolution.  As we consider governance approaches for the RSE, we should also consider whether rough consensus is an appropriate model for change.

Engagement Model

There was a lot of discussion yesterday about the customer/vendor model, and what it means to interact with professionals who are well outside our scope of expertise.  EKR gave the example of a lawyer he might employ, for instance, where as Colin pointed out that the respect and attachment to people who are labeled “contractors” might have some cultural differences.  Mark pointed out on list that he hasn’t seen people show disrespect toward the RPC.  Indeed, I would go further and say that on the whole we do not show disrespect to those who we clearly see in a supporting role to the organization.

RFC 8728 does not use the word “customer”.  This is a new word in the RSE vocabulary.  Adrian made the point early on that if we are to use this term, we need to define the role.  That is smack in the middle of our charter.  As I reads things, we have two definitions proposed within the group, and I will add a third and a fourth for discussion purposes:

A working group along the lines that Nevil mentioned in his draft
A committee that Mike mentioned in his proposal
The stream managers
The RSOC (status quo)

I do not endorse any of these.  I would ask for conversation about any of the four of these, or any other group you would like to formulate (you needn’t stick to those four).  For discussion purposes, I propose that we accept the rebuttable presumption that these groups are responsible for setting qualifications on the role of RSE, that they may range those qualifications from pencil pusher to anointed Grand Poobah of the Series.

In considering these groups, it is important for people answer these questions:

Who is accountable to the community for the series and how?  If something goes wrong again, how does the community express its displeasure?  To put a fine point on this: if you define customer as coders, you should be able to define an accountability mechanism to them.  Otherwise you might think in terms of proxies.

What is the relationship between each entity in the system?  Specifically, the RSE, these committees, the other governing boards (the IAB, IESG, LLC), the Executive Director, and the RPC?

Format of proposals

As we move forward, email messages or drafts for proposals are fine.  I will capture the key points on Github.  As I mentioned yesterday, I propose to seek a neutral editor for a consensus draft at least on the problem space, and then aiming toward solutions.

Comments?

Eliot