- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Tue, 14 Sep 2010 07:11:16 -0500
- To: "Michael(tm) Smith" <mike@w3.org>
- Cc: public-html-a11y@w3.org, Robert J Burns <rob@robburns.com>, html4all <talk@html4all.org>
Hi Mike, The "NotInW3CSpecYet" keyword is a good idea. Thank you, Mike for adding it to the W3C's Bugzilla. It honestly labels a bug for what it is. The "NotInW3CSpecYet" keyword means: "This bug is for a feature that is has not been adopted into the W3C version of HTML5 and may never be, and that is not under the HTML WG decision policy and may never be." http://www.w3.org/Bugs/Public/describekeywords.cgi The HTML Accessibility task force has enough to try to track for the time being. If any "NotInW3CSpecYet" keywords are removed later the task force can deal with them at that time and re-add the "a11y" and "media" keywords that you removed if they are needed. One question, can other groups now use Bugzilla for related specs if they add the "NotInW3CSpecYet" keyword? I'm thinking about Rob Burns' HTML 4.1 draft at html4all. http://html4all.org/HTMLDraft.html Thanks. Best Regards, Laura On 9/13/10, Michael(tm) Smith <mike@w3.org> wrote: > This is an FYI to let members of the task force know that I added > a new NotInW3CSpecYet keyword to bugzilla -- for use in flagging > bugs for features that are not in the W3C HTML5 WD or editor's draft. > > This keyword is free for anybody to use in flagging such bugs. > > Some background on this: > > I set up the HTML WG bugzilla (way back when) in part as a way to > provide a low barrier of entry for people to easily report typos > and editorial bugs and such. And an embedded comment form was > later added to make it even easier for people to submit such bug > reports and comments. And I think those two things have served us > well so far -- a lot of such bugs have been found and fixed due to > them. > > As a result of that, though, it creates the possibility that some > bugs end up going into bugzilla against features that are not in > any W3C spec version (and may never be). I think that's OK as long > as we have a way to identify those and distinguish them from bugs > that are against parts of the W3C HTML5 WD or editor's draft. So > that's what I created this keyword for. > > So please keep in mind that this bugzilla instance has from the > beginning been a kind of shared, open resource (for example, it > intentionally has never required bug commenters to be members of > the HTML WG, but is open to anybody) and I think there is value to > us in trying to keep it that way as much as we can. > > But at the same time, we need to have ways to distinguish > different classes of bugs from one another. The chief lowest-cost- > to-all-involved way that has proven useful in the past for doing > that is to mint new keywords when we see a need. So that's what > I've done again in this case, and I would like to ask that we give > it a try and see if it helps or not. Of course as with everything > we do, we need to periodically re-evaluate whether it's having the > intended effect or not. But that does mean giving it a chance for > a while first before deciding. > > --Mike > > -- > Michael(tm) Smith > http://people.w3.org/mike -- Laura L. Carlson
Received on Tuesday, 14 September 2010 12:11:49 UTC