Organize a Technical Report Transition (2023 Process)

Not sure what's your next step? Try our step finder and look at milestones calculator.

About This Document anchor

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.

Steps for transition to First Public Working Draft  anchor

Once the Process Document requirements for the transition to First Public Working Draft have been satisfied (see section 6.3.5 ), W3C follows the steps described below to complete the transition. 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 (or updates) an Internet Media Type, before the transition to First Public Working Draft, see also Register an Internet Media Type for a W3C Specification to review the entire Internet Media Type registration process.

Transition request
  • The Document Contact creates a transition request in w3c/transitions. Note: For the TAG, no First Public Working Draft transition request is required; the request is assumed to be approved by the Team. A public archive of transition requests is available (since October 2019).
  • Following an initial review by the Team, the Document Contact MAY be asked to organize a transition meeting with the Team to discuss the request.
  • The Project Management Lead approve the transition request. The Lead MAY ask the CEO (or someone assigned by the CEO) to take responsibility for approving the transition request.
Publication Planning
  • The Document Contact ensures that there is a public archived place (github or mailing list) available for comments; (for mailing list, the Team Contact uses the mailing list request form).
  • 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.
  • Before sending the publication request, the Team 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.
Publication and 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.
  • The W3C Communications Team makes an announcement on the W3C home page.

 

Transition Requirements for Working Draft anchor

The Working Group:

  • must record the group’s decision to request advancement.

    Provide a link to meeting minutes, github issues, or email announcing the decision.

  • must obtain Team verification.

    Submit a transition request.

  • must provide public documentation of any Formal Objections.

    Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.

  • should provide information about implementations known to the Working Group.

Transition request anchor

A First Public Working Draft 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 URL to the document) or direct inclusion.
  3. A statement whether or not the group considers the document to be a delta specification.
  4. Fulfill the requirements for the Advancement on the Recommendation Track.
  5. Has anything changed on the patent disclosure page since the previous transition? Have there been any incomplete or problematic disclosures?

To submit a transition request, open a new issue in w3c/transitions.

Transition Meeting with the Team anchor

For a Working Draft transition, the CEO, or its delegates, may request a transition meeting attended by:

  • The Team contact(s)
  • The Project Management Lead (or someone appointed by him), who generally chairs the meeting.
  • Those delegated by the Team to approve the transition.
  • The Team should be invited to attend the meeting if the transition involves contentious issues such as IPR, technical or other concerns.

The Team Contact is responsible for the execution of the following (under the supervision of the Project Management Lead):

  1. Scheduling the meeting. To allow chairs of WGs with dependencies and other commenters time to review the treatment of review 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.

Sample agenda anchor

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 Team's attention.
Review of the horizontal tracker boards
Ensure that all horizontal *-needs-resolution issues are closed by the relevant horizontal review group.
Decision
The Team 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 Team 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?

Some reasons for declining a transition request

  • The Team is not satisfied after its verification with how the Working Group fulfilled the requirements for advancement.
  • The Working Group has issued a transition request despite a Formal Objection and the Council is not satisfied with the Working Group's rationale.

Per section 6.3.3 of the Process, "The Team MUST inform the Advisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity stage is declined and the specification is returned to a Working Group for further work."

Scheduling Publication anchor

The Webmaster publishes on Tuesdays and Thursdays (cf. the announcement to chairs).

Please send advance notice to webreq@w3.org:

  • 3 business days in advance: If you need help from the Webmaster to fix errors, or ask for Pubrules error exception.
  • 2 business days in advance: If the document is perfectly ready.

Upcoming publication moratoria are listed below and also available as a Google calendar:

Publication Request anchor

A publication request MUST include the following information:
⟶ You may copy the list below and paste into the email sent to webreq@w3.org

  1. Information:
    • Document Title: xxx xxx
    • Document URL: https://www.w3.org/TR/yyyy/XX-xxx-yyyymmdd/
    • Publication Date: (if document not installed) Month Date Year
    • Description: Used in TR/xx/all page (only needed if differ from the 'Abstract' of the document)
    • Family: Used in the new TR Page to categorize specifications, configured in GitHub w3c/spec-families repo.
    • Document tags: (see the list of tags here)
    • Requirements for shortlinks redirection: (may apply if there are multi levels)
  2. Approvals:
    • Record of approval of the transition request.
    • Team's approval state: (approved / not yet / not needed)
  3. Checks:
    • Pass Pubrules' check: (yes / need Team's exception)
      ⟶ Check the document using Pubrules UI.
      ⟶ How to deal with Pubrules' result:
      • error: should not contain any `error`, unless it's an exception approved by the Team. This could likely block publication
      • warning: Please read through each warning and try to reduce the number of them.
    • Comment on Pubrules: (describe the help you need if there's any error)
    • Pass Link Checker's check: (yes)
      ⟶ Check the document using W3C Link Checker.
      ⟶ How to deal with result of Link Checker:
      • 404 Not Found: should not contain any `404` link. This could likely block publication.
      • 403 Forbidden: Please check manually.
      • Broken Fragments: These kind of error could be false alarm, please check manually.
      • Status: 301: Please consider using the new link.

It is perfectly appropriate to send a publication while waiting for a Team's approval but does run the risk of not receiving the Team's approval in time. Please coordinate with the Project Management Lead if needed.

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.

Publication anchor

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 7. 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.

Call for Exclusions anchor

The Patent Policy FAQ clarifies when Call for Exclusions are sent out.

The Team sends a Call for Exclusion to participants. The exclusion opportunity lasts 150 days. At approximately 90 days, The Team sends out a reminder with a pointer to the "Patent Review Draft".

This document lives in GitHub, where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use GitHub issues.