W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2003

Summary of Last Call Process

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Wed, 05 Feb 2003 11:34:51 +0000
Message-Id: <5.1.0.14.0.20030205092235.031caeb8@localhost>
To: RDF Core <w3c-rdfcore-wg@w3.org>

I thought it would be useful to post a summary of the last call process as 
I understand it, so that:

   o to collect the various bits together
   o for folks who weren't at various telecon's

This is intended as a framework.  I expect folks to use their judgement in 
making this work.  We can ammend in the light of experience.

PRINCIPLES

   o we have made our decisions - we are not finding out if folks would 
have preferred different decisions, we are finding out if they can't live 
with the decisions we have made

   o if we make a change to a document that might reasonably cause a 
reviewer to change their review to negative, then we have to do a second 
last call.  Ultimately, the director determines reasonableness.


MUSTS:

   o Every comment must have a disposition, which I'm calling:
     - withdrawn
     - accepted
     - rejected
     - rejected and objection

   o that disposition must be clear to the commentor who must have a chance 
to object

   o Each document must list the changes since last call.

WANTS

   o a clear disciplined process where its clear to everyone, inside and 
outside the WG what's going on


INCOMING COMMENTS

  o the incoming channel for comments is www-rdf-comments@w3.org and 
nothing else

  o editors (or a delegate) respond to incoming comments
    - once an editor has volunteered to handle a comment - that respondent 
is responsible for either resolving it or ensuring its put on the WG lcc list
    - lets make sure we don't send mixed signals to commentors

  o handling a comment may follow one of the following paths:

   A misunderstanding
     . editor responds, pointing out misunderstanding and asking commentor 
whether that covers the issue
     . commentor responds yes - editor responds with [closed] in the 
subject line
     . commentor responds no - keep going

   B editor uses discretion and agrees to accept comment in which case:

     . editor adds a item to the change list in the editors draft
     . that item has a frag id, suggest #lcc-nnn for some nnn
     . that item has a link to the message causing the change
     . that item is marked as todo until its done
     . editor responds to commentor
       ' copying www-rdf-comments@w3.org accepting change
       ' noting change id (not the url of the ed's draft)
       ' adding [closed] to the subject line
       ' describing intended change if its not obvious
       ' invitation to confirm that change is acceptable

   C editor seeks clarification of the comment
     . use your judgement
     . vague comments are bad
     . philosophical ratholes are bad
     . test cases are good
     . references to specific text is good
     . understanding significance of comment to commentor (is this a 
personal opinion of how it might be done better or does a billion dollar 
business go down the tubes if this problem isn't fixed)
     . summarizing understanding of comment, once clarified is good
     . Go to step B or D at editors discretion

   D editor refers comment to WG
     . comment gets an id in the last call comments list
     . editor stimulates discussion of comment as appropriate
     . proposed disposition of comment is presented to WG at telecon
     . WG decides on disposition
     . if doc changes, add item to doc's change list with link to lcc 
comment doc
     . editor responds to commentor indicating
       ' comment
       ' disposition - with reference to telecon minutes
       ' if rejected - the reason
       ' if accepted summary of proposed changes and change id
       ' invitation to confirm, on www-rdf-comments that disposition is 
acceptable
     . lcc list updated to indicate disposition, wg response and response 
from commentor

  - Jan has volunteered to take a weekly sweep through the comments list to 
identify anything that gets dropped.

Brian
Received on Wednesday, 5 February 2003 06:33:40 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:55:48 EDT