- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 17 Feb 2010 16:25:50 -0800
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: HTMLWG WG <public-html@w3.org>, RDFa WG <public-rdfa-wg@w3.org>
Hi Manu, On Feb 17, 2010, at 4:00 PM, Manu Sporny wrote: > On 02/17/2010 04:58 PM, Sam Ruby wrote: >> Manu Sporny wrote: >>> There is a new HTML+RDFa draft available that includes all of the >>> bugs >>> logged against the "HTML+RDFa" project in W3C Bugzilla as of right >>> now. >>> This draft attempts to resolve the publication issues raised with >>> the >>> latest heartbeat requirement, namely: >> >> My apologies as I didn't catch this before: I don't believe that >> including all bug reports is a viable and scalable approach that >> can be >> consistently applied across all documents. > > There is some mis-communication or a misconception about the approach > taken for including bugs in the HTML+RDFa spec. > > I'd like to know more about your thought process, as I disagree with > your conclusion. I do think that this is not only viable, but also > consistent and scalable. > > Note that the bugs listed in the status sections of the HTML+RDFa > specification are only for the HTML+RDFa Bugzilla component, it > doesn't > include "all bug reports". The Chairs discussed this topic earlier this afternoon. While I can't fully speak for Sam, let me try to clarify the points of concern: (1) Ideally, we would like the process for inline issue markers to be consistent between all of the HTML Working Group's drafts. We don't want HTML5 doing one thing, HTML+RDFa doing another, and H:TML doing potentially yet another thing. (2) The last time we went through a publication cycle, after lengthy discussion we came to consensus that flagging tracker issues was the right way to handle inline markers for the HTML5 draft (not bugs and not handpicked issues). We think at least the starting point for discussion should be that we will extend this policy to our other drafts. If we change the policy, it should be by coming to consensus on a change to our approach, not by having each draft do something different. (3) It seems like the mechanism implemented for HTML+RDFa does not include issues at all, only bugs. That means that if a bug is resolved and escalated to the issue tracker, it would not get a marker any more, which seems like the opposite of what we want. (4) Marking all bugs (and not just issues) inline seems like it would not scale to the HTML5 draft. We are getting literally hundreds of incoming bugs a month, and we're also seeing hundreds of bugs resolved per month. The sheer number of bug markers that would result would seriously interfere with readability of the draft. Furthermore, bugs are filed and resolved at such a fast pace that the set of bug markers would be obsolete almost immediately after being published. Issues by their nature last somewhat longer and so are more useful to flag. We are also expecting editors to give a turnaround time of at most a month on bugs, so even for other drafts, inline bug markers are almost guaranteed to be obsolete within a month of publication. >> I am not comfortable with a plan that requires each and every >> document >> produced by this working group to list each and every bug that may >> apply to that document. > > The process is automated, the code is open source, and it is the same > sort of process that is applied to the HTML5 spec. The only difference > is that the HTML5 spec includes all OPEN issues, and the HTML+RDFa > spec > currently includes all OPEN issues and all OPEN bugs. My understanding is that if one of the open bugs was resolved and escalated to the tracker, it would no longer be recorded in the draft. Is that correct? Regards, Maciej
Received on Thursday, 18 February 2010 00:26:24 UTC