Re: Change Proposals, objections, and the Decision Policy

On Jun 14, 2010, at 5:49 PM, Adam Barth wrote:
> On Mon, Jun 14, 2010 at 9:32 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>> On Jun 2, 2010, at 7:17 AM, Tab Atkins Jr. wrote:
>>> On Tue, Jun 1, 2010 at 6:53 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>>>> 
>>>> I was going to wait a day or so before I mentioned it again, but you
>>>> recently authored two change proposals which I suggested that you might want
>>>> to augment.
>>>> 
>>>> When it comes time for a poll in issues 89 and 92, what URLs should be used
>>>> to identify the change proposals that people are to register their
>>>> objections?
>>> 
>>> I can rewrite them to include the additional information I've sent to
>>> the list.  Ping me before the poll comes up if I forget about it.
>>> 
>>>> As to your question in this email: the primary purpose of proposals is to
>>>> make a case FOR something, i.e., provide rationale.  Clearly stated
>>>> objections contained within a proposal will be considered, but that isn't
>>>> the primary purpose of a proposal.
>>>> 
>>>> This is true even for proposals made in response to other proposals (i.e.,
>>>> counter-proposals).  The chairs made a decision that uncontested content in
>>>> the spec does not need rationale, but contested material does, and that
>>>> responses to bug reports and proposals are the place to provide the
>>>> rationale.
>>> 
>>> This doesn't answer my question.  Allow me to make it more direct.  Do
>>> I hurt my case by merely authoring a change proposal and then not
>>> repeating my objections in the poll?
>> 
>> I have not yet discussed this with my co-Chairs, but here is my take.
>> 
>> When the Chairs review survey responses on an issue, we also carefully study the Change Proposals submitted and most particularly the rationale sections. If you look at the Working Group Decision for ISSUE-76 (<http://lists.w3.org/Archives/Public/public-html/2010Jan/att-0218/issue-76-decision.html>), each point of rationale in each submitted Change Proposal was explicitly addressed. For the recent round of decisions, we also carefully reviewed Change Proposal rationales, but we commented on them in a somewhat more cursory way.
>> 
>> Since we're telling WG participants that they do not need to restate objections that are redundant with a Change Proposal, then I think we need to be very clear that we are in fact treating arguments in the rationale sections as objections when appropriate, even if not explicitly worded as such. Therefore I will recommend that for future decisions, the Chairs explicitly address at least all the individual points of rationale from each Change Proposal in the written decision.
> 
> A lot of the discussion around Change Proposals and the Decision
> Process seems to revolve around the "strength of objections."  Would
> it make my proposal more likely to convince the chairs if I edited my
> proposal to more strongly object to the opposing viewpoint?
> 
> Previously, I was under the impression that technical merit was the
> salient criterion, so I couched my proposal in terms of technical
> trade-offs.  I can certainly be more of an objectionist if that's what
> the chairs desire.

Why do you persist in this game?  I can understand Ian's desire
to keep stringing this diatribe along, but I cannot understand why
anyone else would be fool enough to pretend that the chairs are
idiots or somehow motivated to accept vocalness as a measure of
"strength of objection".

A true technical issue, as in "something described in the spec
doesn't work that way in practice", is almost always a strong
objection on the part of those that have already implemented it.
Likewise, a specification that requires a future implementation
should result in a strong objection by those who refuse to
implement it.  Similarly, a protocol that one side of the
communication chooses to implement but the other side is going
to have to block should result in a strong objection.

In rare cases, we can resolve objections by actually testing
different alternatives or by seeing the success or failure of
test deployments.  However, that requires a fair evaluation of
those tests and an editor that doesn't suffer from severe NIH
syndrome.

In some cases, the editor/author places speculative stuff in
the specification in the hope that everyone agrees with it.
When someone disagrees with that speculation, the editor
is expected to remove it.  Insisting that the removal be
preconditioned by an extensive argument based on technical
merit presupposes that there is any merit in the text being
added in the first place.  Authors are lousy judges on the
merit of their own speculation.

I would say that the chairs have been looking for objections that
reveal how much technical and social damage will be caused by the
action, one way or the other, where both are defined in terms of
the entire scope of HTML implementations and the entire scope
of HTML as a standard.  They have bent over backwards to avoid
making any personal evaluations of "technical merit" with their
chair hats on, since that would not be consistent with the role
of chair for evaluating WG consensus (not their own consensus).
Ian doesn't seem to understand the distinction, because in his
world all decisions are made by Ian/WHATWG, and so he keeps
portraying these acts of observation as decisions by the chairs
rather than decisions of the WG.

This part of the W3C process is extremely unusual, since most
W3C editors are willing to listen to other experts in the field
and accept their evaluations of technical alternatives rather than
rely on their own inexperience to act as judge, jury, and executioner.

Ian's arguments are entirely based on browser behavior, when it
suits him, and entirely based on speculation when it doesn't.
We have had several discussions on terminology and language
definition for which he has shown no interest in consistency.
We have argued about URI and URL algorithms for which his claim
of browser implementation has turned out to be utterly false.
We are still arguing about the definition of Content-Language
as a pragma in HTML5, even though that definition is technically
wrong, not implemented by the majority of browsers let alone
any of the thousand or so content management systems, actively
harmful to deployed content, disagrees with the normative
MIME and HTTP definitions, breaks the principle of orthogonality
that is core to Web architecture, and even manages to misuse
the term "pragma" for something that is very clearly metadata.

There is no technical merit to a solution that has not and
will not be implemented, and yet I had to spend the better part
of six months arguing for @ping to be removed from the spec,
something that would have been harmful if implemented for at least
two different technical reasons, both of which were repeatedly explained.
Ian is still incapable of seeing either technical argument.

I find the dual spec to be an insult to the standards process and
a disgrace for the WHATWG.  It is pathetic.  It turns the grandiose
statements about HTML5 from Google and Apple into a pack of lies,
something I suspect neither CEO would appreciate.  Stuff like
@ping could easily be published as separate proposals, like
all other standards processes, but Ian thinks he can win this
game instead by challenging ownership of the standard itself.
I'd prefer that he stop wasting my time, either way, so I would
prefer that he either try to move HTML5 out of the W3C (and we
can stop calling it a standards effort) or choose to adhere to
the standards process without any sniveling, lying, backside
abuse of the process.

Personally, I disagree with about half of the change proposal
decisions so far, not because the chairs are wrong but because
I don't think the text should even appear in the HTML standard
until it has been implemented with some consistency. HTML is not
a new protocol, and I don't think any speculation belongs in the
standard.  I see no reason to prefer one thousand-page document
that nobody agrees on over a single agreed standard and multiple
new proposals, and I simply don't care how much more difficult
that makes it for the editor.  It needs to be easier for readers.

If there are technical inconsistencies in the W3C spec, then Ian can
propose the corresponding changes just like anyone else.  If his
arguments have no technical merit and are only being made for political
reasons or because he is swimming in a warm snit, then I hope you can
find the time to argue against them.  I certainly won't bother until
the dual spec issue is resolved, since this whole process is
irrelevant if there is any confusion over what is the standard.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Tuesday, 15 June 2010 03:19:39 UTC