- From: Shelley Powers <shelley.just@gmail.com>
- Date: Mon, 18 Jan 2010 18:59:46 -0600
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, HTMLWG WG <public-html@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>
On Mon, Jan 18, 2010 at 6:44 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Mon, Jan 18, 2010 at 6:31 PM, Shelley Powers <shelley.just@gmail.com> wrote: >> If you all think the spec is good, you shouldn't be reluctant to >> provide a rationale for why its good. > > Of course I should be reluctant. It's time out of my day that I could > be spending more usefully if someone never writes a change proposal > and the issue times out. > People who have to write change proposals also have other work to do. You seem to think we're raising these issues frivolously, and that we won't take the time for the change proposals. Manu actually split the Microdata spec out, and wrote an entire RDFa in HTML spec -- that is not frivolous The Accessibility folks created a new WG, several documents, and many different documents because of issues -- that is not frivolous My own dt/dd change proposal was detailed, met all of the standards for change proposal, and actually had consensus and won't require a poll -- that is not frivolous No one has acted frivolously, and none of us is independently wealthy, and most of us haven't been hired by someone like Google in order to do this work. If we're willing to take the time to argue for change, you all should be willing to take the time to argue against the change. >> If a rationale has been given in >> the past, I imagine that a counter proposal can consist of a copy and >> paste of the prior rationale, or even just a link to the rationale. > > You imagine incorrectly, and the very limited history of counter > proposals the group has seen thus far illustrates that directly. If > one is going to the effort of writing up something at all, it's > worthwhile to do a proper summarization. > You got it in one... > If a mere link to the rationale was sufficient, then there would be no > reason to write a counter proposal in the first place. > >> If >> no rationale has been given, then frankly the rationale for the spec >> text is far overdue, and there's no harm in providing it. In fact, >> giving the rational may help the group to discover that they have >> misunderstood the spec text, as has happened with the hidden element. > > There are benefits to explaining the rationale behind parts of the > spec. That does not mean that the working group should be obligated > to explain every single part of the spec just because someone requests > it. > If people feel strongly enough to go through all of the work we have to go through, then yes, this group does. If the spec has an existing good rationale, this rationale only needs to be re-stated. But if one doesn't exist, perhaps there is no genuinely good rationale, in which case we have made HTML5 better. >> Neither case requires waiting on me for me to write my change proposal >> first. We all have time during the discussion to update our change >> proposals, based on what others say. >> >> The current Decision Process does not have a step in it that allows >> for a counter-proposal, triggered by a person submitting a Change >> Proposal. As Sam stated, if you have time problems, are sick, the work >> is complex and takes times, the co-chairs do have the leverage to give >> an extension in time. But, as Sam also stated, your just wanting to >> see what I write, first, is not a legitimate reason for an extension >> (correct me if I'm wrong on these, Sam). > > I continue to maintain that, yes, it is a legitimate reason. > Otherwise either (a) no one writes a counter proposal, and an unworthy > change proposal receives more attention than it deserves, possibly > being accepted when it wouldn't have otherwise been, or (b) someone > writes a counter proposal to every issue, even ones that end up timing > out or having an obviously weak or frivolous change proposal. > Has anyone provided a weak or frivolous change proposal yet? When weak change proposals are provided is the time to address this issue. > Don't get me wrong; in an ideal world, where every change proposal was > sincere and worthwhile, then it would be nice to receive a full > justification of each part of the spec whenever someone didn't > understand the rationale behind something. We do not live in an ideal > world, however, and people will sometimes abuse processes out of > stupidity or maliciousness. Defending against these situations is > worthwhile. > So what you're saying is that my issues are not sincere or worthwhile? I would have to say, Tab, that you seem quick dismiss other people concerns when they don't agree with yours. But disagreement with you, is not a rationale. I can guarantee you, all of my change proposals will be provided, all will be very detailed, with the best arguments I can provide. So those who want to write counter-proposals, your time won't be wasted. Shelley > ~TJ >
Received on Tuesday, 19 January 2010 01:00:13 UTC