W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: Splitting out sections and submitting bugs (canvas, Microdata, et al) Re: Proposal to publish HTML5 and vocab specs

From: Sam Ruby <rubys@intertwingly.net>
Date: Wed, 28 Oct 2009 12:16:24 -0400
Message-ID: <4AE86E58.9020306@intertwingly.net>
To: Shelley Powers <shelley.just@gmail.com>
CC: Julian Reschke <julian.reschke@gmx.de>, Jirka Kosek <jirka@kosek.cz>, Ian Hickson <ian@hixie.ch>, public-html@w3.org
Shelley Powers wrote:
>> I'm aware of such a change proposal for Microdata.  I'm aware of work being
>> done to split out canvas, and this needs a consolidated set of rationale,
>> ideally in the form of a change proposal.
> 
> I agree, the Canvas proposal is not complete. One part of it is done,
> the 2D API split, but not the clean up in HTML5, or working through
> some of the interface issues. I asked a question on this, but wasn't
> answered, so am not sure what's happening with Canvas.
> 
> Is there anyway we can get this entered as tasks in the Tracker?

The most straightforward way is to start with a bug report.  We can skip 
that step in exceptional circumstances, but is there any reason to do 
that for this case?

>> Are there other sections that need to be removed or split out?  If so, now
>> would be an ideal time to bring them forward, ideally first as bugs, and
>> then as issues if the resolution is not satisfactory.  If not, why are we
>> having this discussion?
> 
> Agree. I'm spending November devoted to one thing: writing up bugs,
> escalating bugs to issues, and *writing change proposals (and the
> MathML comments). I know others are doing the same.

Thanks!

> Now is the time to do these things. I'd like to propose something,
> first, though.
> 
> I would remove my objection to another heart beat document if the
> HTML5 author agrees not to make any additional changes to the document
> that can't be specifically tied back to a change request or bug
> entered into the W3C bug database. If the document is stable enough to
> be a WhatWG document, there shouldn't be anything about the document
> that is currently undergoing change _except_ for changes based on
> feedback. And that feedback should be documented, formally.
> 
> The changes should not be occurring because of loose discussions in
> IRC, or hallways discussions when it comes to that. They shouldn't be
> _just_ in the WhatWG database, either, or occurring spontaneously.
> There should be a an accountability of changes to the document from
> this moment on.
> 
> Is this a fair request to make?

Unfortunately, I don't think it is.  I am certain that I could find a 
half-dozen typos in the document at will at the present time.  I don't 
believe that we need undue process for routine items.

For accountability, we've asked for rationale for each change, and 
tracking from bug reports to commits; furthermore we've provided a 
process by which people who disagree with the draft can register bugs, 
raise issues, create change proposals, and in the extreme cases even 
propose alternate documents for consideration.

I happen to believe that's more than sufficient, but if you disagree I 
would suggest you respond to Maciej's Call for Consensus: Adopt Proposed 
Decision Policy:

http://lists.w3.org/Archives/Public/public-html/2009Oct/1034.html

>>>> - Sam Ruby
>>>>
> 
> Shelley

- Sam Ruby
Received on Wednesday, 28 October 2009 16:17:04 UTC

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