- 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