- From: Dan Connolly <connolly@w3.org>
- Date: Wed, 08 Jun 2005 10:34:52 -0500
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
So we closed all the WG issues yesterday. Woohoo! And I have three volunteers to do a top-to-bottom read of the QL editor's draft in preparation for a WG decision on Tuesday, 14 Jun... 15:59:51 [DanC] KC, SH volunteer to do a last call review 15:59:57 [DanC] JB too -- http://www.w3.org/2005/06/07-dawg-irc (minutes coming in the next day or so) I have some ground-rules to suggest: Every comment should come with suggested replacement text. If you just can't think of replacement wording, but you're 100% certain something is broken, sketch a test case. The editors are not obliged to do anything about comments that don't include suggested replacement text nor a test case (sketch). Cite the version you're commenting on by URI and CVS revision. I currently see http://www.w3.org/2001/sw/DataAccess/rq23/ 1.377 The editors have a few things to work on, but I don't think the reviews should wait until they're done. Kendall, Steve, Jeen, please "start your engines" at your earliest convenience. Anything you know about when you'll send your comments or what angle(s) you intend to focus on is handy for me and the editors to know, I'm sure. If you're comfortable sending it to the WG, that's great too. Try to distinguish between -- suggestions, which the editor is free to take or leave without explanation -- requests, which the editor should act on or explain why not -- critical issues, which should go on the WG agenda if the editor doesn't agree Try to make one major point per message, and take care that the subject is a good summary. Some ideas... Subject: problem with nested optionals and disjunction? Subject: editorial comments, sections 1-4 Subject: wrong answer for bnode example (CRITICAL) If/when you finish your review, please send a message ala "I'm pretty much finished; these are the critical issues I found: ... ." Andy has asked me about the quality threshhold for the LC draft. There are few hard-and-fast rules, but to declare last call is to say that we're satisfied with the way the draft addresses all the issues we know about. Not that it's perfect, but that if nobody finds any problems for the rest of the process, we're OK with it becoming a W3C Recommendation. Now the odds are that reviewers will find problems, and that in finishing out the test suite during CR, we will find some things to clarify; we and while we're fixing those problems, we can also tidy it up editorially -- add a glossary or an index of formal definitions, polish the wording, tweak the stylesheets, that sort of thing. What's *not* OK to say something like "well, we know that part of the design is broken, but we'll fix it during last call." It's one thing to be not 100% sure that the design is right; it's another thing to have positive evidence of a problem and count on fixing it later. Ultimately, the quality threshold is a group decision. Personally, I'm constantly conflicted between my mathematical training, which says "either you got it right or you got it wrong; no partial credit" and my role as chair, which includes watching the schedule. Fixing problems sooner is generally cheaper, but time-to-market is important too. Quality-of-specification is hardly the leading indicator for successful deployment of web technologies. A lot of things that changed the world were back-of-the-envelope things at the time. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Wednesday, 8 June 2005 15:34:55 UTC