Re: Poll for preferred API alternative

On 08/31/2012 12:52 AM, Matthew Kaufman wrote:
> I cannot answer any of the three proposed alternatives because I have
> to objection to the substance of this "poll".

Matthew, I'm sorry that you can't answer.

>
> On the call, it was clear that there were at least three, if not
> four, areas of possible contention. One was "the stuff we all agree
> needs to be added", and I don't think we need a poll for that. The
> second (and third, if split) was the use of SDP as the API surface,
> and in particular the use of SDP Offer/Answer semantics with that
> API. And finally was whether PeerConnection should be replaced by a
> larger number of objects with more specific functions.

When we looked at the alternatives presented, and the discussion so
far, it was clear that on these two points, there was a binary
decision to make: Either we would do them, or we would not do them.
If either step is taken, it will mark a major architectural change to
the current APIs.

We therefore made it our first order of business whether or not the
group's opinion was leaning one way or another on these proposed
"major reset" changes.

Regardless of the outcome of this poll, the "list of stuff that is
proposed to be added" should be addressed. But it is very difficult to
address it in a meaningful way (i.e. discuss how to support certain 
feature we agree should be supported) without having the foundation.

>
> So in that sense, the below poll fails to allow participants to
> express a desire for (for instance) removing the Offer/Answer state
> machine and possibly SDP while keeping the existing PeerConnection
> object.
>
> In addition, I believe that conducting the poll in the below fashion
> will fail to meet the guidelines specified at
> http://www.w3.org/2005/10/Process-20051014/policies.html#managing-dissent
> ...namely the statement,  "Groups SHOULD favor proposals that create
> the weakest objections. This is preferred over proposals that are
> supported by a large majority but that cause strong objections from a
> few people."
>
> A poll which attempts to determine what creates the weakest
> objections for each of the points of contention would be appropriate.
> (By, for instance, asking which alternatives one could live with vs.
> what would be highly objectionable.)

Again, on these particular items, the choice is to do or not to do;
there is no "halfway point" here. It was clear from the call that some
people are strongly in favor of one and some people are strongly in
favor of another.

Once the chairs have studied the result of the poll, we'll be ready to
propose a plan for going forward. Of course the plan will then be 
discussed in the group.

> One which attempts to lump the
> issues together and determine what is supported by the largest
> majority is not. The below statement "If this call results in a clear
> preponderance... the WG chairs will take that as direction" combined
> with the questions posed DOES NOT COMPLY with the W3C process as I
> understand it.

Your concern has been noted.

Stefan for the chairs

>
> Matthew Kaufman
>
> -----Original Message----- From: Stefan Hakansson LK
> [mailto:stefan.lk.hakansson@ericsson.com] ...
>
> The two alternatives, as the chairs see them, are the following:
>
> 1) Continue with a design based on the PeerConnection object, using
> SDP as part of the API, roughly in the style of the current API
> description. 2) Remove the PeerConnection object and all use of SDP
> from the API, and pursue an API roughly in the style of Microsoft's
> CU-WebRTC proposal.
>
> In order to make this call, we're calling for the WG participants to
> make their opinion known, by indicating one of three alternative
> opinions:
>
> 1) The group should continue with a design based on the
> PeerConnection object, using SDP as part of the API. 2) The group
> should remove the PeerConnection and all use of SDP from the API, and
> pursue a design based on the CU-WebRTC proposal. 3) This participant
> does not have enough information to state an opinion at this time.
>
> The chairs will make the result of the opinion tally public after the
> end date.
>
> If this call results in a clear preponderance for one of the
> alternatives, the WG chairs will take that as direction - if the last
> alternative has a clear preponderance, the WG chairs will direct the
> WG pursue further discussion of this topic only, putting all other
> work on hold until this is resolved; in the two other cases, the
> chairs will direct the WG pursue the chosen design option, and leave
> the other to others to follow up if they wish, but not drive it
> further in the WG.
>
> This is not a vote - it is a tallying of opinions. If a preponderance
> of preference is clear, the chairs will ask the WG if it agrees that
> a consensus exists to proceed based on that preference.
>
> Please state your opinion before Friday, Sept 7, and communicate this
> to the chairs. Mail to the list is an acceptable means of
> communicating your opinion.
>
> Stefan for the chairs
>
>
>

Received on Friday, 31 August 2012 14:21:10 UTC