Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.w3.org/2005/08/01-transitions.html below:

How to Organize a Technical Report Transition (2005 Process)

This resource describes the internal W3C Technical Report publication processes. A companion document provides more information about roles involved in these processes and interactions with the W3C Communications Team. A comparison of requirements across all document types is available.

Once the Process Document requirements for the transition to First Public and Last Call STATUS have been satisfied (see section 7.4.1 section 7.4.2 sections section 7.4.1 and section 7.4.2 section 7.4.3 section 7.4.4 section 7.6.3 section 7.4.5 section 7.7.1 section 7.7.2 under "Entrance Criteria"), W3C follows the steps described below to complete the transition. W3C follows the steps described below for transition to a First Public STATUS. These steps are grouped by theme. They are not strictly ordered; in practice, some steps are completed in parallel. For instance, groups often manage the transition request/meeting steps in parallel with the publication request steps.

Note: If your specification involves an Internet Media Type, before the transition to First Public and Last Call STATUS, see also How to Register an Internet Media Type for a W3C Specification to review the entire Internet Media Type registration process. for information about what must be included in the section of your Last Call Working Draft and how to request review within the IETF. for information about alerting the W3C liaisons to the IETF so that they may request formal review and approval by the IESG. for information about how the W3C liaisons to the IETF track the registration process.

Note: If your specification defines an XPointer Scheme, before the transition to STATUS, please register the scheme in the the W3C XPointer Scheme Registry.

Negotiation of Review Schedule

• The Chair negotiates the Last Call review schedule with the Chairs of groups with dependencies (on chairs@w3.org). Securing review commitments before going to Last Call will help ensure that your document receives wide review. The suggested way to negotiate a last call review schedule is to send a heads-up to the Chairs of groups with dependencies, cc'ing chairs@w3.org. Several weeks prior to the estimated Last Call start date, the Working Group should negotiate schedules with groups where there are dependencies.

Transition request

• The Team Contact reviews the (Team-only) pre-publication steps.
• At least one week prior to an expected meeting with the Director, the The Chair (or Team Contact) Team Contact sends a transition request to the Domain Lead(s) responsible for the group(s) publishing the document, cc'ing w3t-comm@w3.org and chairs@w3.org. We recommend explicitly addressing the Domain Lead by name in the body of the message. Note: For the TAG, no First Public Working Draft transition request is required; the request is assumed to be approved by the Director, who Chairs the TAG. sends a transition request to the Director (and anyone working with the Director on transitions): timbl@w3.org, ralph@w3.org, plh@w3.org, cc'ing w3t-comm@w3.org and chairs@w3.org and the relevant Domain Lead. We recommend explicitly addressing the expected reviewer(s) by name in the body of the message.
• The Team Contact organizes a transition meeting with the Director to discuss the request. Note: When Advisory Committee review indicates unambiguous support, the Director may waive the need for a telephone call.
• The Domain Lead(s) approve the transition request. A Domain Lead MAY ask another Domain Lead (or the Director or someone assigned by the Director) to take responsibility for approving the transition request. The Director approves the transition request.

Publication and Transition Planning

Publication Planning

Publication Planning

• The Document Contact prepares the document in accordance with pubrules and develops a proposed publication schedule, taking into account possible publishing moratoria. The title page date is chosen based on the anticipated publication schedule. Note: Director approval is required for some namespace URIs; see URIs for W3C Namespaces for details.
• Before sending the publication request, the Document Contact SHOULD install the document in its final location. The Document Contact MAY request publication of a document that is not yet installed at its final location, but in this case MUST provide installation instructions to the Webmaster. If a document to be published consists of more than one HTML file (i.e., there are style sheets, schemas, etc.), all materials MUST be made available to the Webmaster from a single directory (which may include subdirectories).
• The Document Contact sends a publication request to the Webmaster at webreq@w3.org, optionally cc'ing w3c-archive@w3.org (which has a Member-visible archive). See below for details about scheduling a publication, and specifically requirements about advance notice to the Webmaster. Note: If the publication is the result of returning a document to a Working Group for further work, the Team Contact alerts the W3C Communications Team by sending to w3t-comm@w3.org a draft announcement for the Membership (required by section 7.4.6 of the Process) that explains why the document was returned for further work.

Form and Mailing List Preparation

Mailing List Preparation

• The Team Contact ensures that there is a mailing list with a public archive available for comments; use the mailing list request form. The Team Contact also ensures that there is a mailing list with a Team-only archive available for AC Representative comments; this list is cited from the review form.
• The Team Contact builds a STATUS review form that the Activity Lead (or Domain Lead) reviews for correctness. Note: At the current time, WBS review forms are generated from installed documents, but before the Webmaster completes publication.
• The Team Contact sends a draft transition announcement to the Communications Team at w3t-comm@w3.org.

Publication and Transition Announcement

Publication

Publication

Transition Announcement

• The Webmaster completes publication and notifies the Chair and Team Contact of publication, cc'ing webreq@w3.org and w3t-comm@w3.org. Note: If the publication is the result of returning a document to a Working Group for further work, the Webmaster alerts the W3C Communications Team.
• After coordination with the Communications Team on the transition announcement timing (especially those accompanied by press releases; see more about interactions with the Communications Team), the Webmaster completes publication and notifies the person who sent the request, cc'ing webreq@w3.org and w3t-comm@w3.org. Publication SHOULD precede the transition announcement by only a small amount of time.
• In order to facilitate peer review, once the document has been published, the Chair sends a transition announcement to chairs@w3.org and the group's public mailing list.
• The W3C Communications Team sends a transition announcement to w3c-ac-members@w3.org and chairs@w3.org and on the W3C home page.
• The Chair SHOULD forward the announcement to the Working Group's public mailing list taking caution not to send any Member-confidential information to a public list.
• If this publication is the result of returning a document to a Working Group for further work, the Communications Team announces that to w3c-ac-members@w3.org and chairs@w3.org.

Note: After announcement of a First Public or Last Call Working Draft, the W3C Communications Team issues a Call for Exclusions in accordance with the W3C Patent Policy.

Note: Instructions for publication of an Ordinary STATUS are included for convenience even though this is not a Recommendation Track transition as defined in the W3C Process.

Note: The Working Group MAY publish a revision of a Candidate Recommendation with minor changes before the next transition.

Note: The Working Group SHOULD NOT publish a (new) revision of a STATUS before the end of the (current) review period.

The message subject line and body SHOULD identify this as a "transition request"; see above for where to send the request. A First Public and Last Call STATUS transition request MUST include:

1. Document title, URIs, and estimated publication date.
2. The document Abstract and Status sections, either by reference (e.g., the URI to the document) or direct inclusion.
3. A statement whether or not the group considers the document to be a delta specification. This statement is only required for documents expected to become normative Recommendations under the W3C Patent Policy.

1. Document title and URIs.
2. Rationale for why it is appropriate to rescind the Recommendation.

Furthermore, the transition request provides evidence that the group has satisfied the transition requirements. The questions and observations in the subsections below provide examples of what SHOULD be in the transition request to help the Domain Lead(s) Director assess whether the group has satisfied the transition requirements. The transition request SHOULD be organized so that it serves as the basis for the agenda of the meeting with the Director.

The goal of the transition request is to secure an archived record of the Director's Domain Lead(s)' approval of the title, and shortname. In the past, shortnames have been changed between versions, and documents have been split and merged between versions. A conservative approach is to treat a merged or split document like a first publication.

The Team Contact(s) generally present the new draft for the entire W3C Team as soon as possible after the transition request (and possibly before Domain Lead approval). The length of the presentation varies (from "more than a lightning talk" to a Project Review) depending on the technical or political complexity of the specification.

Note: All requirements related to a Proposed Edited Recommendation (PER) are limited to the scope of the changes.

Note: When a Working Group "skips CR", then for the transition to Proposed Recommendation, the Working Group must satisfy both the requirements to advance to CR and to advance to PR.

Note: In general, the Director will not approve a request to advance to Proposed Recommendation status if there are any open "exclusion opportunities" under the W3C Patent Policy (per the Patent Policy FAQ, question 24) or any Patent Advisory Groups (PAGs) currently discussing the document (per the Patent Policy FAQ, question 29).

• Have there been any important changes to the document since the previous transition? Include, for example, a link to a change log where important changes are highlighted.
• Would these changes invalidate someone's earlier review? If there have been substantial changes to the document since the previous transition (except for the removal of feature at risk), the Working Group must republish the document as a Working Draft.
• Were features at risk removed?
• If this specification is a revision of a previous Recommendation, does the document clearly state the relation of this version to the previous one? For instance, does it supersede or obsolete the previous Recommendation? Where is this stated (e.g., the status section)? Does the specification explain whether authors should create content according to the previous or current version? Does the specification explain whether processors should continue to process content according to the previous Recommendation?
• If there will be two Recommendations of different major revision numbers, does the newer specification explain the relationship?
• Were there any changes that would affect conformance of software or documents? Have other groups confirmed this? See section 7.6.2 of the Process Document.

• Does this specification have any normative references to W3C specifications that are not yet Proposed Recommendations? See Normative References Guidelines. Candidate Recommendations? Note: In general, documents do not advance to Recommendation with normative references to W3C specifications that are not yet Recommendations. See Normative References Guidelines.
• Have other Groups confirmed that dependencies have been satisfied? For example, does the issues list show that these groups are satisfied as a result of their review of the document? Are there dependencies that have not been satisfied?
• Is there evidence that additional dependencies related to implementation have been satisfied?

• Was there wide review by groups with dependencies?
• Was there review from implementers?
• Was there review from Advisory Committee representatives?
• Any review from other organizations?

• Include a link to an issues list that indicates that the Group has been responsive to reviewers who have raised issues since the previous transition. The Director's expectations are that, as a document advances, the Working Group will keep an increasingly precise record of how it has formally addressed each issue. The Director is responsible for addressing those issues raised by the Advisory Committee during a Proposed Recommendation and Proposed Edited Recommendation review period. Typically the Director consults with the group. Per the Process Document, section 7.3, the Director MAY respond to the reviewer after the close of the Proposed Recommendation review period (e.g., in the announcement of the transition to Recommendation). For substantive issues, especially substantive or serious technical issues the Team Contact should endeavor to understand the reviewer's issues and try to resolve them before sending the Director a request to advance to Recommendation. The request to advance to Recommendation should document the success or failure of these negotiations.
• For changes in the issues list since the previous transition:
  • Highlight issues where the Group has declined to make a change, with rationale. See also Clarification: tables summarizing review Tim Berners-Lee (Tue, Feb 15 2000).
  • Highlight issues where the Group has not satisfied a reviewer and has either not yet responded to the reviewer, or the reviewer has not yet acknowledged the Group's decision.
  • Show, without highlighting:
    • Issues where the Working Group has accepted a proposed change.
    • Issues where the Working Group has clarified the specification to the satisfaction of the reviewer.

• Have there been any objections since the previous transition?
• For each objection, is there a record of the decision, the objection, and attempts to satisfy the reviewer?

• Have the default requirements of the Process Document been satisfied (e.g., implementation of each feature, preferably two implementations)?
• What are the Group's plans for showing implementation of optional features? In general, the Director expects mandatory features and optional features that affect interoperability to be handled similarly. Optional features that are truly optional (i.e., that do not affect interoperability) may require less implementability testing.
• Is there a preliminary implementation report? The implementation report should be a detailed matrix showing which software implements each feature of the specification.
• The request MUST Include a link to a final implementation report, or, if there is no such report, rationale why the Director should approve the request nonetheless.
• What are expectations about additional software that is expected to implement the specification during CR?
• What is the minimal duration of the CR period? Estimate of how long it will take before requesting PR?
• Are there any features at risk?
• Does the WG have additional implementation experience that will help demonstrate interoperability (e.g., has there been an interoperability day or workshop? Is one planned?)?
• Are there tests or test suites available that will allow the WG to demonstrate/evaluate that features have been implemented? If not, what metrics will the WG use? If there are special conditions for this specification related to evaluation of implementations, what are they? Are test suites planned at any time? If there are tests or test suites available, are there links between the tests and the features of the specification they purport to test?

• Has anything changed on the patent disclosure page since the previous transition? Have there been any incomplete or problematic disclosures?
• Are there any open exclusion opportunities? See Patent Policy FAQ question 24: The W3C Team will not, however, start a Proposed Recommendation review period until all current exclusion opportunities for a given specification have ended.
• If the group is not using IPP: Does the disclosure page conform to the patent policy requirements?

For a STATUS transition, the convention is to hold a transition meeting attended by:

• The Team contact(s)
• The Domain Leader (or someone appointed by them), who generally chairs the meeting.
• Those assigned by the Director to manage transitions.
• The Director should be invited to attend the meeting if the transition involves contentious issues such as IPR, technical or other concerns.
• The Working Group Chair(s)
• Others invited by the Domain Leader (or whoever is chairing the transition meeting)
• In the event that the specification significantly affects the work of another WG, a (non-Team) representative of that Group should be invited to the call.

Note: Per announcement to the Chairs, beginning in February 2007, the Comm Team and QA do not generally attend transition meetings.

The Team Contact is responsible for the execution of the following (under the supervision of the Domain Leader):

1. Scheduling the meeting. To allow chairs of WGs with dependencies and other commenters time to review the treatment of last call comments in the disposition of comments document, the transition request MUST be sent a minimum of seven days prior to the transition meeting.
2. Reserving a teleconference bridge.
3. Choosing a scribe prior to the meeting.
4. Ensuring that the meeting record is distributed to the participants. The meeting record (typically a link to an IRC log) must include the decision, and should highlight all recommendations. The meeting record should be sent to all participants attendees, and MUST be cc'ed to w3t-archive@w3.org.

Administrative

1. Is everyone here?
2. Confirmation of Chair, Scribe
3. Are any changes required to the agenda?

Review of the transition request

In particular, review those items highlighted as requiring the Director's attention.

Decision

The Director assesses whether the W3C Process has been followed and whether there is sufficient consensus to support the transition request. In most cases the decision to make the transition is made during the teleconference. However the decision could take up to two weeks if any difficult issues arise during the meeting. The Director may delegate the W3C decision; see Team processes for TR publications.

Next steps

1. If the decision is negative: how do we repair the problem? what happens next? who does what? Note: If documents have been copied to /TR space, please remove them.
2. If the decision is positive: how do we announce this decision? when? what is the plan and schedule for any communications opportunities, including Member testimonials? any action items from this meeting?

• The technical report has been substantively modified since the previous transition. In this case, the document is returned to the Working Group for further work.
• The Director is not satisfied with how the Working Group has addressed issues.
• The Working Group has issued a transition request despite a Formal Objection and the Director is not satisfied with the Working Group's rationale.

A publication request is an assertion from the Document Contact that the document satisfies the pubrules requirements. The subject line and body SHOULD identify this as a "publication request"; see above for where to send the request. A publication request MUST include the following information.

1. Document title and URI(s). Document URI requirements are described in Publication Rules.
2. One or two sentences of description of the specification (for communication purposes on the "current status" pages). The sentence may be taken from the abstract. As an example, see status section for specifications related to mobile web authoring. These status pages, as their name suggests, let the community know about relationships among close specifications, what to use and not to use, how things fit together, etc. Contact the Comm Team with questions at w3t-comm@w3.org. Note: The Webmaster may also ask the Document Contact for assistance in categorizing the specification in an existing (or new) group on the TR page.
3. A proposed publication schedule.
4. Whether the only change since the previous Last Call (if any) is that text has been deleted; If so, W3C can skip the Patent Policy Exclusion (see the Patent Policy FAQ).
5. Record of approval of the transition request.
6. Record of W3M decision to close the group.
7. Evidence that publication is in accordance with expectations set by the group charter (e.g., quote the charter).

Note: Someone from the W3C management team (usually the relevant Domain Leader) SHOULD be aware of the status of the document.

The Document Contact negotiates a publication date with the Webmaster. Each publication request SHOULD propose a publication date. If the request does not include a proposed publication date, the Webmaster MAY consider the title page date as the proposed publication date.

As of 2 March 2010 (cf. the announcement to chairs) the Webmaster publishes on Tuesdays and Thursdays. Regarding advance notice:

• if the checker reports issues that are confusing, please send the publication request no later than 3 business days prior to the desired publication date and in the request explicitly state which issues require Webmaster attention.
• otherwise, please send the publication request no later than 1 business day prior to the publication date (and 2 days is even better).

If the Webmaster finds errors during the publication process, he will endeavor to publish on the desired date, but he MAY also postpone publication to the next available publication date in order to resolve issues. In general, it will not be necessary to change the title page date of a document that is published a couple of days later than planned. If it becomes apparent that a publication date will be well after a title page date, the Webmaster SHOULD ask the Document Contact to resubmit a revised document with a more current title page date.

When scheduling publication, please note that publishing "blackouts" occur at the end of the calendar year and around certain W3C events such as AC meetings and All-Group meetings. The Communications Team announces these publishing moratoria with approximately six months notice. The announcements are linked from the Chairs' Guidebook.

In order to ensure publication standards, upon receiving a publication request the Webmaster SHALL make a best effort to verify that the document satisfies the pubrules requirements except for the accessibility requirements of section 1.6. The Webmaster SHALL publish the document (cf. the Webmaster's guide) if the following conditions have been met:

1. The publication request is complete, and
2. The document satisfies the pubrules requirements verified by the Webmaster.

Otherwise the Webmaster SHALL NOT publish. In this case, the Webmaster SHALL provide details to the person who sent the request about which requirements have not been satisfied.

The Webmaster SHALL NOT publish the document until the date on the title page or later. The Webmaster publishes the document by updating the appropriate technical report index and updating the latest version link, and then announcing publication as described above.

A First Public and Last Call STATUS transition announcement MUST include the following information:

1. That this is a STATUS transition announcement.
2. Document title, URIs.
3. Instructions for providing feedback.
4. Review end date.
5. Link to information about the review; generally this is a link to an online form (created by the Team Contact). The following information from the transition request MUST be available (generally in the form):
   • title, abstract, and status. Note: It is useful to draw the reviewer's attention in the review form to important information, even if some of that information is duplicated in the status section due to pubrules requirements.
   • implementation information
   • information about changes
   • information about wide review (link to an issues list)
6. Information about any Formal Objections.
7. Link to a public (home) page for the group that produced the document.

Please use the Team-only transition announcement template as a starting point.

1. That this is a STATUS transition announcement.
2. Document title, URIs.
3. Instructions for providing feedback.
4. A reference to the group's transition request.
5. Minimal duration before next transition request.
6. Links to evidence that requirements for the transition have been satisfied (i.e., the same information that was in the transition request).
7. Report of any Formal Objections.
8. Whether this publication is the result of returning a document to a working group for further work as a Candidate Recommendation.
9. Document abstract and status.

Please use the Team-only transition announcement template as a starting point.

1. That this is a STATUS transition announcement.
2. Document title, URIs.
3. A paragraph introducing the work, usually the Abstract.
4. Indication, in general terms, of level of support of Membership. Note: As a policy, the Team does not announce detailed results (i.e., numbers of reviews) of a Proposed Recommendation review to the Membership or Public, except for information regarding formal objections.
5. Report of any Formal Objections.
6. Any additional information for companion document(s).

1. That this is a First Public STATUS transition announcement.
2. Document title, URIs.
3. Instructions for providing feedback.
4. A reference to the group's transition request.

Note: The First Public Working Draft is significant with respect to the W3C Patent Policy. As explained in the Patent Policy FAQ, the Communications Team issues a Call for Exclusions (see section 4 of the W3C Patent Policy) approximately ninety days after the publication of this draft.

1. That this is a First Public and Last Call STATUS transition announcement.
2. Document title, URIs.
3. Instructions for providing feedback.
4. Review end date.
5. A reference to the group's decision to make this transition.
6. Evidence that the document satisfies group's requirements. Include a link to requirements (e.g., in the charter or requirements documents). Does the requirements document indicate where in the specification the requirements are met?
7. The names of groups with dependencies, explicitly inviting review from them.
8. Report of any Formal Objections.
9. A link to a patent disclosure page.

The Last Call transition announcement SHOULD provide information about where people can learn about issues raised during the Last Call review period (e.g., a link to an issues list).

The Last Call transition announcement MAY indicate priority feedback items. Please note that as of Last Call, no technical issues should be open, even though the Working Group may request feedback on particular choices they have made.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3