toward last call for SPARQL QL

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