Guide

Starting member review of Proposed Recommendation

Note: A revised version of this document is in development.

This document is a supplement to PR section of the process document.

For Working Drafts, there is no requirement for review of a document outside the working group, and groups are encouraged to make working drafts frequently.

However, for Proposed Recommendations, there must be a review within the W3C community. The staff must be be clear that all related working groups and coordination groups have reviewed the documents. This will take time, and it is wise to plan through the staff contact and project lead, who will be involved for when this review can be done, who will do it. This means planning people's time, and it means scheduling a meeting with the director and staff contacts for the related groups.

Clearly this will all proceed easily if related groups have been involved consistently during the development of the document, and their views have been taken into account (see Last Call). For example, XML1 .0 met with criticism as it had lost the namespace functionality which had been promised to other groups. It almost failed to have the director's approval, and had to be escalated to a discussion at the AC meeting.

@@see also: Deployment Plans

Working implementation status

Resolved : All chairs should prepare a report to the director asking for a document to become Proposed Rec.

Before Proposed Recommendation is accepted, there must be a report on the implementation status. Features which have not been implemented and tested must be pointed out, and some reasoning provided for them being in the specification.

It is wise to build implementation requirements into the charter, as the SMIL group had, so that expectations can be set realistically. A good rule is two interoperable implementations for a protocol.

It is essential that implementation of prototypes start as early as possible. This does not mean that products in the marketplace should be build from working drafts, but prototypes should.

Step by Step

1. The chair of the Working Group (or if there is no WG, the editor)�asks the Director for the document to go to review. Include a title, date, URL of working draft, and status of this document in the mail message, as well as a rationale why this document is ready for review now (incl. implementation status, review by other groups). CC chairs@w3.org
   • some exemplary requests for PR status:

   This request must be sent a minimum of seven days in advance of the teleconference in which the Director, Chair, Team Contact and Project lead discuss the advancement of the document.

2. If the Director agrees (consensus, clean document, project lead support):
   1. The editor prepares the document in PR format, based on the last PR document published (for style) and the WD (for content).
   2. The staff contact has the responsability for an appropriate "Status of this document" section.
   3. The staff contact asks the systems team to set up the two archived mailing lists for member review and public comments (w3c-XXX-review & www-XXX-comments). The former has an auto-responder, for which the staff contact provides a text.
   4. The staff contact arranges with the communications team the period of ballot and Director's decision (at least 4 + 2 weeks) and and helps draft the Director's call for review. Please use the Exclusive XML Canonicalization Version 1.0 is a Proposed Recommendation call for review as a model (Note: The IPR section may change once the patent policy has been completed). The call for review must include the following information in addition to the standard review information:
      • Three email addresses:
        1. One for Team-only comments
        2. One for Member-visible comments but not announced to Membership
        3. An indication that if reviewer wishes to share comments with AC, to copy w3c-ac-forum.
      • the name of the specific editor(s) assigned or to be assigned by the Team
      • the duration of the review period. The review period may not be less than four weeks.
      • that the Director's decision as to the disposition of the proposal will not be made sooner two weeks after the end of the review period. If possible, the call for review should set expectations about when the Director's decision is likely (but not guaranteed) to be announced. Editors must reply to substantive ballot comments before this time.
   5. The staff contact may copy the document to its final location (check links!)
   6. The staff contact provides the Web team with (1) a pointer to the current location and (2) a pointer to the Director's decision. The Web team then updates the TR page.
   7. The chair announces the new PR document on chairs@w3.org
   8. The communications team discusses with the staff contact and the chair the possibility of a press release, for the PR, for the REC, or for both. They collect quotes from members who want to participate in the press release. Everybody keeps himself available to answer comments, talk to the press, etc.

During the review period, the staff contact watches the incoming comments, and summarizes them for the Director.

Summary of Review and Review Decision

When a spec goes from one step to another, by last call or member (or any) review, then a review summary is the record of the review, and should at the end of the day demonstrate that justice has been done and seen to be done. This is normally prepared by the staff, with the help of chair and sometimes editors. The non-confidential part can be published. Member reviews always have a confidential checkbox - this allows a separate public and team versions to be prepared. Public comments are public and should be answered publically.

The review decision is made by a meeting normally including the director, the project lead, activity lead, staff contact, and working group chair[s], and possibly document editors. As input it needs the reviw table which summarizes

1. The input comment (from whom, on behalf of which member if any, pointer to

Examples:

• (Team only) Mimassa's XHTML 1.0 second review.
• Ian's summary of WCAG PR issues

Every comment must be responded to. If at all possible, feedback must be obtained

For technical point, (@@@ to be continued)

The review process can override if the negative comment is out of bounds procedurally, or finally if ansoluteley necessary as a matter of expediency if more time would be neeeded.

Going to Recommendation

@@Just starting to work on this for AUGL Rec --Ian 8 Nov 1999@@

1. EARLY: Schedule a meeting with the Director to discuss comments that arose during Proposed Rec.
2. EARLY: Contact Member organizations (e.g., through Working Group participants) and other individuals who may submit testimonials for the Recommendation Press Release.
3. The Team Contact schedules a release date with the Comm team..
4. Organize other documents: FAQs, etc.

Sys Admin

• Set up lists as asked@@

Webmaster@@

When asked, (check with Director too),

1. Put review deadline into member calendar, and date of recommendation decision.
2. Check format and style of PR document
3. Send Call for Review to members with pointer to TR
4. Put links to PR document in TR area.
5. Give newsletter edtor the Call for addition to next newsletter.

Consider press coverage. If press releases are made, ensure members have had the message just before the press releases are made.