Re: Alternative decision process in RTCWeb

[Ted Hardie <[e-mail]>]

On Sun, Dec 1, 2013 at 3:35 PM, Melinda Shore <[e-mail]>wrote:

> On 12/1/13 8:01 AM, Ted Hardie wrote:
> > For what it's worth, all the chairs agree that failure to get consensus
> > is a valid outcome and it may be where we end up.  The internal
> > discussion among the chairs and RAI ADs was extremely extensive and not
> > at all fun; think soul-searching, beating of breasts, tearing of sack
> > cloth, and wearing of ashes.   Trust us that we did not do this lightly;
> > as one of us put it in the internal discussion: "We're going to get an
> > epic beat down for this".
>
> You did not receive an "epic beat down" although I think you
> probably should have (or something like one).


Well, the week is young, and lots of Americans were off.


>  What you did
> was huge and has impacts far outside the scope of one
> decision in one working group.
>
>
Just to get the tense structures right, we are currently in the "a proposal
has been made to the working group and will be revised" phase.  The next
step, should we get there, is a consensus call to use this alternative
process.
That is *explicitly* using our standard process for reaching consensus, as
Magnus's note to the working  group makes clear.


> Look, I've been feeling for some time that our decision-making
> structures don't work for us anymore - that there are too many
> people looking for optimal personal outcomes (as opposed to
> optimal organizational, good-for-the-internet outcomes), there
> aren't enough people invested in a healthy process, and that
> it's become incredibly difficult - too difficult - to reach
> decisions in a contested space.  However, changing decision-
> making to a voting-based process assumes changes to the
> organization that I think are devastating.  When we distinguish
> between those who are eligible to vote and those who aren't
> we create a membership, and when we vote and have a membership
> we enter into the very nasty problem of balancing what I think
> is our most important organizational characteristic - openness -
> against the problem of ballot box stuffing.
>
>
The chairs and ADs discussed this set of issues at great length and
proposed this despite those (with a great deal of queasiness and
and discomfort, I reiterate).  We did so because we think we will
_lose interoperability_ if we don't get a decision here.  I agree with you
that our greatest organizational characteristic is openness, but our
biggest focus as an engineering organization is interoperability.  If
we give that up because our process can't get us there, we have lost
something quite real.  Not just relevance, but an opportunity to make
the Internet better by enabling an ecosystem the really enhances what
we can do with the web.  That's an opportunity cost that cuts all of us
who have been working on this pretty hard.

I don't ask you to love this idea; I don't.  I do hope you understand the
hard place on the other side of the rock.



> We were quite successful in minimizing the impact of the EFF-
> motivated mailing list deluge on the TLS authz patent, which
> I don't think we could have done if we'd been using the
> processes you've invented.  We certainly wouldn't have been
> able to have a good outcome in nvo3.  Speaking of which, that
> working group was deadlocked for quite awhile but managed their
> way out of it without going to a voting model.
>
> I think that we're not that far away from needing to take
> a long, hard look at how we're structured with an eye towards
> what we need to do to maintain our openness while remaining
> effective.


I agree, but unfortunately the last few process changes have all
gone forward in ways that strongly indicate that the organization
is only willing to consider incremental change (and that mostly done
outside of working group processes).  What you describe may require
a little more punctuated equilibrium than we can currently muster.


>  I think the particular situation in WebRTC, with
> a roll-your-own voting process, is absolutely the wrong
> context for doing that - it needs to be done at the pace at
> which it needs to be done and it needs to be done thoughtfully
> and thoroughly, and not because one particular working group
> can't figure out how to go forward but needs something now.
>
>
"Wait for it" means "lose interoperability".  Whether that wait is
for the market to decide, for the IETF to find new processes, or for new
codecs without IPR to appear.

Just so we're clear.

Ted


> Melinda
>
>