Towards a Happier, Friendlier, Kinder Last Call (A Checklist)

Steven Pemberton, W3C and CWI Amsterdam

Chair HTML and Forms WGs

Current score (2003-05-06): 8 last calls, 1 last last call.

Adopt the Right Attitude

In producing a specification, your attitude should not be "we will tell the world how it should be", but "we represent the community, including those who do not have the time or resources to be involved, and we will produce a specification that as best as possible matches the community's (probably conflicting) requirements".

Last call is the moment that you announce that as far as you are concerned you are finished in that process, and now want to check that the community agrees with you.

Write Your Draft :-)

• Fulfil the requirements of your charter and requirements documents, or document those that have not been fulfilled;
• Formally address all issues raised by WG participants, other WGs, the Membership, and the public about the Draft.
• It will make your life at CR much easier if you identify the testable assertions in your specification at this stage, and not during CR when you are writing your test suite. (It will make a better spec too)

(Your draft must be a public document with a suitable status section.)

Prepare for the Review

• Decide when you would like the review to start and how long it should be: 3 weeks is required, longer is better; don't rush it, it will only cause problems in the future.
• Estimate which WGs and other parties should review.
• Secure commitments by announcing the plan to go to last call to your coordination group, and negotiate a start and end with them and your other reviewers.
• Ensure that there is a public mailing list ready for last call comments
• Send a publication request to the Web Team.
• Fix the errors that the Web Team report...
• When published, announce the last call.

Announce it

Announce the beginning of the review with email to chairs@w3.org, the WG mailing list, your coordination group list, and other lists to encourage public feedback. Include:

• That this is a last call announcement (duh)
• The end date. (The start date is the date of the announcement; the document publication date should be the same.)
• The email address for comments.
• The document's title, address, and publication date.
• The list of dependent Working Groups (and other parties) invited (or committed) to review the document.
• A link to the decision to go to last call.
• A list of priority feedback items and/or minority opinions on decisions.

And then wait...

This will be the first time most people have even looked at your draft...

Relax a little...

And contemplate the meaning of 'last'... it may turn out to have a different meaning to what you are used to...

And track your issues.

The Working Group mailing list should be the definitive archive of issues raised and their resolutions.

An issue tracking mechanism is useful... in the same way that air is useful when you want to breathe.

Be flexible about the deadline

But don't overdo it.

Some last call comments may miss the deadline (Personal record -- for comments received, not comments sent -- 5 months late)

At the deadline chase up groups that commited to review and you haven't had a response from yet. It is not enough to say "they didn't send any comments"; you should require some reply, even if it is "no comments".

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. Although silence is officially consent, many of your commentators are Really Busy™. Try to get some response if possible, especially from important constituents.

Dissenters cannot stop a group's work, and dissenters are required to sketch what would have to change to satisfy them (they can't just say "I don't agree with this feature"). But it is better not to have dissenters, so try to resolve issues.

Create A Disposition of Comments Document

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 on going to CR, but not if it doesn't include it. Make objections visibly obvious in the dispositoin of comments, to aid reviewers during the CR review teleconference.

Create a CR Draft

Make the changes you agreed to...

Not Process, but I believe essential: Two weeks before asking the Director to advance to CR, announce your intention to the same lists that the last call announcement went to, pointing to the disposition of comments document (this gives the chance to catch mistakes).

Go for CR

The Director must be satisfied that you have done the above stuff, i.e.:

• You have fulfilled the relevant requirements of your charter and requirements documents, or documented the rationale for requirements that have not been fulfilled;
• You have formally addressed all issues raised during the review
• You have reported all formal objections;
• You have resolved dependencies with other groups.

You are encouraged to include a report of present and expected implementations as part of the request.