Last Call

Steven Pemberton, W3C and CWI Amsterdam

Chair HTML WG

Co-chair Forms WG

Current score (2002-02-27): 6 last calls, 1 last last call.

First Write Your Draft

Fulfil the requirements of your charter and requirements documents, or document which have not been fulfilled;
Formally address all issues raised by WG participants, other WGs, the Membership, and the public about the Draft.
It 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.
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.
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.

The Announcement

Announce the beginning of the review with email to chairs@w3.org, the WG mailing list, 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 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...

Some last call comments may miss the deadline

Be flexible, but don't overdo it.

Personal record (for comments received): 5 months late

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.

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.

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 fulfilled the relevant requirements of your charter and requirements documents, or with 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 implementation as part of the request.

Summary of New Stuff

Make Requirements documents more formally a part of the process.

More support for massaging documents into publishable form.

More tracking support.

Pre-announce CR request.