Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure)

From: Eliot Lear <[email-masked]>
Date: Mon, 1 Feb 2021 09:59:12 +0100

Hi Martin,

Martin and all,

Let us put aside blocks for the moment, assuming that we are likely to find agreement that a block can be overridden.  That assumption is worth discussing, of course.  I’ve tried to put this into tabular form so that people have a feel for what we’re talking about:

If the RSE does not have a vote, but convinces another stream manager to block, the case we seem most worried about, then it takes three stream managers to override.  If the RSE does have a vote and also convinces a stream manager to join, it still requires three stream managers to override, and so there is no difference.

If on the other hand, the block has to be sustained by a vote, then there is a difference.  In this case, if the RSE has a vote, there needs to be agreement of two steam managers to sustain.  If the RSE doesn’t have a vote then three stream managers are needed to sustain.

And if two votes are required to block rather than a majority and the RSE has no vote, this means that all four stream managers would have to vote to override the RSE.

Thus the voting rules are important to understand.  Obviously I’ve only delved into one scenario, and there are others.  And there are of course other voting rules.  One challenge here is to determine which is the dog and which is the tail: Is it important to be respect streams so that damage cannot occur?  Is it important to support the will of the WG?  And of course, the parameters of why one can vote no matter.

Eliot

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 01 Feb 2021 20:37:58 +1100

Maybe I should have been clearer.  What I was talking about was an approval process that only really consisted of testing whether the approval body blocked the proposal.  I think that Russ phrased this as "two approvals and no block positions".

That would allow for abstention of two streams.  I honestly don't think that the number of approvals matters very much.  You just need to avoid approving proposals that are frivolous or that lack genuine interest.  I have no real position on whether the RSx should be allowed to engage in an approval process, because I don't think that it matters all that much.

My interest is in what blocking looks like and how an attempt to block might be overturned - if that is possible.

With a "voting" RSx, you have to decide a) whether the RSx can block, b) whether to automatically override a single block position, and c) what conditions overriding the block would need.

Without distinguishing RSx from stream manager roles, sensible values for N_block are 1 or 2.  But I would argue that overturning 2 block positions (which might represent 2 whole streams out of four) from a simple majority makes light of those taking block positions.  So I'm going to suggest that it doesn't make sense to allow for 2 block positions to be overturned, only 1 at most.  If there were significantly more streams involved, maybe 2 would make sense, but we aren't there.

My other point is that the basis on which the RSx would be blocking are not very clear.  If you distinguish RSx from stream managers and only allow stream managers to block, that might be better, but then you have the same problem as above.  You could add the RSx to any vote to overturn a block, but the real effect there is a new choice between 3/5 to overturn and 4/5 to overturn.

Note that in all cases, the individual (stream manager or RSx) were involved in the discussions and were found by the chairs to have been heard and their concerns addressed, even if they did not necessarily agree with that.  They are then exercising their unique option to formalize their objections.

For stream managers, who answer to their stream, I would expect their intentions to be clearly communicated and their block position only to occur after wide consultation (would would include the RSx, but also the IRSG/IESG/IAB/ISEB and various mailing lists as appropriate).  Ultimately, a stream manager has a system by which they are held accountable and I would expect that to be effective.

On Mon, Feb 1, 2021, at 19:59, Eliot Lear wrote:
> Hi Martin,
> 
> Martin and all,
> 
> Let us put aside *blocks* for the moment, assuming that we are likely 
> to find agreement that a block can be overridden.  That assumption is 
> worth discussing, of course.  I’ve tried to put this into tabular form 
> so that people have a feel for what we’re talking about:
> 
> 
> If the RSE *does* *not* have a vote, but convinces another stream 
> manager to block, the case we seem most worried about, then it takes 
> three stream managers to override.  If the RSE *does* have a vote and 
> *also* convinces a stream manager to join, it *still* requires three 
> stream managers to override, and so there is no difference.
> 
> If on the other hand, the block has to be sustained by a vote, then 
> there is a difference.  In this case, if the RSE has a vote, there 
> needs to be agreement of two steam managers to sustain.  If the RSE 
> doesn’t have a vote then three stream managers are needed to sustain.
> 
> And if two votes are required to block rather than a majority and the 
> RSE has no vote, this means that all four stream managers would have to 
> vote to override the RSE.
> 
> Thus the voting rules are important to understand.  Obviously I’ve only 
> delved into one scenario, and there are others.  And there are of 
> course other voting rules.  One challenge here is to determine which is 
> the dog and which is the tail: Is it important to be respect streams so 
> that damage cannot occur?  Is it important to support the will of the 
> WG?  And of course, the parameters of why one can vote no matter. 
> 
> Eliot
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
> 
> Attachments:
> * PastedGraphic-3.png
> * signature.asc

---

From: Eliot Lear <[email-masked]>
Date: Mon, 1 Feb 2021 12:00:17 +0100

Hi Martin,

> On 1 Feb 2021, at 10:37, Martin Thomson <[email-masked]> wrote:
> […]
> 

Clarifying the implications of the latter was the purpose of my email, simply to articulate implications of different voting systems, including what it would mean for a block to be overturned.

> With a "voting" RSx, you have to decide a) whether the RSx can block, b) whether to automatically override a single block position, and c) what conditions overriding the block would need.

Indeed.

> Without distinguishing RSx from stream manager roles, sensible values for N_block are 1 or 2.  But I would argue that overturning 2 block positions (which might represent 2 whole streams out of fou…

Right. What the table I generated shows is that if you go with “2 blocks cannot be overridden”, that means, in order to override, if the RSx has a vote, that requires all four streams to override.  You can decide for yourself whether you view that as a high bar or not, but I think Joel also took this case off the table, by saying that the RSx should not on his or her own be able to block, but perhaps I misunderstood his position.  If that is the prevailing view if the RSE has a vote, then we are talking 3/5 to override; and if the RSE doesn’t have a vote, we would be talking 3/4 to override, the key # being 3.  Things go a little differently if the RSE is in the group that overrides.  That would mean that it would be possible for two stream managers to be overridden.

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 1 Feb 2021 09:27:04 -0500

I think there are two aspects about which your table seems to be misleading.

First, and most important, I want the structure to be robust if we add 
or remove a stream.  Focusing on the exact number obscures that.

Secondly, whether a person has a formal say in the decision (whether we 
call that a vote or a requirement for consensus, or a DISCUSS position 
doesn't matter) or does not have such a formal say inevitably affects 
the interaction with the rest of the body.  I think it is important for 
the way I at least want the RSE/A viewed that they have the same kind of 
say that the stream managers have.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Feb 2021 17:42:43 +1300

> say that the stream managers have.

Exactly.

Why are we in trouble? Because the previous RSE felt they were not being
treated as a colleague with relevant expertise but as a hired hand.
The one mistake to avoid above all is re-creating that situation.

I think we shouldn't use the word "vote" at all, nor "block". The
approving body rule should be: consensus. If that means long arguments
to clear a "discuss" by any member, so be it. It's not as though
this body will be reviewing a very large number of documents.

   Brian

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 2 Feb 2021 14:23:08 +0100

I think I could see a shepherd-like role for the RSx in the process, where the RSx write some kind of short report for the approval body that summarises the process and the impact on the series as a whole from his/her point of view. In that process I think it would also make sense for the RSx to directly participate in meetings of the approval body and have an additional chance to discuss and explain any concerns directly with stream managers. However, I support Martin’s proposal (I might wrongly attribute this to Martin but he most recently expanded his view on the list) where only stream managers can block (and only one is needed for the block) but the block has to be back-up in some way by community input for the respective stream.

Mirja

> On 1. Feb 2021, at 15:27, Joel M. Halpern <[email-masked]> wrote:
> 
> First, and most important, I want the structure to be robust if we add or remove a stream.  Focusing on the exact number obscures that.
> 
> Secondly, whether a person has a formal say in the decision (whether we call that a vote or a requirement for consensus, or a DISCUSS position doesn't matter) or does not have such a formal say inevitably affects the interaction with the rest of the body.  I think it is important for the way I at least want the RSE/A viewed that they have the same kind of say that the stream managers have.
> 
> Yours,
> Joel
>