- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Wed, 05 Feb 2003 11:34:51 +0000
- 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 UTC