RE: Issue 30 (Was: RE: Getting HTML5 to Recommendation in 2014)

> From: Maciej Stachowiak [mailto:mjs@apple.com]
> 
> On Sep 20, 2012, at 1:01 PM, Adrian Roselli <Roselli@algonquinstudios.com>
> wrote:
> 
> >> From: Maciej Stachowiak [mailto:mjs@apple.com]
> >>
> >> On Sep 20, 2012, at 12:14 PM, Adrian Roselli
> >> <Roselli@algonquinstudios.com>
> >> wrote:
> >>
> >>>>> 2. Not acting because there *may* be a Formal Objection isn't a
> reason.
> >>>> Granted, I don't know the players, who might object or how complex
> >>>> that process is. If I tell a client I'm not going to follow the
> >>>> agreed scope of work (the existing committed process and deadline,
> >>>> in this analogy) because he or she may object, I'd expect to be fired.
> >>>> I'd continue to move ahead and follow the expectations that have
> >>>> already been set. A Formal Objection will be dealt with, but at
> >>>> least there
> >> will be *movement*.
> >>>>
> >>>> There is no "may" about it.  We have people making such statements
> >>>> without having even seen a decision.  We have every reason to
> >>>> believe that they will follow through.  And that resolving such FOs
> >>>> will delay our
> >> entry to CR.
> >>>
> >>> Now you have me in a process knowledge-gap.
> >>>
> >>> Will a Formal Objection to an attribute that isn't even in the spec
> >>> really
> >> delay an end of 2014 CR date? Is the process that complex?
> >>
> >> All Formal Objections must be fully processed before we can enter CR.
> >> So it would shift all milestones starting with entry to CR by however
> >> long that takes.
> >
> > I don't know what "processed" means in this context (I understand it with
> meat, not with FOs).
> >
> > Can a Formal Objection be processed by declaring it as a future extension
> spec? Is there a document somewhere that tells me what the processes are?
> 
> This portion of the W3C Process document describes what happens to
> Formal Objections:
> 
> http://www.w3.org/2005/10/Process-
> 20051014/policies.html#WGArchiveMinorityViews
> 
> An informal description:
> - The Director normally takes up Formal Objections when a transition call
> comes in.
> - The Director gets input from the originator of the objection as well as the
> Chairs on behalf of the WG
> - The W3C Team advises the Director on a ruling.
> - The Director posts a ruling.
> - The Working Group must implement the ruling.
> 
> Based on past experience, I expect this to be a 1-3 month process, perhaps
> even more for rulings that require spec changes which are not specified in
> full detail.

Thanks. I appreciate the extra detail.


> >>> Is it likely that there may be other Formal Objections to other
> >>> aspects of
> >> the spec? Should we toss those aspects aside if someone threatens a
> >> Formal Objection?
> >>>
> >>> Yes, those are rhetorical, but it seems to me this approach enables
> >>> anyone
> >> who wants to threaten a Formal Objection as a way to strong-arm an
> >> action (or lack of action).
> >>>
> >>> To me, that isn't a reason to stop moving ahead on this or other
> >>> issues that
> >> are already in play.
> >>
> >> We hope that in this case, an extension spec can be a compromise that
> >> will not lead to strong objections from either side. We may be wrong
> >> on that. But the W3C Process requires groups to find proposals that
> >> draw the weakest objections. The Director has made clear to the
> >> Chairs that, while it may not be possible to avoid every Formal
> >> Objection, the WG should not run headlong intot hem either.
> >
> > What I am reading here is that if I don't like how an aspect of the spec is
> coming along, I can threaten a Formal Objection and the Chairs, at the
> direction of the Director, should avoid doing that thing that made me
> threaten it.
> >
> > This sounds like a broken policy that enables threats of a FO. Moreso if the
> "processing" method is overly complex.
> 
> We expect the Director to look at whether Formal Objections are made in
> good faith. In this case, there are material arguments to be made for both
> sides. Also, given the history of the issue, both sides would have particular
> reason to be upset by a ruling against them. The proponents of adding back
> longdesc went to a great effort to gather data to reopen the issue. If they got
> rejected a second time, they may feel like the process was a shame. On the
> other hand, proponents of keeping longdesc out won on the merits the first
> time around. They may be upset if that victory is yanked away from them.

I understand your point, but feelings will be hurt by any decision. I don't think that should be a concern.


> None of this means that, in general, just threatening a Formal Objection is a
> trump card. The W3C Process also says:
> 
> "Dissenters cannot stop a group's work simply by saying that they cannot live
> with a decision. When the Chair believes that the Group has duly considered
> the legitimate concerns of dissenters as far as is possible and reasonable, the
> group should move on."
> <http://www.w3.org/2005/10/Process-20051014/policies.html#managing-
> dissent>

Sounds to me like the Formal Objection that has been threatened, as defined by Sam in his email ("There is no 'may' about it.  We have people making such statements without having even seen a decision.") [1], is actually being used as a trump card.

It sounds to me like the survey should proceed and the threatened FO should be dismissed (again, using Sam's language, since I am not privy to the language of the threat).


> That is why we are floating the compromise solution of extension spec as the
> path forward. I would appreciate your input on the merits of that
> compromise (is it sensible? can you live with it?) rather than just debating
> whether we should press forward instead.

I'm trying to understand the process, but couched in that is the idea that I do not like an extension spec to address issues like this.

Adding a brand new element or attribute, sure. Probably a good fit for <picture>, for example.

Re-instating an element or attribute that existed in a prior release? No, I think that gap leads to confusion and more of an excuse for both developers and browser makers to fail to support it in any way. If it's on the ropes now, it's doomed to failure if it comes out as an extension.

Bear in mind -- my understanding of extension spec is just what I have gleaned by reading other posts on the list since this new approach was proposed...barely 24 hours ago.

Part of my desire to press forward is because in researching issue 30 I see commitments made that have not been met, for various reasons. Most notably a date on the issues list that has already passed. I think it looks bad for the WG and sends a message to others inside and outside the group that dates are meaningless. With my very limited involvement, if I am promised a date for an action, I am unlikely to believe it.

Given my comment above about how this FO threat sounds like an attempt at a trump card and the process protects against that, I'd say the WG chairs just move ahead to the survey as previously committed.


1. http://lists.w3.org/Archives/Public/public-html/2012Sep/0304.html

Received on Thursday, 20 September 2012 20:55:46 UTC