Dealing with comments

First issue your spec

and make sure you have a system for recording comments. There are a few around.

Since issue tracking is one of the major activities in the W3C, I personally think that there should be a W3C issue tracker. Some groups use tracker.

XHTML2 WG uses a system built by Shane McCarron from an Open source issue tracker called Jitterbug originally developed by Andrew Tridgell. Advantages include:

Email driven: retains the paper trail for issues
Web interface: can interrogate and update on the fly
W3C process based (has states required by process)
Automatically generates the Disposition of comments

Collect your comments

Really, make sure that the people who should have replied have replied.

Dangers you may want to avoid:

Someone spotting a major problem at PR
AC reps who don't understand the concept of last call
DoS attacks

Triage

In battlefield hospitals, they have limited resources.

So they split the wounded into three classes:

Those who will live even without care
Those who will die even with care
The rest

They allocate resources to the last group.

Triage of comments

The W3C process is a battlefield, and you have limited resources.

Before the meeting get someone to split the comments into three classes:

Those that are clearly right and need no discussion. (Typically editorial remarks.)
Those that are clearly out of scope.
The rest.

Spend your precious resources on the last group.

Keep discussion short

Discuss issues you think can be solved quickly first.

Try to have potential solutions ready: avoid designing on the fly.

Try a 5 (or 10) minute rule.

You want to reach consensus:

Don't ask "does everyone agree with that?", ask "any objections?"
Listen out for the magic words "I could live with that", and stop as soon as you hear it.
Don't reopen issues if there is no new information.

Be strict with comments

Comments that do not include constructive suggestions do not need to be taken as seriously as those that do.

Attain Consensus

Decide on each issue: accept, reject, compromise, etc.

Send a mail to the commentor telling your reponse. If not an accept, ask if they can live with the result. Archive your mail. Give them 2 weeks to reply. Silence is consent.

Dissenters cannot stop a group's work, but it is better not to have dissenters, so try to resolve issues.

Document the group's decision for each issue

For non-accepts, document the link to the mail to the person, and if received, the link to the reply.

Document objections. When you are sure an issue has received due consideration and is further not resolvable, document the technical arguments for not accepting.

Formal objections should include technical arguments and propose changes that would remove the dissenter's objection; these proposals may be vague or incomplete. You must report an objection that includes such information to the Director, but not if it doesn't include it.