W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Issues 89 through 97

From: Shelley Powers <shelley.just@gmail.com>
Date: Mon, 18 Jan 2010 09:59:46 -0600
Message-ID: <643cc0271001180759s34497ddal4c4e07a9c66b7865@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: Maciej Stachowiak <mjs@apple.com>, HTMLWG WG <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>
On Mon, Jan 18, 2010 at 9:29 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> Shelley Powers wrote:
>>
>> I would like ensure, though, that the group is instructed that all
>> proposals, in support of zero-edits and otherwise, are also due this
>> time.
>
> That's not really fair, since a counter proposal should be able to address
> the rationale included in yours.  So I don't believe a good counter proposal
> can be or should be written until after the initial change proposal has been
> received.  Then there should also be some time permitted to make changes
> based on feedback and the content of the counter proposals.

There is nothing in the Decision Process that allows for asking for
counter-proposals, and allowing a month for someone to write one. We
write our proposals based on what's in the spec. Those who want to
write a zero-edit proposal should do the same. And then both parties
should update their proposals based on discussion.

This procedure, as it was defined in the Decision Process, allows all
parties to respond to what's written in all proposals, and based on
discussion. Simple, clean, fair, and not drawn out.

>
> It's also not worth spending time writing a counter proposal to a proposal
> that may not even get written.  If you don't get it in on time, then the
> issue will be closed and we won't have to worry about a counter proposal.
>

I disagree with this.

As noted with the recent @doc attribute discussion, Ian came into the
group, barely wrote a couple of sentences that an implementor wants
this, and when I asked for some more background on this new attribute,
and justification for adding something that I feel is not something we
_really_ want in the spec, I was told to dig for all of this
information in the (many times contradictory) email messages.

Frankly? This comes across as very undisciplined, and even a little
sloppy. Discussion is good, but we should _all_ be prepared to explain
our requests--not just those who disagree with Ian.

Hopefully a zero-edit proposal will fill in the background of what
exists in the spec, providing a written justification for the
section/element/attribute, perhaps even provide clarity for the
purpose of the spec content. As we've seen with the hidden attribute,
once a person actually challenges it, we find out that people who
support keeping hidden don't even have the same view of its purpose.
Those who support the hidden attribute can use the Decision process to
write a proposal clarifying the purpose of the attribute, and
providing text that will eliminate confusion about its use.

This isn't about winning and losing -- this is all about ensuring that
we not only have the best spec we can deliver, but that we also have
an equal understanding of what it is we're including. The doc
attribute was badly introduced, with little justification given.
Asking folks to dig through emails in this list, and in the WhatWG, as
we were told when we asked for a more in-depth explanation behind its
purpose, should not be encouraged. We should be able to point to one
missive, either an initial email, or a proposal that provides sound
reasoning, a good justification, and a good understanding, of exactly
what is being proposed.

As we've seen with the discussion on @hidden, this did not happen, and
many folks did not have a clear idea of what it was they were
defending. It's only when I challenged the validity of the @hidden
attribute that a clearer understanding of what the hidden attribute is
began to emerge--and a need to provide a better explanation for it.

Folks don't need to wait to see what I write in order to write their
own justification for keeping the hidden attribute (or any of the
other changes). And when I do produce my document, they can edit their
proposal, same as I can mine--not only based on each other's work, but
also based on the discussion.

Most importantly, we'll have effectively cut out one step that was
incorrectly introduced, and cut at least a month out of the process.

> --
> Lachlan Hunt - Opera Software

Shelley

> http://lachy.id.au/
> http://www.opera.com/
>
Received on Monday, 18 January 2010 16:00:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC