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

On 02/17/2010 07:25 PM, Maciej Stachowiak wrote:
> 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.

I have no problem with consistency, as a high-level principle. The
problem that I have is when high-level principles are broadly applied,
they can result in a conflict with practicalities. For example,
affecting understanding and transparency of bugs and issues. I'm
asserting that, in this particular case, the high-level principles
resulted in a conflict with practicalities.

> (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.

I was asked to /remove/ text from the HTML+RDFa spec that made it easier
to understand the current set of bugs and issues. I hope that this point
is not lost on the HTML WG chairs.

> (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.

We had a discussion about this:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9011
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9010

In that discussion I asked for time to implement the feature in the
specbugs script. ISSUE-41 was noted via bug #9011, which was in the
HTML+RDFa spec. It's not implemented today, but all I needed was a few
hours to implement it and this would become a non-issue.

> (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.

With so many bugs being resolved so quickly, the draft itself is
obsolete within a matter of days. Heartbeats are a snapshot of the
current state of affairs, not a long-lived document that is frozen in time.

As for the readability concern, let's look at some numbers:

The HTML5 spec is roughly 39,526 lines of text:
    html2txt HTML5.html > HTML5.txt

Let's assume that each bug takes 2 lines of text to express, at the
moment there are 68 bugs logged against the HTML5 spec:

(((68*2) / 39526) * 100) == 0.34 %

That's a third of 1% of the spec would be used for bug markers.

Now assume that we have five times as many bugs:

(((68*5) / 39526) * 100) = 0.86%

Still less than 1% of the spec would be devoted to 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?

With the version of toolchain as it stands today, yes. With just a few
hours of hacking on specbugs, no. The only problem is finding the time
to write the code... it's a trivial technical problem.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/

Received on Thursday, 18 February 2010 06:24:28 UTC