diff --git a/transitions/index.html b/transitions/index.html index fd6882aa4..2fc22f858 100644 --- a/transitions/index.html +++ b/transitions/index.html @@ -1,431 +1,212 @@ - - - - - - - How to Organize a Technical Report Transition (2023 Process) - - - - - - - - - - - - - - - -
-

Publication Policies

- -

Resources

- -

Tools

-
+

 

-

About This Document

+

About This Document

-

This resource describes the internal W3C Technical Report +

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 - an update request for a - publication of a +

Steps for + transition to + an update request for a + publication of a publication of an LABEL Snapshot @@ -441,54 +222,40 @@

Steps for

- + Once the Process Document requirements for the transition to LABEL have been satisfied (see - section 6.3.5 - section 6.3.7 - section 6.3.8.1 - section 6.3.9 - - section + section 6.3.5 + section 6.3.7 + section 6.3.8.1 + section 6.3.9 + + section 6.3.11.5 and section 6.3.4 - section 6.3.11.3 - section 6.3.11.4 + section 6.3.11.3 + section 6.3.11.4 - section 6.3.10 + section 6.3.10 or section 6.3.12.4 for restoring a Recommendation - section 6.3.12.4 + section 6.3.12.4 - section 6.3.12.4), + section 6.3.12.4), W3C follows the steps described below to complete the transition. - Once the Group determined that the requirements of section 6.3.6 apply, the W3C follows + Once the Group determined that the requirements of section 6.3.6 apply, the W3C follows the steps described below to update a STATUS. - Once the Group, or the Maintainer Contact, determined that the requirements of section 6.3.11.2 apply, the W3C follows + Once the Group, or the Maintainer Contact, determined that the requirements of section 6.3.11.2 apply, the W3C follows the steps described below to update a STATUS. - Once the Group determined that the requirements of section 6.3.8.2 have been + Once the Group determined that the requirements of section 6.3.8.2 have been satisfied, the Working Group follows the steps described below to publish a STATUS. @@ -504,13 +271,11 @@

Steps for in parallel with the publication request steps.

-

+

Note: If your specification involves (or updates) an Internet Media Type, before the transition to First Public - STATUS, see also How to Register + STATUS, see also How to Register an Internet Media Type for a W3C Specification to review the entire Internet Media Type registration process. @@ -528,8 +293,7 @@

Steps for

Note: If your specification defines (or updates) an XPointer - Scheme, before the transition to STATUS, please register the scheme in the W3C XPointer Scheme + Scheme, before the transition to STATUS, please register the scheme in the W3C XPointer Scheme Registry.

@@ -546,7 +310,7 @@

Steps for wide review in order to move to Candidate Recommendation. The Group MUST show that all horizontal *-needs-resolution issues have been closed by the relevant - horizontal group in the horizontal group's tracker + horizontal group in the horizontal group's tracker in order to publish the STATUS. The Group MUST show that any horizontal *-needs-resolution issues have been acknowledged in order to publish @@ -559,33 +323,23 @@

Steps for -
Transition request
+
Transition request
Update request
-
+
  • If an individual - made a request to the relevant Working Group, or the TAG (using w3ctag/obsoletion) if such a group does not exist, + made a request to the relevant Working Group, or the TAG (using w3ctag/obsoletion) if such a group does not exist, to obsolete or to supersederescind a Recommendation, and the request was not answered within 90 days, the individual should send his request to webreq@w3.org, cc'ing plh@w3.org, www-archive@w3.org.
    • -
  • - At least one week prior to an expected +
  • + At least one week prior to an expected decision from or meeting with the Team, the - The Document Contact - - - creates a transition request in w3c/transitions. - For the purpose of the automatic publishing + The Document Contact + + + creates a transition request in w3c/transitions. + For the purpose of the automatic publishing system, it's important that the title of the issue ends with the shortname of your specification, thus you will need one single issue for each specification. Note: @@ -596,86 +350,71 @@

    Steps for sends a transition request to the Team: ralph@w3.org, plh@w3.org, cc'ing ylafon@w3.org, - w3t-comm@w3.org. An issue is also created in w3c/transitions (for tracking purposes). + w3t-comm@w3.org. An issue is also created in w3c/transitions (for tracking purposes). A public archive of transition requests is available (since October 2019). -

    • + -
  • - Following an initial review by the Team, the Document Contact +
  • + 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 Industry or Strategy 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. - + The Team verifies the transition request. - Approvals are expected to appear as an issue comment "Transition - approved." in w3c/transitions + Approvals are expected to appear as an issue comment "Transition + approved." in w3c/transitions and - the label 'Awaiting + the label 'Awaiting Publication' will need to be set. - + In most cases the decision to approve the transition is made on Fridays.
-
+
Publication Planning
@@ -694,8 +433,7 @@

Steps for
  • If the publication is the result - of stopping work on a specification, the Document Contact + of stopping work on a specification, the Document Contact alerts the Webmaster at webreq@w3.org, optionally cc'ing w3c-archive@w3.org (which has a Member-visible archive). @@ -704,20 +442,17 @@

    Steps for -
    +
    Form and Announcement Preparation
    -
    Announcement Preparation
    -
    +
    Announcement Preparation
    +
    -
    Publication and Transition Announcement
    +
    Publication and Transition Announcement
    Publication and Update Announcement
    -
    Publication
    +
    Publication
    Transition Announcement
      -
    • The Webmaster completes publication and notifies the Chair - and Team Contact of publication, cc'ing webreq@w3.org +
    • The Webmaster completes publication and notifies the Chair + and Team Contact of publication, cc'ing webreq@w3.org and w3t-comm@w3.org.
      • -
    • The Document +
    • The Document Contact publishes the document using the W3C automatic system.
      • -
    • +
    • After coordination with the Communications Team on the transition announcement timing (especially those accompanied by press releases; see more about @@ -866,15 +582,13 @@

      Steps for Since September 2015, the Communications Team no longer posts homepage news for regular WDs, unless explicitely requested.

      • -
    • +
    • The W3C Communications Team sends the transition announcement to w3c-ac-members@w3.org and chairs@w3.org - and on the W3C home page. + and on the W3C home page. The Advisory Committee review is started. The Call for Exclusions and the Advisory Committee review are started.
      • @@ -884,15 +598,13 @@

      Steps for to chairs@w3.org and on the W3C home page. -
    • The Chair or Team Contact(s) SHOULD forward +
    • The Chair or Team Contact(s) 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.
    • The - Document Contact SHOULD forward the announcement to the Working + Document Contact SHOULD forward the announcement to the Working Group's public mailing list.
      • @@ -916,39 +628,33 @@

      Steps for

      Note: STATUS - is not a maturity stage defined in the W3C Process but is described as a proposal before the next + is not a maturity stage defined in the W3C Process but is described as a proposal before the next step.

      -
      - -
      -
      -

      Transition Requirements for STATUS

      -

      The decision to advance a document to Recommendation is a - W3C Decision. +

      +

       

      +
      +
      +

      Transition Requirements for STATUS

      +

      The decision to advance a document to Recommendation is a + W3C Decision.

      -

      The Working - GroupW3C:

      +

      The Working + GroupW3C:

        -
      • must record the group’sindividual(s) decision to request advancement. -

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

        +
      • must record the group’sindividual(s) decision to request advancement. +

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

        -

        For a Recommendation, you may reuse the group's decision to move to +

        For a Recommendation, you may reuse the group's decision to move to Proposed Recommendation.

        • -
      • must obtain Team +
      • must obtain Team verification. -

        Submit a transition request.

        +

        Submit a transition request.

        • -
      • must publicly +
      • must publicly document all new features (class 4 changes) to the technical report @@ -956,12 +662,12 @@

        Transition Requirements for S

        Include a link to a change log where new features are highlighted, highlight them in the Status of the Document.

        • -
      • must not contain new features +
      • must not contain new features (class 4 changes) to the technical report since the Recommendation.
        • -
      • must publicly document if other substantive changes +
      • must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.
        @@ -977,19 +683,15 @@

        Transition Requirements for S 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?
        • -
      +

    • -
  • should publicly document if editorial +
  • should publicly document if editorial changes have been made, and may document the details of such changes.
    • -
  • must formally address all issues - raised about the document since the previous maturity level. -
    +
  • must formally address all issues + raised about the document since the previous maturity level. +
    • Include a link to an issues list, such as GitHub issues, that indicates that the group has been responsive to reviewers who have raised issues since the previous transition. The Team's @@ -997,10 +699,9 @@

      Transition Requirements for S has formally addressed each issue.

    • 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 +
      • 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:
          @@ -1009,62 +710,52 @@

          Transition Requirements for S reviewer.

        • - +
    • -
  • should formally +
  • should formally address all errata raised about the document since the Recommendation. -

    Include a link to an issues list, such as GitHub issues, that indicates that errata have been +

    Include a link to an issues list, such as GitHub issues, that indicates that errata have been responded.

    • -
  • must provide public documentation of any Formal Objections. +
  • 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 report which, if any, of the Working Group'sindividual(s) requirements +
  • should report which, if any, of the Working Group'sindividual(s) requirements for this document have changed since the previous step.
    • -
  • should report any changes in +
  • should report any changes in dependencies with other groups. -
    +
    • In general, documents do not advance to Proposed Recommendation with normative references to other - specifications that are considered unstable. See also Normative References Guidelines.
      • + specifications that are considered unstable. See also Normative References Guidelines.
    • Documents must not include normative references to a Rescinded/Obsolete/Superseded Recommendation.
    • -
  • should - provide information about implementations known to the Working Groupindividual(s). -

    +
  • should + provide information about implementations known to the Working Groupindividual(s).
    • -
  • must provide information about +
  • must provide information about implementations known to the individual(s). -

    See implementation experience

    +

    See implementation experience

    • -
  • must provide information about implementations known to the - Working Groupindividual(s). +
  • must provide information about implementations known to the + Working Groupindividual(s).
      -
    • Unless this information changed since the previous +
    • Unless this information changed since the previous transition, indicate "No change".
      • -
    • Include a link to a final implementation report, or, if there is +
    • Include a link to a final implementation report, or, if there is no such report, rationale why the Team should approve the request nonetheless.
      • -
    • If you use WPT results, provide a snapshot of those results, e.g wpt.fyi +
    • If you use WPT results, provide a snapshot of those results, e.g wpt.fyi snapshot of webauthn (save a copy of the resulting report)
    @@ -1072,43 +763,35 @@

    Transition Requirements for S

    • -
    +

    Requirements for revising a STATUS

    -

    A Working Group should publish a Working Draft to the W3C Technical Reports page +

    A Working Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.

    If 6 months elapse without significant changes to a specification, - a Working Group should publish a revised Working Draft, + a Working Group should publish a revised Working Draft, whose status section should indicate reasons for the lack of change.

    To publish a revision of a Working draft, a Working Group:

    -
    +

    Requirements for updating a STATUS

    -

    WARNING: If your existing Recommendation was not - approved for accepting new features, +

    WARNING: If your existing Recommendation was not + approved for accepting new features, you are not allowed to follow these steps. You MUST follow the First Public Working Draft steps instead.

    -

    The decision to incorporate proposed amendments in a Recommendation is a - W3C Decision. +

    The decision to incorporate proposed amendments in a Recommendation is a + W3C Decision.

    -

    The Working Group:

    -

    The W3C:

    +

    The Working Group:

    +

    The W3C:

      -
    • must obtain Team +
    • must obtain Team verification, or fulfill the criteria for Streamlined Publication Approval.

      Submit an update request.

    • must record the group’s decision to request the update. -

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

      +

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

      • -
    • must show that the changes - proposed amendments have received wide +
    • must show that the changes + proposed amendments have received wide review. -
      +
      • Was the public requested to review the changes (such as announcement from a previous publication)?
      • Which are the groups with dependencies, per the Group's charter, and did they review the document?
        • -
      • Were the horizontal groups given proper opportunities to review subtantive changes? Are there any *-needs-resolution +
      • Were the horizontal groups given proper opportunities to review subtantive changes? Are there any *-needs-resolution issue pending?
      • Was there early review from implementers? Are the changes already deployed in implementations?
        • -
      • +
      • Streamlined Publication Approval requires, for each of the W3C Horizontal Groups, if the Horizontal Review Group has made available a set criteria under which their review is not necessary, @@ -1168,15 +845,12 @@

        Requirements for updating a STATU

      - Proposed amendments can only be incorporated as-is, per section 6.3.11.5. + Proposed amendments can only be incorporated as-is, per section 6.3.11.5.

      • -
    • - Streamlined Publication Approval requires the group to formally address: +
    • + Streamlined Publication Approval requires the group to formally address:

      • all issues raised against the document that resulted in changes since the previous publication

        @@ -1193,24 +867,22 @@

        Requirements for updating a STATU of the person who raised it: their proposal has been accepted, or a compromise has been found, - or they accepted the Working Group’s rationale for rejecting it. This implies no pending *-needs-resolution issues, + or they accepted the Working Group’s rationale for rejecting it. This implies no pending *-needs-resolution issues, and no pending PAG conclusions.

        • -
      • must provide public documentation of any Formal +
      • 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.
          • -
        • +
        • Streamlined Publication Approval requires no formal objection have been registered.
          • -
        +
    -
  • must publicly document of all new +
  • must publicly document of all new features (class 4 changes) to the technical report @@ -1226,33 +898,30 @@

    Requirements for updating a STATU must not happen, unless it was a proposed amendment.

    • -
  • should publicly document if editorial +
  • should publicly document if editorial changes changes have been made, and may document the details of such changes.
  • must show that the revised specification - meets all Working Group requirements, + meets all Working Group requirements, or explain why the requirements have changed or been deferred,
    • Where are the requirements defined (e.g,. a charter or requirements document)?
    • Are any requirements previously satisfied no longer satisfied? Are any requirements previously unsatisfied now satisfied?
      • -
    • +
    • Streamlined Publication Approval requires no changes to Working Group requirements.
    • -
  • should report which, if any, of the Working Group's +
  • should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
      -
    • +
    • Streamlined Publication Approval requires no changes to Working Group requirements.
    @@ -1260,19 +929,17 @@

    Requirements for updating a STATU

  • should report any changes in dependencies with other groups.
    • -
  • should provide information about implementations known to the Working Group. +
  • should provide information about implementations known to the Working Group.
    • -
    +
    • must show that the specification - has met all Working - Groupindividual(s) + has met all Working + Groupindividual(s) requirements, or explain why the requirements have changed or been deferred,
      @@ -1289,8 +956,7 @@

      Requirements for updating a STATU
    • Does this specification have any normative references to other specifications that are not yet stable? The Team's expectations are that, as a document advances, there will be an increasingly need - for normative referenced materials to be scrutinized. See Normative References Guidelines. + for normative referenced materials to be scrutinized. See Normative References Guidelines.
    • Does this specification have any normative references to a Rescinded/Obsolete/Superseded Recommendation? Documents must not include normative references to a @@ -1308,10 +974,9 @@

      Requirements for updating a STATU

    • must document - how adequate implementation experience will be demonstrated, + how adequate implementation experience will be demonstrated, -
      +

      This is also known as "CR exit criteria".

      • Are there tests or test suites available that will allow the WG to demonstrate/evaluate that features @@ -1328,12 +993,9 @@

        Requirements for updating a STATU

      • -
    • may identify features in the document as at risk. +
    • may identify features in the document as at risk. These features may be removed - before advancement to Proposed Recommendation without a requirement to publish a new Candidate + before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

      If any, the list of features at-risk must appear in the Status of the Document.

      @@ -1343,10 +1005,9 @@

      Requirements for updating a STATU and should be longer for complex documents, and,

      This deadline must appear in the Status of the Document.

      • -
    • must show that the specification has received wide +
    • must show that the specification has received wide review. -
      +
      @@ -1365,7 +1025,7 @@

      Requirements for updating a STATU

      -
      +
        @@ -1374,12 +1034,9 @@

        Requirements for updating a STATU and should be longer for complex documents,

        This deadline must appear in the Status of the Document.

        -
      • may identify features in the document as at risk. +
      • may identify features in the document as at risk. These features may be removed - before advancement to Proposed Recommendation without a requirement to publish a new Candidate + before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

        The list of features at-risk must appear in the Status of the Document, if any.

        @@ -1387,13 +1044,10 @@

        Requirements for updating a STATU

      -
      -

      Requirements for publishing a STATUS

      +
      +

      Requirements for publishing a STATUS

      -

      A Working Group should publish an Update Draft to the W3C +

      A Working Group should publish an Update Draft to the W3C Technical Reports page when there have been significant changes to the previous published document @@ -1402,29 +1056,23 @@

      Requirements for publishing a The Working Group:

      -
      -

      Updating a STATUS with editorial changes

      +
      +

      Updating a STATUS with editorial changes

      The Working Group:

      -
      +

      Requirements for requesting a STATUS

      The request:

        @@ -1663,35 +1272,32 @@

        Requirements for requesting a STATUS

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

        -
      • must include rationale for the proposal.
        • +
      • must include rationale for the proposal.
      • must provide the Document title and URLs of the newer version, if any.
        • -
      • must identify known dependencies.
        • -
      • should provide information about known +
      • must identify known dependencies.
        • +
      • should provide information about known implementations.
        • -
      • should publish documentation of significant changes to +
      • should publish documentation of significant changes to the technical report since any previous publication.
      -

      +

      The Team must then submit the request to the Advisory Committee for review.

      -
      -

      Transition requirements to STATUS

      +
      +

      Transition requirements to STATUS

      The W3C:

        -
      • must obtain Team +
      • must obtain Team verification. -

        Submit a transition request.

        +

        Submit a transition request.

        • -
      • must formally +
      • must formally address all issues - raised about the document since the previous maturity level. -
        + raised about the document since the previous maturity level. +
        • Include a link to an issues list, such as GitHub issues, that indicates that the group has been responsive to reviewers who have raised issues since the previous transition. The Team's expectations @@ -1699,10 +1305,9 @@

          Transition requirements to STA addressed each issue.

        • 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 +
          • 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:
              @@ -1711,25 +1316,22 @@

              Transition requirements to STA reviewer.

            • - +
        • -
      • must provide public documentation of any Formal Objections. +
      • 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.

      • If there was any dissent in Advisory Committee reviews, - the Team must publish the substantive content of the dissent + the Team must publish the substantive content of the dissent to W3C and the general public, - and must formally address the comment + and must formally address the comment at least 14 days before publication as a W3C Recommendation.
        @@ -1742,18 +1344,14 @@

        Transition requirements to STA
      • Provide link(s) to the Advisory Committee reviews, issues where the dissent was made public, and where the comment was addressed.

      -
      • +
    -
    -

    Transition requestUpdate Request

    +
    +

    Transition requestUpdate Request

    Tip: When updating an existing Candidate Recommendation, focus your new request on what @@ -1761,45 +1359,37 @@

    +

    An First Public STATUS - transitionupdate request MUST + transitionupdate request MUST include:

      -
    1. Document title, URIs, and estimated +
    2. Document title, URIs, and estimated publication date.
    3. The document Abstract and Status sections, either by reference (e.g., the URL to the document) or direct inclusion.
      4. -
    4. +
    5. A statement whether or not the group considers the document to be a delta specification.
      6. -
    6. Fulfill the requirements for the Advancement on the Recommendation Track.
      7. -
    7. Fulfill the requesting the STATUS.
      8. -
    8. Fulfill the requirements for the update request.
      9. +
    9. Fulfill the requirements for the Advancement on the Recommendation Track.
      10. +
    10. Fulfill the requesting the STATUS.
      11. +
    11. Fulfill the requirements for the update request.
    12. Has anything changed on the patent disclosure page since the previous transition? Have there been any incomplete or problematic disclosures?

    -
    +

    Transition Meeting with the Team

    @@ -1810,8 +1400,7 @@

    Transition
    • The Team contact(s)
      • -
    • The Maintainer Contact
      • +
    • The Maintainer Contact
    • The Project Management Lead (or someone appointed by him), who generally chairs the meeting.
      • @@ -1822,18 +1411,13 @@

      Transition transition involves contentious issues such as IPR, technical or other concerns. -
    • The Working Group Chair(s)individual(s)
      • +
    • The Working Group Chair(s)individual(s)
      • -
    • Others invited by the Project Management Lead (or whoever is +
    • Others invited by the Project Management Lead (or whoever is chairing the transition meeting)
      • -
    • In the event that the specification significantly affects the +
    • 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.
      • @@ -1864,7 +1448,7 @@

      Transition -

      Sample agenda

      +

      Sample agenda

      Administrative
      @@ -1909,8 +1493,7 @@

      Sample agenda

    • If the decision is positive: how do we announce this decision? when? what is the plan and schedule for any - communications opportunities, including Member + communications opportunities, including Member testimonials? any action items from this meeting?
      • @@ -1920,15 +1503,13 @@

      Sample agenda

      Some reasons for declining a transition request

        -
      • - The Team is not satisfied after its verification with how the Working Group fulfilled +
      • + 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 + Formal Objection and the Council is not satisfied with the Working Group's rationale.
        • @@ -1947,8 +1528,7 @@

        Some reasons for declining a transition request

      -

      Per section 6.3.13.4, in some conditions, the +

      Per section 6.3.13.4, in some conditions, the Team is required to accept the transition request.

      @@ -1963,26 +1543,19 @@

      Some reasons for declining a transition request

    -
    +
    -

    - Scheduling Publication -

    +

    Scheduling Publication

    -

    - Tip: STATUSs published through the W3C automatic system do not need to get scheduled with the +

    + Tip: STATUSs published through the W3C automatic system do not need to get scheduled with the Webmaster and are not subjected to publishing moratoria.

    -

    7 days for transition: Unless there are exceptional - circumstances, the Team requires a minimum of 7 days period between the transition request and the publication. +

    7 days for transition: Unless there are exceptional + circumstances, the Team requires a minimum of 7 days period between the transition request and the publication. - This allows other Groups or outside individuals to review the transition request and may formally object within this period. + This allows other Groups or outside individuals to review the transition request and may formally object within this period. While the Team strives to address transitions within this 7 days period, delays due to transition issues or competing Team's priorities are not unheard of and may increase the length of the period needed. Group @@ -1994,14 +1567,13 @@

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

      -

      Publication Request

      +

      Publication Request

      Note: Someone from the W3C @@ -2012,8 +1584,8 @@

      Publication Request

      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
            • @@ -2038,7 +1610,7 @@

            Publication Request

            *Document tags update: (see the list of tags here) -
          • *Retired: (only needed when 'yes')
            +
          • *Retired: (only needed when 'yes')
            ⟶ Indicate if the publication is the result of stopping work on a specification (aka "retired").
            • @@ -2047,65 +1619,56 @@

            Publication Request

          • Approvals:
              -
            • Record of +
            • Record of approval of the transition request.
              • -
            • Record of approval of the +
            • Record of approval of the update request.
            • Record of W3M decision to close the group.
              • -
            • Team's approval state: +
            • Team's approval state: (approved / not yet / not needed)
            • Evidence that publication is in accordance with expectations set by the group charter (e.g., quote the charter).
              • -
            • Record of +
            • Record of approval of the Group.
          • *Skip CfE for CR text delete: (only needed when 'yes')
            ⟶ If there has been a previous Candidate Recommendation, whether the only change is - that text has been deleted; If so, W3C can skip the Patent Policy Exclusion (see the Patent Policy FAQ). + that text has been deleted; If so, W3C can skip the Patent Policy Exclusion (see the Patent Policy FAQ).
          • Checks:
            • Pass Pubrules' check: (yes / need Team's exception) -
              ⟶ Check the document using Pubrules +
              ⟶ Check the document using               Pubrules UI              . -
              ⟶ How to deal with Pubrules' result: +
              ⟶ 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. -
                • +
              • 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 +
              ⟶ Check the document using               W3C Link Checker              . -
              ⟶ How to deal with result of 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.
                • +
              • 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 @@ -2129,15 +1692,13 @@

        Publication Request

        these publishing moratoria with approximately six months notice. The announcements are linked from the Chairs' Guidebook.

        -

        Publication

        +

        Publication

        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 + 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:

        @@ -2162,7 +1723,7 @@

        Publication

      1. The publication request is complete, and
      2. The document indicates clearly its new status verified by the Webmaster. The updated version may remove the main body of the - document.
        3. + document.

    Otherwise the Webmaster SHALL NOT @@ -2177,8 +1738,7 @@

    Publication

    -
    +

    Transition Announcement

    An @@ -2219,8 +1779,7 @@

    Transition Announcement

    -
    +
    1. That this is a STATUS @@ -2233,7 +1792,7 @@

      Transition Announcement

    2. Review end date.
      3. -
    3. Link to information about the review; this is the link +
    4. Link to information about the review; this is the link to an online review form (WBS) created by the Team Contact. The following information from the transition request MUST be available (generally in the @@ -2247,7 +1806,7 @@

      Transition Announcement

    5. implementation information
    6. information about changes
      7. -
    7. information about obsoleting or superseding previous Recommendations, if applicable. +
    8. information about obsoleting or superseding previous Recommendations, if applicable. This avoids sending an additional WBS survey just for the purpose of obsoleting/superseding a Recommendation.
    9. information about wide review
      10. @@ -2260,8 +1819,7 @@

      Transition Announcement

    -

    Please use the Team-only +

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

    @@ -2294,8 +1852,7 @@

    Transition Announcement

  • Document abstract and status.
    • -

    Please use the Team-only +

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

    @@ -2316,7 +1873,7 @@

    Transition Announcement

    -
    +
    1. That this is an STATUS @@ -2341,18 +1898,15 @@

      Transition Announcement

    -

    Please use the Team-only +

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

    -

    Please use the Team-only +

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

    -
    +
    1. That this is a First Public @@ -2369,8 +1923,7 @@

      Transition Announcement

    -
    +

    Call for Exclusions

    The Patent Policy FAQ clarifies @@ -2378,62 +1931,53 @@

    Call for Exclusions

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

    -

    +

    If the document was published within 90 days of the First Public Working Draft, it becomes the new Patent Review Draft for the Call for Exclusions started at the time of the First Public Working Draft publication. - Exclusions are with respect to the set of features in this new STATUS. + Exclusions are with respect to the set of features in this new STATUS.

    - A Working Group under the W3C Patent Policy publishes a STATUS. + A Working Group under the W3C Patent Policy publishes a STATUS. The Team sends the second exclusion opportunity. The exclusion opportunity lasts 60 days. Any exclusions are with respect - to new features in the STATUS added since the exclusion + to new features in the STATUS added since the exclusion opportunity of the First Public Working Draft.

    - The Working Group changes the document substantially after STATUS and published a - new STATUS. The Team sends a new exclusion opportunity. It lasts 60 + The Working Group changes the document substantially after STATUS and published a + new STATUS. The Team sends a new exclusion opportunity. It lasts 60 days. Exclusions are with respect to new features in the specification since the previous exclusion - opportunity, i.e., the previous LABEL. + opportunity, i.e., the previous LABEL.

    The Working Group updates the document substantially since the Recommendation and published a - STATUS. The Team sends a exclusion opportunity. It lasts 60 + STATUS. The Team sends a exclusion opportunity. It lasts 60 days. Exclusions are with respect to new features in the specification since the previous exclusion opportunity, i.e., the one applying to the previous Recommendation.

    The Working Group proposes to update the document substantially since the Recommendation and published a - STATUS with proposed changes. The Team sends a exclusion opportunity. It lasts 60 - days. Exclusions are with respect to the proposed changes identified in the + STATUS with proposed changes. The Team sends a exclusion opportunity. It lasts 60 + days. Exclusions are with respect to the proposed changes identified in the specification.

    -
    -
    -

    Feedback is to @w3c/transitions - and is welcome on GitHub

    - - - + + \ No newline at end of file