Dealing with comments

Steven Pemberton, CWI and W3C, Amsterdam

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:

Collect your comments

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

Dangers you may want to avoid:


In battlefield hospitals, they have limited resources.

So they split the wounded into three classes:

  1. Those who will live even without care
  2. Those who will die even with care
  3. 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:

  1. Those that are clearly right and need no discussion. (Typically editorial remarks.)
  2. Those that are clearly out of scope.
  3. 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:

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.

Produce your Disposition of Comments

Make the rejects extra visible to help speed the transition call.