Re: Alternative decision process in RTCWeb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Dec 1, 2013 at 3:35 PM, Melinda Shore <melinda.shore@xxxxxxxxx> 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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]