Re: New HTML+RDFa Heartbeat Draft (2010-02-16)

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