W3C home > Mailing lists > Public > public-html@w3.org > February 2010

Re: Tracking bugs on Microdata and 2D Context

From: Philip Taylor <pjt47@cam.ac.uk>
Date: Tue, 16 Feb 2010 14:51:21 +0000
Message-ID: <4B7AB0E9.9090202@cam.ac.uk>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: HTML WG <public-html@w3.org>
Manu Sporny wrote:
> On 02/16/2010 02:44 AM, Maciej Stachowiak wrote:
>> I'm a little wary of changing our set of components because it seems to
>> break things when we do it. 
> Adding a component for Microdata and 2D Context seems to be the most
> logical long-term solution. If it breaks tools, those tools should be
> fixed such that doing something normal, like adding new Bugzilla
> components, doesn't break them.

The tool I'm most interested in is the "Submit Review Comment" one on 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/> and on 
<http://www.whatwg.org/specs/web-apps/current-work/complete.html>. It's 
valuable because it's radically easy to use, and I'm too lazy to send an 
email or use the Bugzilla entry form to report minor errors that I 
notice in passing. How should this tool be fixed? A few things I can 
think of:

* Add a drop-down box so the submitter can select the component. But 
that'd make it twice as hard to use (since a user would need to input 
twice as many values), which defeats its purpose, and it would probably 
be filled in wrongly anyway.

* Have the script automatically deduce the component based on the 
selected section of the spec. I don't know how possible that would be; 
it sounds tricky to keep it up to date with the different spec splits, 
given that the WHATWG copy (where the tool runs) doesn't do the splits.

* Use a new component ("Some undetermined HTML-related spec") for bugs 
that are submitted by this tool. But then queries on bugs for a given 
spec's components would be actively misleading, since it may look like 
all the bugs have been addressed even if there's dozens of relevant but 
unclassified ones unresolved.

* Use a new component for bugs that are submitted by this tool, and have 
somebody move them into correct components. But that's a lot of manual 
effort with little obvious benefit.

* Don't use W3C's Bugzilla. But then effort would be wasted setting up a 
new bug tracker elsewhere, and the bugs wouldn't be processed with the 
guarantees and procedures that the HTML WG provides.

Are there betters ways of handling this?

(I'm personally content with the current system - I report a bug on the 
WHATWG copy of the spec, it gets fixed or otherwise addressed, later I 
search in the W3C Bugzilla to find my bugs and confirm they were 
resolved correctly, eventually there's zero reported bugs left and I 
decide I should look for more, and I never need to care about components 
or document splits. I'll continue to be happy as long as I can report 
bugs in HTML-related specs and get them fixed with as little effort as 

Philip Taylor
Received on Tuesday, 16 February 2010 14:51:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:58 UTC