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
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.
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.
www-XXX-comments). The former has an auto-responder, for which the staff contact provides a text.
During the review period, the staff contact watches the incoming comments, and summarizes them for the Director.
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
|Jon Doe||ACME plc||Yes w/comment||response||confidential|
|Jane Deer||Baz Inc||No||response||-|
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.
@@Just starting to work on this for AUGL Rec --Ian 8 Nov 1999@@
When asked, (check with Director too),
Consider press coverage. If press releases are made, ensure members have had the message just before the press releases are made.