Re: Change Proposals, objections, and the Decision Policy

Hi Roy,

I appreciate your note of support for the efforts of the chairs. However, a lot of your message veers into personal attacks, and that kind of content is not welcome on this list. Please take that sort of material elsewhere. If you want to post here, please focus on the argument and not the person.

Regards,
Maciej

On Jun 14, 2010, at 8:19 PM, Roy T. Fielding wrote:

> 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 04:30:26 UTC