- From: Shelley Powers <shelley.just@gmail.com>
- Date: Mon, 18 Jan 2010 09:59:46 -0600
- 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