diff --git a/.github/ISSUE_TEMPLATE/agenda.md b/.github/ISSUE_TEMPLATE/agenda.md new file mode 100644 index 00000000..77c908d8 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/agenda.md @@ -0,0 +1,30 @@ +--- +name: Meeting agenda +about: Agenda discussion for a given Process CG meeting +title: '[agenda] 2025-0x-xx' +labels: 'Meeting agenda' +assignees: 'brentzundel,plehegar' + +--- + +## Proposed Agenda + +1. agenda item 1 +1. agenda item 2 +1. agenda item 3 +1. AOB + +--- + +* [label:"Agenda+"](https://github.com/w3c/process/issues?q=state%3Aopen%20label%3AAgenda%2B) +* [label:"Proposed to close"](https://github.com/w3c/process/issues?q=state%3Aopen%20label%3A%22Proposed%20to%20close%22) +* [label:"Needs proposed PR"](https://github.com/w3c/process/issues?q=state%3Aopen%20label%3A%22Needs%20proposed%20PR%22) +* [Mailing list](https://lists.w3.org/Archives/Public/public-w3process/) +* [open pull requests](https://github.com/w3c/process/pulls), [open issues](https://github.com/w3c/process/issues) +--- + +[Process Milestone](https://github.com/w3c/process/milestone/13) + +--- + +Please add comments to this issue if you have suggestions for agenda items diff --git a/.github/ISSUE_TEMPLATE/bug.md b/.github/ISSUE_TEMPLATE/bug.md new file mode 100644 index 00000000..edab9869 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug.md @@ -0,0 +1,10 @@ +--- +name: Bug report +about: Bugs affecting interpretation of the document +title: '' +labels: 'Type: bug' +assignees: '' + +--- + +## Describe the bug affecting interpretation of the document diff --git a/.github/ISSUE_TEMPLATE/editorial.md b/.github/ISSUE_TEMPLATE/editorial.md new file mode 100644 index 00000000..9e56198e --- /dev/null +++ b/.github/ISSUE_TEMPLATE/editorial.md @@ -0,0 +1,10 @@ +--- +name: Editorial issue +about: Editorial improvements or errors that do not affect interpretation of the document +title: '' +labels: 'Type: Editorial improvements' +assignees: '' + +--- + +## Describe the editorial improvements or errors that do not affect interpretation of the document diff --git a/.github/ISSUE_TEMPLATE/enhancement.md b/.github/ISSUE_TEMPLATE/enhancement.md new file mode 100644 index 00000000..907a325b --- /dev/null +++ b/.github/ISSUE_TEMPLATE/enhancement.md @@ -0,0 +1,10 @@ +--- +name: Enhancement +about: Enhancements that affect current interpretation or that add new functionality +title: '' +labels: 'Type: Enhancement' +assignees: '' + +--- + +## Describe the enhancement that affect current interpretation or that add new functionality diff --git a/.github/ISSUE_TEMPLATE/implementation.md b/.github/ISSUE_TEMPLATE/implementation.md new file mode 100644 index 00000000..997b1473 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/implementation.md @@ -0,0 +1,10 @@ +--- +name: Implementation +about: Not an actual issue about the process, but something to be handled for implementing it +title: '' +labels: 'Type: Implementation' +assignees: '' + +--- + +## Describe the implementation of the process issue diff --git a/.github/ISSUE_TEMPLATE/question.md b/.github/ISSUE_TEMPLATE/question.md new file mode 100644 index 00000000..e3c7562b --- /dev/null +++ b/.github/ISSUE_TEMPLATE/question.md @@ -0,0 +1,10 @@ +--- +name: Question +about: General question related to the W3C Process or its implementation +title: '' +labels: 'Type: Question' +assignees: '' + +--- + +## Describe the general question related to the W3C Process or its implementation diff --git a/.github/workflows/compile.yml b/.github/workflows/compile.yml index d103d5b9..bba0141a 100644 --- a/.github/workflows/compile.yml +++ b/.github/workflows/compile.yml @@ -5,20 +5,20 @@ on: [push, pull_request] jobs: deploy: - runs-on: ubuntu-20.04 + runs-on: ubuntu-24.04 name: Build and deploy to gh-pages - if: ${{ github.repository == 'w3c/w3process' && github.event_name == 'push' }} + if: ${{ github.repository == 'w3c/process' && github.event_name == 'push' }} env: GITHUB_TOKEN: ${{ secrets.W3CGRUNTBOT_TOKEN }} GH_BRANCH: ${{ github.head_ref }} GH_EVENT_NUMBER: ${{ github.event.number }} steps: - name: Checkout the repository - uses: actions/checkout@v2 - - name: Setup python 3.8 - uses: actions/setup-python@v2 + uses: actions/checkout@v4 + - name: Setup python 3.12 + uses: actions/setup-python@v5 with: - python-version: 3.8 + python-version: "3.12" architecture: x64 - name: Install bikeshed run: | @@ -29,16 +29,16 @@ jobs: run: ./deploy.sh shell: bash build: - runs-on: ubuntu-20.04 + runs-on: ubuntu-24.04 name: Check that the Process builds cleanly - if: ${{ github.repository != 'w3c/w3process' || github.event_name == 'pull_request' }} + if: ${{ github.repository != 'w3c/process' || github.event_name == 'pull_request' }} steps: - name: Checkout the repository - uses: actions/checkout@v2 - - name: Setup python 3.8 - uses: actions/setup-python@v2 + uses: actions/checkout@v4 + - name: Setup python 3.12 + uses: actions/setup-python@v5 with: - python-version: 3.8 + python-version: "3.12" architecture: x64 - name: Install bikeshed run: | diff --git a/.gitignore b/.gitignore index b77f6495..b7bfe870 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,3 @@ index.html issues-*.html +!issues-20211102.html diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c4f4a5a5..c74c50b8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,5 @@ # Contributing to the W3C Process Document -Thank-you for offering to contribute to the [W3C Process Document](https://www.w3.org/Consortium/Process/). Here we provide some details on how you can contribute. +Thank-you for offering to contribute to the [W3C Process Document](https://www.w3.org/policies/process/). Here we provide some details on how you can contribute. Changes to the process document tend to fall into a few classes, and how the W3C handles these varies. Simple editorial changes may require little review, but more substantial changes will require a more substantial review and discussions by the W3C community. Please read the material below, and get involved as explained. @@ -11,7 +11,7 @@ For simple editorial changes, please feel free to raise a `pull request` or [rai Some changes may appear simple but may actually be more complicated than they appear. Don't worry - please continue to send your `pull request` or [raise an issue](/../../issues) and we can discuss. ## The W3C Process Community Group -The W3C runs a [Process Community Group](https://www.w3.org/community/w3process/), which is an open group created to manage discussions on developing the [W3C Process Document](https://www.w3.org/Consortium/Process/). Some suggestions for changes to the [W3C Process Document](https://www.w3.org/Consortium/Process/) will need to be made within the [Process Community Group](https://www.w3.org/community/w3process/), please see information below as to whether you need to take your suggestions to the group or can just raise a `pull request` or `issue`. +The W3C runs a [Process Community Group](https://www.w3.org/community/w3process/), which is an open group created to manage discussions on developing the [W3C Process Document](https://www.w3.org/policies/process/). Some suggestions for changes to the [W3C Process Document](https://www.w3.org/policies/process/) will need to be made within the [Process Community Group](https://www.w3.org/community/w3process/), please see information below as to whether you need to take your suggestions to the group or can just raise a `pull request` or `issue`. ## Changes that Affect the Way the W3C Operates but Do Not Change the Policy For changes that affect the way that the W3C operates but do not change policy please do the following: @@ -23,7 +23,7 @@ The best way to ensure your issue gets added to the [Process Community Group](ht Another way to ensure the [Process Community Group](https://www.w3.org/community/w3process/) addressed your issue is to check back on the [issues page](/../../issues) page and ask whether it has been addressed. It is more effective to join the group, but you have this option if you need it. -The [Process Community Group](https://www.w3.org/community/w3process/) will discuss your issue, and decide whether the change can be made or whether the issue needs to be brought to the [Advisory Board](https://www.w3.org/Consortium/Process/#AB) or [Advisory Committee](https://www.w3.org/Consortium/Process/#AC) for discussion; see the next section for more information on this process. +The [Process Community Group](https://www.w3.org/community/w3process/) will discuss your issue, and decide whether the change can be made or whether the issue needs to be brought to the [Advisory Board](https://www.w3.org/policies/process/#AB) or [Advisory Committee](https://www.w3.org/policies/process/#AC) for discussion; see the next section for more information on this process. If the [Process Community Group](https://www.w3.org/community/w3process/) agrees the issue does not change the policy and agrees to make the changes detailed in your issue, you may either raise a `pull request` or wait for the Editor to make the required changes. Note: raising a `pull request` **will** be faster. See more details about `pull requests` below. @@ -32,7 +32,7 @@ For changes that represent a change of policy in the W3C, the idea will need to You can raise the issue with the [Process Community Group](https://www.w3.org/community/w3process/), and you can suggest (or they will notice) that it needs policy discussion and refer it onwards. But you may prefer to initiate that discussion yourself. -Getting something in front of both the [Advisory Board](https://www.w3.org/Consortium/Process/#AB) or [Advisory Committee](https://www.w3.org/Consortium/Process/#AC) can be tricky. If your organisation is a W3C member please let your Advisory Committee member know; they will then be able to email the Advisory Committee or bring the issue up at an Advisory Committee meeting. To reach the [Advisory Board](https://www.w3.org/2002/ab/) you can [raise an issue](/../../issues) on this repo (at least two AB members monitor this repo) or send an email to ab@w3.org. +Getting something in front of both the [Advisory Board](https://www.w3.org/policies/process/#AB) or [Advisory Committee](https://www.w3.org/policies/process/#AC) can be tricky. If your organisation is a W3C member please let your Advisory Committee member know; they will then be able to email the Advisory Committee or bring the issue up at an Advisory Committee meeting. To reach the [Advisory Board](https://www.w3.org/2002/ab/) you can [raise an issue](/../../issues) on this repo (at least two AB members monitor this repo) or send an email to ab@w3.org. Gaining consensus from the [Advisory Board](https://www.w3.org/2002/ab/) or [Advisory Committee](https://www.w3.org/participate/meetings) will take some time. After consensus has been reached you may either raise a `pull request` which include the changes agreed by these committees or wait for the Editor to make the required changes. See more details about `pull requests` below. diff --git a/README.md b/README.md index 72b8cb36..89943d19 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ # W3C Process Document repository -This repository is for the editor's draft of the [World Wide Web Consortium Process Document](https://www.w3.org/Consortium/Process/). +This repository is for the editor's draft of the [World Wide Web Consortium Process Document](https://www.w3.org/policies/process/). The Process document is updated most years by the W3C. Discussion happens in the context of the W3C Process Community Group @@ -10,18 +10,16 @@ Discussion happens in the context of the W3C Process Community Group ---- ## Branches under development -[main](https://github.com/w3c/w3process/tree/main) branch: -[Preview](https://www.w3.org/Consortium/Process/Drafts/) - -[director-free](https://github.com/w3c/w3process/tree/director-free) branch: -[Preview](https://www.w3.org/Consortium/Process/Drafts/director-free/) / -[Diff](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FConsortium%2FProcess%2FDrafts%2F&doc2=https%3A%2F%2Fwww.w3.org%2FConsortium%2FProcess%2FDrafts%2Fdirector-free) +* [main](https://github.com/w3c/process/tree/main) branch (current draft of the CG): +[Preview](https://www.w3.org/policies/process/drafts/) +* [ab-tag-discipline](https://github.com/w3c/process/tree/ab-tag-discipline) branch, where potential procedures for removal and recall of AB or TAG members are being worked out: [preview](https://www.w3.org/policies/process/drafts/ab-tag-discipline/) ---- ## Useful searches -[PRs triaged into P2021](https://github.com/w3c/w3process/issues?q=is%3Aopen+-label%3A%22P2021%3A+Priority%22+milestone%3A%22Process+2021%22+) which are not priorities. - +* [Issues and PRs without a milestone](https://github.com/w3c/process/issues?q=is%3Aopen%20no%3Amilestone) +* [Issues and PR included and targetted for the next release](https://github.com/w3c/process/issues?q=is%3Aopen%20milestone%3A%22Process%202024%2F2025%22%20) +* [Issues and PR marked as Agenda+](https://github.com/w3c/process/issues?q=%20label%3AAgenda%2B%20) ---- ## Bikeshed diff --git a/basic-rec-track.svg b/basic-rec-track.svg index 0d14f364..3dde56be 100644 --- a/basic-rec-track.svg +++ b/basic-rec-track.svg @@ -1,19 +1,19 @@ - + Basic W3C Recommendation Track - + First Public Working Draft (FPWD) - Exclusion opportunity - WG decision - Director's approval + WG Decision + + Team Approval - + @@ -23,7 +23,8 @@ Working Draft (WD) - + @@ -32,183 +33,204 @@ Publish a new Working Draft - - WG Decision: review needed, or - No change for 6 months + + WG Decision - + - + Advance to Candidate Recommendation - Director's approval + WG Decision + + Team Approval - + - + - Candidate Recommendation (CR) - Patent Policy exclusion opportunity + Candidate Recommendation Snapshot (CRS) - Patent Policy exclusion opportunity - - - - - Candidate Recommendation Draft (CRD) - - + - + Publish revised Candidate Recommendation Draft - - WG Decision + + WGDecision - - - - - Publish revised Candidate Recommendation Draft - - - WG Decision - - - - - - - - - - Publish revised Candidate Recommendation - - - WG Decision + - Director’s approval - - - - - - + - Publish revised Candidate Recommendation + Publish revised Candidate Recommendation Snapshot - WG Decision - Director’s approval + WG Decision + Team Approval - - - + - - - + + + - Advance to Proposed Recommendation + Advance to Recommendation - Director's approval + WG Decision + + Team Approval + + AC Review - + Return to Working Draft - - WG or Director decision - e.g. for further review + + WG Decision + (or Team Decision with AB+TAG Approval) - + - + - - - Proposed Recommendation (PR) - Advisory Committee review + + + Candidate Recommendation Draft (CRD) - + - + - + - Advance to Recommendation + Publish revised Candidate Recommendation Draft - - Advisory Committee Review - Director's Decision + + WG Decision - - + + - + - Return to Candidate Recommendation + Publish revised Candidate Recommendation Snapshot - AC Review, - Director Decision - e.g. for editorial changes + WG Decision + + Team Approval - + + + + + + + + + + + Recommendation + + + + + + + + + Return to Candidate Recommendation Snapshot + + + WG Decision + (or Team Decision + with AB+TAG + Approval) + + - + Return to Working Draft - - Advisory Committee review and Director's Decision, e.g. for further work and review + + WG Decision + (or Team Decision + with AB+TAG + Approval) - + + + + + + Publish revised Recommendation with editorial changes + + + WG Decision + (editorial) + + + + + + + + + + Publish revised Recommendation with substantive changes + + + WG Decision + + Team Approval + + AC Review + (substantive) + + + + + - - - - Recommendation (Rec) - - - diff --git a/compile.sh b/compile.sh index 4e319144..e2094983 100755 --- a/compile.sh +++ b/compile.sh @@ -7,28 +7,44 @@ set -x set -e # Run bikeshed. If there are errors, exit with a non-zero code -bikeshed --print=plain -f spec - -# Bikeshed the DoCs as well -for i in issues-*.txt; do - if [ -f $i ]; then - bikeshed --print=plain -f issues-list $i - fi -done +# Include a warning in the status for topic branches +if [ $1 ] ; then + bikeshed --print=plain -f spec index.bs index.html \ + --md-status-text="
This is not the latest Editor’s Draft of the W3C Process.\ +

This is the “$1” topic branch; make sure this is indeed the one you’re looking for.\ + If not, the current Editor’s Draft can be found at\ + https://www.w3.org/policies/process/drafts/.
\ + (The Status of this document section may have information about the purpose of this branch.)" \ + --md-ED="https://www.w3.org/policies/process/drafts/$1/" +else + bikeshed --print=plain -f spec +fi -# The out directory should contain everything needed to produce the -# HTML version of the spec. Copy things there if the directory exists. +# Bikeshed the DoCs as well, unless we're on a topic branch +if ! [ $1 ] ; then + for i in issues-*.txt; do + if [ -f $i ]; then + bikeshed --print=plain -f issues-list $i + fi + done +fi -OUT=${1:-out} +# The out/$1 directory needs to contain everything needed +# to publish the HTML version of the spec. +# Copy things there if the directory exists. +# Only copy the actual Process if we're on a topic branch, +# and everything else too (DoCs, snapshots) if we're on the main branch. -if [ -d $OUT ]; then - if [ -d snapshots ]; then - cp -r snapshots $OUT - fi - for i in issues-*.html; do - if [ -f $i ]; then - cp -r $i $OUT - fi - done - cp index.html $OUT +if [ -d out/$1 ]; then + if ! [ $1 ] ; then + if [ -d snapshots ]; then + cp -r snapshots out/$1/ + fi + for i in issues-*.html; do + if [ -f $i ]; then + cp -r $i out/$1/ + fi + done + fi + cp index.html out/$1/ fi diff --git a/deploy.sh b/deploy.sh index 5bb68f62..55b5eb30 100755 --- a/deploy.sh +++ b/deploy.sh @@ -19,9 +19,10 @@ TOPIC_BRANCHES=( "evergreen" "everblue" "section-6-clean-up" - "maintenance-2020", - "p2021-before-reorg", - "p2021") + "maintenance-2020" + "p2021-before-reorg" + "p2021" + "ab-tag-discipline") containsElement () { local e match="$1" @@ -68,7 +69,7 @@ if containsElement "$TRAVIS_BRANCH" "${TOPIC_BRANCHES[@]}" ; then find -maxdepth 1 ! -name . | xargs rm -rf cd ../.. - ./compile.sh "out/$TRAVIS_BRANCH" + ./compile.sh "$TRAVIS_BRANCH" else # Delete all existing contents except .git and topic branches (we will re-create them) for i in "${TOPIC_BRANCHES[@]}"; do diff --git a/index.bs b/index.bs index b1a93dc8..51c4483f 100644 --- a/index.bs +++ b/index.bs @@ -27,50 +27,41 @@ Title: W3C Process Document Group: processcg Status: CG-DRAFT -ED: https://www.w3.org/Consortium/Process/Drafts/ -TR: https://www.w3.org/Consortium/Process/ -Previous Version: https://www.w3.org/2020/Process-20200915/ -Previous Version: https://www.w3.org/2019/Process-20190301/ -Previous Version: https://www.w3.org/2018/Process-20180201/ -Previous Version: https://www.w3.org/2017/Process-20170301/ -Editor: Elika J. Etemad / fantasai, Invited Expert, http://fantasai.inkedblade.net/contact +ED: https://www.w3.org/policies/process/drafts/ +TR: https://www.w3.org/policies/process/ +Previous Version: https://www.w3.org/policies/process/20250818/ +Editor: Elika J. Etemad / fantasai, Apple, https://fantasai.inkedblade.net/contact Editor: Florian Rivoal, Invited Expert, https://florian.rivoal.net/ Former Editor: Natasha Rooney, Invited Expert -Former Editor: Charles McCathie Nevile, Yandex, http://yandex.com +Former Editor: Charles McCathie Nevile, Yandex, https://yandex.com Former Editor: Ian Jacobs, W3C, https://www.w3.org/ Level: none -Repository: w3c/w3process -Shortname: w3process +Repository: w3c/process +Shortname: process Abstract: - The mission of the World Wide Web Consortium (W3C) is to lead the World Wide Web to its full potential - by developing common protocols that promote its evolution and ensure its interoperability. - The W3C Process Document describes the organizational structure of the W3C and processes, + The mission of the World Wide Web Consortium (W3C) + is making the web work, for everyone. + W3C brings together global stakeholders to develop open standards that enable a World Wide Web that connects and empowers humanity. + The W3C Process Document describes the organizational structure of W3C and processes, responsibilities and functions that enable W3C to accomplish its mission. This document does not describe the internal workings of the Team. For more information about the W3C mission and the history of W3C, - please refer to About W3C. + please refer to About W3C. Status Text: This document, - which is based on the 15 September 2020 Process, + which is based on the 18 August 2025 Process, is a work in progress and further changes may occur before completion of this revision cycle. - As detailed in Section 11 Process Changes, + As detailed in Section 11 Process Changes, once the W3C Advisory Board considers it ready for adoption, it will be offered for W3C Advisory Committee Review. -Local Boilerplate: status yes -Issue Tracking: Github (prefered) https://github.com/w3c/w3process/issues/ +Issue Tracking: Github (preferred) https://github.com/w3c/process/issues/ Issue Tracking: Public mailing list https://lists.w3.org/Archives/Public/public-w3process/ Issue Tracking: Member-only mailing list https://lists.w3.org/Archives/Member/process-issues Boilerplate: repository-issue-tracking off - -

-{
-	"PATENT-POLICY-2020": {
-		"href": " https://www.w3.org/Consortium/Patent-Policy-20200915/",
-		"title": "The W3C 2020 Patent Policy"
-	}
-}
+Boilerplate: omit conformance
+Complain About: accidental-2119 yes
+ +Disposition of Comments for the 2023 cycle of the W3C Process + +
+

+

Disposition of Comments for the 2023 cycle of the W3C Process

+

+

Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply. +

+
+ +

+Introduction

+ +

+ This documents the way issues were filed and resolved during the revision cycle of the W3C Process + starting from the publication of the 2 November 2021 version + leading to the proposed 2023 version. + +

+ All issues were tracked in GitHub. + Closed issues and pull requests were given labels to characterize the way they were closed; + see the glossary for details. + +

+Open issues

+ +
+ + 66 issues reported during this cycle or earlier remain open, + but were deferred by the group to be handled during + a subsequent revision of the W3C Process. + +

+ + Live list from GitHub. +

Static copy of this list at the time of writing: +

+
+ +
+ + No issue remains open (unless deferred). + +

+ + Live list from GitHub. + +

+ +

+Issues Resolved

+ +
+ + 125 issues or pull requests were closed as + Closed: Accepted, + Closed: Retracted, + or Closed: Question answered. + +

+ + Live list from GitHub. +

Static copy of this list at the time of writing: +

+
+ +

+Invalid, Duplicate, Out-of-scope

+ +
+ + 20 issues or pull requests were closed as + Closed: Invalid, + Closed: Out of scope, + or Closed: Duplicate, + and tagged as either + Commenter satisfied/accepting + or Commenter Timed Out (Assumed Satisfied). + +

+ + Live list from GitHub. +

Static copy of this list at the time of writing: +

+
+ +
+ + No issues or pull requests were closed as + Closed: Invalid, + Closed: Out of scope, + or Closed: Duplicate, + and tagged as + Commenter Response Pending. + +

+ + Live list from GitHub. + +

+ +
+ + No issues or pull requests were closed as + Closed: Invalid, + Closed: Out of scope, + or Closed: Duplicate, + and tagged as + Commenter Not Satisfied. + +

+ + Live list from GitHub. + +

+ +

+Rejected Issues

+ +
+ + 12 issues or pull requests were closed as + Closed: Rejected + and tagged as either + Commenter satisfied/accepting + or Commenter Timed Out (Assumed Satisfied). + +

+ + Live list from GitHub. +

Static copy of this list at the time of writing: +

+
+ +
+ + 1 issues was closed as + Closed: Rejected + and tagged as + Commenter Response Pending. + +

+ + Live list from GitHub. +

Static copy of this list at the time of writing: +

+
+ +
+ + 2 issues were closed as + Closed: Rejected + and tagged as + Commenter Not Satisfied. + +

+ + Live list from Github. +

+
Number: +
+ Issue 628 + +
Title: +
+ Limit the scope of FO Council deliberations + +
From: +
+ Pierre-Anthony Lemieux + +
Summary: +
+ The FO Council should sustain an FO only if rejecting the FO would necessarily result in a violation of the W3C process. + As it stands, there are no limitations to what folks can file as FO and what the Council will consider. + +
Resolution to close: +
+ RESOLVED: Close 628 no change, flag Commenter Not Satisfied + +
Summary of rationale to close: +
+ W3C normally makes decisions by consensus. + Formal objections happen when we fail to reach consensus + (regardless of why) + but try to move forward anyway. + The Council is there to determine the best way forward + in the face of irreconcilable differences of opinion, + not to adjudicate right vs wrong in terms of rules being followed. + Simple process violations typically result in the team handling them, not FOs. + Focusing the Council solely on process violations would make the Council mostly useless. + +
AB Confirmation: +
+ RESOLUTION: “The AB accepts the resolution of issue #628 knowing it was closed over objection.” +
+
+
Number: +
+ Issue 478 + +
Title: +
+ Appeal process for proposals + +
From: +
+ James Rosewell + +
Summary: +
+ From the opening GitHub comment: +
+ Group chairs [should] make the initial decision should a complaint be received + relating to the scope of a proposal fulfilling the goals of the W3C + as defined in the membership agreement […] + within 7 elapsed days. + […] + Should disagreement remain, + the General Counsel of the W3C [would] be asked to intervene + by at least one member to seek to obtain consensus within 7 elapsed days. + Should consensus still not be possible + a majority vote of the AC […] [should] make the final decision within 7 elapsed days. + In the event of a tie arbitration [should] be used to resolve the matter. +
+ +
Resolution to close: +
+ RESOLVED: #478 is closed + +
Summary of rationale to close: +
+ Full details in GitHub comment, + with the main point being: +
+ “Adding” an appeal process would be redundant with existing appeal processes. + From expressing disagreement when a proposal is initially made, + to registering dissent, + to having FOs processed by the Council, + to having the ability to file an AC Appeal, + there's already a path to express and escalate disagreement, + and no decision is final until these are all exhausted. +
+ +
AB Confirmation: +
+ RESOLUTION: “The AB accepts the resolution of issue #478 as summarized in w3c/w3process#478 (comment)”. +
+
+ +
+ +

+Glossary

+ +

+ All closed issues were given one of the following label: + +

+
Closed: Accepted +
+ A proposition was made or a problem was raised, + and the group accepted the proposition + or some alternative solution that addresses the problem. + +
Closed: Retracted +
+ A proposition was made or a problem was raised, + but he person who had done so eventually changed their mind + or otherwise decided no longer to pursue the question. + +
Closed: Question answered +
+ An issue was open which was more of a request for information + than a problem statement or a suggestion for change, + and the question asked was given an answer. + +
Closed: Duplicate +
+ The issue or pull request is redundant with another one. + +
Closed: Out of scope +
+ The issue is not about the W3C Process. + +
Closed: Invalid +
+ The issue is as stated is inapplicable. + It may for instance raise a problem with a piece of text + which is no longer present in the current version of the Process. + +
Closed: Rejected +
+ The Group decided to close the issue + without making any change to the Process. +
+ +

+ Further, for all issues classified as Closed: Rejected, + Closed: Invalid, + Closed: Out of scope, + or Closed: Duplicate, + the group sought to confirm with the person who raised the issue + if they were willing to accept the conclusions of the group, + which was documented by additional labels: +

+
Commenter satisfied/accepting +
+ The conclusion was confirmed as accepted by the commenter, + even if it may not be their preferred choice. + +
Commenter Timed Out (Assumed Satisfied) +
+ The commenter was explicitly asked whether they were willing to accept the conclusion, + given ample time do answer, + and did not respond. + In the absence of negative feedback, + it is assumed they are OK with the conclusion. + +
Commenter Response Pending +
+ The commenter was explicitly asked whether they were willing to accept the conclusion, + and has not yet responded. + Not enough time has elapsed yet + to draw any conclusion + as to their satisfaction. + +
Commenter Not Satisfied +
+ The commenter has explicitly indicated + that the Group’s conclusion was not acceptable to them. +
diff --git a/retiring-rec.svg b/retiring-rec.svg index 7f79fdd9..a3ebc419 100644 --- a/retiring-rec.svg +++ b/retiring-rec.svg @@ -46,21 +46,21 @@ - - + + Replaced by a new version, AC review - + Superseded Recommendation - + A Superseded Recommendation can become a normal Recommendation with AC review - + - + diff --git a/snapshots/2022-07-27-tac.html b/snapshots/2022-07-27-tac.html new file mode 100644 index 00000000..d6172340 --- /dev/null +++ b/snapshots/2022-07-27-tac.html @@ -0,0 +1,6761 @@ + + + + + W3C Process Document + + + + + + + + + + + + + + + + +
+

+

W3C Process Document

+

Draft Community Group Report,

+
+ More details about this document +
+
+
This version: +
https://www.w3.org/Consortium/Process/Drafts/snapshots/2022-07-27-tac +
Latest published version: +
https://www.w3.org/Consortium/Process/ +
Previous Versions: +
+
+
+
+
+
Feedback: +
Github (preferred) +
Public mailing list +
Member-only mailing list +
Editors: +
Elika J. Etemad / fantasai (Invited Expert) +
Florian Rivoal (Invited Expert) +
Former Editors: +
Natasha Rooney (Invited Expert) +
Charles McCathie Nevile (Yandex) +
Ian Jacobs (W3C) +
+
+
+
+

Copyright © 2022 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

+
+
+
+

Abstract

+

The mission of the World Wide Web Consortium (W3C) is to lead the World Wide Web to its full potential + + by developing common protocols that promote its evolution and ensure its interoperability. + The W3C Process Document describes the organizational structure of the W3C and processes, + responsibilities and functions that enable W3C to accomplish its mission. + This document does not describe the internal workings of the Team.

+

For more information about the W3C mission and the history of W3C, + + please refer to About W3C.

+
+

Status of this document

+
+

W3C, including all existing chartered groups, + follows the most recent operative Process Document announced to the Membership.

+

This document is developed by the Advisory Board’s Process Task Force + working within the W3C Process Community Group (which anyone can join). + This is the 27 July 2022 Draft Community Group Report for the proposed next version of the W3C Process Document.

+

This document, + +which is based on the 2 November 2021 Process, +is a work in progress +and further changes may occur before completion of this revision cycle. +As detailed in Section 11 Process Changes, +once the W3C Advisory Board considers it ready for adoption, +it will be offered for W3C Advisory Committee Review.

+

A history of substantial changes from previous versions of the Process Document is provided.

+
+
+ +
+

Relation of Process Document to Patent Policy

+

W3C Members' attention is called to the fact + that provisions of the Process Document are binding on Members + per the Membership Agreement [MEMBER-AGREEMENT]. + The W3C Patent Policy [PATENT-POLICY] is incorporated by normative reference as a part of the Process Document, + and is thus equally binding.

+

The Patent Policy places additional obligations on Members, Team, and other participants in W3C. + The Process Document does not restate those requirements but includes references to them. + The Process Document and Patent Policy have been designed to allow them to evolve independently.

+

In the Process Document, the term “participant” refers to an individual, not an organization.

+

Conformance and specialized terms

+

The terms must, must not, should, should not, required, + and may are used in accordance with RFC 2119. + The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

+

Some terms have been capitalized in this document (and in other W3C materials) + to indicate that they are entities with special relevance to the W3C Process. + These terms are defined within this document, + and readers are reminded that the ordinary English definitions are insufficient + for the purpose of understanding this document.

+ +
+

1. Introduction

+

W3C work revolves around the standardization of Web technologies. + To accomplish this work, W3C follows processes that promote the development of high-quality standards + based on the consensus of the Membership, Team, and public. + W3C processes promote fairness, responsiveness, and progress: + all facets of the W3C mission. + This document describes the processes W3C follows in pursuit of its mission.

+

The W3C Process promotes the goals of quality and fairness in technical decisions + by encouraging consensus, + soliciting reviews (by both Members and public), + incorporating implementation and interoperability experience, + and requiring Membership-wide approval as part of the technical report development process. Participants in W3C include representatives of its Members and the Team, + as well as Invited Experts who can bring additional expertise or represent additional stakeholders. Team representatives both contribute to the technical work + and help ensure each group’s proper integration with the rest of W3C.

+

W3C’s technical standards, called W3C Recommendations, + are developed by its Working Groups; + W3C also has other types of publications, + all described in § 6 W3C Technical Reports. + W3C has various types of groups; + this document describes the formation and policies + of its chartered Working Groups and Interest Groups, + see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. + W3C also operates Community and Business Groups, + which are separately described in their own process document [BG-CG].

+

In addition, several groups are formally established by the Consortium: + the W3C Advisory Committee, which has a representative from each Member, + and two oversight groups elected by its membership: + the Advisory Board (AB), + which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process; + and the Technical Architecture Group (TAG), + which helps resolve Consortium-wide technical issues.

+

Here is a general overview of how W3C initiates standardization of a Web technology:

+
    +
  1. People generate interest in a particular topic. + For instance, Members express interest by developing proposals in Community Groups + or proposing ideas in Member Submissions. + Also, the Team monitors work inside and outside of W3C for signs of interest, + and helps organize Workshops to bring people together + to discuss topics that interest the W3C community. +
  2. When there is enough interest and an engaged community, + the Team works with the Membership + to draft proposed Interest Group or Working Group charters. + W3C Members review the proposed charters, + and when there is support within W3C for investing resources in the topic of interest, + the W3C approves the group(s), + and they begin their work. +
+

Further sections of this Process Document deal with topics including + liaisons (§ 9 Liaisons), + confidentiality (§ 7 Dissemination Policies), + and formal decisions and appeals (§ 5 Decisions).

+

2. Members and the Team

+

W3C’s mission is to lead the Web to its full potential. + W3C Member organizations provide resources to this end, + and the W3C Team provides the technical leadership + and organization to coordinate the effort.

+

2.1. Members

+

W3C Members are + organizations subscribed according to the Membership Agreement [MEMBER-AGREEMENT]. + They are represented in W3C processes as follows:

+
    +
  1. One representative per Member organization particiaptes + in the Advisory Committee which oversees the work of the W3C. +
  2. Representatives of Member organizations participate + in Working Groups and Interest Groups, + where they author and review technical reports. +
+

W3C membership is open to all entities, + as described in “How to Join W3C” [JOIN]; + (refer to the public list of current W3C Members [MEMBER-LIST]). + The Team must ensure + that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

+

While W3C does not have a class of membership tailored to individuals, + individuals may join W3C. + Restrictions pertaining to related Members apply + when the individual also represents another W3C Member.

+

2.1.1. Rights of Members

+

Each Member organization enjoys the following rights and benefits:

+ +

Furthermore, subject to further restrictions included in the Member Agreement, + representatives of Member organizations participate in W3C as follows:

+ +

The rights and benefits of W3C membership [MEMBER-AGREEMENT] are contingent upon conformance to the processes described in this document. + Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.

+

Additional information for Members is available at the Member Web site [MEMBER-HP].

+

2.1.2. Member Consortia and Related Members

+
2.1.2.1. Membership Consortia
+

A “Member Consortium” means a consortium, + user society, + or association of two or more individuals, + companies, + organizations or governments, + or any combination of these entities + which has the purpose of participating in a common activity + or pooling resources to achieve a common goal other than participation in, + or achieving certain goals in, + W3C. + A joint-stock corporation or similar entity is not a Member Consortium merely because it has shareholders or stockholders. + If it is not clear whether a prospective Member qualifies as a Member Consortium, + the CEO may reasonably make the determination. + For a Member Consortium, the rights and privileges of W3C Membership + described in the W3C Process Document extend to the Member Consortium's paid staff + and Advisory Committee representative.

+

Member Consortia may also designate + up to four (or more at the Team’s discretion) individuals + who, though not employed by the organization, may exercise the rights of Member representatives.

+

For Member Consortia that have individual people as members, + these individuals must disclose their employment affiliation + when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For Member Consortia that have organizations as Members, + all such designated representatives must be an official representative of the Member organization + (e.g. a Committee or Task Force Chairperson) + and must disclose their employment affiliation when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For all representatives of a Member Consortium, + IPR commitments are made on behalf of the Member Consortium, + unless a further IPR commitment is made by the individuals' employers.

+
2.1.2.2. Related Members
+

In the interest of ensuring the integrity of the consensus process, + Member involvement in some of the processes in this document is affected by related Member status. + As used herein, two Members are related if:

+
    +
  1. Either Member is a subsidiary of the other, or +
  2. Both Members are subsidiaries of a common entity, or +
  3. The Members have an employment contract or consulting contract that affects W3C participation. +
+

A subsidiary is an organization of which effective control and/or majority ownership rests with another, + single organization.

+

Related Members must disclose these relationships + according to the mechanisms described in the New Member Orientation [INTRO].

+

2.2. The W3C Team

+

The Team consists of + the Director, CEO, + W3C paid staff, + unpaid interns, + and W3C Fellows. W3C Fellows are Member employees working as part of the Team; + see the W3C Fellows Program [FELLOWS]. + The Team provides technical leadership about Web technologies, + organizes and manages W3C activities to reach goals + within practical constraints (such as resources available), + and communicates with the Members and the public + about the Web and W3C technologies.

+

The Director and CEO may delegate responsibility + (generally to other individuals in the Team) + for any of their roles described in this document, + except participation in the TAG.

+ Team Decisions derive from the Director and CEO's authority, + even when they are carried out by other members of the Team. +

+

The Director is the lead technical architect at W3C, + whose responsibilities are identified throughout this document in relevant places. + Some key ones include: + assessing consensus within W3C for architectural choices, + publication of technical reports, + and chartering new Groups; + appointing group Chairs, + adjudicating as "tie-breaker" for Group decision appeals, + and deciding on the outcome of formal objections; + the Director is generally Chair of the TAG.

+

Team administrative information such as Team salaries, + detailed budgeting, + and other business decisions + are Team-only, + subject to oversight by the Host institutions.

+

Note: W3C is not currently incorporated. + For legal contracts, W3C is represented by four “Host” institutions: + Beihang University, + the European Research Consortium for Informatics and Mathematics (ERCIM), + Keio University, + and the Massachusetts Institute of Technology (MIT). + Within W3C, the Host institutions are governed by hosting agreements; + the Hosts themselves are not W3C Members.

+

3. Groups and Participation

+

For the purposes of this Process, a W3C Group is one of W3C’s Working Groups, Interest Groups, Advisory Committee, Advisory Board, + or TAG, + and a participant is a member of such a group.

+

3.1. Policies for Participation in W3C Groups

+

3.1.1. Individual Participation Criteria

+
3.1.1.1. Expectations and Discipline
+

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

+
    +
  1. Technical competence in one’s role; +
  2. The ability to act fairly; +
  3. Social competence in one’s role. +
+

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities + are responsible for assessing and attesting to the qualities of those nominees.

+

Participants in any W3C activity must abide + by the terms and spirit of the W3C Code of Ethics and Professional Conduct [CEPC] and the participation requirements described in + “Disclosure” + in the W3C Patent Policy [PATENT-POLICY].

+

The CEO may take disciplinary action, + including suspending or removing for cause + a participant in any group (including the AB and TAG) + if serious and/or repeated violations, + such as failure to meet the requirements on individual behavior of + (a) this process + and in particular the CEPC, or + (b) the membership agreement, or + (c) applicable laws, + occur. + Refer to the Guidelines to suspend or remove participants from groups.

+
3.1.1.2. Conflict of Interest Policy
+

Individuals participating materially in W3C work must disclose significant relationships + when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. + These disclosures must be kept up-to-date + as the individual’s affiliations change and W3C membership evolves + (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). + Each section in this document that describes a W3C group + provides more detail about the disclosure mechanisms for that group.

+

The ability of an individual to fulfill a role within a group + without risking a conflict of interest depends on the individual’s affiliations. + When these affiliations change, + the individual’s assignment to the role must be evaluated. + The role may be reassigned according to the appropriate process. + For instance, + the Team may appoint a new group Chair when the current Chair changes affiliations + (e.g., if there is a risk of conflict of interest, + or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

+

The following are some scenarios where disclosure is appropriate:

+
    +
  • Paid consulting for an organization whose activity is relevant to W3C, + or any consulting compensated with equity + (shares of stock, stock options, or other forms of corporate equity). +
  • A decision-making role/responsibility + (such as participating on the Board) in other organizations relevant to W3C. +
  • A position on a publicly visible advisory body, + even if no decision-making authority is involved. +
+

Individuals seeking assistance on these matters should contact the Team.

+

Team members are subject to the W3C Team conflict of interest policy [CONFLICT-POLICY].

+
3.1.1.3. Individuals Representing a Member Organization
+

Generally, individuals representing a Member in an official capacity within W3C + are employees of the Member organization. + However, an Advisory Committee representative may designate a non-employee + to represent the Member. + Non-employee Member representatives must disclose + relevant affiliations to the Team and to any group in which the individual participates.

+

In exceptional circumstances + (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), + the CEO may decline + to allow an individual designated by an Advisory Committee representative to participate in a group.

+

A group charter may limit + the number of individuals representing a W3C Member + (or group of related Members).

+

3.1.2. Meetings

+

The requirements in this section apply to the official meetings of any W3C group.

+

W3C distinguishes two types of meetings:

+
    +
  1. A face-to-face meeting is one + where most of the attendees are expected to participate in the same physical location. +
  2. A distributed meeting is one + where most of the attendees are expected to participate from remote locations + (e.g., by telephone, video conferencing, or IRC). +
+

A Chair may invite an individual with a particular expertise + to attend a meeting on an exceptional basis. + This person is a meeting guest, + not a group participant. + Meeting guests do not have voting rights. + It is the responsibility of the Chair to ensure + that all meeting guests respect the chartered level of confidentiality and other group requirements.

+
3.1.2.1. Meeting Scheduling and Announcements
+

Meeting announcements should be sent to all appropriate group mailing lists, + i.e. those most relevant to the anticipated meeting participants.

+

The following table lists recommendations for organizing a meeting:

+ + + + + + + + + +
+ Face-to-face meetings + Distributed meetings +
Meeting announcement (before) + eight weeks* + one week* +
Agenda available (before) + two weeks + 24 hours (or longer if a meeting is scheduled after a weekend or holiday) +
Participation confirmed (before) + three days + 24 hours +
Action items available (after) + three days + 24 hours +
Minutes available (after) + two weeks + 48 hours +
+

* To allow proper planning (e.g., travel arrangements), + the Chair is responsible for giving sufficient advance notice + about the date and location of a meeting. + Shorter notice for a meeting is allowed + provided that there are no objections from group participants.

+
3.1.2.2. Meeting Minutes
+

Groups should take and retain minutes of their meetings, + and must record + any official group decisions made during the meeting discussions. + Details of the discussion leading to such decisions are not required, + provided that the rationale for the group decision is nonetheless clear.

+
3.1.2.3. Meeting Recordings and Transcripts
+

No-one may take an audio or video recording of a meeting, + or retain an automated transcript, + unless the intent is announced at the start of the meeting, + and no-one participating in the recorded portion of the meeting withholds consent. + If consent is withheld by anyone, recording/retention must not occur. + The announcement must cover: + (a) who will have access to the recording or transcript and + (b) the purpose/use of it and + (c) how it will be retained (e.g. privately, in a cloud service) and for how long.

+

3.1.3. Tooling for Discussions and Publications

+

For W3C Groups operating under this Process, + a core operating principle is to allow access across disabilities, + across country borders, + and across time. + Thus in order to allow all would-be participants to effectively participate, + to allow future participants and observers to understand the rationale and origins of current decisions, + and to guarantee long-lived access to its publications, + W3C requires that:

+
    +
  • All reports, publications, or other deliverables + produced by the group for public consumption + (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, + and backed up by W3C systems + such that if the underlying service is discontinued, + W3C can continue to serve such content without breaking incoming links + or other key functionality. +
  • All reports, publications, or other deliverables + produced by the group for public consumption should follow best practices for internationalization + and for accessibility to people with disabilities. + Network access to W3C-controlled domains may be assumed. +
  • + Official meeting minutes and other records of decisions made must be archived by W3C for future reference; + and other persistent text-based discussions + sponsored by the group, + pertaining to their work + and intended to be referenceable by all group members should be. + This includes discussions conducted over email lists + or in issue-tracking services + or any equivalent fora. + Materials referenced from discussions + and necessary to understand them + should be available at a stable URL, + at a level of confidentiality no stricter than the discussion minutes. +

    Note: The lack, or loss, of such archives does not by itself + invalidate an otherwise-valid decision.

    +
  • + Any tooling used by the group + for producing its documentation and deliverables + or for official group discussions should be usable + (without additional cost) + by all who wish to participate, + including people with disabilities, + to allow their effective participation. +

    Note: If a new participant joins who cannot use the tool, + this can require the Working Group to change its tooling + or operate some workaround.

    +
  • All tools and archives used by the group + for its discussions and recordkeeping should be documented + such that new participants and observers + can easily find the group’s tools and records. +
+

The Team is responsible for ensuring adherence to these rules + and for bringing any group not in compliance into compliance.

+

3.1.4. Resignation from a Group

+

A W3C Member or Invited Expert may resign from a group. + On written notification from an Advisory Committee representative + or Invited Expert + to the team, + the Member and their representatives + or the Invited Expert + will be deemed to have resigned from the relevant group. + The team must record the notification. + See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

+

3.2. The Advisory Committee (AC)

+

3.2.1. Role of the Advisory Committee

+

The Advisory Committee represents + the Members of the W3C at large. + It is responsible for:

+ +

Advisory Committee representatives may initiate + an Advisory Committee Appeal of a W3C decision or Director's decision.

+

See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

+

3.2.2. Participation in the Advisory Committee

+

The Advisory Committee is composed of one representative from each Member organization + (refer to the Member-only list + of current Advisory Committee representatives. [CURRENT-AC])

+

When an organization joins W3C + (see “How to Join W3C” [JOIN]), + it must name its Advisory Committee representative as part of the Membership Agreement. + The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, + provides information about Advisory Committee Meetings, + explains how to name a new Advisory Committee representative, + and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.

+

The AC representative may delegate any of their rights and responsibilities + to an alternate (except the ability to designate an alternate).

+

3.2.3. Advisory Committee Mailing Lists

+

The Team must provide two mailing lists for use by the Advisory Committee:

+
    +
  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. + This list is read-only for Advisory Committee representatives. +
  2. One for discussion among Advisory Committee representatives. + Though this list is primarily for Advisory Committee representatives, + the Team must monitor discussion + and should participate in discussion when appropriate. + Ongoing detailed discussions should be moved to other appropriate lists + (new or existing, such as a mailing list created for a Workshop). +
+

An Advisory Committee representative may request + that additional individuals from their organization be subscribed to these lists. + Failure to contain distribution internally may result in suspension of additional email addresses, + at the discretion of the Team.

+

3.2.4. Advisory Committee Meetings

+

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. + The Team appoints the Chair of these meetings (generally the CEO). + At each Advisory Committee meeting, + the Team should provide an update to the Advisory Committee about:

+
+
Resources +
+
    +
  • The number of W3C Members at each level. +
  • An overview of the financial status of W3C. +
+
Allocations +
+
    +
  • The allocation of the annual budget, including size of the Team and their approximate deployment. +
  • A list of all activities (including but not limited to Working and Interest Groups) + and brief status statement about each, + in particular those started or terminated since the previous Advisory Committee meeting. +
  • The allocation of resources to pursuing liaisons with other organizations. +
+
+

Each Member organization should send one representative to each Advisory Committee Meeting. + In exceptional circumstances + (e.g., during a period of transition between representatives from an organization), + the meeting Chair may allow a Member organization to send two representatives to a meeting.

+

The Team must announce the date and location of each Advisory Committee meeting + no later than at the end of the previous meeting; one year’s notice is preferred. + The Team must announce the region of each Advisory Committee meeting + at least one year in advance.

+

More information about Advisory Committee meetings [AC-MEETING] is available at the Member Web site.

+

3.3. Elected Groups: The AB and the TAG

+

The W3C Process defines two types of elected groups: + the Advisory Board (AB) and + the Technical Architecture Group (TAG), + both elected by the Advisory Committee.

+

3.3.1. Advisory Board (AB)

+
3.3.1.1. Role of the Advisory Board
+

The Advisory Board provides ongoing guidance to the Team + on issues of strategy, + management, + legal matters, + process, + and conflict resolution. + The Advisory Board also serves the Members + by tracking issues raised between Advisory Committee meetings, + soliciting Member comments on such issues, + and proposing actions to resolve these issues. + The Advisory Board manages the evolution of the Process Document. + The Advisory Board hears a Submission Appeal when a Member Submission is rejected + for reasons unrelated to Web architecture; + see also the TAG.

+

The Advisory Board is not a board of directors + and has no decision-making authority within W3C; + its role is strictly advisory.

+

Details about the Advisory Board + (e.g., the list of Advisory Board participants, + mailing list information, and summaries of Advisory Board meetings) + are available at the Advisory Board home page [AB-HP].

+
3.3.1.2. Composition of the Advisory Board
+

The Advisory Board consists of nine to eleven elected participants and one Chair + (who may be one of the elected participants). + With the input of the AB, + the Team appoints the Chair, + who should choose a co-chair among the elected participants. + The Chair(s) are subject to ratification by secret ballot + by two thirds of the AB upon appointment and at the start of each AB term. + The team also appoints a Team Contact, + as described in § 3.4.1 Requirements for All Chartered Groups. + The CEO and Team Contact have a standing invitation + to all regular Advisory Board sessions.

+

The nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

+

The terms of elected Advisory Board participants are for two years. + Terms are staggered so that each year, + either five or six terms expire. + If an individual is elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular Advisory Board terms begin on 1 July and end on 30 June.

+

+
3.3.1.3. Communications of the Advisory Board
+

The Team must make available a mailing list, + confidential to the Advisory Board and Team, + for the Advisory Board to use for its communication.

+

The Advisory Board should send a summary of each of its meetings + to the Advisory Committee and other group Chairs. + The Advisory Board should also report on its activities + at each Advisory Committee meeting.

+

3.3.2. Technical Architecture Group (TAG)

+
3.3.2.1. Role of the Technical Architecture Group
+

The mission of the TAG is stewardship of the Web architecture. + There are three aspects to this mission:

+
    +
  1. to document and build consensus around principles of Web architecture + and to interpret and clarify these principles when necessary; +
  2. to resolve issues involving general Web architecture brought to the TAG; +
  3. to help coordinate cross-technology architecture developments inside and outside W3C. +
+

The TAG hears a Submission Appeal when a Member Submission is rejected for reasons related to Web architecture; + see also the Advisory Board.

+

The TAG's scope is limited to technical issues about Web architecture. + The TAG should not consider + administrative, + process, + or organizational policy issues of W3C, + which are generally addressed by + the W3C Advisory Committee, + Advisory Board, + and Team. + Please refer to the TAG charter [TAG-CHARTER] for more information about the background and scope of the TAG, + and the expected qualifications of TAG participants.

+

When the TAG votes to resolve an issue, + each TAG participant + (whether appointed, elected, or the Chair) + has one vote; + see also the section on voting in the TAG charter [TAG-CHARTER] and the general section on votes in this Process Document.

+

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) + are available at the TAG home page [TAG-HP].

+
3.3.2.2. Composition of the Technical Architecture Group
+

The TAG consists of:

+ +

Participants in the TAG choose by consensus their Chair or co-Chairs; + in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG. + The Chair or co-Chairs must be selected from the participants of the TAG. + The Team also appoints a Team Contact [TEAM-CONTACT] for the TAG, + as described in § 3.4.1 Requirements for All Chartered Groups.

+

The terms of TAG participants are for two years. + Terms are staggered so that each year three elected terms, + and either one or two appointed terms expire. + If an individual is appointed or elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular TAG terms begin on 1 February and end on 31 January.

+
3.3.2.3. Communications of the Technical Architecture Group
+

The Team must make available two mailing lists for the TAG:

+
    +
  • a public discussion (not just input) list for issues of Web architecture. + The TAG will conduct its public business on this list. +
  • a Member-only list for discussions within the TAG + and for requests to the TAG that, + for whatever reason, cannot be made on the public list. +
+

The TAG may also request the creation of additional topic-specific, public mailing lists. + For some TAG discussions (e.g., a Submission Appeal), + the TAG may use a list that will be Member-only.

+

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. + The TAG should also report on its activities at each Advisory Committee meeting.

+

3.3.3. Participation in Elected Groups

+
3.3.3.1. Expectations for Elected Groups Participants
+

Advisory Board and TAG participants have a special role within W3C: + they are elected by the Membership and appointed + with the expectation that they will use their best judgment + to find the best solutions for the Web, + not just for any particular network, + technology, + vendor, + or user. + Advisory Board and TAG participants are expected to participate regularly and fully. + Advisory Board and TAG participants should attend Advisory Committee meetings.

+

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, + to serve the needs of the W3C membership as a whole, + and the Web community. + Whether they are Member representatives or Invited Experts, + their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

+

An individual participates on the Advisory Board or TAG + from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). + Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, + their participation does carry the responsibilities associated with Member representation, + Invited Expert status, + or Team representation + (as described in the section on the AB/TAG nomination and election process).

+

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, + and a participant’s seat must not be delegated to any other person.

+
3.3.3.2. Elected Groups Participation Constraints
+

Given the few seats available on the Advisory Board and the TAG, + and in order to ensure that the diversity of W3C Members is represented:

+ +
3.3.3.3. Advisory Board and Technical Architecture Group Elections
+

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, + using a Single Transferable Vote system. + An election begins when the Team sends a Call for Nominations to the Advisory Committee. + Any Call for Nominations specifies the minimum and maximum number of available seats, + the deadline for nominations, + details about the specific vote tabulation system selected by the Team for the election, + and operational information such as how to nominate a candidate. + The Team may modify the tabulation system after the Call for Nominations + but must stabilize it no later than the Call for Votes. + The TAG Appointment Committee must announce appointments + after the results of the election are known, + and before the start of the term, + as described in § 3.3.3.4 Technical Architecture Group Appointments.

+

In the case of regularly scheduled elections of the TAG, + the minimum and maximum number of available seats are the same: + the 3 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

+

In the case of regularly scheduled elections of the AB, + the minimum and maximum number of available seats differ: + The maximum number is the 5 or 6 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; + the minimum number is such that when added to the occupied seats from the prior year, + the minimum size of the AB (9) is reached.

+

Each Member (or group of related Members) may nominate one individual. + A nomination must be made with the consent of the nominee. + In order for an individual to be nominated as a Member representative, + the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination + the (same) information required for a Member representative in a Working Group. + In order for an individual to be nominated as an Invited Expert, + the individual must provide + the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. + In order for an individual to be nominated as a Team representative, + the nominating Advisory Committee representative must first secure approval from Team management. + A nominee is not required to be an employee of a Member organization, + and may be a W3C Fellow. + The nomination form must ask for the nominee’s primary affiliation, + and this will be reported on the ballot. + For most nominees, + the primary affiliation is their employer and will match their affiliation in the W3C database. + For contractors and invited experts, + this will normally be their contracting company + or their invited expert status; + in some cases + (e.g. where a consultant is consulting for only one organization) + this may be the organization for whom the nominee is consulting. + A change of affiliation is defined + such that this field would carry a different answer + if the nominee were to be re-nominated + (therefore, + terminating employment, + or accepting new employment, + are changes of affiliation). + (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) + Each nomination should include + a few informative paragraphs about the nominee.

+

If, after the deadline for nominations, the number of nominees is:

+
    +
  • Greater than or equal to the minimum number of available seats + and less than or equal to the maximum number of available seats, + those nominees are thereby elected. + This situation constitutes a tie for the purpose of assigning incomplete terms. + Furthermore, if the number is less than the maximum number of available seats, + the longest terms are filled first. +
  • Less than the minimum number of available seats, + Calls for Nominations are issued until a sufficient number of people have been nominated. + Those already nominated do not need to be renominated after a renewed call. +
  • Greater than the maximum number of available seats, + the Team issues a Call for Votes + that includes the names of all candidates, + the (maximum) number of available seats, + the deadline for votes, + details about the vote tabulation system selected by the Team for the election, + and operational information. +
+

When there is a vote, + each Member + (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. + Once the deadline for votes has passed, + the Team announces the results to the Advisory Committee. + In case of a tie the verifiable random selection procedure described below + will be used to fill the available seats.

+

The shortest incomplete term is assigned to the elected candidate ranked lowest by the tabulation of votes, + the next shortest term to the next-lowest ranked elected candidate, + and so on. + In the case of a tie among those eligible for a incomplete term, + the verifiable random selection procedure described below + will be used to assign the incomplete term.

+

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

+
3.3.3.4. Technical Architecture Group Appointments
+

The TAG Appointment Committee is responsible for appointing + 3 of the participants to the Technical Architecture Group. + This mechanism complements the election process. + The TAG Appointment Committee should use its appointments to suppport + a diverse and well-balanced TAG.

+

For regularly scheduled elections, + a TAG Appointment Committee is formed as soon as possible after the Call for Nominations for the relevant TAG election has closed, + and no later than the end of the voting period. + When formed to fill vacated seats out of a regularly scheduled election, + a TAG Appointment Committee is formed as soon as possible after the seat is vacated, + unless a regular Call for Nominations is scheduled within 2 months.

+

The TAG Appointment Committee is composed of the following seats, + selected in order:

+
    +
  1. 1 member of the Team, chosen by the CEO, as Team Contact. + The Team Contact is non-voting, + except that they can break ties. +
  2. 3 participants of the current TAG, randomly selected from those who are not running for election +
  3. 7 Chairs of Working Groups, randomly selected from individuals who are or have been Chair of a Working Group for at least 6 of the preceeding 12 months, + excluding individuals running in the election, + already selected (see above), + or having the same affiliation as someone already selected. +
+

Individuals selected to serve on the TAG Appointment Committee may decline, + in which case the random selection procedure for that seat + is repeated until it is filled + or the pool of eligible electors is exhausted. + If willing participants cannot be found to fill the designated number of seats in each category, + a TAG Appointment Committee is formed despite vacant seats.

+

The chair of the TAG Appointment Committee is chosen by consensus of the participants. + If no consensus can be reached within one week of the committee being formed, + the chair is instead designated by the Team.

+

Participants in the TAG Appointment Committee should recruit and nominate + candidates for appointment to the TAG. + The Team must make available to + the W3C community at large + a means to nominate additional candidates for consideration. + Nominations should include + relevant information in support of the candidate. + These nominations are confidential to the TAG Appointment Committee.

+

The TAG Appointment Committee appoints by consensus the number of individuals necessary to fill the number of vacant seats, + from the eligible nominees. + The constraints for appointment to the TAG are + the same as for elected participants + (see § 3.3.3.2 Elected Groups Participation Constraints and § 3.3.3.3 Advisory Board and Technical Architecture Group Elections), + except that participants of the TAG Appointment Committee cannot appoint themselves. + If consensus cannot be reached before the deadline, + the Chair should call for a vote. + The voting method is at the Chair’s discretion, + but must ensure that + all participants in the TAG Appointment Committee are given an equal say, + and that all eligible nominees are considered.

+

For regularly scheduled elections, + the TAG Appointment Committee must announce its conclusions + after the results of the election are known, + but no later than the start of the Term. + When formed to fill vacated seats outside of a regularly scheduled election, + it must announce its conclusions + no later than the Call for Nominations of the next scheduled election.

+

To ensure that seats on the TAG do not stay vacant, + if the TAG Appointment Committee fails to decide on the required number of appointees + before the deadline, + the Team appoints the missing number. + Seats thus appointed by the Team are vacated at the next regularly scheduled election.

+
3.3.3.5. Verifiable Random Selection Procedure
+

When it is necessary to use a verifiable random selection process + (e.g., in an AB or TAG election, + to “draw straws” in case of a tie + or to fill a incomplete term), + W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. + The procedure orders an input list of names + (listed in alphabetical order by family name unless otherwise specified) + into a “result order”.

+

W3C applies this procedure as follows:

+

+
    +
  1. When N people have tied for M (less than N) seats. + In this case, only the names of the N individuals who tied + are provided as input to the procedure. + The M seats are assigned in result order. +
  2. After all elected individuals have been identified, + when N people are eligible for M (less than N) incomplete terms. + In this case, only the names of those N individuals are provided as input to the procedure. + The incomplete terms are assigned in result order. +
+
3.3.3.6. Elected Groups Vacated Seats
+

An Advisory Board or TAG participant’s seat is vacated when:

+ +

If a participant changes affiliation, + but the participation constraints are met, + that participant’s seat becomes vacant at the next regularly scheduled election for that group.

+

Vacated seats are filled according to this schedule:

+
    +
  • When an appointed TAG seat is vacated, + a TAG Appointment Committee appoints a replacement. +
  • + When an elected seat on either the AB or TAG is vacated, + the seat is filled at the next regularly scheduled election for the group + unless the group Chair requests that W3C hold an election before then + (for instance, due to the group’s workload). +
      +
    • The group Chair should not request such an election + if the next regularly scheduled election is fewer than three months away. +
    • The group Chair may request an election, + and the election may begin, as soon as a current member gives notice of a resignation, + including a resignation effective as of a given date in the future. +
    +

    When such an election is held, + the minimum number of available seats is such that + when added to the number of continuing participants, + the minimum total number of elected seats is met + (6 for the TAG, 9 for the AB); + and the maximum number corresponds to all unoccupied seats. + Except for the number of available seats and the length of the terms, + the usual rules for Advisory Board and Technical Architecture Group Elections apply.

    +
+

3.4. Chartered Groups: Working Groups and Interest Groups

+

This document defines two types of chartered groups:

+
+
Working Groups. +
+ Working Groups typically produce deliverables + (e.g., Recommendation Track technical reports, + software, + test suites, + and reviews of the deliverables of other groups) + as defined in their charter. +

Working Groups have additional participation requirements + described in the W3C Patent Policy [PATENT-POLICY], + see particularly the “Licensing Obligations of Working Group Participants” + and the patent claim exclusion process + in “Exclusion From W3C RF Licensing Requirements”.

+
Interest Groups. +
+ The primary goal of an Interest Group + is to bring together people who wish to evaluate potential Web technologies and policies. + An Interest Group is a forum for the exchange of ideas. +

Interest Groups do not publish Recommendation Track technical reports; + but can publish technical reports on the Note Track.

+
+

3.4.1. Requirements for All Chartered Groups

+

Each group must have a charter. + Requirements for the charter depend on the group type. + All group charters must be public + (even if other proceedings of the group are Member-only).

+

Each group must have a Chair (or co-Chairs) + to coordinate the group’s tasks. + The Team appoints (and re-appoints) Chairs for all groups. + The Chair is a Member representative, + a Team representative, + or an Invited Expert, + (invited by the Team). + The requirements of this document that apply to those types of participants apply to Chairs as well. + The role of the Chair [CHAIR] is described + in the Art of Consensus [GUIDE].

+

Each group must have a Team Contact, + who acts as the interface between the Chair, + group participants, + and the rest of the Team. + The role of the Team Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE]. + The Chair and the Team Contact of a group should not be the same individual.

+

Each group must have an archived mailing list + for formal group communication + (e.g., for meeting announcements and minutes, + documentation of decisions, + and Formal Objections to decisions). + It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists. + Refer to the list of group mailing lists [GROUP-MAIL].

+

A Chair may form task forces + (composed of group participants) + to carry out assignments for the group. + The scope of these assignments must not exceed the scope of the group’s charter. + A group should document the process it uses + to create task forces + (e.g., each task force might have an informal "charter"). + Task forces do not publish technical reports; + the Working Group may choose to publish their results as part of a technical report.

+

3.4.2. Participation in Chartered Groups

+

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, + and Team representatives (including the Team Contact).

+

There are four types of individual participants in an Interest Group: + the same three types as for Working Groups plus, + for an Interest Group where the only participation requirement is mailing list subscription, public participants.

+

Except where noted in this document or in a group charter, + all participants share the same rights and responsibilities in a group; + see also the individual participation criteria.

+

A participant may represent more than one organization + in a Working Group or Interest Group. + Those organizations must all be members of the group.

+

An individual may become + a Working or Interest Group participant + at any time during the group’s existence. + See also relevant requirements in + “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY].

+

On an exceptional basis, + a Working or Interest Group participant may designate + a substitute to attend a meeting and should inform the Chair. + The substitute may act on behalf of the participant, + including for votes. + For the substitute to vote, + the participant must inform the Chair in writing in advance. + As a courtesy to the group, + if the substitute is not well-versed in the group’s discussions, + the regular participant should authorize another participant to act as proxy for votes.

+

To allow rapid progress, + Working Groups are intended to be small + (typically fewer than 15 people) + and composed of experts in the area defined by the charter. + In principle, + Interest Groups have no limit on the number of participants. + When a Working Group grows too large to be effective, + W3C may split it into an Interest Group + (a discussion forum) + and a much smaller Working Group + (a core group of highly dedicated participants).

+

3.4.3. Types of Participants in Chartered Groups

+
3.4.3.1. Member Representative in a Working Group
+

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Advisory Committee representative of the Member in question + has designated the individual as a Working Group participant, and +
  • the individual qualifies for Member representation. +
+

To designate an individual as a Member representative in a Working Group, + an Advisory Committee representative must provide the Chair and Team Contact with all of the following information, + in addition to any other information required by the Call for Participation and charter + (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

+
    +
  1. The name of the W3C Member the individual represents + and whether the individual is an employee of that Member organization; +
  2. A statement that the individual accepts the participation terms + set forth in the charter + (with an indication of charter date or version); +
  3. A statement that the Member will provide the necessary financial support for participation + (e.g., for travel, telephone calls, and conferences). +
+

A Member participates in a Working Group from the moment the first Member representative joins the group + until either of the following occurs:

+
    +
  • the group closes, or +
  • the Member resigns from the Working Group; + this is done through the Member’s Advisory Committee representative. +
+
3.4.3.2. Member Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

+ +

To designate an individual as a Member representative in an Interest Group, + the Advisory Committee representative must follow the instructions + in the Call for Participation and charter.

+

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

+
3.4.3.3. Invited Expert in a Working Group
+

The Chair may invite an individual with a particular expertise + to participate in a Working Group. + This individual may represent an organization in the group + (e.g., if acting as a liaison with another organization).

+

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Chair has designated the individual as a group participant, +
  • the Team Contact has agreed with the Chair’s choice, and +
  • the individual has provided the information required of an Invited Expert to the Chair and Team Contact. +
+

To designate an individual as an Invited Expert in a Working Group, + the Chair must inform the Team Contact + and provide rationale for the choice. + When the Chair and the Team Contact disagree about a designation, + the CEO determines + whether the individual will be invited to participate in the Working Group.

+

To participate in a Working Group as an Invited Expert, + an individual must:

+
    +
  • identify the organization, if any, the individual represents as a participant in this group, +
  • agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT], +
  • accept the participation terms set forth in the charter, + including the participation requirements of + the W3C Patent Policy [PATENT-POLICY], + especially in “Note on Licensing Commitments for Invited Experts” + and in “Disclosure”, + indicating a specific charter date or version, +
  • disclose whether the individual is an employee of a W3C Member; + see the conflict of interest policy, +
  • provide a statement of who will provide the necessary financial support + for the individual’s participation + (e.g., for travel, telephone calls, and conferences), and +
  • if the individual’s employer (including a self-employed individual) + or the organization the individual represents + is not a W3C Member, + indicate whether that organization intends to join W3C. + If the organization does not intend to join W3C, + indicate reasons the individual is aware of for this choice. +
+

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. + The Chair must not use Invited Expert status + to circumvent participation limits imposed by the charter.

+

An Invited Expert participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • the Chair or CEO withdraws the invitation to participate, or +
  • the individual resigns. +
+
3.4.3.4. Invited Expert in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

+
3.4.3.5. Team Representative in a Working Group
+

An individual is a Team representative in a Working Group when so designated by W3C management. + Team representatives both contribute to the technical work + and help ensure the group’s proper integration with the rest of W3C.

+

A Team representative participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • W3C management changes Team representation by sending email to the Chair, + copying the group mailing list. +
+

The Team participates in a Working Group + from the moment the creation of the group is announced + until the group closes.

+
3.4.3.6. Team Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Team representative in an Interest Group when so designated by W3C management.

+

4. Lifecycle of Chartered Groups

+

4.1. Initiating Charter Development

+

W3C creates charters for chartered groups based on interest from the Members and Team. + The Team must notify the Advisory Committee + when a charter for a new Working Group or Interest Group is in development. + This is intended to raise awareness, + even if no formal proposal is yet available. + Advisory Committee representatives may provide + feedback on the Advisory Committee discussion list or via other designated channels.

+

W3C may begin work + on a Working Group or Interest Group charter + at any time.

+

4.2. Content of a Charter

+

A Working Group or Interest Group charter must include all of the following information.

+
    +
  • The group’s mission + (e.g., develop a technology or process, review the work of other groups). +
  • The scope of the group’s work and criteria for success. +
  • The duration of the group (typically from six months to two years). +
  • The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software). +
  • + Expected milestone dates where available. +

    Note: A charter is not required to include schedules for review of other group’s deliverables.

    +
  • The process for the group to approve the release of deliverables + (including intermediate results). +
  • Any dependencies by groups within or outside of W3C on the deliverables of this group. + For any dependencies, the charter must specify + the mechanisms for communication about the deliverables. +
  • Any dependencies of this group on other groups within or outside of W3C. + Such dependencies include interactions with W3C Horizontal Groups [CHARTER]. +
  • The level of confidentiality of the group’s proceedings and deliverables. +
  • Meeting mechanisms and expected frequency. +
  • If known, + the date of the first face-to-face meeting. + The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal. +
  • Communication mechanisms to be employed within the group, + between the group and the rest of W3C, + and with the general public. +
  • Any voting procedures or requirements + other than those specified in § 5.2.3 Deciding by Vote. +
  • An estimate of the expected time commitment from participants. +
  • The expected time commitment and level of involvement by the Team + (e.g., to track developments, + write and edit technical reports, + develop code, + or organize pilot experiments). +
  • Intellectual property information. + What are the intellectual property (including patents and copyright) + considerations affecting the success of the Group? + In particular, is there any reason to believe + that it will be difficult to meet the Royalty-Free licensing goals + in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY]? +
+

See also the charter requirements in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

For every Recommendation Track deliverable + that continues work on technical report published under any other Charter (including a predecessor group of the same name), + for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

+
    +
  • The title, + stable URL, + and publication date of the Working Draft or other Recommendation-track document + that will serve as the basis for work on the deliverable + (labeled “Adopted Draft”); +
  • The title, + stable URL, + and publication date of the document + that was used as the basis for its most recent Exclusion Opportunity + as per + the W3C Patent Policy [PATENT-POLICY]. + (labeled “Exclusion Draft”); and +
  • The stable URL of the Working Group charter + under which the Exclusion Draft was published + (labeled the “Exclusion Draft Charter”). +
+

All of the above data must be identified + in the adopting Working Group’s charter using the labels indicated.

+

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. + The proposed charter must state + the dates on which the Exclusion Opportunity + that arose on publishing the Exclusion Draft began and ended. + As per “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY], + this potentially means that exclusions can only be made immediately on joining a Working Group.

+

An Interest Group charter may include provisions regarding participation, + including specifying + that the only requirement for participation (by anyone) in + the Interest Group is subscription to the Interest Group mailing list. + This type of Interest Group may have public participants.

+

A charter may include + provisions other than those required by this document. + The charter should highlight + whether additional provisions impose constraints + beyond those of the W3C Process Document + (e.g., limits on the number of individuals in a Working Group + who represent the same Member organization or group of related Members).

+

4.3. Advisory Committee Review of a Charter

+

The Team must solicit Advisory Committee review of every new or substantively modified Working Group or Interest Group charter, + except for either:

+
    +
  • +

    a charter extension

    +
  • +

    substantive changes to a charter that do not affect the way the group functions in any significant way.

    +
+

The review period must be at least 28 days. + The following are examples of substantive changes that would not require an Advisory Committee Review: + the addition of an in-scope deliverable, + a change of Team Contact, + or a change of Chair. + Such changes must nonetheless be announced + to the Advisory Committee and to participants in the Working or in the Interest Group, + and a rationale must be provided.

+

The Call for Review of a substantively modified charter must highlight important changes + (e.g., regarding deliverables or resource allocation) + and include rationale for the changes.

+

As part of the Advisory Committee review of any new or substantively modified Working Group charter, + any Advisory Committee representative may request an extended review period.

+

Such a request must be submitted with a Member’s comments + in response to the Call for Review. + Upon receipt of any such request, + the Team must ensure + that the Call for Participation for the Working Group + occurs at least 60 days + after the Call for Review of the charter.

+

4.4. Call for Participation in a Chartered Group

+

Deciding whether to adopt a proposed Working Group or Interest Group charter is a W3C Decision. + Charters may be amended based on review comments + per § 5.7.2 After the Review Period before the Call for Participation.

+

If the decision is to charter the group, + the Team must issue a Call for Participation to the Advisory Committee. + For a new group, this announcement officially creates the group. + The announcement must include a reference to the charter, + the name(s) of the group’s Chair(s), + and the name(s) of the Team Contact(s).

+

After a Call for Participation, + any Member representatives and Invited Experts must be designated (or re-designated). + When a group is re-chartered, + individuals participating in the Working Group or Interest Group before the new Call for Participation + may attend any meetings held within forty-five (45) days of the Call for Participation + even if they have not yet formally rejoined the group + (i.e., committed to the terms of the charter and patent policy).

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against the decision to create + or substantially modify + a Working Group or Interest Group charter.

+

4.5. Charter Extension

+

The Team may decide + to extend a Working Group or Interest Group charter + with no other substantive modifications. + The Team must announce + such extensions to the Advisory Committee. + The announcement must indicate the new duration. + The announcement must also include rationale for the extension, + a reference to the charter, + and the Group homepage + (which includes at least + the name(s) of the group’s Chair(s), + the name of the Team Contact, + and instructions for joining the group).

+

After a charter extension, + Advisory Committee representatives + and the Chair are not required to re-designate Member representatives and Invited Experts.

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.

+

4.6. Chartered Group Closure

+

A Working Group or Interest Group charter specifies a duration for the group.

+

In exceptional circumstances, + The Team may propose through an AC Review to close a group prior to the date specified in the charter. + This may occur for instance + when a Patent Advisory Group concluded that the work should be terminated.

+

Closing a Working Group has implications + with respect to the W3C Patent Policy [PATENT-POLICY].

+

5. Decisions

+

W3C attempts to resolve issues through dialog. + Individuals who disagree strongly with a decision should register with the Chair any Formal Objections.

+

5.1. Types of Decisions

+

The Chair of a Working Group or Interest Group has the prerogative + to make certain decisions based on their own judgment. + Such decisions are called chair decisions.

+

In contrast, + decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group + or following a vote (see § 5.2.3 Deciding by Vote) + are called group decisions (also known as group “resolutions”).

+

A W3C decision is one + where the Director decides, + after exercising the role of assessing consensus of the W3C Community after an Advisory Committee review.

+

5.2. Consensus Building

+

5.2.1. Consensus

+

Consensus is a core value of W3C. + To promote consensus, + the W3C process requires Chairs to ensure + that groups consider all legitimate views and objections, + and endeavor to resolve them, + whether these views and objections are expressed by the active participants of the group + or by others + (e.g., another W3C group, + a group in another organization, + or the general public). + Decisions may be made during meetings + (face-to-face or distributed) + as well as through persistent text-based discussions.

+

Note: The Director, CEO, and COO have the role of + assessing consensus within the Advisory Committee.

+

The following terms are used in this document + to describe the level of support for a decision among a set of eligible individuals:

+
+
Consensus: +
A substantial number of individuals in the set + support the decision + and nobody in the set registers a Formal Objection. + Individuals in the set may abstain. + Abstention is either an explicit expression of no opinion + or silence by an individual in the set. +
Unanimity: +
The particular case of consensus where all individuals in the set support the decision + (i.e., no individual in the set abstains). +
Dissent: +
At least one individual in the set registers a Formal Objection. +
+

By default, the set of individuals eligible to participate in a decision is the set of group participants. + The Process Document does not require a quorum for decisions + (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). + A charter may include a quorum requirement for consensus decisions.

+

Where unanimity is not possible, + a group should strive to make consensus decisions + where there is significant support and few abstentions. + The Process Document does not require a particular percentage of eligible participants + to agree to a motion in order for a decision to be made. + To avoid decisions where there is widespread apathy, + (i.e., little support and many abstentions), + groups should set minimum thresholds of active support before a decision can be recorded. + The appropriate percentage may vary depending on the size of the group + and the nature of the decision. + A charter may include threshold requirements for consensus decisions. + For instance, a charter might require a supermajority of eligible participants + (i.e., some established percentage above 50%) + to support certain types of consensus decisions.

+
+ Note: Chairs have substantial flexibility + in how they obtain and assess consensus among their groups. + Unless otherwise constrained by charter, + they may use modes including but not limited to explicit calls for consensus, + polls of participants, + “lazy consensus” in which lack of objection after sufficient notice is taken as assent; + or they may also delegate and empower a document editor + to assess consensus on their behalf, + whether in general + or for specific pre-determined circumstances + (e.g. in non-controversial situations, for specific types of issues, etc.). +

If questions or disagreements arise, + the final determination of consensus remains with the chair.

+
+

5.2.2. Managing Dissent

+

In some cases, even after careful consideration of all points of view, + a group might find itself unable to reach consensus. + The Chair may record a decision where there is dissent (i.e., there is at least one Formal Objection) + so that the group can make progress + (for example, to produce a deliverable in a timely manner). + Dissenters cannot stop a group’s work + simply by saying that they cannot live with a decision. + When the Chair believes that the Group has duly considered + the legitimate concerns of dissenters as far as is possible and reasonable, + the group should move on.

+

Groups should favor proposals that create the weakest objections. + This is preferred over proposals that are supported by a large majority + but that cause strong objections from a few people. + As part of making a decision where there is dissent, + the Chair is expected to be aware of which participants work for the same + (or related) + Member organizations and weigh their input accordingly.

+

5.2.3. Deciding by Vote

+

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, + and that a vote is necessary to break a deadlock. + In this case the Chair must record + (e.g., in the minutes of the meeting or in an archived email message):

+
    +
  • an explanation of the issue being voted on; +
  • the decision to conduct a vote + (e.g., a simple majority vote) to resolve the issue; +
  • the outcome of the vote; +
  • any Formal Objections. +
+

In order to vote to resolve a substantive issue, + an individual must be a group participant. + Each organization represented in the group must have at most one vote, + even when the organization is represented by several participants in the group + (including Invited Experts). + For the purposes of voting:

+
    +
  • A Member or group of related Members is considered a single organization. +
  • The Team is considered an organization. +
+

Unless the charter states otherwise, Invited Experts may vote.

+

If a participant is unable to attend a vote, + that individual may authorize anyone at the meeting + to act as a proxy. + The absent participant must inform the Chair in writing + who is acting as proxy, with written instructions on the use of the proxy. + For a Working Group or Interest Group, + see the related requirements regarding an individual + who attends a meeting as a substitute for a participant.

+

A group may vote for other purposes than to resolve a substantive issue. + For instance, the Chair often conducts a “straw poll” vote + as a means of determining whether there is consensus about a potential decision.

+

A group may also vote to make a process decision. + For example, + it is appropriate to decide by simple majority + whether to hold a meeting in San Francisco or San Jose + (there’s not much difference geographically). + When simple majority votes are used to decide minor issues, + voters are not required to state the reasons for votes, + and the group is not required to record individual votes.

+

A group charter may include formal voting procedures + (e.g., quorum or threshold requirements) + for making decisions about substantive issues.

+

5.3. Formally Addressing an Issue

+

In the context of this document, + a group has formally addressed an issue when it has sent a public, substantive response + to the reviewer who raised the issue. + A substantive response is expected to include rationale for decisions + (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). + The adequacy of a response is measured + against what a W3C reviewer would generally consider to be technically sound. + If a group believes that a reviewer’s comments result from a misunderstanding, + the group should seek clarification before reaching a decision.

+

As a courtesy, + both Chairs and reviewers should set expectations + for the schedule of responses and acknowledgments. + The group should reply to a reviewer’s initial comments + in a timely manner. + The group should set a time limit + for acknowledgment by a reviewer of the group’s substantive response; + a reviewer cannot block a group’s progress. + It is common for a reviewer to require a week or more + to acknowledge and comment on a substantive response. + The group’s responsibility to respond to reviewers + does not end once a reasonable amount of time has elapsed. + However, reviewers should realize + that their comments will carry less weight + if not sent to the group in a timely manner.

+

Substantive responses should be recorded. + The group should maintain an accurate summary + of all substantive issues and responses to them + (e.g., in the form of an issues list with links to mailing list archives).

+

5.4. Reopening a Decision When Presented With New Information

+

The Chair may reopen a decision + when presented with new information, including:

+
    +
  • additional technical information, +
  • comments by email from participants who were unable to attend a scheduled meeting, +
  • comments by email from meeting attendees + who chose not to speak out during a meeting + (e.g., so they could confer later with colleagues or for cultural reasons). +
+

The Chair should record + that a decision has been reopened, + and must do so upon request from a group participant.

+

5.5. Chair Decision and Group Decision Appeals

+

When group participants believe that their concerns are not being duly considered by the group or the Chair, + they may ask the Director (for representatives of a Member organization, via their Advisory Committee representative) + to confirm or deny the decision. + This is a Group Decision Appeal or a Chair Decision Appeal. + The participants should also make their requests known + to the Team Contact. + The Team Contact must inform the Director + when a group participant has raised concerns about due process.

+

Any requests to the Director to confirm a decision must include a summary of + the issue (whether technical or procedural), + decision, + and rationale for the objection. + All counter-arguments, + rationales, + and decisions must be recorded.

+

Procedures for Advisory Committee appeals are described separately.

+

5.6. Recording and Reporting Formal Objections

+

In the W3C process, + an individual may register a Formal Objection to a decision. + A Formal Objection to a group decision + is one that the reviewer requests that the Director consider + as part of evaluating the related decision + (e.g., in response to a request to advance a technical report).

+

Note: In this document, the term “Formal Objection” is used to emphasize this process implication: + Formal Objections receive Director consideration. + The word “objection” used alone has ordinary English connotations.

+

An individual who registers a Formal Objection should cite technical arguments + and propose changes that would remove the Formal Objection; + these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments + or rationale are unlikely to receive serious consideration.

+

A record of each Formal Objection must be publicly available. + A Call for Review (of a document) to the Advisory Committee must identify any Formal Objections.

+

5.7. Advisory Committee Reviews

+

Advisory Committee review is the process + by which the Advisory Committee formally confers its approval + on charters, technical reports, + and other matters.

+

5.7.1. Start of a Review Period

+

Each Advisory Committee review period + begins with a Call for Review from the Team to the Advisory Committee. + The Call for Review describes the proposal, + raises attention to deadlines, + estimates when the decision will be available, + and includes other practical information. + Each Member organization may send one review, + which must be returned by its Advisory Committee representative.

+

The Team must provide two channels for Advisory Committee review comments:

+
    +
  1. an archived Team-only channel; +
  2. an archived Member-only channel. +
+

The Call for Review must specify + which channel is the default for review comments on that Call.

+

Reviewers may send information + to either or both channels. + A reviewer may also share their own reviews + with other Members on the Advisory Committee discussion list, + and may also make it available to the public.

+

A Member organization may modify its review + during a review period + (e.g., in light of comments from other Members).

+

5.7.2. After the Review Period

+

After the review period, + the Director must announce + to the Advisory Committee the level of support for the proposal + (consensus or dissent). + The Director must also indicate + whether there were any Formal Objections, + with attention to changing confidentiality level. + This W3C decision is generally one of the following:

+
    +
  1. The proposal is approved, + possibly with editorial changes integrated. +
  2. The proposal is approved, + possibly with substantive changes integrated. + In this case the announcement must include rationale + for the decision to advance the document despite the proposal for a substantive change. +
  3. The proposal is returned for additional work, + with a request to the initiator to formally address certain issues. +
  4. The proposal is rejected. +
+

This document does not specify + time intervals between the end of an Advisory Committee review period + and the W3C decision. + This is to ensure that the Members and Team have sufficient time to consider comments + gathered during the review. + The Advisory Committee should not expect an announcement + sooner than two weeks after the end of a review period. + If, after three weeks, the outcome has not been announced, + the Director should provide the Advisory Committee with an update.

+

5.8. Advisory Committee Votes

+

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, + and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. + Whenever the Advisory Committee votes, + each Member or group of related Members has one vote.

+

5.9. Appeal by Advisory Committee Representatives

+

Advisory Committee representatives may appeal certain decisions, + though appeals are only expected to occur in extraordinary circumstances.

+

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate + an Advisory Committee Appeal. + These W3C decisions include those related to group creation and modification, + and transitions to new maturity levels for Recommendation Track documents + and the Process document.

+

Advisory Committee representatives may also initiate an appeal + for certain decisions that do not involve an Advisory Committee review. + These cases are identified in the sections + which describe the requirements for the decision + and include + additional (non-reviewed) maturity levels of Recommendation Track documents, + group charter extensions and closures, + and Memoranda of Understanding.

+

In all cases, + an appeal must be initiated within three weeks of the decision.

+

An Advisory Committee representative initiates an appeal by sending a request to the Team. + The request should say “I appeal this Director’s Decision” + and identify the decision. + Within one week the Team must announce the appeal process + to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. + The archive of these statements must be member-only. + If, within one week of the Team’s announcement, + 5% or more of the Advisory Committee support the appeal request, + the Team must organize an appeal vote + asking the Advisory Committee “Do you approve of the Director’s Decision?” + together with links to the Director's decision and the appeal support.

+

The ballot must allow for three possible responses: + “Approve”, + “Reject”, + and “Abstain”, + together with Comments.

+

If the number of votes to reject + exceeds the number of votes to approve, + the decision is overturned. + In that case, there are the following possible next steps:

+
    +
  1. The proposal is rejected. +
  2. The proposal is returned for additional work, + after which the applicable decision process is re-initiated. +
+

6. W3C Technical Reports

+

The W3C technical report development process is the set of steps and requirements + followed by W3C Working Groups to standardize Web technology. + The W3C technical report development process is designed to:

+
    +
  • support multiple specification development methodologies +
  • maximize consensus about the content of stable technical reports +
  • ensure high technical and editorial quality +
  • promote consistency among specifications +
  • facilitate royalty-free, interoperable implementations of Web Standards, and +
  • earn endorsement by W3C and the broader community. +
+

See also “licensing goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

6.1. Types of Technical Reports

+

This chapter describes the formal requirements + for publishing and maintaining a W3C Recommendation, Note, + or Registry Report.

+
+
Recommendations +
Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines + as standards for the Web. + The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, + and consensus-building, + and is subject to the W3C Patent Policy [PATENT-POLICY], + under which participants commit to Royalty-Free IPR licenses for implementations. + See § 6.3 The W3C Recommendation Track for details. +
Notes +
Groups can also publish documents as W3C Notes and W3C Statements, + typically either to document information + other than technical specifications, + such as use cases motivating a specification + and best practices for its use. + See § 6.4 The Note Track (Notes and Statements) for details. +
Registries +
Working Groups can also publish registries in order to document collections of values or other data. + These are typically published in a separate registry report, + although they can also be directly embedded in Recommendation Track documents + as a registry section. Defining a registry requires wide review and consensus, + but once set up, changes to registry entries are lightweight + and can even be done without a Working Group. + See § 6.5 The Registry Track for details. +
+

Individual Working Groups and Interest Groups should adopt additional processes + for developing publications, + so long as they do not conflict with the requirements in this chapter.

+

6.2. General Requirements for Technical Reports

+

6.2.1. Publication of Technical Reports

+

Publishing as used in this document + refers to producing a version which is listed as a W3C Technical Report on its Technical Reports index at https://www.w3.org/TR [TR]. + Every document published as part of the technical report development process must be a public document. + W3C strives to make archival documents indefinitely available + at their original address in their original form.

+

Every document published as part of the technical report development process must clearly indicate its maturity level, + and must include information about the status of the document. + This status information:

+
    +
  • must be unique each time a specification is published, +
  • must state which Working Group developed the specification, +
  • must state how to send comments or file bugs, + and where these are recorded, +
  • must include expectations about next steps, +
  • should explain how the technology relates to existing international standards + and related work inside or outside W3C, + and +
  • should explain + or link to + an explanation of significant changes from the previous version. +
+

Every Technical Report published + as part of the Technical Report development process + is edited by one or more editors + appointed by a Group Chair. + It is the responsibility of these editors to ensure that the decisions of the Group are + correctly reflected in subsequent drafts of the technical report. + An editor must be a participant, + per § 3.4.2 Participation in Chartered Groups in the Group responsible for the document(s) they are editing.

+

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, + status information, + style, + and copyright requirements). + These rules are subject to change by the Team from time to time. + The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

+

The primary language for W3C Technical Reports is English. + W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C Web site.

+

6.2.2. Reviews and Review Responsibilities

+

A document is available for review + from the moment it is first published. + Working Groups should formally address any substantive review comment + about a technical report in a timely manner.

+

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, + particularly if this would cause significant compatibility problems + due to existing implementation. Working Groups should record substantive + or interesting proposals raised by reviews + but not incorporated into a current specification.

+
6.2.2.1. Wide Review
+

The requirements for wide review are not precisely defined by the W3C Process. + The objective is to ensure that the entire set of stakeholders of the Web community, + including the general public, + have had adequate notice of the progress of the Working Group (for example through notices posted to public-review-announce@w3.org) + and were able to actually perform reviews of and provide comments on the specification. + A second objective is to encourage groups to request reviews + early enough that comments and suggested changes + can still be reasonably incorporated in response to the review. + Before approving transitions, + the Team will consider who has been explicitly offered + a reasonable opportunity to review the document, + who has provided comments, + the record of requests to and responses from reviewers, + especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter + or identified as liaisons [LIAISON], + and seek evidence of clear communication to the general public + about appropriate times and which content to review + and whether such reviews actually occurred.

+

For example, + inviting review of new or significantly revised sections published in Working Drafts, + and tracking those comments + and the Working Group's responses, + is generally a good practice which would often be considered positive evidence of wide review. Working Groups should follow the W3C Horizontal Groups’ review processes, + and should announce to other W3C Working Groups + as well as the general public, + especially those affected by this specification, + a proposal to enter Candidate Recommendation (for example in approximately 28 days). + By contrast a generic statement in a document + requesting review at any time + is likely not to be considered as sufficient evidence + that the group has solicited wide review.

+

A Working Group could present evidence that wide review has been received, + irrespective of solicitation. + But it is important to note that receiving many detailed reviews + is not necessarily the same as wide review, + since they might only represent comment + from a small segment of the relevant stakeholder community.

+

6.2.3. Classes of Changes

+

This document distinguishes the following 5 classes of changes to a specification. + The first two classes of change are considered editorial changes, + the next two substantive changes, + and the last one registry changes.

+
+
+ +
    +
  1. +

    No changes to text content

    +
+
These changes include fixing broken links, style sheets or invalid markup. +
+ +
    +
  1. +

    Corrections that do not affect conformance

    +
+
Changes that reasonable implementers + would not interpret as changing architectural + or interoperability requirements + or their implementation. + Changes which resolve ambiguities in the specification + are considered to change (by clarification) the implementation requirements + and do not fall into this class. +
Examples of changes in this class include + correcting non-normative code examples + where the code clearly conflicts with normative requirements, + clarifying informative use cases or other non-normative text, + fixing typos or grammatical errors + where the change does not change implementation requirements. + If there is any doubt or disagreement + as to whether requirements are changed, + such changes do not fall into this class. +
+ +
    +
  1. +

    Corrections that do not add new features

    +
+
+ These changes may affect conformance to the specification. + A change that affects conformance is one that: +
    +
  • makes conforming data, processors, or other conforming agents become non-conforming according to the new version, + or +
  • makes non-conforming data, processors, or other agents become conforming, + or +
  • clears up an ambiguity or under-specified part of the specification + in such a way that data, + a processor, + or an agent + whose conformance was once unclear + becomes clearly either conforming or non-conforming. +
+
+ +
    +
  1. +

    New features

    +
+
Changes that add a new functionality, element, etc. +
+ +
    +
  1. +

    Changes to the contents of a registry table

    +
+
Changes that add, remove, or alter registry entries in a registry table. +
+

6.2.4. Errata Management

+

Tracking errors is an important part of a Working Group's ongoing care of a technical report; + for this reason, + the scope of a Working Group charter generally allows time + for work after publication of a Recommendation. + In this Process Document, + the term “erratum” + (plural “errata”) refers to any error + that can be resolved by one or more changes in classes 1-3 + of section § 6.2.3 Classes of Changes.

+

Working Groups must keep + a public record of errors + that are reported by readers and implementers + for Recommendations. + Such error reports should be compiled + no less frequently than quarterly.

+

Working Groups decide how to document errata. + Such documentation must identify + the affected technical report text + and describe the error; + it may also describe some possible solution(s). + Readers of the technical report should be able easily + to find and see the errata + that apply to that specific technical report with their associated tests. + Errata may be documented + in a separate errata page or tracking system. + They may, + in addition or alternatively, + be annotated inline + alongside the affected technical report text + or at the start or end of the most relevant section(s).

+

6.2.5. Candidate Amendments

+

An erratum may be accompanied by an informative, candidate correction approved by the consensus of the Working Group. + When annotated inline, + errata—including their candidate corrections—must be marked as such, + are treated as class 2 changes, + and are published accordingly.

+

Note: Annotating changes in this way allows more mature documents + such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, + even when the candidate amendments have not yet received + sufficient review or implementation experience + to be normatively incorporated into the specification proper.

+

A candidate addition is similar to a candidate correction, + except that it proposes a new feature + rather than an error correction.

+

If there is no group chartered to maintain a technical report, + the Team may maintain its errata and associated candidate corrections. + Such corrections must be marked + as Team correction, + and do not constitute + a normative portion of the Recommendation, + as defined in the Patent Policy [PATENT-POLICY] (i.e. they are not covered by the Patent Policy). + The Team must solicit wide review on Team corrections that it produces.

+

Candidate corrections and candidate additions are collectively known as candidate amendments.

+

In addition to their actual maturity level, published REC Track documents with candidate amendments are also considered, + for the purpose of the W3C Patent Policy [PATENT-POLICY], + to be Working Drafts with those candidate amendments treated as normative.

+

6.2.6. License Grants from Non-Participants

+

When a party who is not already obligated under the Patent Policy + offers a change in class 3 or 4 + (as described in § 6.2.3 Classes of Changes) to a technical report under this process + the Team must request + a recorded royalty-free patent commitment; + for a change in class 4, the Team must secure such commitment. + Such commitment should cover, + at a minimum, + all the party’s Essential Claims both in the contribution, + and that become Essential Claims as a result of incorporating the contribution into the draft + that existed at the time of the contribution, + on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

+

6.3. The W3C Recommendation Track

+

Working Groups create specifications and guidelines + to complete the scope of work envisioned by a Working Group's charter. + These technical reports undergo cycles of revision and review + as they advance towards W3C Recommendation status. + Once review suggests the Working Group has met their requirements for a new standard, + including wide review, + a Candidate Recommendation phase + allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. + At the end of the process, + the Advisory Committee reviews the mature technical report, + and if there is support from its Membership, + W3C publishes it as a Recommendation.

+

In summary, the W3C Recommendation Track consists of:

+
    +
  1. Publication of the First Public Working Draft. +
  2. Publication of zero or more revised Working Drafts. +
  3. Publication of one or more Candidate Recommendations. +
  4. Publication of a Proposed Recommendation. +
  5. Publication as a W3C Recommendation. +
+
+ + Basic W3C Recommendation Track + + + + + First Public Working Draft (FPWD) - Exclusion opportunity + + + + WG decision + Team's approval + + + + + + + + + Working Draft (WD) + + + + + + + + Publish a new Working Draft + + + WG Decision: review needed, or + No change for 6 months + + + + + + + + + Advance to Candidate Recommendation + + Team's approval + + + + + + + + + + Candidate Recommendation (CR) - Patent Policy exclusion opportunity + + + + + + Candidate Recommendation Draft (CRD) + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation + + + WG Decision + + Team’s approval + + + + + + + + + Publish revised Candidate Recommendation + + + WG Decision + Team’s approval + + + + + + + + + + Advance to Proposed Recommendation + + Team's approval + + + + + + + + Return to Working Draft + + + WG or Team decision + e.g. for further review + + + + + + + + + + + Proposed Recommendation (PR) - Advisory Committee review + + + + + + + + Advance to Recommendation + + + Advisory Committee Review + Team's Decision + + + + + + + + + Return to Candidate Recommendation + + + AC Review, + Team Decision + e.g. for editorial changes + + + + + + + + + Return to Working Draft + + + Advisory Committee review and Team's Decision, e.g. for further work and review + + + + + + + + + + Recommendation (Rec) + + + + + +
+

This Process defines certain Recommendation Track publications as Patent Review Drafts. + Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004], + these correspond to “Last Call Working Draft” in the Patent Policy; + Starting from the 2020 Patent Policy [PATENT-POLICY-2020], + these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

+

W3C may end work on a technical report at any time.

+

As described in § 6.3.3 Advancement on the Recommendation Track, + the Team will decline a request to advance in maturity level + and return the specification to a Working Group for further work + if it determines that the requirements for advancement + have not been met.

+

6.3.1. Maturity Levels on the Recommendation Track

+
+
Working Draft (WD) +
+ A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, + and other technical organizations, + and for simple historical reference. + Some, but not all, Working Drafts are meant to advance to Recommendation; + see the document status section of a Working Draft + for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, + and do not imply any endorsement by W3C + or its members beyond agreement to work on a general area of technology. + Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. + A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity. +

For all Working Drafts a Working Group:

+
    +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, + and +
  • may request publication of a Working Draft + even if its content is considered unstable + and does not meet all Working Group requirements. +
+

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), + and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

+
Candidate Recommendation (CR) +
+ A Candidate Recommendation is a document that satisfies the technical + requirements of the Working Group that produced it and their dependencies, + and has already received wide review. + W3C publishes a Candidate Recommendation to + +

Note: Advancing to Candidate Recommendation indicates + that the document is considered complete and fit for purpose, + and that no further refinement to the text is expected + without additional implementation experience and testing; + additional features in a later revision may however be expected. + A Candidate Recommendation is expected to be as well-written, + detailed, + self-consistent, + and technically complete + as a Recommendation, + and acceptable as such + if and when the requirements for further advancement are met.

+

Candidate Recommendation publications take one of two forms:

+
+
Candidate Recommendation Snapshot +
+ A Candidate Recommendation Snapshot + corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. + Publishing a Patent Review Draft triggers a Call for Exclusions, + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy. +

Publication as a Candidate Recommendation Snapshot requires approval of either a Transition Request (for the first Candidate Recommendation publication from another maturity level) + or an Update Request (for subsequent Candidate Recommendation Snapshots).

+
Candidate Recommendation Draft +
+ A Candidate Recommendation Draft + is published on the W3C’s Technical Reports page [TR] to integrate changes from the previous Candidate Recommendation Snapshot that the Working Group intends to include + in a subsequent Candidate Recommendation Snapshot. + This allows for wider review of the changes + and for ease of reference to the integrated specification. +

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot. + However, the process requirements are minimized + so that the Working Group can easily keep the specification up to date.

+

A Candidate Recommendation Draft does not provide an exclusion opportunity; + instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

+
+

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered + such that W3C cannot endorse it or continue work on it, + for example due to burdensome patent claims that affect implementers and cannot be resolved + (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). + There is no path to restoration for a Rescinded Candidate Recommendation. + See “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

+
Proposed Recommendation (PR) +
A Proposed Recommendation is a document + that has been accepted by W3C + as of sufficient quality to become a W3C Recommendation. + This phase triggers formal review by the Advisory Committee, + who may recommend + that the document be published as a W3C Recommendation, + returned to the Working Group for further work, + or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation. +
W3C Recommendation (REC) +
+ A W3C Recommendation is a specification + or set of guidelines + or requirements that, + after extensive consensus-building, + has received the endorsement of W3C and its Members. + W3C recommends the wide deployment + of its Recommendations as standards for the Web. + The W3C Royalty-Free IPR licenses + granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. + As technology evolves, + a W3C Recommendation may become: +
+
A Superseded Recommendation +
+ A Superseded Recommendation is a specification + that has been replaced by a newer version + that W3C recommends for new adoption. + An Obsolete or Superseded specification + has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy. +

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, + the latest version replaces the previous one, + without the need to invoke the steps of § 6.3.13.3 Abandoning a W3C Recommendation: + it is the same document, updated. + Explicitly declaring a documented superseded, using the process documented in § 6.3.13.3 Abandoning a W3C Recommendation, + is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

+
An Obsolete Recommendation +
An Obsolete Recommendation is a specification + that W3C has determined lacks sufficient market relevance + to continue recommending it for implementation, + but which does not have fundamental problems + that would require it to be Rescinded. + If an Obsolete specification gains sufficient market relevance, + W3C may decide to restore it to Recommendation status. +
Rescinded Recommendation +
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, + and believes is unlikely to ever be restored to Recommendation status. + See also “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+
Discontinued Draft +
A technical report representing the state of a Recommendation-track document + at the point at which work on it was discontinued. + See § 6.3.13.1 Abandoning an Unfinished Recommendation. +
+

Only sufficiently technically mature work should be advanced.

+

Note: Should faster advancement to meet scheduling considerations be desired, + this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring + less stable features to other technical reports.

+

When publishing an updated version of an existing Candidate Recommendation or Recommendation, + technical reports are expected to meet the same maturity criteria as when they are first published under that status. + However, in the interest of replacing stale documents with improved ones in a timely manner, + if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, + it is also permissible to publish an updated CR or REC following the usual process, + even if only some of these flaws have been satisfactorily addressed.

+

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, + and do not necessarily imply consensus of a Working Group or Interest Group, + nor are their contents endorsed in any way by W3C.

+

6.3.2. Implementation Experience

+

Implementation experience is required to show that a specification is sufficiently clear, + complete, + and relevant to market needs, + to ensure that independent interoperable implementations + of each feature of the specification will be realized. + While no exhaustive list of requirements is provided here, + when assessing that there is adequate implementation experience the Team will consider (though not be limited to):

+
    +
  • is each feature of the current specification implemented, + and how is this demonstrated? +
  • are there independent interoperable implementations of the current specification? +
  • are there implementations created by people other than the authors of the specification? +
  • are implementations publicly deployed? +
  • is there implementation experience + at all levels of the specification’s ecosystem + (authoring, consuming, publishing…)? +
  • are there reports of difficulties or problems with implementation? +
+

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. + Groups are often able to work more effectively + if they plan how they will demonstrate interoperable implementations + early in the development process; + for example, developing tests in concert with implementation efforts.

+

6.3.3. Advancement on the Recommendation Track

+

For all requests to advance a specification + to a new maturity level + (called Transition Requests), + the Working Group:

+
    +
  • must record the group’s decision to request advancement. +
  • must obtain Team approval. Team approval (a Team decision) must be withheld if any Process requirements are not met + or if there remain any unresolved Formal Objections. + If the Team rejects a Transition Request it must indicate its rationale + to the Advisory Committee and the Working Group. +
  • must publicly document all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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 provide public documentation of any Formal Objections. +
  • should report which, if any, of the Working Group's requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

For a First Public Working Draft there is no “previous maturity level”, + so many requirements do not apply, + and approval is normally fairly automatic. + For later stages, + especially transition to Candidate or Proposed Recommendation, + there is usually a formal review meeting + to ensure the requirements have been met before approval is given.

+

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved + while a Working Group's charter is undergoing or awaiting a decision + on an Advisory Committee Review.

+

+

6.3.4. Updating Mature Publications on the Recommendation Track

+

Certain requests to re-publish a specification + within its current maturity level + (called Update Requests) + require extra verification. + For such update requests, the Working Group:

+
    +
  • must record the group’s decision to request the update. +
  • must show that the changes have received wide review. +
  • must obtain Team approval, + or fulfill the criteria for § 6.3.4.1 Streamlined Publication Approval. Team approval (a Team decision), should be withheld if any Process requirements are not met, + and may be withheld in consideration of unresolved Formal Objections. + If the Team rejects an Update Request, + it must indicate its rationale to the Working Group. + If it waives any Process requirements, + it must indicate its rationale to the AC. +
  • must provide public documentation of any Formal Objections. +
  • must publicly document of all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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, + or explain why the requirements have changed or been deferred, +
  • should report which, if any, of the Working Group's requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

There is usually a formal review meeting + to ensure the requirements have been met before Team's approval is given.

+

Note: Update request approval is expected to be fairly simple + compared to getting approval for a transition request.

+

The Team must announce the publication + of the revised specification + to other W3C groups and the Public.

+
6.3.4.1. Streamlined Publication Approval
+

Note: These criteria are intentionally stricter than + the general requirements for an update request. + This is in order to minimize ambiguities and the need for expert judgment, + and to make self-evaluation practical.

+

In order to streamline the publication process in non-controversial cases, + approval to an update request is automatically granted without formal review + when the following additional criteria are fulfilled:

+
    +
  • There must have been no changes to Working Group requirements about this document. +
  • For each of the W3C Horizontal Groups [CHARTER], + if the Horizontal Review Group has made available a set criteria + under which their review is not necessary, + the Working Group must document that these criteria have been fulfilled. + Otherwise, the Working Group must show + that review from that group has been solicited and received. +
  • No Formal Objection has been registered against the document. +
  • + The Working Group must have formally addressed: +
      +
    • +

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

      +
    • +

      all issues raised against changes since the previous publication

      +
    • +

      all issues raised against the document that were closed since the previous publication with no change to the document

      +
    +

    The response to each of these issues must be to the satisfaction + 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.

    +

    Note: This is stricter than the general Transition Request criteria.

    +
+

Additionally, for updates to Recommendations with substantive changes or with new features:

+ +

The Working Group must provide written evidence for these claims, + and the Team must make these answers publicly and permanently available.

+

After publication, + if an AC Representative + or Team member + doubts that the evidence presented supports the claims, + they may request that a formal review meeting be convened post facto. + If that review finds that the requirements were not fulfilled, + the Team may revert the changes + by updating in place the status section to indicate that it has been reverted, + and by republishing the previously approved version of the technical report.

+

6.3.5. Publishing a First Public Working Draft

+

To publish the First Public Working Draft of a document, + a Working Group must meet the applicable requirements for advancement.

+

The Team must announce + the publication of a First Public Working Draft to other W3C groups and to the public.

+

6.3.6. Revising a Working Draft

+

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, + whose status section should indicate reasons for the lack of change.

+

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

+
    +
  • must record the group’s decision to request publication. Consensus is not required, + as this is a procedural step, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Working Draft, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous step, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups, +
+

Possible next steps for any Working Draft:

+ +

6.3.7. Transitioning to Candidate Recommendation

+

To publish a Candidate Recommendation, + in addition to meeting the requirements for advancement a Working Group:

+
    +
  • must show that the specification + has met all Working Group requirements, + or explain why the requirements have changed or been deferred, +
  • must document changes to dependencies during the development of the specification, +
  • must document + how adequate implementation experience will be demonstrated, +
  • must specify the deadline for comments, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • must show that the specification has received wide review, and +
  • 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 Recommendation. +
+

The first Candidate Recommendation publication + after approval of a Transition Request is always a Candidate Recommendation Snapshot. + The Team must announce + the publication of the Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

Possible next steps after a Candidate Recommendation Snapshot:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.8. Revising a Candidate Recommendation

+
6.3.8.1. Publishing a Candidate Recommendation Snapshot
+

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, + the Working Group must meet the requirements of an update request in order to republish.

+

In addition the Working Group:

+
    +
  • must specify the deadline for further comments, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • 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 Recommendation. +
+

The Team must announce + the publication of a revised Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

To provide timely updates and patent protection, + a Candidate Recommendation Snapshot should be published + within 24 months of the Working Group accepting + any proposal for a substantive change + (and preferably sooner). + To make scheduling reviews easier, + a Candidate Recommendation Snapshot should not be published + more often than approximately once every 6 months.

+

Note: Substantive changes trigger a new Exclusion Opportunity + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.8.2. Publishing a Candidate Recommendation Draft
+

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 + that would benefit from review beyond the Working Group.

+

To publish a revision of a Candidate Recommendation Draft, + a Working Group:

+
    +
  • must record the group’s decision to request publication, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups. +
+

Note: A Working Group does not need to + meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

+

Possible next steps after a Candidate Recommendation Draft:

+ +

6.3.9. Transitioning to Proposed Recommendation

+

In addition to meeting the requirements for advancement,

+
    +
  • The status information must specify the deadline for Advisory Committee review, + which must be at least 28 days + after the publication of the Proposed Recommendation and should be at least 10 days + after the end of the last Exclusion Opportunity + per ”Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+

A Working Group:

+ +

The Team:

+ +

Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on, + to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft.

+

A Proposed Recommendation may identify itself + as intending to allow new features (class 4 changes) + after its initial publication as a Recommendation, + as described in § 6.3.11.4 Revising a Recommendation: New Features. + Such an allowance cannot be added + to a technical report previously published as a Recommendation that did not allow such changes.

+

Possible Next Steps:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.10. Transitioning to W3C Recommendation

+

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

+

In addition to meeting the requirements for advancement,

+ +

Possible next steps: + A W3C Recommendation normally retains its status indefinitely. + However it may be:

+ +

6.3.11. Revising a W3C Recommendation

+

This section details the process for making changes to a Recommendation.

+
6.3.11.1. Revising a Recommendation: Markup Changes
+

A Working group may request republication of a Recommendation to make corrections that do not result + in any changes to the text of the specification. + (See class 1 changes.)

+

If there is no Working Group chartered to maintain a Recommendation, + the Team may republish the Recommendation with such changes incorporated.

+
6.3.11.2. Revising a Recommendation: Editorial Changes
+

Editorial changes to a Recommendation require no technical review of the intended changes. + A Working Group, + provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity levels. + (See class 2 changes.)

+

If there is no Working Group chartered to maintain a Recommendation, + the Team may republish the Recommendation with such changes incorporated, + including errata and Team corrections.

+
6.3.11.3. Revising a Recommendation: Substantive Changes
+

A candidate correction can be made normative + and be folded into the main text of the Recommendation, + once it has satisfied all the same criteria + as the rest of the Recommendation, + including review by the community to ensure + the technical and editorial soundness of the candidate amendments. + To validate this, the Working Group must request + a Last Call for Review of Proposed Amendments, + followed by an update request. + See § 6.3.11.5 Incorporating Candidate Amendments.

+

Alternatively, + a Working Group may incorporate the changes + and publish as a Working Draft—or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—and advance the specification from that state. + (See class 3 changes.)

+

Note: If there is no Working Group chartered to maintain a Recommendation the Team cannot make substantive changes and republish the Recommendation. + It can, however, informatively highlight problems and desirable changes + using errata and candidate corrections and republish as described in the previous section.

+
6.3.11.4. Revising a Recommendation: New Features
+

New features (see class 4 changes) + may be incorporated into a Recommendation explicitly identified as allowing new features using candidate additions. + A candidate addition can be made normative + and be folded into the main text of the Recommendation using the same process as for candidate amendments, + as detailed in § 6.3.11.3 Revising a Recommendation: Substantive Changes.

+

Note: This prohibition against new features unless explicitly allowed + enables third parties to depend on Recommendations having a stable feature-set, + as they have prior to the 2020 revision of this Process.

+

To make changes which introduce a new feature + to a Recommendation that does not allow new features, + W3C must create a new technical report, + following the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.

+
6.3.11.5. Incorporating Candidate Amendments
+

A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.

+

The Last Call for Review of Proposed Amendments must be announced to other W3C groups, the public, and the Advisory Committee. + The announcement must:

+
    +
  • Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, + or Last Call for Review of Proposed Corrections and Additions. +
  • Identify the specific candidate amendments under review + as proposed amendments (proposed corrections/proposed additions). +
  • Specify the deadline for review comments, + which must not be any sooner than 60 days from the Call for Review. +
  • Solicit review and, if it does not already have it, implementation experience. +
+

The combination of the existing Recommendation with the proposed amendments included in the Last Call for Review of Proposed Amendments is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. + Also, the review initiated by the Last Call for Review of Proposed Amendments is an Advisory Committee Review.

+

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

+

A Working Group may batch + multiple proposed amendments into a single Last Call for Review of Proposed Amendments. + To facilitate review, + a Last Call for Review of Proposed Amendments on a given specification should not be issued more frequently + than approximately once every 6 months.

+

At the end of the Last Call for Review of Proposed Amendments, + the W3C Decision may either be + to reject the proposed amendment, + or to clear the proposed amendment for advancement as is, + or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. + If the Working Group needs to amend a proposed amendment in response to review feedback + it must issue another Last Call for Review of Proposed Amendments on the revised change + before it can be incorporated into the main text.

+

Once all comments on a proposed amendment have been formally addressed, + and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, + it may incorporate the proposed amendment into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

+

To ensure adequate review of proposed amendment combinations, + only proposed amendments included in the most recent Last Call for Review of Proposed Amendments can be incorporated into the normative Recommendation text. + (Thus if incorporation of a proposed amendment is postponed, + it may need to be included in multiple Last Calls for Review of Proposed Amendments.)

+

6.3.12. Regression on the Recommendation Track

+

A Working Group may republish a Recommendation-track technical report at a lower maturity level by fulfilling the requirements to transition to that maturity level, + as described above.

+

Additionally, + with the approval of the TAG and the AB the Team may return + the technical report to a lower maturity level in response to wide review or a formal objection.

+

6.3.13. Retiring Recommendation Track Documents

+

Work on a technical report may cease at any time. + Work should cease + if W3C or a Working Group determines + that it cannot productively carry the work any further.

+
6.3.13.1. Abandoning an Unfinished Recommendation
+

Any Recommendation-track technical report no longer intended + to advance or to be maintained, + and that is not being rescinded, should be published as a Discontinued Draft, + with no substantive change compared to the previous publication. + This can happen if + the Working Group decided + to abandon work on the report, + or as the result of an AC Review requiring the Working Group to discontinue work on the technical report before completion. + If a Working Group is made to close, + W3C must re-publish any unfinished technical report on the Recommendation track as Discontinued Draft.

+

Such a document should include in its status section + an explanation of why it was discontinued.

+

A Working Group may resume work + on such a technical report within the scope of its charter + at any time, + by re-publishing it as a Working Draft.

+
6.3.13.2. Rescinding a Candidate Recommendation
+

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

+
6.3.13.3. Abandoning a W3C Recommendation
+

It is possible that W3C decides + that implementing a particular Recommendation is no longer recommended. + There are three designations for such specifications, + chosen depending on the advice W3C wishes to give about further use of the specification.

+

W3C may obsolete a Recommendation, + for example if the W3C Community decides that the Recommendation no longer represents best practices, + or is not adopted and is not apparently likely to be adopted. + An Obsolete Recommendation may be restored to normal Recommendation, + for example because despite marking it Obsolete the specification is later more broadly adopted.

+

W3C may declare a Recommendation Superseded + if a newer version exists which W3C recommends for new adoption. + The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; + only the name and explanation change.

+

W3C may rescind a Recommendation + if W3C believes there is no reasonable prospect of it being restored + for example due to burdensome patent claims that affect implementers and cannot be resolved; + see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” + and “PAG Conclusion”.

+

W3C only rescinds, supersedes, or obsoletes entire Recommendations. + A Recommendation can be both superseded and obsolete. + To rescind, supersede, or obsolete some part of a Recommendation, + W3C follows the process for modifying a Recommendation.

+

Note: For the purposes of the W3C Patent Policy [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, + although it is not recommended for future implementation; + a Rescinded Recommendation ceases to be in effect + and no new licenses are granted under the Patent Policy.

+
+ + Supersede, Obsolete or Rescind a W3C Recommendation + + + + Recommendation (Rec) + + + + + A major problem and an AC review can lead to a Recommendation being Rescinded. + There are no new IPR licences issued under the W3C Patent Policy, + and reinstating the Recommendation requires going through the full Rec-track process again. + + Major problem, AC review + + + Rescinded Recommendation - no new IPR licenses + + + + + + + + + With little uptake, following AC review a specification may become an Obsolete Recommendation + + + + + Obsolete Recommendation + + + + + + + + If there is new uptake, with AC review an Obsolete Recommendation may return to normal Recommendation status + + + + + + + + + + + Replaced by a new version, AC review + + Superseded Recommendation + + + + + + + A Superseded Recommendation can become a normal Recommendation with AC review + + + + + + + + + + + +
+
6.3.13.4. Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
+

The process of rescinding, obsoleting, + superseding, + or restoring + a Recommendation can be initiated + either by a request from the Team or via a request from any of the following:

+
    +
  • The Working Group who produced, + or is chartered to maintain, + the Recommendation +
  • The TAG, if there is no such Working Group +
  • Any individual who made a request to the relevant Working Group as described above, + or the TAG if such a group does not exist, to obsolete, rescind, supersede, or restore a Recommendation, + where the request was not answered within 90 days +
  • 5% of the members of the Advisory Committee +
+

The Team must then + submit the request to the Advisory Committee for review. + For any Advisory Committee review of a proposal to + rescind, + obsolete, + supersede, + or restore + a Recommendation the Team must:

+
    +
  • announce the proposal to all Working Group Chairs, + and to the Public, + as well as to the Advisory Committee +
  • indicate that this is a proposal to + Rescind, + Obsolete, + Supersede, + or restore, + a Recommendation as appropriate +
  • identify the Recommendation by URL +
  • publish a rationale for the proposal +
  • identify known dependencies + and solicit review from all dependent Working Groups +
  • solicit public review +
  • specify the deadline for review comments, + which must be at least 28 days + after the announcement +
+

and should

+
    +
  • identify known implementations. +
+

If there was any dissent in the Advisory Committee review, + the Team must publish + the substantive content of the dissent to W3C and the public, + and must formally address the dissent + at least 14 days + before publication as an Obsolete or Rescinded Recommendation.

+

The Advisory Committee may initiate an Advisory Committee Appeal of the Team's decision.

+

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. + The updated version may remove the main body of the document. + The Status of this Document section should link + to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

+

Once W3C has published a Rescinded Recommendation, + future W3C technical reports must not include normative references + to that technical report.

+

Note: W3C strives to ensure that all Technical Reports + will continue to be available at their version-specific URL.

+

6.4. The Note Track (Notes and Statements)

+

6.4.1. Group Notes

+

A Group Note (NOTE) + is published + to provide a stable reference for a useful document + that is not intended to be a formal standard.

+

Working Groups, Interest Groups, + the TAG and the AB may publish work as Notes. + Examples include:

+
    +
  • supporting documentation for a specification, + such as explanations of design principles + or use cases and requirements +
  • non-normative guides to good practices +
+

Some Notes are developed through successive Draft Notes before publication as a full Notes, + while others are published directly as a Note. + There are few formal requirements to publish a document as a Note or Draft Note, + and they have no standing as a recommendation of W3C + but are simply documents preserved for historical reference.

+

Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Draft Notes.

+

6.4.2. Publishing Notes

+

In order to publish a Note or Draft Note, + the group:

+
    +
  • must record their decision + to request publication as a Note or Draft Note, and +
  • should publish documentation + of significant changes to the technical report + since any previous publication. +
+

Both Notes and Draft Notes can be updated by republishing + as a Note or Draft Note. + A technical report may remain + a Note indefinitely.

+

If a Note produced by a chartered group is no longer in scope for any group, + the Team may republish the Note with class 1 changes incorporated, + as well as with errata and Team corrections annotated.

+

6.4.3. Elevating Group Notes to W3C Statement status

+

A W3C Statement is a Note that has been endorsed by W3C as a whole. + In order to elevate a Note to W3C Statement status, + A group must:

+ +

A Note specifying implementable technology should not be elevated to W3C Statement status; + if it does, + the request to publish as a Statement must include rationale + for why it should be elevated, + and why it is not on the Recommendation track.

+

Once these conditions are fulfilled, + the Team must then + begin an Advisory Committee Review on the question of + whether the document is appropriate to publish as a W3C Statement. + During this review period, + the Note must not be updated.

+

The decision to advance a document to W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

The Team must announce the publication of a W3C Statement to the Advisory Committee, other W3C groups, and the public.

+

6.4.4. Revising W3C Statements

+

Given a recorded group decision to do so, + groups can request publication of a W3C Statement with editorial changes—including candidate amendment—without any additional process.

+

A candidate amendment can be folded into the main text of the W3C Statement, + once it has satisfied all the same criteria + as the rest of the Statement, + including review by the community to ensure + the substantive and editorial soundness of the candidate amendments. + To validate this, the group must request + an Advisory Committee review of the changes it wishes to incorporate. + The specific candidate amendments under review must be identified as proposed amendments just as in a Last Call for Review of Proposed Corrections.

+

The decision to incorporate proposed amendments into W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

6.5. The Registry Track

+

A registry documents a data set + consisting of one or more associated registry tables, + each table representing an updatable collection + of logically independent, consistently-structured registry entries. + A registry has three associated components:

+ +

The purposes of maintaining a registry can include:

+
+
non-collision +
Avoiding the problem + of two entities using the same value with different semantics. +
non-duplication +
Avoiding the problem + of having two or more different values in use with the same semantics. +
information +
Providing a central index + where anyone can find out + what a value means + and what its formal definition is + (and where it is). +
submission +
Ease of adding new terms, + including by stakeholders external to the custodian organization. +
consensus +
Promoting a clear consensus of the community on the terms. +
+

This section of the W3C Process provides a specialized process + facilitating the publication and maintenance of such registry tables, + particularly those required by or closely related to W3C Recommendations.

+

Note: Not every table in a specification is a potential registry. + If the intent or effect is that the table enumerates + all the possibilities the authors of the specification expect or envisage, + then the table by itself is enough. + Similarly, if the table is managed by the Working Group + and only updated as part of specification update, + then the complexities of registry management are not needed.

+

6.5.1. Registry Definitions

+

A registry definition defines what each registry table is and how it is maintained. + It must:

+
    +
  • Define the scope and purpose of each registry table. +
  • Define the fields of each registry table and their constraints + (e.g. values must be drawn from a defined set, or be unique, + or only reference publicly available resources, + etc.) +
  • + Define the policy for changes to existing entries, such as +
      +
    • whether entries can be deleted or deprecated +
    • whether entries can be changed after being published, and what kinds of changes are allowed +
    • whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely +
    +
  • Define the method and criteria by which changes are proposed, approved, and incorporated. + (For example, a registry could define + that changes to registry entries can be proposed using a particular web form or email address, + that they must be accompanied by certain background information, + or that they do or do not need to be approved by any member of a particular Working Group.) +
  • + Identify the custodian of the registry table: + the entity to which requests for registry changes must be sent, + and which is responsible for evaluating whether such requests + satisfy the criteria defined in the registry definition. +

    The custodian may be the Working Group, the Team, or a delegated entity. + The custodian for all registry tables in a single registry should generally be the same entity.

    +
+

6.5.2. Publishing Registries

+

Registries can be published either + as a stand-alone technical report on the Registry Track called a registry report, + or incorporated as part of a Recommendation as a registry section.

+

A registry report or registry section is purely documentational, + is not subject to the W3C Patent Policy, + and must not contain any requirements on implementations. + For the purposes of the Patent Policy [PATENT-POLICY], + any registry section in a Recommendation track document + is not a normative portion of that specification.

+

The registry report or registry section must:

+ +

The Team must make available + a means for interested parties to be notified of any updates to a registry table.

+

Note: Since the Process does not impose requirements + on changes to the contents of a registry table other than those imposed by the registry definition, + acceptance of proposed registry changes on behalf of the custodian and + publication of an updated registry report that contains + only registry changes since the previous publication + can be automated + if satisfaction of those rules can be automatically verified.

+

Rules for publication and advancement on the Registry Track are identical to that of the Recommendation Track with the following exceptions:

+ +

6.5.3. Updating Registry Tables

+

Changes to the contents of a registry table that are in accordance with the registry definition, + (i.e. Class 5 changes) + can be made by re-publishing the technical report that contains the affected table, + without needing to satisfy any other requirements for the publication + (not even Working Group consensus, unless this is required by the registry definition). + Such registry changes do not trigger new Advisory Committee Reviews, + nor Exclusion Opportunities, + and do not require approval via an update request, + even for technical reports at maturities where this would normally be expected. + Such publications can be made + even in the absence of a Working Group chartered to maintain the registry + when the custodian is another entity.

+

Note: The custodian is only empowered to make registry changes. + If the Working Group establishing the registry wishes + to empower the custodian to add commentary on individual entries, + this needs to be part of the registry table’s defintion. + If other changes are desired, + they must be requested of the responsible Working Group—or in the absence of a Working Group, of the Team.

+

Changes to the registry tables made in accordance with candidate or proposed amendments to the registry definition which would not be allowed by the unamended registry definition must be identified as such.

+

6.5.4. Registry Data Reports

+

When the registry data is published in a separate technical report from its registry definition, + that report is called a Registry Data Report. + This technical report:

+ +

Registry Data Reports do not have maturity levels in and of themselves; + The maturity level of the registry whose data they record + is that of the technical report holding the registry definition.

+

Anytime a change is made to a registry definition, + the Working Group must update and republish + any document holding the corresponding registry tables to make it consistent with these changes.

+

Given a recorded group decision to do so, + the Working Group may republish the Registry Data Report to incorporate editorial changes. + If there is no Working Group chartered to maintain this registry, + the Team may do so instead.

+

6.5.5. Specifications that Reference Registries

+

Registries document values, + they do not define any architectural or interoperability requirements + related to those values. + All architectural and interoperability requirements + pertaining to registry entries must be contained in the specifications that reference the registry, + and are therefore subject to the processes + (including approval and intellectual property provisions) + applicable to those referencing specifications.

+

If there are entries that must be implemented, + or any other such restrictions, + they must be defined or documented + in the referencing specification + without dependency on the registry.

+
For example, + “All implementations must implement the Basic-Method as defined in the registry” + is not acceptable; + a change to the definition of the Basic-Method in the registry would then affect conformance. + Instead, the requirement must be complete in the specification, + directly or by reference to another specification. + For example + “All implementations must recognize the name Basic-Method, + and implement it as defined by section yy of IETF RFC xxxx”. + (The Registry should nonetheless contain Basic-Method as an entry.)
+

6.6. Switching Tracks

+

Given a Group decision to do so, Working Groups can republish a technical report on a different track than the one it is on, + under the following restrictions:

+ +

Technical reports that switch tracks start at + their new track’s initial maturity level, + while retaining any established identity (url, shortname, etc.).

+

6.7. Further reading

+

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews + and announcements of the various steps, + and tips on getting to Recommendation faster [REC-TIPS]. + Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

+

7. Dissemination Policies

+

7.1. Public Communication

+

The Team is responsible for managing communication within W3C + and with the general public + (e.g., news services, press releases, managing the Web site and access privileges, and managing calendars). + Members should solicit review by the Team + prior to issuing press releases about their work within W3C.

+

The Team makes every effort to ensure the persistence and availability of the following public information:

+ +

To keep the Members abreast of W3C meetings, Workshops, + and review deadlines, + the Team provides them with a regular (e.g., weekly) news service + and maintains a calendar [CALENDAR] of official W3C events. + Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

+

7.2. Confidentiality Levels

+

There are three principal levels of access to W3C information + (on the W3C Web site, in W3C meetings, etc.): + public, + Member-only, + and Team-only.

+

While much information made available by W3C is public, + “Member-only” information + is available to authorized parties only, + including representatives of Member organizations, Invited Experts, + the Advisory Board, + the TAG, + and the Team. + For example, + the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

+

“Team-only” information + is available to the Team and other authorized parties.

+

Those authorized to access Member-only and Team-only information:

+
    +
  • must treat the information as confidential within W3C, +
  • must use reasonable efforts to maintain the proper level of confidentiality, and +
  • must not release this information to the general public or press. +
+

The Team must provide mechanisms + to protect the confidentiality of Member-only information + and ensure that authorized parties have proper access to this information. + Documents should clearly indicate + whether they require Member-only confidentiality. + Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

+

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member + who are considered appropriate recipients. + For instance, + it is the responsibility of the Advisory Committee representative and other employees + and official representatives of the organization + to ensure that Member-only news announcements + are distributed for internal use only within their organization. + Information about Member mailing lists is available + in the New Member Orientation [INTRO].

+

7.3. Changing Confidentiality Level

+

As a benefit of membership, + W3C provides some Team-only and Member-only channels + for certain types of communication. + For example, Advisory Committee representatives can send reviews to a Team-only channel. + However, for W3C processes with a significant public component, + such as the technical report development process, + it is also important for information that affects decision-making to be publicly available. + The Team may need to communicate Team-only information to a Working Group or the public. + Similarly, a Working Group whose proceedings are Member-only must make public + information pertinent to the technical report development process.

+

This document clearly indicates which information must be available to Members or the public, + even though that information was initially communicated on Team-only or Member-only channels. + Only the Team and parties authorized by the Team + may change the level of confidentiality of this information. + When doing so:

+
    +
  1. The Team must use a version of the information + that was expressly provided by the author for the new confidentiality level. + In Calls for Review and other similar messages, + the Team should remind recipients to provide such alternatives. +
  2. The Team must not attribute the version + for the new confidentiality level to the author without the author’s consent. +
  3. If the author has not conveyed to the Team a version + that is suitable for another confidentiality level, + the Team may make available a version that reasonably communicates what is required, + while respecting the original level of confidentiality, + and without attribution to the original author. +
+

8. Workshops and Symposia

+

The Team organizes Workshops and Symposia to promote early involvement in the development of W3C activities + from Members and the public.

+

The goal of a Workshop is usually + either to convene experts and other interested parties for an exchange of ideas + about a technology or policy, + or to address the pressing concerns of W3C Members. + Organizers of the first type of Workshop may solicit position papers for the Workshop program + and may use those papers + to choose attendees and/or presenters.

+

The goal of a Symposium is usually + to educate interested parties about a particular subject.

+

The Call for Participation in a Workshop or Symposium may indicate participation requirements or limits, + and expected deliverables + (e.g., reports and minutes). + Organization of an event does not guarantee + further investment by W3C in a particular topic, + but may lead to proposals for new activities or groups.

+

Workshops and Symposia generally last one to three days. + If a Workshop is being organized to address the pressing concerns of Members, + the Team must issue the Call for Participation + no later than six weeks prior to the Workshop’s scheduled start date. + For other Workshops and Symposia, + the Team must issue a Call for Participation + no later than eight weeks prior to the meeting’s scheduled start date. + This helps ensure that speakers and authors + have adequate time to prepare position papers and talks.

+

9. Liaisons

+

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, + through a number of mechanisms + ranging from very informal + (e.g., an individual from another organization participates in a W3C Working Group, + or just follows its work) + to mutual membership, + to even more formal agreements. + Liaisons are not meant to substitute for W3C membership.

+

All liaisons must be coordinated by the Team due to requirements for public communication; + patent, + copyright, + and other IPR policies; + confidentiality agreements; + and mutual membership agreements.

+

The CEO may negotiate + a Memorandum of Understanding with another organization. + For the purposes of the W3C Process a Memorandum of Understanding (MoU) + is a formal agreement or similar contractual framework between W3C and another party or parties, + other than agreements between the Hosts or between Hosts and W3C members + for the purposes of membership + and agreements related to the ordinary provision of services + for the purposes of running W3C, + that specifies rights and obligations of each party toward the others. + These rights and obligations may include joint deliverables, + an agreed share of technical responsibilities with due coordination, + and/or considerations for confidentiality and specific IPR. + The agreement may be called something other than a “Memorandum of Understanding”, + and something called a “Memorandum of Understanding” + may not be an MoU for the purposes of the Process.

+

Before signing the MoU, + the Team must inform + the Advisory Committee of the intent to sign + and make the MoU available for Advisory Committee review; Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the MoU. + Unless an appeal rejects the proposal to sign an MoU, + the CEO may sign the MoU on behalf of W3C. + A signed Memorandum of Understanding should be made public.

+

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

+

10. Member Submission Process

+

The Member Submission process allows Members + to propose technology + or other ideas + for consideration by the Team. + After review, + the Team may make the material available at the W3C Web site. + The formal process affords Members a record of their contribution + and gives them a mechanism for disclosing the details of the transaction with the Team + (including IPR claims). + The Team also makes review comments on the Submitted materials available for W3C Members, + the public, + and the media.

+

A Member Submission consists of:

+
    +
  • One or more documents developed outside of the W3C process, and +
  • Information about the documents, + provided by the Submitter. +
+

One or more Members (called the Submitter(s)) may participate in a Member Submission. + Only W3C Members may be listed as Submitters.

+

The Submission process consists of the following steps:

+
    +
  1. One of the Submitters sends a request to the Team to acknowledge the Submission request. + The Team and Submitter(s) communicate to ensure that the Member Submission is complete. +
  2. + After review, the Team must either + acknowledge or reject the Submission request. + +
+
+ Note: To avoid confusion about the Member Submission process, please note that: + +
+

Making a Member Submission available at the W3C Web site + does not imply endorsement by W3C, + including the W3C Team or Members. + The acknowledgment of a Submission request + does not imply that any action will be taken by W3C. + It merely records publicly + that the Submission request has been made by the Submitter. + A Member Submission made available by W3C must not be referred to as “work in progress” of W3C.

+

The list of acknowledged Member Submissions [SUBMISSION-LIST] is available at the W3C Web site.

+

10.1. Submitter Rights and Obligations

+

When more than one Member jointly participates in a Submission request, + only one Member formally sends in the request. + That Member must copy + each of the Advisory Committee representatives of the other participating Members, + and each of those Advisory Committee representatives must confirm + (by email to the Team) + their participation in the Submission request.

+

At any time prior to acknowledgment, + any Submitter may withdraw support for a Submission request + (described in "How to send a Submission request" [SUBMISSION-REQ]). + A Submission request is “withdrawn” when no Submitter(s) support it. + The Team must not make statements + about withdrawn Submission requests.

+

Prior to acknowledgment, + the Submitter(s) must not, under any circumstances, + refer to a document as “submitted to the World Wide Web Consortium” + or “under consideration by W3C” or any similar phrase + either in public or Member communication. + The Submitter(s) must not imply + in public or Member communication + that W3C is working (with the Submitter(s)) on the material in the Member Submission. + The Submitter(s) may release the documents in the Member Submission to the public + prior to acknowledgment + (without reference to the Submission request).

+

After acknowledgment, + the Submitter(s) must not, under any circumstances, + imply W3C investment in the Member Submission + until, and unless, the material has been adopted as a deliverable + of a W3C Working Group.

+

10.1.1. Scope of Member Submissions

+

When a technology overlaps in scope with the work of a chartered Working Group, + Members should participate in the Working Group and contribute the technology to the group’s process + rather than seek publication through the Member Submission process. + The Working Group may incorporate the contributed technology into its deliverables. + If the Working Group does not incorporate the technology, + it should not publish the contributed documents + as Working Group Notes since Working Group Notes represent group output, + not input to the group.

+

On the other hand, + while W3C is in the early stages of developing a charter, + Members should use the Submission process + to build consensus around concrete proposals for new work.

+

Members should not submit materials + covering topics well outside the scope of W3C’s mission [MISSION].

+

10.1.2. Information Required in a Submission Request

+

The Submitter(s) + and any other authors of the submitted material must agree that, + if the request is acknowledged, + the documents in the Member Submission will be subject to the W3C Document License [DOC-LICENSE] and will include a reference to it. + The Submitter(s) may hold the copyright for the documents in a Member Submission.

+

The request must satisfy the Member Submission licensing commitments + in “Licensing Commitments in W3C Submissions” + in the W3C Patent Policy [PATENT-POLICY].

+

The Submitter(s) must include the following information:

+
    +
  • The list of all submitting Members. +
  • Position statements from all submitting Members (gathered by the Submitter). + All position statements must appear in a separate document. +
  • Complete electronic copies of any documents submitted for consideration + (e.g., a technical specification, + a position paper, + etc.) + If the Submission request is acknowledged, + these documents will be made available by W3C + and therefore must satisfy the Team’s Publication Rules [PUBRULES]. Submitters may hold the copyright for the material contained in these documents, + but when made available by W3C, + these documents must be subject to the provisions + of the W3C Document License [DOC-LICENSE]. +
+

The request must also answer the following questions.

+
    +
  • What proprietary technology is required to implement the areas addressed by the request, + and what terms are associated with its use? + Again, many answers are possible, + but the specific answer will affect the Team’s Decision. +
  • What resources, if any, + does the Submitter intend to make available + if W3C acknowledges the Submission request + and takes action on it? +
  • What action would the Submitter like W3C to take + if the Submission request is acknowledged? +
  • What mechanisms are there to make changes to the specification being submitted? + This includes, but is not limited to, + stating where change control will reside + if the request is acknowledged. +
+

For other administrative requirements related to Submission requests, + see “How to send a Submission request” [MEMBER-SUB].

+

10.2. Team Rights and Obligations

+

Although they are not technical reports, + the documents in a Member Submission must fulfil the requirements established by the Team, + including the Team’s Publication Rules [PUBRULES].

+

The Team sends a validation notice to the Submitter(s) + once the Team has reviewed a Submission request + and judged it complete and correct.

+

Prior to a decision to acknowledge or reject the request, + the request is Team-only, + and the Team must hold it in the strictest confidentiality. + In particular, + the Team must not comment to the media + about the Submission request.

+

10.3. Acknowledgment of a Submission Request

+

The Team acknowledges a Submission request + by sending an announcement to the Advisory Committee. + Though the announcement may be made at any time, + the Submitter(s) can expect an announcement between four to six weeks after the validation notice. + The Team must keep the Submitter(s) informed + of when an announcement is likely to be made.

+

Once a Submission request has been acknowledged, + the Team must:

+
    +
  • Make the Member Submission available at the W3C Web site. +
  • Make the Team comments about the Submission request available at the W3C Web site. +
+

If the Submitter(s) wishes to modify + a document made available as the result of acknowledgment, + the Submitter(s) must start the Submission process from the beginning, + even just to correct editorial changes.

+

10.4. Rejection of a Submission Request, and Submission Appeals

+

The Team may reject a Submission request + for a variety of reasons, + including any of the following:

+
    +
  • The ideas expressed in the request + overlap in scope with the work of a chartered Working Group, + and acknowledgment might jeopardize the progress of the group. +
  • The IPR statement made by the Submitter(s) is inconsistent with the W3C’s + Patent Policy [PATENT-POLICY] and in particular the “Licensing Commitments in W3C Submissions”, Document License [DOC-LICENSE], + or other IPR policies. +
  • The ideas expressed in the request are poor, + might harm the Web, + or run counter to W3C’s mission [MISSION]. +
  • The ideas expressed in the request lie well outside the scope of W3C’s mission. +
+

In case of a rejection, + the Team must inform the Advisory Committee representative(s) + of the Submitter(s). + If requested by the Submitter(s), + the Team must provide rationale + to the Submitter(s) about the rejection. + Other than to the Submitter(s), + the Team must not make statements about why a Submission request was rejected.

+

The Advisory Committee representative(s) of the Submitters(s) may initiate a Submission Appeal + of the Team’s Decision to the TAG if the reasons are related to Web architecture, + or to the Advisory Board if the request is rejected for other reasons. + In this case the Team should make available + its rationale for the rejection to the appropriate body. + The Team will establish a process for such appeals + that ensures the appropriate level of confidentiality.

+

11. Process Evolution

+

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, + with the Advisory Board—acting as the sponsoring Working Group. + The documents may be developed by the AB or by another group to whom the AB has delegated development. + Review includes + soliciting input from the W3C community, + and in particular the Team.

+

The documents covered by this section are:

+
    +
  • +

    the W3C Process (this document)

    +
  • +

    the W3C Patent Policy [PATENT-POLICY]

    +
  • +

    the W3C Code of Ethics and Professional Conduct [CEPC]

    +
  • +

    The W3C Document License [DOC-LICENSE]

    +
+

The Advisory Board initiates review as follows:

+
    +
  1. The Team sends a Call for Review to the Advisory Committee and other W3C groups. +
  2. After comments have been formally addressed and the document possibly modified, + the Team seeks endorsement from the Members by initiating an Advisory Committee review. + The review period must last at least 28 days. +
  3. After the Advisory Committee review, + following a W3C decision to adopt the document(s), + the Team does so + and sends an announcement to the Advisory Committee. + Advisory Committee representatives may initiate + an Advisory Committee Appeal to W3C. +
+

Note: As of June 2020, + the Patent Policy is developed in the Patents and Standards Interest Group, + the Code of Ethics and Professional Conduct in the Positive Work Environment Community Group, + and the Process in the W3C Process Community Group.

+

12. Acknowledgments

+

This section is non-normative.

+

The editors are grateful to the following people, + who as interested individuals and/or with the affiliation(s) listed, + have contributed to this proposal for a revised Process: + Brian Kardell, + Carine Bournez (W3C), + Charles McCathie Nevile (ConsenSys), + Chris Wilson (Google), + David Singer (Apple), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Elika J. Etemad aka fantasai, + Fuqiao Xue (W3C), + Jeff Jaffe (W3C), + Kevin Fleming (Bloomberg), + Léonie Watson (The Paciello Group), + Michael Champion (Microsoft), + Nigel Megitt (BBC), + Philippe Le Hégaret (W3C), + Ralph Swick (W3C), + Samuel Weiler (W3C), + Sandro Hawke (W3C), + Shawn Lawton Henry, + Tantek Çelik (Mozilla), + Virginia Fournier (Apple), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

The editors are sorry for forgetting any names, + and grateful to those who have listened patiently to conversations about this document + without feeling a need to add more.

+

The following individuals contributed to the development of earlier versions of the Process: + Alex Russell (Google), + Andreas Tai (Institut fuer Rundfunktechnik), + Andrew Betts (Fastly), + Ann Bassetti (The Boeing Company), + Anne van Kesteren, + Art Barstow (Nokia, unaffiliated), + Bede McCall (MITRE), + Ben Wilson, + Brad Hill (Facebook), + Brian Kardell (JQuery), + Carine Bournez (W3C), + Carl Cargill (Netscape, Sun Microsystems, Adobe), + Chris Lilley (W3C), + Chris Wilson (Google), + Claus von Riegen (SAP AG), + Coralie Mercier (W3C), + Cullen Jennings (Cisco), + Dan Appelquist (Telefonica, Samsung), + Dan Connolly (W3C), + Daniel Dardailler (W3C), + Daniel Glazman (Disruptive Innovations), + David Baron (Mozilla), + David Fallside (IBM), + David Singer (Apple), + David Singer (IBM), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Don Brutzman (Web3D), + Don Deutsch (Oracle), + Eduardo Gutentag (Sun Microsystems), + Elika J. Etemad aka fantasai, + Florian Rivoal, + Fuqiao Xue (W3C), + Geoffrey Creighton (Microsoft), + Geoffrey Snedden, + Giri Mandyam (Qualcomm), + Gregg Kellogg, + Hadley Beeman, + Helene Workman (Apple), + Henri Sivonen (Mozilla), + Håkon Wium Lie (Opera Software), + Ian Hickson (Google), + Ian Jacobs (W3C), + Ivan Herman (W3C), + J Alan Bird (W3C), + Jay Kishigami 岸上順一 (NTT), + Jean-Charles Verdié (MStar), + Jean-François Abramatic (IBM, ILOG, W3C), + Jeff Jaffe (W3C), + Jim Bell (HP), + Jim Miller (W3C), + Joe Hall (CDT), + John Klensin (MCI), + Josh Soref (BlackBerry, unaffiliated), + Judy Brewer (W3C), + Judy Zhu 朱红儒 (Alibaba), + Kari Laihonen (Ericsson), + Karl Dubost (Mozilla), + Ken Laskey (MITRE), + Kevin Fleming (Bloomberg), + Klaus Birkenbihl (Fraunhofer Gesellschaft), + Larry Masinter (Adobe Systems), + Lauren Wood (unaffiliated), + Liam Quin (W3C), + Léonie Watson (The Paciello Group), + Marcos Cáceres (Mozilla), + Maria Courtemanche (IBM), + Mark Crawford (SAP), + Mark Nottingham, + Michael Champion (Microsoft), + Michael Geldblum (Oracle), + Mike West (Google), + Mitch Stoltz (EFF), + Natasha Rooney (GSMA), + Nigel Megitt (BBC), + Olle Olsson (SICS), + Ora Lassila (Nokia), + Paul Cotton (Microsoft), + Paul Grosso (Arbortext), + Peter Linss, + Peter Patel-Schneider, + Philippe Le Hégaret (W3C), + Qiuling Pan (Huawei), + Ralph Swick (W3C), + Renato Iannella (IPR Systems), + Rigo Wenning (W3C), + Rob Sanderson (J Paul Getty Trust), + Robin Berjon (W3C), + Sally Khudairi (W3C), + Sam Ruby (IBM), + Sandro Hawke (W3C), + Sangwhan Moon (Odd Concepts), + Scott Peterson (Google), + Steve Holbrook (IBM), + Steve Zilles (Adobe Systems) + Steven Pemberton (CWI), + TV Raman (Google), + Tantek Çelik (Mozilla), + Terence Eden (Her Majesty’s Government), + Thomas Reardon (Microsoft), + Tim Berners-Lee (W3C), + Tim Krauskopf (Spyglass), + Travis Leithead (Microsoft), + Virginia Fournier (Apple), + Virginie Galindo (Gemalto), + Wayne Carr (Intel), + Wendy Fong (Hewlett-Packard), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

13. Changes

+

This section is non-normative.

+

Changes since the 2 November 2021 Process

+

This document is based on the 2 November 2021 Process. + A list of issues addressed, + a diff from Process 2021 to this latest version, + as well as + a detailed log of all changes since then are available.

+

The following is a summary of the main differences:

+
+
Changes related to the role of the Director +
+ +
Other miscellaneous changes +
+
    +
  • Allow Recommendations to transition directly to Working Draft without having to go through Candidate Recommendation when making substantive changes. +
  • Stop excluding comments from AC Reps from those that have to be addressed + while transitioning to Proposed Recommendation; + just because there will be an opportunity to address them later + doesn’t mean they shouldn’t be handled at the first opportunity. +
  • Various bits of information that were so far required + to be included in announcements of charter extensions + are covered in the group’s homepage, + making it sufficient to point to that page + rather than having to inline everything in the announcement. +
+
+

Changes since earlier versions

+

Changes since earlier versions of the Process are detailed + in the changes section of the previous version of the Process.

+
+
+

Conformance

+

Document conventions

+

Conformance requirements are expressed + with a combination of descriptive assertions + and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text + with class="example", + like this:

+
+ +

This is an example of an informative example.

+
+

Informative notes begin with the word “Note” + and are set apart from the normative text + with class="note", + like this:

+

Note, this is an informative note.

+

Conformant Algorithms

+

Requirements phrased in the imperative as part of algorithms + (such as "strip any leading space characters" + or "return false and abort these steps") + are to be interpreted with the meaning of the key word + ("must", "should", "may", etc) + used in introducing the algorithm.

+

Conformance requirements phrased as algorithms or specific steps + can be implemented in any manner, + so long as the end result is equivalent. + In particular, the algorithms defined in this specification + are intended to be easy to understand + and are not intended to be performant. + Implementers are encouraged to optimize.

+
+ +
+

Index

+

Terms defined by this specification

+ + +

Terms defined by reference

+ +

References

+

Normative References

+
+
[CEPC] +
W3C Code of Ethics and Professional Conduct. URL: https://www.w3.org/Consortium/cepc/ +
[COLLABORATORS-AGREEMENT] +
Invited expert and collaborators agreement. URL: https://www.w3.org/Consortium/Legal/collaborators-agreement +
[CONFLICT-POLICY] +
Conflict of Interest Policy for W3C Team Members Engaged in Outside Professional Activities. URL: https://www.w3.org/2000/09/06-conflictpolicy +
[DOC-LICENSE] +
W3C Document License. URL: https://www.w3.org/Consortium/Legal/copyright-documents +
[PATENT-POLICY] +
The W3C Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy/ +
[PATENT-POLICY-2004] +
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/ +
[PATENT-POLICY-2020] +
The W3C 2020 Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy-20200915/ +
[PUBRULES] +
Publication Rules. URL: https://www.w3.org/pubrules/ +
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
[RFC3797] +
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://www.rfc-editor.org/rfc/rfc3797 +
[W3C-PATENT-POLICY] +
Wendy Seltzer. W3C Patent Policy. 15 September 2020. URL: https://www.w3.org/Consortium/Patent-Policy/ +
+

Informative References

+
+
[AB-HP] +
The Advisory Board home page. URL: https://www.w3.org/2002/ab/ +
[AC-MEETING] +
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/Member/Meeting/ +
[BG-CG] +
Community and Business Group Process. URL: https://www.w3.org/community/about/process/ +
[CALENDAR] +
Calendar of all scheduled official W3C events. URL: https://www.w3.org/participate/eventscal +
[CHAIR] +
W3C Working/Interest Group Chair. URL: https://www.w3.org/Guide/chair/role.html +
[CHARTER] +
How to Create a Working Group or Interest Group. URL: https://www.w3.org/Guide/process/charter.html +
[CURRENT-AC] +
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList +
[ELECTION-HOWTO] +
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/2002/10/election-howto +
[FELLOWS] +
W3C Fellows Program. URL: https://www.w3.org/Consortium/Recruitment/Fellows +
[GROUP-MAIL] +
Group mailing lists. URL: https://www.w3.org/groups/ +
[GUIDE] +
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/Guide/ +
[INTRO] +
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro +
[JOIN] +
How to Join W3C. URL: https://www.w3.org/Consortium/join +
[LIAISON] +
W3C liaisons with other organizations. URL: https://www.w3.org/2001/11/StdLiaison +
[MEMBER-AGREEMENT] +
W3C Membership Agreement. URL: https://www.w3.org/Consortium/Agreement/Member-Agreement +
[MEMBER-HP] +
Member Web site (Member-only access). URL: https://www.w3.org/Member/ +
[MEMBER-LIST] +
The list of current W3C Members. URL: https://www.w3.org/Consortium/Member/List +
[MEMBER-SUB] +
How to send a Submission request. URL: https://www.w3.org/2000/09/submission +
[MISSION] +
The W3C Mission statement. URL: https://www.w3.org/Consortium/mission +
[OBS-RESC] +
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/2016/11/obsoleting-rescinding/ +
[REC-TIPS] +
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/2002/05/rec-tips +
[REPUBLISHING] +
In-place modification of W3C Technical Reports. URL: https://www.w3.org/2003/01/republishing/ +
[SUBMISSION-LIST] +
The list of acknowledged Member Submissions. URL: https://www.w3.org/Submission/ +
[SUBMISSION-REQ] +
Make or Withdraw a Member Submission Request (Member-only access). URL: https://www.w3.org/2000/09/submission +
[TAG-CHARTER] +
Technical Architecture Group (TAG) Charter. URL: https://www.w3.org/2004/10/27-tag-charter.html +
[TAG-HP] +
The TAG home page. URL: https://www.w3.org/2001/tag/ +
[TEAM-CONTACT] +
Role of the Team Contact. URL: https://www.w3.org/Guide/teamcontact/role.html +
[TR] +
The W3C technical reports index. URL: https://www.w3.org/TR/ +
[TRANSITION] +
Organize a Technical Report Transition. URL: https://www.w3.org/Guide/transitions +
[TRANSLATION] +
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/snapshots/2023-04-faq.html b/snapshots/2023-04-faq.html new file mode 100644 index 00000000..4441e8f5 --- /dev/null +++ b/snapshots/2023-04-faq.html @@ -0,0 +1,259 @@ + + + + + + +Process 2023 FAQ + +
+

+

Process 2023 FAQ

+

+

Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply. +

+
+ + + +

+1. +Why a Council and not some other option?

+ +

+ Various other options were considered, + but all were found to have more downsides than a Council-based approach. + Among the many variants discussed, the following are notable: + +

+ +

+ We combined the AB (process expertise) and TAG (technical expertise), + who are both AC-elected (community legitimacy) + with the CEO (to represent the Team perspective) + to create the Council, + with the intention that this 21-person combined team would sufficiently balance itself out + to provide high quality resolution of FOs consistent with the values of W3C. + +

+2. +Why (group-voted) dismissal rather than (self-chosen or automatic) recusal?

+ +

+ There are a few problems with recusals: +

+ +

+ Lastly, we've found through our experiences in the experimental Councils + that the Council process works quite well in practice: + in every instance where some participants in the Council could be seen as having a strong stake in the decision, + they were deliberately deferential, + and contributed their perspective to the debate without any attempt at steering the group in a particular direction. + +

+3. +Why has the Council been so awfully slow?

+ +

+ The AB, TAG, and Team apologize for the delays, + and recognize the need to do better. + We’ve been learning, making mistakes, and improving, + and anticipate a faster response time going ahead. + +

+ The Council was introduced as an experiment under delegation from the Director, + and has been evolving over the duration of the experiment. + While it started slow, a number of things have changed to make it faster. + +

+ +

+ It is also worth noting that a large part of the Council experiment period + overlapped with the ramp up to the launch of W3C as a legal entity, + during which both the AB and the Team were overloaded with important and urgent matters, + leaving less time that would have otherwise been appropriate for Formal Objection resolution. + +

+4. +What about chartering?

+ +

+ Formally, the Director has been in charge of initiating AC Review of new charters + and interpreting the results. + In practice, + this task has been long been delegated to the Team. + Therefore what this Process proposal encodes + is merely the practice we've been running under for years: + that the Team initiates charter reviews, + and abides by the results of AC reviews. + We have, however, tightened up how AC reviews are conducted + and what outcomes may come of them. + +

+ There is a clear sense that more transparency and Member involvement in chartering is desired, + and the Team is making improvements in this direction informally + through changes in their practices and guidelines. + However, we weren't ready yet to make additional concrete changes to the Process itself for 2023 + (though we anticipate this discussion to continue into a future Process revision cycle). + +

For now, the proposed Process, + aside from recognizing that it is the Team, + not the Director, + that moves chartering along, + is not different from current practice, + and thus no worse. + +

+5. +What about a NomComm for the TAG?

+ +

+ Diversity and representation are considered especially important in the TAG, + to ensure an ability to handle any technical topic from any industry. + Some proposed that using a Nominating Committee (NomComm) would be a good way to accomplish that, + and an earlier revision of the Director-free Process did in fact have a NomComm + randomly selected (mostly) from the set of WG chairs. + However the TAG felt this was too complicated + (and it was, in fact, quite complicated + once all the details were worked in), + and asked the AB to simply have the Team make the appointments with the input of the community. + This enables the kind of deliberate balancing that a NomComm would provide + and avoids a lot of complexity + +

+ As a safety measure, + we added a 2/3 ratification step by both the TAG and the AB + to ensure the Team appointments are acceptable to the community; + and a term limit of two consecutive appointments to ensure the Team doesn't simply re-appoint old members as a habit. + +

+ Note the TAG appointment process has also been moved to be after the election, + in order to allow the appointments to serve their intended purpose of balancing out the elected TAG. diff --git a/snapshots/2023-04.html b/snapshots/2023-04.html new file mode 100644 index 00000000..09958634 --- /dev/null +++ b/snapshots/2023-04.html @@ -0,0 +1,7318 @@ + + + + + W3C Process Document + + + + + + + + + + + + + + + + +

+

+

W3C Process Document

+

Draft Community Group Report,

+
+ More details about this document +
+
+
This version: +
https://www.w3.org/Consortium/Process/Drafts/snapshots/2023-04 +
Latest published version: +
https://www.w3.org/Consortium/Process/ +
Previous Versions: +
+
+
+
+
+
Feedback: +
Github (preferred) +
Public mailing list +
Member-only mailing list +
Editors: +
Elika J. Etemad / fantasai (Invited Expert) +
Florian Rivoal (Invited Expert) +
Former Editors: +
Natasha Rooney (Invited Expert) +
Charles McCathie Nevile (Yandex) +
Ian Jacobs (W3C) +
+
+
+
+

Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

+
+
+
+

Abstract

+

The mission of the World Wide Web Consortium (W3C) is to lead the World Wide Web to its full potential + + by developing common protocols that promote its evolution and ensure its interoperability. + The W3C Process Document describes the organizational structure of W3C and processes, + responsibilities and functions that enable W3C to accomplish its mission. + This document does not describe the internal workings of the Team.

+

For more information about the W3C mission and the history of W3C, + + please refer to About W3C.

+
+

Status of this document

+
+

W3C, including all existing chartered groups, + follows the most recent operative Process Document announced to the Membership.

+

This document is developed by the Advisory Board’s Process Task Force + working within the W3C Process Community Group (which anyone can join). + This is the 7 April 2023 Draft Community Group Report for the proposed next version of the W3C Process Document.

+

This document, + +which is based on the 2 November 2021 Process, +is offered for W3C Advisory Committee Review of the proposal to adopt this +as the new operative Process document +per Section 11 Process Changes.

+

+

A history of substantial changes from previous versions of the Process Document is provided.

+
+
+ +
+

Relation of Process Document to Patent Policy and Other Policies

+

W3C Members' attention is called to the fact + that provisions of the Process Document are binding on Members + per the Membership Agreement [MEMBER-AGREEMENT]. + The W3C Patent Policy [PATENT-POLICY] and other policies + incorporated by normative reference as a part of the Process Document + are equally binding.

+

The Patent Policy and CEPC place additional obligations on Members, Team, and other participants in W3C. + The Process Document does not restate those requirements but includes references to them. + The Process Document, Patent Policy, and CEPC have been designed to allow each to evolve independently.

+

In the Process Document, the term “participant” refers to an individual, not an organization.

+

Conformance and specialized terms

+

The terms must, must not, should, should not, required, + and may are used in accordance with RFC 2119. + The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

+

Some terms have been capitalized in this document (and in other W3C materials) + to indicate that they are entities with special relevance to the W3C Process. + These terms are defined within this document, + and readers are reminded that the ordinary English definitions are insufficient + for the purpose of understanding this document.

+ +
+

1. Introduction

+

W3C work revolves around the standardization of Web technologies. + To accomplish this work, W3C follows processes that promote the development of high-quality standards + based on the consensus of the Membership, Team, and public. + W3C processes promote fairness, responsiveness, and progress: + all facets of the W3C mission. + This document describes the processes W3C follows in pursuit of its mission.

+

The W3C Process promotes the goals of quality and fairness in technical decisions + by encouraging consensus, + soliciting reviews (by both Members and public), + incorporating implementation and interoperability experience, + and requiring Membership-wide approval as part of the technical report development process. Participants in W3C include representatives of its Members and the Team, + as well as Invited Experts who can bring additional expertise or represent additional stakeholders. Team representatives both contribute to the technical work + and help ensure each group’s proper integration with the rest of W3C.

+

W3C’s technical standards, called W3C Recommendations, + are developed by its Working Groups; + W3C also has other types of publications, + all described in § 6 W3C Technical Reports. + W3C has various types of groups; + this document describes the formation and policies + of its chartered Working Groups and Interest Groups, + see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. + W3C also operates Community and Business Groups, + which are separately described in their own process document [BG-CG].

+

In addition, several groups are formally established by the Consortium: + the W3C Advisory Committee, which has a representative from each Member, + and two oversight groups elected by its membership: + the Advisory Board (AB), + which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process; + and the Technical Architecture Group (TAG), + which helps resolve Consortium-wide technical issues.

+

Here is a general overview of how W3C initiates standardization of a Web technology:

+
    +
  1. People generate interest in a particular topic. + For instance, Members express interest by developing proposals in Community Groups + or proposing ideas in Member Submissions. + Also, the Team monitors work inside and outside of W3C for signs of interest, + and helps organize Workshops to bring people together + to discuss topics that interest the W3C community. +
  2. When there is enough interest and an engaged community, + the Team works with the Membership + to draft proposed Interest Group or Working Group charters. + W3C Members review the proposed charters, + and when there is support within W3C for investing resources in the topic of interest, + W3C approves the group(s), + and they begin their work. +
+

Further sections of this Process Document deal with topics including + liaisons (§ 9 Liaisons), + confidentiality (§ 7 Dissemination Policies), + and formal decisions and appeals (§ 5 Decisions).

+

2. Members and the Team

+

W3C’s mission is to lead the Web to its full potential. + W3C Member organizations provide resources to this end, + and the W3C Team provides the technical leadership + and organization to coordinate the effort.

+

2.1. Members

+

W3C Members are + organizations subscribed according to the Membership Agreement [MEMBER-AGREEMENT]. + They are represented in W3C processes as follows:

+
    +
  1. One representative per Member organization participates + in the Advisory Committee which oversees the work of W3C. +
  2. Representatives of Member organizations participate + in Working Groups and Interest Groups, + where they author and review technical reports. +
+

W3C membership is open to all entities, + as described in “How to Join W3C” [JOIN]; + (refer to the public list of current W3C Members [MEMBER-LIST]). + The Team must ensure + that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

+

While W3C does not have a class of membership tailored to individuals, + individuals may join W3C. + Restrictions pertaining to related Members apply + when the individual also represents another W3C Member.

+

2.1.1. Rights of Members

+

Each Member organization enjoys the following rights and benefits:

+ +

Furthermore, subject to further restrictions included in the Member Agreement, + representatives of Member organizations participate in W3C as follows:

+ +

The rights and benefits of W3C membership [MEMBER-AGREEMENT] are contingent upon conformance to the processes described in this document. + Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.

+

Additional information for Members is available at the Member website [MEMBER-HP].

+

2.1.2. Member Associations and Related Members

+
2.1.2.1. Membership Associations
+

A “Member Association” means a consortium, + user society, + or association of two or more individuals, + companies, + organizations or governments, + or any combination of these entities + which has the purpose of participating in a common activity + or pooling resources to achieve a common goal other than participation in, + or achieving certain goals in, + W3C. + A joint-stock corporation or similar entity is not a Member Association merely because it has shareholders or stockholders. + If it is not clear whether a prospective Member qualifies as a Member Association, + the CEO may reasonably make the determination. + For a Member Association, the rights and privileges of W3C Membership + described in the W3C Process Document extend to the Member Association's paid staff + and Advisory Committee representative.

+

Member Associations may also designate + up to four (or more at the Team’s discretion) individuals + who, though not employed by the organization, may exercise the rights of Member representatives.

+

For Member Associations that have individual people as members, + these individuals must disclose their employment affiliation + when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For Member Associations that have organizations as Members, + all such designated representatives must be an official representative of the Member organization + (e.g. a Committee or Task Force Chairperson) + and must disclose their employment affiliation when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For all representatives of a Member Association, + IPR commitments are made on behalf of the Member Association, + unless a further IPR commitment is made by the individuals' employers.

+
2.1.2.2. Related Members
+

In the interest of ensuring the integrity of the consensus process, + Member involvement in some of the processes in this document is affected by related Member status. + As used herein, two Members are related if:

+
    +
  1. Either Member is a subsidiary of the other, or +
  2. Both Members are subsidiaries of a common entity, or +
  3. The Members have an employment contract or consulting contract that affects W3C participation. +
+

A subsidiary is an organization of which effective control and/or majority ownership rests with another, + single organization.

+

Related Members must disclose these relationships + according to the mechanisms described in the New Member Orientation [INTRO].

+

2.2. The W3C Team

+

The Team consists of CEO, + W3C paid staff, + unpaid interns, + and W3C Fellows. W3C Fellows are Member employees working as part of the Team; + see the W3C Fellows Program [FELLOWS]. + The Team provides technical leadership about Web technologies, + organizes and manages W3C activities to reach goals + within practical constraints (such as resources available), + and communicates with the Members and the public + about the Web and W3C technologies.

+

The CEO may delegate responsibility + (generally to other individuals in the Team) + for any of their roles described in this document. Team Decisions derive from the CEO's authority, + even when they are carried out by other members of the Team.

+

Oversight over the Team, + budgeting, + and other business decisions, + is provided by the W3C Board of Directors, + rather than managed directly by the Process.

+

Note: See the W3C Bylaws for more details + on the Board and overall governance of W3C.

+

3. Groups and Participation

+

For the purposes of this Process, a W3C Group is one of W3C’s Working Groups, Interest Groups, Advisory Committee, Advisory Board, + or TAG, + and a participant is a member of such a group.

+

3.1. Policies for Participation in W3C Groups

+

3.1.1. Individual Participation Criteria

+
3.1.1.1. Expectations and Discipline
+

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

+
    +
  1. Technical competence in one’s role; +
  2. The ability to act fairly; +
  3. Social competence in one’s role. +
+

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities + are responsible for assessing and attesting to the qualities of those nominees.

+

Participants in any W3C activity must abide + by the terms and spirit of the W3C Code of Ethics and Professional Conduct [CEPC] and the participation requirements described in + “Disclosure” + in the W3C Patent Policy [PATENT-POLICY].

+

The CEO may take disciplinary action, + including suspending or removing for cause + a participant in any group (including the AB and TAG) + if serious and/or repeated violations, + such as failure to meet the requirements on individual behavior of + (a) this process + and in particular the CEPC, or + (b) the membership agreement, or + (c) applicable laws, + occur. + Refer to the Guidelines to suspend or remove participants from groups.

+
3.1.1.2. Conflict of Interest Policy
+

Individuals participating materially in W3C work must disclose significant relationships + when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. + These disclosures must be kept up-to-date + as the individual’s affiliations change and W3C membership evolves + (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). + Each section in this document that describes a W3C group + provides more detail about the disclosure mechanisms for that group.

+

The ability of an individual to fulfill a role within a group + without risking a conflict of interest depends on the individual’s affiliations. + When these affiliations change, + the individual’s assignment to the role must be evaluated. + The role may be reassigned according to the appropriate process. + For instance, + the Team may appoint a new group Chair when the current Chair changes affiliations + (e.g., if there is a risk of conflict of interest, + or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

+

The following are some scenarios where disclosure is appropriate:

+
    +
  • Paid consulting for an organization whose activity is relevant to W3C, + or any consulting compensated with equity + (shares of stock, stock options, or other forms of corporate equity). +
  • A decision-making role/responsibility + (such as participating on a Board) + in other organizations relevant to W3C. +
  • A position on a publicly visible advisory body, + even if no decision-making authority is involved. +
+

Individuals seeking assistance on these matters should contact the Team.

+

Team members are subject to the W3C Team conflict of interest policy [CONFLICT-POLICY].

+
3.1.1.3. Individuals Representing a Member Organization
+

Generally, individuals representing a Member in an official capacity within W3C + are employees of the Member organization. + However, an Advisory Committee representative may designate a non-employee + to represent the Member. + Non-employee Member representatives must disclose + relevant affiliations to the Team and to any group in which the individual participates.

+

In exceptional circumstances + (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), + the CEO may decline + to allow an individual designated by an Advisory Committee representative to participate in a group.

+

A group charter may limit + the number of individuals representing a W3C Member + (or group of related Members).

+

3.1.2. Meetings

+

The requirements in this section apply to the official meetings of any W3C group.

+

W3C distinguishes two types of meetings:

+
    +
  1. A face-to-face meeting is one + where most of the attendees are expected to participate in the same physical location. +
  2. A distributed meeting is one + where most of the attendees are expected to participate from remote locations + (e.g., by telephone, video conferencing, or IRC). +
+

A Chair may invite an individual with a particular expertise + to attend a meeting on an exceptional basis. + This person is a meeting guest, + not a group participant. + Meeting guests do not have voting rights. + It is the responsibility of the Chair to ensure + that all meeting guests respect the chartered level of confidentiality and other group requirements.

+
3.1.2.1. Meeting Scheduling and Announcements
+

Meeting announcements should be sent to all appropriate group mailing lists, + i.e. those most relevant to the anticipated meeting participants.

+

The following table lists recommendations for organizing a meeting:

+ + + + + + + + + +
+ Face-to-face meetings + Distributed meetings +
Meeting announcement (before) + eight weeks* + one week* +
Agenda available (before) + two weeks + 24 hours (or longer if a meeting is scheduled after a weekend or holiday) +
Participation confirmed (before) + three days + 24 hours +
Action items available (after) + three days + 24 hours +
Minutes available (after) + two weeks + 48 hours +
+

* To allow proper planning (e.g., travel arrangements), + the Chair is responsible for giving sufficient advance notice + about the date and location of a meeting. + Shorter notice for a meeting is allowed + provided that there are no objections from group participants.

+
3.1.2.2. Meeting Minutes
+

Groups should take and retain minutes of their meetings, + and must record + any official group decisions made during the meeting discussions. + Details of the discussion leading to such decisions are not required, + provided that the rationale for the group decision is nonetheless clear.

+
3.1.2.3. Meeting Recordings and Transcripts
+

No-one may take an audio or video recording of a meeting, + or retain an automated transcript, + unless the intent is announced at the start of the meeting, + and no-one participating in the recorded portion of the meeting withholds consent. + If consent is withheld by anyone, recording/retention must not occur. + The announcement must cover: + (a) who will have access to the recording or transcript and + (b) the purpose/use of it and + (c) how it will be retained (e.g. privately, in a cloud service) and for how long.

+

3.1.3. Tooling for Discussions and Publications

+

For W3C Groups operating under this Process, + a core operating principle is to allow access across disabilities, + across country borders, + and across time. + Thus in order to allow all would-be participants to effectively participate, + to allow future participants and observers to understand the rationale and origins of current decisions, + and to guarantee long-lived access to its publications, + W3C requires that:

+
    +
  • All reports, publications, or other deliverables + produced by the group for public consumption + (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, + and backed up by W3C systems + such that if the underlying service is discontinued, + W3C can continue to serve such content without breaking incoming links + or other key functionality. +
  • All reports, publications, or other deliverables + produced by the group for public consumption should follow best practices for internationalization + and for accessibility to people with disabilities. + Network access to W3C-controlled domains may be assumed. +
  • + Official meeting minutes and other records of decisions made must be archived by W3C for future reference; + and other persistent text-based discussions + sponsored by the group, + pertaining to their work + and intended to be referenceable by all group members should be. + This includes discussions conducted over email lists + or in issue-tracking services + or any equivalent fora. + Materials referenced from discussions + and necessary to understand them + should be available at a stable URL, + at a level of confidentiality no stricter than the discussion minutes. +

    Note: The lack, or loss, of such archives does not by itself + invalidate an otherwise-valid decision.

    +
  • + Any tooling used by the group + for producing its documentation and deliverables + or for official group discussions should be usable + (without additional cost) + by all who wish to participate, + including people with disabilities, + to allow their effective participation. +

    Note: If a new participant joins who cannot use the tool, + this can require the Working Group to change its tooling + or operate some workaround.

    +
  • All tools and archives used by the group + for its discussions and recordkeeping should be documented + such that new participants and observers + can easily find the group’s tools and records. +
+

The Team is responsible for ensuring adherence to these rules + and for bringing any group not in compliance into compliance.

+

3.1.4. Resignation from a Group

+

A W3C Member or Invited Expert may resign from a group. + On written notification from an Advisory Committee representative + or Invited Expert + to the Team, + the Member and their representatives + or the Invited Expert + will be deemed to have resigned from the relevant group. + The Team must record the notification. + See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

+

3.2. The Advisory Committee (AC)

+

3.2.1. Role of the Advisory Committee

+

The Advisory Committee represents + the Members of W3C at large. + It is responsible for:

+ +

Advisory Committee representatives may initiate + an Advisory Committee Appeal of a W3C decision or Team's decision.

+

See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

+

3.2.2. Participation in the Advisory Committee

+

The Advisory Committee is composed of one representative from each Member organization + (refer to the Member-only list + of current Advisory Committee representatives. [CURRENT-AC])

+

When an organization joins W3C + (see “How to Join W3C” [JOIN]), + it must name its Advisory Committee representative as part of the Membership Agreement. + The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, + provides information about Advisory Committee Meetings, + explains how to name a new Advisory Committee representative, + and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.

+

The AC representative may delegate any of their rights and responsibilities + to an alternate (except the ability to designate an alternate).

+

3.2.3. Advisory Committee Mailing Lists

+

The Team must provide two mailing lists for use by the Advisory Committee:

+
    +
  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. + This list is read-only for Advisory Committee representatives. +
  2. One for discussion among Advisory Committee representatives. + Though this list is primarily for Advisory Committee representatives, + the Team must monitor discussion + and should participate in discussion when appropriate. + Ongoing detailed discussions should be moved to other appropriate lists + (new or existing, such as a mailing list created for a Workshop). +
+

An Advisory Committee representative may request + that additional individuals from their organization be subscribed to these lists. + Failure to contain distribution internally may result in suspension of additional email addresses, + at the discretion of the Team.

+

3.2.4. Advisory Committee Meetings

+

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. + The Team appoints the Chair of these meetings (generally the CEO). + At each Advisory Committee meeting, + the Team should provide an update to the Advisory Committee about:

+
+
Resources +
+
    +
  • The number of W3C Members at each level. +
  • An overview of the financial status of W3C. +
+
Allocations +
+
    +
  • The allocation of the annual budget, including size of the Team and their approximate deployment. +
  • A list of all activities (including but not limited to Working and Interest Groups) + and brief status statement about each, + in particular those started or terminated since the previous Advisory Committee meeting. +
  • The allocation of resources to pursuing liaisons with other organizations. +
+
+

Each Member organization should send one representative to each Advisory Committee Meeting. + In exceptional circumstances + (e.g., during a period of transition between representatives from an organization), + the meeting Chair may allow a Member organization to send two representatives to a meeting.

+

The Team must announce the date and location of each Advisory Committee meeting + no later than at the end of the previous meeting; one year’s notice is preferred. + The Team must announce the region of each Advisory Committee meeting + at least one year in advance.

+

More information about Advisory Committee meetings [AC-MEETING] is available at the Member website.

+

3.3. Elected Groups: The AB and the TAG

+

The W3C Process defines two types of elected groups: + the Advisory Board (AB) and + the Technical Architecture Group (TAG), + both elected by the Advisory Committee.

+

3.3.1. Advisory Board (AB)

+
3.3.1.1. Role of the Advisory Board
+

The Advisory Board provides ongoing guidance to the Team + on issues of strategy, + management, + legal matters, + process, + and conflict resolution. + The Advisory Board also serves the Members + by tracking issues raised between Advisory Committee meetings, + soliciting Member comments on such issues, + and proposing actions to resolve these issues. + The Advisory Board manages the evolution of the Process Document. + As part of a W3C Council, + members of the Advisory Board hear and adjudicate on Submission Appeals and Formal Objections.

+

The Advisory Board is distinct from the Board of Directors and has no decision-making authority within W3C; + its role is strictly advisory.

+

Note: While the AB as such does not have decision-making authority, + its members do when sitting as part of a W3C Council.

+

Details about the Advisory Board + (e.g., the list of Advisory Board participants, + mailing list information, and summaries of Advisory Board meetings) + are available at the Advisory Board home page [AB-HP].

+
3.3.1.2. Composition of the Advisory Board
+

The Advisory Board consists of nine to eleven elected participants and one Chair + (who may be one of the elected participants). + With the input of the AB, + the Team appoints the Chair, + who should choose a co-chair among the elected participants. + The Chair(s) are subject to ratification by secret ballot + by two thirds of the AB upon appointment. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The team also appoints a Team Contact, + as described in § 3.4.1 Requirements for All Chartered Groups. + The CEO and Team Contact have a standing invitation + to all regular Advisory Board sessions.

+

The nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

+

The terms of elected Advisory Board participants are for two years. + Terms are staggered so that each year, + either five or six terms expire. + If an individual is elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular Advisory Board terms begin on 1 July and end on 30 June.

+

+
3.3.1.3. Communications of the Advisory Board
+

The Team must make available a mailing list, + confidential to the Advisory Board and Team, + for the Advisory Board to use for its communication.

+

The Advisory Board should send a summary of each of its meetings + to the Advisory Committee and other group Chairs. + The Advisory Board should also report on its activities + at each Advisory Committee meeting.

+
3.3.1.4. Liaisons between the Advisory Board and the Board of Directors
+

To ensure good communication between the AB and the Board of Directors and facilitate operational and management consistency, + the AB may appoint up to two of its participants as liaisons to the Board. + Such appointees are expected to attend and participate in Board meetings + and access Board materials + as Non-voting Observers. [BYLAWS] They do not form part of the Board's decision-making body, + and may be excluded from such participation + in accordance with applicable Board procedures.

+

The Advisory Board should reevaluate + who is assigned to this role + at least at the beginning of each term, + and may swap its appointees more frequently + as they deem appropriate.

+

3.3.2. Technical Architecture Group (TAG)

+
3.3.2.1. Role of the Technical Architecture Group
+

The mission of the TAG is stewardship of the Web architecture. + There are three aspects to this mission:

+
    +
  1. to document and build consensus around principles of Web architecture + and to interpret and clarify these principles when necessary; +
  2. to resolve issues involving general Web architecture brought to the TAG; +
  3. to help coordinate cross-technology architecture developments inside and outside W3C. +
+

As part of a W3C Council, + the members of the TAG hear and adjudicate on Submission Appeals and Formal Objections.

+

The TAG's scope is limited to technical issues about Web architecture. + The TAG should not consider + administrative, + process, + or organizational policy issues of W3C, + which are generally addressed by + the W3C Advisory Committee, + Advisory Board, + and Team. + Please refer to the TAG charter [TAG-CHARTER] for more information about the background and scope of the TAG, + and the expected qualifications of TAG participants.

+

When the TAG votes to resolve an issue, + each TAG participant + (whether appointed, elected, or the Chair) + has one vote; + see also the section on voting in the TAG charter [TAG-CHARTER] and the general section on votes in this Process Document.

+

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) + are available at the TAG home page [TAG-HP].

+
3.3.2.2. Composition of the Technical Architecture Group
+

The TAG consists of:

+ +

Participants in the TAG choose by consensus their Chair or co-Chairs; + in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG. + The Chair or co-Chairs must be selected from the participants of the TAG. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The Team also appoints a Team Contact [TEAM-CONTACT] for the TAG, + as described in § 3.4.1 Requirements for All Chartered Groups.

+

The terms of TAG participants last for two years. + Terms are staggered so that three elected terms + and either one or two appointed terms expire each year. + If an individual is appointed or elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular TAG terms begin on 1 February and end on 31 January.

+
3.3.2.3. Communications of the Technical Architecture Group
+

The Team must make available two mailing lists for the TAG:

+
    +
  • a public discussion (not just input) list for issues of Web architecture. + The TAG will conduct its public business on this list. +
  • a Member-only list for discussions within the TAG + and for requests to the TAG that, + for whatever reason, cannot be made on the public list. +
+

The TAG may also request the creation of additional topic-specific, public mailing lists. + For some TAG discussions (e.g., a Submission Appeal), + the TAG may use a list that will be Member-only.

+

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. + The TAG should also report on its activities at each Advisory Committee meeting.

+

3.3.3. Participation in Elected Groups

+
3.3.3.1. Expectations for Elected Groups Participants
+

Advisory Board and TAG participants have a special role within W3C: + they are elected by the Membership and appointed by the Team with the expectation that they will use their best judgment + to find the best solutions for the Web, + not just for any particular network, + technology, + vendor, + or user. + Advisory Board and TAG participants are expected to participate regularly and fully. + Advisory Board and TAG participants should attend Advisory Committee meetings.

+

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, + to serve the needs of the W3C membership as a whole, + and the Web community. + Whether they are Member representatives or Invited Experts, + their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

+

An individual participates on the Advisory Board or TAG + from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). + Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, + their participation does carry the responsibilities associated with Member representation, + Invited Expert status, + or Team representation + (as described in the section on the AB/TAG nomination and election process).

+

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, + and a participant’s seat must not be delegated to any other person.

+
3.3.3.2. Elected Groups Participation Constraints
+

Given the few seats available on the Advisory Board and the TAG, + and in order to ensure that the diversity of W3C Members is represented:

+ +
3.3.3.3. Advisory Board and Technical Architecture Group Elections
+

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, + using a Single Transferable Vote system. + An election begins when the Team sends a Call for Nominations to the Advisory Committee. + Any Call for Nominations specifies the minimum and maximum number of available seats, + the deadline for nominations, + details about the specific vote tabulation system selected by the Team for the election, + and operational information such as how to nominate a candidate. + The Team may modify the tabulation system after the Call for Nominations + but must stabilize it no later than the Call for Votes. + The Team announces appointments + after the results of the election are known, + and before the start of the term, + as described in § 3.3.3.4 Technical Architecture Group Appointments.

+

In the case of regularly scheduled elections of the TAG, + the minimum and maximum number of available seats are the same: + the 3 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

+

In the case of regularly scheduled elections of the AB, + the minimum and maximum number of available seats differ: + The maximum number is the 5 or 6 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; + the minimum number is such that when added to the occupied seats from the prior year, + the minimum size of the AB (9) is reached.

+

Each Member (or group of related Members) may nominate one individual. + A nomination must be made with the consent of the nominee. + In order for an individual to be nominated as a Member representative, + the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination + the (same) information required for a Member representative in a Working Group. + In order for an individual to be nominated as an Invited Expert, + the individual must provide + the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. + In order for an individual to be nominated as a Team representative, + the nominating Advisory Committee representative must first secure approval from Team management. + A nominee is not required to be an employee of a Member organization, + and may be a W3C Fellow. + The nomination form must ask for the nominee’s primary affiliation, + and this will be reported on the ballot. + For most nominees, + the primary affiliation is their employer and will match their affiliation in the W3C database. + For contractors and invited experts, + this will normally be their contracting company + or their invited expert status; + in some cases + (e.g. where a consultant is consulting for only one organization) + this may be the organization for whom the nominee is consulting. + A change of affiliation is defined + such that this field would carry a different answer + if the nominee were to be re-nominated + (therefore, + terminating employment, + or accepting new employment, + are changes of affiliation). + (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) + Each nomination should include + a few informative paragraphs about the nominee.

+

If, after the deadline for nominations, the number of nominees is:

+
    +
  • Greater than or equal to the minimum number of available seats + and less than or equal to the maximum number of available seats, + those nominees are thereby elected. + This situation constitutes a tie for the purpose of assigning incomplete terms. + Furthermore, if the number is less than the maximum number of available seats, + the longest terms are filled first. +
  • Less than the minimum number of available seats, + Calls for Nominations are issued until a sufficient number of people have been nominated. + Those already nominated do not need to be renominated after a renewed call. +
  • Greater than the maximum number of available seats, + the Team issues a Call for Votes + that includes the names of all candidates, + the (maximum) number of available seats, + the deadline for votes, + details about the vote tabulation system selected by the Team for the election, + and operational information. +
+

When there is a vote, + each Member + (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. + Once the deadline for votes has passed, + the Team announces the results to the Advisory Committee. + In case of a tie the verifiable random selection procedure described below + will be used to fill the available seats.

+

The shortest incomplete term is assigned to the elected candidate ranked lowest by the tabulation of votes, + the next shortest term to the next-lowest ranked elected candidate, + and so on. + In the case of a tie among those eligible for a incomplete term, + the verifiable random selection procedure described below + will be used to assign the incomplete term.

+

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

+
3.3.3.4. Technical Architecture Group Appointments
+

The Team is responsible for appointing + 3 of the participants to the Technical Architecture Group. + This mechanism complements the election process. + The Team should use its appointments to support + a diverse and well-balanced TAG, + including diversity of technical background, knowledge, and skill sets.

+

The Team should actively seek + candidates for appointment to the TAG, + and must make available to + the W3C community at large + a means to propose candidates for consideration, + explicitly soliciting input from at least + current and incoming TAG members, the Advisory Committee, and Working Group Chairs.

+

The constraints for appointment to the TAG are + the same as for elected participants + (see § 3.3.3.2 Elected Groups Participation Constraints and § 3.3.3.3 Advisory Board and Technical Architecture Group Elections), + with the additional constraint that + a person must not be appointed + for more than two consecutive terms. + (Partial terms used to fill a vacated seat do not count towards this limit.)

+

Note: Individuals who have reached the limit of two consecutive appointed terms may freely run for election + if they wish to continue serving on the TAG.

+

The Team's choice of appointee(s) + is subject to ratification by secret ballot + by both the AB and the TAG, + each requiring a two-thirds approval. + In the case of regularly scheduled elections, + the TAG participants in this ratification are + its members for the upcoming term.

+

For regularly scheduled elections, + selection begins once the results of the elections are known, + and the Team should announce the ratified appointment(s) + no later than the start of the regularly scheduled term. + When an appointed seat is vacated outside of a regularly scheduled election, + the Team should seek to appoint a replacement + unless a regular Call for Nominations is scheduled within 2 months, + and it must announce the ratified appointment + no later than the Call for Nominations of the next scheduled election.

+
3.3.3.5. Verifiable Random Selection Procedure
+

When it is necessary to use a verifiable random selection process + (e.g., in an AB or TAG election, + to “draw straws” in case of a tie + or to fill a incomplete term), + W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. + The procedure orders an input list of names + (listed in alphabetical order by family name unless otherwise specified) + into a “result order”.

+

W3C applies this procedure as follows:

+

+
    +
  1. When N people have tied for M (less than N) seats. + In this case, only the names of the N individuals who tied + are provided as input to the procedure. + The M seats are assigned in result order. +
  2. After all elected individuals have been identified, + when N people are eligible for M (less than N) incomplete terms. + In this case, only the names of those N individuals are provided as input to the procedure. + The incomplete terms are assigned in result order. +
+
3.3.3.6. Elected Groups Vacated Seats
+

An Advisory Board or TAG participant’s seat is vacated when:

+ +

If a participant changes affiliation, + but the participation constraints are met, + that participant’s seat becomes vacant at the next regularly scheduled election for that group.

+

Vacated seats are filled according to this schedule:

+
    +
  • When an appointed TAG seat is vacated, + the Team appoints a replacement. +
  • + When an elected seat on either the AB or TAG is vacated, + the seat is filled at the next regularly scheduled election for the group + unless the group Chair requests that W3C hold an election before then + (for instance, due to the group’s workload). +
      +
    • The group Chair should not request such an election + if the next regularly scheduled election is fewer than three months away. +
    • The group Chair may request an election, + and the election may begin, as soon as a current member gives notice of a resignation, + including a resignation effective as of a given date in the future. +
    +

    When such an election is held, + the minimum number of available seats is such that + when added to the number of continuing participants, + the minimum total number of elected seats is met + (6 for the TAG, 9 for the AB); + and the maximum number corresponds to all unoccupied seats. + Except for the number of available seats and the length of the terms, + the usual rules for Advisory Board and Technical Architecture Group Elections apply.

    +
+

3.4. Chartered Groups: Working Groups and Interest Groups

+

This document defines two types of chartered groups:

+
+
Working Groups. +
+ Working Groups typically produce deliverables + (e.g., Recommendation Track technical reports, + software, + test suites, + and reviews of the deliverables of other groups) + as defined in their charter. +

Working Groups have additional participation requirements + described in the W3C Patent Policy [PATENT-POLICY], + see particularly the “Licensing Obligations of Working Group Participants” + and the patent claim exclusion process + in “Exclusion From W3C RF Licensing Requirements”.

+
Interest Groups. +
+ The primary goal of an Interest Group + is to bring together people who wish to evaluate potential Web technologies and policies. + An Interest Group is a forum for the exchange of ideas. +

Interest Groups do not publish Recommendation Track technical reports; + but can publish technical reports on the Note Track.

+
+

3.4.1. Requirements for All Chartered Groups

+

Each group must have a charter. + Requirements for the charter depend on the group type. + All group charters must be public + (even if other proceedings of the group are Member-only).

+

Each group must have a Chair (or co-Chairs) + to coordinate the group’s tasks. + The Team appoints (and re-appoints) Chairs for all groups. + The Chair is a Member representative, + a Team representative, + or an Invited Expert, + (invited by the Team). + The requirements of this document that apply to those types of participants apply to Chairs as well. + The role of the Chair [CHAIR] is described + in the Art of Consensus [GUIDE].

+

Each group must have a Team Contact, + who acts as the interface between the Chair, + group participants, + and the rest of the Team. + The role of the Team Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE]. + The Chair and the Team Contact of a group should not be the same individual.

+

Each group must have an archived mailing list + for formal group communication + (e.g., for meeting announcements and minutes, + documentation of decisions, + and Formal Objections to decisions). + It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists. + Refer to the list of group mailing lists [GROUP-MAIL].

+

A Chair may form task forces + (composed of group participants) + to carry out assignments for the group. + The scope of these assignments must not exceed the scope of the group’s charter. + A group should document the process it uses + to create task forces + (e.g., each task force might have an informal "charter"). + Task forces do not publish technical reports; + the Working Group may choose to publish their results as part of a technical report.

+

3.4.2. Participation in Chartered Groups

+

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, + and Team representatives (including the Team Contact).

+

There are four types of individual participants in an Interest Group: + the same three types as for Working Groups plus, + for an Interest Group where the only participation requirement is mailing list subscription, public participants.

+

Except where noted in this document or in a group charter, + all participants share the same rights and responsibilities in a group; + see also the individual participation criteria.

+

A participant may represent more than one organization + in a Working Group or Interest Group. + Those organizations must all be members of the group.

+

An individual may become + a Working or Interest Group participant + at any time during the group’s existence. + See also relevant requirements in + “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY].

+

On an exceptional basis, + a Working or Interest Group participant may designate + a substitute to attend a meeting and should inform the Chair. + The substitute may act on behalf of the participant, + including for votes. + For the substitute to vote, + the participant must inform the Chair in writing in advance. + As a courtesy to the group, + if the substitute is not well-versed in the group’s discussions, + the regular participant should authorize another participant to act as proxy for votes.

+

To allow rapid progress, + Working Groups are intended to be small + (typically fewer than 15 people) + and composed of experts in the area defined by the charter. + In principle, + Interest Groups have no limit on the number of participants. + When a Working Group grows too large to be effective, + W3C may split it into an Interest Group + (a discussion forum) + and a much smaller Working Group + (a core group of highly dedicated participants).

+

3.4.3. Types of Participants in Chartered Groups

+
3.4.3.1. Member Representative in a Working Group
+

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Advisory Committee representative of the Member in question + has designated the individual as a Working Group participant, and +
  • the individual qualifies for Member representation. +
+

To designate an individual as a Member representative in a Working Group, + an Advisory Committee representative must provide the Chair and Team Contact with all of the following information, + in addition to any other information required by the Call for Participation and charter + (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

+
    +
  1. The name of the W3C Member the individual represents + and whether the individual is an employee of that Member organization; +
  2. A statement that the individual accepts the participation terms + set forth in the charter + (with an indication of charter date or version); +
  3. A statement that the Member will provide the necessary financial support for participation + (e.g., for travel, telephone calls, and conferences). +
+

A Member participates in a Working Group from the moment the first Member representative joins the group + until either of the following occurs:

+
    +
  • the group closes, or +
  • the Member resigns from the Working Group; + this is done through the Member’s Advisory Committee representative. +
+
3.4.3.2. Member Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

+ +

To designate an individual as a Member representative in an Interest Group, + the Advisory Committee representative must follow the instructions + in the Call for Participation and charter.

+

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

+
3.4.3.3. Invited Expert in a Working Group
+

The Chair may invite an individual with a particular expertise + to participate in a Working Group. + This individual may represent an organization in the group + (e.g., if acting as a liaison with another organization).

+

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Chair has designated the individual as a group participant, +
  • the Team Contact has agreed with the Chair’s choice, and +
  • the individual has provided the information required of an Invited Expert to the Chair and Team Contact. +
+

To designate an individual as an Invited Expert in a Working Group, + the Chair must inform the Team Contact + and provide rationale for the choice. + When the Chair and the Team Contact disagree about a designation, + the CEO determines + whether the individual will be invited to participate in the Working Group.

+

To participate in a Working Group as an Invited Expert, + an individual must:

+
    +
  • identify the organization, if any, the individual represents as a participant in this group, +
  • agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT], +
  • accept the participation terms set forth in the charter, + including the participation requirements of + the W3C Patent Policy [PATENT-POLICY], + especially in “Note on Licensing Commitments for Invited Experts” + and in “Disclosure”, + indicating a specific charter date or version, +
  • disclose whether the individual is an employee of a W3C Member; + see the conflict of interest policy, +
  • provide a statement of who will provide the necessary financial support + for the individual’s participation + (e.g., for travel, telephone calls, and conferences), and +
  • if the individual’s employer (including a self-employed individual) + or the organization the individual represents + is not a W3C Member, + indicate whether that organization intends to join W3C. + If the organization does not intend to join W3C, + indicate reasons the individual is aware of for this choice. +
+

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. + The Chair must not use Invited Expert status + to circumvent participation limits imposed by the charter.

+

An Invited Expert participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • the Chair or CEO withdraws the invitation to participate, or +
  • the individual resigns. +
+
3.4.3.4. Invited Expert in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

+
3.4.3.5. Team Representative in a Working Group
+

An individual is a Team representative in a Working Group when so designated by W3C management. + Team representatives both contribute to the technical work + and help ensure the group’s proper integration with the rest of W3C.

+

A Team representative participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • W3C management changes Team representation by sending email to the Chair, + copying the group mailing list. +
+

The Team participates in a Working Group + from the moment the creation of the group is announced + until the group closes.

+
3.4.3.6. Team Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Team representative in an Interest Group when so designated by W3C management.

+

4. Lifecycle of Chartered Groups

+

4.1. Initiating Charter Development

+

W3C creates charters for chartered groups based on interest from the Members and Team. + The Team must notify the Advisory Committee + when a charter for a new Working Group or Interest Group is in development. + This is intended to raise awareness, + even if no formal proposal is yet available. + Advisory Committee representatives may provide + feedback on the Advisory Committee discussion list or via other designated channels.

+

W3C may begin work + on a Working Group or Interest Group charter + at any time.

+

4.2. Content of a Charter

+

A Working Group or Interest Group charter must include all of the following information.

+
    +
  • The group’s mission + (e.g., develop a technology or process, review the work of other groups). +
  • The scope of the group’s work and criteria for success. +
  • The duration of the group (typically from six months to two years). +
  • The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software). +
  • + Expected milestone dates where available. +

    Note: A charter is not required to include schedules for review of other group’s deliverables.

    +
  • The process for the group to approve the release of deliverables + (including intermediate results). +
  • Any dependencies by groups within or outside of W3C on the deliverables of this group. + For any dependencies, the charter must specify + the mechanisms for communication about the deliverables. +
  • Any dependencies of this group on other groups within or outside of W3C. + Such dependencies include interactions with W3C Horizontal Groups [CHARTER]. +
  • The level of confidentiality of the group’s proceedings and deliverables. +
  • Meeting mechanisms and expected frequency. +
  • If known, + the date of the first face-to-face meeting. + The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal. +
  • Communication mechanisms to be employed within the group, + between the group and the rest of W3C, + and with the general public. +
  • Any voting procedures or requirements + other than those specified in § 5.2.3 Deciding by Vote. +
  • An estimate of the expected time commitment from participants. +
  • The expected time commitment and level of involvement by the Team + (e.g., to track developments, + write and edit technical reports, + develop code, + or organize pilot experiments). +
  • Intellectual property information. + What are the intellectual property (including patents and copyright) + considerations affecting the success of the Group? + In particular, is there any reason to believe + that it will be difficult to meet the Royalty-Free licensing goals + in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY]? +
+

See also the charter requirements in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

For every Recommendation Track deliverable + that continues work on technical report published under any other Charter (including a predecessor group of the same name), + for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

+
    +
  • The title, + stable URL, + and publication date of the Working Draft or other Recommendation-track document + that will serve as the basis for work on the deliverable + (labeled “Adopted Draft”); +
  • The title, + stable URL, + and publication date of the document + that was used as the basis for its most recent Exclusion Opportunity + as per + the W3C Patent Policy [PATENT-POLICY]. + (labeled “Exclusion Draft”); and +
  • The stable URL of the Working Group charter + under which the Exclusion Draft was published + (labeled the “Exclusion Draft Charter”). +
+

All of the above data must be identified + in the adopting Working Group’s charter using the labels indicated.

+

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. + The proposed charter must state + the dates on which the Exclusion Opportunity + that arose on publishing the Exclusion Draft began and ended. + As per “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY], + this potentially means that exclusions can only be made immediately on joining a Working Group.

+

An Interest Group charter may include provisions regarding participation, + including specifying + that the only requirement for participation (by anyone) in + the Interest Group is subscription to the Interest Group mailing list. + This type of Interest Group may have public participants.

+

A charter may include + provisions other than those required by this document. + The charter should highlight + whether additional provisions impose constraints + beyond those of the W3C Process Document + (e.g., limits on the number of individuals in a Working Group + who represent the same Member organization or group of related Members).

+

4.3. Advisory Committee Review of a Charter

+

The Team must solicit Advisory Committee review of every new or substantively modified Working Group or Interest Group charter, + except for either:

+
    +
  • +

    a charter extension

    +
  • +

    substantive changes to a charter that do not affect the way the group functions in any significant way.

    +
+

The review period must be at least 28 days. + The following are examples of substantive changes that would not require an Advisory Committee Review: + the addition of an in-scope deliverable, + a change of Team Contact, + or a change of Chair. + Such changes must nonetheless be announced + to the Advisory Committee and to participants in the Working or in the Interest Group, + and a rationale must be provided.

+

The Call for Review of a substantively modified charter must highlight important changes + (e.g., regarding deliverables or resource allocation) + and include rationale for the changes.

+

As part of the Advisory Committee review of any new or substantively modified Working Group charter, + any Advisory Committee representative may request an extended review period.

+

Such a request must be submitted with a Member’s comments + in response to the Call for Review. + Upon receipt of any such request, + the Team must ensure + that the Call for Participation for the Working Group + occurs at least 60 days + after the Call for Review of the charter.

+

4.4. Call for Participation in a Chartered Group

+

Deciding whether to adopt a proposed Working Group or Interest Group charter is a W3C Decision. + Charters may be amended based on review comments + per § 5.7.2 After the Review Period before the Call for Participation.

+

If the decision is to charter the group, + the Team must issue a Call for Participation to the Advisory Committee. + For a new group, this announcement officially creates the group. + The announcement must include a reference to the charter, + the name(s) of the group’s Chair(s), + and the name(s) of the Team Contact(s).

+

After a Call for Participation, + any Member representatives and Invited Experts must be designated (or re-designated). + When a group is re-chartered, + individuals participating in the Working Group or Interest Group before the new Call for Participation + may attend any meetings held within forty-five (45) days of the Call for Participation + even if they have not yet formally rejoined the group + (i.e., committed to the terms of the charter and patent policy).

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against the decision to create + or substantially modify + a Working Group or Interest Group charter.

+

4.5. Charter Extension

+

The Team may decide + to extend a Working Group or Interest Group charter + with no other substantive modifications. + The Team must announce + such extensions to the Advisory Committee. + The announcement must indicate the new duration. + The announcement must also include rationale for the extension, + a reference to the charter, + and the Group homepage + (which includes at least + the name(s) of the group’s Chair(s), + the name of the Team Contact, + and instructions for joining the group).

+

After a charter extension, + Advisory Committee representatives + and the Chair are not required to re-designate Member representatives and Invited Experts.

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.

+

4.6. Chartered Group Closure

+

A Working Group or Interest Group charter specifies a duration for the group.

+

The Team, the TAG, or the AB may propose to close a group + prior to the date specified in the charter in any of the following circumstances:

+
    +
  • +

    There are insufficient member resources to produce chartered deliverables +or to maintain the group, +according to priorities established within W3C.

    +
  • +

    A Patent Advisory Group concluded that the work should be terminated.

    +
  • +

    The TAG or AB determined that continuing operation of the chartered group or its work +would be detrimental to W3C or its mission.

    +
  • +

    The group produced all chartered deliverables ahead of schedule.

    +
+

Such a proposal to close a group must be accompanied by rationale, + and the proposal must be confirmed by an AC Review as a W3C Decision.

+

Closing a Working Group has implications + with respect to the W3C Patent Policy [PATENT-POLICY].

+

5. Decisions

+

W3C attempts to resolve issues through dialog. + Individuals who disagree strongly with a decision should register with the Chair any Formal Objections.

+

5.1. Types of Decisions

+

The Chair of a Working Group or Interest Group has the prerogative + to make certain decisions based on their own judgment. + Such decisions are called chair decisions.

+

In contrast, + decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group + or following a vote (see § 5.2.3 Deciding by Vote) + are called group decisions (also known as group “resolutions”).

+

Decisions made by members of the Team in connection with this Process, + based on their own individual or collective judgement, + are called Team Decisions.

+

In contrast, + a W3C decision is + determined by the Team on behalf of the W3C community + by assessing the consensus of the W3C Community after an Advisory Committee review.

+

5.2. Consensus Building

+

5.2.1. Consensus

+

Consensus is a core value of W3C. + To promote consensus, + the W3C process requires Chairs to ensure + that groups consider all legitimate views and objections, + and endeavor to resolve them, + whether these views and objections are expressed by the active participants of the group + or by others + (e.g., another W3C group, + a group in another organization, + or the general public). + Decisions may be made during meetings + (face-to-face or distributed) + as well as through persistent text-based discussions.

+

Note: The CEO has the role of + assessing consensus within the Advisory Committee.

+

The following terms are used in this document + to describe the level of support for a decision among a set of eligible individuals:

+
+
Consensus: +
A substantial number of individuals in the set + support the decision + and there is no sustained objection from anybody in the set. + Individuals in the set may abstain. + Abstention is either an explicit expression of no opinion + or silence by an individual in the set. +
Unanimity: +
The particular case of consensus where all individuals in the set support the decision + (i.e., no individual in the set abstains). +
Dissent: +
At least one individual in the set sustains an objection. +
+

Note: A Formal Objection always indicates a sustained objection, + but isn’t necessary to express it + (except in some formal contexts such as AC Reviews). + Disagreement with a proposed decision, + however, does not always rise to the level of sustained objection, + as individuals could be willing to accept a decision + while expressing disagreement.

+

By default, the set of individuals eligible to participate in a decision is the set of group participants. + The Process Document does not require a quorum for decisions + (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). + A charter may include a quorum requirement for consensus decisions.

+

Where unanimity is not possible, + a group should strive to make consensus decisions + where there is significant support and few abstentions. + The Process Document does not require a particular percentage of eligible participants + to agree to a motion in order for a decision to be made. + To avoid decisions where there is widespread apathy, + (i.e., little support and many abstentions), + groups should set minimum thresholds of active support before a decision can be recorded. + The appropriate percentage may vary depending on the size of the group + and the nature of the decision. + A charter may include threshold requirements for consensus decisions. + For instance, a charter might require a supermajority of eligible participants + (i.e., some established percentage above 50%) + to support certain types of consensus decisions.

+
+ Note: Chairs have substantial flexibility + in how they obtain and assess consensus among their groups. + Unless otherwise constrained by charter, + they may use modes including but not limited to explicit calls for consensus, + polls of participants, + “lazy consensus” in which lack of objection after sufficient notice is taken as assent; + or they may also delegate and empower a document editor + to assess consensus on their behalf, + whether in general + or for specific pre-determined circumstances + (e.g. in non-controversial situations, for specific types of issues, etc.). +

If questions or disagreements arise, + the final determination of consensus remains with the chair.

+
+

5.2.2. Managing Dissent

+

In some cases, even after careful consideration of all points of view, + a group might find itself unable to reach consensus. + The Chair may record a decision where there is dissent so that the group can make progress + (for example, to produce a deliverable in a timely manner). + Dissenters cannot stop a group’s work + simply by saying that they cannot live with a decision. + When the Chair believes that the Group has duly considered + the legitimate concerns of dissenters as far as is possible and reasonable, + the group should move on.

+

Groups should favor proposals that create the weakest objections. + This is preferred over proposals that are supported by a large majority + but that cause strong objections from a few people. + As part of making a decision where there is dissent, + the Chair is expected to be aware of which participants work for the same + (or related) + Member organizations and weigh their input accordingly.

+

Note: Dissenters can escalate their sustained objection to a decision by registering a Formal Objection.

+

5.2.3. Deciding by Vote

+

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, + and that a vote is necessary to break a deadlock. + In this case the Chair must record + (e.g., in the minutes of the meeting or in an archived email message):

+
    +
  • an explanation of the issue being voted on; +
  • the decision to conduct a vote + (e.g., a simple majority vote) to resolve the issue; +
  • the outcome of the vote; +
  • any Formal Objections. +
+

In order to vote to resolve a substantive issue, + an individual must be a group participant. + Each organization represented in the group must have at most one vote, + even when the organization is represented by several participants in the group + (including Invited Experts). + For the purposes of voting:

+
    +
  • A Member or group of related Members is considered a single organization. +
  • The Team is considered an organization. +
+

Unless the charter states otherwise, Invited Experts may vote.

+

If a participant is unable to attend a vote, + that individual may authorize anyone at the meeting + to act as a proxy. + The absent participant must inform the Chair in writing + who is acting as proxy, with written instructions on the use of the proxy. + For a Working Group or Interest Group, + see the related requirements regarding an individual + who attends a meeting as a substitute for a participant.

+

A group may vote for other purposes than to resolve a substantive issue. + For instance, the Chair often conducts a “straw poll” vote + as a means of determining whether there is consensus about a potential decision.

+

A group may also vote to make a process decision. + For example, + it is appropriate to decide by simple majority + whether to hold a meeting in San Francisco or San Jose + (there’s not much difference geographically). + When simple majority votes are used to decide minor issues, + voters are not required to state the reasons for votes, + and the group is not required to record individual votes.

+

A group charter may include formal voting procedures + (e.g., quorum or threshold requirements) + for making decisions about substantive issues.

+

5.3. Formally Addressing an Issue

+

In the context of this document, + a group has formally addressed an issue when it has sent a public, substantive response + to the reviewer who raised the issue. + A substantive response is expected to include rationale for decisions + (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). + The adequacy of a response is measured + against what a W3C reviewer would generally consider to be technically sound. + If a group believes that a reviewer’s comments result from a misunderstanding, + the group should seek clarification before reaching a decision.

+

As a courtesy, + both Chairs and reviewers should set expectations + for the schedule of responses and acknowledgments. + The group should reply to a reviewer’s initial comments + in a timely manner. + The group should set a time limit + for acknowledgment by a reviewer of the group’s substantive response; + a reviewer cannot block a group’s progress. + It is common for a reviewer to require a week or more + to acknowledge and comment on a substantive response. + The group’s responsibility to respond to reviewers + does not end once a reasonable amount of time has elapsed. + However, reviewers should realize + that their comments will carry less weight + if not sent to the group in a timely manner.

+

Substantive responses should be recorded. + The group should maintain an accurate summary + of all substantive issues and responses to them + (e.g., in the form of an issues list with links to mailing list archives).

+

5.4. Reopening a Decision When Presented With New Information

+

The Chair may reopen a decision + when presented with new information, including:

+
    +
  • additional technical information, +
  • comments by email from participants who were unable to attend a scheduled meeting, +
  • comments by email from meeting attendees + who chose not to speak out during a meeting + (e.g., so they could confer later with colleagues or for cultural reasons). +
+

The Chair should record + that a decision has been reopened, + and must do so upon request from a group participant.

+

5.5. Registering Formal Objections

+

Any individual + (regardless of whether they are associated with a Member) may appeal any decision made in connection with this Process + (except those having a different appeal process) + by registering a Formal Objection with the Team. + Group participants should inform + their Team Contact as well as the group’s Chair(s). + The Team Contact must inform the CEO when a group participant has also raised concerns about due process.

+

Note: In this document, the term Formal Objection is used to emphasize this process implication: + Formal Objections receive formal consideration and a formal response. + The word “objection” used alone has its ordinary English connotations. + See § 5.2 Consensus Building.

+

A Formal Objection must include a summary of + the issue (whether technical or procedural), + the decision being appealed, + and the rationale for the objection. + It should cite technical arguments + and propose changes that would remove the Formal Objection; + these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments + or rationale are unlikely to receive serious consideration. + Counter-arguments, + rationales, + and decisions should also be recorded.

+

A record of each Formal Objection against a decision regarding a publicly-available document must be made publicly available; + likewise, a record of each Formal Objection against a Member-visible decision must be made available to Members. + A Call for Review to the Advisory Committee must identify any Formal Objections related to that review.

+

Note: Formal Objections against matter in a technical report are required to be addressed before requesting advancement of the technical report.

+

A Formal Objection filed during an Advisory Committee Review is considered registered at the close of the review period.

+

5.6. Addressing Formal Objections

+

5.6.1. Investigation and Mediation by the Team

+

The Team considers the Formal objection, + researches the question, + interviews parties, + and so on, + to make sure the problem and the various viewpoints are well understood, + and to the extent possible, + to arrive at a recommended disposition. + If the Team can resolve the issue + to the satisfaction of the individual that filed the Formal Objection, + the individual withdraws the objection and the disposition process terminates.

+

Otherwise, + upon concluding that consensus cannot be found, + and no later than 90 days after the Formal Objection being registered, + the Team must initiate formation of a W3C Council, + which should be convened within 45 days of being initiated. + Concurrently, it must prepare a report for the Council documenting its findings and attempts to find consensus.

+

5.6.2. W3C Council

+

A W3C Council is the body convened to resolve Formal Objections by combining the capabilities and perspectives of the AB, the TAG, and the Team, + and is tasked with doing so in the best interests of the Web and W3C.

+
5.6.2.1. Council Composition
+

Each W3C Council is composed of the following members (excepting any renounced or dismissed):

+ +

Participation in a W3C Council must not require attendance of face-to-face meetings.

+

A distinct instance of the W3C Council is convened for each decision being appealed or objected to. + Membership of an instance the Council is be fixed at formation, + and is not changed by any AB or TAG elections + occurring before that Council has reached a conclusion. + However, if participation in a Council falls so low as to hinder effective and balanced deliberations, + the W3C Council Chair should dissolve the Council and call for a new one to be convened.

+

A Team member is assigned + to act as the Council Team Contact, + to support this Council + and to facilitate adherence to this Process.

+
5.6.2.2. Extraordinary Delegation
+

In extraordinary cases, + if they feel a Council would not be the appropriate deciding body, + a member of the Team (particularly the Legal Counsel) or + any potential Council member + may suggest that the decision for that specific Formal Objection be delegated + to the W3C Board of Directors, + to an officer of its corporation (such as the Legal Counsel), + or to one or more specific individuals from the Team. + The potential Council members then may confidentially discuss + and must vote + whether to delegate the decision for that specific Formal Objection. + A decision to delegate must be supported by a two-thirds supermajority vote + (i.e., at least twice as many votes in favor as against). + Delegation in such cases cannot be later revoked.

+

The Team must inform the Advisory Committee when a Formal Objection has been delegated, + and to whom it has been delegated.

+
5.6.2.3. Council Participation, Dismissal, and Renunciation
+

In order to apply consistent criteria, + the potential Council members decide collectively + which reasons against service + rise to a sufficient level for a potential member to be dismissed. + No-one is automatically dismissed, + and individual recusal is not used in the Council. Dismissal applies to an individual person in the context of a specific Council, + and should be used rarely in order to preserve the greatest diversity on the Council.

+

Note: A W3C Council is a deliberative body whose purpose is + to find the best way forward for the Web and for W3C. + It is not a judicial body tasked with determining right or wrong.

+

The Team must draft a list of potential Council members, + with annotations of possible reasons for dismissal against each one. + The W3C community, + including members and team, and potential council members, must be given an opportunity to contribute possible reasons to this list. + Affected members must be given + an opportunity to respond to such comments about themselves. + The Team may report comments verbatim + or may paraphrase them while preserving their intent; + they may also elide inappropriate comments, + such as any that violate applicable laws or the [CEPC].

+

Before a Council forms, + the Team presents the entire list of potential members + and collected reasons and responses + to the potential Council members. + They then consider for each potential member + whether that individual’s participation + would compromise the integrity of the Council decision, + and vote whether to dismiss that potential member. + No one is allowed to vote on their own dismissal; + each dismissal is decided by simple majority of those not abstaining.

+

Note: Since dismissal is individual, + when the decision being objected to was made by the TAG or AB acting as a body, + the entire TAG or AB is not expected or required to be dismissed.

+

An individual may also renounce their seat on a Council, for strong reason, + such as being forbidden by their employer to serve. The individual chooses the extent to which they explain + their renunciation. + Renunciation is disqualification from participation, + not abstention, + and should not be used + to excuse an absence of participation.

+

Any person who has been dismissed or who renounces their seat + does not receive Council materials, + take part in its deliberations, + help in the determination of consensus, + or vote. + The W3C Council may still solicit and hear their testimony, + as they can of anyone else in the W3C community.

+
5.6.2.4. Unanimous Short Circuit
+

The full Council process may be short-circuited if + the Team recommends a resolution + and every potential member of a Council who is not renouncing their seat + votes affirmatively (no abstentions) to adopt this resolution.

+

This step may be run concurrently with § 5.6.2.3 Council Participation, Dismissal, and Renunciation and prior to choosing a Chair.

+

Note: This is intended for exceptional cases + that don’t seem to warrant a full Council response + because they are, for instance, too trivial, duplicative, etc.

+
5.6.2.5. Council Chairing
+

The Chair of each W3C Council is chosen by its members, + by consensus if possible, + falling back to a vote if that fails. + The chair must be a member of that W3C Council. + Chair selection happens during formation of each Council, + and must be re-run + if requested by the Council Team Contact or by the Chair during the Council’s operation.

+
5.6.2.6. Council Deliberations
+

Upon appointment of the W3C Council Chair and delivery of the Team’s report, + the W3C Council is considered to be convened + and can start deliberations.

+

Having reviewed the information gathered by the Team, + the Council may conduct additional research or analysis, + or request additional information or interviews from anyone, + including the Team.

+

The Council may further attempt to broker consensus, + which, if successful, disposes the formal objection.

+

Otherwise, + after sufficient deliberation, + the W3C Council decides whether to sustain or overrule the objection. + The W3C Council may overrule the Formal Objection even if it agrees with some of the supportive arguments.

+

When sustaining an objection, + it should recommend a way forward. + If the overturned decision has already had consequences + (e.g., if the objection concerns material already in a published document) + the Council should suggest how these consequences might be mitigated. + The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion; + and the Formal Objection is not considered fully addressed until then.

+

Note: This does not create new powers for the Team, + such as the ability to “unpublish” documents. + The Team's role is to ensure the responsible parties enact adequate mitigations, + by whatever means they already have at their disposal.

+

A Council may form sub-groups for deliberation, + who may return with a recommendation, + but the full Council issues the final decision. + The decision of the W3C Council should be unanimous, + and may be issued under consensus. + However, if despite careful deliberation + a W3C Council is unable to reach consensus, + the W3C Council Chair may instead resort to voting. + In that case, + the decision is made by simple majority, + with the W3C Council Chair breaking any tie. + In case of a vote, + if two members of a Council who share the same affiliation cast an identical ballot, + then their ballots count as a one vote, + not two.

+

In the case of non-unanimous decisions, + members of a W3C Council who disagree with the decision may write a Minority Opinion explaining the reason for their disagreement.

+

The deliberations of a W3C Council are confidential to that W3C Council and its Council Team Contact.

+

If a W3C Council is unable to come to a conclusion within 45 days of being convened, + the W3C Council Chair must inform the AC of this delay + and of the status of the discussions. + The W3C Council Chair may additionally make this report public.

+
5.6.2.7. Council Decision Report
+

A Council terminates by issuing a Council Report, + which:

+
    +
  • +

    must state whether the Council sustains or overrules the objection(s).

    +
  • +

    must provide a rationale supporting the decision, +which should address each argument raised in the Formal Objection(s).

    +
  • +

    must include any recommendation decided by the Council.

    +
  • +

    if the Formal Objection has been sustained, should include any suggested mitigations.

    +
  • +

    must include the Minority Opinion(s), if any.

    +
  • +

    must report the names of those who were dismissed or renounced their seat as well as those who were qualified to serve.

    +
  • +

    must report the names of the individuals who participated in the final decision.

    +
  • +

    may report vote totals, if any vote was held.

    +
  • +

    must not attribute any position to any individual on the Council.

    +
+

The Team must maintain a public page on the W3C website indexing all completed Council Reports. + If a Council decision is later overturned by an AC Appeal, + this must also be mentioned. Council Reports must be no more confidential + than the decision or document being objected to.

+

The Council may also issue a Supplemental Confidential Council Report with a more restricted level of confidentiality than its main report + when it believes that additional commentary on confidential aspects of the case + would be informative. + However, the main Council Report should be self-sufficient + and understandable without reference to Supplemental Confidential Council Reports.

+
5.6.2.8. Appealing Council Decisions
+

Advisory Committee representatives may initiate an Advisory Committee Appeal of a Council decision issued in a Council Report.

+

5.7. Advisory Committee Reviews

+

Advisory Committee review is the process + by which the Advisory Committee formally confers its approval + on charters, technical reports, + and other matters.

+

5.7.1. Start of a Review Period

+

Each Advisory Committee review period + begins with a Call for Review from the Team to the Advisory Committee. + The Call for Review describes the proposal, + raises attention to deadlines, + estimates when the decision will be available, + and includes other practical information. + Each Member organization may send one review, + which must be returned by its Advisory Committee representative.

+

For clarity, + in the context of an AC Review, dissent must be expressed as a Formal Objection.

+

The Team must provide two channels for Advisory Committee review comments:

+
    +
  1. an archived Team-only channel; +
  2. an archived Member-only channel. +
+

The Call for Review must specify + which channel is the default for review comments on that Call.

+

Reviewers may send information + to either or both channels. + A reviewer may also share their own reviews + with other Members on the Advisory Committee discussion list, + and may also make it available to the public.

+

A Member organization may modify its review + during a review period + (e.g., in light of comments from other Members).

+

5.7.2. After the Review Period

+

After the review period, + the Team determines the appropriate W3C Decision, + which they must announce to the Advisory Committee. + The announcement must indicate + the level of support for the proposal + (consensus or dissent), + and specifically + whether there were any Formal Objections, + with attention to changing the confidentiality level of the Formal Objections.

+

If there is dissent (i.e., there were Formal Objections, at least some of which were sustained) + or if there is not consensus because of insufficient support, W3C Decision must be one of:

+
    +
  • The proposal is returned for additional work, + with a request to the initiator to improve the proposal. +
  • The proposal is rejected. +
+

If the proposal has consensus, + or if any Formal Objections are retracted or overruled + and the proposal otherwise has sufficient support to achieve consensus, + this W3C Decision must be one of:

+
    +
  • The proposal is adopted, + possibly with additional changes integrated + in order to address the comments of the AC (see below). +
  • The proposal is returned for additional work, + with a request to the initiator to make desirable changes identified during the review + and to resubmit. +
+

If the proposal is adopted with changes other than class 1 (markup) changes, + then those changes must be announced to the AC and to the Group that owns the document (if any).

+

Additionally, when adopting a proposal with substantive changes integrated, + the announcement must include rationale + for the substantive changes, + and those changes must have the consensus of the subset of the AC that voted on the proposal + (including anyone who explicitly abstained). + For publications which have conditions in addition to AC approval + for introducing substantive changes (such as Group consensus or implementation experience), + those other conditions must also be re-fulfilled.

+
For example, to make substantive changes to a Proposed Recommendations, + the technical report could be returned to Candidate Recommendation. + Alternatively, the desired changes can be introduced as non-substantive amendments + using the process for revising a Recommendation. + However, they cannot be directly integrated between PR and REC, + because that would fail to trigger a patent exclusion opportunity.
+

This document does not specify + time intervals between the end of an Advisory Committee review period + and the W3C decision. + This is to ensure that the Members and Team have sufficient time to consider comments + gathered during the review. + The Advisory Committee should not expect an announcement + sooner than two weeks after the end of a review period. + If, after three weeks, the outcome has not been announced, + the Team should provide the Advisory Committee with an update.

+

5.8. Advisory Committee Votes

+

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, + and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. + Whenever the Advisory Committee votes, + each Member or group of related Members has one vote.

+

5.9. Appeal by Advisory Committee Representatives

+

Advisory Committee representatives may appeal certain decisions, + though appeals are only expected to occur in extraordinary circumstances.

+

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate + an Advisory Committee Appeal. + These W3C decisions include those related to group creation and modification, + and transitions to new maturity stages for Recommendation Track documents + and the Process document.

+

Advisory Committee representatives may also initiate an appeal + for decisions of a W3C Council, and + for certain decisions that do not involve an Advisory Committee review. + These cases are identified in the sections + which describe the requirements for the decision + and include + additional (non-reviewed) maturity stages of Recommendation Track documents, + group charter extensions and closures, + and Memoranda of Understanding.

+

In all cases, + an appeal must be initiated within three weeks of the decision.

+

An Advisory Committee representative initiates an appeal by sending a request to the Team, + and should also share this request with the Advisory Committee. + The request should say “I appeal this Decision” + and identify the decision, + and may also include their rationale for appealing the decision.

+

Note: See Appealing a W3C Decision for a recommendation + on how to communicate an appeal request to the Team and the AC.

+

Within one week the Team must announce the appeal process + to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. + The archive of these statements must be member-only. + If, within one week of the Team’s announcement, + 5% or more of the Advisory Committee support the appeal request, + the Team must organize an appeal vote + asking the Advisory Committee “Do you approve of the Decision?” + together with links to the decision and the appeal support.

+

The ballot must allow for three possible responses: + “Approve”, + “Reject”, + and “Abstain”, + together with Comments.

+

If the number of votes to reject + exceeds the number of votes to approve, + the decision is overturned. + In that case, there are the following possible next steps:

+
    +
  1. The proposal is rejected. +
  2. The proposal is returned for additional work, + after which the applicable decision process is re-initiated. +
+

6. W3C Technical Reports

+

The W3C technical report development process is the set of steps and requirements + followed by W3C Working Groups to standardize Web technology. + The W3C technical report development process is designed to:

+
    +
  • support multiple specification development methodologies +
  • maximize consensus about the content of stable technical reports +
  • ensure high technical and editorial quality +
  • promote consistency among specifications +
  • facilitate royalty-free, interoperable implementations of Web Standards, and +
  • earn endorsement by W3C and the broader community. +
+

See also “licensing goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

6.1. Types of Technical Reports

+

This chapter describes the formal requirements + for publishing and maintaining a W3C Recommendation, Note, + or Registry Report.

+
+
Recommendations +
Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines + as standards for the Web. + The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, + and consensus-building, + and is subject to the W3C Patent Policy [PATENT-POLICY], + under which participants commit to Royalty-Free IPR licenses for implementations. + See § 6.3 The W3C Recommendation Track for details. +
Notes +
Groups can also publish documents as W3C Notes and W3C Statements, + typically either to document information + other than technical specifications, + such as use cases motivating a specification + and best practices for its use. + See § 6.4 The Note Track (Notes and Statements) for details. +
Registries +
Working Groups can also publish registries in order to document collections of values or other data. + These are typically published in a separate registry report, + although they can also be directly embedded in Recommendation Track documents + as a registry section. Defining a registry requires wide review and consensus, + but once set up, changes to registry entries are lightweight + and can even be done without a Working Group. + See § 6.5 The Registry Track for details. +
+

Individual Working Groups and Interest Groups should adopt additional processes + for developing publications, + so long as they do not conflict with the requirements in this chapter.

+

6.2. General Requirements for Technical Reports

+

6.2.1. Publication of Technical Reports

+

Publishing as used in this document + refers to producing a version which is listed as a W3C Technical Report on its Technical Reports index at https://www.w3.org/TR [TR]. + Every document published as part of the technical report development process must be a public document. + W3C strives to make archival documents indefinitely available + at their original address in their original form.

+

Every document published as part of the technical report development process must clearly indicate its maturity stage, + and must include information about the status of the document. + This status information:

+
    +
  • must be unique each time a specification is published, +
  • must state which Working Group developed the specification, +
  • must state how to send comments or file bugs, + and where these are recorded, +
  • must include expectations about next steps, +
  • should explain how the technology relates to existing international standards + and related work inside or outside W3C, + and +
  • should explain + or link to + an explanation of significant changes from the previous version. +
+

Every Technical Report published + as part of the Technical Report development process + is edited by one or more editors + appointed by a Group Chair. + It is the responsibility of these editors to ensure that the decisions of the Group are + correctly reflected in subsequent drafts of the technical report. + An editor must be a participant, + per § 3.4.2 Participation in Chartered Groups in the Group responsible for the document(s) they are editing.

+

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, + status information, + style, + and copyright requirements). + These rules are subject to change by the Team from time to time. + The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

+

The primary language for W3C Technical Reports is English. + W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C website.

+

6.2.2. Reviews and Review Responsibilities

+

A document is available for review + from the moment it is first published. + Working Groups should formally address any substantive review comment + about a technical report in a timely manner.

+

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, + particularly if this would cause significant compatibility problems + due to existing implementation. Working Groups should record substantive + or interesting proposals raised by reviews + but not incorporated into a current specification.

+
6.2.2.1. Wide Review
+

The requirements for wide review are not precisely defined by the W3C Process. + The objective is to ensure that the entire set of stakeholders of the Web community, + including the general public, + have had adequate notice of the progress of the Working Group (for example through notices posted to public-review-announce@w3.org) + and were able to actually perform reviews of and provide comments on the specification. + A second objective is to encourage groups to request reviews + early enough that comments and suggested changes + can still be reasonably incorporated in response to the review. + Before approving transitions, + the Team will consider who has been explicitly offered + a reasonable opportunity to review the document, + who has provided comments, + the record of requests to and responses from reviewers, + especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter + or identified as liaisons [LIAISON], + and seek evidence of clear communication to the general public + about appropriate times and which content to review + and whether such reviews actually occurred.

+

For example, + inviting review of new or significantly revised sections published in Working Drafts, + and tracking those comments + and the Working Group's responses, + is generally a good practice which would often be considered positive evidence of wide review. Working Groups should follow the W3C Horizontal Groups’ review processes, + and should announce to other W3C Working Groups + as well as the general public, + especially those affected by this specification, + a proposal to enter Candidate Recommendation (for example in approximately 28 days). + By contrast a generic statement in a document + requesting review at any time + is likely not to be considered as sufficient evidence + that the group has solicited wide review.

+

A Working Group could present evidence that wide review has been received, + irrespective of solicitation. + But it is important to note that receiving many detailed reviews + is not necessarily the same as wide review, + since they might only represent comment + from a small segment of the relevant stakeholder community.

+

6.2.3. Classes of Changes

+

This document distinguishes the following 5 classes of changes to a document. + The first two classes of change are considered editorial changes, + the next two substantive changes, + and the last one registry changes.

+
+
+ +
    +
  1. +

    No changes to text content

    +
+
These changes include fixing broken links, style sheets, or invalid markup. +
+ +
    +
  1. +

    Changes that do not functionally affect interpretation of the document

    +
+
For Recommendation-track technical reports specifically, + this constitutes changes that do not affect conformance, + i.e. changes that reasonable implementers + would not interpret as changing architectural + or interoperability requirements + or their implementation. + Changes which resolve ambiguities in the specification + are considered to change (by clarification) the implementation requirements + and do not fall into this class. +
Examples of changes in this class include + correcting non-normative examples + which clearly conflict with normative requirements, + clarifying informative use cases or other non-normative text, + fixing typos or grammatical errors + where the change does not change requirements. +
If there is any doubt or disagreement + as to whether a change functionally affects interpretation, + that change does not fall into this class. +
+ +
    +
  1. +

    Other changes that do not add new features

    +
+
+ For Recommendation-track documents, + these changes may affect conformance to the specification. + A change that affects conformance is one that: +
    +
  • makes conforming data, processors, or other conforming agents become non-conforming according to the new version, + or +
  • makes non-conforming data, processors, or other agents become conforming, + or +
  • clears up an ambiguity or under-specified part of the specification + in such a way that data, + a processor, + or an agent + whose conformance was once unclear + becomes clearly either conforming or non-conforming. +
+
+ +
    +
  1. +

    New features

    +
+
Changes that add new functionality, + such as new elements, new APIs, new rules, etc. +
+ +
    +
  1. +

    Changes to the contents of a registry table

    +
+
Changes that add, remove, or alter registry entries in a registry table. +
+

6.2.4. Errata Management

+

Tracking errors is an important part of a Working Group's ongoing care of a technical report; + for this reason, + the scope of a Working Group charter generally allows time + for work after publication of a Recommendation. + In this Process Document, + the term “erratum” + (plural “errata”) refers to any error + that can be resolved by one or more changes in classes 1-3 + of section § 6.2.3 Classes of Changes.

+

Working Groups must keep + a public record of errors + that are reported by readers and implementers + for Recommendations. + Such error reports should be compiled + no less frequently than quarterly.

+

Working Groups decide how to document errata. + Such documentation must identify + the affected technical report text + and describe the error; + it may also describe some possible solution(s). + Readers of the technical report should be able easily + to find and see the errata + that apply to that specific technical report with their associated tests. + Errata may be documented + in a separate errata page or tracking system. + They may, + in addition or alternatively, + be annotated inline + alongside the affected technical report text + or at the start or end of the most relevant section(s).

+

6.2.5. Candidate Amendments

+

An erratum may be accompanied by an informative, candidate correction approved by group decision. + When annotated inline, + errata—including their candidate corrections—must be marked as such, + are treated as class 2 changes, + and are published accordingly.

+

Note: Annotating changes in this way allows more mature documents + such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, + even when the candidate amendments have not yet received + sufficient review or implementation experience + to be normatively incorporated into the specification proper.

+

A candidate addition is similar to a candidate correction, + except that it proposes a new feature + rather than an error correction.

+

If there is no group chartered to maintain a technical report, + the Team may maintain its errata and associated candidate corrections. + Such corrections must be marked + as Team correction, + and do not constitute + a normative portion of the Recommendation, + as defined in the Patent Policy [PATENT-POLICY] (i.e. they are not covered by the Patent Policy). + The Team must solicit wide review on Team corrections that it produces.

+

Candidate corrections and candidate additions are collectively known as candidate amendments.

+

In addition to their actual maturity stage, published REC Track documents with candidate amendments are also considered, + for the purpose of the W3C Patent Policy [PATENT-POLICY], + to be Working Drafts with those candidate amendments treated as normative.

+

6.2.6. License Grants from Non-Participants

+

When a party who is not already obligated under the Patent Policy + offers a change in class 3 or 4 + (as described in § 6.2.3 Classes of Changes) to a technical report under this process + the Team must request + a recorded royalty-free patent commitment; + for a change in class 4, the Team must secure such commitment. + Such commitment should cover, + at a minimum, + all the party’s Essential Claims both in the contribution, + and that become Essential Claims as a result of incorporating the contribution into the draft + that existed at the time of the contribution, + on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

+

6.3. The W3C Recommendation Track

+

Working Groups create specifications and guidelines + to complete the scope of work envisioned by a Working Group's charter. + These technical reports undergo cycles of revision and review + as they advance towards W3C Recommendation status. + Once review suggests the Working Group has met their requirements for a new standard, + including wide review, + a Candidate Recommendation phase + allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. + At the end of the process, + the Advisory Committee reviews the mature technical report, + and if there is support from its Membership, + W3C publishes it as a Recommendation.

+

In summary, the W3C Recommendation Track consists of:

+
    +
  1. Publication of the First Public Working Draft. +
  2. Publication of zero or more revised Working Drafts. +
  3. Publication of one or more Candidate Recommendations. +
  4. Publication of a Proposed Recommendation. +
  5. Publication as a W3C Recommendation. +
+
+ + Basic W3C Recommendation Track + + + + + First Public Working Draft (FPWD) - Exclusion opportunity + + + + WG decision + Team's approval + + + + + + + + + Working Draft (WD) + + + + + + + + Publish a new Working Draft + + + WG Decision: review needed, or + No change for 6 months + + + + + + + + + Advance to Candidate Recommendation + + Team's approval + + + + + + + + + + Candidate Recommendation Snapshot (CRS) - Patent Policy exclusion opportunity + + + + + + Candidate Recommendation Draft (CRD) + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation + + + WG Decision + + Team’s approval + + + + + + + + + Publish revised Candidate Recommendation + + + WG Decision + Team’s approval + + + + + + + + + + Advance to Proposed Recommendation + + Team's approval + + + + + + + + Return to Working Draft + + + WG or Team decision + e.g. for further review + + + + + + + + + + + Proposed Recommendation (PR) - Advisory Committee review + + + + + + + + Advance to Recommendation + + + Advisory Committee Review + Team's Decision + + + + + + + + + Return to Candidate Recommendation + + + AC Review, + Team Decision + e.g. for editorial changes + + + + + + + + + Return to Working Draft + + + Advisory Committee review and Team's Decision, e.g. for further work and review + + + + + + + + + + Recommendation (Rec) + + + + + +
+

This Process defines certain Recommendation Track publications as Patent Review Drafts. + Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004], + these correspond to “Last Call Working Draft” in the Patent Policy; + Starting from the 2020 Patent Policy [PATENT-POLICY-2020], + these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

+

W3C may end work on a technical report at any time.

+

As described in § 6.3.3 Advancement on the Recommendation Track, + the Team will decline a request to advance in maturity stage + and return the specification to a Working Group for further work + if it determines that the requirements for advancement + have not been met.

+

6.3.1. Maturity Stages on the Recommendation Track

+
+
Working Draft (WD) +
+ A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, + and other technical organizations, + and for simple historical reference. + Some, but not all, Working Drafts are meant to advance to Recommendation; + see the document status section of a Working Draft + for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, + and do not imply any endorsement by W3C + or its members beyond agreement to work on a general area of technology. + Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. + A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity. +

For all Working Drafts a Working Group:

+
    +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, + and +
  • may request publication of a Working Draft + even if its content is considered unstable + and does not meet all Working Group requirements. +
+

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), + and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

+
Candidate Recommendation (CR) +
+ A Candidate Recommendation is a document that satisfies the technical + requirements of the Working Group that produced it and their dependencies, + and has already received wide review. + W3C publishes a Candidate Recommendation to + +

Note: Advancing to Candidate Recommendation indicates + that the document is considered complete and fit for purpose, + and that no further refinement to the text is expected + without additional implementation experience and testing; + additional features in a later revision may however be expected. + A Candidate Recommendation is expected to be as well-written, + detailed, + self-consistent, + and technically complete + as a Recommendation, + and acceptable as such + if and when the requirements for further advancement are met.

+

Candidate Recommendation publications take one of two forms:

+
+
Candidate Recommendation Snapshot (CRS) +
+ A Candidate Recommendation Snapshot + corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. + Publishing a Patent Review Draft triggers a Call for Exclusions, + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy. +

Publication as a Candidate Recommendation Snapshot requires verification of either a Transition Request (for the first Candidate Recommendation publication from another maturity stage) + or an Update Request (for subsequent Candidate Recommendation Snapshots).

+
Candidate Recommendation Draft (CRD) +
+ A Candidate Recommendation Draft + is published on the W3C’s Technical Reports page [TR] to integrate changes from the previous Candidate Recommendation Snapshot that the Working Group intends to include + in a subsequent Candidate Recommendation Snapshot. + This allows for wider review of the changes + and for ease of reference to the integrated specification. +

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot. + However, the process requirements are minimized + so that the Working Group can easily keep the specification up to date.

+

A Candidate Recommendation Draft does not provide an exclusion opportunity; + instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

+
+

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered + such that W3C cannot endorse it or continue work on it, + for example due to burdensome patent claims that affect implementers and cannot be resolved + (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). + There is no path to restoration for a Rescinded Candidate Recommendation. + See “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

+
Proposed Recommendation (PR) +
A Proposed Recommendation is a document + that has been accepted by W3C + as of sufficient quality to become a W3C Recommendation. + This phase triggers formal review by the Advisory Committee, + who may recommend + that the document be published as a W3C Recommendation, + returned to the Working Group for further work, + or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation. +
W3C Recommendation (REC) +
+ A W3C Recommendation is a specification + or set of guidelines + or requirements that, + after extensive consensus-building, + has received the endorsement of W3C and its Members. + W3C recommends the wide deployment + of its Recommendations as standards for the Web. + The W3C Royalty-Free IPR licenses + granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. + As technology evolves, + a W3C Recommendation may become: +
+
A Superseded Recommendation +
+ A Superseded Recommendation is a specification + that has been replaced by a newer version + that W3C recommends for new adoption. + An Obsolete or Superseded specification + has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy. +

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, + the latest version replaces the previous one, + without the need to invoke the steps of § 6.3.13.3 Abandoning a W3C Recommendation: + it is the same document, updated. + Explicitly declaring a documented superseded, using the process documented in § 6.3.13.3 Abandoning a W3C Recommendation, + is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

+
An Obsolete Recommendation +
An Obsolete Recommendation is a specification + that W3C has determined lacks sufficient market relevance + to continue recommending it for implementation, + but which does not have fundamental problems + that would require it to be Rescinded. + If an Obsolete specification gains sufficient market relevance, + W3C may decide to restore it to Recommendation status. +
Rescinded Recommendation +
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, + and believes is unlikely to ever be restored to Recommendation status. + See also “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+
Discontinued Draft +
A technical report representing the state of a Recommendation-track document + at the point at which work on it was discontinued. + See § 6.3.13.1 Abandoning an Unfinished Recommendation. +
+

Only sufficiently technically mature work should be advanced.

+

Note: Should faster advancement to meet scheduling considerations be desired, + this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring + less stable features to other technical reports.

+

When publishing an updated version of an existing Candidate Recommendation or Recommendation, + technical reports are expected to meet the same maturity criteria as when they are first published under that status. + However, in the interest of replacing stale documents with improved ones in a timely manner, + if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, + it is also permissible to publish an updated CR or REC following the usual process, + even if only some of these flaws have been satisfactorily addressed.

+

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, + and do not necessarily imply consensus of a Working Group or Interest Group, + nor are their contents endorsed in any way by W3C.

+

6.3.2. Implementation Experience

+

Implementation experience is required to show that a specification is sufficiently clear, + complete, + and relevant to market needs, + to ensure that independent interoperable implementations + of each feature of the specification will be realized. + While no exhaustive list of requirements is provided here, + when assessing that there is adequate implementation experience the Team will consider (though not be limited to):

+
    +
  • is each feature of the current specification implemented, + and how is this demonstrated? +
  • are there independent interoperable implementations of the current specification? +
  • are there implementations created by people other than the authors of the specification? +
  • are implementations publicly deployed? +
  • is there implementation experience + at all levels of the specification’s ecosystem + (authoring, consuming, publishing…)? +
  • are there reports of difficulties or problems with implementation? +
+

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. + Groups are often able to work more effectively + if they plan how they will demonstrate interoperable implementations + early in the development process; + for example, developing tests in concert with implementation efforts.

+

6.3.3. Advancement on the Recommendation Track

+

For all requests to advance a specification + to a new maturity stage + (called Transition Requests), + the Working Group:

+
    +
  • must record the group’s decision to request advancement. +
  • must obtain Team verification. Team verification (a Team decision) must be withheld if any Process requirements are not met + or if there remain any unresolved Formal Objections + (including any sustained by a Council but not yet fully addressed), + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects a Transition Request it must indicate its rationale + to the Advisory Committee and the Working Group. +
  • must publicly document all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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 stage. +
  • must provide public documentation of any Formal Objections. +
  • should report which, if any, of the Working Group's requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

For a First Public Working Draft there is no “previous maturity stage”, + so many requirements do not apply, + and verification is normally fairly straightforward. + For later stages, + especially transition to Candidate or Proposed Recommendation, + there is usually a formal review meeting + to verify that the requirements have been met.

+

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved + while a Working Group's charter is undergoing or awaiting a decision + on an Advisory Committee Review.

+

+

6.3.4. Updating Mature Publications on the Recommendation Track

+

Certain requests to re-publish a specification + within its current maturity stage + (called Update Requests) + require extra verification. + For such update requests, the Working Group:

+
    +
  • must record the group’s decision to request the update. +
  • must show that the changes have received wide review. +
  • must obtain Team verification, + or fulfill the criteria for § 6.3.4.1 Streamlined Publication Approval. Team verification (a Team decision), should be withheld if any Process requirements are not met, + and may be withheld in consideration of unresolved Formal Objections + (including any sustained by a Council but not yet fully addressed) + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects an Update Request, + it must indicate its rationale to the Working Group. + If it waives any Process requirements, + it must indicate its rationale to the AC. +
  • must provide public documentation of any Formal Objections. +
  • must publicly document of all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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, + or explain why the requirements have changed or been deferred, +
  • should report which, if any, of the Working Group's requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

There is usually a formal review meeting + to verify that the requirements have been met.

+

Note: Update request verification is expected to be fairly simple + compared to verification of a transition request.

+

The Team must announce the publication + of the revised specification + to other W3C groups and the Public.

+
6.3.4.1. Streamlined Publication Approval
+

Note: These criteria are intentionally stricter than + the general requirements for an update request. + This is in order to minimize ambiguities and the need for expert judgment, + and to make self-evaluation practical.

+

In order to streamline the publication process in non-controversial cases, + verification of an update request is automatically granted without formal review + when the following additional criteria are fulfilled:

+
    +
  • There must have been no changes to Working Group requirements about this document. +
  • For each of the W3C Horizontal Groups [CHARTER], + if the Horizontal Review Group has made available a set criteria + under which their review is not necessary, + the Working Group must document that these criteria have been fulfilled. + Otherwise, the Working Group must show + that review from that group has been solicited and received. +
  • No Formal Objection has been registered against the document. +
  • + The Working Group must have formally addressed: +
      +
    • +

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

      +
    • +

      all issues raised against changes since the previous publication

      +
    • +

      all issues raised against the document that were closed since the previous publication with no change to the document

      +
    +

    The response to each of these issues must be to the satisfaction + 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.

    +

    Note: This is stricter than the general Transition Request criteria.

    +
+

Additionally, for updates to Recommendations with substantive changes or with new features:

+ +

The Working Group must provide written evidence for these claims, + and the Team must make these answers publicly and permanently available.

+

After publication, + if an AC Representative + or Team member + doubts that the evidence presented supports the claims, + they may request that a formal review meeting be convened post facto. + If that review finds that the requirements were not fulfilled, + the Team may revert the changes + by updating in place the status section to indicate that it has been reverted, + and by republishing the previously approved version of the technical report.

+

6.3.5. Publishing a First Public Working Draft

+

To publish the First Public Working Draft of a document, + a Working Group must meet the applicable requirements for advancement.

+

The Team must announce + the publication of a First Public Working Draft to other W3C groups and to the public.

+

6.3.6. Revising a Working Draft

+

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, + whose status section should indicate reasons for the lack of change.

+

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

+
    +
  • must record the group’s decision to request publication. Consensus is not required, + as this is a procedural step, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Working Draft, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous step, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups, +
+

Possible next steps for any Working Draft:

+ +

6.3.7. Transitioning to Candidate Recommendation

+

To publish a Candidate Recommendation, + in addition to meeting the requirements for advancement a Working Group:

+
    +
  • must show that the specification + has met all Working Group requirements, + or explain why the requirements have changed or been deferred, +
  • must document changes to dependencies during the development of the specification, +
  • must document + how adequate implementation experience will be demonstrated, +
  • must specify the deadline for comments, + delineating the Candidate Recommendation review period, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • must show that the specification has received wide review, and +
  • 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 Recommendation. +
+

The first Candidate Recommendation publication + after verification of having met the requirements for a Transition Request is always a Candidate Recommendation Snapshot. + The Team must announce + the publication of the Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

Possible next steps after a Candidate Recommendation Snapshot:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.8. Revising a Candidate Recommendation

+
6.3.8.1. Publishing a Candidate Recommendation Snapshot
+

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, + the Working Group must meet the requirements of an update request in order to republish.

+

In addition the Working Group:

+
    +
  • must specify the deadline for further comments, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • 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 Recommendation. +
+

The Team must announce + the publication of a revised Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

To provide timely updates and patent protection, + a Candidate Recommendation Snapshot should be published + within 24 months of the Working Group accepting + any proposal for a substantive change + (and preferably sooner). + To make scheduling reviews easier, + a Candidate Recommendation Snapshot should not be published + more often than approximately once every 6 months.

+

Note: Substantive changes trigger a new Exclusion Opportunity + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.8.2. Publishing a Candidate Recommendation Draft
+

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 + that would benefit from review beyond the Working Group.

+

To publish a revision of a Candidate Recommendation Draft, + a Working Group:

+
    +
  • must record the group’s decision to request publication, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups. +
+

Note: A Working Group does not need to + meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

+

Possible next steps after a Candidate Recommendation Draft:

+ +

6.3.9. Transitioning to Proposed Recommendation

+

In addition to meeting the requirements for advancement,

+
    +
  • The status information must specify the deadline for Advisory Committee review, + which must be at least 28 days + after the publication of the Proposed Recommendation and should be at least 10 days + after the end of the last Exclusion Opportunity + per ”Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+

A Working Group:

+ +

The Team:

+ +

Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on, + to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft.

+

A Proposed Recommendation may identify itself + as intending to allow new features (class 4 changes) + after its initial publication as a Recommendation, + as described in § 6.3.11.4 Revising a Recommendation: New Features. + Such an allowance cannot be added + to a technical report previously published as a Recommendation that did not allow such changes.

+

Possible Next Steps:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.10. Transitioning to W3C Recommendation

+

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

+

In addition to meeting the requirements for advancement,

+ +

Possible next steps: + A W3C Recommendation normally retains its status indefinitely. + However it may be:

+ +

6.3.11. Revising a W3C Recommendation

+

This section details the process for making changes to a Recommendation.

+
6.3.11.1. Revising a Recommendation: Markup Changes
+

A Working group may request republication of a Recommendation to make corrections that do not result + in any changes to the text of the specification. + (See class 1 changes.)

+

If there is no Working Group chartered to maintain a Recommendation, + the Team may republish the Recommendation with such changes incorporated.

+
6.3.11.2. Revising a Recommendation: Editorial Changes
+

Editorial changes to a Recommendation require no technical review of the intended changes. + A Working Group, + provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity stages. + (See class 2 changes.)

+

If there is no Working Group chartered to maintain a Recommendation, + the Team may republish the Recommendation with such changes incorporated, + including errata and Team corrections.

+
6.3.11.3. Revising a Recommendation: Substantive Changes
+

A candidate correction can be made normative + and be folded into the main text of the Recommendation, + once it has satisfied all the same criteria + as the rest of the Recommendation, + including review by the community to ensure + the technical and editorial soundness of the candidate amendments. + To validate this, the Working Group must request + a Last Call for Review of Proposed Amendments, + followed by an update request. + See § 6.3.11.5 Incorporating Candidate Amendments.

+

Alternatively, + a Working Group may incorporate the changes + and publish as a Working Draft—or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—and advance the specification from that state. + (See class 3 changes.)

+

Note: If there is no Working Group chartered to maintain a Recommendation the Team cannot make substantive changes and republish the Recommendation. + It can, however, informatively highlight problems and desirable changes + using errata and candidate corrections and republish as described in the previous section.

+
6.3.11.4. Revising a Recommendation: New Features
+

New features (see class 4 changes) + may be incorporated into a Recommendation explicitly identified as allowing new features using candidate additions. + A candidate addition can be made normative + and be folded into the main text of the Recommendation using the same process as for candidate amendments, + as detailed in § 6.3.11.3 Revising a Recommendation: Substantive Changes.

+

Note: This prohibition against new features unless explicitly allowed + enables third parties to depend on Recommendations having a stable feature-set, + as they have prior to the 2020 revision of this Process.

+

To make changes which introduce a new feature + to a Recommendation that does not allow new features, + W3C must create a new technical report, + following the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.

+
6.3.11.5. Incorporating Candidate Amendments
+

A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.

+

The Last Call for Review of Proposed Amendments must be announced to other W3C groups, the public, and the Advisory Committee. + The announcement must:

+
    +
  • Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, + or Last Call for Review of Proposed Corrections and Additions. +
  • Identify the specific candidate amendments under review + as proposed amendments (proposed corrections/proposed additions). +
  • Specify the deadline for review comments, + which must not be any sooner than 60 days from the Call for Review. +
  • Solicit review and, if it does not already have it, implementation experience. +
+

The combination of the existing Recommendation with the proposed amendments included in the Last Call for Review of Proposed Amendments is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. + Also, the review initiated by the Last Call for Review of Proposed Amendments is an Advisory Committee Review.

+

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

+

A Working Group may batch + multiple proposed amendments into a single Last Call for Review of Proposed Amendments. + To facilitate review, + a Last Call for Review of Proposed Amendments on a given specification should not be issued more frequently + than approximately once every 6 months.

+

At the end of the Last Call for Review of Proposed Amendments, + the W3C Decision may either be + to reject the proposed amendment, + or to clear the proposed amendment for advancement as is, + or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. + If the Working Group needs to amend a proposed amendment in response to review feedback + it must issue another Last Call for Review of Proposed Amendments on the revised change + before it can be incorporated into the main text.

+

Once all comments on a proposed amendment have been formally addressed, + and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, + it may incorporate the proposed amendment into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

+

To ensure adequate review of proposed amendment combinations, + only proposed amendments included in the most recent Last Call for Review of Proposed Amendments can be incorporated into the normative Recommendation text. + (Thus if incorporation of a proposed amendment is postponed, + it may need to be included in multiple Last Calls for Review of Proposed Amendments.)

+

6.3.12. Regression on the Recommendation Track

+

A Working Group may republish a Recommendation-track technical report at a lower maturity stage by fulfilling the requirements to transition to that maturity stage, + as described above.

+

Additionally, + with the approval of the TAG and the AB the Team may return + the technical report to a lower maturity stage in response to wide review or a formal objection.

+

6.3.13. Retiring Recommendation Track Documents

+

Work on a technical report may cease at any time. + Work should cease + if W3C or a Working Group determines + that it cannot productively carry the work any further.

+
6.3.13.1. Abandoning an Unfinished Recommendation
+

Any Recommendation-track technical report no longer intended + to advance or to be maintained, + and that is not being rescinded, should be published as a Discontinued Draft, + with no substantive change compared to the previous publication. + This can happen if + the Working Group decided + to abandon work on the report, + or as the result of an AC Review requiring the Working Group to discontinue work on the technical report before completion. + If a Working Group is made to close, + W3C must re-publish any unfinished technical report on the Recommendation track as Discontinued Draft.

+

Such a document should include in its status section + an explanation of why it was discontinued.

+

A Working Group may resume work + on such a technical report within the scope of its charter + at any time, + by re-publishing it as a Working Draft.

+
6.3.13.2. Rescinding a Candidate Recommendation
+

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

+
6.3.13.3. Abandoning a W3C Recommendation
+

It is possible that W3C decides + that implementing a particular Recommendation is no longer recommended. + There are three designations for such specifications, + chosen depending on the advice W3C wishes to give about further use of the specification.

+

W3C may obsolete a Recommendation, + for example if the W3C Community decides that the Recommendation no longer represents best practices, + or is not adopted and is not apparently likely to be adopted. + An Obsolete Recommendation may be restored to normal Recommendation, + for example because despite marking it Obsolete the specification is later more broadly adopted.

+

W3C may declare a Recommendation Superseded + if a newer version exists which W3C recommends for new adoption. + The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; + only the name and explanation change.

+

W3C may rescind a Recommendation + if W3C believes there is no reasonable prospect of it being restored + for example due to burdensome patent claims that affect implementers and cannot be resolved; + see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” + and “PAG Conclusion”.

+

W3C only rescinds, supersedes, or obsoletes entire Recommendations. + A Recommendation can be both superseded and obsolete. + To rescind, supersede, or obsolete some part of a Recommendation, + W3C follows the process for modifying a Recommendation.

+

Note: For the purposes of the W3C Patent Policy [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, + although it is not recommended for future implementation; + a Rescinded Recommendation ceases to be in effect + and no new licenses are granted under the Patent Policy.

+
+ + Supersede, Obsolete or Rescind a W3C Recommendation + + + + Recommendation (Rec) + + + + + A major problem and an AC review can lead to a Recommendation being Rescinded. + There are no new IPR licences issued under the W3C Patent Policy, + and reinstating the Recommendation requires going through the full Rec-track process again. + + Major problem, AC review + + + Rescinded Recommendation - no new IPR licenses + + + + + + + + + With little uptake, following AC review a specification may become an Obsolete Recommendation + + + + + Obsolete Recommendation + + + + + + + + If there is new uptake, with AC review an Obsolete Recommendation may return to normal Recommendation status + + + + + + + + + + + Replaced by a new version, AC review + + Superseded Recommendation + + + + + + + A Superseded Recommendation can become a normal Recommendation with AC review + + + + + + + + + + + +
+
6.3.13.4. Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
+

The process of rescinding, obsoleting, + superseding, + or restoring + a Recommendation can be initiated + either by a request from the Team or via a request from any of the following:

+
    +
  • The Working Group who produced, + or is chartered to maintain, + the Recommendation +
  • The TAG, if there is no such Working Group +
  • Any individual who made a request to the relevant Working Group as described above, + or the TAG if such a group does not exist, to obsolete, rescind, supersede, or restore a Recommendation, + where the request was not answered within 90 days +
  • 5% of the members of the Advisory Committee +
+

The Team must then + submit the request to the Advisory Committee for review. + For any Advisory Committee review of a proposal to + rescind, + obsolete, + supersede, + or restore + a Recommendation the Team must:

+
    +
  • announce the proposal to all Working Group Chairs, + and to the Public, + as well as to the Advisory Committee +
  • indicate that this is a proposal to + Rescind, + Obsolete, + Supersede, + or restore, + a Recommendation as appropriate +
  • identify the Recommendation by URL +
  • publish a rationale for the proposal +
  • identify known dependencies + and solicit review from all dependent Working Groups +
  • solicit public review +
  • specify the deadline for review comments, + which must be at least 28 days + after the announcement +
+

and should

+
    +
  • identify known implementations. +
+

If there was any dissent in the Advisory Committee review, + the Team must publish + the substantive content of the dissent to W3C and the public, + and must formally address the dissent + at least 14 days + before publication as an Obsolete or Rescinded Recommendation.

+

The Advisory Committee may initiate an Advisory Committee Appeal of the Team's decision.

+

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. + The updated version may remove the main body of the document. + The Status of this Document section should link + to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

+

Once W3C has published a Rescinded Recommendation, + future W3C technical reports must not include normative references + to that technical report.

+

Note: W3C strives to ensure that all Technical Reports + will continue to be available at their version-specific URL.

+

6.4. The Note Track (Notes and Statements)

+

6.4.1. Group Notes

+

A Group Note (NOTE) + is published + to provide a stable reference for a useful document + that is not intended to be a formal standard.

+

Working Groups, Interest Groups, + the TAG and the AB may publish work as Notes. + Examples include:

+
    +
  • supporting documentation for a specification, + such as explanations of design principles + or use cases and requirements +
  • non-normative guides to good practices +
+

Some Notes are developed through successive Draft Notes before publication as a full Notes, + while others are published directly as a Note. + There are few formal requirements to publish a document as a Note or Draft Note, + and they have no standing as a recommendation of W3C + but are simply documents preserved for historical reference.

+

Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Draft Notes.

+

6.4.2. Publishing Notes

+

In order to publish a Note or Draft Note, + the group:

+
    +
  • must record their decision + to request publication as a Note or Draft Note, and +
  • should publish documentation + of significant changes to the technical report + since any previous publication. +
+

Both Notes and Draft Notes can be updated by republishing + as a Note or Draft Note. + A technical report may remain + a Note indefinitely.

+

If a Note produced by a chartered group is no longer in scope for any group, + the Team may republish the Note with class 1 changes incorporated, + as well as with errata and Team corrections annotated.

+

6.4.3. Elevating Group Notes to W3C Statement status

+

A W3C Statement is a Note that has been endorsed by W3C as a whole. + In order to elevate a Note to W3C Statement status, + A group must:

+ +

A Note specifying implementable technology should not be elevated to W3C Statement status; + if it does, + the request to publish as a Statement must include rationale + for why it should be elevated, + and why it is not on the Recommendation track.

+

Once these conditions are fulfilled, + the Team must then + begin an Advisory Committee Review on the question of + whether the document is appropriate to publish as a W3C Statement. + During this review period, + the Note must not be updated.

+

The decision to advance a document to W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

The Team must announce the publication of a W3C Statement to the Advisory Committee, other W3C groups, and the public.

+

6.4.4. Revising W3C Statements

+

Given a recorded group decision to do so, + groups can request publication of a W3C Statement with editorial changes—including candidate amendment—without any additional process.

+

A candidate amendment can be folded into the main text of the W3C Statement, + once it has satisfied all the same criteria + as the rest of the Statement, + including review by the community to ensure + the substantive and editorial soundness of the candidate amendments. + To validate this, the group must request + an Advisory Committee review of the changes it wishes to incorporate. + The specific candidate amendments under review must be identified as proposed amendments just as in a Last Call for Review of Proposed Corrections.

+

The decision to incorporate proposed amendments into W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

6.5. The Registry Track

+

A registry documents a data set + consisting of one or more associated registry tables, + each table representing an updatable collection + of logically independent, consistently-structured registry entries. + A registry has three associated components:

+ +

The purposes of maintaining a registry can include:

+
+
non-collision +
Avoiding the problem + of two entities using the same value with different semantics. +
non-duplication +
Avoiding the problem + of having two or more different values in use with the same semantics. +
information +
Providing a central index + where anyone can find out + what a value means + and what its formal definition is + (and where it is). +
submission +
Ease of adding new terms, + including by stakeholders external to the custodian organization. +
consensus +
Promoting a clear consensus of the community on the terms. +
+

This section of the W3C Process provides a specialized process + facilitating the publication and maintenance of such registry tables, + particularly those required by or closely related to W3C Recommendations.

+

Note: Not every table in a specification is a potential registry. + If the intent or effect is that the table enumerates + all the possibilities the authors of the specification expect or envisage, + then the table by itself is enough. + Similarly, if the table is managed by the Working Group + and only updated as part of specification update, + then the complexities of registry management are not needed.

+

6.5.1. Registry Definitions

+

A registry definition defines what each registry table is and how it is maintained. + It must:

+
    +
  • Define the scope and purpose of each registry table. +
  • Define the fields of each registry table and their constraints + (e.g. values must be drawn from a defined set, or be unique, + or only reference publicly available resources, + etc.) +
  • + Define the policy for changes to existing entries, such as +
      +
    • whether entries can be deleted or deprecated +
    • whether entries can be changed after being published, and what kinds of changes are allowed +
    • whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely +
    +
  • Define the method and criteria by which changes are proposed, approved, and incorporated. + (For example, a registry could define + that changes to registry entries can be proposed using a particular web form or email address, + that they must be accompanied by certain background information, + or that they do or do not need to be approved by any member of a particular Working Group.) +
  • + Identify the custodian of the registry table: + the entity to which requests for registry changes must be sent, + and which is responsible for evaluating whether such requests + satisfy the criteria defined in the registry definition. +

    The custodian may be the Working Group, the Team, or a delegated entity. + The custodian for all registry tables in a single registry should generally be the same entity.

    +
+

6.5.2. Publishing Registries

+

Registries can be published either + as a stand-alone technical report on the Registry Track called a registry report, + or incorporated as part of a Recommendation as a registry section.

+

A registry report or registry section is purely documentational, + is not subject to the W3C Patent Policy, + and must not contain any requirements on implementations. + For the purposes of the Patent Policy [PATENT-POLICY], + any registry section in a Recommendation track document + is not a normative portion of that specification.

+

The registry report or registry section must:

+ +

The Team must make available + a means for interested parties to be notified of any updates to a registry table.

+

Note: Since the Process does not impose requirements + on changes to the contents of a registry table other than those imposed by the registry definition, + acceptance of proposed registry changes on behalf of the custodian and + publication of an updated registry report that contains + only registry changes since the previous publication + can be automated + if satisfaction of those rules can be automatically verified.

+

Rules for publication and advancement on the Registry Track are identical to that of the Recommendation Track with the following exceptions:

+ +

6.5.3. Updating Registry Tables

+

Changes to the contents of a registry table that are in accordance with the registry definition, + (i.e. Class 5 changes) + can be made by re-publishing the technical report that contains the affected table, + without needing to satisfy any other requirements for the publication + (not even Working Group consensus, unless this is required by the registry definition). + Such registry changes do not trigger new Advisory Committee Reviews, + nor Exclusion Opportunities, + and do not require verification via an update request, + even for technical reports at maturities where this would normally be expected. + Such publications can be made + even in the absence of a Working Group chartered to maintain the registry + when the custodian is another entity.

+

Note: The custodian is only empowered to make registry changes. + If the Working Group establishing the registry wishes + to empower the custodian to add commentary on individual entries, + this needs to be part of the registry table’s definition. + If other changes are desired, + they must be requested of the responsible Working Group—or in the absence of a Working Group, of the Team.

+

Changes to the registry tables made in accordance with candidate or proposed amendments to the registry definition which would not be allowed by the unamended registry definition must be identified as such.

+

6.5.4. Registry Data Reports

+

When the registry data is published in a separate technical report from its registry definition, + that report is called a Registry Data Report. + This technical report:

+ +

Registry Data Reports do not have maturity stages in and of themselves; + The maturity stage of the registry whose data they record + is that of the technical report holding the registry definition.

+

Anytime a change is made to a registry definition, + the Working Group must update and republish + any document holding the corresponding registry tables to make it consistent with these changes.

+

Given a recorded group decision to do so, + the Working Group may republish the Registry Data Report to incorporate editorial changes. + If there is no Working Group chartered to maintain this registry, + the Team may do so instead.

+

6.5.5. Specifications that Reference Registries

+

Registries document values, + they do not define any architectural or interoperability requirements + related to those values. + All architectural and interoperability requirements + pertaining to registry entries must be contained in the specifications that reference the registry, + and are therefore subject to the processes + (including approval and intellectual property provisions) + applicable to those referencing specifications.

+

If there are entries that must be implemented, + or any other such restrictions, + they must be defined or documented + in the referencing specification + without dependency on the registry.

+
For example, + “All implementations must implement the Basic-Method as defined in the registry” + is not acceptable; + a change to the definition of the Basic-Method in the registry would then affect conformance. + Instead, the requirement must be complete in the specification, + directly or by reference to another specification. + For example + “All implementations must recognize the name Basic-Method, + and implement it as defined by section yy of IETF RFC xxxx”. + (The Registry should nonetheless contain Basic-Method as an entry.)
+

6.6. Switching Tracks

+

Given a Group decision to do so, Working Groups can republish a technical report on a different track than the one it is on, + under the following restrictions:

+ +

Technical reports that switch tracks start at + their new track’s initial maturity stage, + while retaining any established identity (url, shortname, etc.).

+

6.7. Further reading

+

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews + and announcements of the various steps, + and tips on getting to Recommendation faster [REC-TIPS]. + Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

+

7. Dissemination Policies

+

7.1. Public Communication

+

The Team is responsible for managing communication within W3C + and with the general public + (e.g., news services, press releases, managing the website and access privileges, and managing calendars). + Members should solicit review by the Team + prior to issuing press releases about their work within W3C.

+

The Team makes every effort to ensure the persistence and availability of the following public information:

+
    +
  • W3C technical reports whose publication has been approved. + Per W3C IPR Policies, + W3C technical reports (and software) are available free of charge to the general public. +
  • A mission statement [MISSION] that explains the purpose and mission of W3C, + the key benefits for Members, + and the organizational structure of W3C. +
  • Legal documents, + including the Membership Agreement [MEMBER-AGREEMENT] and documentation of any legal commitments W3C has with other entities. +
  • The Process Document. +
  • Public results of W3C activities and Workshops. +
+

To keep the Members abreast of W3C meetings, Workshops, + and review deadlines, + the Team provides them with a regular (e.g., weekly) news service + and maintains a calendar [CALENDAR] of official W3C events. + Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

+

7.2. Confidentiality Levels

+

There are three principal levels of access to W3C information + (on the W3C website, in W3C meetings, etc.): + public, + Member-only, + and Team-only.

+

While much information made available by W3C is public, + “Member-only” information + is available to authorized parties only, + including representatives of Member organizations, Invited Experts, + the Advisory Board, + the TAG, + and the Team. + For example, + the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

+

“Team-only” information + is available to the Team and other authorized parties.

+

Those authorized to access Member-only and Team-only information:

+
    +
  • must treat the information as confidential within W3C, +
  • must use reasonable efforts to maintain the proper level of confidentiality, and +
  • must not release this information to the general public or press. +
+

The Team must provide mechanisms + to protect the confidentiality of Member-only information + and ensure that authorized parties have proper access to this information. + Documents should clearly indicate + whether they require Member-only confidentiality. + Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

+

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member + who are considered appropriate recipients. + For instance, + it is the responsibility of the Advisory Committee representative and other employees + and official representatives of the organization + to ensure that Member-only news announcements + are distributed for internal use only within their organization. + Information about Member mailing lists is available + in the New Member Orientation [INTRO].

+

7.3. Changing Confidentiality Level

+

As a benefit of membership, + W3C provides some Team-only and Member-only channels + for certain types of communication. + For example, Advisory Committee representatives can send reviews to a Team-only channel. + However, for W3C processes with a significant public component, + such as the technical report development process, + it is also important for information that affects decision-making to be publicly available. + The Team may need to communicate Team-only information to a Working Group or the public. + Similarly, a Working Group whose proceedings are Member-only must make public + information pertinent to the technical report development process.

+

This document clearly indicates which information must be available to Members or the public, + even though that information was initially communicated on Team-only or Member-only channels. + Only the Team and parties authorized by the Team + may change the level of confidentiality of this information. + When doing so:

+
    +
  1. The Team must use a version of the information + that was expressly provided by the author for the new confidentiality level. + In Calls for Review and other similar messages, + the Team should remind recipients to provide such alternatives. +
  2. The Team must not attribute the version + for the new confidentiality level to the author without the author’s consent. +
  3. If the author has not conveyed to the Team a version + that is suitable for another confidentiality level, + the Team may make available a version that reasonably communicates what is required, + while respecting the original level of confidentiality, + and without attribution to the original author. +
+

8. Workshops and Symposia

+

The Team organizes Workshops and Symposia to promote early involvement in the development of W3C activities + from Members and the public.

+

The goal of a Workshop is usually + either to convene experts and other interested parties for an exchange of ideas + about a technology or policy, + or to address the pressing concerns of W3C Members. + Organizers of the first type of Workshop may solicit position papers for the Workshop program + and may use those papers + to choose attendees and/or presenters.

+

The goal of a Symposium is usually + to educate interested parties about a particular subject.

+

The Call for Participation in a Workshop or Symposium may indicate participation requirements or limits, + and expected deliverables + (e.g., reports and minutes). + Organization of an event does not guarantee + further investment by W3C in a particular topic, + but may lead to proposals for new activities or groups.

+

Workshops and Symposia generally last one to three days. + If a Workshop is being organized to address the pressing concerns of Members, + the Team must issue the Call for Participation + no later than six weeks prior to the Workshop’s scheduled start date. + For other Workshops and Symposia, + the Team must issue a Call for Participation + no later than eight weeks prior to the meeting’s scheduled start date. + This helps ensure that speakers and authors + have adequate time to prepare position papers and talks.

+

9. Liaisons

+

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, + through a number of mechanisms + ranging from very informal + (e.g., an individual from another organization participates in a W3C Working Group, + or just follows its work) + to mutual membership, + to even more formal agreements. + Liaisons are not meant to substitute for W3C membership.

+

All liaisons must be coordinated by the Team due to requirements for public communication; + patent, + copyright, + and other IPR policies; + confidentiality agreements; + and mutual membership agreements.

+

W3C may negotiate technical agreements with another organization. + For purposes of the W3C Process, + a technical agreement is a formal contract, + or a Memorandum of Understanding (MoU), + or a similar document, + between W3C and another party or parties, + that relates to the technical activity of the Consortium + (e.g., its publications, groups, or liaisons). + It specifies rights and obligations of each party toward the others. + These rights and obligations may include joint deliverables, + an agreed share of technical responsibilities with due coordination, + and/or considerations for confidentiality and specific IPR.

+

Non-technical agreements, including + those between W3C and its Members for the purposes of membership, + between W3C and its Partners for the purposes of partnership [BYLAWS], + and other agreements related to the operation of the Consortium + or to the ordinary provision of services, + are not subject to these Process provisions.

+

When considering a technical agreement (i.e., before the decision whether to sign is made), + the Team should provide + the Advisory Committee with a draft of the proposed agreement, + along with an explanation of how W3C would benefit from signing this agreement, + for their review and discussion. + After addressing any comments, + and subject to any management or governance procedures that apply + (e.g., formal review of proposed contracts by legal counsel or by the Board), + if the Team decides to proceed with signing the agreement, + the Team must announce the intent to sign, + and provide the final text of the agreement, + with an explanation of signing rationale, to + the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the agreement. + If the proposal is rejected on appeal, + the Team must not sign the agreement on behalf of W3C + unless directed to do so by the Board. + A signed agreement should be made public.

+

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

+

10. Member Submission Process

+

The Member Submission process allows Members + to propose technology + or other ideas + for consideration by the Team. + After review, + the Team may make the material available at the W3C website. + The formal process affords Members a record of their contribution + and gives them a mechanism for disclosing the details of the transaction with the Team + (including IPR claims). + The Team also makes review comments on the Submitted materials available for W3C Members, + the public, + and the media.

+

A Member Submission consists of:

+
    +
  • One or more documents developed outside of the W3C process, and +
  • Information about the documents, + provided by the Submitter. +
+

One or more Members (called the Submitter(s)) may participate in a Member Submission. + Only W3C Members may be listed as Submitters.

+

The Submission process consists of the following steps:

+
    +
  1. One of the Submitters sends a request to the Team to acknowledge the Submission request. + The Team and Submitter(s) communicate to ensure that the Member Submission is complete. +
  2. + After review, the Team must either + acknowledge or reject the Submission request. + +
+
+ Note: To avoid confusion about the Member Submission process, please note that: + +
+

Making a Member Submission available at the W3C website + does not imply endorsement by W3C, + including the W3C Team or Members. + The acknowledgment of a Submission request + does not imply that any action will be taken by W3C. + It merely records publicly + that the Submission request has been made by the Submitter. + A Member Submission made available by W3C must not be referred to as “work in progress” of W3C.

+

The list of acknowledged Member Submissions [SUBMISSION-LIST] is available at the W3C website.

+

10.1. Submitter Rights and Obligations

+

When more than one Member jointly participates in a Submission request, + only one Member formally sends in the request. + That Member must copy + each of the Advisory Committee representatives of the other participating Members, + and each of those Advisory Committee representatives must confirm + (by email to the Team) + their participation in the Submission request.

+

At any time prior to acknowledgment, + any Submitter may withdraw support for a Submission request + (described in "How to send a Submission request" [SUBMISSION-REQ]). + A Submission request is “withdrawn” when no Submitter(s) support it. + The Team must not make statements + about withdrawn Submission requests.

+

Prior to acknowledgment, + the Submitter(s) must not, under any circumstances, + refer to a document as “submitted to the World Wide Web Consortium” + or “under consideration by W3C” or any similar phrase + either in public or Member communication. + The Submitter(s) must not imply + in public or Member communication + that W3C is working (with the Submitter(s)) on the material in the Member Submission. + The Submitter(s) may release the documents in the Member Submission to the public + prior to acknowledgment + (without reference to the Submission request).

+

After acknowledgment, + the Submitter(s) must not, under any circumstances, + imply W3C investment in the Member Submission + until, and unless, the material has been adopted as a deliverable + of a W3C Working Group.

+

10.1.1. Scope of Member Submissions

+

When a technology overlaps in scope with the work of a chartered Working Group, + Members should participate in the Working Group and contribute the technology to the group’s process + rather than seek publication through the Member Submission process. + The Working Group may incorporate the contributed technology into its deliverables. + If the Working Group does not incorporate the technology, + it should not publish the contributed documents + as Working Group Notes since Working Group Notes represent group output, + not input to the group.

+

On the other hand, + while W3C is in the early stages of developing a charter, + Members should use the Submission process + to build consensus around concrete proposals for new work.

+

Members should not submit materials + covering topics well outside the scope of W3C’s mission [MISSION].

+

10.1.2. Information Required in a Submission Request

+

The Submitter(s) + and any other authors of the submitted material must agree that, + if the request is acknowledged, + the documents in the Member Submission will be subject to the W3C Document License [DOC-LICENSE] and will include a reference to it. + The Submitter(s) may hold the copyright for the documents in a Member Submission.

+

The request must satisfy the Member Submission licensing commitments + in “Licensing Commitments in W3C Submissions” + in the W3C Patent Policy [PATENT-POLICY].

+

The Submitter(s) must include the following information:

+
    +
  • The list of all submitting Members. +
  • Position statements from all submitting Members (gathered by the Submitter). + All position statements must appear in a separate document. +
  • Complete electronic copies of any documents submitted for consideration + (e.g., a technical specification, + a position paper, + etc.) + If the Submission request is acknowledged, + these documents will be made available by W3C + and therefore must satisfy the Team’s Publication Rules [PUBRULES]. Submitters may hold the copyright for the material contained in these documents, + but when made available by W3C, + these documents must be subject to the provisions + of the W3C Document License [DOC-LICENSE]. +
+

The request must also answer the following questions.

+
    +
  • What proprietary technology is required to implement the areas addressed by the request, + and what terms are associated with its use? + Again, many answers are possible, + but the specific answer will affect the Team’s Decision. +
  • What resources, if any, + does the Submitter intend to make available + if W3C acknowledges the Submission request + and takes action on it? +
  • What action would the Submitter like W3C to take + if the Submission request is acknowledged? +
  • What mechanisms are there to make changes to the specification being submitted? + This includes, but is not limited to, + stating where change control will reside + if the request is acknowledged. +
+

For other administrative requirements related to Submission requests, + see “How to send a Submission request” [MEMBER-SUB].

+

10.2. Team Rights and Obligations

+

Although they are not technical reports, + the documents in a Member Submission must fulfill the requirements established by the Team, + including the Team’s Publication Rules [PUBRULES].

+

The Team sends a validation notice to the Submitter(s) + once the Team has reviewed a Submission request + and judged it complete and correct.

+

Prior to a decision to acknowledge or reject the request, + the request is Team-only, + and the Team must hold it in the strictest confidentiality. + In particular, + the Team must not comment to the media + about the Submission request.

+

10.3. Acknowledgment of a Submission Request

+

The Team acknowledges a Submission request + by sending an announcement to the Advisory Committee. + Though the announcement may be made at any time, + the Submitter(s) can expect an announcement between four to six weeks after the validation notice. + The Team must keep the Submitter(s) informed + of when an announcement is likely to be made.

+

Once a Submission request has been acknowledged, + the Team must:

+
    +
  • Make the Member Submission available at the W3C website. +
  • Make the Team comments about the Submission request available at the W3C website. +
+

If the Submitter(s) wishes to modify + a document made available as the result of acknowledgment, + the Submitter(s) must start the Submission process from the beginning, + even just to correct editorial changes.

+

10.4. Rejection of a Submission Request, and Submission Appeals

+

The Team may reject a Submission request + for a variety of reasons, + including any of the following:

+
    +
  • The ideas expressed in the request + overlap in scope with the work of a chartered Working Group, + and acknowledgment might jeopardize the progress of the group. +
  • The IPR statement made by the Submitter(s) is inconsistent with W3C’s + Patent Policy [PATENT-POLICY] and in particular the “Licensing Commitments in W3C Submissions”, Document License [DOC-LICENSE], + or other IPR policies. +
  • The ideas expressed in the request are poor, + might harm the Web, + or run counter to W3C’s mission [MISSION]. +
  • The ideas expressed in the request lie well outside the scope of W3C’s mission. +
+

In case of a rejection, + the Team must inform the Advisory Committee representative(s) + of the Submitter(s). + If requested by the Submitter(s), + the Team must provide rationale + to the Submitter(s) about the rejection. + Other than to the Submitter(s), + the Team must not make statements about why a Submission request was rejected.

+

The Advisory Committee representative(s) of the Submitters(s) may initiate a Submission Appeal. + The procedure for handling Submission Appeals is the same as for Formal Objections, + except that an AC Appeal is not possible + and both the Formal Objection and the Council Report are confidential to the Team, TAG, and AB.

+

11. Process Evolution

+

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, + with the Advisory Board—acting as the sponsoring Working Group. + The documents may be developed by the AB or by another group to whom the AB has delegated development. + Review includes + soliciting input from the W3C community, + and in particular the Team.

+

The documents covered by this section are:

+
    +
  • +

    the W3C Process (this document)

    +
  • +

    the W3C Patent Policy [PATENT-POLICY]

    +
  • +

    the W3C Code of Ethics and Professional Conduct [CEPC]

    +
  • +

    The W3C Document License [DOC-LICENSE]

    +
+

The Advisory Board initiates review as follows:

+
    +
  1. The Team sends a Call for Review to the Advisory Committee and other W3C groups. +
  2. After comments have been formally addressed and the document possibly modified, + the Team seeks endorsement from the Members by initiating an Advisory Committee review. + The review period must last at least 28 days. +
  3. After the Advisory Committee review, + following a W3C decision to adopt the document(s), + the Team does so + and sends an announcement to the Advisory Committee. + Advisory Committee representatives may initiate + an Advisory Committee Appeal to W3C. +
+

Note: As of June 2020, + the Patent Policy is developed in the Patents and Standards Interest Group, + the Code of Ethics and Professional Conduct in the Positive Work Environment Community Group, + and the Process in the W3C Process Community Group.

+

12. Acknowledgments

+

This section is non-normative.

+

The editors are grateful to the following people, + who as interested individuals and/or with the affiliation(s) listed, + have contributed to this proposal for a revised Process: + Brian Kardell, + Carine Bournez (W3C), + Charles McCathie Nevile (ConsenSys), + Chris Wilson (Google), + David Singer (Apple), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Elika J. Etemad aka fantasai, + Fuqiao Xue (W3C), + Jeff Jaffe (W3C), + Kevin Fleming (Bloomberg), + Léonie Watson (The Paciello Group), + Michael Champion (Microsoft), + Nigel Megitt (BBC), + Philippe Le Hégaret (W3C), + Ralph Swick (W3C), + Samuel Weiler (W3C), + Sandro Hawke (W3C), + Shawn Lawton Henry, + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Virginia Fournier (Apple), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

The editors are sorry for forgetting any names, + and grateful to those who have listened patiently to conversations about this document + without feeling a need to add more.

+

The following individuals contributed to the development of earlier versions of the Process: + Alex Russell (Google), + Andreas Tai (Institut fuer Rundfunktechnik), + Andrew Betts (Fastly), + Ann Bassetti (The Boeing Company), + Anne van Kesteren, + Art Barstow (Nokia, unaffiliated), + Bede McCall (MITRE), + Ben Wilson, + Brad Hill (Facebook), + Brian Kardell (JQuery), + Carine Bournez (W3C), + Carl Cargill (Netscape, Sun Microsystems, Adobe), + Chris Lilley (W3C), + Chris Wilson (Google), + Claus von Riegen (SAP AG), + Coralie Mercier (W3C), + Cullen Jennings (Cisco), + Dan Appelquist (Telefonica, Samsung), + Dan Connolly (W3C), + Daniel Dardailler (W3C), + Daniel Glazman (Disruptive Innovations), + David Baron (Mozilla), + David Fallside (IBM), + David Singer (Apple), + David Singer (IBM), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Don Brutzman (Web3D), + Don Deutsch (Oracle), + Eduardo Gutentag (Sun Microsystems), + Elika J. Etemad aka fantasai, + Florian Rivoal, + Fuqiao Xue (W3C), + Geoffrey Creighton (Microsoft), + Giri Mandyam (Qualcomm), + Gregg Kellogg, + Hadley Beeman, + Helene Workman (Apple), + Henri Sivonen (Mozilla), + Håkon Wium Lie (Opera Software), + Ian Hickson (Google), + Ian Jacobs (W3C), + Ivan Herman (W3C), + J Alan Bird (W3C), + Jay Kishigami 岸上順一 (NTT), + Jean-Charles Verdié (MStar), + Jean-François Abramatic (IBM, ILOG, W3C), + Jeff Jaffe (W3C), + Jim Bell (HP), + Jim Miller (W3C), + Joe Hall (CDT), + John Klensin (MCI), + Josh Soref (BlackBerry, unaffiliated), + Judy Brewer (W3C), + Judy Zhu 朱红儒 (Alibaba), + Kari Laihonen (Ericsson), + Karl Dubost (Mozilla), + Ken Laskey (MITRE), + Kevin Fleming (Bloomberg), + Klaus Birkenbihl (Fraunhofer Gesellschaft), + Larry Masinter (Adobe Systems), + Lauren Wood (unaffiliated), + Liam Quin (W3C), + Léonie Watson (The Paciello Group), + Marcos Cáceres (Mozilla), + Maria Courtemanche (IBM), + Mark Crawford (SAP), + Mark Nottingham, + Michael Champion (Microsoft), + Michael Geldblum (Oracle), + Mike West (Google), + Mitch Stoltz (EFF), + Natasha Rooney (GSMA), + Nigel Megitt (BBC), + Olle Olsson (SICS), + Ora Lassila (Nokia), + Paul Cotton (Microsoft), + Paul Grosso (Arbortext), + Peter Linss, + Peter Patel-Schneider, + Philippe Le Hégaret (W3C), + Qiuling Pan (Huawei), + Ralph Swick (W3C), + Renato Iannella (IPR Systems), + Rigo Wenning (W3C), + Rob Sanderson (J Paul Getty Trust), + Robin Berjon (W3C), + Sally Khudairi (W3C), + Sam Ruby (IBM), + Sam Sneddon, + Sandro Hawke (W3C), + Sangwhan Moon (Odd Concepts), + Scott Peterson (Google), + Steve Holbrook (IBM), + Steve Zilles (Adobe Systems) + Steven Pemberton (CWI), + TV Raman (Google), + Tantek Çelik (Mozilla), + Terence Eden (Her Majesty’s Government), + Thomas Reardon (Microsoft), + Tim Berners-Lee (W3C), + Tim Krauskopf (Spyglass), + Travis Leithead (Microsoft), + Virginia Fournier (Apple), + Virginie Galindo (Gemalto), + Wayne Carr (Intel), + Wendy Fong (Hewlett-Packard), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

13. Changes

+

This section is non-normative.

+

Changes since the 2 November 2021 Process

+

This document is based on the 2 November 2021 Process. + A list of issues addressed, + a diff from Process 2021 to this latest version, + as well as + a detailed log of all changes since then are available.

+

In addition to a number of editorial adjustments + and minor tweaks, + the following is a summary of the main differences:

+

Changes related to the role of the Director

+ +

Other Governance Changes

+
    +
  • The TAG now picks its own chair(s), + and the timing of AB and TAG chair selection is clarified. +
  • Appointed TAG seats now have consecutive term limits. +
  • Remove mentions of the Hosts, + add recognition of the existence of the W3C Inc. Board of Directors, + and adjust language for W3C being rooted in W3C Inc. +
  • Codify that the AB is expected to pick up to two of its participants + as liaisons for the board. +
  • Clarify interactions between AC / Team / Board about MoUs + (now called technical agreements). +
+

Other miscellaneous changes

+
    +
  • Improve the definition of consensus + to make the notion usable even in contexts + where Formal Objections would be inappropriate + (such as inside a W3C Council, + or when the TAG or AB pick their chair), + and to avoid circular definitions. +
  • Merge Chair Decision Appeal, Group Decision Appeal, and Formal Objection; + clarify what can be objected to. +
  • Define editorial vs substantive changes for non-REC-track documents. +
  • Expect supporting material to meeting minutes to be archived as the minutes are. +
  • Encourage people requesting an AC Appeal to share their request with the Advisory Committee in addition to the Team. +
  • Allow Recommendations to transition directly to Working Draft without having to go through Candidate Recommendation when making substantive changes. +
  • Place the W3C Document License under the same revision process and requirements as this document, the CEPC, or the Patent Policy. +
  • Similarly to the pre-existing requirement that a public record be made + about confidential Formal Objections about public things, + added a requirement that a member visible record be made + about confidential Formal Objections about member-visible things. +
  • Stop excluding comments from AC Reps from those that have to be addressed + while transitioning to Proposed Recommendation; + just because there will be an opportunity to address them later + doesn’t mean they shouldn’t be handled at the first opportunity. +
  • Clarify what the term Candidate Recommendation review period refers to. +
  • Clarify how the advance notice period for MoU works. +
  • Various bits of information that were so far required + to be included in announcements of charter extensions are covered in the group’s homepage, + making it sufficient to point to that page + rather than having to inline everything in the announcement. +
  • Be more rigorous in references to the Patent Policy, + using dated versions when appropriate. +
  • Rename “Member Consortia” into Member Associations to align with terminology in the Bylaws + (and to avoid confusion with W3C itself). +
  • Rename “maturity level” into “maturity stage”. +
+

Changes since earlier versions

+

Changes since earlier versions of the Process are detailed + in the changes section of the previous version of the Process.

+
+
+

Conformance

+

Document conventions

+

Conformance requirements are expressed + with a combination of descriptive assertions + and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text + with class="example", + like this:

+
+ +

This is an example of an informative example.

+
+

Informative notes begin with the word “Note” + and are set apart from the normative text + with class="note", + like this:

+

Note, this is an informative note.

+
+ +
+

Index

+

Terms defined by this specification

+ + + + +

Terms defined by reference

+ +

References

+

Normative References

+
+
[CEPC] +
W3C Code of Ethics and Professional Conduct. URL: https://www.w3.org/Consortium/cepc/ +
[COLLABORATORS-AGREEMENT] +
Invited expert and collaborators agreement. URL: https://www.w3.org/Consortium/Legal/collaborators-agreement +
[CONFLICT-POLICY] +
Conflict of Interest Policy for W3C Team Members Engaged in Outside Professional Activities. URL: https://www.w3.org/2000/09/06-conflictpolicy +
[DOC-LICENSE] +
W3C Document License. URL: https://www.w3.org/Consortium/Legal/copyright-documents +
[PATENT-POLICY] +
The W3C Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy/ +
[PATENT-POLICY-2004] +
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/ +
[PATENT-POLICY-2020] +
The W3C 2020 Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy-20200915/ +
[PUBRULES] +
Publication Rules. URL: https://www.w3.org/pubrules/ +
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
[RFC3797] +
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://www.rfc-editor.org/rfc/rfc3797 +
[W3C-PATENT-POLICY] +
Wendy Seltzer. W3C Patent Policy. 15 September 2020. URL: https://www.w3.org/Consortium/Patent-Policy/ +
[W3C-PROCESS] +
Elika J. Etemad (fantasai); Florian Rivoal. W3C Process Document. 2 November 2021. URL: https://www.w3.org/Consortium/Process/ +
+

Informative References

+
+
[AB-HP] +
The Advisory Board home page. URL: https://www.w3.org/2002/ab/ +
[AC-MEETING] +
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/Member/Meeting/ +
[BG-CG] +
Community and Business Group Process. URL: https://www.w3.org/community/about/process/ +
[BYLAWS] +
Amended and Restated Bylaws of World Wide Web Consortium, Inc.. URL: https://www.w3.org/2022/10/w3c-bylaws-20221019.pdf +
[CALENDAR] +
Calendar of all scheduled official W3C events. URL: https://www.w3.org/participate/eventscal +
[CHAIR] +
W3C Working/Interest Group Chair. URL: https://www.w3.org/Guide/chair/role.html +
[CHARTER] +
How to Create a Working Group or Interest Group. URL: https://www.w3.org/Guide/process/charter.html +
[COUNCIL-REPORT-INDEX] +
Council Report Index. URL: https://beta.w3.org/about/council/ +
[CURRENT-AC] +
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList +
[DECISION-APPEAL] +
Appealing a W3C Decision. URL: https://www.w3.org/Guide/process/ac-appeal +
[ELECTION-HOWTO] +
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/2002/10/election-howto +
[FELLOWS] +
W3C Fellows Program. URL: https://www.w3.org/Consortium/Recruitment/Fellows +
[GROUP-MAIL] +
Group mailing lists. URL: https://www.w3.org/groups/ +
[GUIDE] +
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/Guide/ +
[INTRO] +
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro +
[JOIN] +
How to Join W3C. URL: https://www.w3.org/Consortium/join +
[LIAISON] +
W3C liaisons with other organizations. URL: https://www.w3.org/2001/11/StdLiaison +
[MEMBER-AGREEMENT] +
W3C Membership Agreement. URL: https://www.w3.org/Consortium/Agreement/Member-Agreement +
[MEMBER-HP] +
Member website (Member-only access). URL: https://www.w3.org/Member/ +
[MEMBER-LIST] +
The list of current W3C Members. URL: https://www.w3.org/Consortium/Member/List +
[MEMBER-SUB] +
How to send a Submission request. URL: https://www.w3.org/2000/09/submission +
[MISSION] +
The W3C Mission statement. URL: https://www.w3.org/Consortium/mission +
[OBS-RESC] +
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/2016/11/obsoleting-rescinding/ +
[REC-TIPS] +
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/2002/05/rec-tips +
[REPUBLISHING] +
In-place modification of W3C Technical Reports. URL: https://www.w3.org/2003/01/republishing/ +
[SUBMISSION-LIST] +
The list of acknowledged Member Submissions. URL: https://www.w3.org/Submission/ +
[SUBMISSION-REQ] +
Make or Withdraw a Member Submission Request (Member-only access). URL: https://www.w3.org/2000/09/submission +
[TAG-CHARTER] +
Technical Architecture Group (TAG) Charter. URL: https://www.w3.org/2004/10/27-tag-charter.html +
[TAG-HP] +
The TAG home page. URL: https://www.w3.org/2001/tag/ +
[TEAM-CONTACT] +
Role of the Team Contact. URL: https://www.w3.org/Guide/teamcontact/role.html +
[TR] +
The W3C technical reports index. URL: https://www.w3.org/TR/ +
[TRANSITION] +
Organize a Technical Report Transition. URL: https://www.w3.org/Guide/transitions +
[TRANSLATION] +
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/ +
[W3C-IPR] +
W3C IPR Policies. URL: https://www.w3.org/Consortium/Legal/2002/ipr-notice-20021231 +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/snapshots/2023-05-24-doc.bsi b/snapshots/2023-05-24-doc.bsi new file mode 100644 index 00000000..22262dc5 --- /dev/null +++ b/snapshots/2023-05-24-doc.bsi @@ -0,0 +1,532 @@ +Draft: https://www.w3.org/Consortium/Process/Drafts/snapshots/2023-04 +Title: W3C Process Document 2023 (AC Review) + + + +

This Disposition of Comments covers comments received during the formal AC Review period for Process 2023. + +

Substantive Changes

+ +

Several review comments received during the AC Review period generated proposals for substantive changes: + +

+ +

Editorial Changes

+ +

AC Review raised a number of suggestions for clarification, +which the Process CG accepted and are summarized below: + +

+ +

Index of Comments and Responses

+ +---- +Issue 1. +Summary: Timeline for publishing formal objections +From: Jeffrey Yasskin +Comment: https://github.com/w3c/w3process/issues/735 +Closed: Deferred +Verified: https://github.com/w3c/w3process/issues/735 +---- +Issue 2. +Summary: Mention Archiving in Tooling section title +From: fantasai +Comment: https://github.com/w3c/w3process/issues/736 +Changes: https://github.com/w3c/w3process/commit/14f4644c9008bf10021628d78c3238a39b139e58 +Closed: Accepted +Verified: Reporter is editor +Resolved: Editorial +---- +Issue 3. +Summary: Improve wording of note about addressing FOs before advancement +From: Jeffrey Yasskin +Comment: https://github.com/w3c/w3process/issues/737 +Closed: Deferred +Verified: By AC comment +---- +Issue 4. +Summary: AC Review questionnaire option to express disagreement +From: Jeffrey Yasskin +Comment: https://github.com/w3c/w3process/issues/738 +Response: https://github.com/w3c/w3process/issues/738#issuecomment-1525644054 +Response: https://github.com/w3c/w3process/issues/738#issuecomment-1544643945 +Closed: Invalid +Verified: https://github.com/w3c/w3process/issues/738#issuecomment-1544662439 +---- +Issue 5. +Summary: FO resolution isn't explicitly invoked +From: Jeffrey Yasskin +Comment: https://github.com/w3c/w3process/issues/739 +Closed: Deferred +Verified: By AC comment +---- +Issue 6. +Summary: Clarify that AB/TAG approval uses their normal decision policy +From: Jeffrey Yasskin +Comment: https://github.com/w3c/w3process/issues/741 +Closed: Deferred +Verified: By AC comment +---- +Issue 7. +Summary: Clarify where Submission Appeals go +From: Jeffrey Yasskin +Comment: https://github.com/w3c/w3process/issues/742 +Response: https://github.com/w3c/w3process/issues/742#issuecomment-1544656020 +Changes: https://github.com/w3c/w3process/commit/189b5ec060b46094c70a3ff343cc0ddb7968e0de +Closed: Accepted +Verified: [reporter thumbs up on response] +Resolved: Bugfix +---- +Issue 8. +Summary: Remove normative keywords from non-normative notes +From: Jeffrey Yasskin +Comment: https://github.com/w3c/w3process/issues/745 +Closed: Deferred +Verified: https://github.com/w3c/w3process/issues/745 +---- +Issue 9. +Summary: Avoid two different meanings for “sustain” +From: Jeffrey Yasskin +Comment: https://github.com/w3c/w3process/issues/746 +Changes: https://github.com/w3c/w3process/pull/762 +Closed: Accepted +Resolved: Editorial +---- +Issue 10. +Summary: Clarify which formal contexts require FO for dissent +From: Chris Needham +Comment: https://github.com/w3c/w3process/issues/746#issuecomment-1549991610 +Response: https://github.com/w3c/w3process/issues/746#issuecomment-1553935933 +Changes: https://github.com/w3c/w3process/pull/763 +Closed: Accepted +Verified: Reporter is change author +Resolved: Editorial +---- +Issue 11. +Summary: Clarify purpose of dismissal +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/747 +Response: https://github.com/w3c/w3process/issues/747#issuecomment-1544708674 +Changes: https://github.com/w3c/w3process/pull/757/commits/4f20cd1b0ebb44b07987e8ceedbda4b8db382fb7 +Closed: Accepted +Verified: https://github.com/w3c/w3process/issues/747#issuecomment-1562212194 +---- +Issue 12. +Summary: “potential Council member” phrasing is wordy +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/747 +Response: https://github.com/w3c/w3process/issues/747#issuecomment-1544708674 +Response: https://github.com/w3c/w3process/issues/747#issuecomment-1545309505 +Closed: Rejected +Verified: https://github.com/w3c/w3process/issues/747#issuecomment-1562212194 +Resolved: Editorial +---- +Issue 13. +Summary: Note wrt nature of Council is oddly placed +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/747#issuecomment-1529019322 +Response: https://github.com/w3c/w3process/issues/747#issuecomment-1544708674 +Closed: Rejected +Verified: https://github.com/w3c/w3process/issues/747#issuecomment-1562212194 +Resolved: Editorial +---- +Issue 14. +Summary: Unclear antecedent for “they” +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/747#issuecomment-1529019871 +Changes: https://github.com/w3c/w3process/pull/757/commits/e23a195b5775231ea33ca169ec204217cf33948d +Closed: Accepted +Verified: https://github.com/w3c/w3process/issues/747#issuecomment-1562212194 +Resolved: Editorial +---- +Issue 15A. +Summary: Use supermajority for dismissal voting (instead of majority) +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/748 +Comment: https://github.com/w3c/w3process/issues/748#issuecomment-1529728892 +Response: https://github.com/w3c/w3process/issues/748#issuecomment-1529464611 +Response: https://github.com/w3c/w3process/issues/748#issuecomment-1530089344 +Response: https://github.com/w3c/w3process/issues/748#issuecomment-1545665413 +Changes: https://github.com/w3c/w3process/pull/760 +Closed: Rejected +Note: The AB resolved not to change the voting threshold, + but did resolve to make the dismissal vote counts public. +Resolved: AB May 2023 F2F +---- +Issue 15B. +Summary: Use single-person veto for dismissal (instead of majority) +From: Nigel Megitt +Comment: https://github.com/w3c/w3process/issues/748#issuecomment-1531724271 +Response: https://github.com/w3c/w3process/issues/748#issuecomment-1545665413 +Changes: https://github.com/w3c/w3process/pull/760 +Closed: Rejected +Note: The AB resolved not to change the voting threshold, + but did resolve to make the dismissal vote counts public. +Resolved: AB May 2023 F2F +---- +Issue 16. +Summary: Improve transparency of dismissal process +From: Advisory Board +Comment https://github.com/w3c/w3process/issues/748 +Response: https://github.com/w3c/w3process/issues/748#issuecomment-1545665413 +Changes: https://github.com/w3c/w3process/pull/760 +Open: Accepted by AB, proposed to the Director for either Process or /Guide +Note: As a result of the discussion in GitHub issue 748 (see above) + the AB resolved to require reporting dismissal vote counts, + to show the level of support or concern for the participation + of each member of the Council. +---- +Issue 17. +Summary: AB/TAG Decisions and Council Conflict of Interest +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/749 +Response: https://github.com/w3c/w3process/issues/749#issuecomment-1551892219 +Changes: https://github.com/w3c/w3process/pull/761 +Open: Accepted by AB, recommended to adopt into practice by CG +Note: The AB resolved not to remove the TAG/AB from the Council, + but to exclude them from a Council Decision vote (if any) + if the decision/proposal in question came from the TAG/AB. + They may still participate in a consensus Council Decision. +Note: The Council can always delegate in cases where it feels that + would provide a more legitimate decision; and the AC still + retains the ability to appeal a Council Decision if necessary. +Resolved: AB May 2023 F2F +---- +Issue 18. +Summary: Expressing disagreement in AC review without Formal Objection +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/750 +Response: https://github.com/w3c/w3process/issues/750#issuecomment-1529053389 +Closed: Retracted +---- +Issue 19A. +Summary: Council/Team Powers of Mitigation too broad +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/751 +Response: https://github.com/w3c/w3process/issues/751#issuecomment-1529453863 +Comment: https://github.com/w3c/w3process/issues/751#issuecomment-1554703461 +Response: https://github.com/w3c/w3process/issues/751#issuecomment-1559068321 +Closed: Invalid +Verified: https://github.com/w3c/w3process/issues/751#issuecomment-1563685512 +---- +Issue 19B. +Summary: Limits on Council/Team Powers of Mitigation hard to understand +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/751#issuecomment-1560306816 +Response: https://github.com/w3c/w3process/issues/751#issuecomment-1560492526 +Closed: Deferred +Verified: https://github.com/w3c/w3process/issues/751#issuecomment-1563685512 +---- +Issue 20. +Summary: Publication of Minority opinions +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/752 +Response: https://github.com/w3c/w3process/issues/752#issuecomment-1529175671 +Closed: Retracted +---- +Issue 21. +Summary: Why is AC review of MoU appeal-based rather than approval-based? +From: Mark Nottingham +Comment: https://github.com/w3c/w3process/issues/753 +Response: https://github.com/w3c/w3process/issues/753#issuecomment-1529194913 +Response: https://github.com/w3c/w3process/issues/753#issuecomment-1530815822 +Closed: Deferred +Verified: https://github.com/w3c/w3process/issues/753#issuecomment-1530815822 +---- +Issue 22. +Summary: Define “joint deliverables” +From: Eric Siow +Comment: https://github.com/w3c/w3process/issues/754 +Response: https://github.com/w3c/w3process/issues/754#issuecomment-1532480890 +Closed: Deferred +Verified: https://github.com/w3c/w3process/issues/754 +---- +Issue 23. +Summary: What to do in case of non-responsiveness during FO resolution +From: Philippe Le Hegaret +Comment: https://github.com/w3c/w3process/issues/755 +Response: https://github.com/w3c/w3process/issues/755#issuecomment-1551893751 +Closed: OutOfScope +Note: The AB resolved that /Guide should advise the Team to spin up + the Council after a reasonable timeout when the objector or + decider is non-responsive while trying to broker consensus or + clarify their position. +Verified: Reporter is co-chair +Resolved: AB May 2023 F2F +---- +Issue 24. +Summary: Increase size of TAG +From: Theresa O'Connor +Comment: https://github.com/w3c/AB-memberonly/issues/171 +Comment: https://github.com/w3c/w3process/issues/465 +Comment: https://github.com/w3c/AB-memberonly/issues/171#issuecomment-1517110155 +Comment: https://github.com/w3c/AB-memberonly/issues/171#issuecomment-1517166312 +Response: https://github.com/w3c/AB-memberonly/issues/171#issuecomment-1551895803 +Changes: https://github.com/w3c/w3process/pull/733 +Open: Accepted by AB, proposed to Director +Resolved: AB May 2023 F2F +---- +Issue 25. +Summary: Council composition is broken due to “member” vs “participant” +From: Tantek Çelik +Comment: https://github.com/w3c/w3process/issues/764 +Response: https://github.com/w3c/w3process/issues/764#issuecomment-1562177663 +Closed: Invalid +Verified: https://github.com/w3c/w3process/issues/764#issuecomment-1562300254 +---- +Issue 26. +Summary: Various Objections +From: James Rosewell +Comment: See https://www.w3.org/2002/09/wbs/33280/Process-2023/results +Open: Formal Objection; deferred to the Director +---- +Issue 27. +Summary: Various Concerns +From: Jon Andrieu +Comment: See https://www.w3.org/2002/09/wbs/33280/Process-2023/results +Note: Needs specific issues / discussion to be actionable +Open: Deferred ; needs Team response +---- +Issue 28. +Summary: Clarify informative nature of references +From: Tantek Çelik +Comment: https://github.com/w3c/w3process/issues/765 +Response: https://github.com/w3c/w3process/pull/766 +Closed: Approved by the Director +---- diff --git a/snapshots/2023-05-24-doc.html b/snapshots/2023-05-24-doc.html new file mode 100644 index 00000000..2e4de579 --- /dev/null +++ b/snapshots/2023-05-24-doc.html @@ -0,0 +1,575 @@ + + +W3C Process Document 2023 (AC Review) Disposition of Comments for 2023-05-24- Draft + + +

W3C Process Document 2023 (AC Review) Disposition of Comments for 2023-05-24- Draft

+ +
+
Dated Draft:
https://www.w3.org/Consortium/Process/Drafts/snapshots/2023-04 +
Editor's Draft:
https://www.w3.org/Consortium/Process/Drafts/ +
+ + +

This Disposition of Comments covers comments received during the formal AC Review period for Process 2023. +

Substantive Changes

+

Several review comments received during the AC Review period generated proposals for substantive changes: +

+

Editorial Changes

+

AC Review raised a number of suggestions for clarification, +which the Process CG accepted and are summarized below: +

+

Index of Comments and Responses

+ + +
+ Disposition Status Legend and Filters +

The following color coding convention is used for comments:

+ + + +

Open issues are marked like this

+ +

An issue can be closed as Accepted, OutOfScope, + Invalid, Rejected, or Retracted. + Verified indicates commentor's acceptance of the response.

+
+
+Issue 1. #
+Summary:  Timeline for publishing formal objections
+From:     Jeffrey Yasskin
+Comment:  https://github.com/w3c/w3process/issues/735
+Closed:   Deferred
+Verified: https://github.com/w3c/w3process/issues/735
+
+Issue 2. #
+Summary:  Mention Archiving in Tooling section title
+From:     fantasai
+Comment:  https://github.com/w3c/w3process/issues/736
+Changes:  https://github.com/w3c/w3process/commit/14f4644c9008bf10021628d78c3238a39b139e58
+Closed:   Accepted
+Verified: Reporter is editor
+Resolved: Editorial
+
+Issue 3. #
+Summary:  Improve wording of note about addressing FOs before advancement
+From:     Jeffrey Yasskin
+Comment:  https://github.com/w3c/w3process/issues/737
+Closed:   Deferred
+Verified: By AC comment
+
+Issue 4. #
+Summary:  AC Review questionnaire option to express disagreement
+From:     Jeffrey Yasskin
+Comment:  https://github.com/w3c/w3process/issues/738
+Response: https://github.com/w3c/w3process/issues/738#issuecomment-1525644054
+Response: https://github.com/w3c/w3process/issues/738#issuecomment-1544643945
+Closed:   Invalid
+Verified: https://github.com/w3c/w3process/issues/738#issuecomment-1544662439
+
+Issue 5. #
+Summary:  FO resolution isn't explicitly invoked
+From:     Jeffrey Yasskin
+Comment:  https://github.com/w3c/w3process/issues/739
+Closed:   Deferred
+Verified: By AC comment
+
+Issue 6. #
+Summary:  Clarify that AB/TAG approval uses their normal decision policy
+From:     Jeffrey Yasskin
+Comment:  https://github.com/w3c/w3process/issues/741
+Closed:   Deferred
+Verified: By AC comment
+
+Issue 7. #
+Summary:  Clarify where Submission Appeals go
+From:     Jeffrey Yasskin
+Comment:  https://github.com/w3c/w3process/issues/742
+Response: https://github.com/w3c/w3process/issues/742#issuecomment-1544656020
+Changes:  https://github.com/w3c/w3process/commit/189b5ec060b46094c70a3ff343cc0ddb7968e0de
+Closed:   Accepted
+Verified: [reporter thumbs up on response]
+Resolved: Bugfix
+
+Issue 8. #
+Summary:  Remove normative keywords from non-normative notes
+From:     Jeffrey Yasskin
+Comment:  https://github.com/w3c/w3process/issues/745
+Closed:   Deferred
+Verified: https://github.com/w3c/w3process/issues/745
+
+Issue 9. #
+Summary:  Avoid two different meanings for “sustain”
+From:     Jeffrey Yasskin
+Comment:  https://github.com/w3c/w3process/issues/746
+Changes:  https://github.com/w3c/w3process/pull/762
+Closed:   Accepted
+Resolved: Editorial
+
+Issue 10. #
+Summary:  Clarify which formal contexts require FO for dissent
+From:     Chris Needham
+Comment:  https://github.com/w3c/w3process/issues/746#issuecomment-1549991610
+Response: https://github.com/w3c/w3process/issues/746#issuecomment-1553935933
+Changes:  https://github.com/w3c/w3process/pull/763
+Closed:   Accepted
+Verified: Reporter is change author
+Resolved: Editorial
+
+Issue 11. #
+Summary:  Clarify purpose of dismissal
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/747
+Response: https://github.com/w3c/w3process/issues/747#issuecomment-1544708674
+Changes:  https://github.com/w3c/w3process/pull/757/commits/4f20cd1b0ebb44b07987e8ceedbda4b8db382fb7
+Closed:   Accepted
+Verified: https://github.com/w3c/w3process/issues/747#issuecomment-1562212194
+
+Issue 12. #
+Summary:  “potential Council member” phrasing is wordy
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/747
+Response: https://github.com/w3c/w3process/issues/747#issuecomment-1544708674
+Response: https://github.com/w3c/w3process/issues/747#issuecomment-1545309505
+Closed:   Rejected
+Verified: https://github.com/w3c/w3process/issues/747#issuecomment-1562212194
+Resolved: Editorial
+
+Issue 13. #
+Summary:  Note wrt nature of Council is oddly placed
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/747#issuecomment-1529019322
+Response: https://github.com/w3c/w3process/issues/747#issuecomment-1544708674
+Closed:   Rejected
+Verified: https://github.com/w3c/w3process/issues/747#issuecomment-1562212194
+Resolved: Editorial
+
+Issue 14. #
+Summary:  Unclear antecedent for “they”
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/747#issuecomment-1529019871
+Changes:  https://github.com/w3c/w3process/pull/757/commits/e23a195b5775231ea33ca169ec204217cf33948d
+Closed:   Accepted
+Verified: https://github.com/w3c/w3process/issues/747#issuecomment-1562212194
+Resolved: Editorial
+
+Issue 15A. #
+Summary:  Use supermajority for dismissal voting (instead of majority)
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/748
+Comment:  https://github.com/w3c/w3process/issues/748#issuecomment-1529728892
+Response: https://github.com/w3c/w3process/issues/748#issuecomment-1529464611
+Response: https://github.com/w3c/w3process/issues/748#issuecomment-1530089344
+Response: https://github.com/w3c/w3process/issues/748#issuecomment-1545665413
+Changes:  https://github.com/w3c/w3process/pull/760
+Closed:   Rejected
+Note:     The AB resolved not to change the voting threshold,
+          but did resolve to make the dismissal vote counts public.
+Resolved: AB May 2023 F2F
+
+Issue 15B. #
+Summary:  Use single-person veto for dismissal (instead of majority)
+From:     Nigel Megitt
+Comment:  https://github.com/w3c/w3process/issues/748#issuecomment-1531724271
+Response: https://github.com/w3c/w3process/issues/748#issuecomment-1545665413
+Changes:  https://github.com/w3c/w3process/pull/760
+Closed:   Rejected
+Note:     The AB resolved not to change the voting threshold,
+          but did resolve to make the dismissal vote counts public.
+Resolved: AB May 2023 F2F
+
+Issue 16. #
+Summary:  Improve transparency of dismissal process
+From:     Advisory Board
+Comment   https://github.com/w3c/w3process/issues/748
+Response: https://github.com/w3c/w3process/issues/748#issuecomment-1545665413
+Changes:  https://github.com/w3c/w3process/pull/760
+Open:     Accepted by AB, proposed to the Director for either Process or /Guide
+Note:     As a result of the discussion in GitHub issue 748 (see above)
+          the AB resolved to require reporting dismissal vote counts,
+          to show the level of support or concern for the participation
+          of each member of the Council.
+
+Issue 17. #
+Summary:  AB/TAG Decisions and Council Conflict of Interest
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/749
+Response: https://github.com/w3c/w3process/issues/749#issuecomment-1551892219
+Changes:  https://github.com/w3c/w3process/pull/761
+Open:     Accepted by AB, recommended to adopt into practice by CG
+Note:     The AB resolved not to remove the TAG/AB from the Council,
+          but to exclude them from a Council Decision vote (if any)
+          if the decision/proposal in question came from the TAG/AB.
+          They may still participate in a consensus Council Decision.
+Note:     The Council can always delegate in cases where it feels that
+          would provide a more legitimate decision; and the AC still
+          retains the ability to appeal a Council Decision if necessary.
+Resolved: AB May 2023 F2F
+
+Issue 18. #
+Summary:  Expressing disagreement in AC review without Formal Objection
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/750
+Response: https://github.com/w3c/w3process/issues/750#issuecomment-1529053389
+Closed:   Retracted
+
+Issue 19A. #
+Summary:  Council/Team Powers of Mitigation too broad
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/751
+Response: https://github.com/w3c/w3process/issues/751#issuecomment-1529453863
+Comment:  https://github.com/w3c/w3process/issues/751#issuecomment-1554703461
+Response: https://github.com/w3c/w3process/issues/751#issuecomment-1559068321
+Closed:   Invalid
+Verified: https://github.com/w3c/w3process/issues/751#issuecomment-1563685512
+
+Issue 19B. #
+Summary:  Limits on Council/Team Powers of Mitigation hard to understand
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/751#issuecomment-1560306816
+Response: https://github.com/w3c/w3process/issues/751#issuecomment-1560492526
+Closed:   Deferred
+Verified: https://github.com/w3c/w3process/issues/751#issuecomment-1563685512
+
+Issue 20. #
+Summary:  Publication of Minority opinions
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/752
+Response: https://github.com/w3c/w3process/issues/752#issuecomment-1529175671
+Closed:   Retracted
+
+Issue 21. #
+Summary:  Why is AC review of MoU appeal-based rather than approval-based?
+From:     Mark Nottingham
+Comment:  https://github.com/w3c/w3process/issues/753
+Response: https://github.com/w3c/w3process/issues/753#issuecomment-1529194913
+Response: https://github.com/w3c/w3process/issues/753#issuecomment-1530815822
+Closed:   Deferred
+Verified: https://github.com/w3c/w3process/issues/753#issuecomment-1530815822
+
+Issue 22. #
+Summary:  Define “joint deliverables”
+From:     Eric Siow
+Comment:  https://github.com/w3c/w3process/issues/754
+Response: https://github.com/w3c/w3process/issues/754#issuecomment-1532480890
+Closed:   Deferred
+Verified: https://github.com/w3c/w3process/issues/754
+
+Issue 23. #
+Summary:  What to do in case of non-responsiveness during FO resolution
+From:     Philippe Le Hegaret
+Comment:  https://github.com/w3c/w3process/issues/755
+Response: https://github.com/w3c/w3process/issues/755#issuecomment-1551893751
+Closed:   OutOfScope
+Note:     The AB resolved that /Guide should advise the Team to spin up
+          the Council after a reasonable timeout when the objector or
+          decider is non-responsive while trying to broker consensus or
+          clarify their position.
+Verified: Reporter is co-chair
+Resolved: AB May 2023 F2F
+
+Issue 24. #
+Summary:  Increase size of TAG
+From:     Theresa O'Connor
+Comment:  https://github.com/w3c/AB-memberonly/issues/171
+Comment:  https://github.com/w3c/w3process/issues/465
+Comment:  https://github.com/w3c/AB-memberonly/issues/171#issuecomment-1517110155
+Comment:  https://github.com/w3c/AB-memberonly/issues/171#issuecomment-1517166312
+Response: https://github.com/w3c/AB-memberonly/issues/171#issuecomment-1551895803
+Changes:  https://github.com/w3c/w3process/pull/733
+Open:     Accepted by AB, proposed to Director
+Resolved: AB May 2023 F2F
+
+Issue 25. #
+Summary:  Council composition is broken due to “member” vs “participant”
+From:     Tantek Çelik
+Comment:  https://github.com/w3c/w3process/issues/764
+Response: https://github.com/w3c/w3process/issues/764#issuecomment-1562177663
+Closed:   Invalid
+Verified: https://github.com/w3c/w3process/issues/764#issuecomment-1562300254
+
+Issue 26. #
+Summary:  Various Objections
+From:     James Rosewell
+Comment:  See https://www.w3.org/2002/09/wbs/33280/Process-2023/results
+Open:     Formal Objection; deferred to the Director
+
+Issue 27. #
+Summary:  Various Concerns
+From:     Jon Andrieu
+Comment:  See https://www.w3.org/2002/09/wbs/33280/Process-2023/results
+Note:     Needs specific issues / discussion to be actionable
+Open:     Deferred ; needs Team response
+
+Issue 28. #
+Summary:  Clarify informative nature of references
+From:     Tantek Çelik
+Comment:  https://github.com/w3c/w3process/issues/765
+Response: https://github.com/w3c/w3process/pull/766
+Closed:   Approved by the Director
+ diff --git a/snapshots/2023-06-12.html b/snapshots/2023-06-12.html new file mode 100644 index 00000000..42945755 --- /dev/null +++ b/snapshots/2023-06-12.html @@ -0,0 +1,7091 @@ + + + + + W3C Process Document + + + + + + + + + + + + + + + +
+

+

W3C Process Document

+

Draft Community Group Report,

+
+
+
This version: +
https://www.w3.org/Consortium/Process/Drafts/snapshots/2023-06-12 +
Latest published version: +
https://www.w3.org/Consortium/Process/ +
Editor's Draft: +
https://www.w3.org/Consortium/Process/Drafts/ +
Previous Versions: +
+
+
+
+
+
Feedback: +
Github (preferred) +
Public mailing list +
Member-only mailing list +
Editors: +
Elika J. Etemad / fantasai (Invited Expert) +
Florian Rivoal (Invited Expert) +
Former Editors: +
Natasha Rooney (Invited Expert) +
Charles McCathie Nevile (Yandex) +
Ian Jacobs (W3C) +
+
+
+

Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

+
+
+
+

Abstract

+

The mission of the World Wide Web Consortium (W3C) is to lead the World Wide Web to its full potential + + by developing common protocols that promote its evolution and ensure its interoperability. + The W3C Process Document describes the organizational structure of W3C and processes, + responsibilities and functions that enable W3C to accomplish its mission. + This document does not describe the internal workings of the Team.

+

For more information about the W3C mission and the history of W3C, + + please refer to About W3C.

+
+

Status of this document

+
+

W3C, including all existing chartered groups, + follows the most recent operative Process Document announced to the Membership.

+

This document is developed by the Advisory Board’s Process Task Force + working within the W3C Process Community Group (which anyone can join). + This is the 12 June 2023 Draft Community Group Report for the proposed next version of the W3C Process Document.

+

This document, + +which is based on the 2 November 2021 Process, +is a work in progress +and further changes may occur before completion of this revision cycle. +As detailed in Section 11 Process Changes, +once the W3C Advisory Board considers it ready for adoption, +it will be offered for W3C Advisory Committee Review. +A 7 April snapshot was created +and sent for W3C Advisory Committee Review on 12 April 2023.

+

A history of substantial changes from previous versions of the Process Document is provided.

+
+
+ +
+

Relation of Process Document to Patent Policy and Other Policies

+

W3C Members' attention is called to the fact + that provisions of the Process Document are binding on Members + per the Membership Agreement [MEMBER-AGREEMENT]. + The W3C Patent Policy [PATENT-POLICY] and other policies + incorporated by normative reference as a part of the Process Document + are equally binding.

+

The Patent Policy and CEPC place additional obligations on Members, Team, and other participants in W3C. + The Process Document does not restate those requirements but includes references to them. + The Process Document, Patent Policy, and CEPC have been designed to allow each to evolve independently.

+

In the Process Document, the term “participant” refers to an individual, not an organization.

+

Conformance and specialized terms

+

The terms must, must not, should, should not, required, + and may are used in accordance with RFC 2119. + The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

+

Some terms have been capitalized in this document (and in other W3C materials) + to indicate that they are entities with special relevance to the W3C Process. + These terms are defined within this document, + and readers are reminded that the ordinary English definitions are insufficient + for the purpose of understanding this document.

+ +
+

1. Introduction

+

W3C work revolves around the standardization of Web technologies. + To accomplish this work, W3C follows processes that promote the development of high-quality standards + based on the consensus of the Membership, Team, and public. + W3C processes promote fairness, responsiveness, and progress: + all facets of the W3C mission. + This document describes the processes W3C follows in pursuit of its mission.

+

The W3C Process promotes the goals of quality and fairness in technical decisions + by encouraging consensus, + soliciting reviews (by both Members and public), + incorporating implementation and interoperability experience, + and requiring Membership-wide approval as part of the technical report development process. Participants in W3C include representatives of its Members and the Team, + as well as Invited Experts who can bring additional expertise or represent additional stakeholders. Team representatives both contribute to the technical work + and help ensure each group’s proper integration with the rest of W3C.

+

W3C’s technical standards, called W3C Recommendations, + are developed by its Working Groups; + W3C also has other types of publications, + all described in § 6 W3C Technical Reports. + W3C has various types of groups; + this document describes the formation and policies + of its chartered Working Groups and Interest Groups, + see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. + W3C also operates Community and Business Groups, + which are separately described in their own process document [BG-CG].

+

In addition, several groups are formally established by the Consortium: + the W3C Advisory Committee, which has a representative from each Member, + and two oversight groups elected by its membership: + the Advisory Board (AB), + which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process; + and the Technical Architecture Group (TAG), + which helps resolve Consortium-wide technical issues.

+

Here is a general overview of how W3C initiates standardization of a Web technology:

+
    +
  1. People generate interest in a particular topic. + For instance, Members express interest by developing proposals in Community Groups + or proposing ideas in Member Submissions. + Also, the Team monitors work inside and outside of W3C for signs of interest, + and helps organize Workshops to bring people together + to discuss topics that interest the W3C community. +
  2. When there is enough interest and an engaged community, + the Team works with the Membership + to draft proposed Interest Group or Working Group charters. + W3C Members review the proposed charters, + and when there is support within W3C for investing resources in the topic of interest, + W3C approves the group(s), + and they begin their work. +
+

Further sections of this Process Document deal with topics including + liaisons (§ 9 Liaisons), + confidentiality (§ 7 Dissemination Policies), + and formal decisions and appeals (§ 5 Decisions).

+

2. Members and the Team

+

W3C’s mission is to lead the Web to its full potential. + W3C Member organizations provide resources to this end, + and the W3C Team provides the technical leadership + and organization to coordinate the effort.

+

2.1. Members

+

W3C Members are + organizations subscribed according to the Membership Agreement [MEMBER-AGREEMENT]. + They are represented in W3C processes as follows:

+
    +
  1. One representative per Member organization participates + in the Advisory Committee which oversees the work of W3C. +
  2. Representatives of Member organizations participate + in Working Groups and Interest Groups, + where they author and review technical reports. +
+

W3C membership is open to all entities, + as described in “How to Join W3C” [JOIN]; + (refer to the public list of current W3C Members [MEMBER-LIST]). + The Team must ensure + that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

+

While W3C does not have a class of membership tailored to individuals, + individuals may join W3C. + Restrictions pertaining to related Members apply + when the individual also represents another W3C Member.

+

2.1.1. Rights of Members

+

Each Member organization enjoys the following rights and benefits:

+ +

Furthermore, subject to further restrictions included in the Member Agreement, + representatives of Member organizations participate in W3C as follows:

+ +

The rights and benefits of W3C membership [MEMBER-AGREEMENT] are contingent upon conformance to the processes described in this document. + Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.

+

Additional information for Members is available at the Member website [MEMBER-HP].

+

2.1.2. Member Associations and Related Members

+
2.1.2.1. Membership Associations
+

A “Member Association” means a consortium, + user society, + or association of two or more individuals, + companies, + organizations or governments, + or any combination of these entities + which has the purpose of participating in a common activity + or pooling resources to achieve a common goal other than participation in, + or achieving certain goals in, + W3C. + A joint-stock corporation or similar entity is not a Member Association merely because it has shareholders or stockholders. + If it is not clear whether a prospective Member qualifies as a Member Association, + the CEO may reasonably make the determination. + For a Member Association, the rights and privileges of W3C Membership + described in the W3C Process Document extend to the Member Association's paid staff + and Advisory Committee representative.

+

Member Associations may also designate + up to four (or more at the Team’s discretion) individuals + who, though not employed by the organization, may exercise the rights of Member representatives.

+

For Member Associations that have individual people as members, + these individuals must disclose their employment affiliation + when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For Member Associations that have organizations as Members, + all such designated representatives must be an official representative of the Member organization + (e.g. a Committee or Task Force Chairperson) + and must disclose their employment affiliation when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For all representatives of a Member Association, + IPR commitments are made on behalf of the Member Association, + unless a further IPR commitment is made by the individuals' employers.

+
2.1.2.2. Related Members
+

In the interest of ensuring the integrity of the consensus process, + Member involvement in some of the processes in this document is affected by related Member status. + As used herein, two Members are related if:

+
    +
  1. Either Member is a subsidiary of the other, or +
  2. Both Members are subsidiaries of a common entity, or +
  3. The Members have an employment contract or consulting contract that affects W3C participation. +
+

A subsidiary is an organization of which effective control and/or majority ownership rests with another, + single organization.

+

Related Members must disclose these relationships + according to the mechanisms described in the New Member Orientation [INTRO].

+

2.2. The W3C Team

+

The Team consists of CEO, + W3C paid staff, + unpaid interns, + and W3C Fellows. W3C Fellows are Member employees working as part of the Team; + see the W3C Fellows Program [FELLOWS]. + The Team provides technical leadership about Web technologies, + organizes and manages W3C activities to reach goals + within practical constraints (such as resources available), + and communicates with the Members and the public + about the Web and W3C technologies.

+

The CEO may delegate responsibility + (generally to other individuals in the Team) + for any of their roles described in this document. Team Decisions derive from the CEO's authority, + even when they are carried out by other members of the Team.

+

Oversight over the Team, + budgeting, + and other business decisions, + is provided by the W3C Board of Directors, + rather than managed directly by the Process.

+

Note: See the W3C Bylaws for more details + on the Board and overall governance of W3C.

+

3. Groups and Participation

+

For the purposes of this Process, a W3C Group is one of W3C’s Working Groups, Interest Groups, Advisory Committee, Advisory Board, + or TAG, + and a participant is a member of such a group.

+

3.1. Policies for Participation in W3C Groups

+

3.1.1. Individual Participation Criteria

+
3.1.1.1. Expectations and Discipline
+

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

+
    +
  1. Technical competence in one’s role; +
  2. The ability to act fairly; +
  3. Social competence in one’s role. +
+

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities + are responsible for assessing and attesting to the qualities of those nominees.

+

Participants in any W3C activity must abide + by the terms and spirit of the W3C Code of Ethics and Professional Conduct [CEPC] and the participation requirements described in + “Disclosure” + in the W3C Patent Policy [PATENT-POLICY].

+

The CEO may take disciplinary action, + including suspending or removing for cause + a participant in any group (including the AB and TAG) + if serious and/or repeated violations, + such as failure to meet the requirements on individual behavior of + (a) this process + and in particular the CEPC, or + (b) the membership agreement, or + (c) applicable laws, + occur. + Refer to the Guidelines to suspend or remove participants from groups.

+
3.1.1.2. Conflict of Interest Policy
+

Individuals participating materially in W3C work must disclose significant relationships + when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. + These disclosures must be kept up-to-date + as the individual’s affiliations change and W3C membership evolves + (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). + Each section in this document that describes a W3C group + provides more detail about the disclosure mechanisms for that group.

+

The ability of an individual to fulfill a role within a group + without risking a conflict of interest depends on the individual’s affiliations. + When these affiliations change, + the individual’s assignment to the role must be evaluated. + The role may be reassigned according to the appropriate process. + For instance, + the Team may appoint a new group Chair when the current Chair changes affiliations + (e.g., if there is a risk of conflict of interest, + or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

+

The following are some scenarios where disclosure is appropriate:

+
    +
  • Paid consulting for an organization whose activity is relevant to W3C, + or any consulting compensated with equity + (shares of stock, stock options, or other forms of corporate equity). +
  • A decision-making role/responsibility + (such as participating on a Board) + in other organizations relevant to W3C. +
  • A position on a publicly visible advisory body, + even if no decision-making authority is involved. +
+

Individuals seeking assistance on these matters should contact the Team.

+

Team members are subject to the W3C Team conflict of interest policy [CONFLICT-POLICY].

+
3.1.1.3. Individuals Representing a Member Organization
+

Generally, individuals representing a Member in an official capacity within W3C + are employees of the Member organization. + However, an Advisory Committee representative may designate a non-employee + to represent the Member. + Non-employee Member representatives must disclose + relevant affiliations to the Team and to any group in which the individual participates.

+

In exceptional circumstances + (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), + the CEO may decline + to allow an individual designated by an Advisory Committee representative to participate in a group.

+

A group charter may limit + the number of individuals representing a W3C Member + (or group of related Members).

+

3.1.2. Meetings

+

The requirements in this section apply to the official meetings of any W3C group.

+

W3C distinguishes two types of meetings:

+
    +
  1. A face-to-face meeting is one + where most of the attendees are expected to participate in the same physical location. +
  2. A distributed meeting is one + where most of the attendees are expected to participate from remote locations + (e.g., by telephone, video conferencing, or IRC). +
+

A Chair may invite an individual with a particular expertise + to attend a meeting on an exceptional basis. + This person is a meeting guest, + not a group participant. + Meeting guests do not have voting rights. + It is the responsibility of the Chair to ensure + that all meeting guests respect the chartered level of confidentiality and other group requirements.

+
3.1.2.1. Meeting Scheduling and Announcements
+

Meeting announcements should be sent to all appropriate group mailing lists, + i.e. those most relevant to the anticipated meeting participants.

+

The following table lists recommendations for organizing a meeting:

+ + + + + + + + + +
+ Face-to-face meetings + Distributed meetings +
Meeting announcement (before) + eight weeks* + one week* +
Agenda available (before) + two weeks + 24 hours (or longer if a meeting is scheduled after a weekend or holiday) +
Participation confirmed (before) + three days + 24 hours +
Action items available (after) + three days + 24 hours +
Minutes available (after) + two weeks + 48 hours +
+

* To allow proper planning (e.g., travel arrangements), + the Chair is responsible for giving sufficient advance notice + about the date and location of a meeting. + Shorter notice for a meeting is allowed + provided that there are no objections from group participants.

+
3.1.2.2. Meeting Minutes
+

Groups should take and retain minutes of their meetings, + and must record + any official group decisions made during the meeting discussions. + Details of the discussion leading to such decisions are not required, + provided that the rationale for the group decision is nonetheless clear.

+
3.1.2.3. Meeting Recordings and Transcripts
+

No-one may take an audio or video recording of a meeting, + or retain an automated transcript, + unless the intent is announced at the start of the meeting, + and no-one participating in the recorded portion of the meeting withholds consent. + If consent is withheld by anyone, recording/retention must not occur. + The announcement must cover: + (a) who will have access to the recording or transcript and + (b) the purpose/use of it and + (c) how it will be retained (e.g. privately, in a cloud service) and for how long.

+

3.1.3. Tooling and Archiving for Discussions and Publications

+

For W3C Groups operating under this Process, + a core operating principle is to allow access across disabilities, + across country borders, + and across time. + Thus in order to allow all would-be participants to effectively participate, + to allow future participants and observers to understand the rationale and origins of current decisions, + and to guarantee long-lived access to its publications, + W3C requires that:

+
    +
  • All reports, publications, or other deliverables + produced by the group for public consumption + (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, + and backed up by W3C systems + such that if the underlying service is discontinued, + W3C can continue to serve such content without breaking incoming links + or other key functionality. +
  • All reports, publications, or other deliverables + produced by the group for public consumption should follow best practices for internationalization + and for accessibility to people with disabilities. + Network access to W3C-controlled domains may be assumed. +
  • + Official meeting minutes and other records of decisions made must be archived by W3C for future reference; + and other persistent text-based discussions + sponsored by the group, + pertaining to their work + and intended to be referenceable by all group members should be. + This includes discussions conducted over email lists + or in issue-tracking services + or any equivalent fora. + Materials referenced from discussions + and necessary to understand them + should be available at a stable URL, + at a level of confidentiality no stricter than the discussion minutes. +

    Note: The lack, or loss, of such archives does not by itself + invalidate an otherwise-valid decision.

    +
  • + Any tooling used by the group + for producing its documentation and deliverables + or for official group discussions should be usable + (without additional cost) + by all who wish to participate, + including people with disabilities, + to allow their effective participation. +

    Note: If a new participant joins who cannot use the tool, + this can require the Working Group to change its tooling + or operate some workaround.

    +
  • All tools and archives used by the group + for its discussions and recordkeeping should be documented + such that new participants and observers + can easily find the group’s tools and records. +
+

The Team is responsible for ensuring adherence to these rules + and for bringing any group not in compliance into compliance.

+

3.1.4. Resignation from a Group

+

A W3C Member or Invited Expert may resign from a group. + On written notification from an Advisory Committee representative + or Invited Expert + to the Team, + the Member and their representatives + or the Invited Expert + will be deemed to have resigned from the relevant group. + The Team must record the notification. + See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

+

3.2. The Advisory Committee (AC)

+

3.2.1. Role of the Advisory Committee

+

The Advisory Committee represents + the Members of W3C at large. + It is responsible for:

+ +

Advisory Committee representatives may initiate + an Advisory Committee Appeal of a W3C decision or Team's decision.

+

See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

+

3.2.2. Participation in the Advisory Committee

+

The Advisory Committee is composed of one representative from each Member organization + (refer to the Member-only list + of current Advisory Committee representatives. [CURRENT-AC])

+

When an organization joins W3C + (see “How to Join W3C” [JOIN]), + it must name its Advisory Committee representative as part of the Membership Agreement. + The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, + provides information about Advisory Committee Meetings, + explains how to name a new Advisory Committee representative, + and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.

+

The AC representative may delegate any of their rights and responsibilities + to an alternate (except the ability to designate an alternate).

+

3.2.3. Advisory Committee Mailing Lists

+

The Team must provide two mailing lists for use by the Advisory Committee:

+
    +
  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. + This list is read-only for Advisory Committee representatives. +
  2. One for discussion among Advisory Committee representatives. + Though this list is primarily for Advisory Committee representatives, + the Team must monitor discussion + and should participate in discussion when appropriate. + Ongoing detailed discussions should be moved to other appropriate lists + (new or existing, such as a mailing list created for a Workshop). +
+

An Advisory Committee representative may request + that additional individuals from their organization be subscribed to these lists. + Failure to contain distribution internally may result in suspension of additional email addresses, + at the discretion of the Team.

+

3.2.4. Advisory Committee Meetings

+

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. + The Team appoints the Chair of these meetings (generally the CEO). + At each Advisory Committee meeting, + the Team should provide an update to the Advisory Committee about:

+
+
Resources +
+
    +
  • The number of W3C Members at each level. +
  • An overview of the financial status of W3C. +
+
Allocations +
+
    +
  • The allocation of the annual budget, including size of the Team and their approximate deployment. +
  • A list of all activities (including but not limited to Working and Interest Groups) + and brief status statement about each, + in particular those started or terminated since the previous Advisory Committee meeting. +
  • The allocation of resources to pursuing liaisons with other organizations. +
+
+

Each Member organization should send one representative to each Advisory Committee Meeting. + In exceptional circumstances + (e.g., during a period of transition between representatives from an organization), + the meeting Chair may allow a Member organization to send two representatives to a meeting.

+

The Team must announce the date and location of each Advisory Committee meeting + no later than at the end of the previous meeting; one year’s notice is preferred. + The Team must announce the region of each Advisory Committee meeting + at least one year in advance.

+

More information about Advisory Committee meetings [AC-MEETING] is available at the Member website.

+

3.3. Elected Groups: The AB and the TAG

+

The W3C Process defines two types of elected groups: + the Advisory Board (AB) and + the Technical Architecture Group (TAG), + both elected by the Advisory Committee.

+

3.3.1. Advisory Board (AB)

+
3.3.1.1. Role of the Advisory Board
+

The Advisory Board provides ongoing guidance to the Team + on issues of strategy, + management, + legal matters, + process, + and conflict resolution. + The Advisory Board also serves the Members + by tracking issues raised between Advisory Committee meetings, + soliciting Member comments on such issues, + and proposing actions to resolve these issues. + The Advisory Board manages the evolution of the Process Document. + As part of a W3C Council, + members of the Advisory Board hear and adjudicate on Submission Appeals and Formal Objections.

+

The Advisory Board is distinct from the Board of Directors and has no decision-making authority within W3C; + its role is strictly advisory.

+

Note: While the AB as such does not have decision-making authority, + its members do when sitting as part of a W3C Council.

+

Details about the Advisory Board + (e.g., the list of Advisory Board participants, + mailing list information, and summaries of Advisory Board meetings) + are available at the Advisory Board home page [AB-HP].

+
3.3.1.2. Composition of the Advisory Board
+

The Advisory Board consists of nine to eleven elected participants and one Chair + (who may be one of the elected participants). + With the input of the AB, + the Team appoints the Chair, + who should choose a co-chair among the elected participants. + The Chair(s) are subject to ratification by secret ballot + by two thirds of the AB upon appointment. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The team also appoints a Team Contact, + as described in § 3.4.1 Requirements for All Chartered Groups. + The CEO and Team Contact have a standing invitation + to all regular Advisory Board sessions.

+

The nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

+

The terms of elected Advisory Board participants are for two years. + Terms are staggered so that each year, + either five or six terms expire. + If an individual is elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular Advisory Board terms begin on 1 July and end on 30 June.

+

+
3.3.1.3. Communications of the Advisory Board
+

The Team must make available a mailing list, + confidential to the Advisory Board and Team, + for the Advisory Board to use for its communication.

+

The Advisory Board should send a summary of each of its meetings + to the Advisory Committee and other group Chairs. + The Advisory Board should also report on its activities + at each Advisory Committee meeting.

+
3.3.1.4. Liaisons between the Advisory Board and the Board of Directors
+

To ensure good communication between the AB and the Board of Directors and facilitate operational and management consistency, + the AB may appoint up to two of its participants as liaisons to the Board. + Such appointees are expected to attend and participate in Board meetings + and access Board materials + as Non-voting Observers. [BYLAWS] They do not form part of the Board's decision-making body, + and may be excluded from such participation + in accordance with applicable Board procedures.

+

The Advisory Board should reevaluate + who is assigned to this role + at least at the beginning of each term, + and may swap its appointees more frequently + as they deem appropriate.

+

3.3.2. Technical Architecture Group (TAG)

+
3.3.2.1. Role of the Technical Architecture Group
+

The mission of the TAG is stewardship of the Web architecture. + There are three aspects to this mission:

+
    +
  1. to document and build consensus around principles of Web architecture + and to interpret and clarify these principles when necessary; +
  2. to resolve issues involving general Web architecture brought to the TAG; +
  3. to help coordinate cross-technology architecture developments inside and outside W3C. +
+

As part of a W3C Council, + the members of the TAG hear and adjudicate on Submission Appeals and Formal Objections.

+

The TAG's scope is limited to technical issues about Web architecture. + The TAG should not consider + administrative, + process, + or organizational policy issues of W3C, + which are generally addressed by + the W3C Advisory Committee, + Advisory Board, + and Team. + Please refer to the TAG charter [TAG-CHARTER] for more information about the background and scope of the TAG, + and the expected qualifications of TAG participants.

+

When the TAG votes to resolve an issue, + each TAG participant + (whether appointed, elected, or the Chair) + has one vote; + see also the section on voting in the TAG charter [TAG-CHARTER] and the general section on votes in this Process Document.

+

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) + are available at the TAG home page [TAG-HP].

+
3.3.2.2. Composition of the Technical Architecture Group
+

The TAG consists of:

+ +

Participants in the TAG choose by consensus their Chair or co-Chairs; + in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG. + The Chair or co-Chairs must be selected from the participants of the TAG. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The Team also appoints a Team Contact [TEAM-CONTACT] for the TAG, + as described in § 3.4.1 Requirements for All Chartered Groups.

+

The terms of TAG participants last for two years. + Terms are staggered so that three elected terms + and either one or two appointed terms expire each year. + If an individual is appointed or elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular TAG terms begin on 1 February and end on 31 January.

+
3.3.2.3. Communications of the Technical Architecture Group
+

The Team must make available two mailing lists for the TAG:

+
    +
  • a public discussion (not just input) list for issues of Web architecture. + The TAG will conduct its public business on this list. +
  • a Member-only list for discussions within the TAG + and for requests to the TAG that, + for whatever reason, cannot be made on the public list. +
+

The TAG may also request the creation of additional topic-specific, public mailing lists. + For some TAG discussions (e.g., a Submission Appeal), + the TAG may use a list that will be Member-only.

+

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. + The TAG should also report on its activities at each Advisory Committee meeting.

+

3.3.3. Participation in Elected Groups

+
3.3.3.1. Expectations for Elected Groups Participants
+

Advisory Board and TAG participants have a special role within W3C: + they are elected by the Membership and appointed by the Team with the expectation that they will use their best judgment + to find the best solutions for the Web, + not just for any particular network, + technology, + vendor, + or user. + Advisory Board and TAG participants are expected to participate regularly and fully. + Advisory Board and TAG participants should attend Advisory Committee meetings.

+

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, + to serve the needs of the W3C membership as a whole, + and the Web community. + Whether they are Member representatives or Invited Experts, + their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

+

An individual participates on the Advisory Board or TAG + from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). + Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, + their participation does carry the responsibilities associated with Member representation, + Invited Expert status, + or Team representation + (as described in the section on the AB/TAG nomination and election process).

+

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, + and a participant’s seat must not be delegated to any other person.

+
3.3.3.2. Elected Groups Participation Constraints
+

Given the few seats available on the Advisory Board and the TAG, + and in order to ensure that the diversity of W3C Members is represented:

+ +
3.3.3.3. Advisory Board and Technical Architecture Group Elections
+

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, + using a Single Transferable Vote system. + An election begins when the Team sends a Call for Nominations to the Advisory Committee. + Any Call for Nominations specifies the minimum and maximum number of available seats, + the deadline for nominations, + details about the specific vote tabulation system selected by the Team for the election, + and operational information such as how to nominate a candidate. + The Team may modify the tabulation system after the Call for Nominations + but must stabilize it no later than the Call for Votes. + The Team announces appointments + after the results of the election are known, + and before the start of the term, + as described in § 3.3.3.4 Technical Architecture Group Appointments.

+

In the case of regularly scheduled elections of the TAG, + the minimum and maximum number of available seats are the same: + the 3 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

+

In the case of regularly scheduled elections of the AB, + the minimum and maximum number of available seats differ: + The maximum number is the 5 or 6 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; + the minimum number is such that when added to the occupied seats from the prior year, + the minimum size of the AB (9) is reached.

+

Each Member (or group of related Members) may nominate one individual. + A nomination must be made with the consent of the nominee. + In order for an individual to be nominated as a Member representative, + the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination + the (same) information required for a Member representative in a Working Group. + In order for an individual to be nominated as an Invited Expert, + the individual must provide + the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. + In order for an individual to be nominated as a Team representative, + the nominating Advisory Committee representative must first secure approval from Team management. + A nominee is not required to be an employee of a Member organization, + and may be a W3C Fellow. + The nomination form must ask for the nominee’s primary affiliation, + and this will be reported on the ballot. + For most nominees, + the primary affiliation is their employer and will match their affiliation in the W3C database. + For contractors and invited experts, + this will normally be their contracting company + or their invited expert status; + in some cases + (e.g. where a consultant is consulting for only one organization) + this may be the organization for whom the nominee is consulting. + A change of affiliation is defined + such that this field would carry a different answer + if the nominee were to be re-nominated + (therefore, + terminating employment, + or accepting new employment, + are changes of affiliation). + (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) + Each nomination should include + a few informative paragraphs about the nominee.

+

If, after the deadline for nominations, the number of nominees is:

+
    +
  • Greater than or equal to the minimum number of available seats + and less than or equal to the maximum number of available seats, + those nominees are thereby elected. + This situation constitutes a tie for the purpose of assigning incomplete terms. + Furthermore, if the number is less than the maximum number of available seats, + the longest terms are filled first. +
  • Less than the minimum number of available seats, + Calls for Nominations are issued until a sufficient number of people have been nominated. + Those already nominated do not need to be renominated after a renewed call. +
  • Greater than the maximum number of available seats, + the Team issues a Call for Votes + that includes the names of all candidates, + the (maximum) number of available seats, + the deadline for votes, + details about the vote tabulation system selected by the Team for the election, + and operational information. +
+

When there is a vote, + each Member + (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. + Once the deadline for votes has passed, + the Team announces the results to the Advisory Committee. + In case of a tie the verifiable random selection procedure described below + will be used to fill the available seats.

+

The shortest incomplete term is assigned to the elected candidate ranked lowest by the tabulation of votes, + the next shortest term to the next-lowest ranked elected candidate, + and so on. + In the case of a tie among those eligible for a incomplete term, + the verifiable random selection procedure described below + will be used to assign the incomplete term.

+

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

+
3.3.3.4. Technical Architecture Group Appointments
+

The Team is responsible for appointing + 3 of the participants to the Technical Architecture Group. + This mechanism complements the election process. + The Team should use its appointments to support + a diverse and well-balanced TAG, + including diversity of technical background, knowledge, and skill sets.

+

The Team should actively seek + candidates for appointment to the TAG, + and must make available to + the W3C community at large + a means to propose candidates for consideration, + explicitly soliciting input from at least + current and incoming TAG members, the Advisory Committee, and Working Group Chairs.

+

The constraints for appointment to the TAG are + the same as for elected participants + (see § 3.3.3.2 Elected Groups Participation Constraints and § 3.3.3.3 Advisory Board and Technical Architecture Group Elections), + with the additional constraint that + a person must not be appointed + for more than two consecutive terms. + (Partial terms used to fill a vacated seat do not count towards this limit.)

+

Note: Individuals who have reached the limit of two consecutive appointed terms may freely run for election + if they wish to continue serving on the TAG.

+

The Team's choice of appointee(s) + is subject to ratification by secret ballot + by both the AB and the TAG, + each requiring a two-thirds approval. + In the case of regularly scheduled elections, + the TAG participants in this ratification are + its members for the upcoming term.

+

For regularly scheduled elections, + selection begins once the results of the elections are known, + and the Team should announce the ratified appointment(s) + no later than the start of the regularly scheduled term. + When an appointed seat is vacated outside of a regularly scheduled election, + the Team should seek to appoint a replacement + unless a regular Call for Nominations is scheduled within 2 months, + and it must announce the ratified appointment + no later than the Call for Nominations of the next scheduled election.

+
3.3.3.5. Verifiable Random Selection Procedure
+

When it is necessary to use a verifiable random selection process + (e.g., in an AB or TAG election, + to “draw straws” in case of a tie + or to fill a incomplete term), + W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. + The procedure orders an input list of names + (listed in alphabetical order by family name unless otherwise specified) + into a “result order”.

+

W3C applies this procedure as follows:

+

+
    +
  1. When N people have tied for M (less than N) seats. + In this case, only the names of the N individuals who tied + are provided as input to the procedure. + The M seats are assigned in result order. +
  2. After all elected individuals have been identified, + when N people are eligible for M (less than N) incomplete terms. + In this case, only the names of those N individuals are provided as input to the procedure. + The incomplete terms are assigned in result order. +
+
3.3.3.6. Elected Groups Vacated Seats
+

An Advisory Board or TAG participant’s seat is vacated when:

+ +

If a participant changes affiliation, + but the participation constraints are met, + that participant’s seat becomes vacant at the next regularly scheduled election for that group.

+

Vacated seats are filled according to this schedule:

+
    +
  • When an appointed TAG seat is vacated, + the Team appoints a replacement. +
  • + When an elected seat on either the AB or TAG is vacated, + the seat is filled at the next regularly scheduled election for the group + unless the group Chair requests that W3C hold an election before then + (for instance, due to the group’s workload). +
      +
    • The group Chair should not request such an election + if the next regularly scheduled election is fewer than three months away. +
    • The group Chair may request an election, + and the election may begin, as soon as a current member gives notice of a resignation, + including a resignation effective as of a given date in the future. +
    +

    When such an election is held, + the minimum number of available seats is such that + when added to the number of continuing participants, + the minimum total number of elected seats is met + (6 for the TAG, 9 for the AB); + and the maximum number corresponds to all unoccupied seats. + Except for the number of available seats and the length of the terms, + the usual rules for Advisory Board and Technical Architecture Group Elections apply.

    +
+

3.4. Chartered Groups: Working Groups and Interest Groups

+

This document defines two types of chartered groups:

+
+
Working Groups. +
+ Working Groups typically produce deliverables + (e.g., Recommendation Track technical reports, + software, + test suites, + and reviews of the deliverables of other groups) + as defined in their charter. +

Working Groups have additional participation requirements + described in the W3C Patent Policy [PATENT-POLICY], + see particularly the “Licensing Obligations of Working Group Participants” + and the patent claim exclusion process + in “Exclusion From W3C RF Licensing Requirements”.

+
Interest Groups. +
+ The primary goal of an Interest Group + is to bring together people who wish to evaluate potential Web technologies and policies. + An Interest Group is a forum for the exchange of ideas. +

Interest Groups do not publish Recommendation Track technical reports; + but can publish technical reports on the Note Track.

+
+

3.4.1. Requirements for All Chartered Groups

+

Each group must have a charter. + Requirements for the charter depend on the group type. + All group charters must be public + (even if other proceedings of the group are Member-only).

+

Each group must have a Chair (or co-Chairs) + to coordinate the group’s tasks. + The Team appoints (and re-appoints) Chairs for all groups. + The Chair is a Member representative, + a Team representative, + or an Invited Expert, + (invited by the Team). + The requirements of this document that apply to those types of participants apply to Chairs as well.

+

Note: The role of the Chair [CHAIR] is described + in the Art of Consensus [GUIDE].

+

Each group must have a Team Contact, + who acts as the interface between the Chair, + group participants, + and the rest of the Team.

+

Note: The role of the Team Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE].

+

The Chair and the Team Contact of a group should not be the same individual.

+

Each group must have an archived mailing list + for formal group communication + (e.g., for meeting announcements and minutes, + documentation of decisions, + and Formal Objections to decisions). + It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists. + Refer to the list of group mailing lists [GROUP-MAIL].

+

A Chair may form task forces + (composed of group participants) + to carry out assignments for the group. + The scope of these assignments must not exceed the scope of the group’s charter. + A group should document the process it uses + to create task forces + (e.g., each task force might have an informal "charter"). + Task forces do not publish technical reports; + the Working Group may choose to publish their results as part of a technical report.

+

3.4.2. Participation in Chartered Groups

+

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, + and Team representatives (including the Team Contact).

+

There are four types of individual participants in an Interest Group: + the same three types as for Working Groups plus, + for an Interest Group where the only participation requirement is mailing list subscription, public participants.

+

Except where noted in this document or in a group charter, + all participants share the same rights and responsibilities in a group; + see also the individual participation criteria.

+

A participant may represent more than one organization + in a Working Group or Interest Group. + Those organizations must all be members of the group.

+

An individual may become + a Working or Interest Group participant + at any time during the group’s existence. + See also relevant requirements in + “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY].

+

On an exceptional basis, + a Working or Interest Group participant may designate + a substitute to attend a meeting and should inform the Chair. + The substitute may act on behalf of the participant, + including for votes. + For the substitute to vote, + the participant must inform the Chair in writing in advance. + As a courtesy to the group, + if the substitute is not well-versed in the group’s discussions, + the regular participant should authorize another participant to act as proxy for votes.

+

To allow rapid progress, + Working Groups are intended to be small + (typically fewer than 15 people) + and composed of experts in the area defined by the charter. + In principle, + Interest Groups have no limit on the number of participants. + When a Working Group grows too large to be effective, + W3C may split it into an Interest Group + (a discussion forum) + and a much smaller Working Group + (a core group of highly dedicated participants).

+

3.4.3. Types of Participants in Chartered Groups

+
3.4.3.1. Member Representative in a Working Group
+

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Advisory Committee representative of the Member in question + has designated the individual as a Working Group participant, and +
  • the individual qualifies for Member representation. +
+

To designate an individual as a Member representative in a Working Group, + an Advisory Committee representative must provide the Chair and Team Contact with all of the following information, + in addition to any other information required by the Call for Participation and charter + (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

+
    +
  1. The name of the W3C Member the individual represents + and whether the individual is an employee of that Member organization; +
  2. A statement that the individual accepts the participation terms + set forth in the charter + (with an indication of charter date or version); +
  3. A statement that the Member will provide the necessary financial support for participation + (e.g., for travel, telephone calls, and conferences). +
+

A Member participates in a Working Group from the moment the first Member representative joins the group + until either of the following occurs:

+
    +
  • the group closes, or +
  • the Member resigns from the Working Group; + this is done through the Member’s Advisory Committee representative. +
+
3.4.3.2. Member Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

+ +

To designate an individual as a Member representative in an Interest Group, + the Advisory Committee representative must follow the instructions + in the Call for Participation and charter.

+

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

+
3.4.3.3. Invited Expert in a Working Group
+

The Chair may invite an individual with a particular expertise + to participate in a Working Group. + This individual may represent an organization in the group + (e.g., if acting as a liaison with another organization).

+

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Chair has designated the individual as a group participant, +
  • the Team Contact has agreed with the Chair’s choice, and +
  • the individual has provided the information required of an Invited Expert to the Chair and Team Contact. +
+

To designate an individual as an Invited Expert in a Working Group, + the Chair must inform the Team Contact + and provide rationale for the choice. + When the Chair and the Team Contact disagree about a designation, + the CEO determines + whether the individual will be invited to participate in the Working Group.

+

To participate in a Working Group as an Invited Expert, + an individual must:

+
    +
  • identify the organization, if any, the individual represents as a participant in this group, +
  • agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT], +
  • accept the participation terms set forth in the charter, + including the participation requirements of + the W3C Patent Policy [PATENT-POLICY], + especially in “Note on Licensing Commitments for Invited Experts” + and in “Disclosure”, + indicating a specific charter date or version, +
  • disclose whether the individual is an employee of a W3C Member; + see the conflict of interest policy, +
  • provide a statement of who will provide the necessary financial support + for the individual’s participation + (e.g., for travel, telephone calls, and conferences), and +
  • if the individual’s employer (including a self-employed individual) + or the organization the individual represents + is not a W3C Member, + indicate whether that organization intends to join W3C. + If the organization does not intend to join W3C, + indicate reasons the individual is aware of for this choice. +
+

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. + The Chair must not use Invited Expert status + to circumvent participation limits imposed by the charter.

+

An Invited Expert participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • the Chair or CEO withdraws the invitation to participate, or +
  • the individual resigns. +
+
3.4.3.4. Invited Expert in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

+
3.4.3.5. Team Representative in a Working Group
+

An individual is a Team representative in a Working Group when so designated by W3C management. + Team representatives both contribute to the technical work + and help ensure the group’s proper integration with the rest of W3C.

+

A Team representative participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • W3C management changes Team representation by sending email to the Chair, + copying the group mailing list. +
+

The Team participates in a Working Group + from the moment the creation of the group is announced + until the group closes.

+
3.4.3.6. Team Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Team representative in an Interest Group when so designated by W3C management.

+

4. Lifecycle of Chartered Groups

+

4.1. Initiating Charter Development

+

W3C creates charters for chartered groups based on interest from the Members and Team. + The Team must notify the Advisory Committee + when a charter for a new Working Group or Interest Group is in development. + This is intended to raise awareness, + even if no formal proposal is yet available. + Advisory Committee representatives may provide + feedback on the Advisory Committee discussion list or via other designated channels.

+

W3C may begin work + on a Working Group or Interest Group charter + at any time.

+

4.2. Content of a Charter

+

A Working Group or Interest Group charter must include all of the following information.

+
    +
  • The group’s mission + (e.g., develop a technology or process, review the work of other groups). +
  • The scope of the group’s work and criteria for success. +
  • The duration of the group (typically from six months to two years). +
  • The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software). +
  • + Expected milestone dates where available. +

    Note: A charter is not required to include schedules for review of other group’s deliverables.

    +
  • The process for the group to approve the release of deliverables + (including intermediate results). +
  • Any dependencies by groups within or outside of W3C on the deliverables of this group. + For any dependencies, the charter must specify + the mechanisms for communication about the deliverables. +
  • Any dependencies of this group on other groups within or outside of W3C. + Such dependencies include interactions with W3C Horizontal Groups [CHARTER]. +
  • The level of confidentiality of the group’s proceedings and deliverables. +
  • Meeting mechanisms and expected frequency. +
  • If known, + the date of the first face-to-face meeting. + The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal. +
  • Communication mechanisms to be employed within the group, + between the group and the rest of W3C, + and with the general public. +
  • Any voting procedures or requirements + other than those specified in § 5.2.3 Deciding by Vote. +
  • An estimate of the expected time commitment from participants. +
  • The expected time commitment and level of involvement by the Team + (e.g., to track developments, + write and edit technical reports, + develop code, + or organize pilot experiments). +
  • Intellectual property information. + What are the intellectual property (including patents and copyright) + considerations affecting the success of the Group? + In particular, is there any reason to believe + that it will be difficult to meet the Royalty-Free licensing goals + in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY]? +
+

See also the charter requirements in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

For every Recommendation Track deliverable + that continues work on technical report published under any other Charter (including a predecessor group of the same name), + for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

+
    +
  • The title, + stable URL, + and publication date of the Working Draft or other Recommendation-track document + that will serve as the basis for work on the deliverable + (labeled “Adopted Draft”); +
  • The title, + stable URL, + and publication date of the document + that was used as the basis for its most recent Exclusion Opportunity + as per + the W3C Patent Policy [PATENT-POLICY]. + (labeled “Exclusion Draft”); and +
  • The stable URL of the Working Group charter + under which the Exclusion Draft was published + (labeled the “Exclusion Draft Charter”). +
+

All of the above data must be identified + in the adopting Working Group’s charter using the labels indicated.

+

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. + The proposed charter must state + the dates on which the Exclusion Opportunity + that arose on publishing the Exclusion Draft began and ended. + As per “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY], + this potentially means that exclusions can only be made immediately on joining a Working Group.

+

An Interest Group charter may include provisions regarding participation, + including specifying + that the only requirement for participation (by anyone) in + the Interest Group is subscription to the Interest Group mailing list. + This type of Interest Group may have public participants.

+

A charter may include + provisions other than those required by this document. + The charter should highlight + whether additional provisions impose constraints + beyond those of the W3C Process Document + (e.g., limits on the number of individuals in a Working Group + who represent the same Member organization or group of related Members).

+

4.3. Advisory Committee Review of a Charter

+

The Team must solicit Advisory Committee review of every new or substantively modified Working Group or Interest Group charter, + except for either:

+
    +
  • +

    a charter extension

    +
  • +

    substantive changes to a charter that do not affect the way the group functions in any significant way.

    +
+

The review period must be at least 28 days. + The following are examples of substantive changes that would not require an Advisory Committee Review: + the addition of an in-scope deliverable, + a change of Team Contact, + or a change of Chair. + Such changes must nonetheless be announced + to the Advisory Committee and to participants in the Working or in the Interest Group, + and a rationale must be provided.

+

The Call for Review of a substantively modified charter must highlight important changes + (e.g., regarding deliverables or resource allocation) + and include rationale for the changes.

+

As part of the Advisory Committee review of any new or substantively modified Working Group charter, + any Advisory Committee representative may request an extended review period.

+

Such a request must be submitted with a Member’s comments + in response to the Call for Review. + Upon receipt of any such request, + the Team must ensure + that the Call for Participation for the Working Group + occurs at least 60 days + after the Call for Review of the charter.

+

4.4. Call for Participation in a Chartered Group

+

Deciding whether to adopt a proposed Working Group or Interest Group charter is a W3C Decision. + Charters may be amended based on review comments + per § 5.7.2 After the Review Period before the Call for Participation.

+

If the decision is to charter the group, + the Team must issue a Call for Participation to the Advisory Committee. + For a new group, this announcement officially creates the group. + The announcement must include a reference to the charter, + the name(s) of the group’s Chair(s), + and the name(s) of the Team Contact(s).

+

After a Call for Participation, + any Member representatives and Invited Experts must be designated (or re-designated). + When a group is re-chartered, + individuals participating in the Working Group or Interest Group before the new Call for Participation + may attend any meetings held within forty-five (45) days of the Call for Participation + even if they have not yet formally rejoined the group + (i.e., committed to the terms of the charter and patent policy).

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against the decision to create + or substantially modify + a Working Group or Interest Group charter.

+

4.5. Charter Extension

+

The Team may decide + to extend a Working Group or Interest Group charter + with no other substantive modifications. + The Team must announce + such extensions to the Advisory Committee. + The announcement must indicate the new duration. + The announcement must also include rationale for the extension, + a reference to the charter, + and the Group homepage + (which includes at least + the name(s) of the group’s Chair(s), + the name of the Team Contact, + and instructions for joining the group).

+

After a charter extension, + Advisory Committee representatives + and the Chair are not required to re-designate Member representatives and Invited Experts.

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.

+

4.6. Chartered Group Closure

+

A Working Group or Interest Group charter specifies a duration for the group.

+

The Team, the TAG, or the AB may propose to close a group + prior to the date specified in the charter in any of the following circumstances:

+
    +
  • +

    There are insufficient member resources to produce chartered deliverables +or to maintain the group, +according to priorities established within W3C.

    +
  • +

    A Patent Advisory Group concluded that the work should be terminated.

    +
  • +

    The TAG or AB determined that continuing operation of the chartered group or its work +would be detrimental to W3C or its mission.

    +
  • +

    The group produced all chartered deliverables ahead of schedule.

    +
+

Such a proposal to close a group must be accompanied by rationale, + and the proposal must be confirmed by an AC Review as a W3C Decision.

+

Closing a Working Group has implications + with respect to the W3C Patent Policy [PATENT-POLICY].

+

5. Decisions

+

W3C attempts to resolve issues through dialog. + Individuals who disagree strongly with a decision should register with the Chair any Formal Objections.

+

5.1. Types of Decisions

+

The Chair of a Working Group or Interest Group has the prerogative + to make certain decisions based on their own judgment. + Such decisions are called chair decisions.

+

In contrast, + decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group + or following a vote (see § 5.2.3 Deciding by Vote) + are called group decisions (also known as group “resolutions”).

+

Decisions made by members of the Team in connection with this Process, + based on their own individual or collective judgement, + are called Team Decisions.

+

In contrast, + a W3C decision is + determined by the Team on behalf of the W3C community + by assessing the consensus of the W3C Community after an Advisory Committee review.

+

5.2. Consensus Building

+

5.2.1. Consensus

+

Consensus is a core value of W3C. + To promote consensus, + the W3C process requires Chairs to ensure + that groups consider all legitimate views and objections, + and endeavor to resolve them, + whether these views and objections are expressed by the active participants of the group + or by others + (e.g., another W3C group, + a group in another organization, + or the general public). + Decisions may be made during meetings + (face-to-face or distributed) + as well as through persistent text-based discussions.

+

Note: The CEO has the role of + assessing consensus within the Advisory Committee.

+

The following terms are used in this document + to describe the level of support for a decision among a set of eligible individuals:

+
+
Consensus: +
A substantial number of individuals in the set + support the decision + and there is no sustained objection from anybody in the set. + Individuals in the set may abstain. + Abstention is either an explicit expression of no opinion + or silence by an individual in the set. +
Unanimity: +
The particular case of consensus where all individuals in the set support the decision + (i.e., no individual in the set abstains). +
Dissent: +
At least one individual in the set sustains an objection. +
+

Note: A Formal Objection always indicates a sustained objection, + but isn’t necessary to express it + (except in the context of formal AC Reviews). + Disagreement with a proposed decision, + however, does not always rise to the level of sustained objection, + as individuals could be willing to accept a decision + while expressing disagreement.

+

By default, the set of individuals eligible to participate in a decision is the set of group participants. + The Process Document does not require a quorum for decisions + (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). + A charter may include a quorum requirement for consensus decisions.

+

Where unanimity is not possible, + a group should strive to make consensus decisions + where there is significant support and few abstentions. + The Process Document does not require a particular percentage of eligible participants + to agree to a motion in order for a decision to be made. + To avoid decisions where there is widespread apathy, + (i.e., little support and many abstentions), + groups should set minimum thresholds of active support before a decision can be recorded. + The appropriate percentage may vary depending on the size of the group + and the nature of the decision. + A charter may include threshold requirements for consensus decisions. + For instance, a charter might require a supermajority of eligible participants + (i.e., some established percentage above 50%) + to support certain types of consensus decisions.

+
+ Note: Chairs have substantial flexibility + in how they obtain and assess consensus among their groups. + Unless otherwise constrained by charter, + they may use modes including but not limited to explicit calls for consensus, + polls of participants, + “lazy consensus” in which lack of objection after sufficient notice is taken as assent; + or they may also delegate and empower a document editor + to assess consensus on their behalf, + whether in general + or for specific pre-determined circumstances + (e.g. in non-controversial situations, for specific types of issues, etc.). +

If questions or disagreements arise, + the final determination of consensus remains with the chair.

+
+

5.2.2. Managing Dissent

+

In some cases, even after careful consideration of all points of view, + a group might find itself unable to reach consensus. + The Chair may record a decision where there is dissent so that the group can make progress + (for example, to produce a deliverable in a timely manner). + Dissenters cannot stop a group’s work + simply by saying that they cannot live with a decision. + When the Chair believes that the Group has duly considered + the legitimate concerns of dissenters as far as is possible and reasonable, + the group should move on.

+

Groups should favor proposals that create the weakest objections. + This is preferred over proposals that are supported by a large majority + but that cause strong objections from a few people. + As part of making a decision where there is dissent, + the Chair is expected to be aware of which participants work for the same + (or related) + Member organizations and weigh their input accordingly.

+

Note: Dissenters can escalate their sustained objection to a decision by registering a Formal Objection.

+

5.2.3. Deciding by Vote

+

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, + and that a vote is necessary to break a deadlock. + In this case the Chair must record + (e.g., in the minutes of the meeting or in an archived email message):

+
    +
  • an explanation of the issue being voted on; +
  • the decision to conduct a vote + (e.g., a simple majority vote) to resolve the issue; +
  • the outcome of the vote; +
  • any Formal Objections. +
+

In order to vote to resolve a substantive issue, + an individual must be a group participant. + Each organization represented in the group must have at most one vote, + even when the organization is represented by several participants in the group + (including Invited Experts). + For the purposes of voting:

+
    +
  • A Member or group of related Members is considered a single organization. +
  • The Team is considered an organization. +
+

Unless the charter states otherwise, Invited Experts may vote.

+

If a participant is unable to attend a vote, + that individual may authorize anyone at the meeting + to act as a proxy. + The absent participant must inform the Chair in writing + who is acting as proxy, with written instructions on the use of the proxy. + For a Working Group or Interest Group, + see the related requirements regarding an individual + who attends a meeting as a substitute for a participant.

+

A group may vote for other purposes than to resolve a substantive issue. + For instance, the Chair often conducts a “straw poll” vote + as a means of determining whether there is consensus about a potential decision.

+

A group may also vote to make a process decision. + For example, + it is appropriate to decide by simple majority + whether to hold a meeting in San Francisco or San Jose + (there’s not much difference geographically). + When simple majority votes are used to decide minor issues, + voters are not required to state the reasons for votes, + and the group is not required to record individual votes.

+

A group charter may include formal voting procedures + (e.g., quorum or threshold requirements) + for making decisions about substantive issues.

+

5.3. Formally Addressing an Issue

+

In the context of this document, + a group has formally addressed an issue when it has sent a public, substantive response + to the reviewer who raised the issue. + A substantive response is expected to include rationale for decisions + (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). + The adequacy of a response is measured + against what a W3C reviewer would generally consider to be technically sound. + If a group believes that a reviewer’s comments result from a misunderstanding, + the group should seek clarification before reaching a decision.

+

As a courtesy, + both Chairs and reviewers should set expectations + for the schedule of responses and acknowledgments. + The group should reply to a reviewer’s initial comments + in a timely manner. + The group should set a time limit + for acknowledgment by a reviewer of the group’s substantive response; + a reviewer cannot block a group’s progress. + It is common for a reviewer to require a week or more + to acknowledge and comment on a substantive response. + The group’s responsibility to respond to reviewers + does not end once a reasonable amount of time has elapsed. + However, reviewers should realize + that their comments will carry less weight + if not sent to the group in a timely manner.

+

Substantive responses should be recorded. + The group should maintain an accurate summary + of all substantive issues and responses to them + (e.g., in the form of an issues list with links to mailing list archives).

+

5.4. Reopening a Decision When Presented With New Information

+

The Chair may reopen a decision + when presented with new information, including:

+
    +
  • additional technical information, +
  • comments by email from participants who were unable to attend a scheduled meeting, +
  • comments by email from meeting attendees + who chose not to speak out during a meeting + (e.g., so they could confer later with colleagues or for cultural reasons). +
+

The Chair should record + that a decision has been reopened, + and must do so upon request from a group participant.

+

5.5. Registering Formal Objections

+

Any individual + (regardless of whether they are associated with a Member) may appeal any decision made in connection with this Process + (except those having a different appeal process) + by registering a Formal Objection with the Team. + Group participants should inform + their Team Contact as well as the group’s Chair(s). + The Team Contact must inform the CEO when a group participant has also raised concerns about due process.

+

Note: In this document, the term Formal Objection is used to emphasize this process implication: + Formal Objections receive formal consideration and a formal response. + The word “objection” used alone has its ordinary English connotations. + See § 5.2 Consensus Building.

+

A Formal Objection must include a summary of + the issue (whether technical or procedural), + the decision being appealed, + and the rationale for the objection. + It should cite technical arguments + and propose changes that would remove the Formal Objection; + these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments + or rationale are unlikely to receive serious consideration. + Counter-arguments, + rationales, + and decisions should also be recorded.

+

A record of each Formal Objection against a decision regarding a publicly-available document must be made publicly available; + likewise, a record of each Formal Objection against a Member-visible decision must be made available to Members. + A Call for Review to the Advisory Committee must identify any Formal Objections related to that review.

+

Note: Formal Objections against matter in a technical report are required to be addressed before requesting advancement of the technical report.

+

A Formal Objection filed during an Advisory Committee Review is considered registered at the close of the review period.

+

5.6. Addressing Formal Objections

+

5.6.1. Investigation and Mediation by the Team

+

The Team considers the Formal objection, + researches the question, + interviews parties, + and so on, + to make sure the problem and the various viewpoints are well understood, + and to the extent possible, + to arrive at a recommended disposition. + If the Team can resolve the issue + to the satisfaction of the individual that filed the Formal Objection, + the individual withdraws the objection and the disposition process terminates.

+

Otherwise, + upon concluding that consensus cannot be found, + and no later than 90 days after the Formal Objection being registered, + the Team must initiate formation of a W3C Council, + which should be convened within 45 days of being initiated. + Concurrently, it must prepare a report for the Council documenting its findings and attempts to find consensus.

+

5.6.2. W3C Council

+

A W3C Council is the body convened to resolve Formal Objections by combining the capabilities and perspectives of the AB, the TAG, and the Team, + and is tasked with doing so in the best interests of the Web and W3C.

+
5.6.2.1. Council Composition
+

Each W3C Council is composed of the following members (excepting any renounced or dismissed):

+ +

Participation in a W3C Council must not require attendance of face-to-face meetings.

+

A distinct instance of the W3C Council is convened for each decision being appealed or objected to. + Membership of each Council instance is fixed at formation, + and is not changed by any AB or TAG elections + occurring before that Council has reached a conclusion. + However, if participation in a Council falls so low as to hinder effective and balanced deliberations, + the W3C Council Chair should dissolve the Council and call for a new one to be convened.

+

A Team member is assigned + to act as the Council Team Contact, + to support this Council + and to facilitate adherence to this Process.

+
5.6.2.2. Extraordinary Delegation
+

In extraordinary cases, + if they feel a Council would not be the appropriate deciding body, + a member of the Team (particularly the Legal Counsel) or + any potential Council member + may suggest that the decision for that specific Formal Objection be delegated + to the W3C Board of Directors, + to an officer of its corporation (such as the Legal Counsel), + or to one or more specific individuals from the Team. + The potential Council members then may confidentially discuss + and must vote + whether to delegate the decision for that specific Formal Objection. + A decision to delegate must be supported by a two-thirds supermajority vote + (i.e., at least twice as many votes in favor as against). + Delegation in such cases cannot be later revoked.

+

The Team must inform the Advisory Committee when a Formal Objection has been delegated, + and to whom it has been delegated.

+
5.6.2.3. Council Participation, Dismissal, and Renunciation
+

A potential Council member may be dismissed from the Council. + In order to apply consistent criteria, + the potential Council members decide collectively + which reasons against service + rise to a sufficient level for a potential member to be dismissed. + No-one is automatically dismissed, + and individual recusal is not used in the Council. Dismissal applies to an individual person in the context of a specific Council, + and should be used rarely in order to preserve the greatest diversity on the Council.

+

Note: A W3C Council is a deliberative body whose purpose is + to find the best way forward for the Web and for W3C. + It is not a judicial body tasked with determining right or wrong.

+

The Team must draft a list of potential Council members, + with annotations of possible reasons for dismissal against each one. + The W3C community, + including members and team, and potential council members, must be given an opportunity to contribute possible reasons to this list. + Affected members must be given + an opportunity to respond to such comments about themselves. + The Team may report comments verbatim + or may paraphrase them while preserving their intent; + they may also elide inappropriate comments, + such as any that violate applicable laws or the [CEPC].

+

Before a Council forms, + the Team presents the entire list of potential members + and collected reasons and responses + to the potential Council members, + who then consider for each potential member + whether that individual’s participation + would compromise the integrity of the Council decision, + and vote whether to dismiss that potential member. + No one is allowed to vote on their own dismissal; + each dismissal is decided by simple majority of those not abstaining.

+

Note: Since dismissal is individual, + when the decision being objected to was made by the TAG or AB acting as a body, + the entire TAG or AB is not expected or required to be dismissed.

+

An individual may also renounce their seat on a Council, for strong reason, + such as being forbidden by their employer to serve. The individual chooses the extent to which they explain + their renunciation. + Renunciation is disqualification from participation, + not abstention, + and should not be used + to excuse an absence of participation.

+

Any person who has been dismissed or who renounces their seat + does not receive Council materials, + take part in its deliberations, + help in the determination of consensus, + or vote. + The W3C Council may still solicit and hear their testimony, + as they can of anyone else in the W3C community.

+
5.6.2.4. Unanimous Short Circuit
+

The full Council process may be short-circuited if + the Team recommends a resolution + and every potential member of a Council who is not renouncing their seat + votes affirmatively (no abstentions) to adopt this resolution.

+

This step may be run concurrently with § 5.6.2.3 Council Participation, Dismissal, and Renunciation and prior to choosing a Chair.

+

Note: This is intended for exceptional cases + that don’t seem to warrant a full Council response + because they are, for instance, too trivial, duplicative, etc.

+
5.6.2.5. Council Chairing
+

The Chair of each W3C Council is chosen by its members, + by consensus if possible, + falling back to a vote if that fails. + The chair must be a member of that W3C Council. + Chair selection happens during formation of each Council, + and must be re-run + if requested by the Council Team Contact or by the Chair during the Council’s operation.

+
5.6.2.6. Council Deliberations
+

Upon appointment of the W3C Council Chair and delivery of the Team’s report, + the W3C Council is considered to be convened + and can start deliberations.

+

Having reviewed the information gathered by the Team, + the Council may conduct additional research or analysis, + or request additional information or interviews from anyone, + including the Team.

+

The Council may further attempt to broker consensus, + which, if successful, disposes the formal objection.

+

Otherwise, + after sufficient deliberation, + the W3C Council decides whether to uphold or overrule the objection. + The W3C Council may overrule the Formal Objection even if it agrees with some of the supportive arguments.

+

When upholding an objection, + it should recommend a way forward. + If the overturned decision has already had consequences + (e.g., if the objection concerns material already in a published document) + the Council should suggest how these consequences might be mitigated. + The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion; + and the Formal Objection is not considered fully addressed until then.

+

Note: This does not create new powers for the Team, + such as the ability to “unpublish” documents. + The Team's role is to ensure the responsible parties enact adequate mitigations, + by whatever means they already have at their disposal.

+

A Council may form sub-groups for deliberation, + who may return with a recommendation, + but the full Council issues the final decision. + The decision of the W3C Council should be unanimous, + and may be issued under consensus. + However, if despite careful deliberation + a W3C Council is unable to reach consensus, + the W3C Council Chair may instead resort to voting. + In that case, + the decision is made by simple majority, + with the W3C Council Chair breaking any tie. + In case of a vote, + if two members of a Council who share the same affiliation cast an identical ballot, + then their ballots count as a one vote, + not two.

+

In the case of non-unanimous decisions, + members of a W3C Council who disagree with the decision may write a Minority Opinion explaining the reason for their disagreement.

+

The deliberations of a W3C Council are confidential to that W3C Council and its Council Team Contact.

+

If a W3C Council is unable to come to a conclusion within 45 days of being convened, + the W3C Council Chair must inform the AC of this delay + and of the status of the discussions. + The W3C Council Chair may additionally make this report public.

+
5.6.2.7. Council Decision Report
+

A Council terminates by issuing a Council Report, + which:

+
    +
  • +

    must state whether the Council upholds or overrules the objection(s).

    +
  • +

    must provide a rationale supporting the decision, +which should address each argument raised in the Formal Objection(s).

    +
  • +

    must include any recommendation decided by the Council.

    +
  • +

    if the Formal Objection has been upheld, should include any suggested mitigations.

    +
  • +

    must include the Minority Opinion(s), if any.

    +
  • +

    must report the names of those who were dismissed or renounced their seat as well as those who were qualified to serve.

    +
  • +

    must report the names of the individuals who participated in the final decision.

    +
  • +

    may report vote totals, if any vote was held.

    +
  • +

    must not attribute any position to any individual on the Council.

    +
+

The Team must maintain a public page on the W3C website indexing all completed Council Reports. + If a Council decision is later overturned by an AC Appeal, + this must also be mentioned. Council Reports must be no more confidential + than the decision or document being objected to.

+

The Council may also issue a Supplemental Confidential Council Report with a more restricted level of confidentiality than its main report + when it believes that additional commentary on confidential aspects of the case + would be informative. + However, the main Council Report should be self-sufficient + and understandable without reference to Supplemental Confidential Council Reports.

+
5.6.2.8. Appealing Council Decisions
+

Advisory Committee representatives may initiate an Advisory Committee Appeal of a Council decision issued in a Council Report.

+

5.7. Advisory Committee Reviews

+

Advisory Committee review is the process + by which the Advisory Committee formally confers its approval + on charters, technical reports, + and other matters.

+

5.7.1. Start of a Review Period

+

Each Advisory Committee review period + begins with a Call for Review from the Team to the Advisory Committee. + The Call for Review describes the proposal, + raises attention to deadlines, + estimates when the decision will be available, + and includes other practical information. + Each Member organization may send one review, + which must be returned by its Advisory Committee representative.

+

For clarity, + in the context of an AC Review, dissent must be expressed as a Formal Objection.

+

The Team must provide two channels for Advisory Committee review comments:

+
    +
  1. an archived Team-only channel; +
  2. an archived Member-only channel. +
+

The Call for Review must specify + which channel is the default for review comments on that Call.

+

Reviewers may send information + to either or both channels. + A reviewer may also share their own reviews + with other Members on the Advisory Committee discussion list, + and may also make it available to the public.

+

A Member organization may modify its review + during a review period + (e.g., in light of comments from other Members).

+

5.7.2. After the Review Period

+

After the review period, + the Team determines the appropriate W3C Decision, + which they must announce to the Advisory Committee. + The announcement must indicate + the level of support for the proposal + (consensus or dissent), + and specifically + whether there were any Formal Objections, + with attention to changing the confidentiality level of the Formal Objections.

+

If there were Formal Objections, at least some of which were upheld, + or if there is not consensus because of insufficient support, W3C Decision must be one of:

+
    +
  • The proposal is returned for additional work, + with a request to the initiator to improve the proposal. +
  • The proposal is rejected. +
+

If the proposal has consensus, + or if any Formal Objections are retracted or overruled + and the proposal otherwise has sufficient support to achieve consensus, + this W3C Decision must be one of:

+
    +
  • The proposal is adopted, + possibly with additional changes integrated + in order to address the comments of the AC (see below). +
  • The proposal is returned for additional work, + with a request to the initiator to make desirable changes identified during the review + and to resubmit. +
+

If the proposal is adopted with changes other than class 1 (markup) changes, + then those changes must be announced to the AC and to the Group that owns the document (if any).

+

Additionally, when adopting a proposal with substantive changes integrated, + the announcement must include rationale + for the substantive changes, + and those changes must have the consensus of the subset of the AC that voted on the proposal + (including anyone who explicitly abstained). + For publications which have conditions in addition to AC approval + for introducing substantive changes (such as Group consensus or implementation experience), + those other conditions must also be re-fulfilled.

+
For example, to make substantive changes to a Proposed Recommendations, + the technical report could be returned to Candidate Recommendation. + Alternatively, the desired changes can be introduced as non-substantive amendments + using the process for revising a Recommendation. + However, they cannot be directly integrated between PR and REC, + because that would fail to trigger a patent exclusion opportunity.
+

This document does not specify + time intervals between the end of an Advisory Committee review period + and the W3C decision. + This is to ensure that the Members and Team have sufficient time to consider comments + gathered during the review. + The Advisory Committee should not expect an announcement + sooner than two weeks after the end of a review period. + If, after three weeks, the outcome has not been announced, + the Team should provide the Advisory Committee with an update.

+

5.8. Advisory Committee Votes

+

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, + and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. + Whenever the Advisory Committee votes, + each Member or group of related Members has one vote.

+

5.9. Appeal by Advisory Committee Representatives

+

Advisory Committee representatives may appeal certain decisions, + though appeals are only expected to occur in extraordinary circumstances.

+

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate + an Advisory Committee Appeal. + These W3C decisions include those related to group creation and modification, + and transitions to new maturity stages for Recommendation Track documents + and the Process document.

+

Advisory Committee representatives may also initiate an appeal + for decisions of a W3C Council, and + for certain decisions that do not involve an Advisory Committee review. + These cases are identified in the sections + which describe the requirements for the decision + and include + additional (non-reviewed) maturity stages of Recommendation Track documents, + group charter extensions and closures, + and Memoranda of Understanding.

+

In all cases, + an appeal must be initiated within three weeks of the decision.

+

An Advisory Committee representative initiates an appeal by sending a request to the Team, + and should also share this request with the Advisory Committee. + The request should say “I appeal this Decision” + and identify the decision, + and may also include their rationale for appealing the decision.

+

Note: See Appealing a W3C Decision for a recommendation + on how to communicate an appeal request to the Team and the AC.

+

Within one week the Team must announce the appeal process + to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. + The archive of these statements must be member-only. + If, within one week of the Team’s announcement, + 5% or more of the Advisory Committee support the appeal request, + the Team must organize an appeal vote + asking the Advisory Committee “Do you approve of the Decision?” + together with links to the decision and the appeal support.

+

The ballot must allow for three possible responses: + “Approve”, + “Reject”, + and “Abstain”, + together with Comments.

+

If the number of votes to reject + exceeds the number of votes to approve, + the decision is overturned. + In that case, there are the following possible next steps:

+
    +
  1. The proposal is rejected. +
  2. The proposal is returned for additional work, + after which the applicable decision process is re-initiated. +
+

6. W3C Technical Reports

+

The W3C technical report development process is the set of steps and requirements + followed by W3C Working Groups to standardize Web technology. + The W3C technical report development process is designed to:

+
    +
  • support multiple specification development methodologies +
  • maximize consensus about the content of stable technical reports +
  • ensure high technical and editorial quality +
  • promote consistency among specifications +
  • facilitate royalty-free, interoperable implementations of Web Standards, and +
  • earn endorsement by W3C and the broader community. +
+

See also “licensing goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

6.1. Types of Technical Reports

+

This chapter describes the formal requirements + for publishing and maintaining a W3C Recommendation, Note, + or Registry Report.

+
+
Recommendations +
Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines + as standards for the Web. + The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, + and consensus-building, + and is subject to the W3C Patent Policy [PATENT-POLICY], + under which participants commit to Royalty-Free IPR licenses for implementations. + See § 6.3 The W3C Recommendation Track for details. +
Notes +
Groups can also publish documents as W3C Notes and W3C Statements, + typically either to document information + other than technical specifications, + such as use cases motivating a specification + and best practices for its use. + See § 6.4 The Note Track (Notes and Statements) for details. +
Registries +
Working Groups can also publish registries in order to document collections of values or other data. + These are typically published in a separate registry report, + although they can also be directly embedded in Recommendation Track documents + as a registry section. Defining a registry requires wide review and consensus, + but once set up, changes to registry entries are lightweight + and can even be done without a Working Group. + See § 6.5 The Registry Track for details. +
+

Individual Working Groups and Interest Groups should adopt additional processes + for developing publications, + so long as they do not conflict with the requirements in this chapter.

+

6.2. General Requirements for Technical Reports

+

6.2.1. Publication of Technical Reports

+

Publishing as used in this document + refers to producing a version which is listed as a W3C Technical Report on its Technical Reports index at https://www.w3.org/TR [TR]. + Every document published as part of the technical report development process must be a public document. + W3C strives to make archival documents indefinitely available + at their original address in their original form.

+

Every document published as part of the technical report development process must clearly indicate its maturity stage, + and must include information about the status of the document. + This status information:

+
    +
  • must be unique each time a specification is published, +
  • must state which Working Group developed the specification, +
  • must state how to send comments or file bugs, + and where these are recorded, +
  • must include expectations about next steps, +
  • should explain how the technology relates to existing international standards + and related work inside or outside W3C, + and +
  • should explain + or link to + an explanation of significant changes from the previous version. +
+

Every Technical Report published + as part of the Technical Report development process + is edited by one or more editors + appointed by a Group Chair. + It is the responsibility of these editors to ensure that the decisions of the Group are + correctly reflected in subsequent drafts of the technical report. + An editor must be a participant, + per § 3.4.2 Participation in Chartered Groups in the Group responsible for the document(s) they are editing.

+

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, + status information, + style, + and copyright requirements). + These rules are subject to change by the Team from time to time. + The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

+

The primary language for W3C Technical Reports is English. + W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C website.

+

6.2.2. Reviews and Review Responsibilities

+

A document is available for review + from the moment it is first published. + Working Groups should formally address any substantive review comment + about a technical report in a timely manner.

+

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, + particularly if this would cause significant compatibility problems + due to existing implementation. Working Groups should record substantive + or interesting proposals raised by reviews + but not incorporated into a current specification.

+
6.2.2.1. Wide Review
+

The requirements for wide review are not precisely defined by the W3C Process. + The objective is to ensure that the entire set of stakeholders of the Web community, + including the general public, + have had adequate notice of the progress of the Working Group (for example through notices posted to public-review-announce@w3.org) + and were able to actually perform reviews of and provide comments on the specification. + A second objective is to encourage groups to request reviews + early enough that comments and suggested changes + can still be reasonably incorporated in response to the review. + Before approving transitions, + the Team will consider who has been explicitly offered + a reasonable opportunity to review the document, + who has provided comments, + the record of requests to and responses from reviewers, + especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter + or identified as liaisons [LIAISON], + and seek evidence of clear communication to the general public + about appropriate times and which content to review + and whether such reviews actually occurred.

+

For example, + inviting review of new or significantly revised sections published in Working Drafts, + and tracking those comments + and the Working Group's responses, + is generally a good practice which would often be considered positive evidence of wide review. Working Groups should follow the W3C Horizontal Groups’ review processes, + and should announce to other W3C Working Groups + as well as the general public, + especially those affected by this specification, + a proposal to enter Candidate Recommendation (for example in approximately 28 days). + By contrast a generic statement in a document + requesting review at any time + is likely not to be considered as sufficient evidence + that the group has solicited wide review.

+

A Working Group could present evidence that wide review has been received, + irrespective of solicitation. + But it is important to note that receiving many detailed reviews + is not necessarily the same as wide review, + since they might only represent comment + from a small segment of the relevant stakeholder community.

+

6.2.3. Classes of Changes

+

This document distinguishes the following 5 classes of changes to a document. + The first two classes of change are considered editorial changes, + the next two substantive changes, + and the last one registry changes.

+
+
+ +
    +
  1. +

    No changes to text content

    +
+
These changes include fixing broken links, style sheets, or invalid markup. +
+ +
    +
  1. +

    Changes that do not functionally affect interpretation of the document

    +
+
For Recommendation-track technical reports specifically, + this constitutes changes that do not affect conformance, + i.e. changes that reasonable implementers + would not interpret as changing architectural + or interoperability requirements + or their implementation. + Changes which resolve ambiguities in the specification + are considered to change (by clarification) the implementation requirements + and do not fall into this class. +
Examples of changes in this class include + correcting non-normative examples + which clearly conflict with normative requirements, + clarifying informative use cases or other non-normative text, + fixing typos or grammatical errors + where the change does not change requirements. +
If there is any doubt or disagreement + as to whether a change functionally affects interpretation, + that change does not fall into this class. +
+ +
    +
  1. +

    Other changes that do not add new features

    +
+
+ For Recommendation-track documents, + these changes may affect conformance to the specification. + A change that affects conformance is one that: +
    +
  • makes conforming data, processors, or other conforming agents become non-conforming according to the new version, + or +
  • makes non-conforming data, processors, or other agents become conforming, + or +
  • clears up an ambiguity or under-specified part of the specification + in such a way that data, + a processor, + or an agent + whose conformance was once unclear + becomes clearly either conforming or non-conforming. +
+
+ +
    +
  1. +

    New features

    +
+
Changes that add new functionality, + such as new elements, new APIs, new rules, etc. +
+ +
    +
  1. +

    Changes to the contents of a registry table

    +
+
Changes that add, remove, or alter registry entries in a registry table. +
+

6.2.4. Errata Management

+

Tracking errors is an important part of a Working Group's ongoing care of a technical report; + for this reason, + the scope of a Working Group charter generally allows time + for work after publication of a Recommendation. + In this Process Document, + the term “erratum” + (plural “errata”) refers to any error + that can be resolved by one or more changes in classes 1-3 + of section § 6.2.3 Classes of Changes.

+

Working Groups must keep + a public record of errors + that are reported by readers and implementers + for Recommendations. + Such error reports should be compiled + no less frequently than quarterly.

+

Working Groups decide how to document errata. + Such documentation must identify + the affected technical report text + and describe the error; + it may also describe some possible solution(s). + Readers of the technical report should be able easily + to find and see the errata + that apply to that specific technical report with their associated tests. + Errata may be documented + in a separate errata page or tracking system. + They may, + in addition or alternatively, + be annotated inline + alongside the affected technical report text + or at the start or end of the most relevant section(s).

+

6.2.5. Candidate Amendments

+

An erratum may be accompanied by an informative, candidate correction approved by group decision. + When annotated inline, + errata—including their candidate corrections—must be marked as such, + are treated as class 2 changes, + and are published accordingly.

+

Note: Annotating changes in this way allows more mature documents + such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, + even when the candidate amendments have not yet received + sufficient review or implementation experience + to be normatively incorporated into the specification proper.

+

A candidate addition is similar to a candidate correction, + except that it proposes a new feature + rather than an error correction.

+

If there is no group chartered to maintain a technical report, + the Team may maintain its errata and associated candidate corrections. + Such corrections must be marked + as Team correction, + and do not constitute + a normative portion of the Recommendation, + as defined in the Patent Policy [PATENT-POLICY] (i.e. they are not covered by the Patent Policy). + The Team must solicit wide review on Team corrections that it produces.

+

Candidate corrections and candidate additions are collectively known as candidate amendments.

+

In addition to their actual maturity stage, published REC Track documents with candidate amendments are also considered, + for the purpose of the W3C Patent Policy [PATENT-POLICY], + to be Working Drafts with those candidate amendments treated as normative.

+

6.2.6. License Grants from Non-Participants

+

When a party who is not already obligated under the Patent Policy + offers a change in class 3 or 4 + (as described in § 6.2.3 Classes of Changes) to a technical report under this process + the Team must request + a recorded royalty-free patent commitment; + for a change in class 4, the Team must secure such commitment. + Such commitment should cover, + at a minimum, + all the party’s Essential Claims both in the contribution, + and that become Essential Claims as a result of incorporating the contribution into the draft + that existed at the time of the contribution, + on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

+

6.3. The W3C Recommendation Track

+

Working Groups create specifications and guidelines + to complete the scope of work envisioned by a Working Group's charter. + These technical reports undergo cycles of revision and review + as they advance towards W3C Recommendation status. + Once review suggests the Working Group has met their requirements for a new standard, + including wide review, + a Candidate Recommendation phase + allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. + At the end of the process, + the Advisory Committee reviews the mature technical report, + and if there is support from its Membership, + W3C publishes it as a Recommendation.

+

In summary, the W3C Recommendation Track consists of:

+
    +
  1. Publication of the First Public Working Draft. +
  2. Publication of zero or more revised Working Drafts. +
  3. Publication of one or more Candidate Recommendations. +
  4. Publication of a Proposed Recommendation. +
  5. Publication as a W3C Recommendation. +
+
+ + Basic W3C Recommendation Track + + + + + First Public Working Draft (FPWD) - Exclusion opportunity + + + + WG Decision + + Team Approval + + + + + + + + + Working Draft (WD) + + + + + + + + Publish a new Working Draft + + + WG Decision + + + + + + + + + Advance to Candidate Recommendation + + WG Decision + + Team Approval + + + + + + + + + + Candidate Recommendation Snapshot (CRS) - Patent Policy exclusion opportunity + + + + + + Candidate Recommendation Draft (CRD) + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + + Team Approval + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + Team Approval + + + + + + + + + + Advance to Proposed Recommendation + + WG Decision + + Team Approval + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision with AB+TAG Approval) + + + + + + + + + + + Proposed Recommendation (PR) — AC Review + + + AC Review + + + + + + Advance to Recommendation + + + W3C Decision + + + + + + + + + Return to Candidate Recommendation Snapshot + + + W3C Decision + + + + + + + + + Return to Working Draft + + + W3C Decision + + + + + + + + + + Recommendation (Rec) + + + + + +
+

This Process defines certain Recommendation Track publications as Patent Review Drafts. + Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004], + these correspond to “Last Call Working Draft” in the Patent Policy; + Starting from the 2020 Patent Policy [PATENT-POLICY-2020], + these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

+

W3C may end work on a technical report at any time.

+

As described in § 6.3.3 Advancement on the Recommendation Track, + the Team will decline a request to advance in maturity stage + and return the specification to a Working Group for further work + if it determines that the requirements for advancement + have not been met.

+

6.3.1. Maturity Stages on the Recommendation Track

+
+
Working Draft (WD) +
+ A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, + and other technical organizations, + and for simple historical reference. + Some, but not all, Working Drafts are meant to advance to Recommendation; + see the document status section of a Working Draft + for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, + and do not imply any endorsement by W3C + or its members beyond agreement to work on a general area of technology. + Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. + A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity. +

For all Working Drafts a Working Group:

+
    +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, + and +
  • may request publication of a Working Draft + even if its content is considered unstable + and does not meet all Working Group requirements. +
+

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), + and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

+
Candidate Recommendation (CR) +
+ A Candidate Recommendation is a document that satisfies the technical + requirements of the Working Group that produced it and their dependencies, + and has already received wide review. + W3C publishes a Candidate Recommendation to + +

Note: Advancing to Candidate Recommendation indicates + that the document is considered complete and fit for purpose, + and that no further refinement to the text is expected + without additional implementation experience and testing; + additional features in a later revision may however be expected. + A Candidate Recommendation is expected to be as well-written, + detailed, + self-consistent, + and technically complete + as a Recommendation, + and acceptable as such + if and when the requirements for further advancement are met.

+

Candidate Recommendation publications take one of two forms:

+
+
Candidate Recommendation Snapshot (CRS) +
+ A Candidate Recommendation Snapshot + corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. + Publishing a Patent Review Draft triggers a Call for Exclusions, + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy. +

Publication as a Candidate Recommendation Snapshot requires verification of either a Transition Request (for the first Candidate Recommendation publication from another maturity stage) + or an Update Request (for subsequent Candidate Recommendation Snapshots).

+
Candidate Recommendation Draft (CRD) +
+ A Candidate Recommendation Draft + is published on the W3C’s Technical Reports page [TR] to integrate changes from the previous Candidate Recommendation Snapshot that the Working Group intends to include + in a subsequent Candidate Recommendation Snapshot. + This allows for wider review of the changes + and for ease of reference to the integrated specification. +

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot. + However, the process requirements are minimized + so that the Working Group can easily keep the specification up to date.

+

A Candidate Recommendation Draft does not provide an exclusion opportunity; + instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

+
+

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered + such that W3C cannot endorse it or continue work on it, + for example due to burdensome patent claims that affect implementers and cannot be resolved + (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). + There is no path to restoration for a Rescinded Candidate Recommendation. + See “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

+
Proposed Recommendation (PR) +
A Proposed Recommendation is a document + that has been accepted by W3C + as of sufficient quality to become a W3C Recommendation. + This phase triggers formal review by the Advisory Committee, + who may recommend + that the document be published as a W3C Recommendation, + returned to the Working Group for further work, + or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation. +
W3C Recommendation (REC) +
+ A W3C Recommendation is a specification + or set of guidelines + or requirements that, + after extensive consensus-building, + has received the endorsement of W3C and its Members. + W3C recommends the wide deployment + of its Recommendations as standards for the Web. + The W3C Royalty-Free IPR licenses + granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. + As technology evolves, + a W3C Recommendation may become: +
+
A Superseded Recommendation +
+ A Superseded Recommendation is a specification + that has been replaced by a newer version + that W3C recommends for new adoption. + An Obsolete or Superseded specification + has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy. +

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, + the latest version replaces the previous one, + without the need to invoke the steps of § 6.3.13.3 Abandoning a W3C Recommendation: + it is the same document, updated. + Explicitly declaring a documented superseded, using the process documented in § 6.3.13.3 Abandoning a W3C Recommendation, + is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

+
An Obsolete Recommendation +
An Obsolete Recommendation is a specification + that W3C has determined lacks sufficient market relevance + to continue recommending it for implementation, + but which does not have fundamental problems + that would require it to be Rescinded. + If an Obsolete specification gains sufficient market relevance, + W3C may decide to restore it to Recommendation status. +
Rescinded Recommendation +
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, + and believes is unlikely to ever be restored to Recommendation status. + See also “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+
Discontinued Draft +
A technical report representing the state of a Recommendation-track document + at the point at which work on it was discontinued. + See § 6.3.13.1 Abandoning an Unfinished Recommendation. +
+

Only sufficiently technically mature work should be advanced.

+

Note: Should faster advancement to meet scheduling considerations be desired, + this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring + less stable features to other technical reports.

+

When publishing an updated version of an existing Candidate Recommendation or Recommendation, + technical reports are expected to meet the same maturity criteria as when they are first published under that status. + However, in the interest of replacing stale documents with improved ones in a timely manner, + if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, + it is also permissible to publish an updated CR or REC following the usual process, + even if only some of these flaws have been satisfactorily addressed.

+

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, + and do not necessarily imply consensus of a Working Group or Interest Group, + nor are their contents endorsed in any way by W3C.

+

6.3.2. Implementation Experience

+

Implementation experience is required to show that a specification is sufficiently clear, + complete, + and relevant to market needs, + to ensure that independent interoperable implementations + of each feature of the specification will be realized. + While no exhaustive list of requirements is provided here, + when assessing that there is adequate implementation experience the Team will consider (though not be limited to):

+
    +
  • is each feature of the current specification implemented, + and how is this demonstrated? +
  • are there independent interoperable implementations of the current specification? +
  • are there implementations created by people other than the authors of the specification? +
  • are implementations publicly deployed? +
  • is there implementation experience + at all levels of the specification’s ecosystem + (authoring, consuming, publishing…)? +
  • are there reports of difficulties or problems with implementation? +
+

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. + Groups are often able to work more effectively + if they plan how they will demonstrate interoperable implementations + early in the development process; + for example, developing tests in concert with implementation efforts.

+

6.3.3. Advancement on the Recommendation Track

+

For all requests to advance a specification + to a new maturity stage + (called Transition Requests), + the Working Group:

+
    +
  • must record the group’s decision to request advancement. +
  • must obtain Team verification. Team verification (a Team decision) must be withheld if any Process requirements are not met + or if there remain any unresolved Formal Objections + (including any upheld by a Council but not yet fully addressed), + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects a Transition Request it must indicate its rationale + to the Advisory Committee and the Working Group. +
  • must publicly document all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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 stage. +
  • must provide public documentation of any Formal Objections. +
  • should report which, if any, of the Working Group's requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

For a First Public Working Draft there is no “previous maturity stage”, + so many requirements do not apply, + and verification is normally fairly straightforward. + For later stages, + especially transition to Candidate or Proposed Recommendation, + there is usually a formal review meeting + to verify that the requirements have been met.

+

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved + while a Working Group's charter is undergoing or awaiting a decision + on an Advisory Committee Review.

+

+

6.3.4. Updating Mature Publications on the Recommendation Track

+

Certain requests to re-publish a specification + within its current maturity stage + (called Update Requests) + require extra verification. + For such update requests, the Working Group:

+
    +
  • must record the group’s decision to request the update. +
  • must show that the changes have received wide review. +
  • must obtain Team verification, + or fulfill the criteria for § 6.3.4.1 Streamlined Publication Approval. Team verification (a Team decision), should be withheld if any Process requirements are not met, + and may be withheld in consideration of unresolved Formal Objections + (including any upheld by a Council but not yet fully addressed) + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects an Update Request, + it must indicate its rationale to the Working Group. + If it waives any Process requirements, + it must indicate its rationale to the AC. +
  • must provide public documentation of any Formal Objections. +
  • must publicly document of all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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, + or explain why the requirements have changed or been deferred, +
  • should report which, if any, of the Working Group's requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

There is usually a formal review meeting + to verify that the requirements have been met.

+

Note: Update request verification is expected to be fairly simple + compared to verification of a transition request.

+

The Team must announce the publication + of the revised specification + to other W3C groups and the Public.

+
6.3.4.1. Streamlined Publication Approval
+

Note: These criteria are intentionally stricter than + the general requirements for an update request. + This is in order to minimize ambiguities and the need for expert judgment, + and to make self-evaluation practical.

+

In order to streamline the publication process in non-controversial cases, + verification of an update request is automatically granted without formal review + when the following additional criteria are fulfilled:

+
    +
  • There must have been no changes to Working Group requirements about this document. +
  • For each of the W3C Horizontal Groups [CHARTER], + if the Horizontal Review Group has made available a set criteria + under which their review is not necessary, + the Working Group must document that these criteria have been fulfilled. + Otherwise, the Working Group must show + that review from that group has been solicited and received. +
  • No Formal Objection has been registered against the document. +
  • + The Working Group must have formally addressed: +
      +
    • +

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

      +
    • +

      all issues raised against changes since the previous publication

      +
    • +

      all issues raised against the document that were closed since the previous publication with no change to the document

      +
    +

    The response to each of these issues must be to the satisfaction + 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.

    +

    Note: This is stricter than the general Transition Request criteria.

    +
+

Additionally, for updates to Recommendations with substantive changes or with new features:

+ +

The Working Group must provide written evidence for these claims, + and the Team must make these answers publicly and permanently available.

+

After publication, + if an AC Representative + or Team member + doubts that the evidence presented supports the claims, + they may request that a formal review meeting be convened post facto. + If that review finds that the requirements were not fulfilled, + the Team may revert the changes + by updating in place the status section to indicate that it has been reverted, + and by republishing the previously approved version of the technical report.

+

6.3.5. Publishing a First Public Working Draft

+

To publish the First Public Working Draft of a document, + a Working Group must meet the applicable requirements for advancement.

+

The Team must announce + the publication of a First Public Working Draft to other W3C groups and to the public.

+

6.3.6. Revising a Working Draft

+

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, + whose status section should indicate reasons for the lack of change.

+

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

+
    +
  • must record the group’s decision to request publication. Consensus is not required, + as this is a procedural step, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Working Draft, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous step, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups, +
+

Possible next steps for any Working Draft:

+ +

6.3.7. Transitioning to Candidate Recommendation

+

To publish a Candidate Recommendation, + in addition to meeting the requirements for advancement a Working Group:

+
    +
  • must show that the specification + has met all Working Group requirements, + or explain why the requirements have changed or been deferred, +
  • must document changes to dependencies during the development of the specification, +
  • must document + how adequate implementation experience will be demonstrated, +
  • must specify the deadline for comments, + delineating the Candidate Recommendation review period, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • must show that the specification has received wide review, and +
  • 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 Recommendation. +
+

The first Candidate Recommendation publication + after verification of having met the requirements for a Transition Request is always a Candidate Recommendation Snapshot. + The Team must announce + the publication of the Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

Possible next steps after a Candidate Recommendation Snapshot:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.8. Revising a Candidate Recommendation

+
6.3.8.1. Publishing a Candidate Recommendation Snapshot
+

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, + the Working Group must meet the requirements of an update request in order to republish.

+

In addition the Working Group:

+
    +
  • must specify the deadline for further comments, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • 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 Recommendation. +
+

The Team must announce + the publication of a revised Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

To provide timely updates and patent protection, + a Candidate Recommendation Snapshot should be published + within 24 months of the Working Group accepting + any proposal for a substantive change + (and preferably sooner). + To make scheduling reviews easier, + a Candidate Recommendation Snapshot should not be published + more often than approximately once every 6 months.

+

Note: Substantive changes trigger a new Exclusion Opportunity + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.8.2. Publishing a Candidate Recommendation Draft
+

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 + that would benefit from review beyond the Working Group.

+

To publish a revision of a Candidate Recommendation Draft, + a Working Group:

+
    +
  • must record the group’s decision to request publication, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups. +
+

Note: A Working Group does not need to + meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

+

Possible next steps after a Candidate Recommendation Draft:

+ +

6.3.9. Transitioning to Proposed Recommendation

+

In addition to meeting the requirements for advancement,

+
    +
  • The status information must specify the deadline for Advisory Committee review, + which must be at least 28 days + after the publication of the Proposed Recommendation and should be at least 10 days + after the end of the last Exclusion Opportunity + per ”Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+

A Working Group:

+ +

The Team:

+ +

Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on, + to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft.

+

A Proposed Recommendation may identify itself + as intending to allow new features (class 4 changes) + after its initial publication as a Recommendation, + as described in § 6.3.11.4 Revising a Recommendation: New Features. + Such an allowance cannot be added + to a technical report previously published as a Recommendation that did not allow such changes.

+

Possible Next Steps:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.10. Transitioning to W3C Recommendation

+

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

+

In addition to meeting the requirements for advancement,

+ +

Possible next steps: + A W3C Recommendation normally retains its status indefinitely. + However it may be:

+ +

6.3.11. Revising a W3C Recommendation

+

This section details the process for making changes to a Recommendation.

+
6.3.11.1. Revising a Recommendation: Markup Changes
+

A Working group may request republication of a Recommendation to make corrections that do not result + in any changes to the text of the specification. + (See class 1 changes.)

+

If there is no Working Group chartered to maintain a Recommendation, + the Team may republish the Recommendation with such changes incorporated.

+
6.3.11.2. Revising a Recommendation: Editorial Changes
+

Editorial changes to a Recommendation require no technical review of the intended changes. + A Working Group, + provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity stages. + (See class 2 changes.)

+

If there is no Working Group chartered to maintain a Recommendation, + the Team may republish the Recommendation with such changes incorporated, + including errata and Team corrections.

+
6.3.11.3. Revising a Recommendation: Substantive Changes
+

A candidate correction can be made normative + and be folded into the main text of the Recommendation, + once it has satisfied all the same criteria + as the rest of the Recommendation, + including review by the community to ensure + the technical and editorial soundness of the candidate amendments. + To validate this, the Working Group must request + a Last Call for Review of Proposed Amendments, + followed by an update request. + See § 6.3.11.5 Incorporating Candidate Amendments.

+

Alternatively, + a Working Group may incorporate the changes + and publish as a Working Draft—or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—and advance the specification from that state. + (See class 3 changes.)

+

Note: If there is no Working Group chartered to maintain a Recommendation the Team cannot make substantive changes and republish the Recommendation. + It can, however, informatively highlight problems and desirable changes + using errata and candidate corrections and republish as described in the previous section.

+
6.3.11.4. Revising a Recommendation: New Features
+

New features (see class 4 changes) + may be incorporated into a Recommendation explicitly identified as allowing new features using candidate additions. + A candidate addition can be made normative + and be folded into the main text of the Recommendation using the same process as for candidate amendments, + as detailed in § 6.3.11.3 Revising a Recommendation: Substantive Changes.

+

Note: This prohibition against new features unless explicitly allowed + enables third parties to depend on Recommendations having a stable feature-set, + as they have prior to the 2020 revision of this Process.

+

To make changes which introduce a new feature + to a Recommendation that does not allow new features, + W3C must create a new technical report, + following the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.

+
6.3.11.5. Incorporating Candidate Amendments
+

A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.

+

The Last Call for Review of Proposed Amendments must be announced to other W3C groups, the public, and the Advisory Committee. + The announcement must:

+
    +
  • Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, + or Last Call for Review of Proposed Corrections and Additions. +
  • Identify the specific candidate amendments under review + as proposed amendments (proposed corrections/proposed additions). +
  • Specify the deadline for review comments, + which must not be any sooner than 60 days from the Call for Review. +
  • Solicit review and, if it does not already have it, implementation experience. +
+

The combination of the existing Recommendation with the proposed amendments included in the Last Call for Review of Proposed Amendments is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. + Also, the review initiated by the Last Call for Review of Proposed Amendments is an Advisory Committee Review.

+

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

+

A Working Group may batch + multiple proposed amendments into a single Last Call for Review of Proposed Amendments. + To facilitate review, + a Last Call for Review of Proposed Amendments on a given specification should not be issued more frequently + than approximately once every 6 months.

+

At the end of the Last Call for Review of Proposed Amendments, + the W3C Decision may either be + to reject the proposed amendment, + or to clear the proposed amendment for advancement as is, + or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. + If the Working Group needs to amend a proposed amendment in response to review feedback + it must issue another Last Call for Review of Proposed Amendments on the revised change + before it can be incorporated into the main text.

+

Once all comments on a proposed amendment have been formally addressed, + and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, + it may incorporate the proposed amendment into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

+

To ensure adequate review of proposed amendment combinations, + only proposed amendments included in the most recent Last Call for Review of Proposed Amendments can be incorporated into the normative Recommendation text. + (Thus if incorporation of a proposed amendment is postponed, + it may need to be included in multiple Last Calls for Review of Proposed Amendments.)

+

6.3.12. Regression on the Recommendation Track

+

A Working Group may republish a Recommendation-track technical report at a lower maturity stage by fulfilling the requirements to transition to that maturity stage, + as described above.

+

Additionally, + with the approval of the TAG and the AB the Team may return + the technical report to a lower maturity stage in response to wide review or a formal objection.

+

6.3.13. Retiring Recommendation Track Documents

+

Work on a technical report may cease at any time. + Work should cease + if W3C or a Working Group determines + that it cannot productively carry the work any further.

+
6.3.13.1. Abandoning an Unfinished Recommendation
+

Any Recommendation-track technical report no longer intended + to advance or to be maintained, + and that is not being rescinded, should be published as a Discontinued Draft, + with no substantive change compared to the previous publication. + This can happen if + the Working Group decided + to abandon work on the report, + or as the result of an AC Review requiring the Working Group to discontinue work on the technical report before completion. + If a Working Group is made to close, + W3C must re-publish any unfinished technical report on the Recommendation track as Discontinued Draft.

+

Such a document should include in its status section + an explanation of why it was discontinued.

+

A Working Group may resume work + on such a technical report within the scope of its charter + at any time, + by re-publishing it as a Working Draft.

+
6.3.13.2. Rescinding a Candidate Recommendation
+

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

+
6.3.13.3. Abandoning a W3C Recommendation
+

It is possible that W3C decides + that implementing a particular Recommendation is no longer recommended. + There are three designations for such specifications, + chosen depending on the advice W3C wishes to give about further use of the specification.

+

W3C may obsolete a Recommendation, + for example if the W3C Community decides that the Recommendation no longer represents best practices, + or is not adopted and is not apparently likely to be adopted. + An Obsolete Recommendation may be restored to normal Recommendation, + for example because despite marking it Obsolete the specification is later more broadly adopted.

+

W3C may declare a Recommendation Superseded + if a newer version exists which W3C recommends for new adoption. + The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; + only the name and explanation change.

+

W3C may rescind a Recommendation + if W3C believes there is no reasonable prospect of it being restored + for example due to burdensome patent claims that affect implementers and cannot be resolved; + see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” + and “PAG Conclusion”.

+

W3C only rescinds, supersedes, or obsoletes entire Recommendations. + A Recommendation can be both superseded and obsolete. + To rescind, supersede, or obsolete some part of a Recommendation, + W3C follows the process for modifying a Recommendation.

+

Note: For the purposes of the W3C Patent Policy [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, + although it is not recommended for future implementation; + a Rescinded Recommendation ceases to be in effect + and no new licenses are granted under the Patent Policy.

+
+ + Supersede, Obsolete or Rescind a W3C Recommendation + + + + Recommendation (Rec) + + + + + A major problem and an AC review can lead to a Recommendation being Rescinded. + There are no new IPR licences issued under the W3C Patent Policy, + and reinstating the Recommendation requires going through the full Rec-track process again. + + Major problem, AC review + + + Rescinded Recommendation - no new IPR licenses + + + + + + + + + With little uptake, following AC review a specification may become an Obsolete Recommendation + + + + + Obsolete Recommendation + + + + + + + + If there is new uptake, with AC review an Obsolete Recommendation may return to normal Recommendation status + + + + + + + + + + + Replaced by a new version, AC review + + Superseded Recommendation + + + + + + + A Superseded Recommendation can become a normal Recommendation with AC review + + + + + + + + + + + +
+
6.3.13.4. Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
+

The process of rescinding, obsoleting, + superseding, + or restoring + a Recommendation can be initiated + either by a request from the Team or via a request from any of the following:

+
    +
  • The Working Group who produced, + or is chartered to maintain, + the Recommendation +
  • The TAG, if there is no such Working Group +
  • Any individual who made a request to the relevant Working Group as described above, + or the TAG if such a group does not exist, to obsolete, rescind, supersede, or restore a Recommendation, + where the request was not answered within 90 days +
  • 5% of the members of the Advisory Committee +
+

The Team must then + submit the request to the Advisory Committee for review. + For any Advisory Committee review of a proposal to + rescind, + obsolete, + supersede, + or restore + a Recommendation the Team must:

+
    +
  • announce the proposal to all Working Group Chairs, + and to the Public, + as well as to the Advisory Committee +
  • indicate that this is a proposal to + Rescind, + Obsolete, + Supersede, + or restore, + a Recommendation as appropriate +
  • identify the Recommendation by URL +
  • publish a rationale for the proposal +
  • identify known dependencies + and solicit review from all dependent Working Groups +
  • solicit public review +
  • specify the deadline for review comments, + which must be at least 28 days + after the announcement +
+

and should

+
    +
  • identify known implementations. +
+

If there was any dissent in the Advisory Committee review, + the Team must publish + the substantive content of the dissent to W3C and the public, + and must formally address the dissent + at least 14 days + before publication as an Obsolete or Rescinded Recommendation.

+

The Advisory Committee may initiate an Advisory Committee Appeal of the Team's decision.

+

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. + The updated version may remove the main body of the document. + The Status of this Document section should link + to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

+

Once W3C has published a Rescinded Recommendation, + future W3C technical reports must not include normative references + to that technical report.

+

Note: W3C strives to ensure that all Technical Reports + will continue to be available at their version-specific URL.

+

6.4. The Note Track (Notes and Statements)

+

6.4.1. Group Notes

+

A Group Note (NOTE) + is published + to provide a stable reference for a useful document + that is not intended to be a formal standard.

+

Working Groups, Interest Groups, + the TAG and the AB may publish work as Notes. + Examples include:

+
    +
  • supporting documentation for a specification, + such as explanations of design principles + or use cases and requirements +
  • non-normative guides to good practices +
+

Some Notes are developed through successive Draft Notes before publication as a full Notes, + while others are published directly as a Note. + There are few formal requirements to publish a document as a Note or Draft Note, + and they have no standing as a recommendation of W3C + but are simply documents preserved for historical reference.

+

Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Draft Notes.

+

6.4.2. Publishing Notes

+

In order to publish a Note or Draft Note, + the group:

+
    +
  • must record their decision + to request publication as a Note or Draft Note, and +
  • should publish documentation + of significant changes to the technical report + since any previous publication. +
+

Both Notes and Draft Notes can be updated by republishing + as a Note or Draft Note. + A technical report may remain + a Note indefinitely.

+

If a Note produced by a chartered group is no longer in scope for any group, + the Team may republish the Note with class 1 changes incorporated, + as well as with errata and Team corrections annotated.

+

6.4.3. Elevating Group Notes to W3C Statement status

+

A W3C Statement is a Note that has been endorsed by W3C as a whole. + In order to elevate a Note to W3C Statement status, + A group must:

+ +

A Note specifying implementable technology should not be elevated to W3C Statement status; + if it does, + the request to publish as a Statement must include rationale + for why it should be elevated, + and why it is not on the Recommendation track.

+

Once these conditions are fulfilled, + the Team must then + begin an Advisory Committee Review on the question of + whether the document is appropriate to publish as a W3C Statement. + During this review period, + the Note must not be updated.

+

The decision to advance a document to W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

The Team must announce the publication of a W3C Statement to the Advisory Committee, other W3C groups, and the public.

+

6.4.4. Revising W3C Statements

+

Given a recorded group decision to do so, + groups can request publication of a W3C Statement with editorial changes—including candidate amendment—without any additional process.

+

A candidate amendment can be folded into the main text of the W3C Statement, + once it has satisfied all the same criteria + as the rest of the Statement, + including review by the community to ensure + the substantive and editorial soundness of the candidate amendments. + To validate this, the group must request + an Advisory Committee review of the changes it wishes to incorporate. + The specific candidate amendments under review must be identified as proposed amendments just as in a Last Call for Review of Proposed Corrections.

+

The decision to incorporate proposed amendments into W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

6.5. The Registry Track

+

A registry documents a data set + consisting of one or more associated registry tables, + each table representing an updatable collection + of logically independent, consistently-structured registry entries. + A registry has three associated components:

+ +

The purposes of maintaining a registry can include:

+
+
non-collision +
Avoiding the problem + of two entities using the same value with different semantics. +
non-duplication +
Avoiding the problem + of having two or more different values in use with the same semantics. +
information +
Providing a central index + where anyone can find out + what a value means + and what its formal definition is + (and where it is). +
submission +
Ease of adding new terms, + including by stakeholders external to the custodian organization. +
consensus +
Promoting a clear consensus of the community on the terms. +
+

This section of the W3C Process provides a specialized process + facilitating the publication and maintenance of such registry tables, + particularly those required by or closely related to W3C Recommendations.

+

Note: Not every table in a specification is a potential registry. + If the intent or effect is that the table enumerates + all the possibilities the authors of the specification expect or envisage, + then the table by itself is enough. + Similarly, if the table is managed by the Working Group + and only updated as part of specification update, + then the complexities of registry management are not needed.

+

6.5.1. Registry Definitions

+

A registry definition defines what each registry table is and how it is maintained. + It must:

+
    +
  • Define the scope and purpose of each registry table. +
  • Define the fields of each registry table and their constraints + (e.g. values must be drawn from a defined set, or be unique, + or only reference publicly available resources, + etc.) +
  • + Define the policy for changes to existing entries, such as +
      +
    • whether entries can be deleted or deprecated +
    • whether entries can be changed after being published, and what kinds of changes are allowed +
    • whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely +
    +
  • Define the method and criteria by which changes are proposed, approved, and incorporated. + (For example, a registry could define + that changes to registry entries can be proposed using a particular web form or email address, + that they must be accompanied by certain background information, + or that they do or do not need to be approved by any member of a particular Working Group.) +
  • + Identify the custodian of the registry table: + the entity to which requests for registry changes must be sent, + and which is responsible for evaluating whether such requests + satisfy the criteria defined in the registry definition. +

    The custodian may be the Working Group, the Team, or a delegated entity. + The custodian for all registry tables in a single registry should generally be the same entity.

    +
+

6.5.2. Publishing Registries

+

Registries can be published either + as a stand-alone technical report on the Registry Track called a registry report, + or incorporated as part of a Recommendation as a registry section.

+

A registry report or registry section is purely documentational, + is not subject to the W3C Patent Policy, + and must not contain any requirements on implementations. + For the purposes of the Patent Policy [PATENT-POLICY], + any registry section in a Recommendation track document + is not a normative portion of that specification.

+

The registry report or registry section must:

+ +

The Team must make available + a means for interested parties to be notified of any updates to a registry table.

+

Note: Since the Process does not impose requirements + on changes to the contents of a registry table other than those imposed by the registry definition, + acceptance of proposed registry changes on behalf of the custodian and + publication of an updated registry report that contains + only registry changes since the previous publication + can be automated + if satisfaction of those rules can be automatically verified.

+

Rules for publication and advancement on the Registry Track are identical to that of the Recommendation Track with the following exceptions:

+ +

6.5.3. Updating Registry Tables

+

Changes to the contents of a registry table that are in accordance with the registry definition, + (i.e. Class 5 changes) + can be made by re-publishing the technical report that contains the affected table, + without needing to satisfy any other requirements for the publication + (not even Working Group consensus, unless this is required by the registry definition). + Such registry changes do not trigger new Advisory Committee Reviews, + nor Exclusion Opportunities, + and do not require verification via an update request, + even for technical reports at maturities where this would normally be expected. + Such publications can be made + even in the absence of a Working Group chartered to maintain the registry + when the custodian is another entity.

+

Note: The custodian is only empowered to make registry changes. + If the Working Group establishing the registry wishes + to empower the custodian to add commentary on individual entries, + this needs to be part of the registry table’s definition. + If other changes are desired, + they must be requested of the responsible Working Group—or in the absence of a Working Group, of the Team.

+

Changes to the registry tables made in accordance with candidate or proposed amendments to the registry definition which would not be allowed by the unamended registry definition must be identified as such.

+

6.5.4. Registry Data Reports

+

When the registry data is published in a separate technical report from its registry definition, + that report is called a Registry Data Report. + This technical report:

+ +

Registry Data Reports do not have maturity stages in and of themselves; + The maturity stage of the registry whose data they record + is that of the technical report holding the registry definition.

+

Anytime a change is made to a registry definition, + the Working Group must update and republish + any document holding the corresponding registry tables to make it consistent with these changes.

+

Given a recorded group decision to do so, + the Working Group may republish the Registry Data Report to incorporate editorial changes. + If there is no Working Group chartered to maintain this registry, + the Team may do so instead.

+

6.5.5. Specifications that Reference Registries

+

Registries document values, + they do not define any architectural or interoperability requirements + related to those values. + All architectural and interoperability requirements + pertaining to registry entries must be contained in the specifications that reference the registry, + and are therefore subject to the processes + (including approval and intellectual property provisions) + applicable to those referencing specifications.

+

If there are entries that must be implemented, + or any other such restrictions, + they must be defined or documented + in the referencing specification + without dependency on the registry.

+
For example, + “All implementations must implement the Basic-Method as defined in the registry” + is not acceptable; + a change to the definition of the Basic-Method in the registry would then affect conformance. + Instead, the requirement must be complete in the specification, + directly or by reference to another specification. + For example + “All implementations must recognize the name Basic-Method, + and implement it as defined by section yy of IETF RFC xxxx”. + (The Registry should nonetheless contain Basic-Method as an entry.)
+

6.6. Switching Tracks

+

Given a Group decision to do so, Working Groups can republish a technical report on a different track than the one it is on, + under the following restrictions:

+ +

Technical reports that switch tracks start at + their new track’s initial maturity stage, + while retaining any established identity (url, shortname, etc.).

+

6.7. Further reading

+

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews + and announcements of the various steps, + and tips on getting to Recommendation faster [REC-TIPS]. + Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

+

7. Dissemination Policies

+

7.1. Public Communication

+

The Team is responsible for managing communication within W3C + and with the general public + (e.g., news services, press releases, managing the website and access privileges, and managing calendars). + Members should solicit review by the Team + prior to issuing press releases about their work within W3C.

+

The Team makes every effort to ensure the persistence and availability of the following public information:

+
    +
  • W3C technical reports whose publication has been approved. + Per W3C IPR Policies, + W3C technical reports (and software) are available free of charge to the general public. +
  • A mission statement [MISSION] that explains the purpose and mission of W3C, + the key benefits for Members, + and the organizational structure of W3C. +
  • Legal documents, + including the Membership Agreement [MEMBER-AGREEMENT] and documentation of any legal commitments W3C has with other entities. +
  • The Process Document. +
  • Public results of W3C activities and Workshops. +
+

To keep the Members abreast of W3C meetings, Workshops, + and review deadlines, + the Team provides them with a regular (e.g., weekly) news service + and maintains a calendar [CALENDAR] of official W3C events. + Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

+

7.2. Confidentiality Levels

+

There are three principal levels of access to W3C information + (on the W3C website, in W3C meetings, etc.): + public, + Member-only, + and Team-only.

+

While much information made available by W3C is public, + “Member-only” information + is available to authorized parties only, + including representatives of Member organizations, Invited Experts, + the Advisory Board, + the TAG, + and the Team. + For example, + the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

+

“Team-only” information + is available to the Team and other authorized parties.

+

Those authorized to access Member-only and Team-only information:

+
    +
  • must treat the information as confidential within W3C, +
  • must use reasonable efforts to maintain the proper level of confidentiality, and +
  • must not release this information to the general public or press. +
+

The Team must provide mechanisms + to protect the confidentiality of Member-only information + and ensure that authorized parties have proper access to this information. + Documents should clearly indicate + whether they require Member-only confidentiality. + Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

+

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member + who are considered appropriate recipients. + For instance, + it is the responsibility of the Advisory Committee representative and other employees + and official representatives of the organization + to ensure that Member-only news announcements + are distributed for internal use only within their organization. + Information about Member mailing lists is available + in the New Member Orientation [INTRO].

+

7.3. Changing Confidentiality Level

+

As a benefit of membership, + W3C provides some Team-only and Member-only channels + for certain types of communication. + For example, Advisory Committee representatives can send reviews to a Team-only channel. + However, for W3C processes with a significant public component, + such as the technical report development process, + it is also important for information that affects decision-making to be publicly available. + The Team may need to communicate Team-only information to a Working Group or the public. + Similarly, a Working Group whose proceedings are Member-only must make public + information pertinent to the technical report development process.

+

This document clearly indicates which information must be available to Members or the public, + even though that information was initially communicated on Team-only or Member-only channels. + Only the Team and parties authorized by the Team + may change the level of confidentiality of this information. + When doing so:

+
    +
  1. The Team must use a version of the information + that was expressly provided by the author for the new confidentiality level. + In Calls for Review and other similar messages, + the Team should remind recipients to provide such alternatives. +
  2. The Team must not attribute the version + for the new confidentiality level to the author without the author’s consent. +
  3. If the author has not conveyed to the Team a version + that is suitable for another confidentiality level, + the Team may make available a version that reasonably communicates what is required, + while respecting the original level of confidentiality, + and without attribution to the original author. +
+

8. Workshops and Symposia

+

The Team organizes Workshops and Symposia to promote early involvement in the development of W3C activities + from Members and the public.

+

The goal of a Workshop is usually + either to convene experts and other interested parties for an exchange of ideas + about a technology or policy, + or to address the pressing concerns of W3C Members. + Organizers of the first type of Workshop may solicit position papers for the Workshop program + and may use those papers + to choose attendees and/or presenters.

+

The goal of a Symposium is usually + to educate interested parties about a particular subject.

+

The Call for Participation in a Workshop or Symposium may indicate participation requirements or limits, + and expected deliverables + (e.g., reports and minutes). + Organization of an event does not guarantee + further investment by W3C in a particular topic, + but may lead to proposals for new activities or groups.

+

Workshops and Symposia generally last one to three days. + If a Workshop is being organized to address the pressing concerns of Members, + the Team must issue the Call for Participation + no later than six weeks prior to the Workshop’s scheduled start date. + For other Workshops and Symposia, + the Team must issue a Call for Participation + no later than eight weeks prior to the meeting’s scheduled start date. + This helps ensure that speakers and authors + have adequate time to prepare position papers and talks.

+

9. Liaisons

+

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, + through a number of mechanisms + ranging from very informal + (e.g., an individual from another organization participates in a W3C Working Group, + or just follows its work) + to mutual membership, + to even more formal agreements. + Liaisons are not meant to substitute for W3C membership.

+

All liaisons must be coordinated by the Team due to requirements for public communication; + patent, + copyright, + and other IPR policies; + confidentiality agreements; + and mutual membership agreements.

+

W3C may negotiate technical agreements with another organization. + For purposes of the W3C Process, + a technical agreement is a formal contract, + or a Memorandum of Understanding (MoU), + or a similar document, + between W3C and another party or parties, + that relates to the technical activity of the Consortium + (e.g., its publications, groups, or liaisons). + It specifies rights and obligations of each party toward the others. + These rights and obligations may include joint deliverables, + an agreed share of technical responsibilities with due coordination, + and/or considerations for confidentiality and specific IPR.

+

Non-technical agreements, including + those between W3C and its Members for the purposes of membership, + between W3C and its Partners for the purposes of partnership [BYLAWS], + and other agreements related to the operation of the Consortium + or to the ordinary provision of services, + are not subject to these Process provisions.

+

When considering a technical agreement (i.e., before the decision whether to sign is made), + the Team should provide + the Advisory Committee with a draft of the proposed agreement, + along with an explanation of how W3C would benefit from signing this agreement, + for their review and discussion. + After addressing any comments, + and subject to any management or governance procedures that apply + (e.g., formal review of proposed contracts by legal counsel or by the Board), + if the Team decides to proceed with signing the agreement, + the Team must announce the intent to sign, + and provide the final text of the agreement, + with an explanation of signing rationale, to + the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the agreement. + If the proposal is rejected on appeal, + the Team must not sign the agreement on behalf of W3C + unless directed to do so by the Board. + A signed agreement should be made public.

+

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

+

10. Member Submission Process

+

The Member Submission process allows Members + to propose technology + or other ideas + for consideration by the Team. + After review, + the Team may make the material available at the W3C website. + The formal process affords Members a record of their contribution + and gives them a mechanism for disclosing the details of the transaction with the Team + (including IPR claims). + The Team also makes review comments on the Submitted materials available for W3C Members, + the public, + and the media.

+

A Member Submission consists of:

+
    +
  • One or more documents developed outside of the W3C process, and +
  • Information about the documents, + provided by the Submitter. +
+

One or more Members (called the Submitter(s)) may participate in a Member Submission. + Only W3C Members may be listed as Submitters.

+

The Submission process consists of the following steps:

+
    +
  1. One of the Submitters sends a request to the Team to acknowledge the Submission request. + The Team and Submitter(s) communicate to ensure that the Member Submission is complete. +
  2. + After review, the Team must either + acknowledge or reject the Submission request. + +
+
+ Note: To avoid confusion about the Member Submission process, please note that: + +
+

Making a Member Submission available at the W3C website + does not imply endorsement by W3C, + including the W3C Team or Members. + The acknowledgment of a Submission request + does not imply that any action will be taken by W3C. + It merely records publicly + that the Submission request has been made by the Submitter. + A Member Submission made available by W3C must not be referred to as “work in progress” of W3C.

+

The list of acknowledged Member Submissions [SUBMISSION-LIST] is available at the W3C website.

+

10.1. Submitter Rights and Obligations

+

When more than one Member jointly participates in a Submission request, + only one Member formally sends in the request. + That Member must copy + each of the Advisory Committee representatives of the other participating Members, + and each of those Advisory Committee representatives must confirm + (by email to the Team) + their participation in the Submission request.

+

At any time prior to acknowledgment, + any Submitter may withdraw support for a Submission request + (described in "How to send a Submission request" [SUBMISSION-REQ]). + A Submission request is “withdrawn” when no Submitter(s) support it. + The Team must not make statements + about withdrawn Submission requests.

+

Prior to acknowledgment, + the Submitter(s) must not, under any circumstances, + refer to a document as “submitted to the World Wide Web Consortium” + or “under consideration by W3C” or any similar phrase + either in public or Member communication. + The Submitter(s) must not imply + in public or Member communication + that W3C is working (with the Submitter(s)) on the material in the Member Submission. + The Submitter(s) may release the documents in the Member Submission to the public + prior to acknowledgment + (without reference to the Submission request).

+

After acknowledgment, + the Submitter(s) must not, under any circumstances, + imply W3C investment in the Member Submission + until, and unless, the material has been adopted as a deliverable + of a W3C Working Group.

+

10.1.1. Scope of Member Submissions

+

When a technology overlaps in scope with the work of a chartered Working Group, + Members should participate in the Working Group and contribute the technology to the group’s process + rather than seek publication through the Member Submission process. + The Working Group may incorporate the contributed technology into its deliverables. + If the Working Group does not incorporate the technology, + it should not publish the contributed documents + as Working Group Notes since Working Group Notes represent group output, + not input to the group.

+

On the other hand, + while W3C is in the early stages of developing a charter, + Members should use the Submission process + to build consensus around concrete proposals for new work.

+

Members should not submit materials + covering topics well outside the scope of W3C’s mission [MISSION].

+

10.1.2. Information Required in a Submission Request

+

The Submitter(s) + and any other authors of the submitted material must agree that, + if the request is acknowledged, + the documents in the Member Submission will be subject to the W3C Document License [DOC-LICENSE] and will include a reference to it. + The Submitter(s) may hold the copyright for the documents in a Member Submission.

+

The request must satisfy the Member Submission licensing commitments + in “Licensing Commitments in W3C Submissions” + in the W3C Patent Policy [PATENT-POLICY].

+

The Submitter(s) must include the following information:

+
    +
  • The list of all submitting Members. +
  • Position statements from all submitting Members (gathered by the Submitter). + All position statements must appear in a separate document. +
  • Complete electronic copies of any documents submitted for consideration + (e.g., a technical specification, + a position paper, + etc.) + If the Submission request is acknowledged, + these documents will be made available by W3C + and therefore must satisfy the Team’s Publication Rules [PUBRULES]. Submitters may hold the copyright for the material contained in these documents, + but when made available by W3C, + these documents must be subject to the provisions + of the W3C Document License [DOC-LICENSE]. +
+

The request must also answer the following questions.

+
    +
  • What proprietary technology is required to implement the areas addressed by the request, + and what terms are associated with its use? + Again, many answers are possible, + but the specific answer will affect the Team’s Decision. +
  • What resources, if any, + does the Submitter intend to make available + if W3C acknowledges the Submission request + and takes action on it? +
  • What action would the Submitter like W3C to take + if the Submission request is acknowledged? +
  • What mechanisms are there to make changes to the specification being submitted? + This includes, but is not limited to, + stating where change control will reside + if the request is acknowledged. +
+

For other administrative requirements related to Submission requests, + see “How to send a Submission request” [MEMBER-SUB].

+

10.2. Team Rights and Obligations

+

Although they are not technical reports, + the documents in a Member Submission must fulfill the requirements established by the Team, + including the Team’s Publication Rules [PUBRULES].

+

The Team sends a validation notice to the Submitter(s) + once the Team has reviewed a Submission request + and judged it complete and correct.

+

Prior to a decision to acknowledge or reject the request, + the request is Team-only, + and the Team must hold it in the strictest confidentiality. + In particular, + the Team must not comment to the media + about the Submission request.

+

10.3. Acknowledgment of a Submission Request

+

The Team acknowledges a Submission request + by sending an announcement to the Advisory Committee. + Though the announcement may be made at any time, + the Submitter(s) can expect an announcement between four to six weeks after the validation notice. + The Team must keep the Submitter(s) informed + of when an announcement is likely to be made.

+

Once a Submission request has been acknowledged, + the Team must:

+
    +
  • Make the Member Submission available at the W3C website. +
  • Make the Team comments about the Submission request available at the W3C website. +
+

If the Submitter(s) wishes to modify + a document made available as the result of acknowledgment, + the Submitter(s) must start the Submission process from the beginning, + even just to correct editorial changes.

+

10.4. Rejection of a Submission Request, and Submission Appeals

+

The Team may reject a Submission request + for a variety of reasons, + including any of the following:

+
    +
  • The ideas expressed in the request + overlap in scope with the work of a chartered Working Group, + and acknowledgment might jeopardize the progress of the group. +
  • The IPR statement made by the Submitter(s) is inconsistent with W3C’s + Patent Policy [PATENT-POLICY] and in particular the “Licensing Commitments in W3C Submissions”, Document License [DOC-LICENSE], + or other IPR policies. +
  • The ideas expressed in the request are poor, + might harm the Web, + or run counter to W3C’s mission [MISSION]. +
  • The ideas expressed in the request lie well outside the scope of W3C’s mission. +
+

In case of a rejection, + the Team must inform the Advisory Committee representative(s) + of the Submitter(s). + If requested by the Submitter(s), + the Team must provide rationale + to the Submitter(s) about the rejection. + Other than to the Submitter(s), + the Team must not make statements about why a Submission request was rejected.

+

The Advisory Committee representative(s) of the Submitters(s) may initiate a Submission Appeal. + The procedure for handling Submission Appeals is the same as for Formal Objections, + except that an AC Appeal is not possible + and both the Formal Objection and the Council Report are confidential to the Team, TAG, and AB.

+

11. Process Evolution

+

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, + with the Advisory Board—acting as the sponsoring Working Group. + The documents may be developed by the AB or by another group to whom the AB has delegated development. + Review includes + soliciting input from the W3C community, + and in particular the Team.

+

The documents covered by this section are:

+
    +
  • +

    the W3C Process (this document)

    +
  • +

    the W3C Patent Policy [PATENT-POLICY]

    +
  • +

    the W3C Code of Ethics and Professional Conduct [CEPC]

    +
  • +

    The W3C Document License [DOC-LICENSE]

    +
+

The Advisory Board initiates review as follows:

+
    +
  1. The Team sends a Call for Review to the Advisory Committee and other W3C groups. +
  2. After comments have been formally addressed and the document possibly modified, + the Team seeks endorsement from the Members by initiating an Advisory Committee review. + The review period must last at least 28 days. +
  3. After the Advisory Committee review, + following a W3C decision to adopt the document(s), + the Team does so + and sends an announcement to the Advisory Committee. + Advisory Committee representatives may initiate + an Advisory Committee Appeal to W3C. +
+

Note: As of June 2020, + the Patent Policy is developed in the Patents and Standards Interest Group, + the Code of Ethics and Professional Conduct in the Positive Work Environment Community Group, + and the Process in the W3C Process Community Group.

+

12. Acknowledgments

+

This section is non-normative.

+

The editors are grateful to the following people, + who as interested individuals and/or with the affiliation(s) listed, + have contributed to this proposal for a revised Process: + Brian Kardell, + Carine Bournez (W3C), + Charles McCathie Nevile (ConsenSys), + Chris Needham (BBC), + Chris Wilson (Google), + David Singer (Apple), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Elika J. Etemad aka fantasai, + Fuqiao Xue (W3C), + Jeff Jaffe (W3C), + Jeffrey Yasskin (Google), + Kevin Fleming (Bloomberg), + Léonie Watson (The Paciello Group), + Mark Nottingham (Cloudflare), + Michael Champion (Microsoft), + Nigel Megitt (BBC), + Philippe Le Hégaret (W3C), + Ralph Swick (W3C), + Samuel Weiler (W3C), + Sandro Hawke (W3C), + Shawn Lawton Henry, + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Virginia Fournier (Apple), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

The editors are sorry for forgetting any names, + and grateful to those who have listened patiently to conversations about this document + without feeling a need to add more.

+

The following individuals contributed to the development of earlier versions of the Process: + Alex Russell (Google), + Andreas Tai (Institut fuer Rundfunktechnik), + Andrew Betts (Fastly), + Ann Bassetti (The Boeing Company), + Anne van Kesteren, + Art Barstow (Nokia, unaffiliated), + Bede McCall (MITRE), + Ben Wilson, + Brad Hill (Facebook), + Brian Kardell (JQuery), + Carine Bournez (W3C), + Carl Cargill (Netscape, Sun Microsystems, Adobe), + Chris Lilley (W3C), + Chris Wilson (Google), + Claus von Riegen (SAP AG), + Coralie Mercier (W3C), + Cullen Jennings (Cisco), + Dan Appelquist (Telefonica, Samsung), + Dan Connolly (W3C), + Daniel Dardailler (W3C), + Daniel Glazman (Disruptive Innovations), + David Baron (Mozilla), + David Fallside (IBM), + David Singer (Apple), + David Singer (IBM), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Don Brutzman (Web3D), + Don Deutsch (Oracle), + Eduardo Gutentag (Sun Microsystems), + Elika J. Etemad aka fantasai, + Florian Rivoal, + Fuqiao Xue (W3C), + Geoffrey Creighton (Microsoft), + Giri Mandyam (Qualcomm), + Gregg Kellogg, + Hadley Beeman, + Helene Workman (Apple), + Henri Sivonen (Mozilla), + Håkon Wium Lie (Opera Software), + Ian Hickson (Google), + Ian Jacobs (W3C), + Ivan Herman (W3C), + J Alan Bird (W3C), + Jay Kishigami 岸上順一 (NTT), + Jean-Charles Verdié (MStar), + Jean-François Abramatic (IBM, ILOG, W3C), + Jeff Jaffe (W3C), + Jim Bell (HP), + Jim Miller (W3C), + Joe Hall (CDT), + John Klensin (MCI), + Josh Soref (BlackBerry, unaffiliated), + Judy Brewer (W3C), + Judy Zhu 朱红儒 (Alibaba), + Kari Laihonen (Ericsson), + Karl Dubost (Mozilla), + Ken Laskey (MITRE), + Kevin Fleming (Bloomberg), + Klaus Birkenbihl (Fraunhofer Gesellschaft), + Larry Masinter (Adobe Systems), + Lauren Wood (unaffiliated), + Liam Quin (W3C), + Léonie Watson (The Paciello Group), + Marcos Cáceres (Mozilla), + Maria Courtemanche (IBM), + Mark Crawford (SAP), + Mark Nottingham, + Michael Champion (Microsoft), + Michael Geldblum (Oracle), + Mike West (Google), + Mitch Stoltz (EFF), + Natasha Rooney (GSMA), + Nigel Megitt (BBC), + Olle Olsson (SICS), + Ora Lassila (Nokia), + Paul Cotton (Microsoft), + Paul Grosso (Arbortext), + Peter Linss, + Peter Patel-Schneider, + Philippe Le Hégaret (W3C), + Qiuling Pan (Huawei), + Ralph Swick (W3C), + Renato Iannella (IPR Systems), + Rigo Wenning (W3C), + Rob Sanderson (J Paul Getty Trust), + Robin Berjon (W3C), + Sally Khudairi (W3C), + Sam Ruby (IBM), + Sam Sneddon, + Sandro Hawke (W3C), + Sangwhan Moon (Odd Concepts), + Scott Peterson (Google), + Steve Holbrook (IBM), + Steve Zilles (Adobe Systems) + Steven Pemberton (CWI), + TV Raman (Google), + Tantek Çelik (Mozilla), + Terence Eden (Her Majesty’s Government), + Thomas Reardon (Microsoft), + Tim Berners-Lee (W3C), + Tim Krauskopf (Spyglass), + Travis Leithead (Microsoft), + Virginia Fournier (Apple), + Virginie Galindo (Gemalto), + Wayne Carr (Intel), + Wendy Fong (Hewlett-Packard), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

13. Changes

+

This section is non-normative.

+

Changes since the 2 November 2021 Process

+

This document is based on the 2 November 2021 Process. + A list of issues addressed, + a diff from Process 2021 to this latest version, + as well as + a detailed log of all changes since then are available.

+

In addition to a number of editorial adjustments + and minor tweaks, + the following is a summary of the main differences:

+

Changes related to the role of the Director

+ +

Other Governance Changes

+
    +
  • The TAG now picks its own chair(s), + and the timing of AB and TAG chair selection is clarified. +
  • Appointed TAG seats now have consecutive term limits. +
  • Remove mentions of the Hosts, + add recognition of the existence of the W3C Inc. Board of Directors, + and adjust language for W3C being rooted in W3C Inc. +
  • Codify that the AB is expected to pick up to two of its participants + as liaisons for the board. +
  • Clarify interactions between AC / Team / Board about MoUs + (now called technical agreements). +
+

Other miscellaneous changes

+
    +
  • Improve the definition of consensus + to make the notion usable even in contexts + where Formal Objections would be inappropriate + (such as inside a W3C Council, + or when the TAG or AB pick their chair), + and to avoid circular definitions. +
  • Merge Chair Decision Appeal, Group Decision Appeal, and Formal Objection; + clarify what can be objected to. +
  • Define editorial vs substantive changes for non-REC-track documents. +
  • Expect supporting material to meeting minutes to be archived as the minutes are. +
  • Encourage people requesting an AC Appeal to share their request with the Advisory Committee in addition to the Team. +
  • Allow Recommendations to transition directly to Working Draft without having to go through Candidate Recommendation when making substantive changes. +
  • Place the W3C Document License under the same revision process and requirements as this document, the CEPC, or the Patent Policy. +
  • Similarly to the pre-existing requirement that a public record be made + about confidential Formal Objections about public things, + added a requirement that a member visible record be made + about confidential Formal Objections about member-visible things. +
  • Stop excluding comments from AC Reps from those that have to be addressed + while transitioning to Proposed Recommendation; + just because there will be an opportunity to address them later + doesn’t mean they shouldn’t be handled at the first opportunity. +
  • Clarify what the term Candidate Recommendation review period refers to. +
  • Clarify how the advance notice period for MoU works. +
  • Various bits of information that were so far required + to be included in announcements of charter extensions are covered in the group’s homepage, + making it sufficient to point to that page + rather than having to inline everything in the announcement. +
  • Be more rigorous in references to the Patent Policy, + using dated versions when appropriate. +
  • Rename “Member Consortia” into Member Associations to align with terminology in the Bylaws + (and to avoid confusion with W3C itself). +
  • Rename “maturity level” into “maturity stage”. +
+

Changes since earlier versions

+

Changes since earlier versions of the Process are detailed + in the changes section of the previous version of the Process.

+
+
+

Conformance

+

Document conventions

+

Conformance requirements are expressed + with a combination of descriptive assertions + and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text + with class="example", + like this:

+
+ +

This is an example of an informative example.

+
+

Informative notes begin with the word “Note” + and are set apart from the normative text + with class="note", + like this:

+

Note, this is an informative note.

+
+ +
+

Index

+

Terms defined by this specification

+ + + + +

Terms defined by reference

+ +

References

+

Normative References

+
+
[CEPC] +
W3C Code of Ethics and Professional Conduct. URL: https://www.w3.org/Consortium/cepc/ +
[COLLABORATORS-AGREEMENT] +
Invited expert and collaborators agreement. URL: https://www.w3.org/Consortium/Legal/collaborators-agreement +
[CONFLICT-POLICY] +
Conflict of Interest Policy for W3C Team Members Engaged in Outside Professional Activities. URL: https://www.w3.org/2000/09/06-conflictpolicy +
[DOC-LICENSE] +
W3C Document License. URL: https://www.w3.org/Consortium/Legal/copyright-documents +
[PATENT-POLICY] +
The W3C Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy/ +
[PATENT-POLICY-2004] +
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/ +
[PATENT-POLICY-2020] +
The W3C 2020 Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy-20200915/ +
[PUBRULES] +
Publication Rules. URL: https://www.w3.org/pubrules/ +
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
[RFC3797] +
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://www.rfc-editor.org/rfc/rfc3797 +
[W3C-PATENT-POLICY] +
Wendy Seltzer. W3C Patent Policy. 15 September 2020. URL: https://www.w3.org/Consortium/Patent-Policy/ +
[W3C-PROCESS] +
Elika J. Etemad (fantasai); Florian Rivoal. W3C Process Document. 2 November 2021. URL: https://www.w3.org/Consortium/Process/ +
+

Informative References

+
+
[AB-HP] +
The Advisory Board home page. URL: https://www.w3.org/2002/ab/ +
[AC-MEETING] +
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/Member/Meeting/ +
[BG-CG] +
Community and Business Group Process. URL: https://www.w3.org/community/about/process/ +
[BYLAWS] +
Amended and Restated Bylaws of World Wide Web Consortium, Inc.. URL: https://www.w3.org/2022/10/w3c-bylaws-20221019.pdf +
[CALENDAR] +
Calendar of all scheduled official W3C events. URL: https://www.w3.org/participate/eventscal +
[CHAIR] +
W3C Working/Interest Group Chair. URL: https://www.w3.org/Guide/chair/role.html +
[CHARTER] +
How to Create a Working Group or Interest Group. URL: https://www.w3.org/Guide/process/charter.html +
[COUNCIL-REPORT-INDEX] +
Council Report Index. URL: https://beta.w3.org/about/council/ +
[CURRENT-AC] +
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList +
[DECISION-APPEAL] +
Appealing a W3C Decision. URL: https://www.w3.org/Guide/process/ac-appeal +
[ELECTION-HOWTO] +
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/2002/10/election-howto +
[FELLOWS] +
W3C Fellows Program. URL: https://www.w3.org/Consortium/Recruitment/Fellows +
[GROUP-MAIL] +
Group mailing lists. URL: https://www.w3.org/groups/ +
[GUIDE] +
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/Guide/ +
[INTRO] +
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro +
[JOIN] +
How to Join W3C. URL: https://www.w3.org/Consortium/join +
[LIAISON] +
W3C liaisons with other organizations. URL: https://www.w3.org/2001/11/StdLiaison +
[MEMBER-AGREEMENT] +
W3C Membership Agreement. URL: https://www.w3.org/Consortium/Agreement/Member-Agreement +
[MEMBER-HP] +
Member website (Member-only access). URL: https://www.w3.org/Member/ +
[MEMBER-LIST] +
The list of current W3C Members. URL: https://www.w3.org/Consortium/Member/List +
[MEMBER-SUB] +
How to send a Submission request. URL: https://www.w3.org/2000/09/submission +
[MISSION] +
The W3C Mission statement. URL: https://www.w3.org/Consortium/mission +
[OBS-RESC] +
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/2016/11/obsoleting-rescinding/ +
[REC-TIPS] +
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/2002/05/rec-tips +
[REPUBLISHING] +
In-place modification of W3C Technical Reports. URL: https://www.w3.org/2003/01/republishing/ +
[SUBMISSION-LIST] +
The list of acknowledged Member Submissions. URL: https://www.w3.org/Submission/ +
[SUBMISSION-REQ] +
Make or Withdraw a Member Submission Request (Member-only access). URL: https://www.w3.org/2000/09/submission +
[TAG-CHARTER] +
Technical Architecture Group (TAG) Charter. URL: https://www.w3.org/2004/10/27-tag-charter.html +
[TAG-HP] +
The TAG home page. URL: https://www.w3.org/2001/tag/ +
[TEAM-CONTACT] +
Role of the Team Contact. URL: https://www.w3.org/Guide/teamcontact/role.html +
[TR] +
The W3C technical reports index. URL: https://www.w3.org/TR/ +
[TRANSITION] +
Organize a Technical Report Transition. URL: https://www.w3.org/Guide/transitions +
[TRANSLATION] +
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/ +
[W3C-IPR] +
W3C IPR Policies. URL: https://www.w3.org/Consortium/Legal/2002/ipr-notice-20021231 +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/snapshots/2023-08.html b/snapshots/2023-08.html new file mode 100644 index 00000000..fb711fb0 --- /dev/null +++ b/snapshots/2023-08.html @@ -0,0 +1,5821 @@ + + + + + W3C Process Document + + + + + + + + + + + + + + + +
+

+

W3C Process Document

+

Draft Community Group Report,

+
+ More details about this document +
+
+
This version: +
https://www.w3.org/Consortium/Process/Drafts/snapshots/2023-08 +
Editor's Draft: +
https://www.w3.org/Consortium/Process/Drafts/ +
Latest published version: +
https://www.w3.org/Consortium/Process/ +
Previous Versions: +
+
+
+
+
+
+
Feedback: +
Github (preferred) +
Public mailing list +
Member-only mailing list +
Editors: +
Elika J. Etemad / fantasai (Apple) +
Florian Rivoal (Invited Expert) +
Former Editors: +
Natasha Rooney (Invited Expert) +
Charles McCathie Nevile (Yandex) +
Ian Jacobs (W3C) +
+
+
+
+

Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

+
+
+
+

Abstract

+

The mission of the World Wide Web Consortium (W3C) is to lead the World Wide Web to its full potential + + by developing common protocols that promote its evolution and ensure its interoperability. + The W3C Process Document describes the organizational structure of W3C and processes, + responsibilities and functions that enable W3C to accomplish its mission. + This document does not describe the internal workings of the Team.

+

For more information about the W3C mission and the history of W3C, + + please refer to About W3C.

+
+

Status of this document

+
+

W3C, including all existing chartered groups, + follows the most recent operative Process Document announced to the Membership.

+

This document is developed by the Advisory Board’s Process Task Force + working within the W3C Process Community Group (which anyone can join). + This is the 2 August 2023 Draft Community Group Report for the proposed next version of the W3C Process Document.

+

This document, + +which is based on the 12 June 2023 Process, +is offered for W3C Advisory Committee Review of the proposal to adopt this +as the new operative Process document +per Section 11 Process Changes.

+

A history of substantial changes from previous versions of the Process Document is provided.

+
+
+ +
+

Relation of Process Document to Patent Policy and Other Policies

+

W3C Members' attention is called to the fact + that provisions of the Process Document are binding on Members + per the Membership Agreement [MEMBER-AGREEMENT]. + The W3C Patent Policy [PATENT-POLICY] and other policies + incorporated by normative reference as a part of the Process Document + are equally binding.

+

The Patent Policy and CEPC place additional obligations on Members, Team, and other participants in W3C. + The Process Document does not restate those requirements but includes references to them. + The Process Document, Patent Policy, and CEPC have been designed to allow each to evolve independently.

+

In the Process Document, the term “participant” refers to an individual, not an organization.

+

Conformance and specialized terms

+

The terms must, must not, should, should not, required, + and may are used in accordance with RFC 2119. + The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

+

Some terms have been capitalized in this document (and in other W3C materials) + to indicate that they are entities with special relevance to the W3C Process. + These terms are defined within this document, + and readers are reminded that the ordinary English definitions are insufficient + for the purpose of understanding this document.

+ +
+

1. Introduction

+

W3C work revolves around the standardization of Web technologies. + To accomplish this work, W3C follows processes that promote the development of high-quality standards + based on the consensus of the Membership, Team, and public. + W3C processes promote fairness, responsiveness, and progress: + all facets of the W3C mission. + This document describes the processes W3C follows in pursuit of its mission.

+

The W3C Process promotes the goals of quality and fairness in technical decisions + by encouraging consensus, + soliciting reviews (by both Members and public), + incorporating implementation and interoperability experience, + and requiring Membership-wide approval as part of the technical report development process. Participants in W3C include representatives of its Members and the Team, + as well as Invited Experts who can bring additional expertise or represent additional stakeholders. Team representatives both contribute to the technical work + and help ensure each group’s proper integration with the rest of W3C.

+

W3C’s technical standards, called W3C Recommendations, + are developed by its Working Groups; + W3C also has other types of publications, + all described in § 6 W3C Technical Reports. + W3C has various types of groups; + this document describes the formation and policies + of its chartered Working Groups and Interest Groups, + see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. + W3C also operates Community and Business Groups, + which are separately described in their own process document [BG-CG].

+

In addition, several groups are formally established by the Consortium: + the W3C Advisory Committee, which has a representative from each Member, + and two oversight groups elected by its membership: + the Advisory Board (AB), + which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process; + and the Technical Architecture Group (TAG), + which helps resolve Consortium-wide technical issues.

+

Here is a general overview of how W3C initiates standardization of a Web technology:

+
    +
  1. People generate interest in a particular topic. + For instance, Members express interest by developing proposals in Community Groups + or proposing ideas in Member Submissions. + Also, the Team monitors work inside and outside of W3C for signs of interest, + and helps organize Workshops to bring people together + to discuss topics that interest the W3C community. +
  2. When there is enough interest and an engaged community, + the Team works with the Membership + to draft proposed Interest Group or Working Group charters. + W3C Members review the proposed charters, + and when there is support within W3C for investing resources in the topic of interest, + W3C approves the group(s), + and they begin their work. +
+

Further sections of this Process Document deal with topics including + liaisons (§ 9 Liaisons), + confidentiality (§ 7 Dissemination Policies), + and formal decisions and appeals (§ 5 Decisions).

+

2. Members and the Team

+

W3C’s mission is to lead the Web to its full potential. + W3C Member organizations provide resources to this end, + and the W3C Team provides the technical leadership + and organization to coordinate the effort.

+

2.1. Members

+

W3C Members are + organizations subscribed according to the Membership Agreement [MEMBER-AGREEMENT]. + They are represented in W3C processes as follows:

+
    +
  1. One representative per Member organization participates + in the Advisory Committee which oversees the work of W3C. +
  2. Representatives of Member organizations participate + in Working Groups and Interest Groups, + where they author and review technical reports. +
+

W3C membership is open to all entities, + as described in “How to Join W3C” [JOIN]; + (refer to the public list of current W3C Members [MEMBER-LIST]). + The Team must ensure + that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

+

While W3C does not have a class of membership tailored to individuals, + individuals may join W3C. + Restrictions pertaining to related Members apply + when the individual also represents another W3C Member.

+

2.1.1. Rights of Members

+

Each Member organization enjoys the following rights and benefits:

+ +

Furthermore, subject to further restrictions included in the Member Agreement, + representatives of Member organizations participate in W3C as follows:

+ +

The rights and benefits of W3C membership [MEMBER-AGREEMENT] are contingent upon conformance to the processes described in this document. + Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.

+

Additional information for Members is available at the Member website [MEMBER-HP].

+

2.1.2. Member Associations and Related Members

+
2.1.2.1. Membership Associations
+

A “Member Association” means a consortium, + user society, + or association of two or more individuals, + companies, + organizations or governments, + or any combination of these entities + which has the purpose of participating in a common activity + or pooling resources to achieve a common goal other than participation in, + or achieving certain goals in, + W3C. + A joint-stock corporation or similar entity is not a Member Association merely because it has shareholders or stockholders. + If it is not clear whether a prospective Member qualifies as a Member Association, + the CEO may reasonably make the determination. + For a Member Association, the rights and privileges of W3C Membership + described in the W3C Process Document extend to the Member Association's paid staff + and Advisory Committee representative.

+

Member Associations may also designate + up to four (or more at the Team’s discretion) individuals + who, though not employed by the organization, may exercise the rights of Member representatives.

+

For Member Associations that have individual people as members, + these individuals must disclose their employment affiliation + when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For Member Associations that have organizations as Members, + all such designated representatives must be an official representative of the Member organization + (e.g. a Committee or Task Force Chairperson) + and must disclose their employment affiliation when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For all representatives of a Member Association, + IPR commitments are made on behalf of the Member Association, + unless a further IPR commitment is made by the individuals' employers.

+
2.1.2.2. Related Members
+

In the interest of ensuring the integrity of the consensus process, + Member involvement in some of the processes in this document is affected by related Member status. + As used herein, two Members are related if:

+
    +
  1. Either Member is a subsidiary of the other, or +
  2. Both Members are subsidiaries of a common entity, or +
  3. The Members have an employment contract or consulting contract that affects W3C participation. +
+

A subsidiary is an organization of which effective control and/or majority ownership rests with another, + single organization.

+

Related Members must disclose these relationships + according to the mechanisms described in the New Member Orientation [INTRO].

+

2.2. The W3C Team

+

The Team consists of CEO, + W3C paid staff, + unpaid interns, + and W3C Fellows. W3C Fellows are Member employees working as part of the Team; + see the W3C Fellows Program [FELLOWS]. + The Team provides technical leadership about Web technologies, + organizes and manages W3C activities to reach goals + within practical constraints (such as resources available), + and communicates with the Members and the public + about the Web and W3C technologies.

+

The CEO may delegate responsibility + (generally to other individuals in the Team) + for any of their roles described in this document. Team Decisions derive from the CEO's authority, + even when they are carried out by other members of the Team.

+

Oversight over the Team, + budgeting, + and other business decisions, + is provided by the W3C Board of Directors, + rather than managed directly by the Process.

+

Note: See the W3C Bylaws for more details + on the Board and overall governance of W3C.

+

3. Groups and Participation

+

For the purposes of this Process, a W3C Group is one of W3C’s Working Groups, Interest Groups, Advisory Committee, Advisory Board, + or TAG, + and a participant is a member of such a group.

+

3.1. Policies for Participation in W3C Groups

+

3.1.1. Individual Participation Criteria

+
3.1.1.1. Expectations and Discipline
+

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

+
    +
  1. Technical competence in one’s role; +
  2. The ability to act fairly; +
  3. Social competence in one’s role. +
+

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities + are responsible for assessing and attesting to the qualities of those nominees.

+

Participants in any W3C activity must abide + by the terms and spirit of the W3C Code of Ethics and Professional Conduct [CEPC] and the participation requirements described in + “Disclosure” + in the W3C Patent Policy [PATENT-POLICY].

+

The CEO may take disciplinary action, + including suspending or removing for cause + a participant in any group (including the AB and TAG) + if serious and/or repeated violations, + such as failure to meet the requirements on individual behavior of + (a) this process + and in particular the CEPC, or + (b) the membership agreement, or + (c) applicable laws, + occur. + Refer to the Guidelines to suspend or remove participants from groups.

+
3.1.1.2. Conflict of Interest Policy
+

Individuals participating materially in W3C work must disclose significant relationships + when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. + These disclosures must be kept up-to-date + as the individual’s affiliations change and W3C membership evolves + (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). + Each section in this document that describes a W3C group + provides more detail about the disclosure mechanisms for that group.

+

The ability of an individual to fulfill a role within a group + without risking a conflict of interest depends on the individual’s affiliations. + When these affiliations change, + the individual’s assignment to the role must be evaluated. + The role may be reassigned according to the appropriate process. + For instance, + the Team may appoint a new group Chair when the current Chair changes affiliations + (e.g., if there is a risk of conflict of interest, + or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

+

The following are some scenarios where disclosure is appropriate:

+
    +
  • Paid consulting for an organization whose activity is relevant to W3C, + or any consulting compensated with equity + (shares of stock, stock options, or other forms of corporate equity). +
  • A decision-making role/responsibility + (such as participating on a Board) + in other organizations relevant to W3C. +
  • A position on a publicly visible advisory body, + even if no decision-making authority is involved. +
+

Individuals seeking assistance on these matters should contact the Team.

+

Team members are subject to the W3C Team conflict of interest policy [CONFLICT-POLICY].

+
3.1.1.3. Individuals Representing a Member Organization
+

Generally, individuals representing a Member in an official capacity within W3C + are employees of the Member organization. + However, an Advisory Committee representative may designate a non-employee + to represent the Member. + Non-employee Member representatives must disclose + relevant affiliations to the Team and to any group in which the individual participates.

+

In exceptional circumstances + (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), + the CEO may decline + to allow an individual designated by an Advisory Committee representative to participate in a group.

+

A group charter may limit + the number of individuals representing a W3C Member + (or group of related Members).

+

3.1.2. Meetings

+

The requirements in this section apply to the official meetings of any W3C group.

+

W3C distinguishes two types of meetings:

+
    +
  1. A face-to-face meeting is one + where most of the attendees are expected to participate in the same physical location. +
  2. A distributed meeting is one + where most of the attendees are expected to participate from remote locations + (e.g., by telephone, video conferencing, or IRC). +
+

A Chair may invite an individual with a particular expertise + to attend a meeting on an exceptional basis. + This person is a meeting guest, + not a group participant. + Meeting guests do not have voting rights. + It is the responsibility of the Chair to ensure + that all meeting guests respect the chartered level of confidentiality and other group requirements.

+
3.1.2.1. Meeting Scheduling and Announcements
+

Meeting announcements should be sent to all appropriate group mailing lists, + i.e. those most relevant to the anticipated meeting participants.

+

The following table lists recommendations for organizing a meeting:

+ + + + + + + + + +
+ Face-to-face meetings + Distributed meetings +
Meeting announcement (before) + eight weeks* + one week* +
Agenda available (before) + two weeks + 24 hours (or longer if a meeting is scheduled after a weekend or holiday) +
Participation confirmed (before) + three days + 24 hours +
Action items available (after) + three days + 24 hours +
Minutes available (after) + two weeks + 48 hours +
+

* To allow proper planning (e.g., travel arrangements), + the Chair is responsible for giving sufficient advance notice + about the date and location of a meeting. + Shorter notice for a meeting is allowed + provided that there are no objections from group participants.

+
3.1.2.2. Meeting Minutes
+

Groups should take and retain minutes of their meetings, + and must record + any official group decisions made during the meeting discussions. + Details of the discussion leading to such decisions are not required, + provided that the rationale for the group decision is nonetheless clear.

+
3.1.2.3. Meeting Recordings and Transcripts
+

No-one may take an audio or video recording of a meeting, + or retain an automated transcript, + unless the intent is announced at the start of the meeting, + and no-one participating in the recorded portion of the meeting withholds consent. + If consent is withheld by anyone, recording/retention must not occur. + The announcement must cover: + (a) who will have access to the recording or transcript and + (b) the purpose/use of it and + (c) how it will be retained (e.g. privately, in a cloud service) and for how long.

+

3.1.3. Tooling and Archiving for Discussions and Publications

+

For W3C Groups operating under this Process, + a core operating principle is to allow access across disabilities, + across country borders, + and across time. + Thus in order to allow all would-be participants to effectively participate, + to allow future participants and observers to understand the rationale and origins of current decisions, + and to guarantee long-lived access to its publications, + W3C requires that:

+
    +
  • All reports, publications, or other deliverables + produced by the group for public consumption + (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, + and backed up by W3C systems + such that if the underlying service is discontinued, + W3C can continue to serve such content without breaking incoming links + or other key functionality. +
  • All reports, publications, or other deliverables + produced by the group for public consumption should follow best practices for internationalization + and for accessibility to people with disabilities. + Network access to W3C-controlled domains may be assumed. +
  • + Official meeting minutes and other records of decisions made must be archived by W3C for future reference; + and other persistent text-based discussions + sponsored by the group, + pertaining to their work + and intended to be referenceable by all group members should be. + This includes discussions conducted over email lists + or in issue-tracking services + or any equivalent fora. + Materials referenced from discussions + and necessary to understand them + should be available at a stable URL, + at a level of confidentiality no stricter than the discussion minutes. +

    Note: The lack, or loss, of such archives does not by itself + invalidate an otherwise-valid decision.

    +
  • + Any tooling used by the group + for producing its documentation and deliverables + or for official group discussions should be usable + (without additional cost) + by all who wish to participate, + including people with disabilities, + to allow their effective participation. +

    Note: If a new participant joins who cannot use the tool, + this can require the Working Group to change its tooling + or operate some workaround.

    +
  • All tools and archives used by the group + for its discussions and recordkeeping should be documented + such that new participants and observers + can easily find the group’s tools and records. +
+

The Team is responsible for ensuring adherence to these rules + and for bringing any group not in compliance into compliance.

+

3.1.4. Resignation from a Group

+

A W3C Member or Invited Expert may resign from a group. + On written notification from an Advisory Committee representative + or Invited Expert + to the Team, + the Member and their representatives + or the Invited Expert + will be deemed to have resigned from the relevant group. + The Team must record the notification. + See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

+

3.2. The Advisory Committee (AC)

+

3.2.1. Role of the Advisory Committee

+

The Advisory Committee represents + the Members of W3C at large. + It is responsible for:

+ +

Advisory Committee representatives may initiate + an Advisory Committee Appeal of a W3C decision or Team's decision.

+

See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

+

3.2.2. Participation in the Advisory Committee

+

The Advisory Committee is composed of one representative from each Member organization + (refer to the Member-only list + of current Advisory Committee representatives. [CURRENT-AC])

+

When an organization joins W3C + (see “How to Join W3C” [JOIN]), + it must name its Advisory Committee representative as part of the Membership Agreement. + The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, + provides information about Advisory Committee Meetings, + explains how to name a new Advisory Committee representative, + and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.

+

The AC representative may delegate any of their rights and responsibilities + to an alternate (except the ability to designate an alternate).

+

3.2.3. Advisory Committee Mailing Lists

+

The Team must provide two mailing lists for use by the Advisory Committee:

+
    +
  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. + This list is read-only for Advisory Committee representatives. +
  2. One for discussion among Advisory Committee representatives. + Though this list is primarily for Advisory Committee representatives, + the Team must monitor discussion + and should participate in discussion when appropriate. + Ongoing detailed discussions should be moved to other appropriate lists + (new or existing, such as a mailing list created for a Workshop). +
+

An Advisory Committee representative may request + that additional individuals from their organization be subscribed to these lists. + Failure to contain distribution internally may result in suspension of additional email addresses, + at the discretion of the Team.

+

3.2.4. Advisory Committee Meetings

+

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. + The Team appoints the Chair of these meetings (generally the CEO). + At each Advisory Committee meeting, + the Team should provide an update to the Advisory Committee about:

+
+
Resources +
+
    +
  • The number of W3C Members at each level. +
  • An overview of the financial status of W3C. +
+
Allocations +
+
    +
  • The allocation of the annual budget, including size of the Team and their approximate deployment. +
  • A list of all activities (including but not limited to Working and Interest Groups) + and brief status statement about each, + in particular those started or terminated since the previous Advisory Committee meeting. +
  • The allocation of resources to pursuing liaisons with other organizations. +
+
+

Each Member organization should send one representative to each Advisory Committee Meeting. + In exceptional circumstances + (e.g., during a period of transition between representatives from an organization), + the meeting Chair may allow a Member organization to send two representatives to a meeting.

+

The Team must announce the date and location of each Advisory Committee meeting + no later than at the end of the previous meeting; one year’s notice is preferred. + The Team must announce the region of each Advisory Committee meeting + at least one year in advance.

+

More information about Advisory Committee meetings [AC-MEETING] is available at the Member website.

+

3.3. Elected Groups: The AB and the TAG

+

The W3C Process defines two types of elected groups: + the Advisory Board (AB) and + the Technical Architecture Group (TAG), + both elected by the Advisory Committee.

+

3.3.1. Advisory Board (AB)

+
3.3.1.1. Role of the Advisory Board
+

The Advisory Board provides ongoing guidance to the Team + on issues of strategy, + management, + legal matters, + process, + and conflict resolution. + The Advisory Board also serves the Members + by tracking issues raised between Advisory Committee meetings, + soliciting Member comments on such issues, + and proposing actions to resolve these issues. + The Advisory Board manages the evolution of the Process Document. + As part of a W3C Council, + members of the Advisory Board hear and adjudicate on Submission Appeals and Formal Objections.

+

The Advisory Board is distinct from the Board of Directors and has no decision-making authority within W3C; + its role is strictly advisory.

+

Note: While the AB as such does not have decision-making authority, + its members do when sitting as part of a W3C Council.

+

Details about the Advisory Board + (e.g., the list of Advisory Board participants, + mailing list information, and summaries of Advisory Board meetings) + are available at the Advisory Board home page [AB-HP].

+
3.3.1.2. Composition of the Advisory Board
+

The Advisory Board consists of nine to eleven elected participants and one Chair + (who may be one of the elected participants). + With the input of the AB, + the Team appoints the Chair, + who should choose a co-chair among the elected participants. + The Chair(s) are subject to ratification by secret ballot + by two thirds of the AB upon appointment. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The team also appoints a Team Contact, + as described in § 3.4.1 Requirements for All Chartered Groups. + The CEO and Team Contact have a standing invitation + to all regular Advisory Board sessions.

+

The nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

+

The terms of elected Advisory Board participants are for two years. + Terms are staggered so that each year, + either five or six terms expire. + If an individual is elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular Advisory Board terms begin on 1 July and end on 30 June.

+

+
3.3.1.3. Communications of the Advisory Board
+

The Team must make available a mailing list, + confidential to the Advisory Board and Team, + for the Advisory Board to use for its communication.

+

The Advisory Board should send a summary of each of its meetings + to the Advisory Committee and other group Chairs. + The Advisory Board should also report on its activities + at each Advisory Committee meeting.

+
3.3.1.4. Liaisons between the Advisory Board and the Board of Directors
+

To ensure good communication between the AB and the Board of Directors and facilitate operational and management consistency, + the AB may appoint up to two of its participants as liaisons to the Board. + Such appointees are expected to attend and participate in Board meetings + and access Board materials + as Non-voting Observers. [BYLAWS] They do not form part of the Board's decision-making body, + and may be excluded from such participation + in accordance with applicable Board procedures.

+

The Advisory Board should reevaluate + who is assigned to this role + at least at the beginning of each term, + and may swap its appointees more frequently + as they deem appropriate.

+

3.3.2. Technical Architecture Group (TAG)

+
3.3.2.1. Role of the Technical Architecture Group
+

The mission of the TAG is stewardship of the Web architecture. + There are three aspects to this mission:

+
    +
  1. to document and build consensus around principles of Web architecture + and to interpret and clarify these principles when necessary; +
  2. to resolve issues involving general Web architecture brought to the TAG; +
  3. to help coordinate cross-technology architecture developments inside and outside W3C. +
+

As part of a W3C Council, + the members of the TAG hear and adjudicate on Submission Appeals and Formal Objections.

+

The TAG's scope is limited to technical issues about Web architecture. + The TAG should not consider + administrative, + process, + or organizational policy issues of W3C, + which are generally addressed by + the W3C Advisory Committee, + Advisory Board, + and Team. + Please refer to the TAG charter [TAG-CHARTER] for more information about the background and scope of the TAG, + and the expected qualifications of TAG participants.

+

When the TAG votes to resolve an issue, + each TAG participant + (whether appointed, elected, or the Chair) + has one vote; + see also the section on voting in the TAG charter [TAG-CHARTER] and the general section on votes in this Process Document.

+

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) + are available at the TAG home page [TAG-HP].

+
3.3.2.2. Composition of the Technical Architecture Group
+

The TAG consists of:

+ +

Participants in the TAG choose by consensus their Chair or co-Chairs; + in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG. + The Chair or co-Chairs must be selected from the participants of the TAG. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The Team also appoints a Team Contact [TEAM-CONTACT] for the TAG, + as described in § 3.4.1 Requirements for All Chartered Groups.

+

The terms of TAG participants last for two years. + Terms are staggered so that four elected terms + and either one or two appointed terms expire each year. + If an individual is appointed or elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular TAG terms begin on 1 February and end on 31 January.

+
3.3.2.3. Communications of the Technical Architecture Group
+

The Team must make available two mailing lists for the TAG:

+
    +
  • a public discussion (not just input) list for issues of Web architecture. + The TAG will conduct its public business on this list. +
  • a Member-only list for discussions within the TAG + and for requests to the TAG that, + for whatever reason, cannot be made on the public list. +
+

The TAG may also request the creation of additional topic-specific, public mailing lists. + For some TAG discussions (e.g., a Submission Appeal), + the TAG may use a list that will be Member-only.

+

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. + The TAG should also report on its activities at each Advisory Committee meeting.

+

3.3.3. Participation in Elected Groups

+
3.3.3.1. Expectations for Elected Groups Participants
+

Advisory Board and TAG participants have a special role within W3C: + they are elected by the Membership and appointed by the Team with the expectation that they will use their best judgment + to find the best solutions for the Web, + not just for any particular network, + technology, + vendor, + or user. + Advisory Board and TAG participants are expected to participate regularly and fully. + Advisory Board and TAG participants should attend Advisory Committee meetings.

+

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, + to serve the needs of the W3C membership as a whole, + and the Web community. + Whether they are Member representatives or Invited Experts, + their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

+

An individual participates on the Advisory Board or TAG + from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). + Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, + their participation does carry the responsibilities associated with Member representation, + Invited Expert status, + or Team representation + (as described in the section on the AB/TAG nomination and election process).

+

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, + and a participant’s seat must not be delegated to any other person.

+
3.3.3.2. Elected Groups Participation Constraints
+

Given the few seats available on the Advisory Board and the TAG, + and in order to ensure that the diversity of W3C Members is represented:

+ +
3.3.3.3. Advisory Board and Technical Architecture Group Elections
+

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, + using a Single Transferable Vote system. + An election begins when the Team sends a Call for Nominations to the Advisory Committee. + Any Call for Nominations specifies the minimum and maximum number of available seats, + the deadline for nominations, + details about the specific vote tabulation system selected by the Team for the election, + and operational information such as how to nominate a candidate. + The Team may modify the tabulation system after the Call for Nominations + but must stabilize it no later than the Call for Votes. + The Team announces appointments + after the results of the election are known, + and before the start of the term, + as described in § 3.3.3.4 Technical Architecture Group Appointments.

+

In the case of regularly scheduled elections of the TAG, + the minimum and maximum number of available seats are the same: + the 4 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

+

In the case of regularly scheduled elections of the AB, + the minimum and maximum number of available seats differ: + The maximum number is the 5 or 6 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; + the minimum number is such that when added to the occupied seats from the prior year, + the minimum size of the AB (9) is reached.

+

Each Member (or group of related Members) may nominate one individual. + A nomination must be made with the consent of the nominee. + In order for an individual to be nominated as a Member representative, + the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination + the (same) information required for a Member representative in a Working Group. + In order for an individual to be nominated as an Invited Expert, + the individual must provide + the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. + In order for an individual to be nominated as a Team representative, + the nominating Advisory Committee representative must first secure approval from Team management. + A nominee is not required to be an employee of a Member organization, + and may be a W3C Fellow. + The nomination form must ask for the nominee’s primary affiliation, + and this will be reported on the ballot. + For most nominees, + the primary affiliation is their employer and will match their affiliation in the W3C database. + For contractors and invited experts, + this will normally be their contracting company + or their invited expert status; + in some cases + (e.g. where a consultant is consulting for only one organization) + this may be the organization for whom the nominee is consulting. + A change of affiliation is defined + such that this field would carry a different answer + if the nominee were to be re-nominated + (therefore, + terminating employment, + or accepting new employment, + are changes of affiliation). + (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) + Each nomination should include + a few informative paragraphs about the nominee.

+

If, after the deadline for nominations, the number of nominees is:

+
    +
  • Greater than or equal to the minimum number of available seats + and less than or equal to the maximum number of available seats, + those nominees are thereby elected. + This situation constitutes a tie for the purpose of assigning incomplete terms. + Furthermore, if the number is less than the maximum number of available seats, + the longest terms are filled first. +
  • Less than the minimum number of available seats, + Calls for Nominations are issued until a sufficient number of people have been nominated. + Those already nominated do not need to be renominated after a renewed call. +
  • Greater than the maximum number of available seats, + the Team issues a Call for Votes + that includes the names of all candidates, + the (maximum) number of available seats, + the deadline for votes, + details about the vote tabulation system selected by the Team for the election, + and operational information. +
+

When there is a vote, + each Member + (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. + Once the deadline for votes has passed, + the Team announces the results to the Advisory Committee. + In case of a tie the verifiable random selection procedure described below + will be used to fill the available seats.

+

The shortest incomplete term is assigned to the elected candidate ranked lowest by the tabulation of votes, + the next shortest term to the next-lowest ranked elected candidate, + and so on. + In the case of a tie among those eligible for a incomplete term, + the verifiable random selection procedure described below + will be used to assign the incomplete term.

+

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

+
3.3.3.4. Technical Architecture Group Appointments
+

The Team is responsible for appointing + 3 of the participants to the Technical Architecture Group. + This mechanism complements the election process. + The Team should use its appointments to support + a diverse and well-balanced TAG, + including diversity of technical background, knowledge, and skill sets.

+

The Team should actively seek + candidates for appointment to the TAG, + and must make available to + the W3C community at large + a means to propose candidates for consideration, + explicitly soliciting input from at least + current and incoming TAG members, the Advisory Committee, and Working Group Chairs.

+

The constraints for appointment to the TAG are + the same as for elected participants + (see § 3.3.3.2 Elected Groups Participation Constraints and § 3.3.3.3 Advisory Board and Technical Architecture Group Elections), + with the additional constraint that + a person must not be appointed + for more than two consecutive terms. + (Partial terms used to fill a vacated seat do not count towards this limit.)

+

Note: Individuals who have reached the limit of two consecutive appointed terms may freely run for election + if they wish to continue serving on the TAG.

+

The Team's choice of appointee(s) + is subject to ratification by secret ballot + by both the AB and the TAG, + each requiring a two-thirds approval. + In the case of regularly scheduled elections, + the TAG participants in this ratification are + its members for the upcoming term.

+

For regularly scheduled elections, + selection begins once the results of the elections are known, + and the Team should announce the ratified appointment(s) + no later than the start of the regularly scheduled term. + When an appointed seat is vacated outside of a regularly scheduled election, + the Team should seek to appoint a replacement + unless a regular Call for Nominations is scheduled within 2 months, + and it must announce the ratified appointment + no later than the Call for Nominations of the next scheduled election.

+
3.3.3.5. Verifiable Random Selection Procedure
+

When it is necessary to use a verifiable random selection process + (e.g., in an AB or TAG election, + to “draw straws” in case of a tie + or to fill a incomplete term), + W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. + The procedure orders an input list of names + (listed in alphabetical order by family name unless otherwise specified) + into a “result order”.

+

W3C applies this procedure as follows:

+

+
    +
  1. When N people have tied for M (less than N) seats. + In this case, only the names of the N individuals who tied + are provided as input to the procedure. + The M seats are assigned in result order. +
  2. After all elected individuals have been identified, + when N people are eligible for M (less than N) incomplete terms. + In this case, only the names of those N individuals are provided as input to the procedure. + The incomplete terms are assigned in result order. +
+
3.3.3.6. Elected Groups Vacated Seats
+

An Advisory Board or TAG participant’s seat is vacated when:

+ +

If a participant changes affiliation, + but the participation constraints are met, + that participant’s seat becomes vacant at the next regularly scheduled election for that group.

+

Vacated seats are filled according to this schedule:

+
    +
  • When an appointed TAG seat is vacated, + the Team appoints a replacement. +
  • + When an elected seat on either the AB or TAG is vacated, + the seat is filled at the next regularly scheduled election for the group + unless the group Chair requests that W3C hold an election before then + (for instance, due to the group’s workload). +
      +
    • The group Chair should not request such an election + if the next regularly scheduled election is fewer than three months away. +
    • The group Chair may request an election, + and the election may begin, as soon as a current member gives notice of a resignation, + including a resignation effective as of a given date in the future. +
    +

    When such an election is held, + the minimum number of available seats is such that + when added to the number of continuing participants, + the minimum total number of elected seats is met + (8 for the TAG, 9 for the AB); + and the maximum number corresponds to all unoccupied seats. + Except for the number of available seats and the length of the terms, + the usual rules for Advisory Board and Technical Architecture Group Elections apply.

    +
+

3.4. Chartered Groups: Working Groups and Interest Groups

+

This document defines two types of chartered groups:

+
+
Working Groups. +
+ Working Groups typically produce deliverables + (e.g., Recommendation Track technical reports, + software, + test suites, + and reviews of the deliverables of other groups) + as defined in their charter. +

Working Groups have additional participation requirements + described in the W3C Patent Policy [PATENT-POLICY], + see particularly the “Licensing Obligations of Working Group Participants” + and the patent claim exclusion process + in “Exclusion From W3C RF Licensing Requirements”.

+
Interest Groups. +
+ The primary goal of an Interest Group + is to bring together people who wish to evaluate potential Web technologies and policies. + An Interest Group is a forum for the exchange of ideas. +

Interest Groups do not publish Recommendation Track technical reports; + but can publish technical reports on the Note Track.

+
+

3.4.1. Requirements for All Chartered Groups

+

Each group must have a charter. + Requirements for the charter depend on the group type. + All group charters must be public + (even if other proceedings of the group are Member-only).

+

Each group must have a Chair (or co-Chairs) + to coordinate the group’s tasks. + The Team appoints (and re-appoints) Chairs for all groups. + The Chair is a Member representative, + a Team representative, + or an Invited Expert, + (invited by the Team). + The requirements of this document that apply to those types of participants apply to Chairs as well.

+

Note: The role of the Chair [CHAIR] is described + in the Art of Consensus [GUIDE].

+

Each group must have a Team Contact, + who acts as the interface between the Chair, + group participants, + and the rest of the Team.

+

Note: The role of the Team Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE].

+

The Chair and the Team Contact of a group should not be the same individual.

+

Each group must have an archived mailing list + for formal group communication + (e.g., for meeting announcements and minutes, + documentation of decisions, + and Formal Objections to decisions). + It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists. + Refer to the list of group mailing lists [GROUP-MAIL].

+

A Chair may form task forces + (composed of group participants) + to carry out assignments for the group. + The scope of these assignments must not exceed the scope of the group’s charter. + A group should document the process it uses + to create task forces + (e.g., each task force might have an informal "charter"). + Task forces do not publish technical reports; + the Working Group may choose to publish their results as part of a technical report.

+

3.4.2. Participation in Chartered Groups

+

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, + and Team representatives (including the Team Contact).

+

There are four types of individual participants in an Interest Group: + the same three types as for Working Groups plus, + for an Interest Group where the only participation requirement is mailing list subscription, public participants.

+

Except where noted in this document or in a group charter, + all participants share the same rights and responsibilities in a group; + see also the individual participation criteria.

+

A participant may represent more than one organization + in a Working Group or Interest Group. + Those organizations must all be members of the group.

+

An individual may become + a Working or Interest Group participant + at any time during the group’s existence. + See also relevant requirements in + “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY].

+

On an exceptional basis, + a Working or Interest Group participant may designate + a substitute to attend a meeting and should inform the Chair. + The substitute may act on behalf of the participant, + including for votes. + For the substitute to vote, + the participant must inform the Chair in writing in advance. + As a courtesy to the group, + if the substitute is not well-versed in the group’s discussions, + the regular participant should authorize another participant to act as proxy for votes.

+

To allow rapid progress, + Working Groups are intended to be small + (typically fewer than 15 people) + and composed of experts in the area defined by the charter. + In principle, + Interest Groups have no limit on the number of participants. + When a Working Group grows too large to be effective, + W3C may split it into an Interest Group + (a discussion forum) + and a much smaller Working Group + (a core group of highly dedicated participants).

+

3.4.3. Types of Participants in Chartered Groups

+
3.4.3.1. Member Representative in a Working Group
+

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Advisory Committee representative of the Member in question + has designated the individual as a Working Group participant, and +
  • the individual qualifies for Member representation. +
+

To designate an individual as a Member representative in a Working Group, + an Advisory Committee representative must provide the Chair and Team Contact with all of the following information, + in addition to any other information required by the Call for Participation and charter + (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

+
    +
  1. The name of the W3C Member the individual represents + and whether the individual is an employee of that Member organization; +
  2. A statement that the individual accepts the participation terms + set forth in the charter + (with an indication of charter date or version); +
  3. A statement that the Member will provide the necessary financial support for participation + (e.g., for travel, telephone calls, and conferences). +
+

A Member participates in a Working Group from the moment the first Member representative joins the group + until either of the following occurs:

+
    +
  • the group closes, or +
  • the Member resigns from the Working Group; + this is done through the Member’s Advisory Committee representative. +
+
3.4.3.2. Member Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

+ +

To designate an individual as a Member representative in an Interest Group, + the Advisory Committee representative must follow the instructions + in the Call for Participation and charter.

+

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

+
3.4.3.3. Invited Expert in a Working Group
+

The Chair may invite an individual with a particular expertise + to participate in a Working Group. + This individual may represent an organization in the group + (e.g., if acting as a liaison with another organization).

+

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Chair has designated the individual as a group participant, +
  • the Team Contact has agreed with the Chair’s choice, and +
  • the individual has provided the information required of an Invited Expert to the Chair and Team Contact. +
+

To designate an individual as an Invited Expert in a Working Group, + the Chair must inform the Team Contact + and provide rationale for the choice. + When the Chair and the Team Contact disagree about a designation, + the CEO determines + whether the individual will be invited to participate in the Working Group.

+

To participate in a Working Group as an Invited Expert, + an individual must:

+
    +
  • identify the organization, if any, the individual represents as a participant in this group, +
  • agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT], +
  • accept the participation terms set forth in the charter, + including the participation requirements of + the W3C Patent Policy [PATENT-POLICY], + especially in “Note on Licensing Commitments for Invited Experts” + and in “Disclosure”, + indicating a specific charter date or version, +
  • disclose whether the individual is an employee of a W3C Member; + see the conflict of interest policy, +
  • provide a statement of who will provide the necessary financial support + for the individual’s participation + (e.g., for travel, telephone calls, and conferences), and +
  • if the individual’s employer (including a self-employed individual) + or the organization the individual represents + is not a W3C Member, + indicate whether that organization intends to join W3C. + If the organization does not intend to join W3C, + indicate reasons the individual is aware of for this choice. +
+

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. + The Chair must not use Invited Expert status + to circumvent participation limits imposed by the charter.

+

An Invited Expert participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • the Chair or CEO withdraws the invitation to participate, or +
  • the individual resigns. +
+
3.4.3.4. Invited Expert in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

+
3.4.3.5. Team Representative in a Working Group
+

An individual is a Team representative in a Working Group when so designated by W3C management. + Team representatives both contribute to the technical work + and help ensure the group’s proper integration with the rest of W3C.

+

A Team representative participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • W3C management changes Team representation by sending email to the Chair, + copying the group mailing list. +
+

The Team participates in a Working Group + from the moment the creation of the group is announced + until the group closes.

+
3.4.3.6. Team Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Team representative in an Interest Group when so designated by W3C management.

+

4. Lifecycle of Chartered Groups

+

4.1. Initiating Charter Development

+

W3C creates charters for chartered groups based on interest from the Members and Team. + The Team must notify the Advisory Committee + when a charter for a new Working Group or Interest Group is in development. + This is intended to raise awareness, + even if no formal proposal is yet available. + Advisory Committee representatives may provide + feedback on the Advisory Committee discussion list or via other designated channels.

+

W3C may begin work + on a Working Group or Interest Group charter + at any time.

+

4.2. Content of a Charter

+

A Working Group or Interest Group charter must include all of the following information.

+
    +
  • The group’s mission + (e.g., develop a technology or process, review the work of other groups). +
  • The scope of the group’s work and criteria for success. +
  • The duration of the group (typically from six months to two years). +
  • The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software). +
  • + Expected milestone dates where available. +

    Note: A charter is not required to include schedules for review of other group’s deliverables.

    +
  • The process for the group to approve the release of deliverables + (including intermediate results). +
  • Any dependencies by groups within or outside of W3C on the deliverables of this group. + For any dependencies, the charter must specify + the mechanisms for communication about the deliverables. +
  • Any dependencies of this group on other groups within or outside of W3C. + Such dependencies include interactions with W3C Horizontal Groups [CHARTER]. +
  • The level of confidentiality of the group’s proceedings and deliverables. +
  • Meeting mechanisms and expected frequency. +
  • If known, + the date of the first face-to-face meeting. + The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal. +
  • Communication mechanisms to be employed within the group, + between the group and the rest of W3C, + and with the general public. +
  • Any voting procedures or requirements + other than those specified in § 5.2.3 Deciding by Vote. +
  • An estimate of the expected time commitment from participants. +
  • The expected time commitment and level of involvement by the Team + (e.g., to track developments, + write and edit technical reports, + develop code, + or organize pilot experiments). +
  • Intellectual property information. + What are the intellectual property (including patents and copyright) + considerations affecting the success of the Group? + In particular, is there any reason to believe + that it will be difficult to meet the Royalty-Free licensing goals + in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY]? +
+

See also the charter requirements in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

For every Recommendation Track deliverable + that continues work on technical report published under any other Charter (including a predecessor group of the same name), + for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

+
    +
  • The title, + stable URL, + and publication date of the Working Draft or other Recommendation-track document + that will serve as the basis for work on the deliverable + (labeled “Adopted Draft”); +
  • The title, + stable URL, + and publication date of the document + that was used as the basis for its most recent Exclusion Opportunity + as per + the W3C Patent Policy [PATENT-POLICY]. + (labeled “Exclusion Draft”); and +
  • The stable URL of the Working Group charter + under which the Exclusion Draft was published + (labeled the “Exclusion Draft Charter”). +
+

All of the above data must be identified + in the adopting Working Group’s charter using the labels indicated.

+

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. + The proposed charter must state + the dates on which the Exclusion Opportunity + that arose on publishing the Exclusion Draft began and ended. + As per “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY], + this potentially means that exclusions can only be made immediately on joining a Working Group.

+

An Interest Group charter may include provisions regarding participation, + including specifying + that the only requirement for participation (by anyone) in + the Interest Group is subscription to the Interest Group mailing list. + This type of Interest Group may have public participants.

+

A charter may include + provisions other than those required by this document. + The charter should highlight + whether additional provisions impose constraints + beyond those of the W3C Process Document + (e.g., limits on the number of individuals in a Working Group + who represent the same Member organization or group of related Members).

+

4.3. Advisory Committee Review of a Charter

+

The Team must solicit Advisory Committee review of every new or substantively modified Working Group or Interest Group charter, + except for either:

+
    +
  • +

    a charter extension

    +
  • +

    substantive changes to a charter that do not affect the way the group functions in any significant way.

    +
+

The review period must be at least 28 days. + The following are examples of substantive changes that would not require an Advisory Committee Review: + the addition of an in-scope deliverable, + a change of Team Contact, + or a change of Chair. + Such changes must nonetheless be announced + to the Advisory Committee and to participants in the Working or in the Interest Group, + and a rationale must be provided.

+

The Call for Review of a substantively modified charter must highlight important changes + (e.g., regarding deliverables or resource allocation) + and include rationale for the changes.

+

As part of the Advisory Committee review of any new or substantively modified Working Group charter, + any Advisory Committee representative may request an extended review period.

+

Such a request must be submitted with a Member’s comments + in response to the Call for Review. + Upon receipt of any such request, + the Team must ensure + that the Call for Participation for the Working Group + occurs at least 60 days + after the Call for Review of the charter.

+

4.4. Call for Participation in a Chartered Group

+

Deciding whether to adopt a proposed Working Group or Interest Group charter is a W3C Decision. + Charters may be amended based on review comments + per § 5.7.2 After the Review Period before the Call for Participation.

+

If the decision is to charter the group, + the Team must issue a Call for Participation to the Advisory Committee. + For a new group, this announcement officially creates the group. + The announcement must include a reference to the charter, + the name(s) of the group’s Chair(s), + and the name(s) of the Team Contact(s).

+

After a Call for Participation, + any Member representatives and Invited Experts must be designated (or re-designated). + When a group is re-chartered, + individuals participating in the Working Group or Interest Group before the new Call for Participation + may attend any meetings held within forty-five (45) days of the Call for Participation + even if they have not yet formally rejoined the group + (i.e., committed to the terms of the charter and patent policy).

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against the decision to create + or substantially modify + a Working Group or Interest Group charter.

+

4.5. Charter Extension

+

The Team may decide + to extend a Working Group or Interest Group charter + with no other substantive modifications. + The Team must announce + such extensions to the Advisory Committee. + The announcement must indicate the new duration. + The announcement must also include rationale for the extension, + a reference to the charter, + and the Group homepage + (which includes at least + the name(s) of the group’s Chair(s), + the name of the Team Contact, + and instructions for joining the group).

+

After a charter extension, + Advisory Committee representatives + and the Chair are not required to re-designate Member representatives and Invited Experts.

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.

+

4.6. Chartered Group Closure

+

A Working Group or Interest Group charter specifies a duration for the group.

+

The Team, the TAG, or the AB may propose to close a group + prior to the date specified in the charter in any of the following circumstances:

+
    +
  • +

    There are insufficient member resources to produce chartered deliverables +or to maintain the group, +according to priorities established within W3C.

    +
  • +

    A Patent Advisory Group concluded that the work should be terminated.

    +
  • +

    The TAG or AB determined that continuing operation of the chartered group or its work +would be detrimental to W3C or its mission.

    +
  • +

    The group produced all chartered deliverables ahead of schedule.

    +
+

Such a proposal to close a group must be accompanied by rationale, + and the proposal must be confirmed by an AC Review as a W3C Decision.

+

Closing a Working Group has implications + with respect to the W3C Patent Policy [PATENT-POLICY].

+

5. Decisions

+

W3C attempts to resolve issues through dialog. + Individuals who disagree strongly with a decision should register with the Chair any Formal Objections.

+

5.1. Types of Decisions

+

The Chair of a Working Group or Interest Group has the prerogative + to make certain decisions based on their own judgment. + Such decisions are called chair decisions.

+

In contrast, + decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group + or following a vote (see § 5.2.3 Deciding by Vote) + are called group decisions (also known as group “resolutions”).

+

Decisions made by members of the Team in connection with this Process, + based on their own individual or collective judgement, + are called Team Decisions.

+

In contrast, + a W3C decision is + determined by the Team on behalf of the W3C community + by assessing the consensus of the W3C Community after an Advisory Committee review.

+

5.2. Consensus Building

+

5.2.1. Consensus

+

Consensus is a core value of W3C. + To promote consensus, + the W3C process requires Chairs to ensure + that groups consider all legitimate views and objections, + and endeavor to resolve them, + whether these views and objections are expressed by the active participants of the group + or by others + (e.g., another W3C group, + a group in another organization, + or the general public). + Decisions may be made during meetings + (face-to-face or distributed) + as well as through persistent text-based discussions.

+

Note: The CEO has the role of + assessing consensus within the Advisory Committee.

+

The following terms are used in this document + to describe the level of support for a decision among a set of eligible individuals:

+
+
Consensus: +
A substantial number of individuals in the set + support the decision + and there is no sustained objection from anybody in the set. + Individuals in the set may abstain. + Abstention is either an explicit expression of no opinion + or silence by an individual in the set. +
Unanimity: +
The particular case of consensus where all individuals in the set support the decision + (i.e., no individual in the set abstains). +
Dissent: +
At least one individual in the set sustains an objection. +
+

Note: A Formal Objection always indicates a sustained objection, + but isn’t necessary to express it + (except in the context of formal AC Reviews). + Disagreement with a proposed decision, + however, does not always rise to the level of sustained objection, + as individuals could be willing to accept a decision + while expressing disagreement.

+

By default, the set of individuals eligible to participate in a decision is the set of group participants. + The Process Document does not require a quorum for decisions + (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). + A charter may include a quorum requirement for consensus decisions.

+

Where unanimity is not possible, + a group should strive to make consensus decisions + where there is significant support and few abstentions. + The Process Document does not require a particular percentage of eligible participants + to agree to a motion in order for a decision to be made. + To avoid decisions where there is widespread apathy, + (i.e., little support and many abstentions), + groups should set minimum thresholds of active support before a decision can be recorded. + The appropriate percentage may vary depending on the size of the group + and the nature of the decision. + A charter may include threshold requirements for consensus decisions. + For instance, a charter might require a supermajority of eligible participants + (i.e., some established percentage above 50%) + to support certain types of consensus decisions.

+
+ Note: Chairs have substantial flexibility + in how they obtain and assess consensus among their groups. + Unless otherwise constrained by charter, + they may use modes including but not limited to explicit calls for consensus, + polls of participants, + “lazy consensus” in which lack of objection after sufficient notice is taken as assent; + or they may also delegate and empower a document editor + to assess consensus on their behalf, + whether in general + or for specific pre-determined circumstances + (e.g. in non-controversial situations, for specific types of issues, etc.). +

If questions or disagreements arise, + the final determination of consensus remains with the chair.

+
+

5.2.2. Managing Dissent

+

In some cases, even after careful consideration of all points of view, + a group might find itself unable to reach consensus. + The Chair may record a decision where there is dissent so that the group can make progress + (for example, to produce a deliverable in a timely manner). + Dissenters cannot stop a group’s work + simply by saying that they cannot live with a decision. + When the Chair believes that the Group has duly considered + the legitimate concerns of dissenters as far as is possible and reasonable, + the group should move on.

+

Groups should favor proposals that create the weakest objections. + This is preferred over proposals that are supported by a large majority + but that cause strong objections from a few people. + As part of making a decision where there is dissent, + the Chair is expected to be aware of which participants work for the same + (or related) + Member organizations and weigh their input accordingly.

+

Note: Dissenters can escalate their sustained objection to a decision by registering a Formal Objection.

+

5.2.3. Deciding by Vote

+

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, + and that a vote is necessary to break a deadlock. + In this case the Chair must record + (e.g., in the minutes of the meeting or in an archived email message):

+
    +
  • an explanation of the issue being voted on; +
  • the decision to conduct a vote + (e.g., a simple majority vote) to resolve the issue; +
  • the outcome of the vote; +
  • any Formal Objections. +
+

In order to vote to resolve a substantive issue, + an individual must be a group participant. + Each organization represented in the group must have at most one vote, + even when the organization is represented by several participants in the group + (including Invited Experts). + For the purposes of voting:

+
    +
  • A Member or group of related Members is considered a single organization. +
  • The Team is considered an organization. +
+

Unless the charter states otherwise, Invited Experts may vote.

+

If a participant is unable to attend a vote, + that individual may authorize anyone at the meeting + to act as a proxy. + The absent participant must inform the Chair in writing + who is acting as proxy, with written instructions on the use of the proxy. + For a Working Group or Interest Group, + see the related requirements regarding an individual + who attends a meeting as a substitute for a participant.

+

A group may vote for other purposes than to resolve a substantive issue. + For instance, the Chair often conducts a “straw poll” vote + as a means of determining whether there is consensus about a potential decision.

+

A group may also vote to make a process decision. + For example, + it is appropriate to decide by simple majority + whether to hold a meeting in San Francisco or San Jose + (there’s not much difference geographically). + When simple majority votes are used to decide minor issues, + voters are not required to state the reasons for votes, + and the group is not required to record individual votes.

+

A group charter may include formal voting procedures + (e.g., quorum or threshold requirements) + for making decisions about substantive issues.

+

5.3. Formally Addressing an Issue

+

In the context of this document, + a group has formally addressed an issue when it has sent a public, substantive response + to the reviewer who raised the issue. + A substantive response is expected to include rationale for decisions + (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). + The adequacy of a response is measured + against what a W3C reviewer would generally consider to be technically sound. + If a group believes that a reviewer’s comments result from a misunderstanding, + the group should seek clarification before reaching a decision.

+

As a courtesy, + both Chairs and reviewers should set expectations + for the schedule of responses and acknowledgments. + The group should reply to a reviewer’s initial comments + in a timely manner. + The group should set a time limit + for acknowledgment by a reviewer of the group’s substantive response; + a reviewer cannot block a group’s progress. + It is common for a reviewer to require a week or more + to acknowledge and comment on a substantive response. + The group’s responsibility to respond to reviewers + does not end once a reasonable amount of time has elapsed. + However, reviewers should realize + that their comments will carry less weight + if not sent to the group in a timely manner.

+

Substantive responses should be recorded. + The group should maintain an accurate summary + of all substantive issues and responses to them + (e.g., in the form of an issues list with links to mailing list archives).

+

5.4. Reopening a Decision When Presented With New Information

+

The Chair may reopen a decision + when presented with new information, including:

+
    +
  • additional technical information, +
  • comments by email from participants who were unable to attend a scheduled meeting, +
  • comments by email from meeting attendees + who chose not to speak out during a meeting + (e.g., so they could confer later with colleagues or for cultural reasons). +
+

The Chair should record + that a decision has been reopened, + and must do so upon request from a group participant.

+

5.5. Registering Formal Objections

+

Any individual + (regardless of whether they are associated with a Member) may appeal any decision made in connection with this Process + (except those having a different appeal process) + by registering a Formal Objection with the Team. + Group participants should inform + their Team Contact as well as the group’s Chair(s). + The Team Contact must inform the CEO when a group participant has also raised concerns about due process.

+

Note: In this document, the term Formal Objection is used to emphasize this process implication: + Formal Objections receive formal consideration and a formal response. + The word “objection” used alone has its ordinary English connotations. + See § 5.2 Consensus Building.

+

A Formal Objection must include a summary of + the issue (whether technical or procedural), + the decision being appealed, + and the rationale for the objection. + It should cite technical arguments + and propose changes that would remove the Formal Objection; + these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments + or rationale are unlikely to receive serious consideration. + Counter-arguments, + rationales, + and decisions should also be recorded.

+

A record of each Formal Objection against a decision regarding a publicly-available document must be made publicly available; + likewise, a record of each Formal Objection against a Member-visible decision must be made available to Members. + A Call for Review to the Advisory Committee must identify any Formal Objections related to that review.

+

Note: Formal Objections against matter in a technical report are required to be addressed before requesting advancement of the technical report.

+

A Formal Objection filed during an Advisory Committee Review is considered registered at the close of the review period.

+

5.6. Addressing Formal Objections

+

5.6.1. Investigation and Mediation by the Team

+

The Team considers the Formal objection, + researches the question, + interviews parties, + and so on, + to make sure the problem and the various viewpoints are well understood, + and to the extent possible, + to arrive at a recommended disposition. + If the Team can resolve the issue + to the satisfaction of the individual that filed the Formal Objection, + the individual withdraws the objection and the disposition process terminates.

+

Otherwise, + upon concluding that consensus cannot be found, + and no later than 90 days after the Formal Objection being registered, + the Team must initiate formation of a W3C Council, + which should be convened within 45 days of being initiated. + Concurrently, it must prepare a report for the Council documenting its findings and attempts to find consensus.

+

5.6.2. W3C Council

+

A W3C Council is the body convened to resolve Formal Objections by combining the capabilities and perspectives of the AB, the TAG, and the Team, + and is tasked with doing so in the best interests of the Web and W3C.

+
5.6.2.1. Council Composition
+

Each W3C Council is composed of the following members (excepting any renounced or dismissed):

+ +

Participation in a W3C Council must not require attendance of face-to-face meetings.

+

A distinct instance of the W3C Council is convened for each decision being appealed or objected to. + Membership of each Council instance is fixed at formation, + and is not changed by any AB or TAG elections + occurring before that Council has reached a conclusion. + However, if participation in a Council falls so low as to hinder effective and balanced deliberations, + the W3C Council Chair should dissolve the Council and call for a new one to be convened.

+

A Team member is assigned + to act as the Council Team Contact, + to support this Council + and to facilitate adherence to this Process.

+
5.6.2.2. Extraordinary Delegation
+

In extraordinary cases, + if they feel a Council would not be the appropriate deciding body, + a member of the Team (particularly the Legal Counsel) or + any potential Council member + may suggest that the decision for that specific Formal Objection be delegated + to the W3C Board of Directors, + to an officer of its corporation (such as the Legal Counsel), + or to one or more specific individuals from the Team. + The potential Council members then may confidentially discuss + and must vote + whether to delegate the decision for that specific Formal Objection. + A decision to delegate must be supported by a two-thirds supermajority vote + (i.e., at least twice as many votes in favor as against). + Delegation in such cases cannot be later revoked.

+

The Team must inform the Advisory Committee when a Formal Objection has been delegated, + and to whom it has been delegated.

+
5.6.2.3. Council Participation, Dismissal, and Renunciation
+

A potential Council member may be dismissed from the Council. + In order to apply consistent criteria, + the potential Council members decide collectively + which reasons against service + rise to a sufficient level for a potential member to be dismissed. + No-one is automatically dismissed, + and individual recusal is not used in the Council. Dismissal applies to an individual person in the context of a specific Council, + and should be used rarely in order to preserve the greatest diversity on the Council.

+

Note: A W3C Council is a deliberative body whose purpose is + to find the best way forward for the Web and for W3C. + It is not a judicial body tasked with determining right or wrong.

+

The Team must draft a list of potential Council members, + with annotations of possible reasons for dismissal against each one. + The W3C community, + including members and team, and potential council members, must be given an opportunity to contribute possible reasons to this list. + Affected members must be given + an opportunity to respond to such comments about themselves. + The Team may report comments verbatim + or may paraphrase them while preserving their intent; + they may also elide inappropriate comments, + such as any that violate applicable laws or the [CEPC].

+

Before a Council forms, + the Team presents the entire list of potential members + and collected reasons and responses + to the potential Council members, + who then consider for each potential member + whether that individual’s participation + would compromise the integrity of the Council decision, + and vote whether to dismiss that potential member. + No one is allowed to vote on their own dismissal; + each dismissal is decided by simple majority of those not abstaining.

+

Note: Since dismissal is individual, + when the decision being objected to was made by the TAG or AB acting as a body, + the entire TAG or AB is not expected or required to be dismissed.

+

An individual may also renounce their seat on a Council, for strong reason, + such as being forbidden by their employer to serve. The individual chooses the extent to which they explain + their renunciation. + Renunciation is disqualification from participation, + not abstention, + and should not be used + to excuse an absence of participation.

+

Any person who has been dismissed or who renounces their seat + does not receive Council materials, + take part in its deliberations, + help in the determination of consensus, + or vote. + The W3C Council may still solicit and hear their testimony, + as they can of anyone else in the W3C community.

+
5.6.2.4. Unanimous Short Circuit
+

The full Council process may be short-circuited if + the Team recommends a resolution + and every potential member of a Council who is not renouncing their seat + votes affirmatively (no abstentions) to adopt this resolution.

+

This step may be run concurrently with § 5.6.2.3 Council Participation, Dismissal, and Renunciation and prior to choosing a Chair.

+

Note: This is intended for exceptional cases + that don’t seem to warrant a full Council response + because they are, for instance, too trivial, duplicative, etc.

+
5.6.2.5. Council Chairing
+

The Chair of each W3C Council is chosen by its members, + by consensus if possible, + falling back to a vote if that fails. + The chair must be a member of that W3C Council. + Chair selection happens during formation of each Council, + and must be re-run + if requested by the Council Team Contact or by the Chair during the Council’s operation.

+
5.6.2.6. Council Deliberations
+

Upon appointment of the W3C Council Chair and delivery of the Team’s report, + the W3C Council is considered to be convened + and can start deliberations.

+

Having reviewed the information gathered by the Team, + the Council may conduct additional research or analysis, + or request additional information or interviews from anyone, + including the Team.

+

The Council may further attempt to broker consensus, + which, if successful, disposes the formal objection.

+

Otherwise, + after sufficient deliberation, + the W3C Council decides whether to uphold or overrule the objection. + The W3C Council may overrule the Formal Objection even if it agrees with some of the supportive arguments.

+

When upholding an objection, + it should recommend a way forward. + If the overturned decision has already had consequences + (e.g., if the objection concerns material already in a published document) + the Council should suggest how these consequences might be mitigated. + The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion; + and the Formal Objection is not considered fully addressed until then.

+

Note: This does not create new powers for the Team, + such as the ability to “unpublish” documents. + The Team's role is to ensure the responsible parties enact adequate mitigations, + by whatever means they already have at their disposal.

+

A Council may form sub-groups for deliberation, + who may return with a recommendation, + but the full Council issues the final decision. + The decision of the W3C Council should be unanimous, + and may be issued under consensus. + However, if despite careful deliberation + a W3C Council is unable to reach consensus, + the W3C Council Chair may instead resort to voting. + In that case, + the decision is made by simple majority, + with the W3C Council Chair breaking any tie. + In case of a vote, + if two members of a Council who share the same affiliation cast an identical ballot, + then their ballots count as a one vote, + not two.

+

In the case of non-unanimous decisions, + members of a W3C Council who disagree with the decision may write a Minority Opinion explaining the reason for their disagreement.

+

The deliberations of a W3C Council are confidential to that W3C Council and its Council Team Contact.

+

If a W3C Council is unable to come to a conclusion within 45 days of being convened, + the W3C Council Chair must inform the AC of this delay + and of the status of the discussions. + The W3C Council Chair may additionally make this report public.

+
5.6.2.7. Council Decision Report
+

A Council terminates by issuing a Council Report, + which:

+
    +
  • +

    must state whether the Council upholds or overrules the objection(s).

    +
  • +

    must provide a rationale supporting the decision, +which should address each argument raised in the Formal Objection(s).

    +
  • +

    must include any recommendation decided by the Council.

    +
  • +

    if the Formal Objection has been upheld, should include any suggested mitigations.

    +
  • +

    must include the Minority Opinion(s), if any.

    +
  • +

    must report the names of those who were dismissed or renounced their seat as well as those who were qualified to serve.

    +
  • +

    must report the names of the individuals who participated in the final decision.

    +
  • +

    may report vote totals, if any vote was held.

    +
  • +

    must not attribute any position to any individual on the Council.

    +
+

The Team must maintain a public page on the W3C website indexing all completed Council Reports. + If a Council decision is later overturned by an AC Appeal, + this must also be mentioned. Council Reports must be no more confidential + than the decision or document being objected to.

+

The Council may also issue a Supplemental Confidential Council Report with a more restricted level of confidentiality than its main report + when it believes that additional commentary on confidential aspects of the case + would be informative. + However, the main Council Report should be self-sufficient + and understandable without reference to Supplemental Confidential Council Reports.

+
5.6.2.8. Appealing Council Decisions
+

Advisory Committee representatives may initiate an Advisory Committee Appeal of a Council decision issued in a Council Report.

+

5.7. Advisory Committee Reviews

+

Advisory Committee review is the process + by which the Advisory Committee formally confers its approval + on charters, technical reports, + and other matters.

+

5.7.1. Start of a Review Period

+

Each Advisory Committee review period + begins with a Call for Review from the Team to the Advisory Committee. + The Call for Review describes the proposal, + raises attention to deadlines, + estimates when the decision will be available, + and includes other practical information. + Each Member organization may send one review, + which must be returned by its Advisory Committee representative.

+

For clarity, + in the context of an AC Review, dissent must be expressed as a Formal Objection.

+

The Team must provide two channels for Advisory Committee review comments:

+
    +
  1. an archived Team-only channel; +
  2. an archived Member-only channel. +
+

The Call for Review must specify + which channel is the default for review comments on that Call.

+

Reviewers may send information + to either or both channels. + A reviewer may also share their own reviews + with other Members on the Advisory Committee discussion list, + and may also make it available to the public.

+

A Member organization may modify its review + during a review period + (e.g., in light of comments from other Members).

+

5.7.2. After the Review Period

+

After the review period, + the Team determines the appropriate W3C Decision, + which they must announce to the Advisory Committee. + The announcement must indicate + the level of support for the proposal + (consensus or dissent), + and specifically + whether there were any Formal Objections, + with attention to changing the confidentiality level of the Formal Objections.

+

If there were Formal Objections, at least some of which were upheld, + or if there is not consensus because of insufficient support, W3C Decision must be one of:

+
    +
  • The proposal is returned for additional work, + with a request to the initiator to improve the proposal. +
  • The proposal is rejected. +
+

If the proposal has consensus, + or if any Formal Objections are retracted or overruled + and the proposal otherwise has sufficient support to achieve consensus, + this W3C Decision must be one of:

+
    +
  • The proposal is adopted, + possibly with additional changes integrated + in order to address the comments of the AC (see below). +
  • The proposal is returned for additional work, + with a request to the initiator to make desirable changes identified during the review + and to resubmit. +
+

If the proposal is adopted with changes other than class 1 (markup) changes, + then those changes must be announced to the AC and to the Group that owns the document (if any).

+

Additionally, when adopting a proposal with substantive changes integrated, + the announcement must include rationale + for the substantive changes, + and those changes must have the consensus of the subset of the AC that voted on the proposal + (including anyone who explicitly abstained). + For publications which have conditions in addition to AC approval + for introducing substantive changes (such as Group consensus or implementation experience), + those other conditions must also be re-fulfilled.

+
For example, to make substantive changes to a Proposed Recommendations, + the technical report could be returned to Candidate Recommendation. + Alternatively, the desired changes can be introduced as non-substantive amendments + using the process for revising a Recommendation. + However, they cannot be directly integrated between PR and REC, + because that would fail to trigger a patent exclusion opportunity.
+

This document does not specify + time intervals between the end of an Advisory Committee review period + and the W3C decision. + This is to ensure that the Members and Team have sufficient time to consider comments + gathered during the review. + The Advisory Committee should not expect an announcement + sooner than two weeks after the end of a review period. + If, after three weeks, the outcome has not been announced, + the Team should provide the Advisory Committee with an update.

+

5.8. Advisory Committee Votes

+

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, + and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. + Whenever the Advisory Committee votes, + each Member or group of related Members has one vote.

+

5.9. Appeal by Advisory Committee Representatives

+

Advisory Committee representatives may appeal certain decisions, + though appeals are only expected to occur in extraordinary circumstances.

+

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate + an Advisory Committee Appeal. + These W3C decisions include those related to group creation and modification, + and transitions to new maturity stages for Recommendation Track documents + and the Process document.

+

Advisory Committee representatives may also initiate an appeal + for decisions of a W3C Council, and + for certain decisions that do not involve an Advisory Committee review. + These cases are identified in the sections + which describe the requirements for the decision + and include + additional (non-reviewed) maturity stages of Recommendation Track documents, + group charter extensions and closures, + and Memoranda of Understanding.

+

In all cases, + an appeal must be initiated within three weeks of the decision.

+

An Advisory Committee representative initiates an appeal by sending a request to the Team, + and should also share this request with the Advisory Committee. + The request should say “I appeal this Decision” + and identify the decision, + and may also include their rationale for appealing the decision.

+

Note: See Appealing a W3C Decision for a recommendation + on how to communicate an appeal request to the Team and the AC.

+

Within one week the Team must announce the appeal process + to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. + The archive of these statements must be member-only. + If, within one week of the Team’s announcement, + 5% or more of the Advisory Committee support the appeal request, + the Team must organize an appeal vote + asking the Advisory Committee “Do you approve of the Decision?” + together with links to the decision and the appeal support.

+

The ballot must allow for three possible responses: + “Approve”, + “Reject”, + and “Abstain”, + together with Comments.

+

If the number of votes to reject + exceeds the number of votes to approve, + the decision is overturned. + In that case, there are the following possible next steps:

+
    +
  1. The proposal is rejected. +
  2. The proposal is returned for additional work, + after which the applicable decision process is re-initiated. +
+

6. W3C Technical Reports

+

The W3C technical report development process is the set of steps and requirements + followed by W3C Working Groups to standardize Web technology. + The W3C technical report development process is designed to:

+
    +
  • support multiple specification development methodologies +
  • maximize consensus about the content of stable technical reports +
  • ensure high technical and editorial quality +
  • promote consistency among specifications +
  • facilitate royalty-free, interoperable implementations of Web Standards, and +
  • earn endorsement by W3C and the broader community. +
+

See also “licensing goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

6.1. Types of Technical Reports

+

This chapter describes the formal requirements + for publishing and maintaining a W3C Recommendation, Note, + or Registry Report.

+
+
Recommendations +
Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines + as standards for the Web. + The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, + and consensus-building, + and is subject to the W3C Patent Policy [PATENT-POLICY], + under which participants commit to Royalty-Free IPR licenses for implementations. + See § 6.3 The W3C Recommendation Track for details. +
Notes +
Groups can also publish documents as W3C Notes and W3C Statements, + typically either to document information + other than technical specifications, + such as use cases motivating a specification + and best practices for its use. + See § 6.4 The Note Track (Notes and Statements) for details. +
Registries +
Working Groups can also publish registries in order to document collections of values or other data. + These are typically published in a separate registry report, + although they can also be directly embedded in Recommendation Track documents + as a registry section. Defining a registry requires wide review and consensus, + but once set up, changes to registry entries are lightweight + and can even be done without a Working Group. + See § 6.5 The Registry Track for details. +
+

Individual Working Groups and Interest Groups should adopt additional processes + for developing publications, + so long as they do not conflict with the requirements in this chapter.

+

6.2. General Requirements for Technical Reports

+

6.2.1. Publication of Technical Reports

+

Publishing as used in this document + refers to producing a version which is listed as a W3C Technical Report on its Technical Reports index at https://www.w3.org/TR [TR]. + Every document published as part of the technical report development process must be a public document. + W3C strives to make archival documents indefinitely available + at their original address in their original form.

+

Every document published as part of the technical report development process must clearly indicate its maturity stage, + and must include information about the status of the document. + This status information:

+
    +
  • must be unique each time a specification is published, +
  • must state which Working Group developed the specification, +
  • must state how to send comments or file bugs, + and where these are recorded, +
  • must include expectations about next steps, +
  • should explain how the technology relates to existing international standards + and related work inside or outside W3C, + and +
  • should explain + or link to + an explanation of significant changes from the previous version. +
+

Every Technical Report published + as part of the Technical Report development process + is edited by one or more editors + appointed by a Group Chair. + It is the responsibility of these editors to ensure that the decisions of the Group are + correctly reflected in subsequent drafts of the technical report. + An editor must be a participant, + per § 3.4.2 Participation in Chartered Groups in the Group responsible for the document(s) they are editing.

+

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, + status information, + style, + and copyright requirements). + These rules are subject to change by the Team from time to time. + The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

+

The primary language for W3C Technical Reports is English. + W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C website.

+

6.2.2. Reviews and Review Responsibilities

+

A document is available for review + from the moment it is first published. + Working Groups should formally address any substantive review comment + about a technical report in a timely manner.

+

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, + particularly if this would cause significant compatibility problems + due to existing implementation. Working Groups should record substantive + or interesting proposals raised by reviews + but not incorporated into a current specification.

+
6.2.2.1. Wide Review
+

The requirements for wide review are not precisely defined by the W3C Process. + The objective is to ensure that the entire set of stakeholders of the Web community, + including the general public, + have had adequate notice of the progress of the Working Group (for example through notices posted to public-review-announce@w3.org) + and were able to actually perform reviews of and provide comments on the specification. + A second objective is to encourage groups to request reviews + early enough that comments and suggested changes + can still be reasonably incorporated in response to the review. + Before approving transitions, + the Team will consider who has been explicitly offered + a reasonable opportunity to review the document, + who has provided comments, + the record of requests to and responses from reviewers, + especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter + or identified as liaisons [LIAISON], + and seek evidence of clear communication to the general public + about appropriate times and which content to review + and whether such reviews actually occurred.

+

For example, + inviting review of new or significantly revised sections published in Working Drafts, + and tracking those comments + and the Working Group's responses, + is generally a good practice which would often be considered positive evidence of wide review. Working Groups should follow the W3C Horizontal Groups’ review processes, + and should announce to other W3C Working Groups + as well as the general public, + especially those affected by this specification, + a proposal to enter Candidate Recommendation (for example in approximately 28 days). + By contrast a generic statement in a document + requesting review at any time + is likely not to be considered as sufficient evidence + that the group has solicited wide review.

+

A Working Group could present evidence that wide review has been received, + irrespective of solicitation. + But it is important to note that receiving many detailed reviews + is not necessarily the same as wide review, + since they might only represent comment + from a small segment of the relevant stakeholder community.

+

6.2.3. Classes of Changes

+

This document distinguishes the following 5 classes of changes to a document. + The first two classes of change are considered editorial changes, + the next two substantive changes, + and the last one registry changes.

+
+
+ +
    +
  1. +

    No changes to text content

    +
+
These changes include fixing broken links, style sheets, or invalid markup. +
+ +
    +
  1. +

    Changes that do not functionally affect interpretation of the document

    +
+
For Recommendation-track technical reports specifically, + this constitutes changes that do not affect conformance, + i.e. changes that reasonable implementers + would not interpret as changing architectural + or interoperability requirements + or their implementation. + Changes which resolve ambiguities in the specification + are considered to change (by clarification) the implementation requirements + and do not fall into this class. +
Examples of changes in this class include + correcting non-normative examples + which clearly conflict with normative requirements, + clarifying informative use cases or other non-normative text, + fixing typos or grammatical errors + where the change does not change requirements. +
If there is any doubt or disagreement + as to whether a change functionally affects interpretation, + that change does not fall into this class. +
+ +
    +
  1. +

    Other changes that do not add new features

    +
+
+ For Recommendation-track documents, + these changes may affect conformance to the specification. + A change that affects conformance is one that: +
    +
  • makes conforming data, processors, or other conforming agents become non-conforming according to the new version, + or +
  • makes non-conforming data, processors, or other agents become conforming, + or +
  • clears up an ambiguity or under-specified part of the specification + in such a way that data, + a processor, + or an agent + whose conformance was once unclear + becomes clearly either conforming or non-conforming. +
+
+ +
    +
  1. +

    New features

    +
+
Changes that add new functionality, + such as new elements, new APIs, new rules, etc. +
+ +
    +
  1. +

    Changes to the contents of a registry table

    +
+
Changes that add, remove, or alter registry entries in a registry table. +
+

6.2.4. Errata Management

+

Tracking errors is an important part of a Working Group's ongoing care of a technical report; + for this reason, + the scope of a Working Group charter generally allows time + for work after publication of a Recommendation. + In this Process Document, + the term “erratum” + (plural “errata”) refers to any error + that can be resolved by one or more changes in classes 1-3 + of section § 6.2.3 Classes of Changes.

+

Working Groups must keep + a public record of errors + that are reported by readers and implementers + for Recommendations. + Such error reports should be compiled + no less frequently than quarterly.

+

Working Groups decide how to document errata. + Such documentation must identify + the affected technical report text + and describe the error; + it may also describe some possible solution(s). + Readers of the technical report should be able easily + to find and see the errata + that apply to that specific technical report with their associated tests. + Errata may be documented + in a separate errata page or tracking system. + They may, + in addition or alternatively, + be annotated inline + alongside the affected technical report text + or at the start or end of the most relevant section(s).

+

6.2.5. Candidate Amendments

+

An erratum may be accompanied by an informative, candidate correction approved by group decision. + When annotated inline, + errata—including their candidate corrections—must be marked as such, + are treated as class 2 changes, + and are published accordingly.

+

Note: Annotating changes in this way allows more mature documents + such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, + even when the candidate amendments have not yet received + sufficient review or implementation experience + to be normatively incorporated into the specification proper.

+

A candidate addition is similar to a candidate correction, + except that it proposes a new feature + rather than an error correction.

+

If there is no group chartered to maintain a technical report, + the Team may maintain its errata and associated candidate corrections. + Such corrections must be marked + as Team correction, + and do not constitute + a normative portion of the Recommendation, + as defined in the Patent Policy [PATENT-POLICY] (i.e. they are not covered by the Patent Policy). + The Team must solicit wide review on Team corrections that it produces.

+

Candidate corrections and candidate additions are collectively known as candidate amendments.

+

In addition to their actual maturity stage, published REC Track documents with candidate amendments are also considered, + for the purpose of the W3C Patent Policy [PATENT-POLICY], + to be Working Drafts with those candidate amendments treated as normative.

+

6.2.6. License Grants from Non-Participants

+

When a party who is not already obligated under the Patent Policy + offers a change in class 3 or 4 + (as described in § 6.2.3 Classes of Changes) to a technical report under this process + the Team must request + a recorded royalty-free patent commitment; + for a change in class 4, the Team must secure such commitment. + Such commitment should cover, + at a minimum, + all the party’s Essential Claims both in the contribution, + and that become Essential Claims as a result of incorporating the contribution into the draft + that existed at the time of the contribution, + on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

+

6.3. The W3C Recommendation Track

+

Working Groups create specifications and guidelines + to complete the scope of work envisioned by a Working Group's charter. + These technical reports undergo cycles of revision and review + as they advance towards W3C Recommendation status. + Once review suggests the Working Group has met their requirements for a new standard, + including wide review, + a Candidate Recommendation phase + allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. + At the end of the process, + the Advisory Committee reviews the mature technical report, + and if there is support from its Membership, + W3C publishes it as a Recommendation.

+

In summary, the W3C Recommendation Track consists of:

+
    +
  1. Publication of the First Public Working Draft. +
  2. Publication of zero or more revised Working Drafts. +
  3. Publication of one or more Candidate Recommendations. +
  4. Publication of a Proposed Recommendation. +
  5. Publication as a W3C Recommendation. +
+
+ + Basic W3C Recommendation Track + + + + + First Public Working Draft (FPWD) - Exclusion opportunity + + + + WG Decision + + Team Approval + + + + + + + + + Working Draft (WD) + + + + + + + + Publish a new Working Draft + + + WG Decision + + + + + + + + + Advance to Candidate Recommendation + + WG Decision + + Team Approval + + + + + + + + + + Candidate Recommendation Snapshot (CRS) - Patent Policy exclusion opportunity + + + + + + Candidate Recommendation Draft (CRD) + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + + Team Approval + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + Team Approval + + + + + + + + + + Advance to Proposed Recommendation + + WG Decision + + Team Approval + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision with AB+TAG Approval) + + + + + + + + + + + Proposed Recommendation (PR) — AC Review + + + AC Review + + + + + + Advance to Recommendation + + + W3C Decision + + + + + + + + + Return to Candidate Recommendation Snapshot + + + W3C Decision + + + + + + + + + Return to Working Draft + + + W3C Decision + + + + + + + + + + Recommendation (Rec) + + + + + +
+

This Process defines certain Recommendation Track publications as Patent Review Drafts. + Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004], + these correspond to “Last Call Working Draft” in the Patent Policy; + Starting from the 2020 Patent Policy [PATENT-POLICY-2020], + these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

+

W3C may end work on a technical report at any time.

+

As described in § 6.3.3 Advancement on the Recommendation Track, + the Team will decline a request to advance in maturity stage + and return the specification to a Working Group for further work + if it determines that the requirements for advancement + have not been met.

+

6.3.1. Maturity Stages on the Recommendation Track

+
+
Working Draft (WD) +
+ A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, + and other technical organizations, + and for simple historical reference. + Some, but not all, Working Drafts are meant to advance to Recommendation; + see the document status section of a Working Draft + for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, + and do not imply any endorsement by W3C + or its members beyond agreement to work on a general area of technology. + Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. + A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity. +

For all Working Drafts a Working Group:

+
    +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, + and +
  • may request publication of a Working Draft + even if its content is considered unstable + and does not meet all Working Group requirements. +
+

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), + and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

+
Candidate Recommendation (CR) +
+ A Candidate Recommendation is a document that satisfies the technical + requirements of the Working Group that produced it and their dependencies, + and has already received wide review. + W3C publishes a Candidate Recommendation to + +

Note: Advancing to Candidate Recommendation indicates + that the document is considered complete and fit for purpose, + and that no further refinement to the text is expected + without additional implementation experience and testing; + additional features in a later revision may however be expected. + A Candidate Recommendation is expected to be as well-written, + detailed, + self-consistent, + and technically complete + as a Recommendation, + and acceptable as such + if and when the requirements for further advancement are met.

+

Candidate Recommendation publications take one of two forms:

+
+
Candidate Recommendation Snapshot (CRS) +
+ A Candidate Recommendation Snapshot + corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. + Publishing a Patent Review Draft triggers a Call for Exclusions, + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy. +

Publication as a Candidate Recommendation Snapshot requires verification of either a Transition Request (for the first Candidate Recommendation publication from another maturity stage) + or an Update Request (for subsequent Candidate Recommendation Snapshots).

+
Candidate Recommendation Draft (CRD) +
+ A Candidate Recommendation Draft + is published on the W3C’s Technical Reports page [TR] to integrate changes from the previous Candidate Recommendation Snapshot that the Working Group intends to include + in a subsequent Candidate Recommendation Snapshot. + This allows for wider review of the changes + and for ease of reference to the integrated specification. +

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot. + However, the process requirements are minimized + so that the Working Group can easily keep the specification up to date.

+

A Candidate Recommendation Draft does not provide an exclusion opportunity; + instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

+
+

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered + such that W3C cannot endorse it or continue work on it, + for example due to burdensome patent claims that affect implementers and cannot be resolved + (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). + There is no path to restoration for a Rescinded Candidate Recommendation. + See “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

+
Proposed Recommendation (PR) +
A Proposed Recommendation is a document + that has been accepted by W3C + as of sufficient quality to become a W3C Recommendation. + This phase triggers formal review by the Advisory Committee, + who may recommend + that the document be published as a W3C Recommendation, + returned to the Working Group for further work, + or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation. +
W3C Recommendation (REC) +
+ A W3C Recommendation is a specification + or set of guidelines + or requirements that, + after extensive consensus-building, + has received the endorsement of W3C and its Members. + W3C recommends the wide deployment + of its Recommendations as standards for the Web. + The W3C Royalty-Free IPR licenses + granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. + As technology evolves, + a W3C Recommendation may become: +
+
A Superseded Recommendation +
+ A Superseded Recommendation is a specification + that has been replaced by a newer version + that W3C recommends for new adoption. + An Obsolete or Superseded specification + has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy. +

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, + the latest version replaces the previous one, + without the need to invoke the steps of § 6.3.13.3 Abandoning a W3C Recommendation: + it is the same document, updated. + Explicitly declaring a documented superseded, using the process documented in § 6.3.13.3 Abandoning a W3C Recommendation, + is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

+
An Obsolete Recommendation +
An Obsolete Recommendation is a specification + that W3C has determined lacks sufficient market relevance + to continue recommending it for implementation, + but which does not have fundamental problems + that would require it to be Rescinded. + If an Obsolete specification gains sufficient market relevance, + W3C may decide to restore it to Recommendation status. +
Rescinded Recommendation +
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, + and believes is unlikely to ever be restored to Recommendation status. + See also “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+
Discontinued Draft +
A technical report representing the state of a Recommendation-track document + at the point at which work on it was discontinued. + See § 6.3.13.1 Abandoning an Unfinished Recommendation. +
+

Only sufficiently technically mature work should be advanced.

+

Note: Should faster advancement to meet scheduling considerations be desired, + this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring + less stable features to other technical reports.

+

When publishing an updated version of an existing Candidate Recommendation or Recommendation, + technical reports are expected to meet the same maturity criteria as when they are first published under that status. + However, in the interest of replacing stale documents with improved ones in a timely manner, + if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, + it is also permissible to publish an updated CR or REC following the usual process, + even if only some of these flaws have been satisfactorily addressed.

+

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, + and do not necessarily imply consensus of a Working Group or Interest Group, + nor are their contents endorsed in any way by W3C.

+

6.3.2. Implementation Experience

+

Implementation experience is required to show that a specification is sufficiently clear, + complete, + and relevant to market needs, + to ensure that independent interoperable implementations + of each feature of the specification will be realized. + While no exhaustive list of requirements is provided here, + when assessing that there is adequate implementation experience the Team will consider (though not be limited to):

+
    +
  • is each feature of the current specification implemented, + and how is this demonstrated? +
  • are there independent interoperable implementations of the current specification? +
  • are there implementations created by people other than the authors of the specification? +
  • are implementations publicly deployed? +
  • is there implementation experience + at all levels of the specification’s ecosystem + (authoring, consuming, publishing…)? +
  • are there reports of difficulties or problems with implementation? +
+

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. + Groups are often able to work more effectively + if they plan how they will demonstrate interoperable implementations + early in the development process; + for example, developing tests in concert with implementation efforts.

+

6.3.3. Advancement on the Recommendation Track

+

For all requests to advance a specification + to a new maturity stage + (called Transition Requests), + the Working Group:

+
    +
  • must record the group’s decision to request advancement. +
  • must obtain Team verification. Team verification (a Team decision) must be withheld if any Process requirements are not met + or if there remain any unresolved Formal Objections + (including any upheld by a Council but not yet fully addressed), + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects a Transition Request it must indicate its rationale + to the Advisory Committee and the Working Group. +
  • must publicly document all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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 stage. +
  • must provide public documentation of any Formal Objections. +
  • should report which, if any, of the Working Group's requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

For a First Public Working Draft there is no “previous maturity stage”, + so many requirements do not apply, + and verification is normally fairly straightforward. + For later stages, + especially transition to Candidate or Proposed Recommendation, + there is usually a formal review meeting + to verify that the requirements have been met.

+

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved + while a Working Group's charter is undergoing or awaiting a decision + on an Advisory Committee Review.

+

+

6.3.4. Updating Mature Publications on the Recommendation Track

+

Certain requests to re-publish a specification + within its current maturity stage + (called Update Requests) + require extra verification. + For such update requests, the Working Group:

+
    +
  • must record the group’s decision to request the update. +
  • must show that the changes have received wide review. +
  • must obtain Team verification, + or fulfill the criteria for § 6.3.4.1 Streamlined Publication Approval. Team verification (a Team decision), should be withheld if any Process requirements are not met, + and may be withheld in consideration of unresolved Formal Objections + (including any upheld by a Council but not yet fully addressed) + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects an Update Request, + it must indicate its rationale to the Working Group. + If it waives any Process requirements, + it must indicate its rationale to the AC. +
  • must provide public documentation of any Formal Objections. +
  • must publicly document of all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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, + or explain why the requirements have changed or been deferred, +
  • should report which, if any, of the Working Group's requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

There is usually a formal review meeting + to verify that the requirements have been met.

+

Note: Update request verification is expected to be fairly simple + compared to verification of a transition request.

+

The Team must announce the publication + of the revised specification + to other W3C groups and the Public.

+
6.3.4.1. Streamlined Publication Approval
+

Note: These criteria are intentionally stricter than + the general requirements for an update request. + This is in order to minimize ambiguities and the need for expert judgment, + and to make self-evaluation practical.

+

In order to streamline the publication process in non-controversial cases, + verification of an update request is automatically granted without formal review + when the following additional criteria are fulfilled:

+
    +
  • There must have been no changes to Working Group requirements about this document. +
  • For each of the W3C Horizontal Groups [CHARTER], + if the Horizontal Review Group has made available a set criteria + under which their review is not necessary, + the Working Group must document that these criteria have been fulfilled. + Otherwise, the Working Group must show + that review from that group has been solicited and received. +
  • No Formal Objection has been registered against the document. +
  • + The Working Group must have formally addressed: +
      +
    • +

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

      +
    • +

      all issues raised against changes since the previous publication

      +
    • +

      all issues raised against the document that were closed since the previous publication with no change to the document

      +
    +

    The response to each of these issues must be to the satisfaction + 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.

    +

    Note: This is stricter than the general Transition Request criteria.

    +
+

Additionally, for updates to Recommendations with substantive changes or with new features:

+ +

The Working Group must provide written evidence for these claims, + and the Team must make these answers publicly and permanently available.

+

After publication, + if an AC Representative + or Team member + doubts that the evidence presented supports the claims, + they may request that a formal review meeting be convened post facto. + If that review finds that the requirements were not fulfilled, + the Team may revert the changes + by updating in place the status section to indicate that it has been reverted, + and by republishing the previously approved version of the technical report.

+

6.3.5. Publishing a First Public Working Draft

+

To publish the First Public Working Draft of a document, + a Working Group must meet the applicable requirements for advancement.

+

The Team must announce + the publication of a First Public Working Draft to other W3C groups and to the public.

+

6.3.6. Revising a Working Draft

+

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, + whose status section should indicate reasons for the lack of change.

+

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

+
    +
  • must record the group’s decision to request publication. Consensus is not required, + as this is a procedural step, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Working Draft, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous step, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups, +
+

Possible next steps for any Working Draft:

+ +

6.3.7. Transitioning to Candidate Recommendation

+

To publish a Candidate Recommendation, + in addition to meeting the requirements for advancement a Working Group:

+
    +
  • must show that the specification + has met all Working Group requirements, + or explain why the requirements have changed or been deferred, +
  • must document changes to dependencies during the development of the specification, +
  • must document + how adequate implementation experience will be demonstrated, +
  • must specify the deadline for comments, + delineating the Candidate Recommendation review period, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • must show that the specification has received wide review, and +
  • 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 Recommendation. +
+

The first Candidate Recommendation publication + after verification of having met the requirements for a Transition Request is always a Candidate Recommendation Snapshot. + The Team must announce + the publication of the Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

Possible next steps after a Candidate Recommendation Snapshot:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.8. Revising a Candidate Recommendation

+
6.3.8.1. Publishing a Candidate Recommendation Snapshot
+

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, + the Working Group must meet the requirements of an update request in order to republish.

+

In addition the Working Group:

+
    +
  • must specify the deadline for further comments, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • 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 Recommendation. +
+

The Team must announce + the publication of a revised Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

To provide timely updates and patent protection, + a Candidate Recommendation Snapshot should be published + within 24 months of the Working Group accepting + any proposal for a substantive change + (and preferably sooner). + To make scheduling reviews easier, + a Candidate Recommendation Snapshot should not be published + more often than approximately once every 6 months.

+

Note: Substantive changes trigger a new Exclusion Opportunity + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.8.2. Publishing a Candidate Recommendation Draft
+

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 + that would benefit from review beyond the Working Group.

+

To publish a revision of a Candidate Recommendation Draft, + a Working Group:

+
    +
  • must record the group’s decision to request publication, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups. +
+

Note: A Working Group does not need to + meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

+

Possible next steps after a Candidate Recommendation Draft:

+ +

6.3.9. Transitioning to Proposed Recommendation

+

In addition to meeting the requirements for advancement,

+
    +
  • The status information must specify the deadline for Advisory Committee review, + which must be at least 28 days + after the publication of the Proposed Recommendation and should be at least 10 days + after the end of the last Exclusion Opportunity + per ”Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+

A Working Group:

+ +

The Team:

+ +

Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on, + to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft.

+

A Proposed Recommendation may identify itself + as intending to allow new features (class 4 changes) + after its initial publication as a Recommendation, + as described in § 6.3.11.4 Revising a Recommendation: New Features. + Such an allowance cannot be added + to a technical report previously published as a Recommendation that did not allow such changes.

+

Possible Next Steps:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.10. Transitioning to W3C Recommendation

+

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

+

In addition to meeting the requirements for advancement,

+ +

Possible next steps: + A W3C Recommendation normally retains its status indefinitely. + However it may be:

+ +

6.3.11. Revising a W3C Recommendation

+

This section details the process for making changes to a Recommendation.

+
6.3.11.1. Revising a Recommendation: Markup Changes
+

A Working group may request republication of a Recommendation to make corrections that do not result + in any changes to the text of the specification. + (See class 1 changes.)

+

If there is no Working Group chartered to maintain a Recommendation, + the Team may republish the Recommendation with such changes incorporated.

+
6.3.11.2. Revising a Recommendation: Editorial Changes
+

Editorial changes to a Recommendation require no technical review of the intended changes. + A Working Group, + provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity stages. + (See class 2 changes.)

+

If there is no Working Group chartered to maintain a Recommendation, + the Team may republish the Recommendation with such changes incorporated, + including errata and Team corrections.

+
6.3.11.3. Revising a Recommendation: Substantive Changes
+

A candidate correction can be made normative + and be folded into the main text of the Recommendation, + once it has satisfied all the same criteria + as the rest of the Recommendation, + including review by the community to ensure + the technical and editorial soundness of the candidate amendments. + To validate this, the Working Group must request + a Last Call for Review of Proposed Amendments, + followed by an update request. + See § 6.3.11.5 Incorporating Candidate Amendments.

+

Alternatively, + a Working Group may incorporate the changes + and publish as a Working Draft—or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—and advance the specification from that state. + (See class 3 changes.)

+

Note: If there is no Working Group chartered to maintain a Recommendation the Team cannot make substantive changes and republish the Recommendation. + It can, however, informatively highlight problems and desirable changes + using errata and candidate corrections and republish as described in the previous section.

+
6.3.11.4. Revising a Recommendation: New Features
+

New features (see class 4 changes) + may be incorporated into a Recommendation explicitly identified as allowing new features using candidate additions. + A candidate addition can be made normative + and be folded into the main text of the Recommendation using the same process as for candidate amendments, + as detailed in § 6.3.11.3 Revising a Recommendation: Substantive Changes.

+

Note: This prohibition against new features unless explicitly allowed + enables third parties to depend on Recommendations having a stable feature-set, + as they have prior to the 2020 revision of this Process.

+

To make changes which introduce a new feature + to a Recommendation that does not allow new features, + W3C must create a new technical report, + following the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.

+
6.3.11.5. Incorporating Candidate Amendments
+

A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.

+

The Last Call for Review of Proposed Amendments must be announced to other W3C groups, the public, and the Advisory Committee. + The announcement must:

+
    +
  • Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, + or Last Call for Review of Proposed Corrections and Additions. +
  • Identify the specific candidate amendments under review + as proposed amendments (proposed corrections/proposed additions). +
  • Specify the deadline for review comments, + which must not be any sooner than 60 days from the Call for Review. +
  • Solicit review and, if it does not already have it, implementation experience. +
+

The combination of the existing Recommendation with the proposed amendments included in the Last Call for Review of Proposed Amendments is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. + Also, the review initiated by the Last Call for Review of Proposed Amendments is an Advisory Committee Review.

+

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

+

A Working Group may batch + multiple proposed amendments into a single Last Call for Review of Proposed Amendments. + To facilitate review, + a Last Call for Review of Proposed Amendments on a given specification should not be issued more frequently + than approximately once every 6 months.

+

At the end of the Last Call for Review of Proposed Amendments, + the W3C Decision may either be + to reject the proposed amendment, + or to clear the proposed amendment for advancement as is, + or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. + If the Working Group needs to amend a proposed amendment in response to review feedback + it must issue another Last Call for Review of Proposed Amendments on the revised change + before it can be incorporated into the main text.

+

Once all comments on a proposed amendment have been formally addressed, + and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, + it may incorporate the proposed amendment into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

+

To ensure adequate review of proposed amendment combinations, + only proposed amendments included in the most recent Last Call for Review of Proposed Amendments can be incorporated into the normative Recommendation text. + (Thus if incorporation of a proposed amendment is postponed, + it may need to be included in multiple Last Calls for Review of Proposed Amendments.)

+

6.3.12. Regression on the Recommendation Track

+

A Working Group may republish a Recommendation-track technical report at a lower maturity stage by fulfilling the requirements to transition to that maturity stage, + as described above.

+

Additionally, + with the approval of the TAG and the AB the Team may return + the technical report to a lower maturity stage in response to wide review or a formal objection.

+

6.3.13. Retiring Recommendation Track Documents

+

Work on a technical report may cease at any time. + Work should cease + if W3C or a Working Group determines + that it cannot productively carry the work any further.

+
6.3.13.1. Abandoning an Unfinished Recommendation
+

Any Recommendation-track technical report no longer intended + to advance or to be maintained, + and that is not being rescinded, should be published as a Discontinued Draft, + with no substantive change compared to the previous publication. + This can happen if + the Working Group decided + to abandon work on the report, + or as the result of an AC Review requiring the Working Group to discontinue work on the technical report before completion. + If a Working Group is made to close, + W3C must re-publish any unfinished technical report on the Recommendation track as Discontinued Draft.

+

Such a document should include in its status section + an explanation of why it was discontinued.

+

A Working Group may resume work + on such a technical report within the scope of its charter + at any time, + by re-publishing it as a Working Draft.

+
6.3.13.2. Rescinding a Candidate Recommendation
+

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

+
6.3.13.3. Abandoning a W3C Recommendation
+

It is possible that W3C decides + that implementing a particular Recommendation is no longer recommended. + There are three designations for such specifications, + chosen depending on the advice W3C wishes to give about further use of the specification.

+

W3C may obsolete a Recommendation, + for example if the W3C Community decides that the Recommendation no longer represents best practices, + or is not adopted and is not apparently likely to be adopted. + An Obsolete Recommendation may be restored to normal Recommendation, + for example because despite marking it Obsolete the specification is later more broadly adopted.

+

W3C may declare a Recommendation Superseded + if a newer version exists which W3C recommends for new adoption. + The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; + only the name and explanation change.

+

W3C may rescind a Recommendation + if W3C believes there is no reasonable prospect of it being restored + for example due to burdensome patent claims that affect implementers and cannot be resolved; + see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” + and “PAG Conclusion”.

+

W3C only rescinds, supersedes, or obsoletes entire Recommendations. + A Recommendation can be both superseded and obsolete. + To rescind, supersede, or obsolete some part of a Recommendation, + W3C follows the process for modifying a Recommendation.

+

Note: For the purposes of the W3C Patent Policy [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, + although it is not recommended for future implementation; + a Rescinded Recommendation ceases to be in effect + and no new licenses are granted under the Patent Policy.

+
+ + Supersede, Obsolete or Rescind a W3C Recommendation + + + + Recommendation (Rec) + + + + + A major problem and an AC review can lead to a Recommendation being Rescinded. + There are no new IPR licences issued under the W3C Patent Policy, + and reinstating the Recommendation requires going through the full Rec-track process again. + + Major problem, AC review + + + Rescinded Recommendation - no new IPR licenses + + + + + + + + + With little uptake, following AC review a specification may become an Obsolete Recommendation + + + + + Obsolete Recommendation + + + + + + + + If there is new uptake, with AC review an Obsolete Recommendation may return to normal Recommendation status + + + + + + + + + + + Replaced by a new version, AC review + + Superseded Recommendation + + + + + + + A Superseded Recommendation can become a normal Recommendation with AC review + + + + + + + + + + + +
+
6.3.13.4. Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
+

The process of rescinding, obsoleting, + superseding, + or restoring + a Recommendation can be initiated + either by a request from the Team or via a request from any of the following:

+
    +
  • The Working Group who produced, + or is chartered to maintain, + the Recommendation +
  • The TAG, if there is no such Working Group +
  • Any individual who made a request to the relevant Working Group as described above, + or the TAG if such a group does not exist, to obsolete, rescind, supersede, or restore a Recommendation, + where the request was not answered within 90 days +
  • 5% of the members of the Advisory Committee +
+

The Team must then + submit the request to the Advisory Committee for review. + For any Advisory Committee review of a proposal to + rescind, + obsolete, + supersede, + or restore + a Recommendation the Team must:

+
    +
  • announce the proposal to all Working Group Chairs, + and to the Public, + as well as to the Advisory Committee +
  • indicate that this is a proposal to + Rescind, + Obsolete, + Supersede, + or restore, + a Recommendation as appropriate +
  • identify the Recommendation by URL +
  • publish a rationale for the proposal +
  • identify known dependencies + and solicit review from all dependent Working Groups +
  • solicit public review +
  • specify the deadline for review comments, + which must be at least 28 days + after the announcement +
+

and should

+
    +
  • identify known implementations. +
+

If there was any dissent in the Advisory Committee review, + the Team must publish + the substantive content of the dissent to W3C and the public, + and must formally address the dissent + at least 14 days + before publication as an Obsolete or Rescinded Recommendation.

+

The Advisory Committee may initiate an Advisory Committee Appeal of the Team's decision.

+

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. + The updated version may remove the main body of the document. + The Status of this Document section should link + to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

+

Once W3C has published a Rescinded Recommendation, + future W3C technical reports must not include normative references + to that technical report.

+

Note: W3C strives to ensure that all Technical Reports + will continue to be available at their version-specific URL.

+

6.4. The Note Track (Notes and Statements)

+

6.4.1. Group Notes

+

A Group Note (NOTE) + is published + to provide a stable reference for a useful document + that is not intended to be a formal standard.

+

Working Groups, Interest Groups, + the TAG and the AB may publish work as Notes. + Examples include:

+
    +
  • supporting documentation for a specification, + such as explanations of design principles + or use cases and requirements +
  • non-normative guides to good practices +
+

Some Notes are developed through successive Draft Notes before publication as a full Notes, + while others are published directly as a Note. + There are few formal requirements to publish a document as a Note or Draft Note, + and they have no standing as a recommendation of W3C + but are simply documents preserved for historical reference.

+

Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Draft Notes.

+

6.4.2. Publishing Notes

+

In order to publish a Note or Draft Note, + the group:

+
    +
  • must record their decision + to request publication as a Note or Draft Note, and +
  • should publish documentation + of significant changes to the technical report + since any previous publication. +
+

Both Notes and Draft Notes can be updated by republishing + as a Note or Draft Note. + A technical report may remain + a Note indefinitely.

+

If a Note produced by a chartered group is no longer in scope for any group, + the Team may republish the Note with class 1 changes incorporated, + as well as with errata and Team corrections annotated.

+

6.4.3. Elevating Group Notes to W3C Statement status

+

A W3C Statement is a Note that has been endorsed by W3C as a whole. + In order to elevate a Note to W3C Statement status, + A group must:

+ +

A Note specifying implementable technology should not be elevated to W3C Statement status; + if it does, + the request to publish as a Statement must include rationale + for why it should be elevated, + and why it is not on the Recommendation track.

+

Once these conditions are fulfilled, + the Team must then + begin an Advisory Committee Review on the question of + whether the document is appropriate to publish as a W3C Statement. + During this review period, + the Note must not be updated.

+

The decision to advance a document to W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

The Team must announce the publication of a W3C Statement to the Advisory Committee, other W3C groups, and the public.

+

6.4.4. Revising W3C Statements

+

Given a recorded group decision to do so, + groups can request publication of a W3C Statement with editorial changes—including candidate amendment—without any additional process.

+

A candidate amendment can be folded into the main text of the W3C Statement, + once it has satisfied all the same criteria + as the rest of the Statement, + including review by the community to ensure + the substantive and editorial soundness of the candidate amendments. + To validate this, the group must request + an Advisory Committee review of the changes it wishes to incorporate. + The specific candidate amendments under review must be identified as proposed amendments just as in a Last Call for Review of Proposed Corrections.

+

The decision to incorporate proposed amendments into W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

6.5. The Registry Track

+

A registry documents a data set + consisting of one or more associated registry tables, + each table representing an updatable collection + of logically independent, consistently-structured registry entries. + A registry has three associated components:

+ +

The purposes of maintaining a registry can include:

+
+
non-collision +
Avoiding the problem + of two entities using the same value with different semantics. +
non-duplication +
Avoiding the problem + of having two or more different values in use with the same semantics. +
information +
Providing a central index + where anyone can find out + what a value means + and what its formal definition is + (and where it is). +
submission +
Ease of adding new terms, + including by stakeholders external to the custodian organization. +
consensus +
Promoting a clear consensus of the community on the terms. +
+

This section of the W3C Process provides a specialized process + facilitating the publication and maintenance of such registry tables, + particularly those required by or closely related to W3C Recommendations.

+

Note: Not every table in a specification is a potential registry. + If the intent or effect is that the table enumerates + all the possibilities the authors of the specification expect or envisage, + then the table by itself is enough. + Similarly, if the table is managed by the Working Group + and only updated as part of specification update, + then the complexities of registry management are not needed.

+

6.5.1. Registry Definitions

+

A registry definition defines what each registry table is and how it is maintained. + It must:

+
    +
  • Define the scope and purpose of each registry table. +
  • Define the fields of each registry table and their constraints + (e.g. values must be drawn from a defined set, or be unique, + or only reference publicly available resources, + etc.) +
  • + Define the policy for changes to existing entries, such as +
      +
    • whether entries can be deleted or deprecated +
    • whether entries can be changed after being published, and what kinds of changes are allowed +
    • whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely +
    +
  • Define the method and criteria by which changes are proposed, approved, and incorporated. + (For example, a registry could define + that changes to registry entries can be proposed using a particular web form or email address, + that they must be accompanied by certain background information, + or that they do or do not need to be approved by any member of a particular Working Group.) +
  • + Identify the custodian of the registry table: + the entity to which requests for registry changes must be sent, + and which is responsible for evaluating whether such requests + satisfy the criteria defined in the registry definition. +

    The custodian may be the Working Group, the Team, or a delegated entity. + The custodian for all registry tables in a single registry should generally be the same entity.

    +
+

6.5.2. Publishing Registries

+

Registries can be published either + as a stand-alone technical report on the Registry Track called a registry report, + or incorporated as part of a Recommendation as a registry section.

+

A registry report or registry section is purely documentational, + is not subject to the W3C Patent Policy, + and must not contain any requirements on implementations. + For the purposes of the Patent Policy [PATENT-POLICY], + any registry section in a Recommendation track document + is not a normative portion of that specification.

+

The registry report or registry section must:

+ +

The Team must make available + a means for interested parties to be notified of any updates to a registry table.

+

Note: Since the Process does not impose requirements + on changes to the contents of a registry table other than those imposed by the registry definition, + acceptance of proposed registry changes on behalf of the custodian and + publication of an updated registry report that contains + only registry changes since the previous publication + can be automated + if satisfaction of those rules can be automatically verified.

+

Rules for publication and advancement on the Registry Track are identical to that of the Recommendation Track with the following exceptions:

+ +

6.5.3. Updating Registry Tables

+

Changes to the contents of a registry table that are in accordance with the registry definition, + (i.e. Class 5 changes) + can be made by re-publishing the technical report that contains the affected table, + without needing to satisfy any other requirements for the publication + (not even Working Group consensus, unless this is required by the registry definition). + Such registry changes do not trigger new Advisory Committee Reviews, + nor Exclusion Opportunities, + and do not require verification via an update request, + even for technical reports at maturities where this would normally be expected. + Such publications can be made + even in the absence of a Working Group chartered to maintain the registry + when the custodian is another entity.

+

Note: The custodian is only empowered to make registry changes. + If the Working Group establishing the registry wishes + to empower the custodian to add commentary on individual entries, + this needs to be part of the registry table’s definition. + If other changes are desired, + they must be requested of the responsible Working Group—or in the absence of a Working Group, of the Team.

+

Changes to the registry tables made in accordance with candidate or proposed amendments to the registry definition which would not be allowed by the unamended registry definition must be identified as such.

+

6.5.4. Registry Data Reports

+

When the registry data is published in a separate technical report from its registry definition, + that report is called a Registry Data Report. + This technical report:

+ +

Registry Data Reports do not have maturity stages in and of themselves; + The maturity stage of the registry whose data they record + is that of the technical report holding the registry definition.

+

Anytime a change is made to a registry definition, + the Working Group must update and republish + any document holding the corresponding registry tables to make it consistent with these changes.

+

Given a recorded group decision to do so, + the Working Group may republish the Registry Data Report to incorporate editorial changes. + If there is no Working Group chartered to maintain this registry, + the Team may do so instead.

+

6.5.5. Specifications that Reference Registries

+

Registries document values, + they do not define any architectural or interoperability requirements + related to those values. + All architectural and interoperability requirements + pertaining to registry entries must be contained in the specifications that reference the registry, + and are therefore subject to the processes + (including approval and intellectual property provisions) + applicable to those referencing specifications.

+

If there are entries that must be implemented, + or any other such restrictions, + they must be defined or documented + in the referencing specification + without dependency on the registry.

+
For example, + “All implementations must implement the Basic-Method as defined in the registry” + is not acceptable; + a change to the definition of the Basic-Method in the registry would then affect conformance. + Instead, the requirement must be complete in the specification, + directly or by reference to another specification. + For example + “All implementations must recognize the name Basic-Method, + and implement it as defined by section yy of IETF RFC xxxx”. + (The Registry should nonetheless contain Basic-Method as an entry.)
+

6.6. Switching Tracks

+

Given a Group decision to do so, Working Groups can republish a technical report on a different track than the one it is on, + under the following restrictions:

+ +

Technical reports that switch tracks start at + their new track’s initial maturity stage, + while retaining any established identity (url, shortname, etc.).

+

6.7. Further reading

+

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews + and announcements of the various steps, + and tips on getting to Recommendation faster [REC-TIPS]. + Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

+

7. Dissemination Policies

+

7.1. Public Communication

+

The Team is responsible for managing communication within W3C + and with the general public + (e.g., news services, press releases, managing the website and access privileges, and managing calendars). + Members should solicit review by the Team + prior to issuing press releases about their work within W3C.

+

The Team makes every effort to ensure the persistence and availability of the following public information:

+
    +
  • W3C technical reports whose publication has been approved. + Per W3C IPR Policies, + W3C technical reports (and software) are available free of charge to the general public. +
  • A mission statement [MISSION] that explains the purpose and mission of W3C, + the key benefits for Members, + and the organizational structure of W3C. +
  • Legal documents, + including the Membership Agreement [MEMBER-AGREEMENT] and documentation of any legal commitments W3C has with other entities. +
  • The Process Document. +
  • Public results of W3C activities and Workshops. +
+

To keep the Members abreast of W3C meetings, Workshops, + and review deadlines, + the Team provides them with a regular (e.g., weekly) news service + and maintains a calendar [CALENDAR] of official W3C events. + Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

+

7.2. Confidentiality Levels

+

There are three principal levels of access to W3C information + (on the W3C website, in W3C meetings, etc.): + public, + Member-only, + and Team-only.

+

While much information made available by W3C is public, + “Member-only” information + is available to authorized parties only, + including representatives of Member organizations, Invited Experts, + the Advisory Board, + the TAG, + and the Team. + For example, + the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

+

“Team-only” information + is available to the Team and other authorized parties.

+

Those authorized to access Member-only and Team-only information:

+
    +
  • must treat the information as confidential within W3C, +
  • must use reasonable efforts to maintain the proper level of confidentiality, and +
  • must not release this information to the general public or press. +
+

The Team must provide mechanisms + to protect the confidentiality of Member-only information + and ensure that authorized parties have proper access to this information. + Documents should clearly indicate + whether they require Member-only confidentiality. + Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

+

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member + who are considered appropriate recipients. + For instance, + it is the responsibility of the Advisory Committee representative and other employees + and official representatives of the organization + to ensure that Member-only news announcements + are distributed for internal use only within their organization. + Information about Member mailing lists is available + in the New Member Orientation [INTRO].

+

7.3. Changing Confidentiality Level

+

As a benefit of membership, + W3C provides some Team-only and Member-only channels + for certain types of communication. + For example, Advisory Committee representatives can send reviews to a Team-only channel. + However, for W3C processes with a significant public component, + such as the technical report development process, + it is also important for information that affects decision-making to be publicly available. + The Team may need to communicate Team-only information to a Working Group or the public. + Similarly, a Working Group whose proceedings are Member-only must make public + information pertinent to the technical report development process.

+

This document clearly indicates which information must be available to Members or the public, + even though that information was initially communicated on Team-only or Member-only channels. + Only the Team and parties authorized by the Team + may change the level of confidentiality of this information. + When doing so:

+
    +
  1. The Team must use a version of the information + that was expressly provided by the author for the new confidentiality level. + In Calls for Review and other similar messages, + the Team should remind recipients to provide such alternatives. +
  2. The Team must not attribute the version + for the new confidentiality level to the author without the author’s consent. +
  3. If the author has not conveyed to the Team a version + that is suitable for another confidentiality level, + the Team may make available a version that reasonably communicates what is required, + while respecting the original level of confidentiality, + and without attribution to the original author. +
+

8. Workshops and Symposia

+

The Team organizes Workshops and Symposia to promote early involvement in the development of W3C activities + from Members and the public.

+

The goal of a Workshop is usually + either to convene experts and other interested parties for an exchange of ideas + about a technology or policy, + or to address the pressing concerns of W3C Members. + Organizers of the first type of Workshop may solicit position papers for the Workshop program + and may use those papers + to choose attendees and/or presenters.

+

The goal of a Symposium is usually + to educate interested parties about a particular subject.

+

The Call for Participation in a Workshop or Symposium may indicate participation requirements or limits, + and expected deliverables + (e.g., reports and minutes). + Organization of an event does not guarantee + further investment by W3C in a particular topic, + but may lead to proposals for new activities or groups.

+

Workshops and Symposia generally last one to three days. + If a Workshop is being organized to address the pressing concerns of Members, + the Team must issue the Call for Participation + no later than six weeks prior to the Workshop’s scheduled start date. + For other Workshops and Symposia, + the Team must issue a Call for Participation + no later than eight weeks prior to the meeting’s scheduled start date. + This helps ensure that speakers and authors + have adequate time to prepare position papers and talks.

+

9. Liaisons

+

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, + through a number of mechanisms + ranging from very informal + (e.g., an individual from another organization participates in a W3C Working Group, + or just follows its work) + to mutual membership, + to even more formal agreements. + Liaisons are not meant to substitute for W3C membership.

+

All liaisons must be coordinated by the Team due to requirements for public communication; + patent, + copyright, + and other IPR policies; + confidentiality agreements; + and mutual membership agreements.

+

W3C may negotiate technical agreements with another organization. + For purposes of the W3C Process, + a technical agreement is a formal contract, + or a Memorandum of Understanding (MoU), + or a similar document, + between W3C and another party or parties, + that relates to the technical activity of the Consortium + (e.g., its publications, groups, or liaisons). + It specifies rights and obligations of each party toward the others. + These rights and obligations may include joint deliverables, + an agreed share of technical responsibilities with due coordination, + and/or considerations for confidentiality and specific IPR.

+

Non-technical agreements, including + those between W3C and its Members for the purposes of membership, + between W3C and its Partners for the purposes of partnership [BYLAWS], + and other agreements related to the operation of the Consortium + or to the ordinary provision of services, + are not subject to these Process provisions.

+

When considering a technical agreement (i.e., before the decision whether to sign is made), + the Team should provide + the Advisory Committee with a draft of the proposed agreement, + along with an explanation of how W3C would benefit from signing this agreement, + for their review and discussion. + After addressing any comments, + and subject to any management or governance procedures that apply + (e.g., formal review of proposed contracts by legal counsel or by the Board), + if the Team decides to proceed with signing the agreement, + the Team must announce the intent to sign, + and provide the final text of the agreement, + with an explanation of signing rationale, to + the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the agreement. + If the proposal is rejected on appeal, + the Team must not sign the agreement on behalf of W3C + unless directed to do so by the Board. + A signed agreement should be made public.

+

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

+

10. Member Submission Process

+

The Member Submission process allows Members + to propose technology + or other ideas + for consideration by the Team. + After review, + the Team may make the material available at the W3C website. + The formal process affords Members a record of their contribution + and gives them a mechanism for disclosing the details of the transaction with the Team + (including IPR claims). + The Team also makes review comments on the Submitted materials available for W3C Members, + the public, + and the media.

+

A Member Submission consists of:

+
    +
  • One or more documents developed outside of the W3C process, and +
  • Information about the documents, + provided by the Submitter. +
+

One or more Members (called the Submitter(s)) may participate in a Member Submission. + Only W3C Members may be listed as Submitters.

+

The Submission process consists of the following steps:

+
    +
  1. One of the Submitters sends a request to the Team to acknowledge the Submission request. + The Team and Submitter(s) communicate to ensure that the Member Submission is complete. +
  2. + After review, the Team must either + acknowledge or reject the Submission request. + +
+
+ Note: To avoid confusion about the Member Submission process, please note that: + +
+

Making a Member Submission available at the W3C website + does not imply endorsement by W3C, + including the W3C Team or Members. + The acknowledgment of a Submission request + does not imply that any action will be taken by W3C. + It merely records publicly + that the Submission request has been made by the Submitter. + A Member Submission made available by W3C must not be referred to as “work in progress” of W3C.

+

The list of acknowledged Member Submissions [SUBMISSION-LIST] is available at the W3C website.

+

10.1. Submitter Rights and Obligations

+

When more than one Member jointly participates in a Submission request, + only one Member formally sends in the request. + That Member must copy + each of the Advisory Committee representatives of the other participating Members, + and each of those Advisory Committee representatives must confirm + (by email to the Team) + their participation in the Submission request.

+

At any time prior to acknowledgment, + any Submitter may withdraw support for a Submission request + (described in "How to send a Submission request" [SUBMISSION-REQ]). + A Submission request is “withdrawn” when no Submitter(s) support it. + The Team must not make statements + about withdrawn Submission requests.

+

Prior to acknowledgment, + the Submitter(s) must not, under any circumstances, + refer to a document as “submitted to the World Wide Web Consortium” + or “under consideration by W3C” or any similar phrase + either in public or Member communication. + The Submitter(s) must not imply + in public or Member communication + that W3C is working (with the Submitter(s)) on the material in the Member Submission. + The Submitter(s) may release the documents in the Member Submission to the public + prior to acknowledgment + (without reference to the Submission request).

+

After acknowledgment, + the Submitter(s) must not, under any circumstances, + imply W3C investment in the Member Submission + until, and unless, the material has been adopted as a deliverable + of a W3C Working Group.

+

10.1.1. Scope of Member Submissions

+

When a technology overlaps in scope with the work of a chartered Working Group, + Members should participate in the Working Group and contribute the technology to the group’s process + rather than seek publication through the Member Submission process. + The Working Group may incorporate the contributed technology into its deliverables. + If the Working Group does not incorporate the technology, + it should not publish the contributed documents + as Working Group Notes since Working Group Notes represent group output, + not input to the group.

+

On the other hand, + while W3C is in the early stages of developing a charter, + Members should use the Submission process + to build consensus around concrete proposals for new work.

+

Members should not submit materials + covering topics well outside the scope of W3C’s mission [MISSION].

+

10.1.2. Information Required in a Submission Request

+

The Submitter(s) + and any other authors of the submitted material must agree that, + if the request is acknowledged, + the documents in the Member Submission will be subject to the W3C Document License [DOC-LICENSE] and will include a reference to it. + The Submitter(s) may hold the copyright for the documents in a Member Submission.

+

The request must satisfy the Member Submission licensing commitments + in “Licensing Commitments in W3C Submissions” + in the W3C Patent Policy [PATENT-POLICY].

+

The Submitter(s) must include the following information:

+
    +
  • The list of all submitting Members. +
  • Position statements from all submitting Members (gathered by the Submitter). + All position statements must appear in a separate document. +
  • Complete electronic copies of any documents submitted for consideration + (e.g., a technical specification, + a position paper, + etc.) + If the Submission request is acknowledged, + these documents will be made available by W3C + and therefore must satisfy the Team’s Publication Rules [PUBRULES]. Submitters may hold the copyright for the material contained in these documents, + but when made available by W3C, + these documents must be subject to the provisions + of the W3C Document License [DOC-LICENSE]. +
+

The request must also answer the following questions.

+
    +
  • What proprietary technology is required to implement the areas addressed by the request, + and what terms are associated with its use? + Again, many answers are possible, + but the specific answer will affect the Team’s Decision. +
  • What resources, if any, + does the Submitter intend to make available + if W3C acknowledges the Submission request + and takes action on it? +
  • What action would the Submitter like W3C to take + if the Submission request is acknowledged? +
  • What mechanisms are there to make changes to the specification being submitted? + This includes, but is not limited to, + stating where change control will reside + if the request is acknowledged. +
+

For other administrative requirements related to Submission requests, + see “How to send a Submission request” [MEMBER-SUB].

+

10.2. Team Rights and Obligations

+

Although they are not technical reports, + the documents in a Member Submission must fulfill the requirements established by the Team, + including the Team’s Publication Rules [PUBRULES].

+

The Team sends a validation notice to the Submitter(s) + once the Team has reviewed a Submission request + and judged it complete and correct.

+

Prior to a decision to acknowledge or reject the request, + the request is Team-only, + and the Team must hold it in the strictest confidentiality. + In particular, + the Team must not comment to the media + about the Submission request.

+

10.3. Acknowledgment of a Submission Request

+

The Team acknowledges a Submission request + by sending an announcement to the Advisory Committee. + Though the announcement may be made at any time, + the Submitter(s) can expect an announcement between four to six weeks after the validation notice. + The Team must keep the Submitter(s) informed + of when an announcement is likely to be made.

+

Once a Submission request has been acknowledged, + the Team must:

+
    +
  • Make the Member Submission available at the W3C website. +
  • Make the Team comments about the Submission request available at the W3C website. +
+

If the Submitter(s) wishes to modify + a document made available as the result of acknowledgment, + the Submitter(s) must start the Submission process from the beginning, + even just to correct editorial changes.

+

10.4. Rejection of a Submission Request, and Submission Appeals

+

The Team may reject a Submission request + for a variety of reasons, + including any of the following:

+
    +
  • The ideas expressed in the request + overlap in scope with the work of a chartered Working Group, + and acknowledgment might jeopardize the progress of the group. +
  • The IPR statement made by the Submitter(s) is inconsistent with W3C’s + Patent Policy [PATENT-POLICY] and in particular the “Licensing Commitments in W3C Submissions”, Document License [DOC-LICENSE], + or other IPR policies. +
  • The ideas expressed in the request are poor, + might harm the Web, + or run counter to W3C’s mission [MISSION]. +
  • The ideas expressed in the request lie well outside the scope of W3C’s mission. +
+

In case of a rejection, + the Team must inform the Advisory Committee representative(s) + of the Submitter(s). + If requested by the Submitter(s), + the Team must provide rationale + to the Submitter(s) about the rejection. + Other than to the Submitter(s), + the Team must not make statements about why a Submission request was rejected.

+

The Advisory Committee representative(s) of the Submitters(s) may initiate a Submission Appeal. + The procedure for handling Submission Appeals is the same as for Formal Objections, + except that an AC Appeal is not possible + and both the Formal Objection and the Council Report are confidential to the Team, TAG, and AB.

+

11. Process Evolution

+

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, + with the Advisory Board—acting as the sponsoring Working Group. + The documents may be developed by the AB or by another group to whom the AB has delegated development. + Review includes + soliciting input from the W3C community, + and in particular the Team.

+

The documents covered by this section are:

+
    +
  • +

    the W3C Process (this document)

    +
  • +

    the W3C Patent Policy [PATENT-POLICY]

    +
  • +

    the W3C Code of Ethics and Professional Conduct [CEPC]

    +
  • +

    The W3C Document License [DOC-LICENSE]

    +
+

The Advisory Board initiates review as follows:

+
    +
  1. The Team sends a Call for Review to the Advisory Committee and other W3C groups. +
  2. After comments have been formally addressed and the document possibly modified, + the Team seeks endorsement from the Members by initiating an Advisory Committee review. + The review period must last at least 28 days. +
  3. After the Advisory Committee review, + following a W3C decision to adopt the document(s), + the Team does so + and sends an announcement to the Advisory Committee. + Advisory Committee representatives may initiate + an Advisory Committee Appeal to W3C. +
+

Note: As of June 2020, + the Patent Policy is developed in the Patents and Standards Interest Group, + the Code of Ethics and Professional Conduct in the Positive Work Environment Community Group, + and the Process in the W3C Process Community Group.

+

12. Acknowledgments

+

This section is non-normative.

+

The editors are grateful to the following people, + who as interested individuals and/or with the affiliation(s) listed, + have contributed to this proposal for a revised Process: + Brian Kardell, + Carine Bournez (W3C), + Charles McCathie Nevile (ConsenSys), + Chris Needham (BBC), + Chris Wilson (Google), + David Singer (Apple), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Elika J. Etemad aka fantasai, + Fuqiao Xue (W3C), + Jeff Jaffe (W3C), + Jeffrey Yasskin (Google), + Kevin Fleming (Bloomberg), + Léonie Watson (The Paciello Group), + Mark Nottingham (Cloudflare), + Michael Champion (Microsoft), + Nigel Megitt (BBC), + Philippe Le Hégaret (W3C), + Ralph Swick (W3C), + Samuel Weiler (W3C), + Sandro Hawke (W3C), + Shawn Lawton Henry, + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Virginia Fournier (Apple), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

The editors are sorry for forgetting any names, + and grateful to those who have listened patiently to conversations about this document + without feeling a need to add more.

+

The following individuals contributed to the development of earlier versions of the Process: + Alex Russell (Google), + Andreas Tai (Institut fuer Rundfunktechnik), + Andrew Betts (Fastly), + Ann Bassetti (The Boeing Company), + Anne van Kesteren, + Art Barstow (Nokia, unaffiliated), + Bede McCall (MITRE), + Ben Wilson, + Brad Hill (Facebook), + Brian Kardell (JQuery), + Carine Bournez (W3C), + Carl Cargill (Netscape, Sun Microsystems, Adobe), + Chris Lilley (W3C), + Chris Wilson (Google), + Claus von Riegen (SAP AG), + Coralie Mercier (W3C), + Cullen Jennings (Cisco), + Dan Appelquist (Telefonica, Samsung), + Dan Connolly (W3C), + Daniel Dardailler (W3C), + Daniel Glazman (Disruptive Innovations), + David Baron (Mozilla), + David Fallside (IBM), + David Singer (Apple), + David Singer (IBM), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Don Brutzman (Web3D), + Don Deutsch (Oracle), + Eduardo Gutentag (Sun Microsystems), + Elika J. Etemad aka fantasai, + Florian Rivoal, + Fuqiao Xue (W3C), + Geoffrey Creighton (Microsoft), + Giri Mandyam (Qualcomm), + Gregg Kellogg, + Hadley Beeman, + Helene Workman (Apple), + Henri Sivonen (Mozilla), + Håkon Wium Lie (Opera Software), + Ian Hickson (Google), + Ian Jacobs (W3C), + Ivan Herman (W3C), + J Alan Bird (W3C), + Jay Kishigami 岸上順一 (NTT), + Jean-Charles Verdié (MStar), + Jean-François Abramatic (IBM, ILOG, W3C), + Jeff Jaffe (W3C), + Jim Bell (HP), + Jim Miller (W3C), + Joe Hall (CDT), + John Klensin (MCI), + Josh Soref (BlackBerry, unaffiliated), + Judy Brewer (W3C), + Judy Zhu 朱红儒 (Alibaba), + Kari Laihonen (Ericsson), + Karl Dubost (Mozilla), + Ken Laskey (MITRE), + Kevin Fleming (Bloomberg), + Klaus Birkenbihl (Fraunhofer Gesellschaft), + Larry Masinter (Adobe Systems), + Lauren Wood (unaffiliated), + Liam Quin (W3C), + Léonie Watson (The Paciello Group), + Marcos Cáceres (Mozilla), + Maria Courtemanche (IBM), + Mark Crawford (SAP), + Mark Nottingham, + Michael Champion (Microsoft), + Michael Geldblum (Oracle), + Mike West (Google), + Mitch Stoltz (EFF), + Natasha Rooney (GSMA), + Nigel Megitt (BBC), + Olle Olsson (SICS), + Ora Lassila (Nokia), + Paul Cotton (Microsoft), + Paul Grosso (Arbortext), + Peter Linss, + Peter Patel-Schneider, + Philippe Le Hégaret (W3C), + Qiuling Pan (Huawei), + Ralph Swick (W3C), + Renato Iannella (IPR Systems), + Rigo Wenning (W3C), + Rob Sanderson (J Paul Getty Trust), + Robin Berjon (W3C), + Sally Khudairi (W3C), + Sam Ruby (IBM), + Sam Sneddon, + Sandro Hawke (W3C), + Sangwhan Moon (Odd Concepts), + Scott Peterson (Google), + Steve Holbrook (IBM), + Steve Zilles (Adobe Systems) + Steven Pemberton (CWI), + TV Raman (Google), + Tantek Çelik (Mozilla), + Terence Eden (Her Majesty’s Government), + Thomas Reardon (Microsoft), + Tim Berners-Lee (W3C), + Tim Krauskopf (Spyglass), + Travis Leithead (Microsoft), + Virginia Fournier (Apple), + Virginie Galindo (Gemalto), + Wayne Carr (Intel), + Wendy Fong (Hewlett-Packard), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

13. Changes

+

This section is non-normative.

+

Changes since the 12 June 2023 Process

+

This document is based on the 12 June 2023 Process. + A list of issues addressed, + a diff from Process 2023 to this latest version, + as well as + a detailed log of all changes since then are available.

+

The only change is:

+ +

Changes since earlier versions

+

Changes since earlier versions of the Process are detailed + in the changes section of the previous version of the Process.

+
+
+

Conformance

+

Document conventions

+

Conformance requirements are expressed + with a combination of descriptive assertions + and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text + with class="example", + like this:

+
+ +

This is an example of an informative example.

+
+

Informative notes begin with the word “Note” + and are set apart from the normative text + with class="note", + like this:

+

Note, this is an informative note.

+
+ +
+

Index

+

Terms defined by this specification

+ +

Terms defined by reference

+ +

References

+

Normative References

+
+
[CEPC] +
W3C Code of Ethics and Professional Conduct. URL: https://www.w3.org/Consortium/cepc/ +
[COLLABORATORS-AGREEMENT] +
Invited expert and collaborators agreement. URL: https://www.w3.org/Consortium/Legal/collaborators-agreement +
[CONFLICT-POLICY] +
Conflict of Interest Policy for W3C Team Members Engaged in Outside Professional Activities. URL: https://www.w3.org/2000/09/06-conflictpolicy +
[DOC-LICENSE] +
W3C Document License. URL: https://www.w3.org/Consortium/Legal/copyright-documents +
[PATENT-POLICY] +
The W3C Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy/ +
[PATENT-POLICY-2004] +
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/ +
[PATENT-POLICY-2020] +
The W3C 2020 Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy-20200915/ +
[PUBRULES] +
Publication Rules. URL: https://www.w3.org/pubrules/ +
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
[RFC3797] +
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://www.rfc-editor.org/rfc/rfc3797 +
[W3C-PATENT-POLICY] +
Wendy Seltzer. W3C Patent Policy. 15 September 2020. URL: https://www.w3.org/Consortium/Patent-Policy/ +
+

Informative References

+
+
[AB-HP] +
The Advisory Board home page. URL: https://www.w3.org/2002/ab/ +
[AC-MEETING] +
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/Member/Meeting/ +
[BG-CG] +
Community and Business Group Process. URL: https://www.w3.org/community/about/process/ +
[BYLAWS] +
Amended and Restated Bylaws of World Wide Web Consortium, Inc.. URL: https://www.w3.org/2022/10/w3c-bylaws-20221019.pdf +
[CALENDAR] +
Calendar of all scheduled official W3C events. URL: https://www.w3.org/participate/eventscal +
[CHAIR] +
W3C Working/Interest Group Chair. URL: https://www.w3.org/Guide/chair/role.html +
[CHARTER] +
How to Create a Working Group or Interest Group. URL: https://www.w3.org/Guide/process/charter.html +
[COUNCIL-REPORT-INDEX] +
Council Report Index. URL: https://www.w3.org/about/council/ +
[CURRENT-AC] +
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList +
[DECISION-APPEAL] +
Appealing a W3C Decision. URL: https://www.w3.org/Guide/process/ac-appeal +
[ELECTION-HOWTO] +
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/2002/10/election-howto +
[FELLOWS] +
W3C Fellows Program. URL: https://www.w3.org/Consortium/Recruitment/Fellows +
[GROUP-MAIL] +
Group mailing lists. URL: https://www.w3.org/groups/ +
[GUIDE] +
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/Guide/ +
[INTRO] +
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro +
[JOIN] +
How to Join W3C. URL: https://www.w3.org/Consortium/join +
[LIAISON] +
W3C liaisons with other organizations. URL: https://www.w3.org/2001/11/StdLiaison +
[MEMBER-AGREEMENT] +
W3C Membership Agreement. URL: https://www.w3.org/Consortium/Agreement/Member-Agreement +
[MEMBER-HP] +
Member website (Member-only access). URL: https://www.w3.org/Member/ +
[MEMBER-LIST] +
The list of current W3C Members. URL: https://www.w3.org/Consortium/Member/List +
[MEMBER-SUB] +
How to send a Submission request. URL: https://www.w3.org/2000/09/submission +
[MISSION] +
The W3C Mission statement. URL: https://www.w3.org/Consortium/mission +
[OBS-RESC] +
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/2016/11/obsoleting-rescinding/ +
[REC-TIPS] +
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/2002/05/rec-tips +
[REPUBLISHING] +
In-place modification of W3C Technical Reports. URL: https://www.w3.org/2003/01/republishing/ +
[SUBMISSION-LIST] +
The list of acknowledged Member Submissions. URL: https://www.w3.org/Submission/ +
[SUBMISSION-REQ] +
Make or Withdraw a Member Submission Request (Member-only access). URL: https://www.w3.org/2000/09/submission +
[TAG-CHARTER] +
Technical Architecture Group (TAG) Charter. URL: https://www.w3.org/2004/10/27-tag-charter.html +
[TAG-HP] +
The TAG home page. URL: https://www.w3.org/2001/tag/ +
[TEAM-CONTACT] +
Role of the Team Contact. URL: https://www.w3.org/Guide/teamcontact/role.html +
[TR] +
The W3C technical reports index. URL: https://www.w3.org/TR/ +
[TRANSITION] +
Organize a Technical Report Transition. URL: https://www.w3.org/Guide/transitions +
[TRANSLATION] +
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/ +
[W3C-IPR] +
W3C IPR Policies. URL: https://www.w3.org/Consortium/Legal/2002/ipr-notice-20021231 +
+ + + + diff --git a/snapshots/2025-05.html b/snapshots/2025-05.html new file mode 100644 index 00000000..29eb4923 --- /dev/null +++ b/snapshots/2025-05.html @@ -0,0 +1,6483 @@ + + + + + W3C Process Document + + + + + + + + + + + + + + + + + + +
+

+

W3C Process Document

+

Draft Community Group Report,

+
+ More details about this document +
+
+
This version: +
https://www.w3.org/policies/process/drafts/snapshots/2025-05 +
Editor’s Draft: +
https://www.w3.org/policies/process/drafts/ +
Latest published version: +
https://www.w3.org/policies/process/ +
Previous Versions: +
+
Feedback: +
Github (preferred) +
Public mailing list +
Member-only mailing list +
Editors: +
Elika J. Etemad / fantasai (Apple) +
Florian Rivoal (Invited Expert) +
Former Editors: +
Natasha Rooney (Invited Expert) +
Charles McCathie Nevile (Yandex) +
Ian Jacobs (W3C) +
+
+
+
+

Copyright © 2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

+
+
+
+

Abstract

+

The mission of the World Wide Web Consortium (W3C) is making the web work, for everyone. +W3C brings together global stakeholders to develop open standards that enable a World Wide Web that connects and empowers humanity. +The W3C Process Document describes the organizational structure of W3C and processes, +responsibilities and functions that enable W3C to accomplish its mission. +This document does not describe the internal workings of the Team.

+

For more information about the W3C mission and the history of W3C, +please refer to About W3C.

+
+

Status of this document

+
+

W3C, including all existing chartered groups, + follows the most recent operative Process Document announced to the Membership.

+

This document is developed by the Advisory Board’s Process Task Force + working within the W3C Process Community Group (which anyone can join). + This is a snaposhot of the Draft Community Group Report for the proposed next version of the W3C Process Document, + taken on the 19 May 2025, + to serve as the basis for informal and wide review.

+

This document, +which is based on the 3 November 2023 Process, +is a work in progress +and further changes may occur before completion of this revision cycle. +As detailed in Section 11 Process Changes, +once the W3C Advisory Board considers it ready for adoption, +it will be offered for W3C Advisory Committee Review.

+

A history of substantial changes from previous versions of the Process Document is provided.

+
+
+ +
+

Relation of Process Document to Patent Policy and Other Policies

+

W3C Members' attention is called to the fact + that provisions of the Process Document are binding on Members + per their Membership Agreement [MEMBER-AGREEMENT]. + The W3C Patent Policy [PATENT-POLICY] and other policies + incorporated by normative reference as a part of the Process Document + are equally binding.

+

The Patent Policy and Code of Conduct place additional obligations on Members, Team, and other participants in W3C. + The Process Document does not restate those requirements but includes references to them. + The Process Document, Patent Policy, and Code of Conduct have been designed to allow each to evolve independently.

+

In the Process Document, the term “participant” refers to an individual, not an organization.

+

Conformance and specialized terms

+

The terms must, must not, should, should not, required, + and may are used in accordance with RFC 2119. + The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

+

Some terms have been capitalized in this document (and in other W3C materials) + to indicate that they are entities with special relevance to the W3C Process. + These terms are defined within this document, + and readers are reminded that the ordinary English definitions are insufficient + for the purpose of understanding this document.

+ +
+

1. Introduction

+

W3C work revolves around the standardization of Web technologies. + To accomplish this work, W3C follows processes that promote the development of high-quality standards + based on the consensus of the Membership, Team, and public. + W3C processes promote fairness, responsiveness, and progress: + all facets of the W3C mission. + This document describes the processes W3C follows in pursuit of its mission.

+

The W3C Process promotes the goals of quality and fairness in technical decisions + by encouraging consensus, + soliciting reviews (by both Members and public), + incorporating implementation and interoperability experience, + and requiring Membership-wide approval as part of the technical report development process. Participants in W3C include representatives of its Members and the Team, + as well as Invited Experts who can bring additional expertise or represent additional stakeholders. Team representatives both contribute to the technical work + and help ensure each group’s proper integration with the rest of W3C.

+

W3C’s technical standards, called W3C Recommendations, + are developed by its Working Groups; + W3C also has other types of publications, + all described in § 6 W3C Technical Reports. + W3C has various types of groups; + this document describes the formation and policies + of its chartered Working Groups and Interest Groups, + see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. + W3C also operates Community and Business Groups, + which are separately described in their own process document [BG-CG].

+

In addition, several groups are formally established by the Consortium: + the W3C Advisory Committee, which has a representative from each Member, + and two oversight groups elected by its membership: + the Advisory Board (AB), + which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process; + and the Technical Architecture Group (TAG), + which helps resolve Consortium-wide technical issues.

+

Here is a general overview of how W3C initiates standardization of a Web technology:

+
    +
  1. People generate interest in a particular topic. + For instance, Members express interest by developing proposals in Community Groups + or proposing ideas in Member Submissions. + Also, the Team monitors work inside and outside of W3C for signs of interest, + and helps organize Workshops to bring people together + to discuss topics that interest the W3C community. +
  2. When there is enough interest and an engaged community, + the Team works with the Membership + to draft proposed Interest Group or Working Group charters. + W3C Members review the proposed charters, + and when there is support within W3C for investing resources in the topic of interest, + W3C approves the group(s), + and they begin their work. +
+

Further sections of this Process Document deal with topics including + liaisons (§ 8 Liaisons), + confidentiality (§ 7 Dissemination Policies), + and formal decisions and appeals (§ 5 Decisions).

+

2. Members and the Team

+

W3C’s mission is to lead the Web to its full potential. + W3C Member organizations provide resources to this end, + and the W3C Team provides the technical leadership + and organization to coordinate the effort.

+

2.1. Members

+

W3C Members are + organizations subscribed according to a Membership Agreement [MEMBER-AGREEMENT]. + They are represented in W3C processes as follows:

+
    +
  1. One representative per Member organization participates + in the Advisory Committee which oversees the work of W3C. +
  2. Representatives of Member organizations participate + in Working Groups and Interest Groups, + where they author and review technical reports. +
+

W3C membership is open to all entities, + as described in “How to Join W3C” [JOIN]; + (refer to the public list of current W3C Members [MEMBER-LIST]). + The Team must ensure + that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

+

While W3C does not have a class of membership tailored to individuals, + individuals may join W3C. + Restrictions pertaining to related Members apply + when the individual also represents another W3C Member.

+

2.1.1. Rights of Members

+

Each Member organization enjoys the following rights and benefits:

+ +

Furthermore, subject to further restrictions included in their Member Agreement, + representatives of Member organizations participate in W3C as follows:

+ +

The rights and benefits of W3C membership [MEMBER-AGREEMENT] are contingent upon conformance to the processes described in this document. + Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.

+

Additional information for Members is available at the Member website [MEMBER-HP].

+

2.1.2. Member Associations and Related Members

+
2.1.2.1. Membership Associations
+

A “Member Association” means a consortium, + user society, + or association of two or more individuals, + companies, + organizations or governments, + or any combination of these entities + which has the purpose of participating in a common activity + or pooling resources to achieve a common goal other than participation in, + or achieving certain goals in, + W3C. + A joint-stock corporation or similar entity is not a Member Association merely because it has shareholders or stockholders. + If it is not clear whether a prospective Member qualifies as a Member Association, + the CEO may reasonably make the determination. + For a Member Association, the rights and privileges of W3C Membership + described in the W3C Process Document extend to the Member Association’s paid staff + and Advisory Committee representative.

+

Member Associations may also designate + up to four (or more at the Team’s discretion) individuals + who, though not employed by the organization, may exercise the rights of Member representatives.

+

For Member Associations that have individual people as members, + these individuals must disclose their employment affiliation + when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For Member Associations that have organizations as Members, + all such designated representatives must be an official representative of the Member organization + (e.g. a Committee or Task Force Chairperson) + and must disclose their employment affiliation when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For all representatives of a Member Association, + IPR commitments are made on behalf of the Member Association, + unless a further IPR commitment is made by the individuals' employers.

+
2.1.2.2. Related Members
+

In the interest of ensuring the integrity of the consensus process, + Member involvement in some of the processes in this document is affected by related Member status. + As used herein, two Members are related if:

+
    +
  1. Either Member is a subsidiary of the other, or +
  2. Both Members are subsidiaries of a common entity, or +
  3. The Members have an employment contract or consulting contract that affects W3C participation. +
+

A subsidiary is an organization of which effective control and/or majority ownership rests with another, + single organization.

+

Related Members must disclose these relationships + according to the mechanisms described in the New Member Orientation [INTRO].

+

2.1.3. Good Standing

+

Members who have not lost Good Standing as defined in the Amended and Restated Bylaws of World Wide Web Consortium, Inc. are considered, for the purposes of this Process, + to be in Good Standing. + A group of related Members is in Good Standing if + at least one of them is in Good Standing.

+

2.2. The W3C Team

+

The Team consists of CEO, + W3C paid staff, + unpaid interns, + and W3C Fellows. W3C Fellows are Member employees working as part of the Team; + see the W3C Fellows Program [FELLOWS]. + The Team provides technical leadership about Web technologies, + organizes and manages W3C activities to reach goals + within practical constraints (such as resources available), + and communicates with the Members and the public + about the Web and W3C technologies.

+

The CEO may delegate responsibility + (generally to other individuals in the Team) + for any of their roles described in this document. Team Decisions derive from the CEO’s authority, + even when they are carried out by other members of the Team.

+

Oversight over the Team, + budgeting, + and other business decisions, + is provided by the W3C Board of Directors, + rather than managed directly by the Process.

+

Note: See the W3C Bylaws for more details + on the Board and overall governance of W3C.

+

3. Groups and Participation

+

For the purposes of this Process, a W3C Group is one of W3C’s Working Groups, Interest Groups, Advisory Committee, Advisory Board, + or TAG, + and a participant is a member of such a group.

+

3.1. Policies for Participation in W3C Groups

+

3.1.1. Individual Participation Criteria

+
3.1.1.1. Expectations and Discipline
+

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

+
    +
  1. Technical competence in one’s role; +
  2. The ability to act fairly; +
  3. Social competence in one’s role. +
+

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities + are responsible for assessing and attesting to the qualities of those nominees.

+

Participants in any W3C activity must abide + by the terms and spirit of the W3C Code of Conduct [COC] and the participation requirements described in + “Disclosure” + in the W3C Patent Policy [PATENT-POLICY].

+

The CEO may take disciplinary action, + including suspending or removing for cause + a participant in any group (including the AB and TAG) + if serious and/or repeated violations, + such as failure to meet the requirements on individual behavior of + (a) this process + and in particular the Code of Conduct, or + (b) the membership agreement, or + (c) applicable laws, + occur. + Refer to the Guidelines to suspend or remove participants from groups.

+
3.1.1.2. Conflict of Interest Policy
+

Individuals participating materially in W3C work must disclose significant relationships + when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. + These disclosures must be kept up-to-date + as the individual’s affiliations change and W3C membership evolves + (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). + Each section in this document that describes a W3C group + provides more detail about the disclosure mechanisms for that group.

+

The ability of an individual to fulfill a role within a group + without risking a conflict of interest depends on the individual’s affiliations. + When these affiliations change, + the individual’s assignment to the role must be evaluated. + The role may be reassigned according to the appropriate process. + For instance, + the Team may appoint a new group Chair when the current Chair changes affiliations + (e.g., if there is a risk of conflict of interest, + or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

+

The following are some scenarios where disclosure is appropriate:

+
    +
  • Paid consulting for an organization whose activity is relevant to W3C, + or any consulting compensated with equity + (shares of stock, stock options, or other forms of corporate equity). +
  • A decision-making role/responsibility + (such as participating on a Board) + in other organizations relevant to W3C. +
  • A position on a publicly visible advisory body, + even if no decision-making authority is involved. +
+

Individuals seeking assistance on these matters should contact the Team.

+

Team members are subject to the Conflict of Interest Policy for the W3C Team [CONFLICT-POLICY].

+
3.1.1.3. Individuals Representing a Member Organization
+

Generally, individuals representing a Member in an official capacity within W3C + are employees of the Member organization. + However, an Advisory Committee representative may designate a non-employee + to represent the Member. + Non-employee Member representatives must disclose + relevant affiliations to the Team and to any group in which the individual participates.

+

In exceptional circumstances + (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), + the CEO may decline + to allow an individual designated by an Advisory Committee representative to participate in a group.

+

A group charter may limit + the number of individuals representing a W3C Member + (or group of related Members).

+

3.1.2. Meetings

+

The requirements in this section apply to the official meetings of any W3C group, + as well as to official W3C meetings with open-ended participation from the Membership and/or the public, + such as Workshops.

+

W3C distinguishes two types of meetings:

+
    +
  1. A face-to-face meeting is one + where most of the attendees are expected to participate in the same physical location. +
  2. A distributed meeting is one + where most of the attendees are expected to participate from remote locations + (e.g., by telephone, video conferencing, or IRC). +
+

A Chair may invite an individual with a particular expertise + to attend a meeting on an exceptional basis. + This person is a meeting guest, + not a group participant. + Meeting guests do not have voting rights. + It is the responsibility of the Chair to ensure + that all meeting guests respect the chartered level of confidentiality and other group requirements.

+
3.1.2.1. Meeting Scheduling and Announcements
+

Meeting announcements should be sent to all appropriate group mailing lists, + i.e. those most relevant to the anticipated meeting participants.

+

The following table lists recommendations for organizing a meeting:

+ + + + + + + + + +
+ Face-to-face meetings + Distributed meetings +
Meeting announcement (before) + eight weeks* + one week* +
Agenda available (before) + two weeks + 24 hours (or longer if a meeting is scheduled after a weekend or holiday) +
Participation confirmed (before) + three days + 24 hours +
Action items available (after) + three days + 24 hours +
Minutes available (after) + two weeks + 48 hours +
+

* To allow proper planning (e.g., travel arrangements), + the Chair is responsible for giving sufficient advance notice + about the date and location of a meeting. + Shorter notice for a meeting is allowed + provided that there are no objections from group participants. + In the case of Workshops, + shorter notice is not allowed.

+
3.1.2.2. Meeting Minutes
+

Groups should take and retain minutes of their meetings, + and must record + any official group decisions made during the meeting discussions. + Details of the discussion leading to such decisions are not required, + provided that the rationale for the group decision is nonetheless clear.

+
3.1.2.3. Meeting Recordings and Transcripts
+

No-one may take an audio or video recording of a meeting, + or retain an automated transcript, + unless the intent is announced at the start of the meeting, + and no-one participating in the recorded portion of the meeting withholds consent. + If consent is withheld by anyone, recording/retention must not occur. + The announcement must cover: + (a) who will have access to the recording or transcript and + (b) the purpose/use of it and + (c) how it will be retained (e.g. privately, in a cloud service) and for how long.

+

3.1.3. Tooling and Archiving for Discussions and Publications

+

For W3C Groups operating under this Process, + a core operating principle is to allow access across disabilities, + across country borders, + and across time. + Thus in order to allow all would-be participants to effectively participate, + to allow future participants and observers to understand the rationale and origins of current decisions, + and to guarantee long-lived access to its publications, + W3C requires that:

+
    +
  • All reports, publications, or other deliverables + produced by the group for public consumption + (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, + and backed up by W3C systems + such that if the underlying service is discontinued, + W3C can continue to serve such content without breaking incoming links + or other key functionality. +
  • All reports, publications, or other deliverables + produced by the group for public consumption should follow best practices for internationalization + and for accessibility to people with disabilities. + Network access to W3C-controlled domains may be assumed. +
  • + Official meeting minutes and other records of decisions made must be archived by W3C for future reference; + and other persistent text-based discussions + sponsored by the group, + pertaining to their work + and intended to be referenceable by all group members should be. + This includes discussions conducted over email lists + or in issue-tracking services + or any equivalent fora. + Materials referenced from discussions + and necessary to understand them + should be available at a stable URL, + at a level of confidentiality no stricter than the discussion minutes. +

    Note: The lack, or loss, of such archives does not by itself + invalidate an otherwise-valid decision.

    +
  • + Any tooling used by the group + for producing its documentation and deliverables + or for official group discussions should be usable + (without additional cost) + by all who wish to participate, + including people with disabilities, + to allow their effective participation. +

    Note: If a new participant joins who cannot use the tool, + this can require the Working Group to change its tooling + or operate some workaround.

    +
  • All tools and archives used by the group + for its discussions and recordkeeping should be documented + such that new participants and observers + can easily find the group’s tools and records. +
+

The Team is responsible for ensuring adherence to these rules + and for bringing any group not in compliance into compliance.

+

3.1.4. Resignation from a Group

+

A W3C Member or Invited Expert may resign from a group. + On written notification from an Advisory Committee representative + or Invited Expert + to the Team, + the Member and their representatives + or the Invited Expert + will be deemed to have resigned from the relevant group. + The Team must record the notification. + See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

+

3.2. The Advisory Committee (AC)

+

3.2.1. Role of the Advisory Committee

+

The Advisory Committee represents + the Members of W3C at large. + It is responsible for:

+ +

Advisory Committee representatives may initiate + an Advisory Committee Appeal of a W3C decision or Team’s decision.

+

See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

+

3.2.2. Participation in the Advisory Committee

+

The Advisory Committee is composed of one representative from each Member organization + (refer to the Member-only list + of current Advisory Committee representatives. [CURRENT-AC])

+

When an organization joins W3C + (see “How to Join W3C” [JOIN]), + it must name its Advisory Committee representative as part of their Membership Agreement. + The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, + provides information about Advisory Committee Meetings, + explains how to name a new Advisory Committee representative, + and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.

+

The AC representative may delegate any of their rights and responsibilities + to an alternate (except the ability to designate an alternate).

+

3.2.3. Advisory Committee Mailing Lists

+

The Team must provide two mailing lists for use by the Advisory Committee:

+
    +
  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. + This list is read-only for Advisory Committee representatives. +
  2. One for discussion among Advisory Committee representatives. + Though this list is primarily for Advisory Committee representatives, + the Team must monitor discussion + and should participate in discussion when appropriate. + Ongoing detailed discussions should be moved to other appropriate lists + (new or existing, such as a mailing list created for a Workshop). +
+

An Advisory Committee representative may request + that additional individuals from their organization be subscribed to these lists. + Failure to contain distribution internally may result in suspension of additional email addresses, + at the discretion of the Team.

+

3.2.4. Advisory Committee Meetings

+

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. + The Team appoints the Chair of these meetings (generally the CEO). + At each Advisory Committee meeting, + the Team should provide an update to the Advisory Committee about:

+
+
Resources +
+
    +
  • The number of W3C Members at each level. +
  • An overview of the financial status of W3C. +
+
Allocations +
+
    +
  • The allocation of the annual budget, including size of the Team and their approximate deployment. +
  • A list of all activities (including but not limited to Working and Interest Groups) + and brief status statement about each, + in particular those started or terminated since the previous Advisory Committee meeting. +
  • The allocation of resources to pursuing liaisons with other organizations. +
+
+

Each Member organization should send one representative to each Advisory Committee Meeting. + In exceptional circumstances + (e.g., during a period of transition between representatives from an organization), + the meeting Chair may allow a Member organization to send two representatives to a meeting.

+

The Team must announce the date and location of each Advisory Committee meeting + no later than at the end of the previous meeting; one year’s notice is preferred. + The Team must announce the region of each Advisory Committee meeting + at least one year in advance.

+

More information about Advisory Committee meetings [AC-MEETING] is available at the Member website.

+

3.3. Elected Groups: The AB and the TAG

+

The W3C Process defines two types of elected groups: + the Advisory Board (AB) and + the Technical Architecture Group (TAG), + both elected by the Advisory Committee.

+

3.3.1. Advisory Board (AB)

+
3.3.1.1. Role of the Advisory Board
+

The Advisory Board provides ongoing guidance to the Team + on issues of strategy, + management, + legal matters, + process, + and conflict resolution. + The Advisory Board also serves the Members + by tracking issues raised between Advisory Committee meetings, + soliciting Member comments on such issues, + and proposing actions to resolve these issues. + The Advisory Board manages the evolution of the Process Document. + As part of a W3C Council, + members of the Advisory Board hear and adjudicate on Submission Appeals and Formal Objections.

+

The Advisory Board is distinct from the Board of Directors and has no decision-making authority within W3C; + its role is strictly advisory.

+

Note: While the AB as such does not have decision-making authority, + its members do when sitting as part of a W3C Council.

+

Details about the Advisory Board + (e.g., the list of Advisory Board participants, + mailing list information, and summaries of Advisory Board meetings) + are available at the Advisory Board home page [AB-HP].

+
3.3.1.2. Composition of the Advisory Board
+

The Advisory Board consists of nine to eleven elected participants and one Chair + (who may be one of the elected participants). + With the input of the AB, + the Team appoints the Chair, + who should choose a co-chair among the elected participants. + Upon appointment, + the Chair(s) are subject to ratification by secret ballot, + requiring approval by two thirds of the elected participants. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The team also appoints a Team Contact, + as described in § 3.4.1 Requirements for All Chartered Groups. + The CEO and Team Contact have a standing invitation + to all regular Advisory Board sessions.

+

The nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

+

The terms of elected Advisory Board participants are for two years. + Terms are staggered so that each year, + either five or six terms expire. + If an individual is elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular Advisory Board terms begin on 1 July and end on 30 June.

+
3.3.1.3. Communications of the Advisory Board
+

The Team must make available a mailing list, + confidential to the Advisory Board and Team, + for the Advisory Board to use for its communication.

+

The Advisory Board should send a summary of each of its meetings + to the Advisory Committee and other group Chairs. + The Advisory Board should also report on its activities + at each Advisory Committee meeting.

+
3.3.1.4. Liaisons between the Advisory Board and the Board of Directors
+

To ensure good communication between the AB and the Board of Directors and facilitate operational and management consistency, + the AB may appoint up to two of its participants as liaisons to the Board. + Such appointees are expected to attend and participate in Board meetings + and access Board materials + as Non-voting Observers. [BYLAWS] They do not form part of the Board’s decision-making body, + and may be excluded from such participation + in accordance with applicable Board procedures.

+

The Advisory Board should reevaluate + who is assigned to this role + at least at the beginning of each term, + and may swap its appointees more frequently + as they deem appropriate.

+

3.3.2. Technical Architecture Group (TAG)

+
3.3.2.1. Role of the Technical Architecture Group
+

The mission of the TAG is stewardship of the Web architecture. + There are three aspects to this mission:

+
    +
  1. to document and build consensus around principles of Web architecture + and to interpret and clarify these principles when necessary; +
  2. to resolve issues involving general Web architecture brought to the TAG; +
  3. to help coordinate cross-technology architecture developments inside and outside W3C. +
+

As part of a W3C Council, + the members of the TAG hear and adjudicate on Submission Appeals and Formal Objections.

+

The TAG’s scope is limited to technical issues about Web architecture. + The TAG should not consider + administrative, + process, + or organizational policy issues of W3C, + which are generally addressed by + the W3C Advisory Committee, + Advisory Board, + and Team.

+

When the TAG votes to resolve an issue, + each TAG participant + (whether appointed, elected, or the Chair) + has one vote; + see also the general section on votes in this Process Document.

+

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) + are available at the TAG home page [TAG-HP].

+
3.3.2.2. Composition of the Technical Architecture Group
+

The TAG consists of:

+ +

Participants in the TAG choose by consensus their Chair or co-Chairs; + in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG. + The Chair or co-Chairs must be selected from the participants of the TAG. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The Team also appoints a Team Contact [TEAM-CONTACT] for the TAG, + as described in § 3.4.1 Requirements for All Chartered Groups.

+

The terms of TAG participants last for two years. + Terms are staggered so that four elected terms + and either one or two appointed terms expire each year. + If an individual is appointed or elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular TAG terms begin on 1 February and end on 31 January.

+
3.3.2.3. Communications of the Technical Architecture Group
+

The Team must make available two mailing lists for the TAG:

+
    +
  • a public discussion (not just input) list for issues of Web architecture. + The TAG will conduct its public business on this list. +
  • a Member-only list for discussions within the TAG + and for requests to the TAG that, + for whatever reason, cannot be made on the public list. +
+

The TAG may also request the creation of additional topic-specific, public mailing lists. + For some TAG discussions (e.g., a Submission Appeal), + the TAG may use a list that will be Member-only.

+

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. + The TAG should also report on its activities at each Advisory Committee meeting.

+

3.3.3. Participation in Elected Groups

+
3.3.3.1. Expectations for Elected Groups Participants
+

Advisory Board and TAG participants have a special role within W3C: + they are elected by the Membership and appointed by the Team with the expectation that they will use their best judgment + to find the best solutions for the Web, + not just for any particular network, + technology, + vendor, + or user. + Advisory Board and TAG participants are expected to participate regularly and fully. + Advisory Board and TAG participants should attend Advisory Committee meetings.

+

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, + to serve the needs of the W3C membership as a whole, + and the Web community. + Whether they are Member representatives or Invited Experts, + their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

+

An individual participates on the Advisory Board or TAG + from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). + Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, + their participation does carry the responsibilities associated with Member representation, + Invited Expert status, + or Team representation + (as described in the section on the AB/TAG nomination and election process).

+

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, + and a participant’s seat must not be delegated to any other person.

+
3.3.3.2. Elected Groups Participation Constraints
+

Given the few seats available on the Advisory Board and the TAG, + and in order to ensure that the diversity of W3C Members is represented:

+ +
3.3.3.3. Advisory Board and Technical Architecture Group Elections
+

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, + using a Single Transferable Vote system. + An election begins when the Team sends a Call for Nominations to the Advisory Committee. + Any Call for Nominations specifies the minimum and maximum number of available seats, + the deadline for nominations, + details about the specific vote tabulation system selected by the Team for the election, + and operational information such as how to nominate a candidate. + The Team may modify the tabulation system after the Call for Nominations + but must stabilize it no later than the Call for Votes. + The Team announces appointments + after the results of the election are known, + and before the start of the term, + as described in § 3.3.3.4 Technical Architecture Group Appointments.

+

In the case of regularly scheduled elections of the TAG, + the minimum and maximum number of available seats are the same: + the 4 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

+

In the case of regularly scheduled elections of the AB, + the minimum and maximum number of available seats differ: + The maximum number is the 5 or 6 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; + the minimum number is such that when added to the occupied seats from the prior year, + the minimum size of the AB (9) is reached.

+

Each Member (or group of related Members) may nominate one individual. + A nomination must be made with the consent of the nominee. + In order for an individual to be nominated as a Member representative, + the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination + the (same) information required for a Member representative in a Working Group. + In order for an individual to be nominated as an Invited Expert, + the individual must provide + the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. + In order for an individual to be nominated as a Team representative, + the nominating Advisory Committee representative must first secure approval from Team management. + A nominee is not required to be an employee of a Member organization, + and may be a W3C Fellow. + The nomination form must ask for the nominee’s primary affiliation, + and this will be reported on the ballot. + For most nominees, + the primary affiliation is their employer and will match their affiliation in the W3C database. + For contractors and invited experts, + this will normally be their contracting company + or their invited expert status; + in some cases + (e.g. where a consultant is consulting for only one organization) + this may be the organization for whom the nominee is consulting. + A change of affiliation is defined + such that this field would carry a different answer + if the nominee were to be re-nominated + (therefore, + terminating employment, + or accepting new employment, + are changes of affiliation). + (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) + Each nomination should include + a few informative paragraphs about the nominee. + If an identified candidate’s nomination information is only partially complete + as of the deadline for nominations, + the Team may allow extra time for that candidate’s nomination to be completed, + so long as it does not delay the election as a whole.

+

If, after the deadline for nominations, the number of nominees is:

+
    +
  • Greater than or equal to the minimum number of available seats + and less than or equal to the maximum number of available seats, + those nominees are thereby elected. + This situation constitutes a tie for the purpose of assigning incomplete terms. + Furthermore, if the number is less than the maximum number of available seats, + the longest terms are filled first. +
  • Less than the minimum number of available seats, + Calls for Nominations are issued until a sufficient number of people have been nominated. + Those already nominated do not need to be renominated after a renewed call. +
  • Greater than the maximum number of available seats, + the Team issues a Call for Votes + that includes the names of all candidates, + the (maximum) number of available seats, + the deadline for votes, + details about the vote tabulation system selected by the Team for the election, + and operational information. +
+

When there is a vote, + each Member in Good Standing (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. + Once the deadline for votes has passed, + the Team announces the results to the Advisory Committee. + In case of a tie the verifiable random selection procedure described below + will be used to fill the available seats.

+

The shortest incomplete term is assigned to the elected candidate ranked lowest by the tabulation of votes, + the next shortest term to the next-lowest ranked elected candidate, + and so on. + In the case of a tie among those eligible for a incomplete term, + the verifiable random selection procedure described below + will be used to assign the incomplete term.

+

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

+
3.3.3.4. Technical Architecture Group Appointments
+

The Team is responsible for appointing + 3 of the participants to the Technical Architecture Group. + This mechanism complements the election process. + The Team should use its appointments to support + a diverse and well-balanced TAG, + including diversity of technical background, knowledge, and skill sets.

+

The Team should actively seek + candidates for appointment to the TAG, + and must make available to + the W3C community at large + a means to propose candidates for consideration, + explicitly soliciting input from at least + current and incoming TAG members, the Advisory Committee, and Working Group Chairs.

+

The constraints for appointment to the TAG are + the same as for elected participants + (see § 3.3.3.2 Elected Groups Participation Constraints and § 3.3.3.3 Advisory Board and Technical Architecture Group Elections), + with the additional constraint that + a person must not be appointed + for more than two consecutive terms. + (Partial terms used to fill a vacated seat do not count towards this limit.)

+

Note: Since there are no limits on elected terms, + this limit on appointed terms does not constrain + term-limited appointees + from running for election at any time.

+

The Team’s choice of appointee(s) + is subject to ratification by secret ballot + by both the AB and the TAG, + requiring a two-thirds approval from each. + In the case of regularly scheduled elections, + the TAG participants in this ratification are + its members for the upcoming term.

+

For regularly scheduled elections, + selection begins once the results of the elections are known, + and the Team should announce the ratified appointment(s) + no later than the start of the regularly scheduled term. + When an appointed seat is vacated outside of a regularly scheduled election, + the Team should seek to appoint a replacement + unless a regular Call for Nominations is scheduled within 2 months, + and it must announce the ratified appointment + no later than the Call for Nominations of the next scheduled election.

+
3.3.3.5. Verifiable Random Selection Procedure
+

When it is necessary to use a verifiable random selection process + (e.g., in an AB or TAG election, + to “draw straws” in case of a tie + or to fill a incomplete term), + W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. + The procedure orders an input list of names + (listed in alphabetical order by family name unless otherwise specified) + into a “result order”.

+

W3C applies this procedure as follows:

+
    +
  1. When N people have tied for M (less than N) seats. + In this case, only the names of the N individuals who tied + are provided as input to the procedure. + The M seats are assigned in result order. +
  2. After all elected individuals have been identified, + when N people are eligible for M (less than N) incomplete terms. + In this case, only the names of those N individuals are provided as input to the procedure. + The incomplete terms are assigned in result order. +
+
3.3.3.6. Elected Groups Vacated Seats
+

An Advisory Board or TAG participant’s seat is vacated when:

+ +

If a participant changes affiliation, + but the participation constraints are met, + that participant’s seat becomes vacant at the next regularly scheduled election for that group.

+

Vacated seats are filled according to this schedule:

+
    +
  • When an appointed TAG seat is vacated, + the Team appoints a replacement. +
  • + When an elected seat on either the AB or TAG is vacated, + the seat is filled at the next regularly scheduled election for the group + unless the group Chair requests that W3C hold an election before then + (for instance, due to the group’s workload). +
      +
    • The group Chair should not request such an election + if the next regularly scheduled election is fewer than three months away. +
    • The group Chair may request an election, + and the election may begin, as soon as a current member gives notice of a resignation, + including a resignation effective as of a given date in the future. +
    +

    When such an election is held, + the minimum number of available seats is such that + when added to the number of continuing participants, + the minimum total number of elected seats is met + (8 for the TAG, 9 for the AB); + and the maximum number corresponds to all unoccupied seats. + Except for the number of available seats and the length of the terms, + the usual rules for Advisory Board and Technical Architecture Group Elections apply.

    +
+

3.4. Chartered Groups: Working Groups and Interest Groups

+

This document defines two types of chartered groups:

+
+
Working Groups. +
+ Working Groups typically produce deliverables + (e.g., Recommendation Track technical reports, + software, + test suites, + and reviews of the deliverables of other groups) + as defined in their charter. +

Working Groups have additional participation requirements + described in the W3C Patent Policy [PATENT-POLICY], + see particularly the “Licensing Obligations of Working Group Participants” + and the patent claim exclusion process + in “Exclusion From W3C RF Licensing Requirements”.

+
Interest Groups. +
+ The primary goal of an Interest Group + is to bring together people who wish to evaluate potential Web technologies and policies. + An Interest Group is a forum for the exchange of ideas. +

Interest Groups do not publish Recommendation Track technical reports; + but can publish technical reports on the Note Track.

+
+

3.4.1. Requirements for All Chartered Groups

+

Each group must have a charter. + Requirements for the charter depend on the group type. + All group charters must be public + (even if other proceedings of the group are Member-only).

+

Each group must have a Chair (or co-Chairs) + to facilitate effective discussion and coordinate the group’s activities. + The Team appoints (and re-appoints) Chairs for all groups. + The Chair is a Member representative, + a Team representative, + or an Invited Expert (invited by the Team). + The requirements of this document that apply to those types of participants apply to Chairs as well.

+

Note: The role of the Chair [CHAIR] is described + in the Art of Consensus [GUIDE].

+

Each group must have a Team Contact, + who acts as the interface between the Chair, + group participants, + and the rest of the Team.

+

Note: The role of the Team Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE].

+

The Chair and the Team Contact of a group should not be the same individual.

+

Each group must have an archived mailing list + for formal group communication + (e.g., for meeting announcements and minutes, + documentation of decisions, + and Formal Objections to decisions). + It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists. + Refer to the list of group mailing lists [GROUP-MAIL].

+

A Chair may form task forces + (composed of group participants) + to carry out assignments for the group. + The scope of these assignments must not exceed the scope of the group’s charter. + A group should document the process it uses + to create task forces + (e.g., each task force might have an informal "charter"). + Task forces do not publish technical reports; + the Working Group may choose to publish their results as part of a technical report.

+

3.4.2. Participation in Chartered Groups

+

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, + and Team representatives (including the Team Contact).

+

There are four types of individual participants in an Interest Group: + the same three types as for Working Groups plus, + for an Interest Group where the only participation requirement is mailing list subscription, public participants.

+

Except where noted in this document or in a group charter, + all participants share the same rights and responsibilities in a group; + see also the individual participation criteria.

+

A participant may represent more than one organization + in a Working Group or Interest Group. + Those organizations must all be members of the group.

+

An individual may become + a Working or Interest Group participant + at any time during the group’s existence. + See also relevant requirements in + “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY].

+

On an exceptional basis, + a Working or Interest Group participant may designate + a substitute to attend a meeting and should inform the Chair. + The substitute may act on behalf of the participant, + including for votes. + For the substitute to vote, + the participant must inform the Chair in writing in advance.

+

To allow rapid progress, + Working Groups are intended to be small + (typically fewer than 15 people) + and composed of experts in the area defined by the charter. + In principle, + Interest Groups have no limit on the number of participants. + When a Working Group grows too large to be effective, + W3C may split it into an Interest Group + (a discussion forum) + and a much smaller Working Group + (a core group of highly dedicated participants).

+

3.4.3. Types of Participants in Chartered Groups

+
3.4.3.1. Member Representative in a Working Group
+

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Advisory Committee representative of the Member in question + has designated the individual as a Working Group participant, and +
  • the individual qualifies for Member representation. +
+

To designate an individual as a Member representative in a Working Group, + an Advisory Committee representative must provide the Chair and Team Contact with all of the following information, + in addition to any other information required by the Call for Participation and charter + (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

+
    +
  1. The name of the W3C Member the individual represents + and whether the individual is an employee of that Member organization; +
  2. A statement that the individual accepts the participation terms + set forth in the charter + (with an indication of charter date or version); +
  3. A statement that the Member will provide the necessary financial support for participation + (e.g., for travel, telephone calls, and conferences). +
+

A Member participates in a Working Group from the moment the first Member representative joins the group + until either of the following occurs:

+
    +
  • the group closes, or +
  • the Member resigns from the Working Group; + this is done through the Member’s Advisory Committee representative. +
+
3.4.3.2. Member Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

+ +

To designate an individual as a Member representative in an Interest Group, + the Advisory Committee representative must follow the instructions + in the Call for Participation and charter.

+

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

+
3.4.3.3. Invited Expert in a Working Group
+

The Chair may invite an individual with a particular expertise + to participate in a Working Group. + This individual may represent an organization in the group + (e.g., if acting as a liaison with another organization).

+

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Chair has designated the individual as a group participant, +
  • the Team Contact has agreed with the Chair’s choice, and +
  • the individual has provided the information required of an Invited Expert to the Chair and Team Contact. +
+

To designate an individual as an Invited Expert in a Working Group, + the Chair must inform the Team Contact + and provide rationale for the choice. + When the Chair and the Team Contact disagree about a designation, + the CEO determines + whether the individual will be invited to participate in the Working Group.

+

To participate in a Working Group as an Invited Expert, + an individual must:

+
    +
  • identify the organization, if any, the individual represents as a participant in this group, +
  • agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT], +
  • accept the participation terms set forth in the charter, + including the participation requirements of + the W3C Patent Policy [PATENT-POLICY], + especially in “Note on Licensing Commitments for Invited Experts” + and in “Disclosure”, + indicating a specific charter date or version, +
  • disclose whether the individual is an employee of a W3C Member; + see the conflict of interest policy, +
  • provide a statement of who will provide the necessary financial support + for the individual’s participation + (e.g., for travel, telephone calls, and conferences), and +
  • if the individual’s employer (including a self-employed individual) + or the organization the individual represents + is not a W3C Member, + indicate whether that organization intends to join W3C. + If the organization does not intend to join W3C, + indicate reasons the individual is aware of for this choice. +
+

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. + The Chair must not use Invited Expert status + to circumvent participation limits imposed by the charter.

+

An Invited Expert participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • the Chair or CEO withdraws the invitation to participate, or +
  • the individual resigns. +
+
3.4.3.4. Invited Expert in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

+
3.4.3.5. Team Representative in a Working Group
+

An individual is a Team representative in a Working Group when so designated by W3C management. + Team representatives both contribute to the technical work + and help ensure the group’s proper integration with the rest of W3C.

+

A Team representative participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • W3C management changes Team representation by sending email to the Chair, + copying the group mailing list. +
+

The Team participates in a Working Group + from the moment the creation of the group is announced + until the group closes.

+
3.4.3.6. Team Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Team representative in an Interest Group when so designated by W3C management.

+

4. Lifecycle of Chartered Groups

+

W3C creates charters for chartered groups based on W3C community interest. + W3C fosters awareness of charters, + improves their quality, + and gauges Membership support in two formal phases:

+ +

4.1. Initiating Charter Refinement

+

Charters can originate in many venues, + including existing Working or Interest Groups, + Community Groups, + and from the Membership. + Prior to the formal refinement phase, + the Team engages with those various parties + to help prepare charters for broader audiences.

+

Formal charter refinement (see below) is initiated + by the Team sending a charter review notice to the Advisory Committee, + to the public, + and, in the case of rechartering, to the affected Group.

+

This charter review notice must include:

+
    +
  • +

    A short summary of the proposal.

    +
  • +

    The location of the charter draft, which must be public.

    +
  • +

    How to participate in the discussion of this charter draft and where to file issues.

    +
  • +

    The expected duration of the charter refinement phase, +which must not be less than 28 days, +and should not be more than 6 months.

    +
  • +

    Who the Chartering Facilitator is.

    +
+

The Team is responsible for initiating charter refinement at its discretion, in consideration of discussions with the community.

+

An Advisory Committee representative may formally request + that the Team initiate charter refinement. + The Team may deny such a request + if it thinks the proposal is insufficiently mature, + does not align with W3C’s scope and mission, + or otherwise does not meet the charter assessment criteria + described in the Guide (see How to Create a Working Group or Interest Group), + and must reply with its rationale. + This rejection is a Team Decision, + and can be appealed only by 5 or more Members, + through their Advisory Committee representative, + formally objecting to the decision within 8 weeks of the decision being announced. + In this case the Team must start an appeal vote on whether to overturn the Team Decision. + (No action is required to be taken when fewer than 5 members object.)

+

4.2. Charter Refinement

+

During charter refinement, + the W3C community, + under the guidance of the Team, + further develops the charter draft with the goal of achieving consensus on the proposal. + The Chartering Facilitator—​who is chosen (and may be replaced) by the Team—​is responsible for seeking community consensus among those participating in the refinement process + and making decisions reflecting that consensus. + In cases where consensus cannot be found, + the Chartering Facilitator may ask the Team to make a Team Decision, + and must document the rationale for the decision.

+

Note: The Chartering Facilitator is not necessarily the Chair of the group being chartered.

+

During charter refinement:

+ +

Before the end of the announced duration + for the charter refinement phase, + the Team (informed by the work of the Chartering Facilitator) must decide which of the following to do:

+
    +
  • +

    Complete charter refinement by initiating AC Review of the charter draft.

    +
  • +

    Abandon the proposal.

    +
  • +

    Extend the charter refinement period.

    +
+

The Team must announce its decision with the same visibility as the initial charter review notice, + and must include a rationale + if they are not initiating AC Review. + Reaching the end of the announced period (including any announced extension) + with no announced decision + is considered a de-facto Team decision to abandon the proposal. + The Team may revise such a decision + by announcing an alternative decision.

+

Formal Objections filed during the charter refinement phase + are specially handled:

+
    +
  • +

    Objections to decisions pertaining to the content of the charter, +as well as objections to initiating the AC Review, +are considered registered at the close of the Advisory Committee Review of the charter, +and are registered against that W3C Decision.

    +

    Note: This enables all Formal Objections on the same proposed charter to be handled together.

    +
  • +

    Objections to abandoning the proposal or to extending the refinement period can be appealed only if 5 or more Members, +through their Advisory Committee representative, +formally object to the decision within 8 weeks of the decision. +In this case, +the Team must do one of the following:

    +
      +
    • +

      Abide by the objectors' request, if they all agree on the +alternative course of action (e.g., to abandon, +extend, or complete charter refinement).

      +
    • +

      Initiate an AC Review to formally solicit the input of +the community and take a W3C Decision on the subsequent +course of action.

      +
    • +

      Convene a Council to decide the subsequent course of action.

      +
    +

    (No action is required to be taken when fewer than 5 members object.)

    +
  • +

    Any other objections are processed normally (See § 5.6 Addressing Formal Objections).

    +
+

4.3. Content of a Charter

+

A Working Group or Interest Group charter must include all of the following information.

+
    +
  • The group’s mission + (e.g., develop a technology or process, review the work of other groups). +
  • The scope of the group’s work and criteria for success. +
  • The duration of the proposed charter for the group. +
  • The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software). +
  • + Expected milestone dates where available. +

    Note: A charter does not need to include + schedules for review of other group’s deliverables.

    +
  • The process for the group to approve the release of deliverables + (including intermediate results). +
  • Any dependencies by groups within or outside of W3C on the deliverables of this group. + For any dependencies, the charter must specify + the mechanisms for communication about the deliverables. +
  • Any dependencies of this group on other groups within or outside of W3C. + Such dependencies include interactions with W3C Horizontal Groups [CHARTER]. +
  • The level of confidentiality of the group’s proceedings and deliverables. +
  • The name and affiliation of the Chair or co-Chairs. +
  • Meeting mechanisms and expected frequency. +
  • If known, + the date of the first face-to-face meeting. + The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal. +
  • Communication mechanisms to be employed within the group, + between the group and the rest of W3C, + and with the general public. +
  • Any voting procedures or requirements + other than those specified in § 5.2.3 Deciding by Vote. +
  • An estimate of the expected time commitment from participants. +
  • The expected time commitment and level of involvement by the Team + (e.g., to track developments, + write and edit technical reports, + develop code, + or organize pilot experiments). +
  • Intellectual property information. + What are the intellectual property (including patents and copyright) + considerations affecting the success of the Group? + In particular, is there any reason to believe + that it will be difficult to meet the Royalty-Free licensing goals + in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY]? +
+

See also the charter requirements in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

For every Recommendation Track deliverable + that continues work on a technical report published under any other Charter (including a predecessor group of the same name), + for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

+
    +
  • The title, + stable URL, + and publication date of the Working Draft or other Recommendation-track document + that will serve as the basis for work on the deliverable + (labeled “Adopted Draft”); +
  • The title, + stable URL, + and publication date of the document + that was used as the basis for its most recent Exclusion Opportunity + as per + the W3C Patent Policy [PATENT-POLICY]. + (labeled “Exclusion Draft”); and +
  • The stable URL of the Working Group charter + under which the Exclusion Draft was published + (labeled the “Exclusion Draft Charter”). +
+

All of the above data must be identified + in the adopting Working Group’s charter using the labels indicated.

+

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. + The proposed charter must state + the dates on which the Exclusion Opportunity + that arose on publishing the Exclusion Draft began and ended. + As per “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY], + this potentially means that exclusions can only be made immediately on joining a Working Group.

+

An Interest Group charter may include provisions regarding participation, + including specifying + that the only requirement for participation (by anyone) in + the Interest Group is subscription to the Interest Group mailing list. + This type of Interest Group may have public participants.

+

A charter may include + provisions other than those required by this document. + The charter should highlight + whether additional provisions impose constraints + beyond those of the W3C Process Document + (e.g., limits on the number of individuals in a Working Group + who represent the same Member organization or group of related Members).

+

4.4. Charter Review and Approval

+

4.4.1. New Charters and Major Changes

+

Any new charter (including re-chartering of existing chartered groups) + and any change that is not a minor change (per § 4.4.2 Minor Changes to Active Charters) to an already-approved charter of a Working Group or Interest Group must be approved by a W3C Decision following an AC Review of that charter. + Modifications to a charter should have the consensus of the group.

+

The review period must be at least 28 days. + Any Advisory Committee representative may request an extended review period + in response to the Call for Review; + upon receipt of any such request, + the Team must extend the review period + to at least 60 days.

+

The Call for Review of a modified charter must highlight important changes + (e.g., regarding changes in scope, deliverables, or resource allocation) + and must include rationale for those changes.

+

The Call for Review of a new or modified charter must include a disposition of comments received during the charter refinement process, + highlighting any issues that were closed despite sustained objections.

+

4.4.2. Minor Changes to Active Charters

+

Editorial changes or substantive changes to a charter (including extensions) + that do not affect the scope of the group’s work + or the way the group functions in any significant way + are deemed minor changes and may be approved by a Team Decision, + in which case they do not require charter refinement nor Advisory Committee Review. + Any change to the scope of the charter or addition of a new REC track deliverable + that does not fall within the scope of an existing deliverable + is a major, not minor, change. + The following are examples of minor changes: + the renaming or restructuring (e.g. splitting or combining) of existing in-scope deliverables, + the addition of new Note track deliverables that help explain the group’s work + a change of Team Contact, + or a change of Chair. Minor changes, other than a change of Team Contact, should have the consensus of the group.

+

The Team may nevertheless choose + to initiate charter refinement and/or Advisory Committee Review when it thinks the changes would benefit from more scrutiny or explicit buy-in.

+

Though Advisory Committee Review is not required, + such changes must still be announced + to the Advisory Committee, + and to participants in the Working or Interest Group, + and a rationale must be provided.

+

4.5. Call for Participation in a Chartered Group

+

Deciding whether to adopt a proposed Working Group or Interest Group charter is a W3C Decision. + Charters may be amended based on review comments + per § 5.7.2 Determining the W3C Decision before the Call for Participation.

+

If the decision is to charter the group, + the Team must issue a Call for Participation to the Advisory Committee. + For a new group, this announcement officially creates the group. + The announcement must include a reference to the charter, + the name(s) of the group’s Chair(s), + and the name(s) of the Team Contact(s).

+

After a Call for Participation, + any Member representatives and Invited Experts must be designated (or re-designated). + When a group is re-chartered, + individuals participating in the Working Group or Interest Group before the new Call for Participation + may attend any meetings held within forty-five (45) days of the Call for Participation + even if they have not yet formally rejoined the group + (i.e., committed to the terms of the charter and patent policy).

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against the decision to create + or substantially modify + a Working Group or Interest Group charter.

+

4.6. Charter Extension

+

The Team may decide + to extend a Working Group or Interest Group charter + with no other substantive modifications. + The Team must announce + such extensions to the Advisory Committee. + The announcement must indicate the new duration. + The announcement must also include rationale for the extension, + a reference to the charter, + and the Group homepage + (which includes at least + the name(s) of the group’s Chair(s), + the name of the Team Contact, + and instructions for joining the group).

+

After a charter extension, + Advisory Committee representatives + and the Chair are not required to re-designate Member representatives and Invited Experts.

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.

+

4.7. Chartered Group Closure

+

A Working Group or Interest Group charter specifies a duration for the group.

+

The Team, the TAG, or the AB may propose to close a group + prior to the date specified in the charter in any of the following circumstances:

+
    +
  • +

    There are insufficient member resources to produce chartered deliverables +or to maintain the group, +according to priorities established within W3C.

    +
  • +

    A Patent Advisory Group concluded that the work should be terminated.

    +
  • +

    The TAG or AB determined that continuing operation of the chartered group or its work +would be detrimental to W3C or its mission.

    +
  • +

    The group produced all chartered deliverables ahead of schedule.

    +
+

Such a proposal to close a group must be accompanied by rationale, + and the proposal must be confirmed by an AC Review as a W3C Decision.

+

Closing a Working Group has implications + with respect to the W3C Patent Policy [PATENT-POLICY].

+

5. Decisions

+

W3C attempts to resolve issues through dialog. + Individuals who disagree strongly with a decision should register with the Chair any Formal Objections.

+

5.1. Types of Decisions

+

The Chair of a Working Group or Interest Group has the prerogative + to make certain decisions based on their own judgment. + Such decisions are called chair decisions.

+

In contrast, + decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group + or following a vote (see § 5.2.3 Deciding by Vote) + are called group decisions (also known as group “resolutions”).

+

Decisions made by members of the Team in connection with this Process, + based on their own individual or collective judgement, + are called Team Decisions.

+

In contrast, + a W3C decision is + determined by the Team on behalf of the W3C community + by assessing the consensus of the W3C Community after an Advisory Committee review.

+

5.2. Consensus Building

+

5.2.1. Consensus

+

Consensus is a core value of W3C. + To promote consensus, + the W3C process requires Chairs to ensure + that groups consider all legitimate views and objections, + and endeavor to resolve them, + whether these views and objections are expressed by the active participants of the group + or by others + (e.g., another W3C group, + a group in another organization, + or the general public). + Decisions may be made during meetings + (face-to-face or distributed) + as well as through persistent text-based discussions.

+

The following terms are used in this document + to describe the level of support for a decision among a set of eligible individuals:

+
+
Consensus: +
A substantial number of individuals in the set + support the decision + and there is no sustained objection from anybody in the set. + Individuals in the set may abstain. + Abstention is either an explicit expression of no opinion + or silence by an individual in the set. +
Unanimity: +
The particular case of consensus where all individuals in the set support the decision + (i.e., no individual in the set abstains). +
Dissent: +
At least one individual in the set sustains an objection. +
+

Note: A Formal Objection always indicates a sustained objection, + but isn’t necessary to express it + (except in the context of formal AC Reviews). + Disagreement with a proposed decision, + however, does not always rise to the level of sustained objection, + as individuals could be willing to accept a decision + while expressing disagreement.

+

By default, the set of individuals eligible to participate in a decision is the set of group participants. + The Process Document does not require a quorum for decisions + (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). + A charter may include a quorum requirement for consensus decisions.

+

Where unanimity is not possible, + a group should strive to make consensus decisions + where there is significant support and few abstentions. + The Process Document does not require a particular percentage of eligible participants + to agree to a motion in order for a decision to be made. + To avoid decisions where there is widespread apathy, + (i.e., little support and many abstentions), + groups should set minimum thresholds of active support before a decision can be recorded. + The appropriate percentage may vary depending on the size of the group + and the nature of the decision. + A charter may include threshold requirements for consensus decisions. + For instance, a charter might require a supermajority of eligible participants + (i.e., some established percentage above 50%) + to support certain types of consensus decisions.

+
+ Note: Chairs have substantial flexibility + in how they obtain and assess consensus among their groups. + Unless otherwise constrained by charter, + they can use modes including but not limited to explicit calls for consensus, + polls of participants, + “lazy consensus” in which lack of objection after sufficient notice is taken as assent; + they can also delegate and empower a document editor + to assess consensus on their behalf, + whether in general + or for specific pre-determined circumstances + (e.g. in non-controversial situations, for specific types of issues, etc.). +

If questions or disagreements arise, + the final determination of consensus remains with the chair.

+
+

5.2.2. Managing Dissent

+

In some cases, even after careful consideration of all points of view, + a group might find itself unable to reach consensus. + The Chair may record a decision where there is dissent so that the group can make progress + (for example, to produce a deliverable in a timely manner). + Dissenters cannot stop a group’s work + simply by saying that they cannot live with a decision. + When the Chair believes that the Group has duly considered + the legitimate concerns of dissenters as far as is possible and reasonable, + the group should move on.

+

Groups should favor proposals that create the weakest objections. + This is preferred over proposals that are supported by a large majority + but that cause strong objections from a few people. + As part of making a decision where there is dissent, + the Chair is expected to be aware of which participants work for the same + (or related) + Member organizations and weigh their input accordingly.

+

Note: Dissenters can escalate their sustained objection to a decision by registering a Formal Objection.

+

5.2.3. Deciding by Vote

+

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, + and that a vote is necessary to break a deadlock. + In this case the Chair must record + (e.g., in the minutes of the meeting or in an archived email message):

+
    +
  • an explanation of the issue being voted on; +
  • the decision to conduct a vote + (e.g., a simple majority vote) to resolve the issue; +
  • the outcome of the vote; +
  • any Formal Objections. +
+

In order to vote to resolve a substantive issue, + an individual must be a group participant. + Each organization represented in the group must have at most one vote, + even when the organization is represented by several participants in the group + (including Invited Experts). + For the purposes of voting:

+
    +
  • A Member or group of related Members is considered a single organization. +
  • The Team is considered an organization. +
+

Unless the charter states otherwise, Invited Experts may vote.

+

If a participant is unable to attend a vote, + that individual may authorize anyone at the meeting + to act as a proxy. + The absent participant must inform the Chair in writing + who is acting as proxy, with written instructions on the use of the proxy. + For a Working Group or Interest Group, + see the related requirements regarding an individual + who attends a meeting as a substitute for a participant.

+

A group may vote for other purposes than to resolve a substantive issue. + For instance, the Chair often conducts a “straw poll” vote + as a means of determining whether there is consensus about a potential decision.

+

A group may also vote to make a process decision. + For example, + it is appropriate to decide by simple majority + whether to hold a meeting in San Francisco or San Jose + (there’s not much difference geographically). + When simple majority votes are used to decide minor issues, + voters are not required to state the reasons for votes, + and the group is not required to record individual votes.

+

A group charter may include formal voting procedures + (e.g., quorum or threshold requirements) + for making decisions about substantive issues.

+

5.3. Formally Addressing an Issue

+

In the context of this document, + a group has formally addressed an issue when it has sent a public, substantive response + to the reviewer who raised the issue. + A substantive response is expected to include rationale for decisions + (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). + The adequacy of a response is measured + against what a W3C reviewer would generally consider to be technically sound. + If a group believes that a reviewer’s comments result from a misunderstanding, + the group should seek clarification before reaching a decision.

+

As a courtesy, + both Chairs and reviewers should set expectations + for the schedule of responses and acknowledgments. + The group should reply to a reviewer’s initial comments + in a timely manner. + The group should set a time limit + for acknowledgment by a reviewer of the group’s substantive response; + a reviewer cannot block a group’s progress. + It is common for a reviewer to require a week or more + to acknowledge and comment on a substantive response. + The group’s responsibility to respond to reviewers + does not end once a reasonable amount of time has elapsed. + However, reviewers should realize + that their comments will carry less weight + if not sent to the group in a timely manner.

+

Substantive responses should be recorded. + The group should maintain an accurate summary + of all substantive issues and responses to them + (e.g., in the form of an issues list with links to mailing list archives).

+

5.4. Reopening a Decision When Presented With New Information

+

The Chair may reopen a decision + when presented with new information, including:

+
    +
  • additional technical information, +
  • comments by email from participants who were unable to attend a scheduled meeting, +
  • comments by email from meeting attendees + who chose not to speak out during a meeting + (e.g., so they could confer later with colleagues or for cultural reasons). +
+

The Chair should record + that a decision has been reopened, + and must do so upon request from a group participant.

+

5.5. Registering Formal Objections

+

Any individual + (regardless of whether they are associated with a Member) may appeal any decision made in connection with this Process + (except those having a different appeal process) + by registering a Formal Objection with the Team. + Group participants should inform + their Team Contact as well as the group’s Chair(s). + The Team Contact must inform the CEO when a group participant has also raised concerns about due process.

+

Note: In this document, the term Formal Objection is used to emphasize this process implication: + Formal Objections receive formal consideration and a formal response. + The word “objection” used alone has its ordinary English connotations. + See § 5.2 Consensus Building.

+

A Formal Objection must include a summary of + the issue (whether technical or procedural), + the decision being appealed, + and the rationale for the objection. + It should cite technical arguments + and propose changes that would remove the Formal Objection; + these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments + or rationale are unlikely to receive serious consideration. + Counter-arguments, + rationales, + and decisions should also be recorded.

+

No later than when the relevant Council is initiated, + a record of each Formal Objection against a decision regarding a publicly-available document must be made publicly available; + likewise, a record of each Formal Objection against a Member-visible decision must be made available to Members. + A Call for Review to the Advisory Committee must identify any Formal Objections related to that review. + This requirement is waived + if the Formal Objection is resolved to the satisfaction of the objector + before its confidentiality is changed.

+

Note: Formal Objections against matter in a technical report are expected to be fully addressed before requesting advancement of the technical report.

+

A Formal Objection filed during an Advisory Committee Review is considered registered at the close of the review period.

+

Registering a Formal Objection initiates the process of addressing the Formal Objection. + The resolution of a recorded Formal Objection—​whether by a Council decision, adoption of a consensus proposal, retraction of the Formal Objection, etc.—​must be recorded and made available at the same level of visibility as the record of the Formal Objection itself.

+

5.6. Addressing Formal Objections

+

5.6.1. Investigation and Mediation by the Team

+

The Team considers the Formal objection, + researches the question, + interviews parties, + and so on, + to make sure the problem and the various viewpoints are well understood, + and to the extent possible, + to arrive at a recommended disposition.

+

In parallel, the Team should start the steps necessary + to convene a Council.

+

If the Team can resolve the issue + to the satisfaction of the individual that filed the Formal Objection, + the individual withdraws the objection and the disposition process terminates.

+

Otherwise, + upon concluding that consensus cannot be found, + and no later than 90 days after the Formal Objection being registered, + the Team must deliver to the Council a report + documenting its findings and attempts to find consensus, + and hand over the matter to the W3C Council.

+

5.6.2. W3C Council

+

A W3C Council is the body convened to resolve Formal Objections by combining the capabilities and perspectives of the AB, the TAG, and the Team, + and is tasked with doing so in the best interests of the Web and W3C.

+
5.6.2.1. Council Composition
+

Each W3C Council is composed of the following members (excepting any renounced or dismissed):

+ +

Participation in a W3C Council must not require attendance of face-to-face meetings.

+

A distinct instance of the W3C Council is convened for each decision being appealed or objected to. + The list of potential Council members evolves + as AB and TAG terms start and end + until dismissal and renunciation are concluded, + at which point the membership of the Council is fixed. + However, if the number of active members in a Council falls so low as to hinder effective and balanced deliberations, + the Council Chair should dissolve the Council and call for a new one to be convened.

+

Note: TAG and AB elections have no effect on the Council’s membership + once it is fixed.

+

A Team member is assigned + to act as the Council Team Contact, + to support this Council + and to facilitate adherence to this Process.

+
5.6.2.2. Extraordinary Delegation
+

In extraordinary cases, + if they feel a Council would not be the appropriate deciding body, + a member of the Team (particularly the Legal Counsel) or + any potential Council member + may suggest that the decision for that specific Formal Objection be delegated + to the W3C Board of Directors, + to an officer of its corporation (such as the Legal Counsel), + or to one or more specific individuals from the Team. + The potential Council members then may confidentially discuss + and must vote + whether to delegate the decision for that specific Formal Objection. + A decision to delegate must be supported by a two-thirds supermajority vote + (i.e., at least twice as many votes in favor as against). + Delegation in such cases cannot be later revoked.

+

The Team must inform the Advisory Committee when a Formal Objection has been delegated, + and to whom it has been delegated.

+
5.6.2.3. Council Participation, Dismissal, and Renunciation
+

A potential Council member may be dismissed from the Council. + In order to apply consistent criteria, + the potential Council members decide collectively + which reasons against service + rise to a sufficient level for a potential member to be dismissed. + No-one is automatically dismissed, + and individual recusal is not used in the Council. Dismissal applies to an individual person in the context of a specific Council, + and should be used rarely in order to preserve the greatest diversity on the Council.

+

Note: A W3C Council is a deliberative body whose purpose is + to find the best way forward for the Web and for W3C. + It is not a judicial body tasked with determining right or wrong.

+

The Team must draft a list of potential Council members, + with annotations of possible reasons for dismissal against each one. + The W3C community, + including members and team, and potential council members, must be given an opportunity to contribute possible reasons to this list. + Affected members must be given + an opportunity to respond to such comments about themselves. + The Team may report comments verbatim + or may paraphrase them while preserving their intent; + they may also elide inappropriate comments, + such as any that violate applicable laws or the [COC].

+

Before a Council forms, + the Team presents the entire list of potential members + and collected reasons and responses + to the potential Council members, + who then consider for each potential member + whether that individual’s participation + would compromise the integrity of the Council decision, + and vote whether to dismiss that potential member. + No one is allowed to vote on their own dismissal; + each dismissal is enacted if there are at least as many ballots for as against.

+

Note: Since dismissal is individual, + when the decision being objected to was made by the TAG or AB acting as a body, + the entire TAG or AB is not expected to be dismissed.

+

An individual may also renounce their seat on a Council, for strong reason, + such as being forbidden by their employer to serve. The individual chooses the extent to which they explain + their renunciation. + Renunciation is disqualification from participation, + not abstention, + and should not be used + to excuse an absence of participation.

+

Any person who has been dismissed or who renounces their seat + does not receive Council materials, + take part in its deliberations, + help in the determination of consensus, + or vote. + The W3C Council may still solicit and hear their testimony, + as they can of anyone else in the W3C community.

+
5.6.2.4. Short Circuit
+

The full Council process may be short-circuited if + the Team recommends a resolution + and potential members of a Council who are not renouncing their seat + confirm it by a vote which results in both of the following:

+
    +
  • +

    at least 80% of them vote affirmatively to adopt this resolution

    +
  • +

    none of them vote against adopting the resolution

    +
+

The request for confirmation must be open for a period of at least two weeks, + or until every potential member of the Council not renouncing their seat + has voted, + whichever is shortest.

+

This step may be run concurrently with § 5.6.2.3 Council Participation, Dismissal, and Renunciation and prior to choosing a Chair.

+

Note: This is intended for exceptional cases + that don’t seem to warrant a full Council response + because they are, for instance, too trivial, duplicative, etc.

+
5.6.2.5. Council Chairing
+

The Chair of each W3C Council is chosen by its members, + by consensus if possible, + falling back to a vote if that fails. + The chair must be a member of that W3C Council. + Chair selection happens during formation of each Council, + and must be re-run + if requested by the Council Team Contact or by the Chair during the Council’s operation.

+
5.6.2.6. Convening the Council
+

Upon appointment of the W3C Council Chair and delivery of the Team’s report, + the W3C Council is considered to be convened and can start deliberations.

+

If a W3C Council has not yet been convened within 90 days of a Formal Objection + being registered, + the Chairs of the TAG and AB may take independent action to ensure + that the dismissal, renunciation, + and chair selection processes have been run. + If a report from the Team is not delivered within those 90 days, + the Council is considered convened upon selection of the Council Chair.

+
5.6.2.7. Council Deliberations
+

Once convened, + the Council may conduct additional research or analysis, + or request additional information or interviews from anyone, + including the Team.

+

The Council may further attempt to broker consensus, + which, if successful, disposes the formal objection.

+

Otherwise, + after sufficient deliberation, + the W3C Council decides whether to uphold or overrule the objection. + The W3C Council may overrule the Formal Objection even if it agrees with some of the supportive arguments.

+

When upholding an objection, + it should recommend a way forward. + If the overturned decision has already had consequences + (e.g., if the objection concerns material already in a published document) + the Council should suggest how these consequences might be mitigated. + The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion; + and the Formal Objection is not considered fully addressed until then.

+

Note: This does not create new powers for the Team, + such as the ability to “unpublish” documents. + The Team’s role is to ensure the responsible parties enact adequate mitigations, + by whatever means they already have at their disposal.

+

A Council may form sub-groups for deliberation, + who may return with a recommendation, + but the full Council issues the final decision. + The decision of the W3C Council should be unanimous, + and may be issued under consensus. + However, if despite careful deliberation + a W3C Council is unable to reach consensus, + the W3C Council Chair may instead resort to voting. + In that case, + the decision is adopted if there are more ballots for than against; + in case of a tie, + the W3C Council Chair determines the outcome. + However, + if the decision or proposal being objected to + originated with the TAG or AB, + then members of that group at the time the decision or proposal was made + must abstain in such a vote. + In case of a vote, + if two members of a Council who share the same affiliation cast an identical ballot, + then their ballots count as a one vote, + not two.

+

In the case of non-unanimous decisions, + members of a W3C Council who disagree with the decision may write a Minority Opinion explaining the reason for their disagreement.

+

The deliberations of a W3C Council are confidential to that W3C Council and its Council Team Contact.

+

If a W3C Council is unable to come to a conclusion within 45 days of being convened, + the W3C Council Chair must inform the AC of this delay + and of the status of the discussions. + The W3C Council Chair may additionally make this report public.

+
5.6.2.8. Council Decision Report
+

A Council terminates by issuing a Council Report, + which:

+
    +
  • +

    must state whether the Council upholds or overrules the objection(s).

    +
  • +

    must provide a rationale supporting the decision, +which should address each argument raised in the Formal Objection(s).

    +
  • +

    must include any recommendation decided by the Council.

    +
  • +

    if the Formal Objection has been upheld, should include any suggested mitigations.

    +
  • +

    must include the Minority Opinion(s), if any.

    +
  • +

    must report the names of those who were dismissed or renounced their seat as well as those who were qualified to serve.

    +
  • +

    must report the names of the individuals who participated in the final decision.

    +
  • +

    must report the number of votes for/against dismissing each participant.

    +
  • +

    may report vote totals for the Council’s decision, if a formal vote was held.

    +
  • +

    must not attribute any position to any individual on the Council.

    +
+

The Team must maintain a public page on the W3C website indexing all completed Council Reports. + If a Council decision is later overturned by an AC Appeal, + this must also be mentioned. Council Reports must be no more confidential + than the decision or document being objected to.

+

The Council may also issue a Supplemental Confidential Council Report with a more restricted level of confidentiality than its main report + when it believes that additional commentary on confidential aspects of the case + would be informative. + However, the main Council Report should be self-sufficient + and understandable without reference to Supplemental Confidential Council Reports.

+
5.6.2.9. Appealing Council Decisions
+

Advisory Committee representatives may initiate an Advisory Committee Appeal of a Council decision issued in a Council Report.

+

5.7. Advisory Committee Reviews and W3C Decisions

+

The Advisory Committee formally confers its approval + on charters, technical reports, + and other matters + through an Advisory Committee review and its resulting W3C Decision.

+

5.7.1. Initiating an Advisory Committee Review

+

Each Advisory Committee review period + begins with a Call for Review from the Team to the Advisory Committee. + The Call for Review describes the proposal, + raises attention to deadlines, + estimates when the decision will be available, + and includes other practical information. + The Team may share its perspective on the proposal + in the Call for Review. + Each Member organization may send one review, + which must be returned by its Advisory Committee representative.

+

For clarity, + in the context of an AC Review, dissent must be expressed as a Formal Objection.

+

The Team must provide two channels for Advisory Committee review comments:

+
    +
  1. an archived Team-only channel; +
  2. an archived Member-only channel. +
+

The Call for Review must specify + which channel is the default for review comments on that Call.

+

Reviewers may send information + to either or both channels. + A reviewer may also share their own reviews + with other Members on the Advisory Committee discussion list, + and may also make it available to the public.

+

A Member organization may modify its review + during a review period + (e.g., in light of comments from other Members).

+

5.7.2. Determining the W3C Decision

+

After the review period, + the Team determines the appropriate W3C Decision, + which they must announce to the Advisory Committee. + The announcement must indicate + the level of support for the proposal + (consensus or dissent), + and specifically + whether there were any Formal Objections, + with attention to changing the confidentiality level of the Formal Objections.

+

If there were Formal Objections, at least some of which were upheld, + or if there is not consensus because of insufficient support, W3C Decision must be one of:

+
    +
  • The proposal is returned for additional work, + with a request to the initiator to improve the proposal. +
  • The proposal is rejected. +
+

If the proposal has consensus, + or if any Formal Objections are retracted or overruled + and the proposal otherwise has sufficient support to achieve consensus, + this W3C Decision must be one of:

+
    +
  • The proposal is adopted, + possibly with additional changes integrated + in order to address the comments of the AC (see below). +
  • The proposal is returned for additional work, + with a request to the initiator to make desirable changes identified during the review + and to resubmit. +
+

If the proposal is adopted with changes other than class 1 (markup) changes, + then those changes must be announced to the AC and to the Group that owns the document (if any). + Additionally, when adopting a proposal with substantive changes integrated, + the announcement must include rationale + for the substantive changes.

+

Substantive changes to the proposal may be adopted + only if the revised proposal has consensus of the subset of the AC that voted on the initial proposal + (including anyone who explicitly abstained), + or if any Formal Objections against the revised proposal are retracted or overruled and the revised proposal otherwise has sufficient support to achieve consensus. + For clarity, + the Team should seek a response from this subset of the AC using the same tooling and degree of formality as it did for the AC Review; + and as is the case during AC Reviews, dissent in this context must be expressed as a Formal Objection.

+

Any Formal Objection raised at this stage against the revised proposal + is handled by the same Council responsible for Formal Objections raised against the initial proposal, + if any.

+

Note: Such a Council has the ability to + clear either the original or the revised proposal for advancement + by overruling all Formal Objections against the original or revised proposal, + respectively.

+

For publications which have conditions in addition to AC approval + for introducing substantive changes (such as Group consensus or implementation experience + or going through a patent Exclusion Opportunity), + those other conditions must also be re-fulfilled.

+
For example, if substantive changes to a technical report are requested when assessing the transition from Candidate Recommendation to Recommendation, + the technical report would need to go through a new Update Request and be republished as a new Candidate Recommendation; + that new version would then need to satisfy the criteria for advancement. + Alternatively, the desired changes can be introduced as non-substantive amendments + using the process for revising a Recommendation. + However, with the exception of the removal of at-risk features, + they cannot be directly integrated between CRS and REC, + because that would fail to trigger a patent exclusion opportunity.
+

For charters, + substantive changes from the initial proposal that underwent AC Review must not include any increase to the scope. + If any such change is desired, + it must be returned for additional work + and go through a complete new AC Review.

+

This document does not specify + time intervals between the end of an Advisory Committee review period + and the W3C decision. + This is to ensure that the Members and Team have sufficient time to consider comments + gathered during the review. + The Advisory Committee should not expect an announcement + sooner than two weeks after the end of a review period. + If, after three weeks, the outcome has not been announced, + the Team should provide the Advisory Committee with an update.

+

5.8. Advisory Committee Votes

+

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, + and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. + Whenever the Advisory Committee votes, + each Member or group of related Members has one vote.

+

5.9. Appeal by Advisory Committee Representatives

+

Advisory Committee representatives may appeal certain decisions, + though appeals are only expected to occur in extraordinary circumstances. + For the purpose of this section, only Advisory Committee representatives of Members in Good Standing are counted.

+

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate + an Advisory Committee Appeal. + These W3C decisions include those related to group creation and modification, + and transitions to new maturity stages for Recommendation Track documents + and the Process document.

+

Advisory Committee representatives may also initiate an appeal + for decisions of a W3C Council, and + for certain decisions that do not involve an Advisory Committee review. + These cases are identified in the sections + which describe the requirements for the decision + and include + additional (non-reviewed) maturity stages of Recommendation Track documents, + group charter extensions and closures, + and technical agreements.

+

In all cases, + an appeal must be initiated within three weeks of the decision.

+

An Advisory Committee representative initiates an appeal by sending a request to the Team, + and should also share this request with the Advisory Committee. + The request should say “I appeal this Decision” + and identify the decision, + and may also include their rationale for appealing the decision.

+

Note: See Appealing a W3C Decision for a recommendation + on how to communicate an appeal request to the Team and the AC.

+

Within one week the Team must announce the appeal process + to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. + The archive of these statements must be member-only. + If, within one week of the Team’s announcement, + 5% or more of the Advisory Committee support the appeal request, + the Team must organize an appeal vote asking the Advisory Committee “Do you approve of the Decision?” + together with links to the decision and the appeal support.

+

The ballot must allow for three possible responses: + “Approve”, + “Reject”, + and “Abstain”, + together with Comments.

+

The level of support needed for an Advisory Committee Appeal to pass + depends on the level of ballot participation + (including explicit “abstain” ballots) + by Advisory Committee Representatives:

+
    +
  • +

    if fewer than 5% participate, +the vote fails.

    +
  • +

    if at least 5% but no more than 15% participate, +and the number of “Approve” ballots exceeds three times (3x) the number of “Reject” ballots, +the vote passes.

    +
  • +

    if more than 15% but fewer than 20% participate, +and the number of “Approve” ballots exceeds twice (2x) the number of “Reject” ballots, +the vote passes.

    +
  • +

    if 20% or more participate, +and the number of “Approve” ballots exceeds the number of “Reject” ballots, +the vote passes.

    +
+

If the vote passes, + the decision is overturned. + Following such rejection, + those who had initiated the proposal may revise it + to address the causes of rejection + and follow the ordinary applicable process + to submit the revised proposal.

+

6. W3C Technical Reports

+

The W3C technical report development process is the set of steps and requirements + followed by W3C Working Groups to standardize Web technology. + The W3C technical report development process is designed to:

+
    +
  • support multiple specification development methodologies +
  • maximize consensus about the content of stable technical reports +
  • ensure high technical and editorial quality +
  • promote consistency among specifications +
  • facilitate royalty-free, interoperable implementations of Web Standards, and +
  • earn endorsement by W3C and the broader community. +
+

See also “licensing goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

6.1. Types of Technical Reports

+

This chapter describes the formal requirements + for publishing and maintaining a W3C Recommendation, Note, + or Registry.

+
+
Recommendations +
Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines + as standards for the Web. + The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, + and consensus-building, + and is subject to the W3C Patent Policy [PATENT-POLICY], + under which participants commit to Royalty-Free IPR licenses for implementations. + See § 6.3 The W3C Recommendation Track for details. +
Notes +
Groups can also publish documents as W3C Notes and W3C Statements, + typically either to document information + other than technical specifications, + such as use cases motivating a specification + and best practices for its use. + See § 6.4 The Note Track (Notes and Statements) for details. +
Registries +
Chartered and elected groups can also publish registries in order to document collections of values or other data. + A registry can be published either as a distinct registry report, + or directly within a Recommendation Track document + as an embedded registry. Defining a registry requires wide review and consensus, + but once set up, changes to registry entries are lightweight + and can even be done without the initiating group’s involvement. + See § 6.5 The Registry Track for details. +
+

Individual Working Groups and Interest Groups should adopt additional processes + for developing publications, + so long as they do not conflict with the requirements in this chapter.

+

6.2. General Requirements for Technical Reports

+

6.2.1. Publication of Technical Reports

+

Publishing as used in this document + refers to producing a version which is listed as a W3C Technical Report on its Technical Reports index at https://www.w3.org/TR [TR]. + Every document published as part of the technical report development process must be a public document. + W3C strives to make archival documents indefinitely available + at their original address in their original form.

+

Every document published as part of the technical report development process must clearly indicate its maturity stage, + and must include information about the status of the document. + This status information:

+
    +
  • must be unique each time a specification is published, +
  • must state which Working Group developed the specification, +
  • must state how to send comments or file bugs, + and where these are recorded, +
  • must include expectations about next steps, +
  • should explain how the technology relates to existing international standards + and related work inside or outside W3C, + and +
  • should explain + or link to + an explanation of significant changes from the previous version. +
+

Every Technical Report published + as part of the Technical Report development process + is edited by one or more editors + appointed by a Group Chair. + It is the responsibility of these editors to ensure that the decisions of the Group are + correctly reflected in subsequent drafts of the technical report. + An editor must be a participant, + per § 3.4.2 Participation in Chartered Groups in the Group responsible for the document(s) they are editing.

+

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, + status information, + style, + and copyright requirements). + These rules are subject to change by the Team from time to time. + The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

+

The primary language for W3C Technical Reports is English. + W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C website.

+

6.2.2. Reviews and Review Responsibilities

+

A document is available for review + from the moment it is first published. + Working Groups should formally address any substantive review comment + about a technical report in a timely manner.

+

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, + particularly if this would cause significant compatibility problems + due to existing implementation. Working Groups should record substantive + or interesting proposals raised by reviews + but not incorporated into a current specification.

+
6.2.2.1. Wide Review
+

The requirements for wide review are not precisely defined by the W3C Process. + The objective is to ensure that the entire set of stakeholders of the Web community, + including the general public, + have had adequate notice of the progress of the Working Group and were able to actually perform reviews of and provide comments on the specification. + A second objective is to encourage groups to request reviews + early enough that comments and suggested changes + can still be reasonably incorporated in response to the review. + Before approving transitions, + the Team will consider who has been explicitly offered + a reasonable opportunity to review the document, + who has provided comments, + the record of requests to and responses from reviewers, + especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter + or identified as liaisons [LIAISON], + and seek evidence of clear communication to the general public + about appropriate times and which content to review + and whether such reviews actually occurred.

+

Note: The Team documents best practices for wide review in the Guidebook. [GUIDE]

+

For example, + inviting review of new or significantly revised sections published in Working Drafts, + and tracking those comments + and the Working Group’s responses, + is generally a good practice which would often be considered positive evidence of wide review. Working Groups should follow the W3C Horizontal Groups’ review processes, + and should announce to other W3C Working Groups + as well as the general public, + especially those affected by this specification, + a proposal to enter Candidate Recommendation (for example in approximately 28 days). + By contrast a generic statement in a document + requesting review at any time + is likely not to be considered as sufficient evidence + that the group has solicited wide review.

+

A Working Group could present evidence that wide review has been received, + irrespective of solicitation. + But it is important to note that receiving many detailed reviews + is not necessarily the same as wide review, + since they might only represent comment + from a small segment of the relevant stakeholder community.

+

6.2.3. Classes of Changes

+

This document distinguishes the following 5 classes of changes to a document. + The first two classes of change are considered editorial changes, + the next two substantive changes, + and the last one registry changes.

+
+
+ +
    +
  1. +

    No changes to text content

    +
+
These changes include fixing broken links, style sheets, or invalid markup. +
+ +
    +
  1. +

    Changes that do not functionally affect interpretation of the document

    +
+
For Recommendation-track technical reports specifically, + this constitutes changes that do not affect conformance, + i.e. changes that reasonable implementers + would not interpret as changing architectural + or interoperability requirements + or their implementation. + Changes which resolve ambiguities in the specification + are considered to change (by clarification) the implementation requirements + and do not fall into this class. +
Examples of changes in this class include + correcting non-normative examples + which clearly conflict with normative requirements, + clarifying various other non-normative text, + fixing typos or grammatical errors + where the change does not change requirements. +
If there is any doubt or disagreement + as to whether a change functionally affects interpretation, + that change does not fall into this class. +
+ +
    +
  1. +

    Other changes that do not add new features

    +
+
+ For Recommendation-track documents, + these changes may affect conformance to the specification. + A change that affects conformance is one that: +
    +
  • makes conforming data, processors, or other conforming agents become non-conforming according to the new version, + or +
  • makes non-conforming data, processors, or other agents become conforming, + or +
  • clears up an ambiguity or under-specified part of the specification + in such a way that data, + a processor, + or an agent + whose conformance was once unclear + becomes clearly either conforming or non-conforming. +
+
+ +
    +
  1. +

    New features

    +
+
Changes that add new functionality, + such as new elements, new APIs, new rules, etc. +
+ +
    +
  1. +

    Changes to the contents of a registry table

    +
+
Changes that add, remove, or alter registry entries in a registry table. +
+

6.2.4. Errata Management

+

Tracking errors is an important part of a Working Group’s ongoing care of a technical report; + for this reason, + the scope of a Working Group charter generally allows time + for work after publication of a Recommendation. + In this Process Document, + the term “erratum” + (plural “errata”) refers to any error + that can be resolved by one or more changes in classes 1-3 + of section § 6.2.3 Classes of Changes.

+

Working Groups must keep + a public record of errors + that are reported by readers and implementers + for Recommendations. + Such error reports should be compiled + no less frequently than quarterly.

+

Working Groups decide how to document errata. + Such documentation must identify + the affected technical report text + and describe the error; + it may also describe some possible solution(s). + Readers of the technical report should be able easily + to find and see the errata + that apply to that specific technical report with their associated tests. + Errata may be documented + in a separate errata page or tracking system. + They may, + in addition or alternatively, + be annotated inline + alongside the affected technical report text + or at the start or end of the most relevant section(s).

+

6.2.5. Candidate Amendments

+

An erratum may be accompanied by a non-normative, candidate correction approved by group decision. + When annotated inline, + errata—​including their candidate corrections—​must be marked as such, + are treated as class 2 changes, + and are published accordingly.

+

Note: Annotating changes in this way allows more mature documents + such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, + even when the candidate amendments have not yet received + sufficient review or implementation experience + to be normatively incorporated into the specification proper.

+

A candidate addition is similar to a candidate correction, + except that it proposes a new feature + rather than an error correction.

+

Candidate corrections and candidate additions are collectively known as candidate amendments.

+

In addition to their actual maturity stage, published REC Track documents with candidate amendments are also considered, + for the purpose of the W3C Patent Policy [PATENT-POLICY], + to be Working Drafts with those candidate amendments treated as normative.

+

6.2.6. Maintenance Without a Group

+

For all types of technical reports and all maturity stages, + if there is no group chartered to maintain a technical report, + the Team may republish it + at the same maturity stage, + integrating as needed:

+
    +
  1. class 1 changes; +
  2. inline errata; +
  3. candidate corrections, + which must be marked as Team correction; +
  4. class 2 changes other than inline errata and Team corrections. +
+

To avoid any potential doubt or disagreement + about whether changes really do fall into class 2, + the Team should be conservative, + limiting itself to obvious and limited fixes, + and must avoid substantial rephrasing, + even of non-normative examples and notes. + If any such change is desired, + the Team must mark it as a Team correction.

+

Team corrections do not constitute + a normative portion of the Recommendation, + as defined in the Patent Policy [PATENT-POLICY] (i.e., they are not covered by the Patent Policy). + For Candidate Recommendations, W3C Recommendations, Candidate Registries, W3C Registries, + as well as W3C Statements, + the Team must solicit wide review on Team corrections that it produces.

+

6.2.7. License Grants from Non-Participants

+

When a party who is not already obligated under the Patent Policy + offers a change in class 3 or 4 + (as described in § 6.2.3 Classes of Changes) to a technical report under this process + the Team must request + a recorded royalty-free patent commitment; + for a change in class 4, the Team must secure such commitment. + Such commitment should cover, + at a minimum, + all the party’s Essential Claims both in the contribution, + and that become Essential Claims as a result of incorporating the contribution into the draft + that existed at the time of the contribution, + on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

+

6.3. The W3C Recommendation Track

+

Working Groups create specifications and guidelines + to complete the scope of work envisioned by a Working Group’s charter. + These technical reports undergo cycles of revision and review + as they advance towards W3C Recommendation status. + Once review suggests the Working Group has met their requirements for a new standard, + including wide review, + a Candidate Recommendation phase + allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. + At the end of the process, + the Advisory Committee reviews the mature technical report, + and if there is support from its Membership, + W3C publishes it as a Recommendation.

+

In summary, the W3C Recommendation Track consists of:

+
    +
  1. Publication of the First Public Working Draft. +
  2. Publication of zero or more revised Working Drafts. +
  3. Publication of one or more Candidate Recommendations. +
  4. Publication as a W3C Recommendation. +
+

A W3C Recommendation Track document is any document whose current status is one of the four in the numbered list above.

+
+ + Basic W3C Recommendation Track + + + + + First Public Working Draft (FPWD) - Exclusion opportunity + + + + WG Decision + + Team Approval + + + + + + + + + Working Draft (WD) + + + + + + + + Publish a new Working Draft + + + WG Decision + + + + + + + + + Advance to Candidate Recommendation + + WG Decision + + Team Approval + + + + + + + + + + Candidate Recommendation Snapshot (CRS) - Patent Policy exclusion opportunity + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG + Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + Team Approval + + + + + + + + Advance to Recommendation + + WG Decision + + Team Approval + + AC Review + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision with AB+TAG Approval) + + + + + + + + + + + Candidate Recommendation Draft (CRD) + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + + Team Approval + + + + + + + + + + + Recommendation + + + + + + + + Return to Candidate Recommendation Snapshot + + + WG Decision + (or Team Decision + with AB+TAG + Approval) + + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision + with AB+TAG + Approval) + + + + + + + + + Publish revised Recommendation with editorial changes + + + WG Decision + (editorial) + + + + + + + + + Publish revised Recommendation with substantive changes + + + WG Decision + + Team Approval + + AC Review + (substantive) + + + + + + + + + +
Non-Normative Summary of the Recommendation Track
+
+

This Process defines certain Recommendation Track publications as Patent Review Drafts. + Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004], + these correspond to “Last Call Working Draft” in the Patent Policy; + Starting from the 2020 Patent Policy [PATENT-POLICY-2020], + these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

+

W3C may end work on a technical report at any time.

+

As described in § 6.3.3 Advancement on the Recommendation Track, + the Team will decline a request to advance in maturity stage + and return the specification to a Working Group for further work + if it determines that the requirements for advancement + have not been met.

+

6.3.1. Maturity Stages on the Recommendation Track

+
+
Working Draft (WD) +
+ A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, + and other technical organizations, + and for simple historical reference. + Some, but not all, Working Drafts are meant to advance to Recommendation; + see the document status section of a Working Draft + for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, + and do not imply any endorsement by W3C + or its members beyond agreement to work on a general area of technology. + Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. + A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity. +

For all Working Drafts a Working Group:

+
    +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, + and +
  • may request publication of a Working Draft + even if its content is considered unstable + and does not meet all Working Group requirements. +
+

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), + and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

+
Candidate Recommendation (CR) +
+ A Candidate Recommendation is a document that satisfies the technical + requirements of the Working Group that produced it and their dependencies, + and has already received wide review. + W3C publishes a Candidate Recommendation to + +

Note: Advancing to Candidate Recommendation indicates + that the document is considered complete and fit for purpose, + and that no further refinement to the text is expected + without additional implementation experience and testing; + however, additional features might be expected in a later revision. + A Candidate Recommendation is expected to be as well-written, + detailed, + self-consistent, + and technically complete + as a Recommendation, + and acceptable as such + if and when the requirements for further advancement are met.

+

Candidate Recommendation publications take one of two forms:

+
+
Candidate Recommendation Snapshot (CRS) +
+ A Candidate Recommendation Snapshot + corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. + Publishing a Patent Review Draft triggers a Call for Exclusions, + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy. +

Publication as a Candidate Recommendation Snapshot requires verification of either a Transition Request (for the first Candidate Recommendation publication from another maturity stage) + or an Update Request (for subsequent Candidate Recommendation Snapshots).

+
Candidate Recommendation Draft (CRD) +
+ A Candidate Recommendation Draft + is published + to solicit review of intended changes from the previous Candidate Recommendation Snapshot. + This allows for wider review of the changes + and for ease of reference to the integrated specification. +

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot. + However, the process requirements are minimized + so that the Working Group can easily keep the specification up to date.

+

A Candidate Recommendation Draft does not provide an exclusion opportunity; + instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

+
+

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered + such that W3C cannot endorse it or continue work on it, + for example due to burdensome patent claims that affect implementers and cannot be resolved + (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). + There is no path to restoration for a Rescinded Candidate Recommendation. + See “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

+
W3C Recommendation (REC) +
+ A W3C Recommendation is a specification + or set of guidelines + or requirements that, + after extensive consensus-building, + has received the endorsement of W3C and its Members. + W3C recommends the wide deployment + of its Recommendations as standards for the Web. + The W3C Royalty-Free IPR licenses + granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. +

After its initial publication, + a W3C Recommendation may be revised + (in accordance with § 6.3.10 Revising a W3C Recommendation) + to address editorial or substantive issues + that are discovered later. + However, new features can only be added + if the document already identifies itself + as intending to allow new features. + Such an allowance cannot be added + to a technical report previously published as a Recommendation that did not allow such changes; + this requires a new technical report (which could, for example, be similarly named but with an incremented version number).

+

As technology evolves, + a W3C Recommendation may become:

+
+
A Superseded Recommendation +
+ A Superseded Recommendation is a specification + that has been replaced by a newer version + that W3C recommends for new adoption. + An Obsolete or Superseded specification + has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy. +

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, + the latest version replaces the previous one, + without the need to invoke the steps of § 6.3.12.3 Abandoning a W3C Recommendation: + it is the same document, updated. + Explicitly declaring a documented superseded, using the process documented in § 6.3.12.3 Abandoning a W3C Recommendation, + is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

+
An Obsolete Recommendation +
An Obsolete Recommendation is a specification + that W3C has determined lacks sufficient market relevance + to continue recommending it for implementation, + but which does not have fundamental problems + that would require it to be Rescinded. + If an Obsolete specification gains sufficient market relevance, + W3C may decide to restore it to Recommendation status. +
Rescinded Recommendation +
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, + and believes is unlikely to ever be restored to Recommendation status. + See also “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+
Discontinued Draft +
A technical report representing the state of a Recommendation-track document + at the point at which work on it was discontinued. + See § 6.3.12.1 Abandoning an Unfinished Recommendation. +
+

Only sufficiently technically mature work should be advanced.

+

Note: Should faster advancement to meet scheduling considerations be desired, + this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring + less stable features to other technical reports.

+

When publishing an updated version of an existing Candidate Recommendation or Recommendation, + technical reports are expected to meet the same maturity criteria as when they are first published under that status. + However, in the interest of replacing stale documents with improved ones in a timely manner, + if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, + it is also permissible to publish an updated CR or REC following the usual process, + even if only some of these flaws have been satisfactorily addressed.

+

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, + and do not necessarily imply consensus of a Working Group or Interest Group, + nor are their contents endorsed in any way by W3C.

+

6.3.2. Implementation Experience

+

Implementation experience is required to show that a specification is sufficiently clear, + complete, + and relevant to market needs, + to ensure that independent interoperable implementations + of each feature of the specification will be realized. + While no exhaustive list of requirements is provided here, + when assessing that there is adequate implementation experience the Team will consider (though not be limited to):

+
    +
  • is each feature of the current specification implemented, + and how is this demonstrated? +
  • are there independent interoperable implementations of the current specification? +
  • are there implementations created by people other than the authors of the specification? +
  • are implementations publicly deployed? +
  • is there implementation experience + at all levels of the specification’s ecosystem + (authoring, consuming, publishing…)? +
  • are there reports of difficulties or problems with implementation? +
+

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. + Groups are often able to work more effectively + if they plan how they will demonstrate interoperable implementations + early in the development process; + for example, developing tests in concert with implementation efforts.

+

6.3.3. Advancement on the Recommendation Track

+

For all requests to advance a specification + to a new maturity stage + (called Transition Requests), + the Working Group:

+
    +
  • must record the group’s decision to request advancement. +
  • must obtain Team verification. Team verification (a Team decision) must be withheld if any Process requirements are not met + or if there remain any unresolved Formal Objections + (including any upheld by a Council but not yet fully addressed), + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects a Transition Request it must indicate its rationale + to the Advisory Committee and the Working Group. +
  • must publicly document all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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 stage. +
  • must provide public documentation of any Formal Objections. +
  • should report which, if any, of the Working Group’s requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

For a First Public Working Draft there is no “previous maturity stage”, + so many requirements do not apply, + and verification is normally fairly straightforward. + For later stages, + especially transitions to Candidate or Recommendation, + there is usually a formal review meeting + to verify that the requirements have been met.

+

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved + while a Working Group’s charter is undergoing or awaiting a decision + on an Advisory Committee Review.

+

6.3.4. Updating Mature Publications on the Recommendation Track

+

Certain requests to re-publish a specification + within its current maturity stage + (called Update Requests) + require extra verification. + For such update requests, the Working Group:

+
    +
  • must record the group’s decision to request the update. +
  • must show that the changes have received wide review. +
  • + must obtain Team verification. Team verification (a Team decision): +
      +
    • +

      should be withheld +if any Process requirements are not met,

      +
    • +

      may be withheld +in consideration of unresolved Formal Objections +(including any upheld by a Council but not yet fully addressed),

      +
    • +

      may be withheld +if the document does not adequately reflect +all relevant decisions of a W3C Council (or its delegates),

      +
    • +

      may be withheld +if the Team believes the Group is not making reasonable progress +on addressing issues raised by individuals external to the Group.

      +
    +

    If the Team rejects an Update Request, + it must indicate its rationale to the Working Group. + If it waives any Process requirements, + it must indicate its rationale to the AC.

    +
  • must provide public documentation of any Formal Objections. +
  • must publicly document of all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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, + or explain why the requirements have changed or been deferred, +
  • should report which, if any, of the Working Group’s requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

There is usually a formal review meeting + to verify that the requirements have been met.

+

Note: Update request verification is expected to be fairly simple + compared to verification of a transition request.

+

The Team must announce the publication + of the revised specification + to other W3C groups and the Public.

+

6.3.5. Publishing a First Public Working Draft

+

To publish the First Public Working Draft of a document, + a Working Group must meet the applicable requirements for advancement.

+

The Team must announce + the publication of a First Public Working Draft to other W3C groups and to the public.

+

6.3.6. Revising a Working Draft

+

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.

+

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

+
    +
  • must record the group’s decision to request publication. Consensus is not required, + as this is a procedural step, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Working Draft, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous step, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups, +
+

Possible next steps for any Working Draft:

+ +

6.3.7. Transitioning to Candidate Recommendation

+

To publish a Candidate Recommendation, + in addition to meeting the requirements for advancement a Working Group:

+
    +
  • must show that the specification + has met all Working Group requirements, + or explain why the requirements have changed or been deferred, +
  • must document changes to dependencies during the development of the specification, +
  • must document + how adequate implementation experience will be demonstrated, +
  • must specify the deadline for comments, + delineating the Candidate Recommendation review period, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • must show that the specification has received wide review, and +
  • may identify features in the document as at risk. + These features may be removed + before advancement to Recommendation without requiring an Update Request. +
+

The first Candidate Recommendation publication + after verification of having met the requirements for a Transition Request is always a Candidate Recommendation Snapshot. + The Team must announce + the publication of the Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

Possible next steps after a Candidate Recommendation Snapshot:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.8. Revising a Candidate Recommendation

+
6.3.8.1. Publishing a Candidate Recommendation Snapshot
+

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, + the Working Group must meet the requirements of an update request in order to republish.

+

In addition the Working Group:

+
    +
  • must specify the deadline for further comments, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • may identify features in the document as at risk. + These features may be removed + before advancement to Recommendation without requiring an Update Request. +
+

The Team must announce + the publication of a revised Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

To provide timely updates and patent protection, + a Candidate Recommendation Snapshot should be published + within 24 months of the Working Group accepting + any proposal for a substantive change + (and preferably sooner). + To make scheduling reviews easier, + a Candidate Recommendation Snapshot should not be published + more often than approximately once every 6 months.

+

Note: Substantive changes trigger a new Exclusion Opportunity + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.8.2. Publishing a Candidate Recommendation Draft
+

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 + that would benefit from review beyond the Working Group.

+

To publish a revision of a Candidate Recommendation Draft, + a Working Group:

+
    +
  • must record the group’s decision to request publication, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups. +
+

Note: A Working Group does not need to + meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

+

Possible next steps after a Candidate Recommendation Draft:

+ +

6.3.9. Transitioning to Recommendation

+

When a Working Group estimates + that a Candidate Recommendation has fulfilled all the relevant criteria, + it may decide to request advancement to W3C Recommendation.

+
6.3.9.1. Requirements for Transition
+

In addition to meeting the requirements for advancement, + the Working Group:

+ +

Additionally, + if the document has previously been published as a W3C Recommendation, the Working Group must not include any class 4 change to that publication + unless it was explicitly marked as allowing new features, + and must not include any such marking + if not already present.

+
6.3.9.2. Initiating Review
+

If all the criteria above are fulfilled, + the Team must begin an Advisory Committee Review on the question of whether the identified Candidate Recommendation Snapshot is appropriate to publish as a W3C Recommendation. + If the document’s most recent publication is not a Candidate Recommendation Snapshot, + then it must be republished as such in order to provide a basis for review. + The deadline for Advisory Committee review must allow at least 28 days, + and must end at least 10 days + after the end of the last Exclusion Opportunity + per ”Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.9.3. Resolution of Review
+

If there was any Formal Objection during the Advisory Committee Review, + the Team must publish the substantive content of the dissent to W3C and the general public, + and the W3C Recommendation must not be published + unless all Formal Objections to the document have been retracted or overruled and at least 14 days have elapsed since the publication of the corresponding Council Report.

+

The decision to advance a document to Recommendation is a W3C Decision. + The Team must announce the publication of a W3C Recommendation to the Advisory Committee, + to other W3C groups + and to the public. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

The newly published Recommendation must not make any substantive changes to the document + compared to the Candidate Recommendation Snapshot submitted for AC Review, + other than dropping features identified at risk.

+
6.3.9.4. Next Steps from W3C Recommendation
+

Possible next steps: + A W3C Recommendation normally retains its status indefinitely. + However it may be:

+ +

6.3.10. Revising a W3C Recommendation

+
6.3.10.1. Revising a Recommendation: Editorial Changes
+

Editorial changes to a Recommendation require no technical review of the intended changes. + A Working Group, + provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity stages. + (See class 1 and class 2 changes.)

+
6.3.10.2. Revising a Recommendation: Substantive Changes
+

Tentative corrections (see class 3 changes) may be annotated into a Recommendation using candidate corrections.

+

Note: Candidate corrections do not normatively modify the document; + they editorially indicate how one might do so. + They are therefore published following the provisions of § 6.3.10.1 Revising a Recommendation: Editorial Changes.

+

A candidate correction can be made normative + and be folded into the main text of the Recommendation, + once it has satisfied all the same criteria + as the rest of the Recommendation, + including review by the community to ensure + its technical and editorial soundness. + To validate this, the Working Group must request + a Last Call for Review of Proposed Amendments, + followed by an update request. + See § 6.3.10.4 Incorporating Candidate Amendments.

+

Alternatively, + a Working Group may incorporate the changes + and publish as a Working Draft—​or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—​and advance the specification from that state. + (See class 3 changes.)

+
6.3.10.3. Revising a Recommendation: New Features
+

For Recommendations explicitly identified as allowing new features, + tentative new features (see class 4 changes) may be added as candidate additions in annotations, + and class 4 changes may be normatively incorporated + in the same fashion as class 3 changes in § 6.3.10.2 Revising a Recommendation: Substantive Changes.

+

Note: Limiting the addition of new features to Recommendations that explicitly allow them + enables third parties to depend on a stable feature-set for Recommendations that do not advertise that ability, + as was the case for all Recommendations prior to the 2020 revision of this Process.

+

Note: When a Recommendation does not allow new features, + new features can be added by creating a new technical report and following the full process of advancing that technical report to Recommendation—​beginning with a new First Public Working Draft. + Such technical reports could be written to represent + additional modules building on top of the original Recommendation of the core technology, + or an expanded replacement of the original Recommendation of the core technology + (in which case the new technical report will typically have the same name as the original, + with an incremented version number).

+
6.3.10.4. Incorporating Candidate Amendments
+

A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.

+

The Last Call for Review of Proposed Amendments must be announced to other W3C groups, the public, and the Advisory Committee. + The announcement must:

+
    +
  • Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, + or Last Call for Review of Proposed Corrections and Additions. +
  • Identify the specific candidate amendments under review + as proposed amendments (proposed corrections/proposed additions). +
  • Specify the deadline for review comments, + which must not be any sooner than 60 days from the Call for Review. +
  • Solicit review and, if it does not already have it, implementation experience. +
+

The combination of the existing Recommendation with the proposed amendments included in the Last Call for Review of Proposed Amendments is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. + Also, the review initiated by the Last Call for Review of Proposed Amendments is an Advisory Committee Review.

+

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

+

A Working Group may batch + multiple proposed amendments into a single Last Call for Review of Proposed Amendments. + To facilitate review, + a Last Call for Review of Proposed Amendments on a given specification should not be issued more frequently + than approximately once every 6 months.

+

At the end of the Last Call for Review of Proposed Amendments, + the W3C Decision may either be + to reject the proposed amendment, + or to clear the proposed amendment for advancement as is, + or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. + If the Working Group needs to amend a proposed amendment in response to review feedback + it must issue another Last Call for Review of Proposed Amendments on the revised change + before it can be incorporated into the main text.

+

Once all comments on a proposed amendment have been formally addressed, + and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, + it may incorporate the proposed amendment into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

+

To ensure adequate review of proposed amendment combinations, + only proposed amendments included in the most recent Last Call for Review of Proposed Amendments can be incorporated into the normative Recommendation text. + (Thus if incorporation of a proposed amendment is postponed, + it may need to be included in multiple Last Calls for Review of Proposed Amendments.)

+

6.3.11. Regression on the Recommendation Track

+

A Working Group may republish a Recommendation-track technical report at a lower maturity stage by fulfilling the requirements to transition to that maturity stage, + as described above.

+

Additionally, + with the approvals (by group decision) of each of the TAG and the AB the Team may return + the technical report to a lower maturity stage in response to wide review or a formal objection.

+

6.3.12. Retiring Recommendation Track Documents

+

Work on a technical report may cease at any time. + Work should cease + if W3C or a Working Group determines + that it cannot productively carry the work any further.

+
6.3.12.1. Abandoning an Unfinished Recommendation
+

Any Recommendation-track technical report no longer intended + to advance or to be maintained, + and that is not being rescinded, should be published as a Discontinued Draft, + with no substantive change compared to the previous publication. + This can happen if + the Working Group decided + to abandon work on the report, + or as the result of an AC Review requiring the Working Group to discontinue work on the technical report before completion. + If a Working Group is made to close, + W3C must re-publish any unfinished technical report on the Recommendation track as Discontinued Draft.

+

Such a document should include in its status section + an explanation of why it was discontinued.

+

A Working Group may resume work + on such a technical report within the scope of its charter + at any time, + by re-publishing it as a Working Draft.

+
6.3.12.2. Rescinding a Candidate Recommendation
+

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

+
6.3.12.3. Abandoning a W3C Recommendation
+

It is possible that W3C decides + that implementing a particular Recommendation is no longer recommended. + There are three designations for such specifications, + chosen depending on the advice W3C wishes to give about further use of the specification.

+

W3C may obsolete a Recommendation, + for example if the W3C Community decides that the Recommendation no longer represents best practices, + or is not adopted and is not apparently likely to be adopted. + An Obsolete Recommendation may be restored to normal Recommendation, + for example because despite marking it Obsolete the specification is later more broadly adopted.

+

W3C may declare a Recommendation Superseded + if a newer version exists which W3C recommends for new adoption. + The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; + only the name and explanation change.

+

W3C may rescind a Recommendation + if W3C believes there is no reasonable prospect of it being restored + for example due to burdensome patent claims that affect implementers and cannot be resolved; + see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” + and “PAG Conclusion”.

+

W3C only rescinds, supersedes, or obsoletes entire Recommendations. + A Recommendation can be both superseded and obsolete. + To rescind, supersede, or obsolete some part of a Recommendation, + W3C follows the process for modifying a Recommendation.

+

Note: For the purposes of the W3C Patent Policy, [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, + although it is not advised for future implementation; + a Rescinded Recommendation ceases to be in effect + and no new licenses are granted under the Patent Policy.

+
+ + Supersede, Obsolete or Rescind a W3C Recommendation + + + + Recommendation (Rec) + + + + + A major problem and an AC review can lead to a Recommendation being Rescinded. + There are no new IPR licences issued under the W3C Patent Policy, + and reinstating the Recommendation requires going through the full Rec-track process again. + + Major problem, AC review + + + Rescinded Recommendation - no new IPR licenses + + + + + + + + + With little uptake, following AC review a specification may become an Obsolete Recommendation + + + + + Obsolete Recommendation + + + + + + + + If there is new uptake, with AC review an Obsolete Recommendation may return to normal Recommendation status + + + + + + + + + + + Replaced by a new version, AC review + + Superseded Recommendation + + + + + + + A Superseded Recommendation can become a normal Recommendation with AC review + + + + + + + + + + + +
Non-Normative Summary of the Paths to Retiring a W3C Recommendation
+
+
6.3.12.4. Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
+

The process of rescinding, obsoleting, + superseding, + or restoring + a Recommendation can be initiated + either by a request from the Team or via a request from any of the following:

+ +

The Team must then + submit the request to the Advisory Committee for review. + For any Advisory Committee review of a proposal to + rescind, + obsolete, + supersede, + or restore + a Recommendation the Team must:

+
    +
  • announce the proposal to all Working Group Chairs, + and to the Public, + as well as to the Advisory Committee +
  • indicate that this is a proposal to + Rescind, + Obsolete, + Supersede, + or restore, + a Recommendation as appropriate +
  • identify the Recommendation by URL +
  • publish a rationale for the proposal +
  • identify known dependencies + and solicit review from all dependent Working Groups +
  • solicit public review +
  • specify the deadline for review comments, + which must be at least 28 days + after the announcement +
+

and should

+
    +
  • identify known implementations. +
+

If there was any dissent in the Advisory Committee review, + the Team must publish + the substantive content of the dissent to W3C and the public, + and must formally address the dissent + at least 14 days + before publication as an Obsolete or Rescinded Recommendation.

+

The Advisory Committee may initiate an Advisory Committee Appeal of the Team’s decision.

+

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. + The updated version may remove the main body of the document. + The Status of this Document section should link + to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

+

Once W3C has published a Rescinded Recommendation, + future W3C technical reports must not include normative references + to that technical report.

+

Note: W3C strives to ensure that all Technical Reports + will continue to be available at their version-specific URL.

+

6.4. The Note Track (Notes and Statements)

+

6.4.1. Group Notes

+

A Group Note (NOTE) + is published + to provide a stable reference for a useful document + that is not intended to be a formal standard.

+

Working Groups, Interest Groups, + the TAG and the AB may publish work as Notes. + Examples include:

+
    +
  • supporting documentation for a specification, + such as explanations of design principles + or use cases and requirements +
  • non-normative guides to good practices +
+

Some Notes are developed through successive Note Drafts before publication as a full Notes, + while others are published directly as a Note. + There are few formal requirements to publish a document as a Note or Note Draft, + and they have no standing as a recommendation of W3C + but are simply documents preserved for historical reference.

+

Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Note Drafts.

+

6.4.2. Publishing Notes

+

In order to publish a Note or Note Draft, + the group:

+
    +
  • must record their decision + to request publication as a Note or Note Draft, and +
  • should publish documentation + of significant changes to the technical report + since any previous publication. +
+

Both Notes and Note Drafts can be updated by republishing + as a Note or Note Draft. + A technical report may remain + a Note indefinitely.

+

6.4.3. Elevating Group Notes to W3C Statement status

+

A W3C Statement is a Note that has been endorsed by W3C as a whole. + In order to elevate a Note to W3C Statement status, + A group must:

+ +

A Note specifying implementable technology should not be elevated to W3C Statement status; + if it does, + the request to publish as a Statement must include rationale + for why it should be elevated, + and why it is not on the Recommendation track.

+

Once these conditions are fulfilled, + the Team must then + begin an Advisory Committee Review on the question of + whether the document is appropriate to publish as a W3C Statement. + During this review period, + the Note must not be updated.

+

The decision to advance a document to W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

The Team must announce the publication of a W3C Statement to the Advisory Committee, other W3C groups, and the public.

+

6.4.4. Revising W3C Statements

+

Given a recorded group decision to do so, + groups can request publication of a W3C Statement with editorial changes—​including candidate amendment—​without any additional process.

+

A candidate amendment can be folded into the main text of the W3C Statement, + once it has satisfied all the same criteria + as the rest of the Statement, + including review by the community to ensure + the substantive and editorial soundness of the candidate amendments. + To validate this, the group must request + an Advisory Committee review of the changes it wishes to incorporate. + The specific candidate amendments under review must be identified as proposed amendments just as in a Last Call for Review of Proposed Corrections.

+

The decision to incorporate proposed amendments into W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

6.5. The Registry Track

+

A registry documents a data set + consisting of one or more registry tables, + each table representing an updatable collection + of logically independent, consistently-structured registry entries. + A registry consists of:

+ +

The purposes of maintaining a registry can include:

+
+
non-collision +
Avoiding the problem + of two entities using the same value with different semantics. +
non-duplication +
Avoiding the problem + of having two or more different values in use with the same semantics. +
information +
Providing a central index + where anyone can find out + what a value means + and what its formal definition is + (and where it is). +
submission +
Ease of adding new terms, + including by stakeholders external to the custodian organization. +
consensus +
Promoting a clear consensus of the community on the terms. +
+

This section of the W3C Process provides a specialized process + facilitating the publication and maintenance of such registry tables, + particularly those required by or closely related to W3C Recommendations.

+

Note: Not every table in a specification is a potential registry. + If the intent or effect is that the table enumerates + all the possibilities the authors of the specification expect or envisage, + then the table by itself is enough. + Similarly, if the table is managed by the Working Group + and only updated as part of specification update, + then the complexities of registry management are not needed.

+

6.5.1. Registry Definitions

+

A registry definition defines what each registry table is and how it is maintained. + It must:

+
    +
  • Define the scope and purpose of each registry table. +
  • Define the fields of each registry table and their constraints + (e.g. values must be drawn from a defined set, or be unique, + or only reference publicly available resources, + etc.) +
  • + Define the policy for changes to existing entries, such as +
      +
    • whether entries can be deleted or deprecated +
    • whether entries can be changed after being published, and what kinds of changes are allowed +
    • whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely +
    +
  • Define the method and criteria by which changes are proposed, approved, and incorporated. + (For example, a registry could define + that changes to registry entries can be proposed using a particular web form or email address, + that they must be accompanied by certain background information, + or that they do or do not need to be approved by any member of a particular Working Group.) +
  • + Identify the custodian of the registry table: + the entity to which requests for registry changes must be sent, + and which is responsible for evaluating whether such requests + satisfy the criteria defined in the registry definition. +

    The custodian may be the initiating group, the Team, or a delegated entity. + The custodian for all registry tables in a single registry should generally be the same entity.

    +

    If the custodian of a registry table ceases to exist or to operate as a custodian + (e.g., the relevant group is disbanded, or + the custodian is unresponsive to repeated attempts to make contact), + and the chartered or elected group that owns the registry definition is itself closed or + unresponsive, + the Team should propose replacing the custodian, + which must be confirmed + by an AC Review as a W3C Decision.

    +
+

6.5.2. Publishing Registries

+

A chartered or elected group can publish a registry as a stand-alone technical report on the Registry Track, + where it is called a registry report. Working Groups have the additional option of + incorporating a registry as part of a Recommendation, + as an embedded registry.

+

The registry report or embedded registry must:

+ +

The Team must make available + a means for interested parties to be notified of any updates to a registry table.

+

Note: Since the Process does not impose requirements + on changes to the contents of a registry table other than those imposed by the registry definition, + acceptance of proposed registry changes on behalf of the custodian and + publication of an updated registry report that contains + only registry changes since the previous publication + can be automated + if satisfaction of those rules can be automatically verified.

+

Rules for publication and advancement on the Registry Track are identical to that of the Recommendation Track with the following exceptions:

+ +

6.5.3. Updating Registry Tables

+

Changes to the contents of a registry table that are in accordance with the registry definition, + (i.e. Class 5 changes) + can be made by re-publishing the technical report that contains the affected table, + without needing to satisfy any other requirements for the publication + (not even a group decision, unless this is required by the registry definition). + Such registry changes do not trigger new Advisory Committee Reviews, + nor Exclusion Opportunities, + and do not require verification via an update request, + even for technical reports at maturities where this would normally be expected. + Such publications can be made + even in the absence of a group chartered to maintain the registry + when the custodian is another entity.

+

Note: The custodian is only empowered to make registry changes. + If the group establishing the registry wishes + to empower the custodian to add commentary on individual entries, + this needs to be part of the registry table’s definition. + If other changes are desired, + they need to be requested of the group responsible for maintaining the registry definition—​or in the absence of such a group, of the Team.

+

Changes to the registry tables made in accordance with candidate or proposed amendments to the registry definition which would not be allowed by the unamended registry definition must be identified as such.

+

6.5.4. Registry Data Reports

+

When the registry data is published in a separate technical report from its registry definition, + that report is called a Registry Data Report. + This technical report:

+ +

Registry Data Reports do not have maturity stages in and of themselves; + The maturity stage of the registry whose data they record + is that of the technical report holding the registry definition.

+

Anytime a change is made to a registry definition, + the group maintaining the registry definition must update and republish + any document holding the corresponding registry tables to make it consistent with these changes.

+

Given a recorded group decision to do so, + the group maintaining the registry definition may republish the Registry Data Report to incorporate editorial changes.

+

6.5.5. Specifications that Reference Registries

+

Registries document values, + they do not define any architectural or interoperability requirements + related to those values. + All architectural and interoperability requirements + pertaining to registry entries must be contained in the specifications that reference the registry, + and are therefore subject to the processes + (including approval and intellectual property provisions) + applicable to those referencing specifications.

+

If there are entries that must be implemented, + or any other such restrictions, + they must be defined or documented + in the referencing specification + without dependency on the registry.

+
For example, “All implementations must implement the Basic-Method as defined in the registry” is not acceptable because + a change to the definition of the Basic-Method in the registry would then affect conformance. + Instead, the requirement has to be complete in the specification, + directly or by reference to another specification. + For example “All implementations must recognize the name Basic-Method, + and implement it as defined by section yy of IETF RFC xxxx”. + (The Registry is nonetheless expected to contain Basic-Method as an entry.)
+

6.5.6. Registries and Patents

+

A registry report or embedded registry is not subject to the W3C Patent Policy, + and must not define any requirements on implementations. + For the purposes of the Patent Policy [PATENT-POLICY] (only), + any embedded registry in a Recommendation track document + is not a normative portion of that specification.

+

6.6. Switching Tracks

+

Given a Group decision to do so, Working Groups can republish a technical report on a different track than the one it is on, + under the following restrictions:

+ +

Technical reports that switch tracks start at + their new track’s initial maturity stage, + while retaining any established identity (url, shortname, etc.).

+

Note: The initial maturity stage of the Recommendation track is Working Draft. First Public Working Draft designates a specific type of Working Draft and is not a separate maturity stage. + A document which switches to the Recommendation track is only published as a First Public Working Draft if it was never previously published as such; + otherwise, it is simply a Working Draft.

+

6.7. Further reading

+

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews + and announcements of the various steps, + and tips on getting to Recommendation faster [REC-TIPS]. + Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

+

7. Dissemination Policies

+

7.1. Public Communication

+

The Team is responsible for managing communication within W3C + and with the general public + (e.g., news services, press releases, managing the website and access privileges, and managing calendars). + Members should solicit review by the Team + prior to issuing press releases about their work within W3C.

+

The Team makes every effort to ensure the persistence and availability of the following public information:

+ +

To keep the Members abreast of W3C meetings, Workshops, + and review deadlines, + the Team provides them with a regular (e.g., weekly) news service + and maintains a calendar [CALENDAR] of official W3C events. + Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

+

7.2. Confidentiality Levels

+

There are three principal levels of access to W3C information + (on the W3C website, in W3C meetings, etc.): + public, + Member-only, + and Team-only.

+

While much information made available by W3C is public, + “Member-only” information + is available to authorized parties only, + including representatives of Member organizations, Invited Experts (as described in https://www.w3.org/invited-experts/#memaccess), + the Advisory Board, + the TAG, + and the Team. + For example, + the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

+

“Team-only” information + is available to the Team and other authorized parties.

+

Those authorized to access Member-only and Team-only information:

+
    +
  • must treat the information as confidential within W3C, +
  • must use reasonable efforts to preserve that confidentiality, and +
  • must not release this information to the general public or press, + nor beyond the proper level of access. +
+

The Team must provide mechanisms + to protect the confidentiality of Member-only information + and ensure that authorized parties have proper access to this information. + Documents should clearly indicate + whether they require Member-only confidentiality. + Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

+

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member + who are considered appropriate recipients. + For instance, + it is the responsibility of the Advisory Committee representative and other employees + and official representatives of the organization + to ensure that Member-only news announcements + are distributed for internal use only within their organization. + Information about Member mailing lists is available + in the New Member Orientation [INTRO].

+

7.3. Changing Confidentiality Level

+

As a benefit of membership, + W3C provides some Team-only and Member-only channels + for certain types of communication. + For example, Advisory Committee representatives can send reviews to a Team-only channel. + However, for W3C processes with a significant public component, + such as the technical report development process, + it is also important for information that affects decision-making to be publicly available. + The Team may need to communicate Team-only information to a Working Group or the public. + Similarly, a Working Group whose proceedings are Member-only must make public + information pertinent to the technical report development process.

+

This document clearly indicates which information must be available to Members or the public, + even though that information was initially communicated on Team-only or Member-only channels. + Only the Team and parties authorized by the Team + may change the level of confidentiality of this information. + When doing so:

+
    +
  1. The Team must use a version of the information + that was expressly provided by the author for the new confidentiality level. + In Calls for Review and other similar messages, + the Team should remind recipients to provide such alternatives. +
  2. The Team must not attribute the version + for the new confidentiality level to the author without the author’s consent. +
  3. If the author has not conveyed to the Team a version + that is suitable for another confidentiality level, + the Team may make available a version that reasonably communicates what is required, + while respecting the original level of confidentiality, + and without attribution to the original author. +
+

8. Liaisons

+

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, + through a number of mechanisms + ranging from very informal + (e.g., an individual from another organization participates in a W3C Working Group, + or just follows its work) + to mutual membership, + to even more formal agreements. + Liaisons are not meant to substitute for W3C membership.

+

All liaisons must be coordinated by the Team due to requirements for public communication; + patent, + copyright, + and other IPR policies; + confidentiality agreements; + and mutual membership agreements.

+

W3C may negotiate technical agreements with another organization. + For purposes of the W3C Process, + a technical agreement is a formal contract, + or a Memorandum of Understanding (MoU), + or a similar document, + between W3C and another party or parties, + that relates to the technical activity of the Consortium + (e.g., its publications, groups, or liaisons). + It specifies rights and obligations of each party toward the others. + These rights and obligations may include joint deliverables, + an agreed share of technical responsibilities with due coordination, + and/or considerations for confidentiality and specific IPR.

+

Non-technical agreements, including + those between W3C and its Members for the purposes of membership, + between W3C and its Partners for the purposes of partnership [BYLAWS], + and other agreements related to the operation of the Consortium + or to the ordinary provision of services, + are not subject to these Process provisions.

+

When considering a technical agreement (i.e., before the decision whether to sign is made), + the Team should provide + the Advisory Committee with a draft of the proposed agreement, + along with an explanation of how W3C would benefit from signing this agreement, + for their review and discussion. + After addressing any comments, + and subject to any management or governance procedures that apply + (e.g., formal review of proposed contracts by legal counsel or by the Board), + if the Team decides to proceed with signing the agreement, + the Team must announce the intent to sign, + and provide the final text of the agreement, + with an explanation of signing rationale, to + the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the agreement. + If the proposal is rejected on appeal, + the Team must not sign the agreement on behalf of W3C + unless directed to do so by the Board. + A signed agreement should be made public.

+

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

+

9. Member Submissions

+

A Member Submission is a document or set of documents + developed outside of W3C, + and submitted to W3C + by one or more Members (the Submitter(s)) + to propose technology or other ideas. + After review, + the Team may make the material available at the W3C website.

+

Making a Member Submission available at the W3C website + does not indicate endorsement, acceptance, or adoption by W3C, + its Team, or its Members. + The acknowledgment of a Submission request + does not imply that any action will be taken by W3C. + It merely records publicly + that the Submission has been made by the Submitter(s). + A Member Submission made available by W3C + is not a W3C technical report and must not be referred to as + an output or “work in progress” of W3C.

+

The Member Submission process consists of the following steps:

+
+
Submission +
One of the Submitters, + copying the Advisory Committee representatives of the other Submitters (if any), + sends a request to the Team to acknowledge the Submission request. + The Team and Submitter(s) communicate to ensure that the Member Submission is complete. +
Review +
+ The Team reviews the Submission + to evaluate its scope, quality, and compliance with the Submission requirements, + including licensing requirements: + +

Detailed procedures and requirements are defined by the Team and documented in the “Member submissions guidebook” [MEMBER-SUB].

+
Decision +
+ After review, the Team must either acknowledge or reject the Submission request. + +
+

The Advisory Committee representative(s) of the Submitter(s) may initiate a Submission Appeal. + The procedure for handling Submission Appeals is the same as for Formal Objections, + except that an AC Appeal is not possible + and both the Formal Objection and the Council Report are confidential to the Team, TAG, and AB.

+

10. Process Evolution

+

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, + with the Advisory Board—​acting as the sponsoring Working Group. + The documents may be developed by the AB or by another group to whom the AB has delegated development. + Review includes + soliciting input from the W3C community, + and in particular the Team.

+

The documents covered by this section are:

+ +

The Advisory Board initiates review as follows:

+
    +
  1. The Team sends a Call for Review to the Advisory Committee and other W3C groups. +
  2. After comments have been formally addressed and the document possibly modified, + the Team seeks endorsement from the Members by initiating an Advisory Committee review. + The review period must last at least 28 days. +
  3. After the Advisory Committee review, + following a W3C decision to adopt the document(s), + the Team does so + and sends an announcement to the Advisory Committee. + Advisory Committee representatives may initiate + an Advisory Committee Appeal to W3C. +
+

Note: As of June 2020, + the Patent Policy is developed in the Patents and Standards Interest Group, + the Code of Conduct in the Positive Work Environment Community Group, + and the Process in the W3C Process Community Group.

+

Appendix A: Retired Terminology

+

This section is non-normative.

+

Previous versions of this process defined and used various concepts and document statuses + that have since been retired or renamed. + For ease of reference, + this appendix lists the more notable ones, + and it links to the the definition or relevant section + in the most recent version of the Process that used them, + and gives the more recent equivalent term when there is one.

+
+
Amended Recommendation (retired term) +
Last defined in section 6.2.1 of the 2020 Process. +
Edited Recommendation (retired term) +
Last defined in section 6.1.2 of the 2019 Process. +
Last Call (retired term) +
Last defined in section 7.4.2 of the 2005 Process. +
Maturity level (renamed term) +
Last defined in section 6.3.1 of the 2021 Process, + now called maturity stage. +
Member Consortium, plural: Member Consortia + (renamed term) +
Last defined in section 2.1.2.1 of the 2021 Process, + now called Member Association. +
Memorandum of Understanding, plural: Memoranda of Understanding, abbreviation: MoU + (renamed term) +
Last defined in section 9 of the 2021 Process, + now called technical agreement. +
Other Charter (renamed term) +
Last used in section 5.2.6 of the 2020 Process, + now called Exclusion Draft Charter. +
Proposed Recommendation (retired term) +
Last defined in section 6.3.1 of the 2023 Process. +
Team Submissions (retired term) +
Last defined in section 2.2.1 of the 2019 Process. +
W3C Chair (renamed term) +
Last defined in section 2.2 of the 2014 Process, + now called CEO. +
+

Appendix B: Acknowledgments

+

This section is non-normative.

+

The editors are grateful to the following people, + who as interested individuals and/or with the affiliation(s) listed, + have contributed to this proposal for a revised Process: + Adam Basha, + Anna Weinberg (Apple) + Charles McCathie Nevile, + Chris Lilley (W3C), + Chris Needham (BBC), + Chris Wilson (Google), + Coralie Mercier (W3C), + David W. Singer (Apple), + Denis Ah-Kang (W3C), + Dominique Hazael-Massieux (W3C), + Ian Jacobs (W3C), + Jeffrey Yasskin (Google), + Jill Schmidt (Apple), + Marcos Cáceres (Apple), + Mark Nottingham, + Martin Thomson (Mozilla), + Michael Champion, + Michael Sirtori (Intel), + Mike Smith (W3C), + Nick Doty (Center for Democracy and Technology), + Nigel Megitt (BBC), + Philippe Le Hégaret (W3C), + Sam Sneddon (Apple), + Shawn Lawton Henry (W3C), + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Theresa O’Connor (Apple), + Vivien Lacourba (W3C).

+

The editors are sorry for forgetting any names, + and grateful to those who have listened patiently to conversations about this document + without feeling a need to add more.

+

The following individuals contributed to the development of earlier versions of the Process: + Alex Russell (Google), + Andreas Tai (Institut fuer Rundfunktechnik), + Andrew Betts (Fastly), + Ann Bassetti (The Boeing Company), + Anne van Kesteren, + Art Barstow (Nokia, unaffiliated), + Bede McCall (MITRE), + Ben Wilson, + Brad Hill (Facebook), + Brian Kardell (JQuery, Igalia), + Carine Bournez (W3C), + Carl Cargill (Netscape, Sun Microsystems, Adobe), + Charles McCathie Nevile (ConsenSys), + Chris Lilley (W3C), + Chris Needham (BBC), + Chris Wilson (Google), + Claus von Riegen (SAP AG), + Coralie Mercier (W3C), + Cullen Jennings (Cisco), + Dan Appelquist (Telefonica, Samsung), + Dan Connolly (W3C), + Daniel Dardailler (W3C), + Daniel Glazman (Disruptive Innovations), + David Baron (Mozilla), + David Fallside (IBM), + David W. Singer (Apple), + David Singer (IBM), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Don Brutzman (Web3D), + Don Deutsch (Oracle), + Eduardo Gutentag (Sun Microsystems), + Elika J. Etemad aka fantasai, + Florian Rivoal, + Fuqiao Xue (W3C), + Geoffrey Creighton (Microsoft), + Giri Mandyam (Qualcomm), + Gregg Kellogg, + Hadley Beeman, + Håkon Wium Lie (Opera Software), + Helene Workman (Apple), + Henri Sivonen (Mozilla), + Ian Hickson (Google), + Ian Jacobs (W3C), + Ivan Herman (W3C), + J Alan Bird (W3C), + Jay Kishigami 岸上順一 (NTT), + Jean-Charles Verdié (MStar), + Jean-François Abramatic (IBM, ILOG, W3C), + Jeff Jaffe (W3C), + Jeffrey Yasskin (Google), + Jim Bell (HP), + Jim Miller (W3C), + Joe Hall (CDT), + John Klensin (MCI), + Josh Soref (BlackBerry, unaffiliated), + Judy Brewer (W3C), + Judy Zhu 朱红儒 (Alibaba), + Kari Laihonen (Ericsson), + Karl Dubost (Mozilla), + Ken Laskey (MITRE), + Kevin Fleming (Bloomberg), + Klaus Birkenbihl (Fraunhofer Gesellschaft), + Larry Masinter (Adobe Systems), + Lauren Wood (unaffiliated), + Léonie Watson (The Paciello Group), + Liam Quin (W3C), + Marcos Cáceres (Mozilla), + Maria Courtemanche (IBM), + Mark Crawford (SAP), + Mark Nottingham, + Michael Champion (Microsoft), + Michael Geldblum (Oracle), + Mike West (Google), + Mitch Stoltz (EFF), + Natasha Rooney (GSMA), + Nigel Megitt (BBC), + Olle Olsson (SICS), + Ora Lassila (Nokia), + Paul Cotton (Microsoft), + Paul Grosso (Arbortext), + Peter Linss, + Peter Patel-Schneider, + Philippe Le Hégaret (W3C), + Qiuling Pan (Huawei), + Ralph Swick (W3C), + Renato Iannella (IPR Systems), + Rigo Wenning (W3C), + Rob Sanderson (J Paul Getty Trust), + Robin Berjon (W3C), + Sally Khudairi (W3C), + Sam Ruby (IBM), + Sam Sneddon, + Samuel Weiler (W3C), + Sandro Hawke (W3C), + Sangwhan Moon (Odd Concepts), + Scott Peterson (Google), + Shawn Lawton Henry, + Steve Holbrook (IBM), + Steve Zilles (Adobe Systems) + Steven Pemberton (CWI), + TV Raman (Google), + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Terence Eden (Her Majesty’s Government), + Thomas Reardon (Microsoft), + Tim Berners-Lee (W3C), + Tim Krauskopf (Spyglass), + Travis Leithead (Microsoft), + Virginia Fournier (Apple), + Virginie Galindo (Gemalto), + Wayne Carr (Intel), + Wendy Fong (Hewlett-Packard), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

Appendix C: Changes

+

This section is non-normative.

+

Changes since the 3 November 2023 Process

+

This document is based on the 3 November 2023 Process. + A list of issues addressed, + a diff from Process 2023 to this latest version, + as well as + a detailed log of all changes since then are available.

+

In addition to a number of editorial adjustments and minor tweaks, the following is a summary of the main differences:

+
+
Changes to technical reports and their publication +
+
    +
  • Retire the Proposed Recommendation phase of the Recommendation track. It was only used as a short-lived transition + during which various verifications and votes about CR were done. + These can be done on a CR + without having to republish it as a separate thing. + This simplifies the Process without changing the actual quality or consensus expectations. + (See Issue 861) +
  • Retire “Streamlined Publication Approval”. + This was meant to enable REC track publication with fewer/faster approval steps + when some stricter than usual criteria were fulfilled. + However, regular REC track publication have improved enough + that this became unnecessary, + and nobody was using it. + (See Issue 856) +
  • Add a requirement to make progress on external issues for update requests + (See Issue 781) +
  • Drop the requirement to publish every 6 months if nothing has changed. + (See Issue 1013) +
  • Enable Team to replace defunct registry custodians when no-one else can. + (See Issue 699) +
  • Allow registries to be published by Interest Groups, the Advisory Board, and the TAG, + in addition to Working Groups. + (See Issue 902) +
  • Rename “registry sections” to embedded registries to avoid confusion over whether they can be split across multiple sections of a Recommendation. + (See Issue 800) +
  • Rename "Draft Note" into "Note Draft", + and "Draft Registry" into "Registry Draft" + to be consistent with other statuses that uses the word "Draft", + and to make that word stand out more. + (See Issue 779) +
  • Clarify the definition of a Registry (see Issue 800) + and of Recommendation Track Documents (see Pull Request 831). +
  • Consolidate and harmonize into a one section the various parts of the Process + that described whether and how the Team can maintain technical reports + that no longer have a Group chartered to maintain them. + (See Pull Request 860) +
+
Changes to chartering +
+ +
Changes to formal decision making and escalation +
+
    +
  • Adjust the rules guiding initiation of Councils, + to make the deadline strict, + and to provide a fallback mechanism if they are not met. + (See Pull Request 925) +
  • Make the Council’s short-circuit a little more flexible. + (See Issue 852) +
  • Exclude TAG/AB Members from voting on TAG/AB proposals in Councils. + (See Issue 749) +
  • Limit the involvement of Tim Berners-Lee to the TAG proper, + not including the Council. + (See Pull Request 792) +
  • Council dismissal vote counts must be reported. + (See Issue 748) +
  • Require documentation of how Formal Objections get resolved. + (See Issue 953) +
  • Put constraints on the timing of making Formal Objections public. + (See Issue 735) +
  • Fine-tune the rules about + how changes can be incorporated into a proposal + following an AC Review. + (See Issue 825) +
  • Adjust AC appeal vote threshold based on participation, + aligning with the thresholds and super majority requirements + for "Requisite Member Vote" from the W3C Bylaws. + (See Issue 886) +
  • Let the originator of a proposal decide whether to try again + after addressing feedback + following an AC Appeal. + (See Issue 844) +
  • Simplify provisions regarding substitute representatives and proxies. + (See Issue 373) +
+
Other changes +
+
    +
  • Reuse the bylaws’ notion of Good Standing, + and restrict TAG and AB elections + as well as AC Votes where a decision is made based on counting ballots + to Members in Good Standing. + (See Issue 935 and Pull Request 954) +
  • The section on Member Submissions was significantly shortened and simplified, + reducing the complexity under formal Process authority, + and shifting much of the material to /Guide, + under Team authority. + (See Issue 412 and Pull Request 936) +
  • Clarify how the outcome of certain ballots are determined. + (See Issue 836, Issue 838) +
  • Stop citing the superseded TAG charter. + (See Issue 794) +
  • Clarify amount of leeway around incomplete nominations to TAG or AB elections. + (See Issue 464) +
  • Shift most of the non-normative discussion about Workshops to [GUIDE], + and reorganize the remaining normative requirements. + (See Pull Request 876) +
  • The URL of this document was changed + from /Consortium/Process/ to /policies/process/ + for better integration in the W3C website architecture. +
+

Changes since earlier versions

+

Changes since earlier versions of the Process are detailed + in the changes section of the previous version of the Process.

+
+
+
+

Conformance

+

Document conventions

+

Conformance requirements are expressed + with a combination of descriptive assertions + and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text + with class="example", + like this:

+
+ +

This is an example of an informative example.

+
+

Informative notes begin with the word “Note” + and are set apart from the normative text + with class="note", + like this:

+

Note, this is an informative note.

+
+ +
+

Index

+

Terms defined by this specification

+ +

Terms defined by reference

+ +

References

+

Normative References

+
+
[COC] +
W3C Code of Conduct. URL: https://www.w3.org/policies/code-of-conduct/ +
[COLLABORATORS-AGREEMENT] +
Invited expert and collaborators agreement. URL: https://www.w3.org/invited-experts/agreement-2023/ +
[CONFLICT-POLICY] +
Conflict of Interest Policy for the W3C Team. URL: https://www.w3.org/policies/conflict-of-interest-policy-for-w3c-team/ +
[DOC-LICENSE] +
W3C Document License. URL: https://www.w3.org/copyright/document-license-2023/ +
[PATENT-POLICY] +
The W3C Patent Policy. URL: https://www.w3.org/policies/patent-policy/ +
[PATENT-POLICY-2004] +
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/ +
[PATENT-POLICY-2020] +
The W3C 2020 Patent Policy. URL: https://www.w3.org/policies/patent-policy/20200915/ +
[PUBRULES] +
Publication Rules. URL: https://www.w3.org/pubrules/ +
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
[RFC3797] +
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://www.rfc-editor.org/rfc/rfc3797 +
[W3C-PATENT-POLICY] +
Wendy Seltzer. W3C Patent Policy. 15 September 2020. URL: https://www.w3.org/policies/patent-policy/ +
+

Informative References

+
+
[AB-HP] +
The Advisory Board home page. URL: https://www.w3.org/2002/ab/ +
[AC-MEETING] +
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/events/ac/ +
[BG-CG] +
Community and Business Group Process. URL: https://www.w3.org/community/about/process/ +
[BYLAWS] +
Amended and Restated Bylaws of World Wide Web Consortium, Inc.. URL: https://www.w3.org/2024/09/25-w3c-bylaws.pdf +
[CALENDAR] +
Calendar of all scheduled official W3C events. URL: https://www.w3.org/events/ +
[CHAIR] +
W3C Working/Interest Group Chair. URL: https://www.w3.org/guide/chair/role +
[CHARTER] +
How to Create a Working Group or Interest Group. URL: https://www.w3.org/guide/process/charter +
[COUNCIL-REPORT-INDEX] +
Council Report Index. URL: https://www.w3.org/about/council/ +
[CURRENT-AC] +
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList +
[DECISION-APPEAL] +
Appealing a W3C Decision. URL: https://www.w3.org/guide/process/ac-appeal +
[ELECTION-HOWTO] +
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/guide/process/election +
[FELLOWS] +
W3C Fellows Program. URL: https://www.w3.org/careers/fellows/ +
[GROUP-MAIL] +
Group mailing lists. URL: https://www.w3.org/groups/ +
[GUIDE] +
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/guide/ +
[INTRO] +
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro +
[JOIN] +
How to Join W3C. URL: https://www.w3.org/membership/join/ +
[LIAISON] +
W3C liaisons with other organizations. URL: https://www.w3.org/liaisons/ +
[MEMBER-AGREEMENT] +
W3C Membership Agreement. URL: https://www.w3.org/membership/agreement/ +
[MEMBER-HP] +
Member website (Member-only access). URL: https://www.w3.org/Member/ +
[MEMBER-LIST] +
The list of current W3C Members. URL: https://www.w3.org/membership/list/ +
[MEMBER-SUB] +
Member submissions guidebook. URL: https://www.w3.org/submissions/guide/ +
[MISSION] +
The W3C Mission statement. URL: https://www.w3.org/mission/ +
[OBS-RESC] +
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/guide/process/obsolete-rescinded-supserseded +
[REC-TIPS] +
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/guide/standards-track/rec-tips +
[REPUBLISHING] +
In-place modification of W3C Technical Reports. URL: https://www.w3.org/guide/standards-track/republishing +
[SUBMISSION-LIST] +
The list of acknowledged Member Submissions. URL: https://www.w3.org/submissions/ +
[TAG-HP] +
The TAG home page. URL: https://www.w3.org/2001/tag/ +
[TEAM-CONTACT] +
Role of the Team Contact. URL: https://www.w3.org/guide/teamcontact/role +
[TR] +
The W3C technical reports index. URL: https://www.w3.org/TR/ +
[TRANSITION] +
Organize a Technical Report Transition. URL: https://www.w3.org/guide/transitions/ +
[TRANSLATION] +
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/ +
[W3C-IPR] +
W3C IPR Policies. URL: https://www.w3.org/policies/ +
+ + + diff --git a/snapshots/2025-06.html b/snapshots/2025-06.html new file mode 100644 index 00000000..4c8ecdc5 --- /dev/null +++ b/snapshots/2025-06.html @@ -0,0 +1,6505 @@ + + + + + W3C Process Document + + + + + + + + + + + + + + + + + + +
+

+

W3C Process Document

+

Draft Community Group Report,

+
+ More details about this document +
+
+
This version: +
https://www.w3.org/policies/process/drafts/snapshots/2025-06 +
Editor’s Draft: +
https://www.w3.org/policies/process/drafts/ +
Latest published version: +
https://www.w3.org/policies/process/ +
Previous Versions: +
+
Feedback: +
Github (preferred) +
Public mailing list +
Member-only mailing list +
Editors: +
Elika J. Etemad / fantasai (Apple) +
Florian Rivoal (Invited Expert) +
Former Editors: +
Natasha Rooney (Invited Expert) +
Charles McCathie Nevile (Yandex) +
Ian Jacobs (W3C) +
+
+
+
+

Copyright © 2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

+
+
+
+

Abstract

+

The mission of the World Wide Web Consortium (W3C) is making the web work, for everyone. +W3C brings together global stakeholders to develop open standards that enable a World Wide Web that connects and empowers humanity. +The W3C Process Document describes the organizational structure of W3C and processes, +responsibilities and functions that enable W3C to accomplish its mission. +This document does not describe the internal workings of the Team.

+

For more information about the W3C mission and the history of W3C, +please refer to About W3C.

+
+

Status of this document

+
+

W3C, including all existing chartered groups, + follows the most recent operative Process Document announced to the Membership.

+

This document is developed by the Advisory Board’s Process Task Force + working within the W3C Process Community Group (which anyone can join). + This is the 24 June 2025 Draft Community Group Report for the proposed next version of the W3C Process Document.

+

This document, +which is based on the 3 November 2023 Process, +is offered for W3C Advisory Committee Review of the proposal to adopt this +as the new operative Process document +per Section 11 Process Changes.

+

A history of substantial changes from previous versions of the Process Document is provided.

+
+
+ +
+

Relation of Process Document to Patent Policy and Other Policies

+

W3C Members' attention is called to the fact + that provisions of the Process Document are binding on Members + per their Membership Agreement [MEMBER-AGREEMENT]. + The W3C Patent Policy [PATENT-POLICY] and other policies + incorporated by normative reference as a part of the Process Document + are equally binding.

+

The Patent Policy and Code of Conduct place additional obligations on Members, Team, and other participants in W3C. + The Process Document does not restate those requirements but includes references to them. + The Process Document, Patent Policy, and Code of Conduct have been designed to allow each to evolve independently.

+

In the Process Document, the term “participant” refers to an individual, not an organization.

+

Conformance and specialized terms

+

The terms must, must not, should, should not, required, + and may are used in accordance with RFC 2119. + The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

+

Some terms have been capitalized in this document (and in other W3C materials) + to indicate that they are entities with special relevance to the W3C Process. + These terms are defined within this document, + and readers are reminded that the ordinary English definitions are insufficient + for the purpose of understanding this document.

+ +
+

1. Introduction

+

W3C work revolves around the standardization of Web technologies. + To accomplish this work, W3C follows processes that promote the development of high-quality standards + based on the consensus of the Membership, Team, and public. + W3C processes promote fairness, responsiveness, and progress: + all facets of the W3C mission. + This document describes the processes W3C follows in pursuit of its mission.

+

The W3C Process promotes the goals of quality and fairness in technical decisions + by encouraging consensus, + soliciting reviews (by both Members and public), + incorporating implementation and interoperability experience, + and requiring Membership-wide approval as part of the technical report development process. Participants in W3C include representatives of its Members and the Team, + as well as Invited Experts who can bring additional expertise or represent additional stakeholders. Team representatives both contribute to the technical work + and help ensure each group’s proper integration with the rest of W3C.

+

W3C’s technical standards, called W3C Recommendations, + are developed by its Working Groups; + W3C also has other types of publications, + all described in § 6 W3C Technical Reports. + W3C has various types of groups; + this document describes the formation and policies + of its chartered Working Groups and Interest Groups, + see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. + W3C also operates Community and Business Groups, + which are separately described in their own process document [BG-CG].

+

In addition, several groups are formally established by the Consortium: + the W3C Advisory Committee, which has a representative from each Member, + and two oversight groups elected by its membership: + the Advisory Board (AB), + which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process; + and the Technical Architecture Group (TAG), + which helps resolve Consortium-wide technical issues.

+

Here is a general overview of how W3C initiates standardization of a Web technology:

+
    +
  1. People generate interest in a particular topic. + For instance, Members express interest by developing proposals in Community Groups + or proposing ideas in Member Submissions. + Also, the Team monitors work inside and outside of W3C for signs of interest, + and helps organize Workshops to bring people together + to discuss topics that interest the W3C community. +
  2. When there is enough interest and an engaged community, + the Team works with the Membership + to draft proposed Interest Group or Working Group charters. + W3C Members review the proposed charters, + and when there is support within W3C for investing resources in the topic of interest, + W3C approves the group(s), + and they begin their work. +
+

Further sections of this Process Document deal with topics including + liaisons (§ 8 Liaisons), + confidentiality (§ 7 Dissemination Policies), + and formal decisions and appeals (§ 5 Decisions).

+

2. Members and the Team

+

W3C’s mission is to lead the Web to its full potential. + W3C Member organizations provide resources to this end, + and the W3C Team provides the technical leadership + and organization to coordinate the effort.

+

2.1. Members

+

W3C Members are + organizations subscribed according to a Membership Agreement [MEMBER-AGREEMENT]. + They are represented in W3C processes as follows:

+
    +
  1. One representative per Member organization participates + in the Advisory Committee which oversees the work of W3C. +
  2. Representatives of Member organizations participate + in Working Groups and Interest Groups, + where they author and review technical reports. +
+

W3C membership is open to all entities, + as described in “How to Join W3C” [JOIN]; + (refer to the public list of current W3C Members [MEMBER-LIST]). + The Team must ensure + that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

+

While W3C does not have a class of membership tailored to individuals, + individuals may join W3C. + Restrictions pertaining to related Members apply + when the individual also represents another W3C Member.

+

2.1.1. Rights of Members

+

Each Member organization enjoys the following rights and benefits:

+ +

Furthermore, subject to further restrictions included in their Member Agreement, + representatives of Member organizations participate in W3C as follows:

+ +

The rights and benefits of W3C membership [MEMBER-AGREEMENT] are contingent upon conformance to the processes described in this document. + Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.

+

Additional information for Members is available at the Member website [MEMBER-HP].

+

2.1.2. Member Associations and Related Members

+
2.1.2.1. Membership Associations
+

A “Member Association” means a consortium, + user society, + or association of two or more individuals, + companies, + organizations or governments, + or any combination of these entities + which has the purpose of participating in a common activity + or pooling resources to achieve a common goal other than participation in, + or achieving certain goals in, + W3C. + A joint-stock corporation or similar entity is not a Member Association merely because it has shareholders or stockholders. + If it is not clear whether a prospective Member qualifies as a Member Association, + the CEO may reasonably make the determination. + For a Member Association, the rights and privileges of W3C Membership + described in the W3C Process Document extend to the Member Association’s paid staff + and Advisory Committee representative.

+

Member Associations may also designate + up to four (or more at the Team’s discretion) individuals + who, though not employed by the organization, may exercise the rights of Member representatives.

+

For Member Associations that have individual people as members, + these individuals must disclose their employment affiliation + when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For Member Associations that have organizations as Members, + all such designated representatives must be an official representative of the Member organization + (e.g. a Committee or Task Force Chairperson) + and must disclose their employment affiliation when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For all representatives of a Member Association, + IPR commitments are made on behalf of the Member Association, + unless a further IPR commitment is made by the individuals' employers.

+
2.1.2.2. Related Members
+

In the interest of ensuring the integrity of the consensus process, + Member involvement in some of the processes in this document is affected by related Member status. + As used herein, two Members are related if:

+
    +
  1. Either Member is a subsidiary of the other, or +
  2. Both Members are subsidiaries of a common entity, or +
  3. The Members have an employment contract or consulting contract that affects W3C participation. +
+

A subsidiary is an organization of which effective control and/or majority ownership rests with another, + single organization.

+

Related Members must disclose these relationships + according to the mechanisms described in the New Member Orientation [INTRO].

+

2.1.3. Good Standing

+

Members who have not lost Good Standing as defined in the Amended and Restated Bylaws of World Wide Web Consortium, Inc. are considered, for the purposes of this Process, + to be in Good Standing. + A group of related Members is in Good Standing if + at least one of them is in Good Standing.

+

2.2. The W3C Team

+

The Team consists of CEO, + W3C paid staff, + unpaid interns, + and W3C Fellows. W3C Fellows are Member employees working as part of the Team; + see the W3C Fellows Program [FELLOWS]. + The Team provides technical leadership about Web technologies, + organizes and manages W3C activities to reach goals + within practical constraints (such as resources available), + and communicates with the Members and the public + about the Web and W3C technologies.

+

The CEO may delegate responsibility + (generally to other individuals in the Team) + for any of their roles described in this document. Team Decisions derive from the CEO’s authority, + even when they are carried out by other members of the Team.

+

Oversight over the Team, + budgeting, + and other business decisions, + is provided by the W3C Board of Directors, + rather than managed directly by the Process.

+

Note: See the W3C Bylaws for more details + on the Board and overall governance of W3C.

+

3. Groups and Participation

+

For the purposes of this Process, a W3C Group is one of W3C’s Working Groups, Interest Groups, Advisory Committee, Advisory Board, + or TAG, + and a participant is a member of such a group.

+

3.1. Policies for Participation in W3C Groups

+

3.1.1. Individual Participation Criteria

+
3.1.1.1. Expectations and Discipline
+

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

+
    +
  1. Technical competence in one’s role; +
  2. The ability to act fairly; +
  3. Social competence in one’s role. +
+

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities + are responsible for assessing and attesting to the qualities of those nominees.

+

Participants in any W3C activity must abide + by the terms and spirit of the W3C Code of Conduct [COC] and the participation requirements described in + “Disclosure” + in the W3C Patent Policy [PATENT-POLICY].

+

The CEO may take disciplinary action, + including suspending or removing for cause + a participant in any group (including the AB and TAG) + if serious and/or repeated violations, + such as failure to meet the requirements on individual behavior of + (a) this process + and in particular the Code of Conduct, or + (b) the membership agreement, or + (c) applicable laws, + occur. + Refer to the Guidelines to suspend or remove participants from groups.

+
3.1.1.2. Conflict of Interest Policy
+

Individuals participating materially in W3C work must disclose significant relationships + when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. + These disclosures must be kept up-to-date + as the individual’s affiliations change and W3C membership evolves + (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). + Each section in this document that describes a W3C group + provides more detail about the disclosure mechanisms for that group.

+

The ability of an individual to fulfill a role within a group + without risking a conflict of interest depends on the individual’s affiliations. + When these affiliations change, + the individual’s assignment to the role must be evaluated. + The role may be reassigned according to the appropriate process. + For instance, + the Team may appoint a new group Chair when the current Chair changes affiliations + (e.g., if there is a risk of conflict of interest, + or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

+

The following are some scenarios where disclosure is appropriate:

+
    +
  • Paid consulting for an organization whose activity is relevant to W3C, + or any consulting compensated with equity + (shares of stock, stock options, or other forms of corporate equity). +
  • A decision-making role/responsibility + (such as participating on a Board) + in other organizations relevant to W3C. +
  • A position on a publicly visible advisory body, + even if no decision-making authority is involved. +
+

Individuals seeking assistance on these matters should contact the Team.

+

Team members are subject to the Conflict of Interest Policy for the W3C Team [CONFLICT-POLICY].

+
3.1.1.3. Individuals Representing a Member Organization
+

Generally, individuals representing a Member in an official capacity within W3C + are employees of the Member organization. + However, an Advisory Committee representative may designate a non-employee + to represent the Member. + Non-employee Member representatives must disclose + relevant affiliations to the Team and to any group in which the individual participates.

+

In exceptional circumstances + (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), + the CEO may decline + to allow an individual designated by an Advisory Committee representative to participate in a group.

+

A group charter may limit + the number of individuals representing a W3C Member + (or group of related Members).

+

3.1.2. Meetings

+

The requirements in this section apply to the official meetings of any W3C group, + as well as to official W3C meetings with open-ended participation from the Membership and/or the public, + such as Workshops.

+

W3C distinguishes two types of meetings:

+
    +
  1. A face-to-face meeting is one + where most of the attendees are expected to participate in the same physical location. +
  2. A distributed meeting is one + where most of the attendees are expected to participate from remote locations + (e.g., by telephone, video conferencing, or IRC). +
+

A Chair may invite an individual with a particular expertise + to attend a meeting on an exceptional basis. + This person is a meeting guest, + not a group participant. + Meeting guests do not have voting rights. + It is the responsibility of the Chair to ensure + that all meeting guests respect the chartered level of confidentiality and other group requirements.

+
3.1.2.1. Meeting Scheduling and Announcements
+

Meeting announcements should be sent to all appropriate group mailing lists, + i.e. those most relevant to the anticipated meeting participants.

+

The following table lists recommendations for organizing a meeting:

+ + + + + + + + + +
+ Face-to-face meetings + Distributed meetings +
Meeting announcement (before) + eight weeks* + one week* +
Agenda available (before) + two weeks + 24 hours (or longer if a meeting is scheduled after a weekend or holiday) +
Participation confirmed (before) + three days + 24 hours +
Action items available (after) + three days + 24 hours +
Minutes available (after) + two weeks + 48 hours +
+

* To allow proper planning (e.g., travel arrangements), + the Chair is responsible for giving sufficient advance notice + about the date and location of a meeting. + Shorter notice for a meeting is allowed + provided that there are no objections from group participants. + In the case of Workshops, + shorter notice is not allowed.

+
3.1.2.2. Meeting Minutes
+

Groups should take and retain minutes of their meetings, + and must record + any official group decisions made during the meeting discussions. + Details of the discussion leading to such decisions are not required, + provided that the rationale for the group decision is nonetheless clear.

+
3.1.2.3. Meeting Recordings and Transcripts
+

No-one may take an audio or video recording of a meeting, + or retain an automated transcript, + unless the intent is announced at the start of the meeting, + and no-one participating in the recorded portion of the meeting withholds consent. + If consent is withheld by anyone, recording/retention must not occur. + The announcement must cover: + (a) who will have access to the recording or transcript and + (b) the purpose/use of it and + (c) how it will be retained (e.g. privately, in a cloud service) and for how long.

+

3.1.3. Tooling and Archiving for Discussions and Publications

+

For W3C Groups operating under this Process, + a core operating principle is to allow access across disabilities, + across country borders, + and across time. + Thus in order to allow all would-be participants to effectively participate, + to allow future participants and observers to understand the rationale and origins of current decisions, + and to guarantee long-lived access to its publications, + W3C requires that:

+
    +
  • All reports, publications, or other deliverables + produced by the group for public consumption + (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, + and backed up by W3C systems + such that if the underlying service is discontinued, + W3C can continue to serve such content without breaking incoming links + or other key functionality. +
  • All reports, publications, or other deliverables + produced by the group for public consumption should follow best practices for internationalization + and for accessibility to people with disabilities. + Network access to W3C-controlled domains may be assumed. +
  • + Official meeting minutes and other records of decisions made must be archived by W3C for future reference; + and other persistent text-based discussions + sponsored by the group, + pertaining to their work + and intended to be referenceable by all group members should be. + This includes discussions conducted over email lists + or in issue-tracking services + or any equivalent fora. + Materials referenced from discussions + and necessary to understand them + should be available at a stable URL, + at a level of confidentiality no stricter than the discussion minutes. +

    Note: The lack, or loss, of such archives does not by itself + invalidate an otherwise-valid decision.

    +
  • + Any tooling used by the group + for producing its documentation and deliverables + or for official group discussions should be usable + (without additional cost) + by all who wish to participate, + including people with disabilities, + to allow their effective participation. +

    Note: If a new participant joins who cannot use the tool, + this can require the Working Group to change its tooling + or operate some workaround.

    +
  • All tools and archives used by the group + for its discussions and recordkeeping should be documented + such that new participants and observers + can easily find the group’s tools and records. +
+

The Team is responsible for ensuring adherence to these rules + and for bringing any group not in compliance into compliance.

+

3.1.4. Resignation from a Group

+

A W3C Member or Invited Expert may resign from a group. + On written notification from an Advisory Committee representative + or Invited Expert + to the Team, + the Member and their representatives + or the Invited Expert + will be deemed to have resigned from the relevant group. + The Team must record the notification. + See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

+

3.2. The Advisory Committee (AC)

+

3.2.1. Role of the Advisory Committee

+

The Advisory Committee represents + the Members of W3C at large. + It is responsible for:

+ +

Advisory Committee representatives may initiate + an Advisory Committee Appeal of a W3C decision or Team’s decision.

+

See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

+

3.2.2. Participation in the Advisory Committee

+

The Advisory Committee is composed of one representative from each Member organization + (refer to the Member-only list + of current Advisory Committee representatives. [CURRENT-AC])

+

When an organization joins W3C + (see “How to Join W3C” [JOIN]), + it must name its Advisory Committee representative as part of their Membership Agreement. + The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, + provides information about Advisory Committee Meetings, + explains how to name a new Advisory Committee representative, + and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.

+

The AC representative may delegate any of their rights and responsibilities + to an alternate (except the ability to designate an alternate).

+

3.2.3. Advisory Committee Mailing Lists

+

The Team must provide two mailing lists for use by the Advisory Committee:

+
    +
  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. + This list is read-only for Advisory Committee representatives. +
  2. One for discussion among Advisory Committee representatives. + Though this list is primarily for Advisory Committee representatives, + the Team must monitor discussion + and should participate in discussion when appropriate. + Ongoing detailed discussions should be moved to other appropriate lists + (new or existing, such as a mailing list created for a Workshop). +
+

An Advisory Committee representative may request + that additional individuals from their organization be subscribed to these lists. + Failure to contain distribution internally may result in suspension of additional email addresses, + at the discretion of the Team.

+

3.2.4. Advisory Committee Meetings

+

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. + The Team appoints the Chair of these meetings (generally the CEO). + At each Advisory Committee meeting, + the Team should provide an update to the Advisory Committee about:

+
+
Resources +
+
    +
  • The number of W3C Members at each level. +
  • An overview of the financial status of W3C. +
+
Allocations +
+
    +
  • The allocation of the annual budget, including size of the Team and their approximate deployment. +
  • A list of all activities (including but not limited to Working and Interest Groups) + and brief status statement about each, + in particular those started or terminated since the previous Advisory Committee meeting. +
  • The allocation of resources to pursuing liaisons with other organizations. +
+
+

Each Member organization should send one representative to each Advisory Committee Meeting. + In exceptional circumstances + (e.g., during a period of transition between representatives from an organization), + the meeting Chair may allow a Member organization to send two representatives to a meeting.

+

The Team must announce the date and location of each Advisory Committee meeting + no later than at the end of the previous meeting; one year’s notice is preferred. + The Team must announce the region of each Advisory Committee meeting + at least one year in advance.

+

More information about Advisory Committee meetings [AC-MEETING] is available at the Member website.

+

3.3. Elected Groups: The AB and the TAG

+

The W3C Process defines two types of elected groups: + the Advisory Board (AB) and + the Technical Architecture Group (TAG), + both elected by the Advisory Committee.

+

3.3.1. Advisory Board (AB)

+
3.3.1.1. Role of the Advisory Board
+

The Advisory Board provides ongoing guidance to the Team + on issues of strategy, + management, + legal matters, + process, + and conflict resolution. + The Advisory Board also serves the Members + by tracking issues raised between Advisory Committee meetings, + soliciting Member comments on such issues, + and proposing actions to resolve these issues. + The Advisory Board manages the evolution of the Process Document. + As part of a W3C Council, + members of the Advisory Board hear and adjudicate on Submission Appeals and Formal Objections.

+

The Advisory Board is distinct from the Board of Directors and has no decision-making authority within W3C; + its role is strictly advisory.

+

Note: While the AB as such does not have decision-making authority, + its members do when sitting as part of a W3C Council.

+

Details about the Advisory Board + (e.g., the list of Advisory Board participants, + mailing list information, and summaries of Advisory Board meetings) + are available at the Advisory Board home page [AB-HP].

+
3.3.1.2. Composition of the Advisory Board
+

The Advisory Board consists of nine to eleven elected participants and one Chair + (who may be one of the elected participants). + With the input of the AB, + the Team appoints the Chair, + who should choose a co-chair among the elected participants. + Upon appointment, + the Chair(s) are subject to ratification by secret ballot, + requiring approval by two thirds of the elected participants. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The team also appoints a Staff Contact, + as described in § 3.4.1 Requirements for All Chartered Groups. + The CEO and Staff Contact have a standing invitation + to all regular Advisory Board sessions.

+

The nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

+

The terms of elected Advisory Board participants are for two years. + Terms are staggered so that each year, + either five or six terms expire. + If an individual is elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular Advisory Board terms begin on 1 July and end on 30 June.

+
3.3.1.3. Communications of the Advisory Board
+

The Team must make available a mailing list, + confidential to the Advisory Board and Team, + for the Advisory Board to use for its communication.

+

The Advisory Board should send a summary of each of its meetings + to the Advisory Committee and other group Chairs. + The Advisory Board should also report on its activities + at each Advisory Committee meeting.

+
3.3.1.4. Liaisons between the Advisory Board and the Board of Directors
+

To ensure good communication between the AB and the Board of Directors and facilitate operational and management consistency, + the AB may appoint up to two of its participants as liaisons to the Board. + Such appointees are expected to attend and participate in Board meetings + and access Board materials + as Non-voting Observers. [BYLAWS] They do not form part of the Board’s decision-making body, + and may be excluded from such participation + in accordance with applicable Board procedures.

+

The Advisory Board should reevaluate + who is assigned to this role + at least at the beginning of each term, + and may swap its appointees more frequently + as they deem appropriate.

+

3.3.2. Technical Architecture Group (TAG)

+
3.3.2.1. Role of the Technical Architecture Group
+

The mission of the TAG is stewardship of the Web architecture. + There are three aspects to this mission:

+
    +
  1. to document and build consensus around principles of Web architecture + and to interpret and clarify these principles when necessary; +
  2. to resolve issues involving general Web architecture brought to the TAG; +
  3. to help coordinate cross-technology architecture developments inside and outside W3C. +
+

As part of a W3C Council, + the members of the TAG hear and adjudicate on Submission Appeals and Formal Objections.

+

The TAG’s scope is limited to technical issues about Web architecture. + The TAG should not consider + administrative, + process, + or organizational policy issues of W3C, + which are generally addressed by + the W3C Advisory Committee, + Advisory Board, + and Team.

+

When the TAG votes to resolve an issue, + each TAG participant + (whether appointed, elected, or the Chair) + has one vote; + see also the general section on votes in this Process Document.

+

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) + are available at the TAG home page [TAG-HP].

+
3.3.2.2. Composition of the Technical Architecture Group
+

The TAG consists of:

+ +

Participants in the TAG choose by consensus their Chair or co-Chairs; + in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG. + The Chair or co-Chairs must be selected from the participants of the TAG. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The Team also appoints a Staff Contact [TEAM-CONTACT] for the TAG, + as described in § 3.4.1 Requirements for All Chartered Groups.

+

The terms of TAG participants last for two years. + Terms are staggered so that four elected terms + and either one or two appointed terms expire each year. + If an individual is appointed or elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular TAG terms begin on 1 February and end on 31 January.

+
3.3.2.3. Communications of the Technical Architecture Group
+

The Team must make available two mailing lists for the TAG:

+
    +
  • a public discussion (not just input) list for issues of Web architecture. + The TAG will conduct its public business on this list. +
  • a Member-only list for discussions within the TAG + and for requests to the TAG that, + for whatever reason, cannot be made on the public list. +
+

The TAG may also request the creation of additional topic-specific, public mailing lists. + For some TAG discussions (e.g., a Submission Appeal), + the TAG may use a list that will be Member-only.

+

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. + The TAG should also report on its activities at each Advisory Committee meeting.

+

3.3.3. Participation in Elected Groups

+
3.3.3.1. Expectations for Elected Groups Participants
+

Advisory Board and TAG participants have a special role within W3C: + they are elected by the Membership and appointed by the Team with the expectation that they will use their best judgment + to find the best solutions for the Web, + not just for any particular network, + technology, + vendor, + or user. + Advisory Board and TAG participants are expected to participate regularly and fully. + Advisory Board and TAG participants should attend Advisory Committee meetings.

+

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, + to serve the needs of the W3C membership as a whole, + and the Web community. + Whether they are Member representatives or Invited Experts, + their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

+

An individual participates on the Advisory Board or TAG + from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). + Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, + their participation does carry the responsibilities associated with Member representation, + Invited Expert status, + or Team representation + (as described in the section on the AB/TAG nomination and election process).

+

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, + and a participant’s seat must not be delegated to any other person.

+
3.3.3.2. Elected Groups Participation Constraints
+

Given the few seats available on the Advisory Board and the TAG, + and in order to ensure that the diversity of W3C Members is represented:

+ +
3.3.3.3. Advisory Board and Technical Architecture Group Elections
+

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, + using a Single Transferable Vote system. + An election begins when the Team sends a Call for Nominations to the Advisory Committee. + Any Call for Nominations specifies the minimum and maximum number of available seats, + the deadline for nominations, + details about the specific vote tabulation system selected by the Team for the election, + and operational information such as how to nominate a candidate. + The Team may modify the tabulation system after the Call for Nominations + but must stabilize it no later than the Call for Votes. + The Team announces appointments + after the results of the election are known, + and before the start of the term, + as described in § 3.3.3.4 Technical Architecture Group Appointments.

+

In the case of regularly scheduled elections of the TAG, + the minimum and maximum number of available seats are the same: + the 4 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

+

In the case of regularly scheduled elections of the AB, + the minimum and maximum number of available seats differ: + The maximum number is the 5 or 6 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; + the minimum number is such that when added to the occupied seats from the prior year, + the minimum size of the AB (9) is reached.

+

Each Member (or group of related Members) may nominate one individual. + A nomination must be made with the consent of the nominee. + In order for an individual to be nominated as a Member representative, + the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination + the (same) information required for a Member representative in a Working Group. + In order for an individual to be nominated as an Invited Expert, + the individual must provide + the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. + In order for an individual to be nominated as a Team representative, + the nominating Advisory Committee representative must first secure approval from Team management. + A nominee is not required to be an employee of a Member organization, + and may be a W3C Fellow. + The nomination form must ask for the nominee’s primary affiliation, + and this will be reported on the ballot. + For most nominees, + the primary affiliation is their employer and will match their affiliation in the W3C database. + For contractors and invited experts, + this will normally be their contracting company + or their invited expert status; + in some cases + (e.g. where a consultant is consulting for only one organization) + this may be the organization for whom the nominee is consulting. + A change of affiliation is defined + such that this field would carry a different answer + if the nominee were to be re-nominated + (therefore, + terminating employment, + or accepting new employment, + are changes of affiliation). + (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) + Each nomination should include + a few informative paragraphs about the nominee. + If an identified candidate’s nomination information is only partially complete + as of the deadline for nominations, + the Team may allow extra time for that candidate’s nomination to be completed, + so long as it does not delay the election as a whole.

+

If, after the deadline for nominations, the number of nominees is:

+
    +
  • Greater than or equal to the minimum number of available seats + and less than or equal to the maximum number of available seats, + those nominees are thereby elected. + This situation constitutes a tie for the purpose of assigning incomplete terms. + Furthermore, if the number is less than the maximum number of available seats, + the longest terms are filled first. +
  • Less than the minimum number of available seats, + Calls for Nominations are issued until a sufficient number of people have been nominated. + Those already nominated do not need to be renominated after a renewed call. +
  • Greater than the maximum number of available seats, + the Team issues a Call for Votes + that includes the names of all candidates, + the (maximum) number of available seats, + the deadline for votes, + details about the vote tabulation system selected by the Team for the election, + and operational information. +
+

When there is a vote, + each Member in Good Standing (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. + Once the deadline for votes has passed, + the Team announces the results to the Advisory Committee. + In case of a tie the verifiable random selection procedure described below + will be used to fill the available seats.

+

The shortest incomplete term is assigned to the elected candidate ranked lowest by the tabulation of votes, + the next shortest term to the next-lowest ranked elected candidate, + and so on. + In the case of a tie among those eligible for a incomplete term, + the verifiable random selection procedure described below + will be used to assign the incomplete term.

+

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

+
3.3.3.4. Technical Architecture Group Appointments
+

The Team is responsible for appointing + 3 of the participants to the Technical Architecture Group. + This mechanism complements the election process. + The Team should use its appointments to support + a diverse and well-balanced TAG, + including diversity of technical background, knowledge, and skill sets.

+

The Team should actively seek + candidates for appointment to the TAG, + and must make available to + the W3C community at large + a means to propose candidates for consideration, + explicitly soliciting input from at least + current and incoming TAG members, the Advisory Committee, and Working Group Chairs.

+

The constraints for appointment to the TAG are + the same as for elected participants + (see § 3.3.3.2 Elected Groups Participation Constraints and § 3.3.3.3 Advisory Board and Technical Architecture Group Elections), + with the additional constraint that + a person must not be appointed + for more than two consecutive terms. + (Partial terms used to fill a vacated seat do not count towards this limit.)

+

Note: Since there are no limits on elected terms, + this limit on appointed terms does not constrain + term-limited appointees + from running for election at any time.

+

The Team’s choice of appointee(s) + is subject to ratification by secret ballot + by both the AB and the TAG, + requiring a two-thirds approval from each. + In the case of regularly scheduled elections, + the TAG participants in this ratification are + its members for the upcoming term.

+

For regularly scheduled elections, + selection begins once the results of the elections are known, + and the Team should announce the ratified appointment(s) + no later than the start of the regularly scheduled term. + When an appointed seat is vacated outside of a regularly scheduled election, + the Team should seek to appoint a replacement + unless a regular Call for Nominations is scheduled within 2 months, + and it must announce the ratified appointment + no later than the Call for Nominations of the next scheduled election.

+
3.3.3.5. Verifiable Random Selection Procedure
+

When it is necessary to use a verifiable random selection process + (e.g., in an AB or TAG election, + to “draw straws” in case of a tie + or to fill a incomplete term), + W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. + The procedure orders an input list of names + (listed in alphabetical order by family name unless otherwise specified) + into a “result order”.

+

W3C applies this procedure as follows:

+
    +
  1. When N people have tied for M (less than N) seats. + In this case, only the names of the N individuals who tied + are provided as input to the procedure. + The M seats are assigned in result order. +
  2. After all elected individuals have been identified, + when N people are eligible for M (less than N) incomplete terms. + In this case, only the names of those N individuals are provided as input to the procedure. + The incomplete terms are assigned in result order. +
+
3.3.3.6. Elected Groups Vacated Seats
+

An Advisory Board or TAG participant’s seat is vacated when:

+ +

If a participant changes affiliation, + but the participation constraints are met, + that participant’s seat becomes vacant at the next regularly scheduled election for that group.

+

Vacated seats are filled according to this schedule:

+
    +
  • When an appointed TAG seat is vacated, + the Team appoints a replacement. +
  • + When an elected seat on either the AB or TAG is vacated, + the seat is filled at the next regularly scheduled election for the group + unless the group Chair requests that W3C hold an election before then + (for instance, due to the group’s workload). +
      +
    • The group Chair should not request such an election + if the next regularly scheduled election is fewer than three months away. +
    • The group Chair may request an election, + and the election may begin, as soon as a current member gives notice of a resignation, + including a resignation effective as of a given date in the future. +
    +

    When such an election is held, + the minimum number of available seats is such that + when added to the number of continuing participants, + the minimum total number of elected seats is met + (8 for the TAG, 9 for the AB); + and the maximum number corresponds to all unoccupied seats. + Except for the number of available seats and the length of the terms, + the usual rules for Advisory Board and Technical Architecture Group Elections apply.

    +
+

3.4. Chartered Groups: Working Groups and Interest Groups

+

This document defines two types of chartered groups:

+
+
Working Groups. +
+ Working Groups typically produce deliverables + (e.g., Recommendation Track technical reports, + software, + test suites, + and reviews of the deliverables of other groups) + as defined in their charter. +

Working Groups have additional participation requirements + described in the W3C Patent Policy [PATENT-POLICY], + see particularly the “Licensing Obligations of Working Group Participants” + and the patent claim exclusion process + in “Exclusion From W3C RF Licensing Requirements”.

+
Interest Groups. +
+ The primary goal of an Interest Group + is to bring together people who wish to evaluate potential Web technologies and policies. + An Interest Group is a forum for the exchange of ideas. +

Interest Groups do not publish Recommendation Track technical reports; + but can publish technical reports on the Note Track.

+
+

3.4.1. Requirements for All Chartered Groups

+

Each group must have a charter. + Requirements for the charter depend on the group type. + All group charters must be public + (even if other proceedings of the group are Member-only).

+

Each group must have a Chair (or co-Chairs) + to facilitate effective discussion and coordinate the group’s activities. + The Team appoints (and re-appoints) Chairs for all groups. + The Chair is a Member representative, + a Team representative, + or an Invited Expert (invited by the Team). + The requirements of this document that apply to those types of participants apply to Chairs as well.

+

Note: The role of the Chair [CHAIR] is described + in the Art of Consensus [GUIDE].

+

Each group must have a Staff Contact (also known as Team Contact), + who acts as the interface between the Chair, + group participants, + and the rest of the Team.

+

Note: The role of the Staff Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE].

+

The Chair and the Staff Contact of a group should not be the same individual.

+

Each group must have an archived mailing list + for formal group communication + (e.g., for meeting announcements and minutes, + documentation of decisions, + and Formal Objections to decisions). + It is the responsibility of the Chair and Staff Contact to ensure that new participants are subscribed to all relevant mailing lists. + Refer to the list of group mailing lists [GROUP-MAIL].

+

A Chair may form task forces + (composed of group participants) + to carry out assignments for the group. + The scope of these assignments must not exceed the scope of the group’s charter. + A group should document the process it uses + to create task forces + (e.g., each task force might have an informal "charter"). + Task forces do not publish technical reports; + the Working Group may choose to publish their results as part of a technical report.

+

3.4.2. Participation in Chartered Groups

+

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, + and Team representatives (including the Staff Contact).

+

There are four types of individual participants in an Interest Group: + the same three types as for Working Groups plus, + for an Interest Group where the only participation requirement is mailing list subscription, public participants.

+

Except where noted in this document or in a group charter, + all participants share the same rights and responsibilities in a group; + see also the individual participation criteria.

+

A participant may represent more than one organization + in a Working Group or Interest Group. + Those organizations must all be members of the group.

+

An individual may become + a Working or Interest Group participant + at any time during the group’s existence. + See also relevant requirements in + “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY].

+

On an exceptional basis, + a Working or Interest Group participant may designate + a substitute to attend a meeting and should inform the Chair. + The substitute may act on behalf of the participant, + including for votes. + For the substitute to vote, + the participant must inform the Chair in writing in advance.

+

To allow rapid progress, + Working Groups are intended to be small + (typically fewer than 15 people) + and composed of experts in the area defined by the charter. + In principle, + Interest Groups have no limit on the number of participants. + When a Working Group grows too large to be effective, + W3C may split it into an Interest Group + (a discussion forum) + and a much smaller Working Group + (a core group of highly dedicated participants).

+

3.4.3. Types of Participants in Chartered Groups

+
3.4.3.1. Member Representative in a Working Group
+

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Advisory Committee representative of the Member in question + has designated the individual as a Working Group participant, and +
  • the individual qualifies for Member representation. +
+

To designate an individual as a Member representative in a Working Group, + an Advisory Committee representative must provide the Chair and Staff Contact with all of the following information, + in addition to any other information required by the Call for Participation and charter + (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

+
    +
  1. The name of the W3C Member the individual represents + and whether the individual is an employee of that Member organization; +
  2. A statement that the individual accepts the participation terms + set forth in the charter + (with an indication of charter date or version); +
  3. A statement that the Member will provide the necessary financial support for participation + (e.g., for travel, telephone calls, and conferences). +
+

A Member participates in a Working Group from the moment the first Member representative joins the group + until either of the following occurs:

+
    +
  • the group closes, or +
  • the Member resigns from the Working Group; + this is done through the Member’s Advisory Committee representative. +
+
3.4.3.2. Member Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

+ +

To designate an individual as a Member representative in an Interest Group, + the Advisory Committee representative must follow the instructions + in the Call for Participation and charter.

+

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

+
3.4.3.3. Invited Expert in a Working Group
+

The Chair may invite an individual with a particular expertise + to participate in a Working Group. + This individual may represent an organization in the group + (e.g., if acting as a liaison with another organization).

+

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Chair has designated the individual as a group participant, +
  • the Staff Contact has agreed with the Chair’s choice, and +
  • the individual has provided the information required of an Invited Expert to the Chair and Staff Contact. +
+

To designate an individual as an Invited Expert in a Working Group, + the Chair must inform the Staff Contact + and provide rationale for the choice. + When the Chair and the Staff Contact disagree about a designation, + the CEO determines + whether the individual will be invited to participate in the Working Group.

+

To participate in a Working Group as an Invited Expert, + an individual must:

+
    +
  • identify the organization, if any, the individual represents as a participant in this group, +
  • agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT], +
  • accept the participation terms set forth in the charter, + including the participation requirements of + the W3C Patent Policy [PATENT-POLICY], + especially in “Note on Licensing Commitments for Invited Experts” + and in “Disclosure”, + indicating a specific charter date or version, +
  • disclose whether the individual is an employee of a W3C Member; + see the conflict of interest policy, +
  • provide a statement of who will provide the necessary financial support + for the individual’s participation + (e.g., for travel, telephone calls, and conferences), and +
  • if the individual’s employer (including a self-employed individual) + or the organization the individual represents + is not a W3C Member, + indicate whether that organization intends to join W3C. + If the organization does not intend to join W3C, + indicate reasons the individual is aware of for this choice. +
+

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. + The Chair must not use Invited Expert status + to circumvent participation limits imposed by the charter.

+

An Invited Expert participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • the Chair or CEO withdraws the invitation to participate, or +
  • the individual resigns. +
+
3.4.3.4. Invited Expert in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

+
3.4.3.5. Team Representative in a Working Group
+

An individual is a Team representative in a Working Group when so designated by W3C management. + Team representatives both contribute to the technical work + and help ensure the group’s proper integration with the rest of W3C.

+

A Team representative participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • W3C management changes Team representation by sending email to the Chair, + copying the group mailing list. +
+

The Team participates in a Working Group + from the moment the creation of the group is announced + until the group closes.

+
3.4.3.6. Team Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Team representative in an Interest Group when so designated by W3C management.

+

4. Lifecycle of Chartered Groups

+

W3C creates charters for chartered groups based on W3C community interest. + W3C fosters awareness of charters, + improves their quality, + and gauges Membership support in two formal phases:

+ +

4.1. Initiating Charter Refinement

+

Charters can originate in many venues, + including existing Working or Interest Groups, + Community Groups, + and from the Membership. + Prior to the formal refinement phase, + the Team engages with those various parties + to help prepare charters for broader audiences.

+

Formal charter refinement (see below) is initiated + by the Team sending a charter review notice to the Advisory Committee, + to the public, + and, in the case of rechartering, to the affected Group.

+

This charter review notice must include:

+
    +
  • +

    A short summary of the proposal.

    +
  • +

    The location of the charter draft, which must be public.

    +
  • +

    How to participate in the discussion of this charter draft and where to file issues.

    +
  • +

    The expected duration of the charter refinement phase, +which must not be less than 28 days, +and should not be more than 6 months.

    +
  • +

    Who the Chartering Facilitator is.

    +
+

The Team is responsible for initiating charter refinement at its discretion, in consideration of discussions with the community.

+

An Advisory Committee representative may formally request + that the Team initiate charter refinement. + The Team may deny such a request + if it thinks the proposal is insufficiently mature, + does not align with W3C’s scope and mission, + or otherwise does not meet the charter assessment criteria + described in the Guide (see How to Create a Working Group or Interest Group), + and must reply with its rationale. + This rejection is a Team Decision, + and can be appealed only by 5 or more Members, + through their Advisory Committee representative, + formally objecting to the decision within 8 weeks of the decision being announced. + In this case the Team must start an appeal vote on whether to overturn the Team Decision. + (No action is required to be taken when fewer than 5 members object.)

+

4.2. Charter Refinement

+

During charter refinement, + the W3C community, + under the guidance of the Team, + further develops the charter draft with the goal of achieving consensus on the proposal. + The Chartering Facilitator—​who is chosen (and may be replaced) by the Team—​is responsible for seeking community consensus among those participating in the refinement process + and making decisions reflecting that consensus. + In cases where consensus cannot be found, + the Chartering Facilitator may ask the Team to make a Team Decision, + and must document the rationale for the decision.

+

Note: The Chartering Facilitator is not necessarily the Chair of the group being chartered.

+

During charter refinement:

+ +

Before the end of the announced duration + for the charter refinement phase, + the Team (informed by the work of the Chartering Facilitator) must decide which of the following to do:

+
    +
  • +

    Complete charter refinement by initiating AC Review of the charter draft.

    +
  • +

    Abandon the proposal.

    +
  • +

    Extend the charter refinement period.

    +
+

The Team must announce its decision with the same visibility as the initial charter review notice, + and must include a rationale + if they are not initiating AC Review. + Reaching the end of the announced period (including any announced extension) + with no announced decision + is considered a de-facto Team decision to abandon the proposal. + The Team may revise such a decision + by announcing an alternative decision.

+

Formal Objections filed during the charter refinement phase + are specially handled:

+
    +
  • +

    Objections to decisions pertaining to the content of the charter, +as well as objections to initiating the AC Review, +are considered registered at the close of the Advisory Committee Review of the charter, +and are registered against that W3C Decision.

    +

    Note: This enables all Formal Objections on the same proposed charter to be handled together.

    +
  • +

    Objections to abandoning the proposal or to extending the refinement period can be appealed only if 5 or more Members, +through their Advisory Committee representative, +formally object to the decision within 8 weeks of the decision. +In this case, +the Team must do one of the following:

    +
      +
    • +

      Abide by the objectors' request, if they all agree on the +alternative course of action (e.g., to abandon, +extend, or complete charter refinement).

      +
    • +

      Initiate an AC Review to formally solicit the input of +the community and take a W3C Decision on the subsequent +course of action.

      +
    • +

      Convene a Council to decide the subsequent course of action.

      +
    +

    (No action is required to be taken when fewer than 5 members object.)

    +
  • +

    Any other objections are processed normally (See § 5.6 Addressing Formal Objections).

    +
+

4.3. Content of a Charter

+

A Working Group or Interest Group charter must include all of the following information.

+
    +
  • The group’s mission + (e.g., develop a technology or process, review the work of other groups). +
  • The scope of the group’s work and criteria for success. +
  • The duration of the proposed charter for the group. +
  • The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software). +
  • + Expected milestone dates where available. +

    Note: A charter does not need to include + schedules for review of other group’s deliverables.

    +
  • The process for the group to approve the release of deliverables + (including intermediate results). +
  • Any dependencies by groups within or outside of W3C on the deliverables of this group. + For any dependencies, the charter must specify + the mechanisms for communication about the deliverables. +
  • Any dependencies of this group on other groups within or outside of W3C. + Such dependencies include interactions with W3C Horizontal Groups [CHARTER]. +
  • The level of confidentiality of the group’s proceedings and deliverables. +
  • The name and affiliation of the Chair or co-Chairs. +
  • Meeting mechanisms and expected frequency. +
  • If known, + the date of the first face-to-face meeting. + The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal. +
  • Communication mechanisms to be employed within the group, + between the group and the rest of W3C, + and with the general public. +
  • Any voting procedures or requirements + other than those specified in § 5.2.3 Deciding by Vote. +
  • An estimate of the expected time commitment from participants. +
  • The expected time commitment and level of involvement by the Team + (e.g., to track developments, + write and edit technical reports, + develop code, + or organize pilot experiments). +
  • Intellectual property information. + What are the intellectual property (including patents and copyright) + considerations affecting the success of the Group? + In particular, is there any reason to believe + that it will be difficult to meet the Royalty-Free licensing goals + in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY]? +
+

See also the charter requirements in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

For every Recommendation Track deliverable + that continues work on a technical report published under any other Charter (including a predecessor group of the same name), + for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

+
    +
  • The title, + stable URL, + and publication date of the Working Draft or other Recommendation-track document + that will serve as the basis for work on the deliverable + (labeled “Adopted Draft”); +
  • The title, + stable URL, + and publication date of the document + that was used as the basis for its most recent Exclusion Opportunity + as per + the W3C Patent Policy [PATENT-POLICY]. + (labeled “Exclusion Draft”); and +
  • The stable URL of the Working Group charter + under which the Exclusion Draft was published + (labeled the “Exclusion Draft Charter”). +
+

All of the above data must be identified + in the adopting Working Group’s charter using the labels indicated.

+

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. + The proposed charter must state + the dates on which the Exclusion Opportunity + that arose on publishing the Exclusion Draft began and ended. + As per “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY], + this potentially means that exclusions can only be made immediately on joining a Working Group.

+

An Interest Group charter may include provisions regarding participation, + including specifying + that the only requirement for participation (by anyone) in + the Interest Group is subscription to the Interest Group mailing list. + This type of Interest Group may have public participants.

+

A charter may include + provisions other than those required by this document. + The charter should highlight + whether additional provisions impose constraints + beyond those of the W3C Process Document + (e.g., limits on the number of individuals in a Working Group + who represent the same Member organization or group of related Members).

+

4.4. Charter Review and Approval

+

4.4.1. New Charters and Major Changes

+

Any new charter (including re-chartering of existing chartered groups) + and any change that is not a minor change (per § 4.4.2 Minor Changes to Active Charters) to an already-approved charter of a Working Group or Interest Group must be approved by a W3C Decision following an AC Review of that charter. + Modifications to a charter should have the consensus of the group.

+

The review period must be at least 28 days. + Any Advisory Committee representative may request an extended review period + in response to the Call for Review; + upon receipt of any such request, + the Team must extend the review period + to at least 60 days.

+

The Call for Review of a modified charter must highlight important changes + (e.g., regarding changes in scope, deliverables, or resource allocation) + and must include rationale for those changes.

+

The Call for Review of a new or modified charter must include a disposition of comments received during the charter refinement process, + highlighting any issues that were closed despite sustained objections.

+

4.4.2. Minor Changes to Active Charters

+

Editorial changes or substantive changes to a charter (including extensions) + that do not affect the scope of the group’s work + or the way the group functions in any significant way + are deemed minor changes and may be approved by a Team Decision, + in which case they do not require charter refinement nor Advisory Committee Review. + Any change to the scope of the charter or addition of a new REC track deliverable + that does not fall within the scope of an existing deliverable + is a major, not minor, change. + The following are examples of minor changes: + the renaming or restructuring (e.g. splitting or combining) of existing in-scope deliverables, + the addition of new Note track deliverables that help explain the group’s work + a change of Staff Contact, + or a change of Chair. Minor changes, other than a change of Staff Contact, should have the consensus of the group.

+

The Team may nevertheless choose + to initiate charter refinement and/or Advisory Committee Review when it thinks the changes would benefit from more scrutiny or explicit buy-in.

+

Though Advisory Committee Review is not required, + such changes must still be announced + to the Advisory Committee, + and to participants in the Working or Interest Group, + and a rationale must be provided.

+

4.5. Call for Participation in a Chartered Group

+

Deciding whether to adopt a proposed Working Group or Interest Group charter is a W3C Decision. + Charters may be amended based on review comments + per § 5.7.2 Determining the W3C Decision before the Call for Participation.

+

If the decision is to charter the group, + the Team must issue a Call for Participation to the Advisory Committee. + For a new group, this announcement officially creates the group. + The announcement must include a reference to the charter, + the name(s) of the group’s Chair(s), + and the name(s) of the Staff Contact(s).

+

After a Call for Participation, + any Member representatives and Invited Experts must be designated (or re-designated). + When a group is re-chartered, + individuals participating in the Working Group or Interest Group before the new Call for Participation + may attend any meetings held within forty-five (45) days of the Call for Participation + even if they have not yet formally rejoined the group + (i.e., committed to the terms of the charter and patent policy).

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against the decision to create + or substantially modify + a Working Group or Interest Group charter.

+

4.6. Charter Extension

+

The Team may decide + to extend a Working Group or Interest Group charter + with no other substantive modifications. + The Team must announce + such extensions to the Advisory Committee. + The announcement must indicate the new duration. + The announcement must also include rationale for the extension, + a reference to the charter, + and the Group homepage + (which includes at least + the name(s) of the group’s Chair(s), + the name of the Staff Contact, + and instructions for joining the group).

+

After a charter extension, + Advisory Committee representatives + and the Chair are not required to re-designate Member representatives and Invited Experts.

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.

+

4.7. Chartered Group Closure

+

A Working Group or Interest Group charter specifies a duration for the group.

+

The Team, the TAG, or the AB may propose to close a group + prior to the date specified in the charter in any of the following circumstances:

+
    +
  • +

    There are insufficient member resources to produce chartered deliverables +or to maintain the group, +according to priorities established within W3C.

    +
  • +

    A Patent Advisory Group concluded that the work should be terminated.

    +
  • +

    The TAG or AB determined that continuing operation of the chartered group or its work +would be detrimental to W3C or its mission.

    +
  • +

    The group produced all chartered deliverables ahead of schedule.

    +
+

Such a proposal to close a group must be accompanied by rationale, + and the proposal must be confirmed by an AC Review as a W3C Decision.

+

Closing a Working Group has implications + with respect to the W3C Patent Policy [PATENT-POLICY].

+

5. Decisions

+

W3C attempts to resolve issues through dialog. + Individuals who disagree strongly with a decision should register with the Chair any Formal Objections.

+

5.1. Types of Decisions

+

The Chair of a Working Group or Interest Group has the prerogative + to make certain decisions based on their own judgment. + Such decisions are called chair decisions.

+

In contrast, + decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group + or following a vote (see § 5.2.3 Deciding by Vote) + are called group decisions (also known as group “resolutions”).

+

Decisions made by members of the Team in connection with this Process, + based on their own individual or collective judgement, + are called Team Decisions.

+

In contrast, + a W3C decision is + determined by the Team on behalf of the W3C community + by assessing the consensus of the W3C Community after an Advisory Committee review.

+

5.2. Consensus Building

+

5.2.1. Consensus

+

Consensus is a core value of W3C. + To promote consensus, + the W3C process requires Chairs to ensure + that groups consider all legitimate views and objections, + and endeavor to resolve them, + whether these views and objections are expressed by the active participants of the group + or by others + (e.g., another W3C group, + a group in another organization, + or the general public). + Decisions may be made during meetings + (face-to-face or distributed) + as well as through persistent text-based discussions.

+

The following terms are used in this document + to describe the level of support for a decision among a set of eligible individuals:

+
+
Consensus: +
A substantial number of individuals in the set + support the decision + and there is no sustained objection from anybody in the set. + Individuals in the set may abstain. + Abstention is either an explicit expression of no opinion + or silence by an individual in the set. +
Unanimity: +
The particular case of consensus where all individuals in the set support the decision + (i.e., no individual in the set abstains). +
Dissent: +
At least one individual in the set sustains an objection. +
+

Note: A Formal Objection always indicates a sustained objection, + but isn’t necessary to express it + (except in the context of formal AC Reviews). + Disagreement with a proposed decision, + however, does not always rise to the level of sustained objection, + as individuals could be willing to accept a decision + while expressing disagreement.

+

By default, the set of individuals eligible to participate in a decision is the set of group participants. + The Process Document does not require a quorum for decisions + (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). + A charter may include a quorum requirement for consensus decisions.

+

Where unanimity is not possible, + a group should strive to make consensus decisions + where there is significant support and few abstentions. + The Process Document does not require a particular percentage of eligible participants + to agree to a motion in order for a decision to be made. + To avoid decisions where there is widespread apathy, + (i.e., little support and many abstentions), + groups should set minimum thresholds of active support before a decision can be recorded. + The appropriate percentage may vary depending on the size of the group + and the nature of the decision. + A charter may include threshold requirements for consensus decisions. + For instance, a charter might require a supermajority of eligible participants + (i.e., some established percentage above 50%) + to support certain types of consensus decisions.

+
+ Note: Chairs have substantial flexibility + in how they obtain and assess consensus among their groups. + Unless otherwise constrained by charter, + they can use modes including but not limited to explicit calls for consensus, + polls of participants, + “lazy consensus” in which lack of objection after sufficient notice is taken as assent; + they can also delegate and empower a document editor + to assess consensus on their behalf, + whether in general + or for specific pre-determined circumstances + (e.g. in non-controversial situations, for specific types of issues, etc.). +

If questions or disagreements arise, + the final determination of consensus remains with the chair.

+
+

5.2.2. Managing Dissent

+

In some cases, even after careful consideration of all points of view, + a group might find itself unable to reach consensus. + The Chair may record a decision where there is dissent so that the group can make progress + (for example, to produce a deliverable in a timely manner). + Dissenters cannot stop a group’s work + simply by saying that they cannot live with a decision. + When the Chair believes that the Group has duly considered + the legitimate concerns of dissenters as far as is possible and reasonable, + the group should move on.

+

Groups should favor proposals that create the weakest objections. + This is preferred over proposals that are supported by a large majority + but that cause strong objections from a few people. + As part of making a decision where there is dissent, + the Chair is expected to be aware of which participants work for the same + (or related) + Member organizations and weigh their input accordingly.

+

Note: Dissenters can escalate their sustained objection to a decision by registering a Formal Objection.

+

5.2.3. Deciding by Vote

+

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, + and that a vote is necessary to break a deadlock. + In this case the Chair must record + (e.g., in the minutes of the meeting or in an archived email message):

+
    +
  • an explanation of the issue being voted on; +
  • the decision to conduct a vote + (e.g., a simple majority vote) to resolve the issue; +
  • the outcome of the vote; +
  • any Formal Objections. +
+

In order to vote to resolve a substantive issue, + an individual must be a group participant. + Each organization represented in the group must have at most one vote, + even when the organization is represented by several participants in the group + (including Invited Experts). + For the purposes of voting:

+
    +
  • A Member or group of related Members is considered a single organization. +
  • The Team is considered an organization. +
+

Unless the charter states otherwise, Invited Experts may vote.

+

If a participant is unable to attend a vote, + that individual may authorize anyone at the meeting + to act as a proxy. + The absent participant must inform the Chair in writing + who is acting as proxy, with written instructions on the use of the proxy. + For a Working Group or Interest Group, + see the related requirements regarding an individual + who attends a meeting as a substitute for a participant.

+

A group may vote for other purposes than to resolve a substantive issue. + For instance, the Chair often conducts a “straw poll” vote + as a means of determining whether there is consensus about a potential decision.

+

A group may also vote to make a process decision. + For example, + it is appropriate to decide by simple majority + whether to hold a meeting in San Francisco or San Jose + (there’s not much difference geographically). + When simple majority votes are used to decide minor issues, + voters are not required to state the reasons for votes, + and the group is not required to record individual votes.

+

A group charter may include formal voting procedures + (e.g., quorum or threshold requirements) + for making decisions about substantive issues.

+

5.3. Formally Addressing an Issue

+

In the context of this document, + a group has formally addressed an issue when it has sent a public, substantive response + to the reviewer who raised the issue. + A substantive response is expected to include rationale for decisions + (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). + The adequacy of a response is measured + against what a W3C reviewer would generally consider to be technically sound. + If a group believes that a reviewer’s comments result from a misunderstanding, + the group should seek clarification before reaching a decision.

+

As a courtesy, + both Chairs and reviewers should set expectations + for the schedule of responses and acknowledgments. + The group should reply to a reviewer’s initial comments + in a timely manner. + The group should set a time limit + for acknowledgment by a reviewer of the group’s substantive response; + a reviewer cannot block a group’s progress. + It is common for a reviewer to require a week or more + to acknowledge and comment on a substantive response. + The group’s responsibility to respond to reviewers + does not end once a reasonable amount of time has elapsed. + However, reviewers should realize + that their comments will carry less weight + if not sent to the group in a timely manner.

+

Substantive responses should be recorded. + The group should maintain an accurate summary + of all substantive issues and responses to them + (e.g., in the form of an issues list with links to mailing list archives).

+

5.4. Reopening a Decision When Presented With New Information

+

The Chair may reopen a decision + when presented with new information, including:

+
    +
  • additional technical information, +
  • comments by email from participants who were unable to attend a scheduled meeting, +
  • comments by email from meeting attendees + who chose not to speak out during a meeting + (e.g., so they could confer later with colleagues or for cultural reasons). +
+

The Chair should record + that a decision has been reopened, + and must do so upon request from a group participant.

+

5.5. Registering Formal Objections

+

Any individual + (regardless of whether they are associated with a Member) may appeal any decision made in connection with this Process + (except those having a different appeal process) + by registering a Formal Objection with the Team. + Group participants should inform + their Staff Contact as well as the group’s Chair(s). + The Staff Contact must inform the CEO when a group participant has also raised concerns about due process.

+

Note: In this document, the term Formal Objection is used to emphasize this process implication: + Formal Objections receive formal consideration and a formal response. + The word “objection” used alone has its ordinary English connotations. + See § 5.2 Consensus Building.

+

A Formal Objection must include a summary of + the issue (whether technical or procedural), + the decision being appealed, + and the rationale for the objection. + It should cite technical arguments + and propose changes that would remove the Formal Objection; + these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments + or rationale are unlikely to receive serious consideration. + Counter-arguments, + rationales, + and decisions should also be recorded.

+

No later than when the relevant Council is initiated, + a record of each Formal Objection against a decision regarding a publicly-available document must be made publicly available; + likewise, a record of each Formal Objection against a Member-visible decision must be made available to Members. + A Call for Review to the Advisory Committee must identify any Formal Objections related to that review. + This requirement is waived + if the Formal Objection is resolved to the satisfaction of the objector + before its confidentiality is changed.

+

Note: Formal Objections against matter in a technical report are expected to be fully addressed before requesting advancement of the technical report.

+

A Formal Objection filed during an Advisory Committee Review is considered registered at the close of the review period.

+

Registering a Formal Objection initiates the process of addressing the Formal Objection. + The resolution of a recorded Formal Objection—​whether by a Council decision, adoption of a consensus proposal, retraction of the Formal Objection, etc.—​must be recorded and made available at the same level of visibility as the record of the Formal Objection itself.

+

5.6. Addressing Formal Objections

+

5.6.1. Investigation and Mediation by the Team

+

The Team considers the Formal objection, + researches the question, + interviews parties, + and so on, + to make sure the problem and the various viewpoints are well understood, + and to the extent possible, + to arrive at a recommended disposition.

+

In parallel, the Team should start the steps necessary + to convene a Council.

+

If the Team can resolve the issue + to the satisfaction of the individual that filed the Formal Objection, + the individual withdraws the objection and the disposition process terminates.

+

Otherwise, + upon concluding that consensus cannot be found, + and no later than 90 days after the Formal Objection being registered, + the Team must deliver to the Council a report + documenting its findings and attempts to find consensus, + and hand over the matter to the W3C Council.

+

5.6.2. W3C Council

+

A W3C Council is the body convened to resolve Formal Objections by combining the capabilities and perspectives of the AB, the TAG, and the Team, + and is tasked with doing so in the best interests of the Web and W3C.

+
5.6.2.1. Council Composition
+

Each W3C Council is composed of the following members (excepting any renounced or dismissed):

+ +

Participation in a W3C Council must not require attendance of face-to-face meetings.

+

A distinct instance of the W3C Council is convened for each decision being appealed or objected to. + The list of potential Council members evolves + as AB and TAG terms start and end + until dismissal and renunciation are concluded, + at which point the membership of the Council is fixed. + However, if the number of active members in a Council falls so low as to hinder effective and balanced deliberations, + the Council Chair should dissolve the Council and call for a new one to be convened.

+

Note: TAG and AB elections have no effect on the Council’s membership + once it is fixed.

+

A Team member is assigned + to act as the Council Staff Contact, + to support this Council + and to facilitate adherence to this Process.

+
5.6.2.2. Extraordinary Delegation
+

In extraordinary cases, + if they feel a Council would not be the appropriate deciding body, + a member of the Team (particularly the Legal Counsel) or + any potential Council member + may suggest that the decision for that specific Formal Objection be delegated + to the W3C Board of Directors, + to an officer of its corporation (such as the Legal Counsel), + or to one or more specific individuals from the Team. + The potential Council members then may confidentially discuss + and must vote + whether to delegate the decision for that specific Formal Objection. + A decision to delegate must be supported by a two-thirds supermajority vote + (i.e., at least twice as many votes in favor as against). + Delegation in such cases cannot be later revoked.

+

The Team must inform the Advisory Committee when a Formal Objection has been delegated, + and to whom it has been delegated.

+
5.6.2.3. Council Participation, Dismissal, and Renunciation
+

A potential Council member may be dismissed from the Council. + In order to apply consistent criteria, + the potential Council members decide collectively + which reasons against service + rise to a sufficient level for a potential member to be dismissed. + No-one is automatically dismissed, + and individual recusal is not used in the Council. Dismissal applies to an individual person in the context of a specific Council, + and should be used rarely in order to preserve the greatest diversity on the Council.

+

Note: A W3C Council is a deliberative body whose purpose is + to find the best way forward for the Web and for W3C. + It is not a judicial body tasked with determining right or wrong.

+

The Team must draft a list of potential Council members, + with annotations of possible reasons for dismissal against each one. + The W3C community, + including members and team, and potential council members, must be given an opportunity to contribute possible reasons to this list. + Affected members must be given + an opportunity to respond to such comments about themselves. + The Team may report comments verbatim + or may paraphrase them while preserving their intent; + they may also elide inappropriate comments, + such as any that violate applicable laws or the [COC].

+

Before a Council forms, + the Team presents the entire list of potential members + and collected reasons and responses + to the potential Council members, + who then consider for each potential member + whether that individual’s participation + would compromise the integrity of the Council decision, + and vote whether to dismiss that potential member. + No one is allowed to vote on their own dismissal; + each dismissal is enacted if there are at least as many ballots for as against.

+

Note: Since dismissal is individual, + when the decision being objected to was made by the TAG or AB acting as a body, + the entire TAG or AB is not expected to be dismissed.

+

An individual may also renounce their seat on a Council, for strong reason, + such as being forbidden by their employer to serve. The individual chooses the extent to which they explain + their renunciation. + Renunciation is disqualification from participation, + not abstention, + and should not be used + to excuse an absence of participation.

+

Any person who has been dismissed or who renounces their seat + does not receive Council materials, + take part in its deliberations, + help in the determination of consensus, + or vote. + The W3C Council may still solicit and hear their testimony, + as they can of anyone else in the W3C community.

+
5.6.2.4. Short Circuit
+

The full Council process may be short-circuited if + the Team recommends a resolution + and potential members of a Council who are not renouncing their seat + confirm it by a vote which results in both of the following:

+
    +
  • +

    at least 80% of them vote affirmatively to adopt this resolution

    +
  • +

    none of them vote against adopting the resolution

    +
+

The request for confirmation must be open for a period of at least two weeks, + or until every potential member of the Council not renouncing their seat + has voted, + whichever is shortest.

+

This step may be run concurrently with § 5.6.2.3 Council Participation, Dismissal, and Renunciation and prior to choosing a Chair.

+

Note: This is intended for exceptional cases + that don’t seem to warrant a full Council response + because they are, for instance, too trivial, duplicative, etc.

+
5.6.2.5. Council Chairing
+

The Chair of each W3C Council is chosen by its members, + by consensus if possible, + falling back to a vote if that fails. + The chair must be a member of that W3C Council. + Chair selection happens during formation of each Council, + and must be re-run + if requested by the Council Staff Contact or by the Chair during the Council’s operation.

+
5.6.2.6. Convening the Council
+

When dismissal, renunciation, and + appointment of the W3C Council Chair have concluded, + and the Team’s report has been delivered, + the W3C Council is considered to be convened and can start deliberations.

+

If a W3C Council has not yet been convened within 90 days of a Formal Objection + being registered, + the Chairs of the TAG and AB may take independent action to ensure + that the dismissal, renunciation, + and chair selection processes have been run. + If a report from the Team is not delivered within those 90 days, + the Council is considered convened upon selection of the Council Chair.

+
5.6.2.7. Council Deliberations
+

Once convened, + the Council may conduct additional research or analysis, + or request additional information or interviews from anyone, + including the Team.

+

The Council may further attempt to broker consensus on one or more of the formal objections, + which, if successful, would allow them to be resolved.

+

Otherwise, + after sufficient deliberation, + and with due consideration of each argument in the applicable Formal Objections, + the W3C Council decides whether to affirm or overturn the decision being objected to. + The W3C Council may affirm the decision + even if it agrees with some of the arguments made as part of a Formal Objection. + When a decision is affirmed, + all Formal Objections against it are said to be overruled. + Conversely, + aspects of Formal Objections that are found by the Council + to justify overturning a decision + are said to be upheld.

+

When overturning a decision, + it should recommend a way forward. + If the overturned decision has already had consequences + pertaining to upheld aspects of the Formal Objection(s) + (e.g., if the objection concerns material already in a published document) + the Council should suggest how these consequences might be mitigated. + The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion; + and the upheld aspects of the Formal Objection(s) (as identified in the Council Report) are not considered fully addressed until then.

+

Note: This does not create new powers for the Team, + such as the ability to “unpublish” documents. + The Team’s role is to ensure the responsible parties enact adequate mitigations, + by whatever means they already have at their disposal.

+

A Council may form sub-groups for deliberation, + who may return with a recommendation, + but the full Council issues the final decision. + The decision of the W3C Council should be unanimous, + and may be issued under consensus. + However, if despite careful deliberation + a W3C Council is unable to reach consensus, + the W3C Council Chair may instead resort to voting. + In that case, + the decision is adopted if there are more ballots for than against; + in case of a tie, + the W3C Council Chair determines the outcome. + However, + if the decision or proposal being objected to + originated with the TAG or AB, + then members of that group at the time the decision or proposal was made + must abstain in such a vote. + In case of a vote, + if two members of a Council who share the same affiliation cast an identical ballot, + then their ballots count as a one vote, + not two.

+

In the case of non-unanimous decisions, + members of a W3C Council who disagree with the Council’s decision may write a Minority Opinion explaining the reason for their disagreement.

+

The deliberations of a W3C Council are confidential to that W3C Council and its Council Staff Contact.

+

Note: This confidentiality requirement is put in place so that + the Council can receive sensitive information in confidence + and to enable Council members to speak freely in their individual expert capacity + without pressure or fear of retaliation + by those involved in the dispute, business relations, their employer, etc.

+

If a W3C Council is unable to come to a conclusion within 45 days of being convened, + the W3C Council Chair must inform the AC of this delay + and of the status of the discussions. + The W3C Council Chair may additionally make this report public.

+
5.6.2.8. Council Decision Report
+

A Council terminates by issuing a Council Report, + which:

+
    +
  • +

    must state whether the Council affirms or overturns the decision being objected to.

    +
  • +

    must provide a rationale supporting its conclusion, +which should address each argument raised in the Formal Objection(s).

    +
  • +

    must include any recommendation decided by the Council.

    +
  • +

    if the decision has been overturned, must identify which aspects of the Formal Objection(s) are being upheld, and should include any suggested mitigations.

    +
  • +

    must include the Minority Opinion(s), if any.

    +
  • +

    must report the names of those who were dismissed or renounced their seat as well as those who were qualified to serve.

    +
  • +

    must report the names of the individuals who participated in the final Council decision.

    +
  • +

    must report the number of votes for/against dismissing each participant.

    +
  • +

    may report vote totals for the Council’s decision, if a formal vote was held.

    +
  • +

    must not attribute any position to any individual on the Council.

    +
+

The Team must maintain a public page on the W3C website indexing all completed Council Reports. + If a Council decision is later overturned by an AC Appeal, + this must also be mentioned. Council Reports must be no more confidential + than the decision or document being objected to.

+

The Council may also issue a Supplemental Confidential Council Report with a more restricted level of confidentiality than its main report + when it believes that additional commentary on confidential aspects of the case + would be informative. + However, the main Council Report should be self-sufficient + and understandable without reference to Supplemental Confidential Council Reports.

+
5.6.2.9. Appealing Council Decisions
+

Advisory Committee representatives may initiate an Advisory Committee Appeal of a Council decision issued in a Council Report.

+

5.7. Advisory Committee Reviews and W3C Decisions

+

The Advisory Committee formally confers its approval + on charters, technical reports, + and other matters + through an Advisory Committee review and its resulting W3C Decision.

+

5.7.1. Initiating an Advisory Committee Review

+

Each Advisory Committee review period + begins with a Call for Review from the Team to the Advisory Committee. + The Call for Review describes the proposal, + raises attention to deadlines, + estimates when the decision will be available, + and includes other practical information. + The Team may share its perspective on the proposal + in the Call for Review. + Each Member organization may send one review, + which must be returned by its Advisory Committee representative.

+

For clarity, + in the context of an AC Review, dissent must be expressed as a Formal Objection.

+

The Team must provide two channels for Advisory Committee review comments:

+
    +
  1. an archived Team-only channel; +
  2. an archived Member-only channel. +
+

The Call for Review must specify + which channel is the default for review comments on that Call.

+

Reviewers may send information + to either or both channels. + A reviewer may also share their own reviews + with other Members on the Advisory Committee discussion list, + and may also make it available to the public.

+

A Member organization may modify its review + during a review period + (e.g., in light of comments from other Members).

+

5.7.2. Determining the W3C Decision

+

After the review period, + the Team determines the appropriate W3C Decision, + which they must announce to the Advisory Committee. + The announcement must indicate + the level of support for the proposal + (consensus or dissent), + and specifically + whether there were any Formal Objections, + with attention to changing the confidentiality level of the Formal Objections.

+

If there were Formal Objections, at least some of which were upheld, + or if there is not consensus because of insufficient support, W3C Decision must be one of:

+
    +
  • The proposal is returned for additional work, + with a request to the initiator to improve the proposal. +
  • The proposal is rejected. +
+

If the proposal has consensus, + or if all Formal Objections are retracted or overruled and the proposal otherwise has sufficient support to achieve consensus, + this W3C Decision must be one of:

+
    +
  • The proposal is adopted, + possibly with additional changes integrated + in order to address the comments of the AC (see below). +
  • The proposal is returned for additional work, + with a request to the initiator to make desirable changes identified during the review + and to resubmit. +
+

If the proposal is adopted with changes other than class 1 (markup) changes, + then those changes must be announced to the AC and to the Group that owns the document (if any). + Additionally, when adopting a proposal with substantive changes integrated, + the announcement must include rationale + for the substantive changes.

+

Substantive changes to the proposal may be adopted + only if the revised proposal has consensus of the subset of the AC that voted on the initial proposal + (including anyone who explicitly abstained), + or if all Formal Objections against the revised proposal are retracted or overruled and the revised proposal otherwise has sufficient support to achieve consensus. + For clarity, + the Team should seek a response from this subset of the AC using the same tooling and degree of formality as it did for the AC Review; + and as is the case during AC Reviews, dissent in this context must be expressed as a Formal Objection.

+

Any Formal Objection raised at this stage against the revised proposal + is handled by the same Council responsible for Formal Objections raised against the initial proposal, + if any.

+

Such a Council has the ability to affirm either the original or the revised proposal for advancement, + thereby overruling all Formal Objections against the original or revised proposal, + respectively.

+

For publications which have conditions in addition to AC approval + for introducing substantive changes (such as Group consensus or implementation experience + or going through a patent Exclusion Opportunity), + those other conditions must also be re-fulfilled.

+
For example, if substantive changes to a technical report are requested when assessing the transition from Candidate Recommendation to Recommendation, + the technical report would need to go through a new Update Request and be republished as a new Candidate Recommendation; + that new version would then need to satisfy the criteria for advancement. + Alternatively, the desired changes can be introduced as non-substantive amendments + using the process for revising a Recommendation. + However, with the exception of the removal of at-risk features, + they cannot be directly integrated between CRS and REC, + because that would fail to trigger a patent exclusion opportunity.
+

For charters, + substantive changes from the initial proposal that underwent AC Review must not include any increase to the scope. + If any such change is desired, + it must be returned for additional work + and go through a complete new AC Review.

+

This document does not specify + time intervals between the end of an Advisory Committee review period + and the W3C decision. + This is to ensure that the Members and Team have sufficient time to consider comments + gathered during the review. + The Advisory Committee should not expect an announcement + sooner than two weeks after the end of a review period. + If, after three weeks, the outcome has not been announced, + the Team should provide the Advisory Committee with an update.

+

5.8. Advisory Committee Votes

+

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, + and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. + Whenever the Advisory Committee votes, + each Member or group of related Members has one vote.

+

5.9. Appeal by Advisory Committee Representatives

+

Advisory Committee representatives may appeal certain decisions, + though appeals are only expected to occur in extraordinary circumstances. + For the purpose of this section, only Advisory Committee representatives of Members in Good Standing are counted.

+

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate + an Advisory Committee Appeal. + These W3C decisions include those related to group creation and modification, + and transitions to new maturity stages for Recommendation Track documents + and the Process document.

+

Advisory Committee representatives may also initiate an appeal + for decisions of a W3C Council, and + for certain decisions that do not involve an Advisory Committee review. + These cases are identified in the sections + which describe the requirements for the decision + and include + additional (non-reviewed) maturity stages of Recommendation Track documents, + group charter extensions and closures, + and technical agreements.

+

In all cases, + an appeal must be initiated within three weeks of the decision.

+

An Advisory Committee representative initiates an appeal by sending a request to the Team, + and should also share this request with the Advisory Committee. + The request should say “I appeal this Decision” + and identify the decision, + and may also include their rationale for appealing the decision.

+

Note: See Appealing a W3C Decision for a recommendation + on how to communicate an appeal request to the Team and the AC.

+

Within one week the Team must announce the appeal process + to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. + The archive of these statements must be member-only. + If, within one week of the Team’s announcement, + 5% or more of the Advisory Committee support the appeal request, + the Team must organize an appeal vote asking the Advisory Committee “Do you approve of the Decision?” + together with links to the decision and the appeal support.

+

The ballot must allow for three possible responses: + “Approve”, + “Reject”, + and “Abstain”, + together with Comments.

+

The level of support needed for an Advisory Committee Appeal to pass + depends on the level of ballot participation + (including explicit “abstain” ballots) + by Advisory Committee Representatives:

+
    +
  • +

    if fewer than 5% participate, +the vote fails.

    +
  • +

    if at least 5% but no more than 15% participate, +and the number of “Approve” ballots exceeds three times (3x) the number of “Reject” ballots, +the vote passes.

    +
  • +

    if more than 15% but fewer than 20% participate, +and the number of “Approve” ballots exceeds twice (2x) the number of “Reject” ballots, +the vote passes.

    +
  • +

    if 20% or more participate, +and the number of “Approve” ballots exceeds the number of “Reject” ballots, +the vote passes.

    +
+

If the vote passes, + the decision is overturned. + Following such rejection, + those who had initiated the proposal may revise it + to address the causes of rejection + and follow the ordinary applicable process + to submit the revised proposal.

+

6. W3C Technical Reports

+

The W3C technical report development process is the set of steps and requirements + followed by W3C Working Groups to standardize Web technology. + The W3C technical report development process is designed to:

+
    +
  • support multiple specification development methodologies +
  • maximize consensus about the content of stable technical reports +
  • ensure high technical and editorial quality +
  • promote consistency among specifications +
  • facilitate royalty-free, interoperable implementations of Web Standards, and +
  • earn endorsement by W3C and the broader community. +
+

See also “licensing goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

6.1. Types of Technical Reports

+

This chapter describes the formal requirements + for publishing and maintaining a W3C Recommendation, Note, + or Registry.

+
+
Recommendations +
Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines + as standards for the Web. + The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, + and consensus-building, + and is subject to the W3C Patent Policy [PATENT-POLICY], + under which participants commit to Royalty-Free IPR licenses for implementations. + See § 6.3 The W3C Recommendation Track for details. +
Notes +
Groups can also publish documents as Group Notes and W3C Statements, + typically either to document information + other than technical specifications, + such as use cases motivating a specification + and best practices for its use. + See § 6.4 The Note Track (Notes and Statements) for details. +
Registries +
Chartered and elected groups can also publish registries in order to document collections of values or other data. + A registry can be published either as a distinct registry report, + or directly within a Recommendation Track document + as an embedded registry. Defining a registry requires wide review and consensus, + but once set up, changes to registry entries are lightweight + and can even be done without the initiating group’s involvement. + See § 6.5 The Registry Track for details. +
+

Individual Working Groups and Interest Groups should adopt additional processes + for developing publications, + so long as they do not conflict with the requirements in this chapter.

+

6.2. General Requirements for Technical Reports

+

6.2.1. Publication of Technical Reports

+

Publishing as used in this document + refers to producing a version which is listed as a W3C Technical Report on its Technical Reports index at https://www.w3.org/TR [TR]. + Every document published as part of the technical report development process must be a public document. + W3C strives to make archival documents indefinitely available + at their original address in their original form.

+

Every document published as part of the technical report development process must clearly indicate its maturity stage, + and must include information about the status of the document. + This status information:

+
    +
  • must be unique each time a specification is published, +
  • must state which Working Group developed the specification, +
  • must state how to send comments or file bugs, + and where these are recorded, +
  • must include expectations about next steps, +
  • should explain how the technology relates to existing international standards + and related work inside or outside W3C, + and +
  • should explain + or link to + an explanation of significant changes from the previous version. +
+

Every Technical Report published + as part of the Technical Report development process + is edited by one or more editors + appointed by a Group Chair. + It is the responsibility of these editors to ensure that the decisions of the Group are + correctly reflected in subsequent drafts of the technical report. + An editor must be a participant, + per § 3.4.2 Participation in Chartered Groups in the Group responsible for the document(s) they are editing.

+

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, + status information, + style, + and copyright requirements). + These rules are subject to change by the Team from time to time. + The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

+

The primary language for W3C Technical Reports is English. + W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C website.

+

6.2.2. Reviews and Review Responsibilities

+

A document is available for review + from the moment it is first published. + Working Groups should formally address any substantive review comment + about a technical report in a timely manner.

+

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, + particularly if this would cause significant compatibility problems + due to existing implementation. Working Groups should record substantive + or interesting proposals raised by reviews + but not incorporated into a current specification.

+
6.2.2.1. Wide Review
+

The requirements for wide review are not precisely defined by the W3C Process. + The objective is to ensure that the entire set of stakeholders of the Web community, + including the general public, + have had adequate notice of the progress of the Working Group and were able to actually perform reviews of and provide comments on the specification. + A second objective is to encourage groups to request reviews + early enough that comments and suggested changes + can still be reasonably incorporated in response to the review. + Before approving transitions, + the Team will consider who has been explicitly offered + a reasonable opportunity to review the document, + who has provided comments, + the record of requests to and responses from reviewers, + especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter + or identified as liaisons [LIAISON], + and seek evidence of clear communication to the general public + about appropriate times and which content to review + and whether such reviews actually occurred.

+

Note: The Team documents best practices for wide review in the Guidebook. [GUIDE]

+

For example, + inviting review of new or significantly revised sections published in Working Drafts, + and tracking those comments + and the Working Group’s responses, + is generally a good practice which would often be considered positive evidence of wide review. Working Groups should follow the W3C Horizontal Groups’ review processes, + and should announce to other W3C Working Groups + as well as the general public, + especially those affected by this specification, + a proposal to enter Candidate Recommendation (for example in approximately 28 days). + By contrast a generic statement in a document + requesting review at any time + is likely not to be considered as sufficient evidence + that the group has solicited wide review.

+

A Working Group could present evidence that wide review has been received, + irrespective of solicitation. + But it is important to note that receiving many detailed reviews + is not necessarily the same as wide review, + since they might only represent comment + from a small segment of the relevant stakeholder community.

+

6.2.3. Classes of Changes

+

This document distinguishes the following 5 classes of changes to a document. + The first two classes of change are considered editorial changes, + the next two substantive changes, + and the last one registry changes.

+
+
+ +
    +
  1. +

    No changes to text content

    +
+
These changes include fixing broken links, style sheets, or invalid markup. +
+ +
    +
  1. +

    Changes that do not functionally affect interpretation of the document

    +
+
For Recommendation-track technical reports specifically, + this constitutes changes that do not affect conformance, + i.e. changes that reasonable implementers + would not interpret as changing architectural + or interoperability requirements + or their implementation. + Changes which resolve ambiguities in the specification + are considered to change (by clarification) the implementation requirements + and do not fall into this class. +
Examples of changes in this class include + correcting non-normative examples + which clearly conflict with normative requirements, + clarifying various other non-normative text, + fixing typos or grammatical errors + where the change does not change requirements. +
If there is any doubt or disagreement + as to whether a change functionally affects interpretation, + that change does not fall into this class. +
+ +
    +
  1. +

    Other changes that do not add new features

    +
+
+ For Recommendation-track documents, + these changes may affect conformance to the specification. + A change that affects conformance is one that: +
    +
  • makes conforming data, processors, or other conforming agents become non-conforming according to the new version, + or +
  • makes non-conforming data, processors, or other agents become conforming, + or +
  • clears up an ambiguity or under-specified part of the specification + in such a way that data, + a processor, + or an agent + whose conformance was once unclear + becomes clearly either conforming or non-conforming. +
+
+ +
    +
  1. +

    New features

    +
+
Changes that add new functionality, + such as new elements, new APIs, new rules, etc. +
+ +
    +
  1. +

    Changes to the contents of a registry table

    +
+
Changes that add, remove, or alter registry entries in a registry table. +
+

6.2.4. Errata Management

+

Tracking errors is an important part of a Working Group’s ongoing care of a technical report; + for this reason, + the scope of a Working Group charter generally allows time + for work after publication of a Recommendation. + In this Process Document, + the term “erratum” + (plural “errata”) refers to any error + that can be resolved by one or more changes in classes 1-3 + of section § 6.2.3 Classes of Changes.

+

Working Groups must keep + a public record of errors + that are reported by readers and implementers + for Recommendations. + Such error reports should be compiled + no less frequently than quarterly.

+

Working Groups decide how to document errata. + Such documentation must identify + the affected technical report text + and describe the error; + it may also describe some possible solution(s). + Readers of the technical report should be able easily + to find and see the errata + that apply to that specific technical report with their associated tests. + Errata may be documented + in a separate errata page or tracking system. + They may, + in addition or alternatively, + be annotated inline + alongside the affected technical report text + or at the start or end of the most relevant section(s).

+

6.2.5. Candidate Amendments

+

An erratum may be accompanied by a non-normative, candidate correction approved by group decision. + When annotated inline, + errata—​including their candidate corrections—​must be marked as such, + are treated as class 2 changes, + and are published accordingly.

+

Note: Annotating changes in this way allows more mature documents + such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, + even when the candidate amendments have not yet received + sufficient review or implementation experience + to be normatively incorporated into the specification proper.

+

A candidate addition is similar to a candidate correction, + except that it proposes a new feature + rather than an error correction.

+

Candidate corrections and candidate additions are collectively known as candidate amendments.

+

In addition to their actual maturity stage, published REC Track documents with candidate amendments are also considered, + for the purpose of the W3C Patent Policy [PATENT-POLICY], + to be Working Drafts with those candidate amendments treated as normative.

+

6.2.6. Maintenance Without a Group

+

For all types of technical reports and all maturity stages, + if there is no group chartered to maintain a technical report, + the Team may republish it + at the same maturity stage, + integrating as needed:

+
    +
  1. class 1 changes; +
  2. inline errata; +
  3. candidate corrections, + which must be marked as Team correction; +
  4. class 2 changes other than inline errata and Team corrections. +
+

To avoid any potential doubt or disagreement + about whether changes really do fall into class 2, + the Team should be conservative, + limiting itself to obvious and limited fixes, + and must avoid substantial rephrasing, + even of non-normative examples and notes. + If any such change is desired, + the Team must mark it as a Team correction.

+

Team corrections do not constitute + a normative portion of the Recommendation, + as defined in the Patent Policy [PATENT-POLICY] (i.e., they are not covered by the Patent Policy). + For Candidate Recommendations, W3C Recommendations, Candidate Registries, W3C Registries, + as well as W3C Statements, + the Team must solicit wide review on Team corrections that it produces.

+

6.2.7. License Grants from Non-Participants

+

When a party who is not already obligated under the Patent Policy + offers a change in class 3 or 4 + (as described in § 6.2.3 Classes of Changes) to a technical report under this process + the Team must request + a recorded royalty-free patent commitment; + for a change in class 4, the Team must secure such commitment. + Such commitment should cover, + at a minimum, + all the party’s Essential Claims both in the contribution, + and that become Essential Claims as a result of incorporating the contribution into the draft + that existed at the time of the contribution, + on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

+

6.3. The W3C Recommendation Track

+

Working Groups create specifications and guidelines + to complete the scope of work envisioned by a Working Group’s charter. + These technical reports undergo cycles of revision and review + as they advance towards W3C Recommendation status. + Once review suggests the Working Group has met their requirements for a new standard, + including wide review, + a Candidate Recommendation phase + allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. + At the end of the process, + the Advisory Committee reviews the mature technical report, + and if there is support from its Membership, + W3C publishes it as a Recommendation.

+

In summary, the W3C Recommendation Track consists of:

+
    +
  1. Publication of the First Public Working Draft. +
  2. Publication of zero or more revised Working Drafts. +
  3. Publication of one or more Candidate Recommendations. +
  4. Publication as a W3C Recommendation. +
+

A W3C Recommendation Track document is any document whose current status is one of the four in the numbered list above.

+
+ + Basic W3C Recommendation Track + + + + + First Public Working Draft (FPWD) - Exclusion opportunity + + + + WG Decision + + Team Approval + + + + + + + + + Working Draft (WD) + + + + + + + + Publish a new Working Draft + + + WG Decision + + + + + + + + + Advance to Candidate Recommendation + + WG Decision + + Team Approval + + + + + + + + + + Candidate Recommendation Snapshot (CRS) - Patent Policy exclusion opportunity + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG + Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + Team Approval + + + + + + + + Advance to Recommendation + + WG Decision + + Team Approval + + AC Review + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision with AB+TAG Approval) + + + + + + + + + + + Candidate Recommendation Draft (CRD) + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + + Team Approval + + + + + + + + + + + Recommendation + + + + + + + + Return to Candidate Recommendation Snapshot + + + WG Decision + (or Team Decision + with AB+TAG + Approval) + + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision + with AB+TAG + Approval) + + + + + + + + + Publish revised Recommendation with editorial changes + + + WG Decision + (editorial) + + + + + + + + + Publish revised Recommendation with substantive changes + + + WG Decision + + Team Approval + + AC Review + (substantive) + + + + + + + + + +
Non-Normative Summary of the Recommendation Track
+
+

This Process defines certain Recommendation Track publications as Patent Review Drafts. + Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004], + these correspond to “Last Call Working Draft” in the Patent Policy; + Starting from the 2020 Patent Policy [PATENT-POLICY-2020], + these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

+

W3C may end work on a technical report at any time.

+

As described in § 6.3.3 Advancement on the Recommendation Track, + the Team will decline a request to advance in maturity stage + and return the specification to a Working Group for further work + if it determines that the requirements for advancement + have not been met.

+

6.3.1. Maturity Stages on the Recommendation Track

+
+
Working Draft (WD) +
+ A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, + and other technical organizations, + and for simple historical reference. + Some, but not all, Working Drafts are meant to advance to Recommendation; + see the document status section of a Working Draft + for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, + and do not imply any endorsement by W3C + or its members beyond agreement to work on a general area of technology. + Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. + A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity. +

For all Working Drafts a Working Group:

+
    +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, + and +
  • may request publication of a Working Draft + even if its content is considered unstable + and does not meet all Working Group requirements. +
+

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), + and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

+
Candidate Recommendation (CR) +
+ A Candidate Recommendation is a document that satisfies the technical + requirements of the Working Group that produced it and their dependencies, + and has already received wide review. + W3C publishes a Candidate Recommendation to + +

Note: Advancing to Candidate Recommendation indicates + that the document is considered complete and fit for purpose, + and that no further refinement to the text is expected + without additional implementation experience and testing; + however, additional features might be expected in a later revision. + A Candidate Recommendation is expected to be as well-written, + detailed, + self-consistent, + and technically complete + as a Recommendation, + and acceptable as such + if and when the requirements for further advancement are met.

+

Candidate Recommendation publications take one of two forms:

+
+
Candidate Recommendation Snapshot (CRS) +
+ A Candidate Recommendation Snapshot + corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. + Publishing a Patent Review Draft triggers a Call for Exclusions, + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy. +

Publication as a Candidate Recommendation Snapshot requires verification of either a Transition Request (for the first Candidate Recommendation publication from another maturity stage) + or an Update Request (for subsequent Candidate Recommendation Snapshots).

+
Candidate Recommendation Draft (CRD) +
+ A Candidate Recommendation Draft + is published + to solicit review of intended changes from the previous Candidate Recommendation Snapshot. + This allows for wider review of the changes + and for ease of reference to the integrated specification. +

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot. + However, the process requirements are minimized + so that the Working Group can easily keep the specification up to date.

+

A Candidate Recommendation Draft does not provide an exclusion opportunity; + instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

+
+

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered + such that W3C cannot endorse it or continue work on it, + for example due to burdensome patent claims that affect implementers and cannot be resolved + (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). + There is no path to restoration for a Rescinded Candidate Recommendation. + See “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

+
W3C Recommendation (REC) +
+ A W3C Recommendation is a specification + or set of guidelines + or requirements that, + after extensive consensus-building, + has received the endorsement of W3C and its Members. + W3C recommends the wide deployment + of its Recommendations as standards for the Web. + The W3C Royalty-Free IPR licenses + granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. +

After its initial publication, + a W3C Recommendation may be revised + (in accordance with § 6.3.10 Revising a W3C Recommendation) + to address editorial or substantive issues + that are discovered later. + However, new features can only be added + if the document already identifies itself + as intending to allow new features. + Adding or removing this allowance is a substantive change. + Such an allowance cannot be added + to a technical report previously published as a Recommendation that did not allow such changes; + this requires a new technical report (which could, for example, be similarly named but with an incremented version number).

+

As technology evolves, + a W3C Recommendation may become:

+
+
A Superseded Recommendation +
+ A Superseded Recommendation is a specification + that has been replaced by a newer version + that W3C recommends for new adoption. + An Obsolete or Superseded specification + has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy. +

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, + the latest version replaces the previous one, + without the need to invoke the steps of § 6.3.12.3 Abandoning a W3C Recommendation: + it is the same document, updated. + Explicitly declaring a documented superseded, using the process documented in § 6.3.12.3 Abandoning a W3C Recommendation, + is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

+
An Obsolete Recommendation +
An Obsolete Recommendation is a specification + that W3C has determined lacks sufficient market relevance + to continue recommending it for implementation, + but which does not have fundamental problems + that would require it to be Rescinded. + If an Obsolete specification gains sufficient market relevance, + W3C may decide to restore it to Recommendation status. +
Rescinded Recommendation +
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, + and believes is unlikely to ever be restored to Recommendation status. + See also “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+
Discontinued Draft +
A technical report representing the state of a Recommendation-track document + at the point at which work on it was discontinued. + See § 6.3.12.1 Abandoning an Unfinished Recommendation. +
+

Only sufficiently technically mature work should be advanced.

+

Note: Should faster advancement to meet scheduling considerations be desired, + this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring + less stable features to other technical reports.

+

When publishing an updated version of an existing Candidate Recommendation or Recommendation, + technical reports are expected to meet the same maturity criteria as when they are first published under that status. + However, in the interest of replacing stale documents with improved ones in a timely manner, + if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, + it is also permissible to publish an updated CR or REC following the usual process, + even if only some of these flaws have been satisfactorily addressed.

+

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, + and do not necessarily imply consensus of a Working Group or Interest Group, + nor are their contents endorsed in any way by W3C.

+

6.3.2. Implementation Experience

+

Implementation experience is required to show that a specification is sufficiently clear, + complete, + and relevant to market needs, + to ensure that independent interoperable implementations + of each feature of the specification will be realized. + While no exhaustive list of requirements is provided here, + when assessing that there is adequate implementation experience the Team will consider (though not be limited to):

+
    +
  • is each feature of the current specification implemented, + and how is this demonstrated? +
  • are there independent interoperable implementations of the current specification? +
  • are there implementations created by people other than the authors of the specification? +
  • are implementations publicly deployed? +
  • is there implementation experience + at all levels of the specification’s ecosystem + (authoring, consuming, publishing…)? +
  • are there reports of difficulties or problems with implementation? +
+

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. + Groups are often able to work more effectively + if they plan how they will demonstrate interoperable implementations + early in the development process; + for example, developing tests in concert with implementation efforts.

+

6.3.3. Advancement on the Recommendation Track

+

For all requests to advance a specification + to a new maturity stage + (called Transition Requests), + the Working Group:

+
    +
  • must record the group’s decision to request advancement. +
  • must obtain Team verification. Team verification (a Team decision) must be withheld if any Process requirements are not met + or if there remain any unresolved Formal Objections + (including any aspect upheld by a Council but not yet fully addressed), + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects a Transition Request it must indicate its rationale + to the Advisory Committee and the Working Group. +
  • must publicly document all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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 stage. +
  • must provide public documentation of any Formal Objections. +
  • should report which, if any, of the Working Group’s requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

For a First Public Working Draft there is no “previous maturity stage”, + so many requirements do not apply, + and verification is normally fairly straightforward. + For later stages, + especially transitions to Candidate or Recommendation, + there is usually a formal review meeting + to verify that the requirements have been met.

+

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved + while a Working Group’s charter is undergoing or awaiting a decision + on an Advisory Committee Review.

+

6.3.4. Updating Mature Publications on the Recommendation Track

+

Certain requests to re-publish a specification + within its current maturity stage + (called Update Requests) + require extra verification. + For such update requests, the Working Group:

+
    +
  • must record the group’s decision to request the update. +
  • must show that the changes have received wide review. +
  • + must obtain Team verification. Team verification (a Team decision): +
      +
    • +

      should be withheld +if any Process requirements are not met,

      +
    • +

      may be withheld +in consideration of unresolved Formal Objections +(including any aspect upheld by a Council but not yet fully addressed),

      +
    • +

      may be withheld +if the document does not adequately reflect +all relevant decisions of a W3C Council (or its delegates),

      +
    • +

      may be withheld +if the Team believes the Group is not making reasonable progress +on addressing issues raised by individuals external to the Group.

      +
    +

    If the Team rejects an Update Request, + it must indicate its rationale to the Working Group. + If it waives any Process requirements, + it must indicate its rationale to the AC.

    +
  • must provide public documentation of any Formal Objections. +
  • must publicly document of all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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, + or explain why the requirements have changed or been deferred, +
  • should report which, if any, of the Working Group’s requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

There is usually a formal review meeting + to verify that the requirements have been met.

+

Note: Update request verification is expected to be fairly simple + compared to verification of a transition request.

+

The Team must announce the publication + of the revised specification + to other W3C groups and the Public.

+

6.3.5. Publishing a First Public Working Draft

+

To publish the First Public Working Draft of a document, + a Working Group must meet the applicable requirements for advancement.

+

The Team must announce + the publication of a First Public Working Draft to other W3C groups and to the public.

+

6.3.6. Revising a Working Draft

+

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.

+

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

+
    +
  • must record the group’s decision to request publication. Consensus is not required, + as this is a procedural step, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Working Draft, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous step, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups, +
+

Possible next steps for any Working Draft:

+ +

6.3.7. Transitioning to Candidate Recommendation

+

To publish a Candidate Recommendation, + in addition to meeting the requirements for advancement a Working Group:

+
    +
  • must show that the specification + has met all Working Group requirements, + or explain why the requirements have changed or been deferred, +
  • must document changes to dependencies during the development of the specification, +
  • must document + how adequate implementation experience will be demonstrated, +
  • must specify the deadline for comments, + delineating the Candidate Recommendation review period, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • must show that the specification has received wide review, and +
  • may identify features in the document as at risk. + These features may be removed + before advancement to Recommendation without requiring an Update Request. +
+

The first Candidate Recommendation publication + after verification of having met the requirements for a Transition Request is always a Candidate Recommendation Snapshot. + The Team must announce + the publication of the Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

Possible next steps after a Candidate Recommendation Snapshot:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.8. Revising a Candidate Recommendation

+
6.3.8.1. Publishing a Candidate Recommendation Snapshot
+

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, + the Working Group must meet the requirements of an update request in order to republish.

+

In addition the Working Group:

+
    +
  • must specify the deadline for further comments, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • may identify features in the document as at risk. + These features may be removed + before advancement to Recommendation without requiring an Update Request. +
+

The Team must announce + the publication of a revised Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

To provide timely updates and patent protection, + a Candidate Recommendation Snapshot should be published + within 24 months of the Working Group accepting + any proposal for a substantive change + (and preferably sooner). + To make scheduling reviews easier, + a Candidate Recommendation Snapshot should not be published + more often than approximately once every 6 months.

+

Note: Substantive changes trigger a new Exclusion Opportunity + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.8.2. Publishing a Candidate Recommendation Draft
+

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 + that would benefit from review beyond the Working Group.

+

To publish a revision of a Candidate Recommendation Draft, + a Working Group:

+
    +
  • must record the group’s decision to request publication, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups. +
+

Note: A Working Group does not need to + meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

+

Possible next steps after a Candidate Recommendation Draft:

+ +

6.3.9. Transitioning to Recommendation

+

When a Working Group estimates + that a Candidate Recommendation has fulfilled all the relevant criteria, + it may decide to request advancement to W3C Recommendation.

+
6.3.9.1. Requirements for Transition
+

In addition to meeting the requirements for advancement, + the Working Group:

+ +

Additionally, + if the document has previously been published as a W3C Recommendation, the Working Group must not include any class 4 change to that publication + unless it was explicitly marked as allowing new features, + and must not include any such marking + if not already present.

+

If the document’s most recent publication is a Candidate Recommendation Draft, + the Team must verify + that it contains no changes since the previous Candidate Recommendation Snapshot other than:

+ +

Otherwise, the Working Group must republish it + as a Candidate Recommendation Snapshot prior to initiating the review.

+
6.3.9.2. Initiating Review
+

If all the criteria above are fulfilled, + the Team must begin an Advisory Committee Review on the question of whether the identified Candidate Recommendation is appropriate to publish as a W3C Recommendation. + The deadline for Advisory Committee review must allow at least 28 days, + and must end at least 10 days + after the end of the last Exclusion Opportunity + per ”Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.9.3. Resolution of Review
+

If there was any Formal Objection during the Advisory Committee Review, + the Team must publish the substantive content of the dissent to W3C and the general public, + and the W3C Recommendation must not be published + unless all Formal Objections to the document have been retracted or overruled and at least 14 days have elapsed since the publication of the corresponding Council Report.

+

The decision to advance a document to Recommendation is a W3C Decision. + The Team must announce the publication of a W3C Recommendation to the Advisory Committee, + to other W3C groups + and to the public. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

The newly published Recommendation must not make any substantive changes to the document + compared to the Candidate Recommendation Snapshot submitted for AC Review, + other than dropping features identified at risk.

+
6.3.9.4. Next Steps from W3C Recommendation
+

Possible next steps: + A W3C Recommendation normally retains its status indefinitely. + However it may be:

+ +

6.3.10. Revising a W3C Recommendation

+
6.3.10.1. Revising a Recommendation: Editorial Changes
+

Editorial changes to a Recommendation require no technical review of the intended changes. + A Working Group, + provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity stages. + (See class 1 and class 2 changes.)

+
6.3.10.2. Revising a Recommendation: Substantive Changes
+

Tentative corrections (see class 3 changes) may be annotated into a Recommendation using candidate corrections.

+

Note: Candidate corrections do not normatively modify the document; + they editorially indicate how one might do so. + They are therefore published following the provisions of § 6.3.10.1 Revising a Recommendation: Editorial Changes.

+

A candidate correction can be made normative + and be folded into the main text of the Recommendation, + once it has satisfied all the same criteria + as the rest of the Recommendation, + including review by the community to ensure + its technical and editorial soundness. + To validate this, the Working Group must request + a Last Call for Review of Proposed Amendments, + followed by an update request. + See § 6.3.10.4 Incorporating Candidate Amendments.

+

Alternatively, + a Working Group may incorporate the changes + and publish as a Working Draft—​or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—​and advance the specification from that state. + (See class 3 changes.)

+
6.3.10.3. Revising a Recommendation: New Features
+

For Recommendations explicitly identified as allowing new features, + tentative new features (see class 4 changes) may be added as candidate additions in annotations, + and class 4 changes may be normatively incorporated + in the same fashion as class 3 changes in § 6.3.10.2 Revising a Recommendation: Substantive Changes.

+

Note: Limiting the addition of new features to Recommendations that explicitly allow them + enables third parties to depend on a stable feature-set for Recommendations that do not advertise that ability, + as was the case for all Recommendations prior to the 2020 revision of this Process.

+

Note: When a Recommendation does not allow new features, + new features can be added by creating a new technical report and following the full process of advancing that technical report to Recommendation—​beginning with a new First Public Working Draft. + Such technical reports could be written to represent + additional modules building on top of the original Recommendation of the core technology, + or an expanded replacement of the original Recommendation of the core technology + (in which case the new technical report will typically have the same name as the original, + with an incremented version number).

+
6.3.10.4. Incorporating Candidate Amendments
+

A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.

+

The Last Call for Review of Proposed Amendments must be announced to other W3C groups, the public, and the Advisory Committee. + The announcement must:

+
    +
  • Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, + or Last Call for Review of Proposed Corrections and Additions. +
  • Identify the specific candidate amendments under review + as proposed amendments (proposed corrections/proposed additions). +
  • Specify the deadline for review comments, + which must not be any sooner than 60 days from the Call for Review. +
  • Solicit review and, if it does not already have it, implementation experience. +
+

The combination of the existing Recommendation with the proposed amendments included in the Last Call for Review of Proposed Amendments is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. + Also, the review initiated by the Last Call for Review of Proposed Amendments is an Advisory Committee Review.

+

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

+

A Working Group may batch + multiple proposed amendments into a single Last Call for Review of Proposed Amendments. + To facilitate review, + a Last Call for Review of Proposed Amendments on a given specification should not be issued more frequently + than approximately once every 6 months.

+

At the end of the Last Call for Review of Proposed Amendments, + the W3C Decision may either be + to reject the proposed amendment, + or to clear the proposed amendment for advancement as is, + or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. + If the Working Group needs to amend a proposed amendment in response to review feedback + it must issue another Last Call for Review of Proposed Amendments on the revised change + before it can be incorporated into the main text.

+

Once all comments on a proposed amendment have been formally addressed, + and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, + it may incorporate the proposed amendment into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

+

To ensure adequate review of proposed amendment combinations, + only proposed amendments included in the most recent Last Call for Review of Proposed Amendments can be incorporated into the normative Recommendation text. + (Thus if incorporation of a proposed amendment is postponed, + it may need to be included in multiple Last Calls for Review of Proposed Amendments.)

+

6.3.11. Regression on the Recommendation Track

+

A Working Group may republish a Recommendation-track technical report at a lower maturity stage by fulfilling the requirements to transition to that maturity stage, + as described above.

+

Additionally, + with the approvals (by group decision) of each of the TAG and the AB the Team may return + the technical report to a lower maturity stage in response to wide review or a formal objection.

+

6.3.12. Retiring Recommendation Track Documents

+

Work on a technical report may cease at any time. + Work should cease + if W3C or a Working Group determines + that it cannot productively carry the work any further.

+
6.3.12.1. Abandoning an Unfinished Recommendation
+

Any Recommendation-track technical report no longer intended + to advance or to be maintained, + and that is not being rescinded, should be published as a Discontinued Draft, + with no substantive change compared to the previous publication. + This can happen if + the Working Group decided + to abandon work on the report, + or as the result of an AC Review requiring the Working Group to discontinue work on the technical report before completion. + If a Working Group is made to close, + W3C must re-publish any unfinished technical report on the Recommendation track as Discontinued Draft.

+

Such a document should include in its status section + an explanation of why it was discontinued.

+

A Working Group may resume work + on such a technical report within the scope of its charter + at any time, + by re-publishing it as a Working Draft.

+
6.3.12.2. Rescinding a Candidate Recommendation
+

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

+
6.3.12.3. Abandoning a W3C Recommendation
+

It is possible that W3C decides + that implementing a particular Recommendation is no longer recommended. + There are three designations for such specifications, + chosen depending on the advice W3C wishes to give about further use of the specification.

+

W3C may obsolete a Recommendation, + for example if the W3C Community decides that the Recommendation no longer represents best practices, + or is not adopted and is not apparently likely to be adopted. + An Obsolete Recommendation may be restored to normal Recommendation, + for example because despite marking it Obsolete the specification is later more broadly adopted.

+

W3C may declare a Recommendation Superseded + if a newer version exists which W3C recommends for new adoption. + The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; + only the name and explanation change.

+

W3C may rescind a Recommendation + if W3C believes there is no reasonable prospect of it being restored + for example due to burdensome patent claims that affect implementers and cannot be resolved; + see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” + and “PAG Conclusion”.

+

W3C only rescinds, supersedes, or obsoletes entire Recommendations. + A Recommendation can be both superseded and obsolete. + To rescind, supersede, or obsolete some part of a Recommendation, + W3C follows the process for modifying a Recommendation.

+

Note: For the purposes of the W3C Patent Policy, [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, + although it is not advised for future implementation; + a Rescinded Recommendation ceases to be in effect + and no new licenses are granted under the Patent Policy.

+
+ + Supersede, Obsolete or Rescind a W3C Recommendation + + + + Recommendation (Rec) + + + + + A major problem and an AC review can lead to a Recommendation being Rescinded. + There are no new IPR licences issued under the W3C Patent Policy, + and reinstating the Recommendation requires going through the full Rec-track process again. + + Major problem, AC review + + + Rescinded Recommendation - no new IPR licenses + + + + + + + + + With little uptake, following AC review a specification may become an Obsolete Recommendation + + + + + Obsolete Recommendation + + + + + + + + If there is new uptake, with AC review an Obsolete Recommendation may return to normal Recommendation status + + + + + + + + + + + Replaced by a new version, AC review + + Superseded Recommendation + + + + + + + A Superseded Recommendation can become a normal Recommendation with AC review + + + + + + + + + + + +
Non-Normative Summary of the Paths to Retiring a W3C Recommendation
+
+
6.3.12.4. Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
+

The process of rescinding, obsoleting, + superseding, + or restoring + a Recommendation can be initiated + either by a request from the Team or via a request from any of the following:

+ +

The Team must then + submit the request to the Advisory Committee for review. + For any Advisory Committee review of a proposal to + rescind, + obsolete, + supersede, + or restore + a Recommendation the Team must:

+
    +
  • announce the proposal to all Working Group Chairs, + and to the Public, + as well as to the Advisory Committee +
  • indicate that this is a proposal to + Rescind, + Obsolete, + Supersede, + or restore, + a Recommendation as appropriate +
  • identify the Recommendation by URL +
  • publish a rationale for the proposal +
  • identify known dependencies + and solicit review from all dependent Working Groups +
  • solicit public review +
  • specify the deadline for review comments, + which must be at least 28 days + after the announcement +
+

and should

+
    +
  • identify known implementations. +
+

If there was any dissent in the Advisory Committee review, + the Team must publish + the substantive content of the dissent to W3C and the public, + and must formally address the dissent + at least 14 days + before publication as an Obsolete or Rescinded Recommendation.

+

The Advisory Committee may initiate an Advisory Committee Appeal of the Team’s decision.

+

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. + The updated version may remove the main body of the document. + The Status of this Document section should link + to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

+

Once W3C has published a Rescinded Recommendation, + future W3C technical reports must not include normative references + to that technical report.

+

Note: W3C strives to ensure that all Technical Reports + will continue to be available at their version-specific URL.

+

6.4. The Note Track (Notes and Statements)

+

6.4.1. Group Notes

+

A Group Note (NOTE) + is published + to provide a stable reference for a useful document + that is not intended to be a formal standard.

+

Working Groups, Interest Groups, + the TAG and the AB may publish work as Notes. + Examples include:

+
    +
  • supporting documentation for a specification, + such as explanations of design principles + or use cases and requirements +
  • non-normative guides to good practices +
+

Some Notes are developed through successive Note Drafts before publication as a full Notes, + while others are published directly as a Note. + There are few formal requirements to publish a document as a Note or Note Draft, + and they have no standing as a recommendation of W3C + but are simply documents preserved for historical reference.

+

Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Note Drafts.

+

6.4.2. Publishing Notes

+

In order to publish a Note or Note Draft, + the group:

+
    +
  • must record their decision + to request publication as a Note or Note Draft, and +
  • should publish documentation + of significant changes to the technical report + since any previous publication. +
+

Both Notes and Note Drafts can be updated by republishing + as a Note or Note Draft. + A technical report may remain + a Note indefinitely.

+

6.4.3. Elevating Group Notes to W3C Statement status

+

A W3C Statement is a Note that has been endorsed by W3C as a whole. + In order to elevate a Note to W3C Statement status, + A group must:

+ +

A Note specifying implementable technology should not be elevated to W3C Statement status; + if it does, + the request to publish as a Statement must include rationale + for why it should be elevated, + and why it is not on the Recommendation track.

+

Once these conditions are fulfilled, + the Team must then + begin an Advisory Committee Review on the question of + whether the document is appropriate to publish as a W3C Statement. + During this review period, + the Note must not be updated.

+

The decision to advance a document to W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

The Team must announce the publication of a W3C Statement to the Advisory Committee, other W3C groups, and the public.

+

6.4.4. Revising W3C Statements

+

Given a recorded group decision to do so, + groups can request publication of a W3C Statement with editorial changes—​including candidate amendment—​without any additional process.

+

A candidate amendment can be folded into the main text of the W3C Statement, + once it has satisfied all the same criteria + as the rest of the Statement, + including review by the community to ensure + the substantive and editorial soundness of the candidate amendments. + To validate this, the group must request + an Advisory Committee review of the changes it wishes to incorporate. + The specific candidate amendments under review must be identified as proposed amendments just as in a Last Call for Review of Proposed Corrections.

+

The decision to incorporate proposed amendments into W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

6.5. The Registry Track

+

A registry documents a data set + consisting of one or more registry tables, + each table representing an updatable collection + of logically independent, consistently-structured registry entries. + A registry consists of:

+ +

The purposes of maintaining a registry can include:

+
+
non-collision +
Avoiding the problem + of two entities using the same value with different semantics. +
non-duplication +
Avoiding the problem + of having two or more different values in use with the same semantics. +
information +
Providing a central index + where anyone can find out + what a value means + and what its formal definition is + (and where it is). +
submission +
Ease of adding new terms, + including by stakeholders external to the custodian organization. +
consensus +
Promoting a clear consensus of the community on the terms. +
+

This section of the W3C Process provides a specialized process + facilitating the publication and maintenance of such registry tables, + particularly those required by or closely related to W3C Recommendations.

+

Note: Not every table in a specification is a potential registry. + If the intent or effect is that the table enumerates + all the possibilities the authors of the specification expect or envisage, + then the table by itself is enough. + Similarly, if the table is managed by the Working Group + and only updated as part of specification update, + then the complexities of registry management are not needed.

+

6.5.1. Registry Definitions

+

A registry definition defines what each registry table is and how it is maintained. + It must:

+
    +
  • Define the scope and purpose of each registry table. +
  • Define the fields of each registry table and their constraints + (e.g. values must be drawn from a defined set, or be unique, + or only reference publicly available resources, + etc.) +
  • + Define the policy for changes to existing entries, such as +
      +
    • whether entries can be deleted or deprecated +
    • whether entries can be changed after being published, and what kinds of changes are allowed +
    • whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely +
    +
  • Define the method and criteria by which changes are proposed, approved, and incorporated. + (For example, a registry could define + that changes to registry entries can be proposed using a particular web form or email address, + that they must be accompanied by certain background information, + or that they do or do not need to be approved by any member of a particular Working Group.) +
  • + Identify the custodian of the registry table: + the entity to which requests for registry changes must be sent, + and which is responsible for evaluating whether such requests + satisfy the criteria defined in the registry definition. +

    The custodian may be the initiating group, the Team, or a delegated entity. + The custodian for all registry tables in a single registry should generally be the same entity.

    +

    If the custodian of a registry table ceases to exist or to operate as a custodian + (e.g., the relevant group is disbanded, or + the custodian is unresponsive to repeated attempts to make contact), + and the chartered or elected group that owns the registry definition is itself closed or + unresponsive, + the Team should propose replacing the custodian, + which must be confirmed + by an AC Review as a W3C Decision.

    +
+

6.5.2. Publishing Registries

+

A chartered or elected group can publish a registry as a stand-alone technical report on the Registry Track, + where it is called a registry report. Working Groups have the additional option of + incorporating a registry as part of a Recommendation, + as an embedded registry.

+

The registry report or embedded registry must:

+ +

The Team must make available + a means for interested parties to be notified of any updates to a registry table.

+

Note: Since the Process does not impose requirements + on changes to the contents of a registry table other than those imposed by the registry definition, + acceptance of proposed registry changes on behalf of the custodian and + publication of an updated registry report that contains + only registry changes since the previous publication + can be automated + if satisfaction of those rules can be automatically verified.

+

Rules for publication and advancement on the Registry Track are identical to that of the Recommendation Track with the following exceptions:

+ +

6.5.3. Updating Registry Tables

+

Changes to the contents of a registry table that are in accordance with the registry definition, + (i.e. Class 5 changes) + can be made by re-publishing the technical report that contains the affected table, + without needing to satisfy any other requirements for the publication + (not even a group decision, unless this is required by the registry definition). + Such registry changes do not trigger new Advisory Committee Reviews, + nor Exclusion Opportunities, + and do not require verification via an update request, + even for technical reports at maturities where this would normally be expected. + Such publications can be made + even in the absence of a group chartered to maintain the registry + when the custodian is another entity.

+

Note: The custodian is only empowered to make registry changes. + If the group establishing the registry wishes + to empower the custodian to add commentary on individual entries, + this needs to be part of the registry table’s definition. + If other changes are desired, + they need to be requested of the group responsible for maintaining the registry definition—​or in the absence of such a group, of the Team.

+

Changes to the registry tables made in accordance with candidate or proposed amendments to the registry definition which would not be allowed by the unamended registry definition must be identified as such.

+

6.5.4. Registry Data Reports

+

When the registry data is published in a separate technical report from its registry definition, + that report is called a Registry Data Report. + This technical report:

+ +

Registry Data Reports do not have maturity stages in and of themselves; + The maturity stage of the registry whose data they record + is that of the technical report holding the registry definition.

+

Anytime a change is made to a registry definition, + the group maintaining the registry definition must update and republish + any document holding the corresponding registry tables to make it consistent with these changes.

+

Given a recorded group decision to do so, + the group maintaining the registry definition may republish the Registry Data Report to incorporate editorial changes.

+

6.5.5. Specifications that Reference Registries

+

Registries document values, + they do not define any architectural or interoperability requirements + related to those values. + All architectural and interoperability requirements + pertaining to registry entries must be contained in the specifications that reference the registry, + and are therefore subject to the processes + (including approval and intellectual property provisions) + applicable to those referencing specifications.

+

If there are entries that must be implemented, + or any other such restrictions, + they must be defined or documented + in the referencing specification + without dependency on the registry.

+
For example, “All implementations must implement the Basic-Method as defined in the registry” is not acceptable because + a change to the definition of the Basic-Method in the registry would then affect conformance. + Instead, the requirement has to be complete in the specification, + directly or by reference to another specification. + For example “All implementations must recognize the name Basic-Method, + and implement it as defined by section yy of IETF RFC xxxx”. + (The Registry is nonetheless expected to contain Basic-Method as an entry.)
+

6.5.6. Registries and Patents

+

A registry report or embedded registry is not subject to the W3C Patent Policy, + and must not define any requirements on implementations. + For the purposes of the Patent Policy [PATENT-POLICY] (only), + any embedded registry in a Recommendation track document + is not a normative portion of that specification.

+

6.6. Switching Tracks

+

Given a Group decision to do so, Working Groups can republish a technical report on a different track than the one it is on, + under the following restrictions:

+ +

Technical reports that switch tracks start at + their new track’s initial maturity stage, + while retaining any established identity (url, shortname, etc.).

+

Note: The initial maturity stage of the Recommendation track is Working Draft. First Public Working Draft designates a specific type of Working Draft and is not a separate maturity stage. + A document which switches to the Recommendation track is only published as a First Public Working Draft if it was never previously published as such; + otherwise, it is simply a Working Draft.

+

6.7. Further reading

+

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews + and announcements of the various steps, + and tips on getting to Recommendation faster [REC-TIPS]. + Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

+

7. Dissemination Policies

+

7.1. Public Communication

+

The Team is responsible for managing communication within W3C + and with the general public + (e.g., news services, press releases, managing the website and access privileges, and managing calendars). + Members should solicit review by the Team + prior to issuing press releases about their work within W3C.

+

The Team makes every effort to ensure the persistence and availability of the following public information:

+ +

To keep the Members abreast of W3C meetings, Workshops, + and review deadlines, + the Team provides them with a regular (e.g., weekly) news service + and maintains a calendar [CALENDAR] of official W3C events. + Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

+

7.2. Confidentiality Levels

+

There are three principal levels of access to W3C information + (on the W3C website, in W3C meetings, etc.): + public, + Member-only, + and Team-only.

+

While much information made available by W3C is public, + “Member-only” information + is available to authorized parties only, + including representatives of Member organizations, Invited Experts (as described in https://www.w3.org/invited-experts/#memaccess), + the Advisory Board, + the TAG, + and the Team. + For example, + the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

+

“Team-only” information + is available to the Team and other authorized parties.

+

Those authorized to access Member-only and Team-only information:

+
    +
  • must treat the information as confidential within W3C, +
  • must use reasonable efforts to preserve that confidentiality, and +
  • must not release this information to the general public or press, + nor beyond the proper level of access. +
+

The Team must provide mechanisms + to protect the confidentiality of Member-only information + and ensure that authorized parties have proper access to this information. + Documents should clearly indicate + whether they require Member-only confidentiality. + Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

+

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member + who are considered appropriate recipients. + For instance, + it is the responsibility of the Advisory Committee representative and other employees + and official representatives of the organization + to ensure that Member-only news announcements + are distributed for internal use only within their organization. + Information about Member mailing lists is available + in the New Member Orientation [INTRO].

+

7.3. Changing Confidentiality Level

+

As a benefit of membership, + W3C provides some Team-only and Member-only channels + for certain types of communication. + For example, Advisory Committee representatives can send reviews to a Team-only channel. + However, for W3C processes with a significant public component, + such as the technical report development process, + it is also important for information that affects decision-making to be publicly available. + The Team may need to communicate Team-only information to a Working Group or the public. + Similarly, a Working Group whose proceedings are Member-only must make public + information pertinent to the technical report development process.

+

This document clearly indicates which information must be available to Members or the public, + even though that information was initially communicated on Team-only or Member-only channels. + Only the Team and parties authorized by the Team + may change the level of confidentiality of this information. + When doing so:

+
    +
  1. The Team must use a version of the information + that was expressly provided by the author for the new confidentiality level. + In Calls for Review and other similar messages, + the Team should remind recipients to provide such alternatives. +
  2. The Team must not attribute the version + for the new confidentiality level to the author without the author’s consent. +
  3. If the author has not conveyed to the Team a version + that is suitable for another confidentiality level, + the Team may make available a version that reasonably communicates what is required, + while respecting the original level of confidentiality, + and without attribution to the original author. +
+

8. Liaisons

+

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, + through a number of mechanisms + ranging from very informal + (e.g., an individual from another organization participates in a W3C Working Group, + or just follows its work) + to mutual membership, + to even more formal agreements. + Liaisons are not meant to substitute for W3C membership.

+

All liaisons must be coordinated by the Team due to requirements for public communication; + patent, + copyright, + and other IPR policies; + confidentiality agreements; + and mutual membership agreements.

+

W3C may negotiate technical agreements with another organization. + For purposes of the W3C Process, + a technical agreement is a formal contract, + or a Memorandum of Understanding (MoU), + or a similar document, + between W3C and another party or parties, + that relates to the technical activity of the Consortium + (e.g., its publications, groups, or liaisons). + It specifies rights and obligations of each party toward the others. + These rights and obligations may include joint deliverables, + an agreed share of technical responsibilities with due coordination, + and/or considerations for confidentiality and specific IPR.

+

Non-technical agreements, including + those between W3C and its Members for the purposes of membership, + between W3C and its Partners for the purposes of partnership [BYLAWS], + and other agreements related to the operation of the Consortium + or to the ordinary provision of services, + are not subject to these Process provisions.

+

When considering a technical agreement (i.e., before the decision whether to sign is made), + the Team should provide + the Advisory Committee with a draft of the proposed agreement, + along with an explanation of how W3C would benefit from signing this agreement, + for their review and discussion. + After addressing any comments, + and subject to any management or governance procedures that apply + (e.g., formal review of proposed contracts by legal counsel or by the Board), + if the Team decides to proceed with signing the agreement, + the Team must announce the intent to sign, + and provide the final text of the agreement, + with an explanation of signing rationale, to + the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the agreement. + If the proposal is rejected on appeal, + the Team must not sign the agreement on behalf of W3C + unless directed to do so by the Board. + A signed agreement should be made public.

+

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

+

9. Member Submissions

+

A Member Submission is a document or set of documents + developed outside of W3C, + and submitted to W3C + by one or more Members (the Submitter(s)) + to propose technology or other ideas. + After review, + the Team may make the material available at the W3C website.

+

Making a Member Submission available at the W3C website + does not indicate endorsement, acceptance, or adoption by W3C, + its Team, or its Members. + The acknowledgment of a Submission request + does not imply that any action will be taken by W3C. + It merely records publicly + that the Submission has been made by the Submitter(s). + A Member Submission made available by W3C + is not a W3C technical report and must not be referred to as + an output or “work in progress” of W3C.

+

The Member Submission process consists of the following steps:

+
+
Submission +
One of the Submitters, + copying the Advisory Committee representatives of the other Submitters (if any), + sends a request to the Team to acknowledge the Submission request. + The Team and Submitter(s) communicate to ensure that the Member Submission is complete. +
Review +
+ The Team reviews the Submission + to evaluate its scope, quality, and compliance with the Submission requirements, + including licensing requirements: + +

Detailed procedures and requirements are defined by the Team and documented in the “Member submissions guidebook” [MEMBER-SUB].

+
Decision +
+ After review, the Team must either acknowledge or reject the Submission request. + +
+

The Advisory Committee representative(s) of the Submitter(s) may initiate a Submission Appeal. + The procedure for handling Submission Appeals is the same as for Formal Objections, + except that an AC Appeal is not possible + and both the Formal Objection and the Council Report are confidential to the Team, TAG, and AB.

+

10. Process Evolution

+

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, + with the Advisory Board acting as the sponsoring Working Group. + The documents may be developed by the AB or by another group to whom the AB has delegated development. + Review includes + soliciting input from the W3C community, + and in particular the Team.

+

The documents covered by this section are:

+ +

The Advisory Board initiates review as follows:

+
    +
  1. The Team sends a Call for Review to the Advisory Committee and other W3C groups. +
  2. After comments have been formally addressed and the document possibly modified, + the Team seeks endorsement from the Members by initiating an Advisory Committee review. + The review period must last at least 28 days. +
  3. After the Advisory Committee review, + following a W3C decision to adopt the document(s), + the Team does so + and sends an announcement to the Advisory Committee. + Advisory Committee representatives may initiate + an Advisory Committee Appeal to W3C. +
+

Note: As of June 2020, + the Patent Policy is developed in the Patents and Standards Interest Group, + the Code of Conduct in the Positive Work Environment Community Group, + and the Process in the W3C Process Community Group.

+

Appendix A: Retired Terminology

+

This section is non-normative.

+

Previous versions of this process defined and used various concepts and document statuses + that have since been retired or renamed. + For ease of reference, + this appendix lists the more notable ones, + and it links to the the definition or relevant section + in the most recent version of the Process that used them, + and gives the more recent equivalent term when there is one.

+
+
Amended Recommendation (retired term) +
Last defined in section 6.2.1 of the 2020 Process. +
Edited Recommendation (retired term) +
Last defined in section 6.1.2 of the 2019 Process. +
Last Call (retired term) +
Last defined in section 7.4.2 of the 2005 Process. +
Maturity level (renamed term) +
Last defined in section 6.3.1 of the 2021 Process, + now called maturity stage. +
Member Consortium, plural: Member Consortia + (renamed term) +
Last defined in section 2.1.2.1 of the 2021 Process, + now called Member Association. +
Memorandum of Understanding, plural: Memoranda of Understanding, abbreviation: MoU + (renamed term) +
Last defined in section 9 of the 2021 Process, + now called technical agreement. +
Other Charter (renamed term) +
Last used in section 5.2.6 of the 2020 Process, + now called Exclusion Draft Charter. +
Proposed Recommendation (retired term) +
Last defined in section 6.3.1 of the 2023 Process. +
Team Submissions (retired term) +
Last defined in section 2.2.1 of the 2019 Process. +
W3C Chair (renamed term) +
Last defined in section 2.2 of the 2014 Process, + now called CEO. +
+

Appendix B: Acknowledgments

+

This section is non-normative.

+

The editors are grateful to the following people, + who as interested individuals and/or with the affiliation(s) listed, + have contributed to this proposal for a revised Process: + Adam Basha, + Anna Weinberg (Apple) + Charles McCathie Nevile, + Chris Lilley (W3C), + Chris Needham (BBC), + Chris Wilson (Google), + Coralie Mercier (W3C), + David W. Singer (Apple), + Denis Ah-Kang (W3C), + Dominique Hazael-Massieux (W3C), + Ian Jacobs (W3C), + Jeffrey Yasskin (Google), + Jill Schmidt (Apple), + Marcos Cáceres (Apple), + Mark Nottingham, + Martin Thomson (Mozilla), + Michael Champion, + Michael Sirtori (Intel), + Mike Smith (W3C), + Nick Doty (Center for Democracy and Technology), + Nigel Megitt (BBC), + Philippe Le Hégaret (W3C), + Sam Sneddon (Apple), + Shawn Lawton Henry (W3C), + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Theresa O’Connor (Apple), + Vivien Lacourba (W3C).

+

The editors are sorry for forgetting any names, + and grateful to those who have listened patiently to conversations about this document + without feeling a need to add more.

+

The following individuals contributed to the development of earlier versions of the Process: + Alex Russell (Google), + Andreas Tai (Institut fuer Rundfunktechnik), + Andrew Betts (Fastly), + Ann Bassetti (The Boeing Company), + Anne van Kesteren, + Art Barstow (Nokia, unaffiliated), + Bede McCall (MITRE), + Ben Wilson, + Brad Hill (Facebook), + Brian Kardell (JQuery, Igalia), + Carine Bournez (W3C), + Carl Cargill (Netscape, Sun Microsystems, Adobe), + Charles McCathie Nevile (ConsenSys), + Chris Lilley (W3C), + Chris Needham (BBC), + Chris Wilson (Google), + Claus von Riegen (SAP AG), + Coralie Mercier (W3C), + Cullen Jennings (Cisco), + Dan Appelquist (Telefonica, Samsung), + Dan Connolly (W3C), + Daniel Dardailler (W3C), + Daniel Glazman (Disruptive Innovations), + David Baron (Mozilla), + David Fallside (IBM), + David W. Singer (Apple), + David Singer (IBM), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Don Brutzman (Web3D), + Don Deutsch (Oracle), + Eduardo Gutentag (Sun Microsystems), + Elika J. Etemad aka fantasai, + Florian Rivoal, + Fuqiao Xue (W3C), + Geoffrey Creighton (Microsoft), + Giri Mandyam (Qualcomm), + Gregg Kellogg, + Hadley Beeman, + Håkon Wium Lie (Opera Software), + Helene Workman (Apple), + Henri Sivonen (Mozilla), + Ian Hickson (Google), + Ian Jacobs (W3C), + Ivan Herman (W3C), + J Alan Bird (W3C), + Jay Kishigami 岸上順一 (NTT), + Jean-Charles Verdié (MStar), + Jean-François Abramatic (IBM, ILOG, W3C), + Jeff Jaffe (W3C), + Jeffrey Yasskin (Google), + Jim Bell (HP), + Jim Miller (W3C), + Joe Hall (CDT), + John Klensin (MCI), + Josh Soref (BlackBerry, unaffiliated), + Judy Brewer (W3C), + Judy Zhu 朱红儒 (Alibaba), + Kari Laihonen (Ericsson), + Karl Dubost (Mozilla), + Ken Laskey (MITRE), + Kevin Fleming (Bloomberg), + Klaus Birkenbihl (Fraunhofer Gesellschaft), + Larry Masinter (Adobe Systems), + Lauren Wood (unaffiliated), + Léonie Watson (The Paciello Group), + Liam Quin (W3C), + Marcos Cáceres (Mozilla), + Maria Courtemanche (IBM), + Mark Crawford (SAP), + Mark Nottingham, + Michael Champion (Microsoft), + Michael Geldblum (Oracle), + Mike West (Google), + Mitch Stoltz (EFF), + Natasha Rooney (GSMA), + Nigel Megitt (BBC), + Olle Olsson (SICS), + Ora Lassila (Nokia), + Paul Cotton (Microsoft), + Paul Grosso (Arbortext), + Peter Linss, + Peter Patel-Schneider, + Philippe Le Hégaret (W3C), + Qiuling Pan (Huawei), + Ralph Swick (W3C), + Renato Iannella (IPR Systems), + Rigo Wenning (W3C), + Rob Sanderson (J Paul Getty Trust), + Robin Berjon (W3C), + Sally Khudairi (W3C), + Sam Ruby (IBM), + Sam Sneddon, + Samuel Weiler (W3C), + Sandro Hawke (W3C), + Sangwhan Moon (Odd Concepts), + Scott Peterson (Google), + Shawn Lawton Henry, + Steve Holbrook (IBM), + Steve Zilles (Adobe Systems) + Steven Pemberton (CWI), + TV Raman (Google), + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Terence Eden (Her Majesty’s Government), + Thomas Reardon (Microsoft), + Tim Berners-Lee (W3C), + Tim Krauskopf (Spyglass), + Travis Leithead (Microsoft), + Virginia Fournier (Apple), + Virginie Galindo (Gemalto), + Wayne Carr (Intel), + Wendy Fong (Hewlett-Packard), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

Appendix C: Changes

+

This section is non-normative.

+

Changes since the 3 November 2023 Process

+

This document is based on the 3 November 2023 Process. + A list of issues addressed, + a diff from Process 2023 to this latest version, + as well as + a detailed log of all changes since then are available.

+

In addition to a number of editorial adjustments and minor tweaks, the following is a summary of the main differences:

+
+
Changes to technical reports and their publication +
+
    +
  • Retire the Proposed Recommendation phase of the Recommendation track. It was only used as a short-lived transition + during which various verifications and votes about CR were done. + These can be done on a CR + without having to republish it as a separate thing. + This simplifies the Process without changing the actual quality or consensus expectations. + (See Issue 861) +
  • Retire “Streamlined Publication Approval”. + This was meant to enable REC track publication with fewer/faster approval steps + when some stricter than usual criteria were fulfilled. + However, regular REC track publication have improved enough + that this became unnecessary, + and nobody was using it. + (See Issue 856) +
  • Add a requirement to make progress on external issues for update requests + (See Issue 781) +
  • Drop the requirement to publish every 6 months if nothing has changed. + (See Issue 1013) +
  • Enable Team to replace defunct registry custodians when no-one else can. + (See Issue 699) +
  • Allow registries to be published by Interest Groups, the Advisory Board, and the TAG, + in addition to Working Groups. + (See Issue 902) +
  • Rename “registry sections” to embedded registries to avoid confusion over whether they can be split across multiple sections of a Recommendation. + (See Issue 800) +
  • Rename "Draft Note" into "Note Draft", + and "Draft Registry" into "Registry Draft" + to be consistent with other statuses that uses the word "Draft", + and to make that word stand out more. + (See Issue 779) +
  • Clarify the definition of a Registry (see Issue 800) + and of Recommendation Track Documents (see Pull Request 831). +
  • Consolidate and harmonize into a one section the various parts of the Process + that described whether and how the Team can maintain technical reports + that no longer have a Group chartered to maintain them. + (See Pull Request 860) +
+
Changes to chartering +
+ +
Changes to formal decision making and escalation +
+
    +
  • Adjust the rules guiding initiation of Councils, + to make the deadline strict, + and to provide a fallback mechanism if they are not met. + (See Pull Request 925) +
  • Make the Council’s short-circuit a little more flexible. + (See Issue 852) +
  • Exclude TAG/AB Members from voting on TAG/AB proposals in Councils. + (See Issue 749) +
  • Limit the involvement of Tim Berners-Lee to the TAG proper, + not including the Council. + (See Pull Request 792) +
  • Council dismissal vote counts must be reported. + (See Issue 748) +
  • Require documentation of how Formal Objections get resolved. + (See Issue 953) +
  • Put constraints on the timing of making Formal Objections public. + (See Issue 735) +
  • Fine-tune the rules about + how changes can be incorporated into a proposal + following an AC Review. + (See Issue 825) +
  • Adjust AC appeal vote threshold based on participation, + aligning with the thresholds and super majority requirements + for "Requisite Member Vote" from the W3C Bylaws. + (See Issue 886) +
  • Let the originator of a proposal decide whether to try again + after addressing feedback + following an AC Appeal. + (See Issue 844) +
  • Simplify provisions regarding substitute representatives and proxies. + (See Issue 373) +
+
Other changes +
+
    +
  • Reuse the bylaws’ notion of Good Standing, + and restrict TAG and AB elections + as well as AC Votes where a decision is made based on counting ballots + to Members in Good Standing. + (See Issue 935 and Pull Request 954) +
  • The section on Member Submissions was significantly shortened and simplified, + reducing the complexity under formal Process authority, + and shifting much of the material to /Guide, + under Team authority. + (See Issue 412 and Pull Request 936) +
  • Clarify how the outcome of certain ballots are determined. + (See Issue 836, Issue 838) +
  • Stop citing the superseded TAG charter. + (See Issue 794) +
  • Clarify amount of leeway around incomplete nominations to TAG or AB elections. + (See Issue 464) +
  • Shift most of the non-normative discussion about Workshops to [GUIDE], + and reorganize the remaining normative requirements. + (See Pull Request 876) +
  • The URL of this document was changed + from /Consortium/Process/ to /policies/process/ + for better integration in the W3C website architecture. +
+

Changes since earlier versions

+

Changes since earlier versions of the Process are detailed + in the changes section of the previous version of the Process.

+
+
+
+

Conformance

+

Document conventions

+

Conformance requirements are expressed + with a combination of descriptive assertions + and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text + with class="example", + like this:

+
+ +

This is an example of an informative example.

+
+

Informative notes begin with the word “Note” + and are set apart from the normative text + with class="note", + like this:

+

Note, this is an informative note.

+
+ +
+

Index

+

Terms defined by this specification

+ +

Terms defined by reference

+ +

References

+

Normative References

+
+
[COC] +
W3C Code of Conduct. URL: https://www.w3.org/policies/code-of-conduct/ +
[COLLABORATORS-AGREEMENT] +
Invited expert and collaborators agreement. URL: https://www.w3.org/invited-experts/agreement-2023/ +
[CONFLICT-POLICY] +
Conflict of Interest Policy for the W3C Team. URL: https://www.w3.org/policies/conflict-of-interest-policy-for-w3c-team/ +
[DOC-LICENSE] +
W3C Document License. URL: https://www.w3.org/copyright/document-license-2023/ +
[PATENT-POLICY] +
The W3C Patent Policy. URL: https://www.w3.org/policies/patent-policy/ +
[PATENT-POLICY-2004] +
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/ +
[PATENT-POLICY-2020] +
The W3C 2020 Patent Policy. URL: https://www.w3.org/policies/patent-policy/20200915/ +
[PUBRULES] +
Publication Rules. URL: https://www.w3.org/pubrules/ +
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
[RFC3797] +
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://www.rfc-editor.org/rfc/rfc3797 +
[W3C-PATENT-POLICY] +
Wendy Seltzer. W3C Patent Policy. 15 September 2020. URL: https://www.w3.org/policies/patent-policy/ +
+

Informative References

+
+
[AB-HP] +
The Advisory Board home page. URL: https://www.w3.org/2002/ab/ +
[AC-MEETING] +
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/events/ac/ +
[BG-CG] +
Community and Business Group Process. URL: https://www.w3.org/community/about/process/ +
[BYLAWS] +
Amended and Restated Bylaws of World Wide Web Consortium, Inc.. URL: https://www.w3.org/2024/09/25-w3c-bylaws.pdf +
[CALENDAR] +
Calendar of all scheduled official W3C events. URL: https://www.w3.org/events/ +
[CHAIR] +
W3C Working/Interest Group Chair. URL: https://www.w3.org/guide/chair/role +
[CHARTER] +
How to Create a Working Group or Interest Group. URL: https://www.w3.org/guide/process/charter +
[COUNCIL-REPORT-INDEX] +
Council Report Index. URL: https://www.w3.org/about/council/ +
[CURRENT-AC] +
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList +
[DECISION-APPEAL] +
Appealing a W3C Decision. URL: https://www.w3.org/guide/process/ac-appeal +
[ELECTION-HOWTO] +
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/guide/process/election +
[FELLOWS] +
W3C Fellows Program. URL: https://www.w3.org/careers/fellows/ +
[GROUP-MAIL] +
Group mailing lists. URL: https://www.w3.org/groups/ +
[GUIDE] +
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/guide/ +
[INTRO] +
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro +
[JOIN] +
How to Join W3C. URL: https://www.w3.org/membership/join/ +
[LIAISON] +
W3C liaisons with other organizations. URL: https://www.w3.org/liaisons/ +
[MEMBER-AGREEMENT] +
W3C Membership Agreement. URL: https://www.w3.org/membership/agreement/ +
[MEMBER-HP] +
Member website (Member-only access). URL: https://www.w3.org/Member/ +
[MEMBER-LIST] +
The list of current W3C Members. URL: https://www.w3.org/membership/list/ +
[MEMBER-SUB] +
Member submissions guidebook. URL: https://www.w3.org/submissions/guide/ +
[MISSION] +
The W3C Mission statement. URL: https://www.w3.org/mission/ +
[OBS-RESC] +
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/guide/process/obsolete-rescinded-supserseded +
[REC-TIPS] +
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/guide/standards-track/rec-tips +
[REPUBLISHING] +
In-place modification of W3C Technical Reports. URL: https://www.w3.org/guide/standards-track/republishing +
[SUBMISSION-LIST] +
The list of acknowledged Member Submissions. URL: https://www.w3.org/submissions/ +
[TAG-HP] +
The TAG home page. URL: https://www.w3.org/2001/tag/ +
[TEAM-CONTACT] +
Role of the Team Contact. URL: https://www.w3.org/guide/teamcontact/role +
[TR] +
The W3C technical reports index. URL: https://www.w3.org/TR/ +
[TRANSITION] +
Organize a Technical Report Transition. URL: https://www.w3.org/guide/transitions/ +
[TRANSLATION] +
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/ +
[W3C-IPR] +
W3C IPR Policies. URL: https://www.w3.org/policies/ +
+ + + \ No newline at end of file diff --git a/snapshots/2025-07-31.html b/snapshots/2025-07-31.html new file mode 100644 index 00000000..6ed1011a --- /dev/null +++ b/snapshots/2025-07-31.html @@ -0,0 +1,6504 @@ + + + + + W3C Process Document + + + + + + + + + + + + + + + + + + +
+

+

W3C Process Document

+

Draft Community Group Report,

+
+ More details about this document +
+
+
This version: +
https://www.w3.org/policies/process/drafts/snapshots/2025-07-31 +
Editor’s Draft: +
https://www.w3.org/policies/process/drafts/ +
Latest published version: +
https://www.w3.org/policies/process/ +
Previous Versions: +
+
Feedback: +
Github (preferred) +
Public mailing list +
Member-only mailing list +
Editors: +
Elika J. Etemad / fantasai (Apple) +
Florian Rivoal (Invited Expert) +
Former Editors: +
Natasha Rooney (Invited Expert) +
Charles McCathie Nevile (Yandex) +
Ian Jacobs (W3C) +
+
+
+
+

Copyright © 2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

+
+
+
+

Abstract

+

The mission of the World Wide Web Consortium (W3C) is making the web work, for everyone. +W3C brings together global stakeholders to develop open standards that enable a World Wide Web that connects and empowers humanity. +The W3C Process Document describes the organizational structure of W3C and processes, +responsibilities and functions that enable W3C to accomplish its mission. +This document does not describe the internal workings of the Team.

+

For more information about the W3C mission and the history of W3C, +please refer to About W3C.

+
+

Status of this document

+
+

W3C, including all existing chartered groups, + follows the most recent operative Process Document announced to the Membership.

+

This document is developed by the Advisory Board’s Process Task Force + working within the W3C Process Community Group (which anyone can join). + This is the 31 July 2025 Draft Community Group Report for the proposed next version of the W3C Process Document.

+

This document, +having completed Advisory Committee Review, +is proposed to be the next version of the W3C Process +after the 3 November 2023 Process. +How it is adopted is detailed in Section 11 Process Changes.

+

A history of substantial changes from previous versions of the Process Document is provided.

+
+
+ +
+

Relation of Process Document to Patent Policy and Other Policies

+

W3C Members' attention is called to the fact + that provisions of the Process Document are binding on Members + per their Membership Agreement [MEMBER-AGREEMENT]. + The W3C Patent Policy [PATENT-POLICY] and other policies + incorporated by normative reference as a part of the Process Document + are equally binding.

+

The Patent Policy and Code of Conduct place additional obligations on Members, Team, and other participants in W3C. + The Process Document does not restate those requirements but includes references to them. + The Process Document, Patent Policy, and Code of Conduct have been designed to allow each to evolve independently.

+

In the Process Document, the term “participant” refers to an individual, not an organization.

+

Conformance and specialized terms

+

The terms must, must not, should, should not, required, + and may are used in accordance with RFC 2119. + The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

+

Some terms have been capitalized in this document (and in other W3C materials) + to indicate that they are entities with special relevance to the W3C Process. + These terms are defined within this document, + and readers are reminded that the ordinary English definitions are insufficient + for the purpose of understanding this document.

+ +
+

1. Introduction

+

W3C work revolves around the standardization of Web technologies. + To accomplish this work, W3C follows processes that promote the development of high-quality standards + based on the consensus of the Membership, Team, and public. + W3C processes promote fairness, responsiveness, and progress: + all facets of the W3C mission. + This document describes the processes W3C follows in pursuit of its mission.

+

The W3C Process promotes the goals of quality and fairness in technical decisions + by encouraging consensus, + soliciting reviews (by both Members and public), + incorporating implementation and interoperability experience, + and requiring Membership-wide approval as part of the technical report development process. Participants in W3C include representatives of its Members and the Team, + as well as Invited Experts who can bring additional expertise or represent additional stakeholders. Team representatives both contribute to the technical work + and help ensure each group’s proper integration with the rest of W3C.

+

W3C’s technical standards, called W3C Recommendations, + are developed by its Working Groups; + W3C also has other types of publications, + all described in § 6 W3C Technical Reports. + W3C has various types of groups; + this document describes the formation and policies + of its chartered Working Groups and Interest Groups, + see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. + W3C also operates Community and Business Groups, + which are separately described in their own process document [BG-CG].

+

In addition, several groups are formally established by the Consortium: + the W3C Advisory Committee, which has a representative from each Member, + and two oversight groups elected by its membership: + the Advisory Board (AB), + which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process; + and the Technical Architecture Group (TAG), + which helps resolve Consortium-wide technical issues.

+

Here is a general overview of how W3C initiates standardization of a Web technology:

+
    +
  1. People generate interest in a particular topic. + For instance, Members express interest by developing proposals in Community Groups + or proposing ideas in Member Submissions. + Also, the Team monitors work inside and outside of W3C for signs of interest, + and helps organize Workshops to bring people together + to discuss topics that interest the W3C community. +
  2. When there is enough interest and an engaged community, + the Team works with the Membership + to draft proposed Interest Group or Working Group charters. + W3C Members review the proposed charters, + and when there is support within W3C for investing resources in the topic of interest, + W3C approves the group(s), + and they begin their work. +
+

Further sections of this Process Document deal with topics including + liaisons (§ 8 Liaisons), + confidentiality (§ 7 Dissemination Policies), + and formal decisions and appeals (§ 5 Decisions).

+

2. Members and the Team

+

W3C’s mission is to lead the Web to its full potential. + W3C Member organizations provide resources to this end, + and the W3C Team provides the technical leadership + and organization to coordinate the effort.

+

2.1. Members

+

W3C Members are + organizations subscribed according to a Membership Agreement [MEMBER-AGREEMENT]. + They are represented in W3C processes as follows:

+
    +
  1. One representative per Member organization participates + in the Advisory Committee which oversees the work of W3C. +
  2. Representatives of Member organizations participate + in Working Groups and Interest Groups, + where they author and review technical reports. +
+

W3C membership is open to all entities, + as described in “How to Join W3C” [JOIN]; + (refer to the public list of current W3C Members [MEMBER-LIST]). + The Team must ensure + that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

+

While W3C does not have a class of membership tailored to individuals, + individuals may join W3C. + Restrictions pertaining to related Members apply + when the individual also represents another W3C Member.

+

2.1.1. Rights of Members

+

Each Member organization enjoys the following rights and benefits:

+ +

Furthermore, subject to further restrictions included in their Member Agreement, + representatives of Member organizations participate in W3C as follows:

+ +

The rights and benefits of W3C membership [MEMBER-AGREEMENT] are contingent upon conformance to the processes described in this document. + Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.

+

Additional information for Members is available at the Member website [MEMBER-HP].

+

2.1.2. Member Associations and Related Members

+
2.1.2.1. Membership Associations
+

A “Member Association” means a consortium, + user society, + or association of two or more individuals, + companies, + organizations or governments, + or any combination of these entities + which has the purpose of participating in a common activity + or pooling resources to achieve a common goal other than participation in, + or achieving certain goals in, + W3C. + A joint-stock corporation or similar entity is not a Member Association merely because it has shareholders or stockholders. + If it is not clear whether a prospective Member qualifies as a Member Association, + the CEO may reasonably make the determination. + For a Member Association, the rights and privileges of W3C Membership + described in the W3C Process Document extend to the Member Association’s paid staff + and Advisory Committee representative.

+

Member Associations may also designate + up to four (or more at the Team’s discretion) individuals + who, though not employed by the organization, may exercise the rights of Member representatives.

+

For Member Associations that have individual people as members, + these individuals must disclose their employment affiliation + when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For Member Associations that have organizations as Members, + all such designated representatives must be an official representative of the Member organization + (e.g. a Committee or Task Force Chairperson) + and must disclose their employment affiliation when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For all representatives of a Member Association, + IPR commitments are made on behalf of the Member Association, + unless a further IPR commitment is made by the individuals' employers.

+
2.1.2.2. Related Members
+

In the interest of ensuring the integrity of the consensus process, + Member involvement in some of the processes in this document is affected by related Member status. + As used herein, two Members are related if:

+
    +
  1. Either Member is a subsidiary of the other, or +
  2. Both Members are subsidiaries of a common entity, or +
  3. The Members have an employment contract or consulting contract that affects W3C participation. +
+

A subsidiary is an organization of which effective control and/or majority ownership rests with another, + single organization.

+

Related Members must disclose these relationships + according to the mechanisms described in the New Member Orientation [INTRO].

+

2.1.3. Good Standing

+

Members who have not lost Good Standing as defined in the Amended and Restated Bylaws of World Wide Web Consortium, Inc. are considered, for the purposes of this Process, + to be in Good Standing. + A group of related Members is in Good Standing if + at least one of them is in Good Standing.

+

2.2. The W3C Team

+

The Team consists of CEO, + W3C paid staff, + unpaid interns, + and W3C Fellows. W3C Fellows are Member employees working as part of the Team; + see the W3C Fellows Program [FELLOWS]. + The Team provides technical leadership about Web technologies, + organizes and manages W3C activities to reach goals + within practical constraints (such as resources available), + and communicates with the Members and the public + about the Web and W3C technologies.

+

The CEO may delegate responsibility + (generally to other individuals in the Team) + for any of their roles described in this document. Team Decisions derive from the CEO’s authority, + even when they are carried out by other members of the Team.

+

Oversight over the Team, + budgeting, + and other business decisions, + is provided by the W3C Board of Directors, + rather than managed directly by the Process.

+

Note: See the W3C Bylaws for more details + on the Board and overall governance of W3C.

+

3. Groups and Participation

+

For the purposes of this Process, a W3C Group is one of W3C’s Working Groups, Interest Groups, Advisory Committee, Advisory Board, + or TAG, + and a participant is a member of such a group.

+

3.1. Policies for Participation in W3C Groups

+

3.1.1. Individual Participation Criteria

+
3.1.1.1. Expectations and Discipline
+

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

+
    +
  1. Technical competence in one’s role; +
  2. The ability to act fairly; +
  3. Social competence in one’s role. +
+

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities + are responsible for assessing and attesting to the qualities of those nominees.

+

Participants in any W3C activity must abide + by the terms and spirit of the W3C Code of Conduct [COC] and the participation requirements described in + “Disclosure” + in the W3C Patent Policy [PATENT-POLICY].

+

The CEO may take disciplinary action, + including suspending or removing for cause + a participant in any group (including the AB and TAG) + if serious and/or repeated violations occur, + such as failure to meet the requirements on individual behavior of + (a) this process + and in particular the Code of Conduct, + (b) their membership agreement, or + (c) applicable laws. + Refer to the Guidelines to suspend or remove participants from groups.

+
3.1.1.2. Conflict of Interest Policy
+

Individuals participating materially in W3C work must disclose significant relationships + when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. + These disclosures must be kept up-to-date + as the individual’s affiliations change and W3C membership evolves + (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). + Each section in this document that describes a W3C group + provides more detail about the disclosure mechanisms for that group.

+

The ability of an individual to fulfill a role within a group + without risking a conflict of interest depends on the individual’s affiliations. + When these affiliations change, + the individual’s assignment to the role must be evaluated. + The role may be reassigned according to the appropriate process. + For instance, + the Team may appoint a new group Chair when the current Chair changes affiliations + (e.g., if there is a risk of conflict of interest, + or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

+

The following are some scenarios where disclosure is appropriate:

+
    +
  • Paid consulting for an organization whose activity is relevant to W3C, + or any consulting compensated with equity + (shares of stock, stock options, or other forms of corporate equity). +
  • A decision-making role/responsibility + (such as participating on a Board) + in other organizations relevant to W3C. +
  • A position on a publicly visible advisory body, + even if no decision-making authority is involved. +
+

Individuals seeking assistance on these matters should contact the Team.

+

Team members are subject to the Conflict of Interest Policy for the W3C Team [CONFLICT-POLICY].

+
3.1.1.3. Individuals Representing a Member Organization
+

Generally, individuals representing a Member in an official capacity within W3C + are employees of the Member organization. + However, an Advisory Committee representative may designate a non-employee + to represent the Member. + Non-employee Member representatives must disclose + relevant affiliations to the Team and to any group in which the individual participates.

+

In exceptional circumstances + (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), + the CEO may decline + to allow an individual designated by an Advisory Committee representative to participate in a group.

+

A group charter may limit + the number of individuals representing a W3C Member + (or group of related Members).

+

3.1.2. Meetings

+

The requirements in this section apply to the official meetings of any W3C group, + as well as to official W3C meetings with open-ended participation from the Membership and/or the public, + such as Workshops.

+

W3C distinguishes two types of meetings:

+
    +
  1. A face-to-face meeting is one + where most of the attendees are expected to participate in the same physical location. +
  2. A distributed meeting is one + where most of the attendees are expected to participate from remote locations + (e.g., by telephone, video conferencing, or IRC). +
+

A Chair may invite an individual with a particular expertise + to attend a meeting on an exceptional basis. + This person is a meeting guest, + not a group participant. + Meeting guests do not have voting rights. + It is the responsibility of the Chair to ensure + that all meeting guests respect the chartered level of confidentiality and other group requirements.

+
3.1.2.1. Meeting Scheduling and Announcements
+

Meeting announcements should be sent to all appropriate group mailing lists, + i.e. those most relevant to the anticipated meeting participants.

+

The following table lists recommendations for organizing a meeting:

+ + + + + + + + + +
+ Face-to-face meetings + Distributed meetings +
Meeting announcement (before) + eight weeks* + one week* +
Agenda available (before) + two weeks + 24 hours (or longer if a meeting is scheduled after a weekend or holiday) +
Participation confirmed (before) + three days + 24 hours +
Action items available (after) + three days + 24 hours +
Minutes available (after) + two weeks + 48 hours +
+

* To allow proper planning (e.g., travel arrangements), + the Chair is responsible for giving sufficient advance notice + about the date and location of a meeting. + Shorter notice for a meeting is allowed + provided that there are no objections from group participants. + In the case of Workshops, + shorter notice is not allowed.

+
3.1.2.2. Meeting Minutes
+

Groups should take and retain minutes of their meetings, + and must record + any official group decisions made during the meeting discussions. + Details of the discussion leading to such decisions are not required, + provided that the rationale for the group decision is nonetheless clear.

+
3.1.2.3. Meeting Recordings and Transcripts
+

No-one may take an audio or video recording of a meeting, + or retain an automated transcript, + unless the intent is announced at the start of the meeting, + and no-one participating in the recorded portion of the meeting withholds consent. + If consent is withheld by anyone, recording/retention must not occur. + The announcement must cover: + (a) who will have access to the recording or transcript and + (b) the purpose/use of it and + (c) how it will be retained (e.g. privately, in a cloud service) and for how long.

+

3.1.3. Tooling and Archiving for Discussions and Publications

+

For W3C Groups operating under this Process, + a core operating principle is to allow access across disabilities, + across country borders, + and across time. + Thus in order to allow all would-be participants to effectively participate, + to allow future participants and observers to understand the rationale and origins of current decisions, + and to guarantee long-lived access to its publications, + W3C requires that:

+
    +
  • All reports, publications, or other deliverables + produced by the group for public consumption + (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, + and backed up by W3C systems + such that if the underlying service is discontinued, + W3C can continue to serve such content without breaking incoming links + or other key functionality. +
  • All reports, publications, or other deliverables + produced by the group for public consumption should follow best practices for internationalization + and for accessibility to people with disabilities. + Network access to W3C-controlled domains may be assumed. +
  • + Official meeting minutes and other records of decisions made must be archived by W3C for future reference; + and other persistent text-based discussions + sponsored by the group, + pertaining to their work + and intended to be referenceable by all group members should be. + This includes discussions conducted over email lists + or in issue-tracking services + or any equivalent fora. + Materials referenced from discussions + and necessary to understand them + should be available at a stable URL, + at a level of confidentiality no stricter than the discussion minutes. +

    Note: The lack, or loss, of such archives does not by itself + invalidate an otherwise-valid decision.

    +
  • + Any tooling used by the group + for producing its documentation and deliverables + or for official group discussions should be usable + (without additional cost) + by all who wish to participate, + including people with disabilities, + to allow their effective participation. +

    Note: If a new participant joins who cannot use the tool, + this can require the Working Group to change its tooling + or operate some workaround.

    +
  • All tools and archives used by the group + for its discussions and recordkeeping should be documented + such that new participants and observers + can easily find the group’s tools and records. +
+

The Team is responsible for ensuring adherence to these rules + and for bringing any group not in compliance into compliance.

+

3.1.4. Resignation from a Group

+

A W3C Member or Invited Expert may resign from a group. + On written notification from an Advisory Committee representative + or Invited Expert + to the Team, + the Member and their representatives + or the Invited Expert + will be deemed to have resigned from the relevant group. + The Team must record the notification. + See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

+

3.2. The Advisory Committee (AC)

+

3.2.1. Role of the Advisory Committee

+

The Advisory Committee represents + the Members of W3C at large. + It is responsible for:

+ +

Advisory Committee representatives may initiate + an Advisory Committee Appeal of a W3C decision or Team’s decision.

+

See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

+

3.2.2. Participation in the Advisory Committee

+

The Advisory Committee is composed of one representative from each Member organization + (refer to the Member-only list + of current Advisory Committee representatives. [CURRENT-AC])

+

When an organization joins W3C + (see “How to Join W3C” [JOIN]), + it must name its Advisory Committee representative as part of their Membership Agreement. + The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, + provides information about Advisory Committee Meetings, + explains how to name a new Advisory Committee representative, + and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.

+

The AC representative may delegate any of their rights and responsibilities + to an alternate (except the ability to designate an alternate).

+

3.2.3. Advisory Committee Mailing Lists

+

The Team must provide two mailing lists for use by the Advisory Committee:

+
    +
  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. + This list is read-only for Advisory Committee representatives. +
  2. One for discussion among Advisory Committee representatives. + Though this list is primarily for Advisory Committee representatives, + the Team must monitor discussion + and should participate in discussion when appropriate. + Ongoing detailed discussions should be moved to other appropriate lists + (new or existing, such as a mailing list created for a Workshop). +
+

An Advisory Committee representative may request + that additional individuals from their organization be subscribed to these lists. + Failure to contain distribution internally may result in suspension of additional email addresses, + at the discretion of the Team.

+

3.2.4. Advisory Committee Meetings

+

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. + The Team appoints the Chair of these meetings (generally the CEO). + At each Advisory Committee meeting, + the Team should provide an update to the Advisory Committee about:

+
+
Resources +
+
    +
  • The number of W3C Members at each level. +
  • An overview of the financial status of W3C. +
+
Allocations +
+
    +
  • The allocation of the annual budget, including size of the Team and their approximate deployment. +
  • A list of all activities (including but not limited to Working and Interest Groups) + and brief status statement about each, + in particular those started or terminated since the previous Advisory Committee meeting. +
  • The allocation of resources to pursuing liaisons with other organizations. +
+
+

Each Member organization should send one representative to each Advisory Committee Meeting. + In exceptional circumstances + (e.g., during a period of transition between representatives from an organization), + the meeting Chair may allow a Member organization to send two representatives to a meeting.

+

The Team must announce the date and location of each Advisory Committee meeting + no later than at the end of the previous meeting; one year’s notice is preferred. + The Team must announce the region of each Advisory Committee meeting + at least one year in advance.

+

More information about Advisory Committee meetings [AC-MEETING] is available at the Member website.

+

3.3. Elected Groups: The AB and the TAG

+

The W3C Process defines two types of elected groups: + the Advisory Board (AB) and + the Technical Architecture Group (TAG), + both elected by the Advisory Committee.

+

3.3.1. Advisory Board (AB)

+
3.3.1.1. Role of the Advisory Board
+

The Advisory Board provides ongoing guidance to the Team + on issues of strategy, + management, + legal matters, + process, + and conflict resolution. + The Advisory Board also serves the Members + by tracking issues raised between Advisory Committee meetings, + soliciting Member comments on such issues, + and proposing actions to resolve these issues. + The Advisory Board manages the evolution of the Process Document. + As part of a W3C Council, + members of the Advisory Board hear and adjudicate on Submission Appeals and Formal Objections.

+

The Advisory Board is distinct from the Board of Directors and has no decision-making authority within W3C; + its role is strictly advisory.

+

Note: While the AB as such does not have decision-making authority, + its members do when sitting as part of a W3C Council.

+

Details about the Advisory Board + (e.g., the list of Advisory Board participants, + mailing list information, and summaries of Advisory Board meetings) + are available at the Advisory Board home page [AB-HP].

+
3.3.1.2. Composition of the Advisory Board
+

The Advisory Board consists of nine to eleven elected participants and one Chair + (who may be one of the elected participants). + With the input of the AB, + the Team appoints the Chair, + who should choose a co-chair among the elected participants. + Upon appointment, + the Chair(s) are subject to ratification by secret ballot, + requiring approval by two thirds of the elected participants. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The team also appoints a Staff Contact, + as described in § 3.4.1 Requirements for All Chartered Groups. + The CEO and Staff Contact have a standing invitation + to all regular Advisory Board sessions.

+

The nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

+

The terms of elected Advisory Board participants are for two years. + Terms are staggered so that each year, + either five or six terms expire. + If an individual is elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular Advisory Board terms begin on 1 July and end on 30 June.

+
3.3.1.3. Communications of the Advisory Board
+

The Team must make available a mailing list, + confidential to the Advisory Board and Team, + for the Advisory Board to use for its communication.

+

The Advisory Board should send a summary of each of its meetings + to the Advisory Committee and other group Chairs. + The Advisory Board should also report on its activities + at each Advisory Committee meeting.

+
3.3.1.4. Liaisons between the Advisory Board and the Board of Directors
+

To ensure good communication between the AB and the Board of Directors and facilitate operational and management consistency, + the AB may appoint up to two of its participants as liaisons to the Board. + Such appointees are expected to attend and participate in Board meetings + and access Board materials + as Non-voting Observers. [BYLAWS] They do not form part of the Board’s decision-making body, + and may be excluded from such participation + in accordance with applicable Board procedures.

+

The Advisory Board should reevaluate + who is assigned to this role + at least at the beginning of each term, + and may swap its appointees more frequently + as they deem appropriate.

+

3.3.2. Technical Architecture Group (TAG)

+
3.3.2.1. Role of the Technical Architecture Group
+

The mission of the TAG is stewardship of the Web architecture. + There are three aspects to this mission:

+
    +
  1. to document and build consensus around principles of Web architecture + and to interpret and clarify these principles when necessary; +
  2. to resolve issues involving general Web architecture brought to the TAG; +
  3. to help coordinate cross-technology architecture developments inside and outside W3C. +
+

As part of a W3C Council, + the members of the TAG hear and adjudicate on Submission Appeals and Formal Objections.

+

The TAG’s scope is limited to technical issues about Web architecture. + The TAG should not consider + administrative, + process, + or organizational policy issues of W3C, + which are generally addressed by + the W3C Advisory Committee, + Advisory Board, + and Team.

+

When the TAG votes to resolve an issue, + each TAG participant + (whether appointed, elected, or the Chair) + has one vote; + see also the general section on votes in this Process Document.

+

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) + are available at the TAG home page [TAG-HP].

+
3.3.2.2. Composition of the Technical Architecture Group
+

The TAG consists of:

+ +

Participants in the TAG choose by consensus their Chair or co-Chairs; + in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG. + The Chair or co-Chairs must be selected from the participants of the TAG. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The Team also appoints a Staff Contact [TEAM-CONTACT] for the TAG, + as described in § 3.4.1 Requirements for All Chartered Groups.

+

The terms of TAG participants last for two years. + Terms are staggered so that four elected terms + and either one or two appointed terms expire each year. + If an individual is appointed or elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular TAG terms begin on 1 February and end on 31 January.

+
3.3.2.3. Communications of the Technical Architecture Group
+

The Team must make available two mailing lists for the TAG:

+
    +
  • a public discussion (not just input) list for issues of Web architecture. + The TAG will conduct its public business on this list. +
  • a Member-only list for discussions within the TAG + and for requests to the TAG that, + for whatever reason, cannot be made on the public list. +
+

The TAG may also request the creation of additional topic-specific, public mailing lists. + For some TAG discussions (e.g., a Submission Appeal), + the TAG may use a list that will be Member-only.

+

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. + The TAG should also report on its activities at each Advisory Committee meeting.

+

3.3.3. Participation in Elected Groups

+
3.3.3.1. Expectations for Elected Groups Participants
+

Advisory Board and TAG participants have a special role within W3C: + they are elected by the Membership and appointed by the Team with the expectation that they will use their best judgment + to find the best solutions for the Web, + not just for any particular network, + technology, + vendor, + or user. + Advisory Board and TAG participants are expected to participate regularly and fully. + Advisory Board and TAG participants should attend Advisory Committee meetings.

+

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, + to serve the needs of the W3C membership as a whole, + and the Web community. + Whether they are Member representatives or Invited Experts, + their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

+

An individual participates on the Advisory Board or TAG + from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). + Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, + their participation does carry the responsibilities associated with Member representation, + Invited Expert status, + or Team representation + (as described in the section on the AB/TAG nomination and election process).

+

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, + and a participant’s seat must not be delegated to any other person.

+
3.3.3.2. Elected Groups Participation Constraints
+

Given the few seats available on the Advisory Board and the TAG, + and in order to ensure that the diversity of W3C Members is represented:

+ +
3.3.3.3. Advisory Board and Technical Architecture Group Elections
+

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, + using a Single Transferable Vote system. + An election begins when the Team sends a Call for Nominations to the Advisory Committee. + Any Call for Nominations specifies the minimum and maximum number of available seats, + the deadline for nominations, + details about the specific vote tabulation system selected by the Team for the election, + and operational information such as how to nominate a candidate. + The Team may modify the tabulation system after the Call for Nominations + but must stabilize it no later than the Call for Votes. + The Team announces appointments + after the results of the election are known, + and before the start of the term, + as described in § 3.3.3.4 Technical Architecture Group Appointments.

+

In the case of regularly scheduled elections of the TAG, + the minimum and maximum number of available seats are the same: + the 4 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

+

In the case of regularly scheduled elections of the AB, + the minimum and maximum number of available seats differ: + The maximum number is the 5 or 6 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; + the minimum number is such that when added to the occupied seats from the prior year, + the minimum size of the AB (9) is reached.

+

Each Member (or group of related Members) may nominate one individual. + A nomination must be made with the consent of the nominee. + In order for an individual to be nominated as a Member representative, + the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination + the (same) information required for a Member representative in a Working Group. + In order for an individual to be nominated as an Invited Expert, + the individual must provide + the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. + In order for an individual to be nominated as a Team representative, + the nominating Advisory Committee representative must first secure approval from Team management. + A nominee is not required to be an employee of a Member organization, + and may be a W3C Fellow. + The nomination form must ask for the nominee’s primary affiliation, + and this will be reported on the ballot. + For most nominees, + the primary affiliation is their employer and will match their affiliation in the W3C database. + For contractors and invited experts, + this will normally be their contracting company + or their invited expert status; + in some cases + (e.g. where a consultant is consulting for only one organization) + this may be the organization for whom the nominee is consulting. + A change of affiliation is defined + such that this field would carry a different answer + if the nominee were to be re-nominated + (therefore, + terminating employment, + or accepting new employment, + are changes of affiliation). + (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) + Each nomination should include + a few informative paragraphs about the nominee. + If an identified candidate’s nomination information is only partially complete + as of the deadline for nominations, + the Team may allow extra time for that candidate’s nomination to be completed, + so long as it does not delay the election as a whole.

+

If, after the deadline for nominations, the number of nominees is:

+
    +
  • Greater than or equal to the minimum number of available seats + and less than or equal to the maximum number of available seats, + those nominees are thereby elected. + This situation constitutes a tie for the purpose of assigning incomplete terms. + Furthermore, if the number is less than the maximum number of available seats, + the longest terms are filled first. +
  • Less than the minimum number of available seats, + Calls for Nominations are issued until a sufficient number of people have been nominated. + Those already nominated do not need to be renominated after a renewed call. +
  • Greater than the maximum number of available seats, + the Team issues a Call for Votes + that includes the names of all candidates, + the (maximum) number of available seats, + the deadline for votes, + details about the vote tabulation system selected by the Team for the election, + and operational information. +
+

When there is a vote, + each Member in Good Standing (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. + Once the deadline for votes has passed, + the Team announces the results to the Advisory Committee. + In case of a tie the verifiable random selection procedure described below + will be used to fill the available seats.

+

The shortest incomplete term is assigned to the elected candidate ranked lowest by the tabulation of votes, + the next shortest term to the next-lowest ranked elected candidate, + and so on. + In the case of a tie among those eligible for a incomplete term, + the verifiable random selection procedure described below + will be used to assign the incomplete term.

+

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

+
3.3.3.4. Technical Architecture Group Appointments
+

The Team is responsible for appointing + 3 of the participants to the Technical Architecture Group. + This mechanism complements the election process. + The Team should use its appointments to support + a diverse and well-balanced TAG, + including diversity of technical background, knowledge, and skill sets.

+

The Team should actively seek + candidates for appointment to the TAG, + and must make available to + the W3C community at large + a means to propose candidates for consideration, + explicitly soliciting input from at least + current and incoming TAG members, the Advisory Committee, and Working Group Chairs.

+

The constraints for appointment to the TAG are + the same as for elected participants + (see § 3.3.3.2 Elected Groups Participation Constraints and § 3.3.3.3 Advisory Board and Technical Architecture Group Elections), + with the additional constraint that + a person must not be appointed + for more than two consecutive terms. + (Partial terms used to fill a vacated seat do not count towards this limit.)

+

Note: Since there are no limits on elected terms, + this limit on appointed terms does not constrain + term-limited appointees + from running for election at any time.

+

The Team’s choice of appointee(s) + is subject to ratification by secret ballot + by both the AB and the TAG, + requiring a two-thirds approval from each. + In the case of regularly scheduled elections, + the TAG participants in this ratification are + its members for the upcoming term.

+

For regularly scheduled elections, + selection begins once the results of the elections are known, + and the Team should announce the ratified appointment(s) + no later than the start of the regularly scheduled term. + When an appointed seat is vacated outside of a regularly scheduled election, + the Team should seek to appoint a replacement + unless a regular Call for Nominations is scheduled within 2 months, + and it must announce the ratified appointment + no later than the Call for Nominations of the next scheduled election.

+
3.3.3.5. Verifiable Random Selection Procedure
+

When it is necessary to use a verifiable random selection process + (e.g., in an AB or TAG election, + to “draw straws” in case of a tie + or to fill a incomplete term), + W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. + The procedure orders an input list of names + (listed in alphabetical order by family name unless otherwise specified) + into a “result order”.

+

W3C applies this procedure as follows:

+
    +
  1. When N people have tied for M (less than N) seats. + In this case, only the names of the N individuals who tied + are provided as input to the procedure. + The M seats are assigned in result order. +
  2. After all elected individuals have been identified, + when N people are eligible for M (less than N) incomplete terms. + In this case, only the names of those N individuals are provided as input to the procedure. + The incomplete terms are assigned in result order. +
+
3.3.3.6. Elected Groups Vacated Seats
+

An Advisory Board or TAG participant’s seat is vacated when:

+ +

If a participant changes affiliation, + but the participation constraints are met, + that participant’s seat becomes vacant at the next regularly scheduled election for that group.

+

Vacated seats are filled according to this schedule:

+
    +
  • When an appointed TAG seat is vacated, + the Team appoints a replacement. +
  • + When an elected seat on either the AB or TAG is vacated, + the seat is filled at the next regularly scheduled election for the group + unless the group Chair requests that W3C hold an election before then + (for instance, due to the group’s workload). +
      +
    • The group Chair should not request such an election + if the next regularly scheduled election is fewer than three months away. +
    • The group Chair may request an election, + and the election may begin, as soon as a current member gives notice of a resignation, + including a resignation effective as of a given date in the future. +
    +

    When such an election is held, + the minimum number of available seats is such that + when added to the number of continuing participants, + the minimum total number of elected seats is met + (8 for the TAG, 9 for the AB); + and the maximum number corresponds to all unoccupied seats. + Except for the number of available seats and the length of the terms, + the usual rules for Advisory Board and Technical Architecture Group Elections apply.

    +
+

3.4. Chartered Groups: Working Groups and Interest Groups

+

This document defines two types of chartered groups:

+
+
Working Groups. +
+ Working Groups typically produce deliverables + (e.g., Recommendation Track technical reports, + software, + test suites, + and reviews of the deliverables of other groups) + as defined in their charter. +

Working Groups have additional participation requirements + described in the W3C Patent Policy [PATENT-POLICY], + see particularly the “Licensing Obligations of Working Group Participants” + and the patent claim exclusion process + in “Exclusion From W3C RF Licensing Requirements”.

+
Interest Groups. +
+ The primary goal of an Interest Group + is to bring together people who wish to evaluate potential Web technologies and policies. + An Interest Group is a forum for the exchange of ideas. +

Interest Groups do not publish Recommendation Track technical reports; + but can publish technical reports on the Note Track.

+
+

3.4.1. Requirements for All Chartered Groups

+

Each group must have a charter. + Requirements for the charter depend on the group type. + All group charters must be public + (even if other proceedings of the group are Member-only).

+

Each group must have a Chair (or co-Chairs) + to facilitate effective discussion and coordinate the group’s activities. + The Team appoints (and re-appoints) Chairs for all groups. + The Chair is a Member representative, + a Team representative, + or an Invited Expert (invited by the Team). + The requirements of this document that apply to those types of participants apply to Chairs as well.

+

Note: The role of the Chair [CHAIR] is described + in the Art of Consensus [GUIDE].

+

Each group must have a Staff Contact (also known as Team Contact), + who acts as the interface between the Chair, + group participants, + and the rest of the Team.

+

Note: The role of the Staff Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE].

+

The Chair and the Staff Contact of a group should not be the same individual.

+

Each group must have an archived mailing list + for formal group communication + (e.g., for meeting announcements and minutes, + documentation of decisions, + and Formal Objections to decisions). + It is the responsibility of the Chair and Staff Contact to ensure that new participants are subscribed to all relevant mailing lists. + Refer to the list of group mailing lists [GROUP-MAIL].

+

A Chair may form task forces + (composed of group participants) + to carry out assignments for the group. + The scope of these assignments must not exceed the scope of the group’s charter. + A group should document the process it uses + to create task forces + (e.g., each task force might have an informal "charter"). + Task forces do not publish technical reports; + the Working Group may choose to publish their results as part of a technical report.

+

3.4.2. Participation in Chartered Groups

+

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, + and Team representatives (including the Staff Contact).

+

There are four types of individual participants in an Interest Group: + the same three types as for Working Groups plus, + for an Interest Group where the only participation requirement is mailing list subscription, public participants.

+

Except where noted in this document or in a group charter, + all participants share the same rights and responsibilities in a group; + see also the individual participation criteria.

+

A participant may represent more than one organization + in a Working Group or Interest Group. + Those organizations must all be members of the group.

+

An individual may become + a Working or Interest Group participant + at any time during the group’s existence. + See also relevant requirements in + “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY].

+

On an exceptional basis, + a Working or Interest Group participant may designate + a substitute to attend a meeting and should inform the Chair. + The substitute may act on behalf of the participant, + including for votes. + For the substitute to vote, + the participant must inform the Chair in writing in advance.

+

To allow rapid progress, + Working Groups are intended to be small + (typically fewer than 15 people) + and composed of experts in the area defined by the charter. + In principle, + Interest Groups have no limit on the number of participants. + When a Working Group grows too large to be effective, + W3C may split it into an Interest Group + (a discussion forum) + and a much smaller Working Group + (a core group of highly dedicated participants).

+

3.4.3. Types of Participants in Chartered Groups

+
3.4.3.1. Member Representative in a Working Group
+

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Advisory Committee representative of the Member in question + has designated the individual as a Working Group participant, and +
  • the individual qualifies for Member representation. +
+

To designate an individual as a Member representative in a Working Group, + an Advisory Committee representative must provide the Chair and Staff Contact with all of the following information, + in addition to any other information required by the Call for Participation and charter + (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

+
    +
  1. The name of the W3C Member the individual represents + and whether the individual is an employee of that Member organization; +
  2. A statement that the individual accepts the participation terms + set forth in the charter + (with an indication of charter date or version); +
  3. A statement that the Member will provide the necessary financial support for participation + (e.g., for travel, telephone calls, and conferences). +
+

A Member participates in a Working Group from the moment the first Member representative joins the group + until either of the following occurs:

+
    +
  • the group closes, or +
  • the Member resigns from the Working Group; + this is done through the Member’s Advisory Committee representative. +
+
3.4.3.2. Member Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

+ +

To designate an individual as a Member representative in an Interest Group, + the Advisory Committee representative must follow the instructions + in the Call for Participation and charter.

+

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

+
3.4.3.3. Invited Expert in a Working Group
+

The Chair may invite an individual with a particular expertise + to participate in a Working Group. + This individual may represent an organization in the group + (e.g., if acting as a liaison with another organization).

+

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Chair has designated the individual as a group participant, +
  • the Staff Contact has agreed with the Chair’s choice, and +
  • the individual has provided the information required of an Invited Expert to the Chair and Staff Contact. +
+

To designate an individual as an Invited Expert in a Working Group, + the Chair must inform the Staff Contact + and provide rationale for the choice. + When the Chair and the Staff Contact disagree about a designation, + the CEO determines + whether the individual will be invited to participate in the Working Group.

+

To participate in a Working Group as an Invited Expert, + an individual must:

+
    +
  • identify the organization, if any, the individual represents as a participant in this group, +
  • agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT], +
  • accept the participation terms set forth in the charter, + including the participation requirements of + the W3C Patent Policy [PATENT-POLICY], + especially in “Note on Licensing Commitments for Invited Experts” + and in “Disclosure”, + indicating a specific charter date or version, +
  • disclose whether the individual is an employee of a W3C Member; + see the conflict of interest policy, +
  • provide a statement of who will provide the necessary financial support + for the individual’s participation + (e.g., for travel, telephone calls, and conferences), and +
  • if the individual’s employer (including a self-employed individual) + or the organization the individual represents + is not a W3C Member, + indicate whether that organization intends to join W3C. + If the organization does not intend to join W3C, + indicate reasons the individual is aware of for this choice. +
+

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. + The Chair must not use Invited Expert status + to circumvent participation limits imposed by the charter.

+

An Invited Expert participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • the Chair or CEO withdraws the invitation to participate, or +
  • the individual resigns. +
+
3.4.3.4. Invited Expert in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

+
3.4.3.5. Team Representative in a Working Group
+

An individual is a Team representative in a Working Group when so designated by W3C management. + Team representatives both contribute to the technical work + and help ensure the group’s proper integration with the rest of W3C.

+

A Team representative participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • W3C management changes Team representation by sending email to the Chair, + copying the group mailing list. +
+

The Team participates in a Working Group + from the moment the creation of the group is announced + until the group closes.

+
3.4.3.6. Team Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Team representative in an Interest Group when so designated by W3C management.

+

4. Lifecycle of Chartered Groups

+

W3C creates charters for chartered groups based on W3C community interest. + W3C fosters awareness of charters, + improves their quality, + and gauges Membership support in two formal phases:

+ +

4.1. Initiating Charter Refinement

+

Charters can originate in many venues, + including existing Working or Interest Groups, + Community Groups, + and from the Membership. + Prior to the formal refinement phase, + the Team engages with those various parties + to help prepare charters for broader audiences.

+

Formal charter refinement (see below) is initiated + by the Team sending a charter review notice to the Advisory Committee, + to the public, + and, in the case of rechartering, to the affected Group.

+

This charter review notice must include:

+
    +
  • +

    A short summary of the proposal.

    +
  • +

    The location of the charter draft, which must be public.

    +
  • +

    How to participate in the discussion of this charter draft and where to file issues.

    +
  • +

    The expected duration of the charter refinement phase, +which must not be less than 28 days, +and should not be more than 6 months.

    +
  • +

    Who the Chartering Facilitator is.

    +
+

The Team is responsible for initiating charter refinement at its discretion, in consideration of discussions with the community.

+

An Advisory Committee representative may formally request + that the Team initiate charter refinement. + The Team may deny such a request + if it thinks the proposal is insufficiently mature, + does not align with W3C’s scope and mission, + or otherwise does not meet the charter assessment criteria + described in the Guide (see How to Create a Working Group or Interest Group), + and must reply with its rationale. + This rejection is a Team Decision, + and can be appealed only by 5 or more Members, + through their Advisory Committee representative, + formally objecting to the decision within 8 weeks of the decision being announced. + In this case the Team must start an appeal vote on whether to overturn the Team Decision. + (No action is required to be taken when fewer than 5 members object.)

+

4.2. Charter Refinement

+

During charter refinement, + the W3C community, + under the guidance of the Team, + further develops the charter draft with the goal of achieving consensus on the proposal. + The Chartering Facilitator—​who is chosen (and may be replaced) by the Team—​is responsible for seeking community consensus among those participating in the refinement process + and making decisions reflecting that consensus. + In cases where consensus cannot be found, + the Chartering Facilitator may ask the Team to make a Team Decision, + and must document the rationale for the decision.

+

Note: The Chartering Facilitator is not necessarily the Chair of the group being chartered.

+

During charter refinement:

+ +

Before the end of the announced duration + for the charter refinement phase, + the Team (informed by the work of the Chartering Facilitator) must decide which of the following to do:

+
    +
  • +

    Complete charter refinement by initiating AC Review of the charter draft.

    +
  • +

    Abandon the proposal.

    +
  • +

    Extend the charter refinement period.

    +
+

The Team must announce its decision with the same visibility as the initial charter review notice, + and must include a rationale + if they are not initiating AC Review. + Reaching the end of the announced period (including any announced extension) + with no announced decision + is considered a de-facto Team decision to abandon the proposal. + The Team may revise such a decision + by announcing an alternative decision.

+

Formal Objections filed during the charter refinement phase + are specially handled:

+
    +
  • +

    Objections to decisions pertaining to the content of the charter, +as well as objections to initiating the AC Review, +are considered registered at the close of the Advisory Committee Review of the charter, +and are registered against that W3C Decision.

    +

    Note: This enables all Formal Objections on the same proposed charter to be handled together.

    +
  • +

    Objections to abandoning the proposal or to extending the refinement period can be appealed only if 5 or more Members, +through their Advisory Committee representative, +formally object to the decision within 8 weeks of the decision. +In this case, +the Team must do one of the following:

    +
      +
    • +

      Abide by the objectors' request, if they all agree on the +alternative course of action (e.g., to abandon, +extend, or complete charter refinement).

      +
    • +

      Initiate an AC Review to formally solicit the input of +the community and take a W3C Decision on the subsequent +course of action.

      +
    • +

      Convene a Council to decide the subsequent course of action.

      +
    +

    (No action is required to be taken when fewer than 5 members object.)

    +
  • +

    Any other objections are processed normally (See § 5.6 Addressing Formal Objections).

    +
+

4.3. Content of a Charter

+

A Working Group or Interest Group charter must include all of the following information.

+
    +
  • The group’s mission + (e.g., develop a technology or process, review the work of other groups). +
  • The scope of the group’s work and criteria for success. +
  • The duration of the proposed charter for the group. +
  • The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software). +
  • + Expected milestone dates where available. +

    Note: A charter does not need to include + schedules for review of other group’s deliverables.

    +
  • The process for the group to approve the release of deliverables + (including intermediate results). +
  • Any dependencies by groups within or outside of W3C on the deliverables of this group. + For any dependencies, the charter must specify + the mechanisms for communication about the deliverables. +
  • Any dependencies of this group on other groups within or outside of W3C. + Such dependencies include interactions with W3C Horizontal Groups [CHARTER]. +
  • The level of confidentiality of the group’s proceedings and deliverables. +
  • The name and affiliation of the Chair or co-Chairs. +
  • Meeting mechanisms and expected frequency. +
  • If known, + the date of the first face-to-face meeting. + The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal. +
  • Communication mechanisms to be employed within the group, + between the group and the rest of W3C, + and with the general public. +
  • Any voting procedures or requirements + other than those specified in § 5.2.3 Deciding by Vote. +
  • An estimate of the expected time commitment from participants. +
  • The expected time commitment and level of involvement by the Team + (e.g., to track developments, + write and edit technical reports, + develop code, + or organize pilot experiments). +
  • Intellectual property information. + What are the intellectual property (including patents and copyright) + considerations affecting the success of the Group? + In particular, is there any reason to believe + that it will be difficult to meet the Royalty-Free licensing goals + in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY]? +
+

See also the charter requirements in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

For every Recommendation Track deliverable + that continues work on a technical report published under any other Charter (including a predecessor group of the same name), + for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

+
    +
  • The title, + stable URL, + and publication date of the Working Draft or other Recommendation-track document + that will serve as the basis for work on the deliverable + (labeled “Adopted Draft”); +
  • The title, + stable URL, + and publication date of the document + that was used as the basis for its most recent Exclusion Opportunity + as per + the W3C Patent Policy [PATENT-POLICY]. + (labeled “Exclusion Draft”); and +
  • The stable URL of the Working Group charter + under which the Exclusion Draft was published + (labeled the “Exclusion Draft Charter”). +
+

All of the above data must be identified + in the adopting Working Group’s charter using the labels indicated.

+

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. + The proposed charter must state + the dates on which the Exclusion Opportunity + that arose on publishing the Exclusion Draft began and ended. + As per “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY], + this potentially means that exclusions can only be made immediately on joining a Working Group.

+

An Interest Group charter may include provisions regarding participation, + including specifying + that the only requirement for participation (by anyone) in + the Interest Group is subscription to the Interest Group mailing list. + This type of Interest Group may have public participants.

+

A charter may include + provisions other than those required by this document. + The charter should highlight + whether additional provisions impose constraints + beyond those of the W3C Process Document + (e.g., limits on the number of individuals in a Working Group + who represent the same Member organization or group of related Members).

+

4.4. Charter Review and Approval

+

4.4.1. New Charters and Major Changes

+

Any new charter (including re-chartering of existing chartered groups) + and any change that is not a minor change (per § 4.4.2 Minor Changes to Active Charters) to an already-approved charter of a Working Group or Interest Group must be approved by a W3C Decision following an AC Review of that charter. + Modifications to a charter should have the consensus of the group.

+

The review period must be at least 28 days. + Any Advisory Committee representative may request an extended review period + in response to the Call for Review; + upon receipt of any such request, + the Team must extend the review period + to at least 60 days.

+

The Call for Review of a modified charter must highlight important changes + (e.g., regarding changes in scope, deliverables, or resource allocation) + and must include rationale for those changes.

+

The Call for Review of a new or modified charter must include a disposition of comments received during the charter refinement process, + highlighting any issues that were closed despite sustained objections.

+

4.4.2. Minor Changes to Active Charters

+

Editorial changes or substantive changes to a charter (including extensions) + that do not affect the scope of the group’s work + or the way the group functions in any significant way + are deemed minor changes and may be approved by a Team Decision, + in which case they do not require charter refinement nor Advisory Committee Review. + Any change to the scope of the charter or addition of a new REC track deliverable + that does not fall within the scope of an existing deliverable + is a major, not minor, change. + The following are examples of minor changes: + the renaming or restructuring (e.g. splitting or combining) of existing in-scope deliverables, + the addition of new Note track deliverables that help explain the group’s work, + a change of Staff Contact, + or a change of Chair. Minor changes, other than a change of Staff Contact, should have the consensus of the group.

+

The Team may nevertheless choose + to initiate charter refinement and/or Advisory Committee Review when it thinks the changes would benefit from more scrutiny or explicit buy-in.

+

Though Advisory Committee Review is not required, + such changes must still be announced + to the Advisory Committee, + and to participants in the Working or Interest Group, + and a rationale must be provided.

+

4.5. Call for Participation in a Chartered Group

+

Deciding whether to adopt a proposed Working Group or Interest Group charter is a W3C Decision. + Charters may be amended based on review comments + per § 5.7.2 Determining the W3C Decision before the Call for Participation.

+

If the decision is to charter the group, + the Team must issue a Call for Participation to the Advisory Committee. + For a new group, this announcement officially creates the group. + The announcement must include a reference to the charter, + the name(s) of the group’s Chair(s), + and the name(s) of the Staff Contact(s).

+

After a Call for Participation, + any Member representatives and Invited Experts must be designated (or re-designated). + When a group is re-chartered, + individuals participating in the Working Group or Interest Group before the new Call for Participation + may attend any meetings held within forty-five (45) days of the Call for Participation + even if they have not yet formally rejoined the group + (i.e., committed to the terms of the charter and patent policy).

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against the decision to create + or substantially modify + a Working Group or Interest Group charter.

+

4.6. Charter Extension

+

The Team may decide + to extend a Working Group or Interest Group charter + with no other substantive modifications. + The Team must announce + such extensions to the Advisory Committee. + The announcement must indicate the new duration. + The announcement must also include rationale for the extension, + a reference to the charter, + and the Group homepage + (which includes at least + the name(s) of the group’s Chair(s), + the name of the Staff Contact, + and instructions for joining the group).

+

After a charter extension, + Advisory Committee representatives + and the Chair are not required to re-designate Member representatives and Invited Experts.

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.

+

4.7. Chartered Group Closure

+

A Working Group or Interest Group charter specifies a duration for the group.

+

The Team, the TAG, or the AB may propose to close a group + prior to the date specified in the charter in any of the following circumstances:

+
    +
  • +

    There are insufficient member resources to produce chartered deliverables +or to maintain the group, +according to priorities established within W3C.

    +
  • +

    A Patent Advisory Group concluded that the work should be terminated.

    +
  • +

    The TAG or AB determined that continuing operation of the chartered group or its work +would be detrimental to W3C or its mission.

    +
  • +

    The group produced all chartered deliverables ahead of schedule.

    +
+

Such a proposal to close a group must be accompanied by rationale, + and the proposal must be confirmed by an AC Review as a W3C Decision.

+

Closing a Working Group has implications + with respect to the W3C Patent Policy [PATENT-POLICY].

+

5. Decisions

+

W3C attempts to resolve issues through dialog. + Individuals who disagree strongly with a decision should register with the Chair any Formal Objections.

+

5.1. Types of Decisions

+

The Chair of a Working Group or Interest Group has the prerogative + to make certain decisions based on their own judgment. + Such decisions are called chair decisions.

+

In contrast, + decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group + or following a vote (see § 5.2.3 Deciding by Vote) + are called group decisions (also known as group “resolutions”).

+

Decisions made by members of the Team in connection with this Process, + based on their own individual or collective judgement, + are called Team Decisions.

+

In contrast, + a W3C decision is + determined by the Team on behalf of the W3C community + by assessing the consensus of the W3C Community after an Advisory Committee review.

+

5.2. Consensus Building

+

5.2.1. Consensus

+

Consensus is a core value of W3C. + To promote consensus, + the W3C process requires Chairs to ensure + that groups consider all legitimate views and objections, + and endeavor to resolve them, + whether these views and objections are expressed by the active participants of the group + or by others + (e.g., another W3C group, + a group in another organization, + or the general public). + Decisions may be made during meetings + (face-to-face or distributed) + as well as through persistent text-based discussions.

+

The following terms are used in this document + to describe the level of support for a decision among a set of eligible individuals:

+
+
Consensus: +
A substantial number of individuals in the set + support the decision + and there is no sustained objection from anybody in the set. + Individuals in the set may abstain. + Abstention is either an explicit expression of no opinion + or silence by an individual in the set. +
Unanimity: +
The particular case of consensus where all individuals in the set support the decision + (i.e., no individual in the set abstains). +
Dissent: +
At least one individual in the set sustains an objection. +
+

Note: A Formal Objection always indicates a sustained objection, + but isn’t necessary to express it + (except in the context of formal AC Reviews). + Disagreement with a proposed decision, + however, does not always rise to the level of sustained objection, + as individuals could be willing to accept a decision + while expressing disagreement.

+

By default, the set of individuals eligible to participate in a decision is the set of group participants. + The Process Document does not require a quorum for decisions + (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). + A charter may include a quorum requirement for consensus decisions.

+

Where unanimity is not possible, + a group should strive to make consensus decisions + where there is significant support and few abstentions. + The Process Document does not require a particular percentage of eligible participants + to agree to a motion in order for a decision to be made. + To avoid decisions where there is widespread apathy, + (i.e., little support and many abstentions), + groups should set minimum thresholds of active support before a decision can be recorded. + The appropriate percentage may vary depending on the size of the group + and the nature of the decision. + A charter may include threshold requirements for consensus decisions. + For instance, a charter might require a supermajority of eligible participants + (i.e., some established percentage above 50%) + to support certain types of consensus decisions.

+
+ Note: Chairs have substantial flexibility + in how they obtain and assess consensus among their groups. + Unless otherwise constrained by charter, + they can use modes including but not limited to explicit calls for consensus, + polls of participants, + “lazy consensus” in which lack of objection after sufficient notice is taken as assent; + they can also delegate and empower a document editor + to assess consensus on their behalf, + whether in general + or for specific pre-determined circumstances + (e.g. in non-controversial situations, for specific types of issues, etc.). +

If questions or disagreements arise, + the final determination of consensus remains with the chair.

+
+

5.2.2. Managing Dissent

+

In some cases, even after careful consideration of all points of view, + a group might find itself unable to reach consensus. + The Chair may record a decision where there is dissent so that the group can make progress + (for example, to produce a deliverable in a timely manner). + Dissenters cannot stop a group’s work + simply by saying that they cannot live with a decision. + When the Chair believes that the Group has duly considered + the legitimate concerns of dissenters as far as is possible and reasonable, + the group should move on.

+

Groups should favor proposals that create the weakest objections. + This is preferred over proposals that are supported by a large majority + but that cause strong objections from a few people. + As part of making a decision where there is dissent, + the Chair is expected to be aware of which participants work for the same + (or related) + Member organizations and weigh their input accordingly.

+

Note: Dissenters can escalate their sustained objection to a decision by registering a Formal Objection.

+

5.2.3. Deciding by Vote

+

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, + and that a vote is necessary to break a deadlock. + In this case the Chair must record + (e.g., in the minutes of the meeting or in an archived email message):

+
    +
  • an explanation of the issue being voted on; +
  • the decision to conduct a vote + (e.g., a simple majority vote) to resolve the issue; +
  • the outcome of the vote; +
  • any Formal Objections. +
+

In order to vote to resolve a substantive issue, + an individual must be a group participant. + Each organization represented in the group must have at most one vote, + even when the organization is represented by several participants in the group + (including Invited Experts). + For the purposes of voting:

+
    +
  • A Member or group of related Members is considered a single organization. +
  • The Team is considered an organization. +
+

Unless the charter states otherwise, Invited Experts may vote.

+

If a participant is unable to attend a vote, + that individual may authorize anyone at the meeting + to act as a proxy. + The absent participant must inform the Chair in writing + who is acting as proxy, with written instructions on the use of the proxy. + For a Working Group or Interest Group, + see the related requirements regarding an individual + who attends a meeting as a substitute for a participant.

+

A group may vote for other purposes than to resolve a substantive issue. + For instance, the Chair often conducts a “straw poll” vote + as a means of determining whether there is consensus about a potential decision.

+

A group may also vote to make a process decision. + For example, + it is appropriate to decide by simple majority + whether to hold a meeting in San Francisco or San Jose + (there’s not much difference geographically). + When simple majority votes are used to decide minor issues, + voters are not required to state the reasons for votes, + and the group is not required to record individual votes.

+

A group charter may include formal voting procedures + (e.g., quorum or threshold requirements) + for making decisions about substantive issues.

+

5.3. Formally Addressing an Issue

+

In the context of this document, + a group has formally addressed an issue when it has sent a public, substantive response + to the reviewer who raised the issue. + A substantive response is expected to include rationale for decisions + (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). + The adequacy of a response is measured + against what a W3C reviewer would generally consider to be technically sound. + If a group believes that a reviewer’s comments result from a misunderstanding, + the group should seek clarification before reaching a decision.

+

As a courtesy, + both Chairs and reviewers should set expectations + for the schedule of responses and acknowledgments. + The group should reply to a reviewer’s initial comments + in a timely manner. + The group should set a time limit + for acknowledgment by a reviewer of the group’s substantive response; + a reviewer cannot block a group’s progress. + It is common for a reviewer to require a week or more + to acknowledge and comment on a substantive response. + The group’s responsibility to respond to reviewers + does not end once a reasonable amount of time has elapsed. + However, reviewers should realize + that their comments will carry less weight + if not sent to the group in a timely manner.

+

Substantive responses should be recorded. + The group should maintain an accurate summary + of all substantive issues and responses to them + (e.g., in the form of an issues list with links to mailing list archives).

+

5.4. Reopening a Decision When Presented With New Information

+

The Chair may reopen a decision + when presented with new information, including:

+
    +
  • additional technical information, +
  • comments by email from participants who were unable to attend a scheduled meeting, +
  • comments by email from meeting attendees + who chose not to speak out during a meeting + (e.g., so they could confer later with colleagues or for cultural reasons). +
+

The Chair should record + that a decision has been reopened, + and must do so upon request from a group participant.

+

5.5. Registering Formal Objections

+

Any individual + (regardless of whether they are associated with a Member) may appeal any decision made in connection with this Process + (except those having a different appeal process) + by registering a Formal Objection with the Team. + Group participants should inform + their Staff Contact as well as the group’s Chair(s). + The Staff Contact must inform the CEO when a group participant has also raised concerns about due process.

+

Note: In this document, the term Formal Objection is used to emphasize this process implication: + Formal Objections receive formal consideration and a formal response. + The word “objection” used alone has its ordinary English connotations. + See § 5.2 Consensus Building.

+

A Formal Objection must include a summary of + the issue (whether technical or procedural), + the decision being appealed, + and the rationale for the objection. + It should cite technical arguments + and propose changes that would remove the Formal Objection; + these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments + or rationale are unlikely to receive serious consideration. + Counter-arguments, + rationales, + and decisions should also be recorded.

+

No later than when the relevant Council is initiated, + a record of each Formal Objection against a decision regarding a publicly-available document must be made publicly available; + likewise, a record of each Formal Objection against a Member-visible decision must be made available to Members. + A Call for Review to the Advisory Committee must identify any Formal Objections related to that review. + These requirements are waived + if the Formal Objection is resolved to the satisfaction of the objector + before its confidentiality is changed.

+

Note: Formal Objections against matter in a technical report are expected to be fully addressed before requesting advancement of the technical report.

+

A Formal Objection filed during an Advisory Committee Review is considered registered at the close of the review period.

+

Registering a Formal Objection initiates the process of addressing the Formal Objection. + The resolution of a recorded Formal Objection—​whether by a Council decision, adoption of a consensus proposal, retraction of the Formal Objection, etc.—​must be recorded and made available at the same level of visibility as the record of the Formal Objection itself.

+

5.6. Addressing Formal Objections

+

5.6.1. Investigation and Mediation by the Team

+

The Team considers the Formal objection, + researches the question, + interviews parties, + and so on, + to make sure the problem and the various viewpoints are well understood, + and to the extent possible, + to arrive at a recommended disposition.

+

In parallel, the Team should start the steps necessary + to convene a Council.

+

If the Team can resolve the issue + to the satisfaction of the individual that filed the Formal Objection, + the individual withdraws the objection and the disposition process terminates.

+

Otherwise, + upon concluding that consensus cannot be found, + and no later than 90 days after the Formal Objection being registered, + the Team must deliver to the Council a report + documenting its findings and attempts to find consensus, + and hand over the matter to the W3C Council.

+

5.6.2. W3C Council

+

A W3C Council is the body convened to resolve Formal Objections by combining the capabilities and perspectives of the AB, the TAG, and the Team, + and is tasked with doing so in the best interests of the Web and W3C.

+
5.6.2.1. Council Composition
+

Each W3C Council is composed of the following members (excepting any renounced or dismissed):

+ +

Participation in a W3C Council must not require attendance of face-to-face meetings.

+

A distinct instance of the W3C Council is convened for each decision being appealed or objected to. + The list of potential Council members evolves + as AB and TAG terms start and end + until dismissal and renunciation are concluded, + at which point the membership of the Council is fixed. + However, if the number of active members in a Council falls so low as to hinder effective and balanced deliberations, + the Council Chair should dissolve the Council and call for a new one to be convened.

+

Note: TAG and AB elections have no effect on the Council’s membership + once it is fixed.

+

A Team member is assigned + to act as the Council Staff Contact, + to support this Council + and to facilitate adherence to this Process.

+
5.6.2.2. Extraordinary Delegation
+

In extraordinary cases, + if they feel a Council would not be the appropriate deciding body, + a member of the Team (particularly the Legal Counsel) or + any potential Council member + may suggest that the decision for that specific Formal Objection be delegated + to the W3C Board of Directors, + to an officer of its corporation (such as the Legal Counsel), + or to one or more specific individuals from the Team. + The potential Council members then may confidentially discuss + and must vote + whether to delegate the decision for that specific Formal Objection. + A decision to delegate must be supported by a two-thirds supermajority vote + (i.e., at least twice as many votes in favor as against). + Delegation in such cases cannot be later revoked.

+

The Team must inform the Advisory Committee when a Formal Objection has been delegated, + and to whom it has been delegated.

+
5.6.2.3. Council Participation, Dismissal, and Renunciation
+

A potential Council member may be dismissed from the Council. + In order to apply consistent criteria, + the potential Council members decide collectively + which reasons against service + rise to a sufficient level for a potential member to be dismissed. + No-one is automatically dismissed, + and individual recusal is not used in the Council. Dismissal applies to an individual person in the context of a specific Council, + and should be used rarely in order to preserve the greatest diversity on the Council.

+

Note: A W3C Council is a deliberative body whose purpose is + to find the best way forward for the Web and for W3C. + It is not a judicial body tasked with determining right or wrong.

+

The Team must draft a list of potential Council members, + with annotations of possible reasons for dismissal against each one. + The W3C community, + including members and team, and potential council members, must be given an opportunity to contribute possible reasons to this list. + Affected members must be given + an opportunity to respond to such comments about themselves. + The Team may report comments verbatim + or may paraphrase them while preserving their intent; + they may also elide inappropriate comments, + such as any that violate applicable laws or the [COC].

+

Before a Council forms, + the Team presents the entire list of potential members + and collected reasons and responses + to the potential Council members, + who then consider for each potential member + whether that individual’s participation + would compromise the integrity of the Council decision, + and vote whether to dismiss that potential member. + No one is allowed to vote on their own dismissal; + each dismissal is enacted if there are at least as many ballots for as against.

+

Note: Since dismissal is individual, + when the decision being objected to was made by the TAG or AB acting as a body, + the entire TAG or AB is not expected to be dismissed.

+

An individual may also renounce their seat on a Council, for strong reason, + such as being forbidden by their employer to serve. The individual chooses the extent to which they explain + their renunciation. + Renunciation is disqualification from participation, + not abstention, + and should not be used + to excuse an absence of participation.

+

Any person who has been dismissed or who renounces their seat + does not receive Council materials, + take part in its deliberations, + help in the determination of consensus, + or vote. + The W3C Council may still solicit and hear their testimony, + as they can of anyone else in the W3C community.

+
5.6.2.4. Short Circuit
+

The full Council process may be short-circuited if + the Team recommends a resolution + and potential members of a Council who are not renouncing their seat + confirm it by a vote which results in both of the following:

+
    +
  • +

    at least 80% of them vote affirmatively to adopt this resolution

    +
  • +

    none of them vote against adopting the resolution

    +
+

The request for confirmation must be open for a period of at least two weeks, + or until every potential member of the Council not renouncing their seat + has voted, + whichever is shortest.

+

This step may be run concurrently with § 5.6.2.3 Council Participation, Dismissal, and Renunciation and prior to choosing a Chair.

+

Note: This is intended for exceptional cases + that don’t seem to warrant a full Council response + because they are, for instance, too trivial, duplicative, etc.

+
5.6.2.5. Council Chairing
+

The Chair of each W3C Council is chosen by its members, + by consensus if possible, + falling back to a vote if that fails. + The chair must be a member of that W3C Council. + Chair selection happens during formation of each Council, + and must be re-run + if requested by the Council Staff Contact or by the Chair during the Council’s operation.

+
5.6.2.6. Convening the Council
+

When dismissal, renunciation, and + appointment of the W3C Council Chair have concluded, + and the Team’s report has been delivered, + the W3C Council is considered to be convened and can start deliberations.

+

If a W3C Council has not yet been convened within 90 days of a Formal Objection + being registered, + the Chairs of the TAG and AB may take independent action to ensure + that the dismissal, renunciation, + and chair selection processes have been run. + If a report from the Team is not delivered within those 90 days, + the Council is considered convened upon selection of the Council Chair.

+
5.6.2.7. Council Deliberations
+

Once convened, + the Council may conduct additional research or analysis, + or request additional information or interviews from anyone, + including the Team.

+

The Council may further attempt to broker consensus on one or more of the formal objections, + which, if successful, would allow them to be resolved.

+

Otherwise, + after sufficient deliberation, + and with due consideration of each argument in the applicable Formal Objections, + the W3C Council decides whether to affirm or overturn the decision being objected to. + The W3C Council may affirm the decision + even if it agrees with some of the arguments made as part of a Formal Objection. + When a decision is affirmed, + all Formal Objections against it are said to be overruled. + Conversely, + aspects of Formal Objections that are found by the Council + to justify overturning a decision + are said to be upheld.

+

When overturning a decision, + the Council should recommend a way forward. + If the overturned decision has already had consequences + pertaining to upheld aspects of the Formal Objection(s) + (e.g., if the objection concerns material already in a published document) + the Council should suggest how these consequences might be mitigated. + The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion; + and the upheld aspects of the Formal Objection(s) (as identified in the Council Report) are not considered fully addressed until then.

+

Note: This does not create new powers for the Team, + such as the ability to “unpublish” documents. + The Team’s role is to ensure the responsible parties enact adequate mitigations, + by whatever means they already have at their disposal.

+

A Council may form sub-groups for deliberation, + who may return with a recommendation, + but the full Council issues the final decision. + The decision of the W3C Council should be unanimous, + and may be issued under consensus. + However, if despite careful deliberation + a W3C Council is unable to reach consensus, + the W3C Council Chair may instead resort to voting. + In that case, + the decision is adopted if there are more ballots for than against; + in case of a tie, + the W3C Council Chair determines the outcome. + However, + if the decision or proposal being objected to + originated with the TAG or AB, + then members of that group at the time the decision or proposal was made + must abstain in such a vote. + In case of a vote, + if two members of a Council who share the same affiliation cast an identical ballot, + then their ballots count as a one vote, + not two.

+

In the case of non-unanimous decisions, + members of a W3C Council who disagree with the Council’s decision may write a Minority Opinion explaining the reason for their disagreement.

+

The deliberations of a W3C Council are confidential to that W3C Council and its Council Staff Contact.

+

Note: This confidentiality requirement is put in place so that + the Council can receive sensitive information in confidence + and to enable Council members to speak freely in their individual expert capacity + without pressure or fear of retaliation + by those involved in the dispute, business relations, their employer, etc.

+

If a W3C Council is unable to come to a conclusion within 45 days of being convened, + the W3C Council Chair must inform the AC of this delay + and of the status of the discussions. + The W3C Council Chair may additionally make this report public.

+
5.6.2.8. Council Decision Report
+

A Council terminates by issuing a Council Report, + which:

+
    +
  • +

    must state whether the Council affirms or overturns the decision being objected to.

    +
  • +

    must provide a rationale supporting its conclusion, +which should address each argument raised in the Formal Objection(s).

    +
  • +

    must include any recommendation decided by the Council.

    +
  • +

    if the decision has been overturned, must identify which aspects of the Formal Objection(s) are being upheld, and should include any suggested mitigations.

    +
  • +

    must include the Minority Opinion(s), if any.

    +
  • +

    must report the names of those who were dismissed or renounced their seat as well as those who were qualified to serve.

    +
  • +

    must report the names of the individuals who participated in the final Council decision.

    +
  • +

    must report the number of votes for/against dismissing each participant.

    +
  • +

    may report vote totals for the Council’s decision, if a formal vote was held.

    +
  • +

    must not attribute any position to any individual on the Council.

    +
+

The Team must maintain a public page on the W3C website indexing all completed Council Reports. + If a Council decision is later overturned by an AC Appeal, + this must also be mentioned. Council Reports must be no more confidential + than the decision or document being objected to.

+

The Council may also issue a Supplemental Confidential Council Report with a more restricted level of confidentiality than its main report + when it believes that additional commentary on confidential aspects of the case + would be informative. + However, the main Council Report should be self-sufficient + and understandable without reference to Supplemental Confidential Council Reports.

+
5.6.2.9. Appealing Council Decisions
+

Advisory Committee representatives may initiate an Advisory Committee Appeal of a Council decision issued in a Council Report.

+

5.7. Advisory Committee Reviews and W3C Decisions

+

The Advisory Committee formally confers its approval + on charters, technical reports, + and other matters + through an Advisory Committee review and its resulting W3C Decision.

+

5.7.1. Initiating an Advisory Committee Review

+

Each Advisory Committee review period + begins with a Call for Review from the Team to the Advisory Committee. + The Call for Review describes the proposal, + raises attention to deadlines, + estimates when the decision will be available, + and includes other practical information. + The Team may share its perspective on the proposal + in the Call for Review. + Each Member organization may send one review, + which must be returned by its Advisory Committee representative.

+

For clarity, + in the context of an AC Review, dissent must be expressed as a Formal Objection.

+

The Team must provide two channels for Advisory Committee review comments:

+
    +
  1. an archived Team-only channel; +
  2. an archived Member-only channel. +
+

The Call for Review must specify + which channel is the default for review comments on that Call.

+

Reviewers may send information + to either or both channels. + A reviewer may also share their own reviews + with other Members on the Advisory Committee discussion list, + and may also make it available to the public.

+

A Member organization may modify its review + during a review period + (e.g., in light of comments from other Members).

+

5.7.2. Determining the W3C Decision

+

After the review period, + the Team determines the appropriate W3C Decision, + which they must announce to the Advisory Committee. + The announcement must indicate + the level of support for the proposal + (consensus or dissent), + and specifically + whether there were any Formal Objections, + with attention to changing the confidentiality level of the Formal Objections.

+

If there were Formal Objections, at least some of which were upheld, + or if there is not consensus because of insufficient support, W3C Decision must be one of:

+
    +
  • The proposal is returned for additional work, + with a request to the initiator to improve the proposal. +
  • The proposal is rejected. +
+

If the proposal has consensus, + or if all Formal Objections are retracted or overruled and the proposal otherwise has sufficient support to achieve consensus, + this W3C Decision must be one of:

+
    +
  • The proposal is adopted, + possibly with additional changes integrated + in order to address the comments of the AC (see below). +
  • The proposal is returned for additional work, + with a request to the initiator to make desirable changes identified during the review + and to resubmit. +
+

If the proposal is adopted with changes other than class 1 (markup) changes, + then those changes must be announced to the AC and to the Group that owns the document (if any). + Additionally, when adopting a proposal with substantive changes integrated, + the announcement must include rationale + for the substantive changes.

+

Substantive changes to the proposal may be adopted + only if the revised proposal has consensus of the subset of the AC that voted on the initial proposal + (including anyone who explicitly abstained), + or if all Formal Objections against the revised proposal are retracted or overruled and the revised proposal otherwise has sufficient support to achieve consensus. + For clarity, + the Team should seek a response from this subset of the AC using the same tooling and degree of formality as it did for the AC Review; + and as is the case during AC Reviews, dissent in this context must be expressed as a Formal Objection.

+

Any Formal Objection raised at this stage against the revised proposal + is handled by the same Council responsible for Formal Objections raised against the initial proposal, + if any.

+

Such a Council has the ability to affirm either the original or the revised proposal for advancement, + thereby overruling all Formal Objections against the original or revised proposal, + respectively.

+

For publications which have conditions in addition to AC approval + for introducing substantive changes (such as Group consensus or implementation experience + or going through a patent Exclusion Opportunity), + those other conditions must also be re-fulfilled.

+
For example, if substantive changes to a technical report are requested when assessing the transition from Candidate Recommendation to Recommendation, + the technical report would need to go through a new Update Request and be republished as a new Candidate Recommendation; + that new version would then need to satisfy the criteria for advancement. + Alternatively, the desired changes can be introduced as non-substantive amendments + using the process for revising a Recommendation. + However, with the exception of the removal of at-risk features, + they cannot be directly integrated between CRS and REC, + because that would fail to trigger a patent exclusion opportunity.
+

For charters, + substantive changes from the initial proposal that underwent AC Review must not include any increase to the scope. + If any such change is desired, + it must be returned for additional work + and go through a complete new AC Review.

+

This document does not specify + time intervals between the end of an Advisory Committee review period + and the W3C decision. + This is to ensure that the Members and Team have sufficient time to consider comments + gathered during the review. + The Advisory Committee should not expect an announcement + sooner than two weeks after the end of a review period. + If, after three weeks, the outcome has not been announced, + the Team should provide the Advisory Committee with an update.

+

5.8. Advisory Committee Votes

+

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, + and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. + Whenever the Advisory Committee votes, + each Member or group of related Members has one vote.

+

5.9. Appeal by Advisory Committee Representatives

+

Advisory Committee representatives may appeal certain decisions, + though appeals are only expected to occur in extraordinary circumstances. + For the purpose of this section, only Advisory Committee representatives of Members in Good Standing are counted.

+

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate + an Advisory Committee Appeal. + These W3C decisions include those related to group creation and modification, + and transitions to new maturity stages for Recommendation Track documents + and the Process document.

+

Advisory Committee representatives may also initiate an appeal + for decisions of a W3C Council, and + for certain decisions that do not involve an Advisory Committee review. + These cases are identified in the sections + which describe the requirements for the decision + and include + additional (non-reviewed) maturity stages of Recommendation Track documents, + group charter extensions and closures, + and technical agreements.

+

In all cases, + an appeal must be initiated within three weeks of the decision.

+

An Advisory Committee representative initiates an appeal by sending a request to the Team, + and should also share this request with the Advisory Committee. + The request should say “I appeal this Decision” + and identify the decision, + and may also include their rationale for appealing the decision.

+

Note: See Appealing a W3C Decision for a recommendation + on how to communicate an appeal request to the Team and the AC.

+

Within one week the Team must announce the appeal process + to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. + The archive of these statements must be member-only. + If, within one week of the Team’s announcement, + 5% or more of the Advisory Committee support the appeal request, + the Team must organize an appeal vote asking the Advisory Committee “Do you approve of the Decision?” + together with links to the decision and the appeal support.

+

The ballot must allow for three possible responses: + “Approve”, + “Reject”, + and “Abstain”, + together with Comments.

+

The level of support needed for an Advisory Committee Appeal to pass + depends on the level of ballot participation + (including explicit “abstain” ballots) + by Advisory Committee Representatives:

+
    +
  • +

    if fewer than 5% participate, +the vote fails.

    +
  • +

    if at least 5% but no more than 15% participate, +and the number of “Approve” ballots exceeds three times (3x) the number of “Reject” ballots, +the vote passes.

    +
  • +

    if more than 15% but fewer than 20% participate, +and the number of “Approve” ballots exceeds twice (2x) the number of “Reject” ballots, +the vote passes.

    +
  • +

    if 20% or more participate, +and the number of “Approve” ballots exceeds the number of “Reject” ballots, +the vote passes.

    +
+

If the vote passes, + the decision is overturned. + Following such rejection, + those who had initiated the proposal may revise it + to address the causes of rejection + and follow the ordinary applicable process + to submit the revised proposal.

+

6. W3C Technical Reports

+

The W3C technical report development process is the set of steps and requirements + followed by W3C Working Groups to standardize Web technology. + The W3C technical report development process is designed to:

+
    +
  • support multiple specification development methodologies +
  • maximize consensus about the content of stable technical reports +
  • ensure high technical and editorial quality +
  • promote consistency among specifications +
  • facilitate royalty-free, interoperable implementations of Web Standards, and +
  • earn endorsement by W3C and the broader community. +
+

See also “licensing goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

6.1. Types of Technical Reports

+

This chapter describes the formal requirements + for publishing and maintaining a W3C Recommendation, Note, + or Registry.

+
+
Recommendations +
Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines + as standards for the Web. + The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, + and consensus-building, + and is subject to the W3C Patent Policy [PATENT-POLICY], + under which participants commit to Royalty-Free IPR licenses for implementations. + See § 6.3 The W3C Recommendation Track for details. +
Notes +
Groups can also publish documents as Group Notes and W3C Statements, + typically either to document information + other than technical specifications, + such as use cases motivating a specification + and best practices for its use. + See § 6.4 The Note Track (Notes and Statements) for details. +
Registries +
Chartered and elected groups can also publish registries in order to document collections of values or other data. + A registry can be published either as a distinct registry report, + or directly within a Recommendation Track document + as an embedded registry. Defining a registry requires wide review and consensus, + but once set up, changes to registry entries are lightweight + and can even be done without the initiating group’s involvement. + See § 6.5 The Registry Track for details. +
+

Individual Working Groups and Interest Groups should adopt additional processes + for developing publications, + so long as they do not conflict with the requirements in this chapter.

+

6.2. General Requirements for Technical Reports

+

6.2.1. Publication of Technical Reports

+

Publishing as used in this document + refers to producing a version which is listed as a W3C Technical Report on its Technical Reports index at https://www.w3.org/TR [TR]. + Every document published as part of the technical report development process must be a public document. + W3C strives to make archival documents indefinitely available + at their original address in their original form.

+

Every document published as part of the technical report development process must clearly indicate its maturity stage, + and must include information about the status of the document. + This status information:

+
    +
  • must be unique each time a specification is published, +
  • must state which Working Group developed the specification, +
  • must state how to send comments or file bugs, + and where these are recorded, +
  • must include expectations about next steps, +
  • should explain how the technology relates to existing international standards + and related work inside or outside W3C, + and +
  • should explain + or link to + an explanation of significant changes from the previous version. +
+

Every Technical Report published + as part of the Technical Report development process + is edited by one or more editors + appointed by a Group Chair. + It is the responsibility of these editors to ensure that the decisions of the Group are + correctly reflected in subsequent drafts of the technical report. + An editor must be a participant, + per § 3.4.2 Participation in Chartered Groups in the Group responsible for the document(s) they are editing.

+

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, + status information, + style, + and copyright requirements). + These rules are subject to change by the Team from time to time. + The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

+

The primary language for W3C Technical Reports is English. + W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C website.

+

6.2.2. Reviews and Review Responsibilities

+

A document is available for review + from the moment it is first published. + Working Groups should formally address any substantive review comment + about a technical report in a timely manner.

+

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, + particularly if this would cause significant compatibility problems + due to existing implementation. Working Groups should record substantive + or interesting proposals raised by reviews + but not incorporated into a current specification.

+
6.2.2.1. Wide Review
+

The requirements for wide review are not precisely defined by the W3C Process. + The objective is to ensure that the entire set of stakeholders of the Web community, + including the general public, + have had adequate notice of the progress of the Working Group and were able to actually perform reviews of and provide comments on the specification. + A second objective is to encourage groups to request reviews + early enough that comments and suggested changes + can still be reasonably incorporated in response to the review. + Before approving transitions, + the Team will consider who has been explicitly offered + a reasonable opportunity to review the document, + who has provided comments, + the record of requests to and responses from reviewers, + especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter + or identified as liaisons [LIAISON], + and seek evidence of clear communication to the general public + about appropriate times and which content to review + and whether such reviews actually occurred.

+

Note: The Team documents best practices for wide review in the Guidebook. [GUIDE]

+

For example, + inviting review of new or significantly revised sections published in Working Drafts, + and tracking those comments + and the Working Group’s responses, + is generally a good practice which would often be considered positive evidence of wide review. Working Groups should follow the W3C Horizontal Groups’ review processes, + and should announce to other W3C Working Groups + as well as the general public, + especially those affected by this specification, + a proposal to enter Candidate Recommendation (for example in approximately 28 days). + By contrast a generic statement in a document + requesting review at any time + is likely not to be considered as sufficient evidence + that the group has solicited wide review.

+

A Working Group could present evidence that wide review has been received, + irrespective of solicitation. + But it is important to note that receiving many detailed reviews + is not necessarily the same as wide review, + since they might only represent comment + from a small segment of the relevant stakeholder community.

+

6.2.3. Classes of Changes

+

This document distinguishes the following 5 classes of changes to a document. + The first two classes of change are considered editorial changes, + the next two substantive changes, + and the last one registry changes.

+
+
+ +
    +
  1. +

    No changes to text content

    +
+
These changes include fixing broken links, style sheets, or invalid markup. +
+ +
    +
  1. +

    Changes that do not functionally affect interpretation of the document

    +
+
For Recommendation-track technical reports specifically, + this constitutes changes that do not affect conformance, + i.e. changes that reasonable implementers + would not interpret as changing architectural + or interoperability requirements + or their implementation. + Changes which resolve ambiguities in the specification + are considered to change (by clarification) the implementation requirements + and do not fall into this class. +
Examples of changes in this class include + correcting non-normative examples + which clearly conflict with normative requirements, + clarifying various other non-normative text, + fixing typos or grammatical errors + where the change does not change requirements. +
If there is any doubt or disagreement + as to whether a change functionally affects interpretation, + that change does not fall into this class. +
+ +
    +
  1. +

    Other changes that do not add new features

    +
+
+ For Recommendation-track documents, + these changes may affect conformance to the specification. + A change that affects conformance is one that: +
    +
  • makes conforming data, processors, or other conforming agents become non-conforming according to the new version, + or +
  • makes non-conforming data, processors, or other agents become conforming, + or +
  • clears up an ambiguity or under-specified part of the specification + in such a way that data, + a processor, + or an agent + whose conformance was once unclear + becomes clearly either conforming or non-conforming. +
+
+ +
    +
  1. +

    New features

    +
+
Changes that add new functionality, + such as new elements, new APIs, new rules, etc. +
+ +
    +
  1. +

    Changes to the contents of a registry table

    +
+
Changes that add, remove, or alter registry entries in a registry table. +
+

6.2.4. Errata Management

+

Tracking errors is an important part of a Working Group’s ongoing care of a technical report; + for this reason, + the scope of a Working Group charter generally allows time + for work after publication of a Recommendation. + In this Process Document, + the term “erratum” + (plural “errata”) refers to any error + that can be resolved by one or more changes in classes 1-3 + of section § 6.2.3 Classes of Changes.

+

Working Groups must keep + a public record of errors + that are reported by readers and implementers + for Recommendations. + Such error reports should be compiled + no less frequently than quarterly.

+

Working Groups decide how to document errata. + Such documentation must identify + the affected technical report text + and describe the error; + it may also describe some possible solution(s). + Readers of the technical report should be able easily + to find and see the errata + that apply to that specific technical report with their associated tests. + Errata may be documented + in a separate errata page or tracking system. + They may, + in addition or alternatively, + be annotated inline + alongside the affected technical report text + or at the start or end of the most relevant section(s).

+

6.2.5. Candidate Amendments

+

An erratum may be accompanied by a non-normative, candidate correction approved by group decision. + When annotated inline, + errata—​including their candidate corrections—​must be marked as such, + are treated as class 2 changes, + and are published accordingly.

+

Note: Annotating changes in this way allows more mature documents + such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, + even when the candidate amendments have not yet received + sufficient review or implementation experience + to be normatively incorporated into the specification proper.

+

A candidate addition is similar to a candidate correction, + except that it proposes a new feature + rather than an error correction.

+

Candidate corrections and candidate additions are collectively known as candidate amendments.

+

In addition to their actual maturity stage, published REC Track documents with candidate amendments are also considered, + for the purpose of the W3C Patent Policy [PATENT-POLICY], + to be Working Drafts with those candidate amendments treated as normative.

+

6.2.6. Maintenance Without a Group

+

For all types of technical reports and all maturity stages, + if there is no group chartered to maintain a technical report, + the Team may republish it + at the same maturity stage, + integrating as needed:

+
    +
  1. class 1 changes; +
  2. inline errata; +
  3. candidate corrections, + which must be marked as Team correction; +
  4. class 2 changes other than inline errata and Team corrections. +
+

To avoid any potential doubt or disagreement + about whether changes really do fall into class 2, + the Team should be conservative, + limiting itself to obvious and limited fixes, + and must avoid substantial rephrasing, + even of non-normative examples and notes. + If any such change is desired, + the Team must mark it as a Team correction.

+

Team corrections do not constitute + a normative portion of the Recommendation, + as defined in the Patent Policy [PATENT-POLICY] (i.e., they are not covered by the Patent Policy). + For Candidate Recommendations, W3C Recommendations, Candidate Registries, W3C Registries, + as well as W3C Statements, + the Team must solicit wide review on Team corrections that it produces.

+

6.2.7. License Grants from Non-Participants

+

When a party who is not already obligated under the Patent Policy + offers a change in class 3 or 4 + (as described in § 6.2.3 Classes of Changes) to a technical report under this process + the Team must request + a recorded royalty-free patent commitment; + for a change in class 4, the Team must secure such commitment. + Such commitment should cover, + at a minimum, + all the party’s Essential Claims both in the contribution, + and that become Essential Claims as a result of incorporating the contribution into the draft + that existed at the time of the contribution, + on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

+

6.3. The W3C Recommendation Track

+

Working Groups create specifications and guidelines + to complete the scope of work envisioned by a Working Group’s charter. + These technical reports undergo cycles of revision and review + as they advance towards W3C Recommendation status. + Once review suggests the Working Group has met their requirements for a new standard, + including wide review, + a Candidate Recommendation phase + allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. + At the end of the process, + the Advisory Committee reviews the mature technical report, + and if there is support from its Membership, + W3C publishes it as a Recommendation.

+

In summary, the main steps of the W3C Recommendation Track are:

+
    +
  1. Publication of the First Public Working Draft. +
  2. Publication of zero or more revised Working Drafts. +
  3. Publication of one or more Candidate Recommendations. +
  4. Publication as a W3C Recommendation. +
+
+ + Basic W3C Recommendation Track + + + + + First Public Working Draft (FPWD) - Exclusion opportunity + + + + WG Decision + + Team Approval + + + + + + + + + Working Draft (WD) + + + + + + + + Publish a new Working Draft + + + WG Decision + + + + + + + + + Advance to Candidate Recommendation + + WG Decision + + Team Approval + + + + + + + + + + Candidate Recommendation Snapshot (CRS) - Patent Policy exclusion opportunity + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG + Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + Team Approval + + + + + + + + Advance to Recommendation + + WG Decision + + Team Approval + + AC Review + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision with AB+TAG Approval) + + + + + + + + + + + Candidate Recommendation Draft (CRD) + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + + Team Approval + + + + + + + + + + + Recommendation + + + + + + + + Return to Candidate Recommendation Snapshot + + + WG Decision + (or Team Decision + with AB+TAG + Approval) + + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision + with AB+TAG + Approval) + + + + + + + + + Publish revised Recommendation with editorial changes + + + WG Decision + (editorial) + + + + + + + + + Publish revised Recommendation with substantive changes + + + WG Decision + + Team Approval + + AC Review + (substantive) + + + + + + + + + +
Non-Normative Summary of the Recommendation Track
+
+

Only sufficiently technically mature work should be advanced. + As described in § 6.3.3 Advancement on the Recommendation Track, + the Team will decline a request to advance in maturity stage + and return the specification to a Working Group for further work + if it determines that the requirements for advancement + have not been met.

+

Note: Should faster advancement to meet scheduling considerations be desired, + this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring + less stable features to other technical reports.

+

W3C may end work on a technical report at any time.

+

6.3.1. Maturity Stages on the Recommendation Track

+

A W3C Recommendation Track document is any document whose current status is one of those described in this section.

+
+
Working Draft (WD) +
+ A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, + and other technical organizations, + and for simple historical reference. + Some, but not all, Working Drafts are meant to advance to Recommendation; + see the document status section of a Working Draft + for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, + and do not imply any endorsement by W3C + or its members beyond agreement to work on a general area of technology. + Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. + A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity. +

For all Working Drafts a Working Group:

+
    +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, + and +
  • may request publication of a Working Draft + even if its content is considered unstable + and does not meet all Working Group requirements. +
+

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), + and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

+
Candidate Recommendation (CR) +
+ A Candidate Recommendation is a document that satisfies the technical + requirements of the Working Group that produced it and their dependencies, + and has already received wide review. + W3C publishes a Candidate Recommendation to + +

Note: Advancing to Candidate Recommendation indicates + that the document is considered complete and fit for purpose, + and that no further refinement to the text is expected + without additional implementation experience and testing; + however, additional features might be expected in a later revision. + A Candidate Recommendation is expected to be as well-written, + detailed, + self-consistent, + and technically complete + as a Recommendation, + and acceptable as such + if and when the requirements for further advancement are met.

+

Candidate Recommendation publications take one of two forms:

+
+
Candidate Recommendation Snapshot (CRS) +
+ A Candidate Recommendation Snapshot + corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. + Publishing a Patent Review Draft triggers a Call for Exclusions, + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy. +

Publication as a Candidate Recommendation Snapshot requires verification of either a Transition Request (for the first Candidate Recommendation publication from another maturity stage) + or an Update Request (for subsequent Candidate Recommendation Snapshots).

+
Candidate Recommendation Draft (CRD) +
+ A Candidate Recommendation Draft + is published + to solicit review of intended changes from the previous Candidate Recommendation Snapshot. + This allows for wider review of the changes + and for ease of reference to the integrated specification. +

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot. + However, the process requirements are minimized + so that the Working Group can easily keep the specification up to date.

+

A Candidate Recommendation Draft does not provide an exclusion opportunity; + instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

+
+

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered + such that W3C cannot endorse it or continue work on it, + for example due to burdensome patent claims that affect implementers and cannot be resolved + (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). + There is no path to restoration for a Rescinded Candidate Recommendation. + See “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

+
W3C Recommendation (REC) +
+ A W3C Recommendation is a specification + or set of guidelines + or requirements that, + after extensive consensus-building, + has received the endorsement of W3C and its Members. + W3C recommends the wide deployment + of its Recommendations as standards for the Web. + The W3C Royalty-Free IPR licenses + granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. +

After its initial publication, + a W3C Recommendation may be revised + (in accordance with § 6.3.10 Revising a W3C Recommendation) + to address editorial or substantive issues + that are discovered later. + However, new features can only be added + if the document already identifies itself + as intending to allow new features. + Adding or removing this allowance is a substantive change. + Such an allowance cannot be added + to a technical report previously published as a Recommendation that did not allow such changes; + this requires a new technical report (which could, for example, be similarly named but with an incremented version number).

+

As technology evolves, + a W3C Recommendation may become:

+
+
A Superseded Recommendation +
+ A Superseded Recommendation is a specification + that has been replaced by a newer version + that W3C recommends for new adoption. + An Obsolete or Superseded specification + has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy. +

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, + the latest version replaces the previous one, + without the need to invoke the steps of § 6.3.12.3 Abandoning a W3C Recommendation: + it is the same document, updated. + Explicitly declaring a documented superseded, using the process documented in § 6.3.12.3 Abandoning a W3C Recommendation, + is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

+
An Obsolete Recommendation +
An Obsolete Recommendation is a specification + that W3C has determined lacks sufficient market relevance + to continue recommending it for implementation, + but which does not have fundamental problems + that would require it to be Rescinded. + If an Obsolete specification gains sufficient market relevance, + W3C may decide to restore it to Recommendation status. +
Rescinded Recommendation +
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, + and believes is unlikely to ever be restored to Recommendation status. + See also “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+
Discontinued Draft +
A technical report representing the state of a Recommendation-track document + at the point at which work on it was discontinued. + See § 6.3.12.1 Abandoning an Unfinished Recommendation. +
+

This Process defines certain Recommendation Track publications as Patent Review Drafts. + Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004], + these correspond to “Last Call Working Draft” in the Patent Policy; + Starting from the 2020 Patent Policy [PATENT-POLICY-2020], + these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

+

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, + and do not necessarily imply consensus of a Working Group or Interest Group, + nor are their contents endorsed in any way by W3C.

+

When publishing an updated version of an existing Candidate Recommendation or Recommendation, + technical reports are expected to meet the same maturity criteria as when they are first published under that status. + However, in the interest of replacing stale documents with improved ones in a timely manner, + if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, + it is also permissible to publish an updated CR or REC following the usual process, + even if only some of these flaws have been satisfactorily addressed.

+

6.3.2. Implementation Experience

+

Implementation experience is required to show that a specification is sufficiently clear, + complete, + and relevant to market needs, + to ensure that independent interoperable implementations + of each feature of the specification will be realized. + While no exhaustive list of requirements is provided here, + when assessing that there is adequate implementation experience the Team will consider (though not be limited to):

+
    +
  • is each feature of the current specification implemented, + and how is this demonstrated? +
  • are there independent interoperable implementations of the current specification? +
  • are there implementations created by people other than the authors of the specification? +
  • are implementations publicly deployed? +
  • is there implementation experience + at all levels of the specification’s ecosystem + (authoring, consuming, publishing…)? +
  • are there reports of difficulties or problems with implementation? +
+

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. + Groups are often able to work more effectively + if they plan how they will demonstrate interoperable implementations + early in the development process; + for example, developing tests in concert with implementation efforts.

+

6.3.3. Advancement on the Recommendation Track

+

For all requests to advance a specification + to a new maturity stage + (called Transition Requests), + the Working Group:

+
    +
  • must record the group’s decision to request advancement. +
  • must obtain Team verification. Team verification (a Team decision) must be withheld if any Process requirements are not met + or if there remain any unresolved Formal Objections + (including any aspect upheld by a Council but not yet fully addressed), + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects a Transition Request it must indicate its rationale + to the Advisory Committee and the Working Group. +
  • must publicly document all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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 stage. +
  • must provide public documentation of any Formal Objections. +
  • should report which, if any, of the Working Group’s requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

For a First Public Working Draft there is no “previous maturity stage”, + so many requirements do not apply, + and verification is normally fairly straightforward. + For later stages, + especially transitions to Candidate or Recommendation, + there is usually a formal review meeting + to verify that the requirements have been met.

+

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved + while a Working Group’s charter is undergoing or awaiting a decision + on an Advisory Committee Review.

+

6.3.4. Updating Mature Publications on the Recommendation Track

+

Certain requests to re-publish a specification + within its current maturity stage + (called Update Requests) + require extra verification. + For such update requests, the Working Group:

+
    +
  • must record the group’s decision to request the update. +
  • must show that the changes have received wide review. +
  • + must obtain Team verification. Team verification (a Team decision): +
      +
    • +

      should be withheld +if any Process requirements are not met,

      +
    • +

      may be withheld +in consideration of unresolved Formal Objections +(including any aspect upheld by a Council but not yet fully addressed),

      +
    • +

      may be withheld +if the document does not adequately reflect +all relevant decisions of a W3C Council (or its delegates),

      +
    • +

      may be withheld +if the Team believes the Group is not making reasonable progress +on addressing issues raised by individuals external to the Group.

      +
    +

    If the Team rejects an Update Request, + it must indicate its rationale to the Working Group. + If it waives any Process requirements, + it must indicate its rationale to the AC.

    +
  • must provide public documentation of any Formal Objections. +
  • must publicly document of all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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, + or explain why the requirements have changed or been deferred, +
  • should report which, if any, of the Working Group’s requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

There is usually a formal review meeting + to verify that the requirements have been met.

+

Note: Update request verification is expected to be fairly simple + compared to verification of a transition request.

+

The Team must announce the publication + of the revised specification + to other W3C groups and the Public.

+

6.3.5. Publishing a First Public Working Draft

+

To publish the First Public Working Draft of a document, + a Working Group must meet the applicable requirements for advancement.

+

The Team must announce + the publication of a First Public Working Draft to other W3C groups and to the public.

+

6.3.6. Revising a Working Draft

+

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.

+

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

+
    +
  • must record the group’s decision to request publication. Consensus is not required, + as this is a procedural step, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Working Draft, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous step, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups, +
+

Possible next steps for any Working Draft:

+ +

6.3.7. Transitioning to Candidate Recommendation

+

To publish a Candidate Recommendation, + in addition to meeting the requirements for advancement a Working Group:

+
    +
  • must show that the specification + has met all Working Group requirements, + or explain why the requirements have changed or been deferred, +
  • must document changes to dependencies during the development of the specification, +
  • must document + how adequate implementation experience will be demonstrated, +
  • must specify the deadline for comments, + delineating the Candidate Recommendation review period, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • must show that the specification has received wide review, and +
  • may identify features in the document as at risk. + These features may be removed + before advancement to Recommendation without requiring an Update Request. +
+

The first Candidate Recommendation publication + after verification of having met the requirements for a Transition Request is always a Candidate Recommendation Snapshot. + The Team must announce + the publication of the Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

Possible next steps after a Candidate Recommendation Snapshot:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.8. Revising a Candidate Recommendation

+
6.3.8.1. Publishing a Candidate Recommendation Snapshot
+

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, + the Working Group must meet the requirements of an update request in order to republish.

+

In addition the Working Group:

+
    +
  • must specify the deadline for further comments, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • may identify features in the document as at risk. + These features may be removed + before advancement to Recommendation without requiring an Update Request. +
+

The Team must announce + the publication of a revised Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

To provide timely updates and patent protection, + a Candidate Recommendation Snapshot should be published + within 24 months of the Working Group accepting + any proposal for a substantive change + (and preferably sooner). + To make scheduling reviews easier, + a Candidate Recommendation Snapshot should not be published + more often than approximately once every 6 months.

+

Note: Substantive changes trigger a new Exclusion Opportunity + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.8.2. Publishing a Candidate Recommendation Draft
+

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 + that would benefit from review beyond the Working Group.

+

To publish a revision of a Candidate Recommendation Draft, + a Working Group:

+
    +
  • must record the group’s decision to request publication, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups. +
+

Note: A Working Group does not need to + meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

+

Possible next steps after a Candidate Recommendation Draft:

+ +

6.3.9. Transitioning to Recommendation

+

When a Working Group estimates + that a Candidate Recommendation has fulfilled all the relevant criteria, + it may decide to request advancement to W3C Recommendation.

+
6.3.9.1. Requirements for Transition
+

In addition to meeting the requirements for advancement, + the Working Group:

+ +

Additionally, + if the document has previously been published as a W3C Recommendation, the Working Group must not include any class 4 change to that publication + unless it was explicitly marked as allowing new features, + and must not include any such marking + if not already present.

+

If the document’s most recent publication is a Candidate Recommendation Draft, + the Team must verify + that it contains no changes since the previous Candidate Recommendation Snapshot other than:

+ +

Otherwise, the Working Group must republish it + as a Candidate Recommendation Snapshot prior to initiating the review.

+
6.3.9.2. Initiating Review
+

If all the criteria above are fulfilled, + the Team must begin an Advisory Committee Review on the question of whether the identified Candidate Recommendation is appropriate to publish as a W3C Recommendation. + The deadline for Advisory Committee review must allow at least 28 days, + and must end at least 10 days + after the end of the last Exclusion Opportunity + per ”Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.9.3. Resolution of Review
+

If there was any Formal Objection during the Advisory Committee Review, + the Team must publish the substantive content of the dissent to W3C and the general public, + and the W3C Recommendation must not be published + unless all Formal Objections to the document have been retracted or overruled and at least 14 days have elapsed since the publication of the corresponding Council Report.

+

The decision to advance a document to Recommendation is a W3C Decision. + The Team must announce the publication of a W3C Recommendation to the Advisory Committee, + to other W3C groups + and to the public. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

The newly published Recommendation must not make any substantive changes to the document + compared to the Candidate Recommendation Snapshot submitted for AC Review, + other than dropping features identified at risk.

+
6.3.9.4. Next Steps from W3C Recommendation
+

Possible next steps: + A W3C Recommendation normally retains its status indefinitely. + However it may be:

+ +

6.3.10. Revising a W3C Recommendation

+
6.3.10.1. Revising a Recommendation: Editorial Changes
+

Editorial changes to a Recommendation require no technical review of the intended changes. + A Working Group, + provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity stages. + (See class 1 and class 2 changes.)

+
6.3.10.2. Revising a Recommendation: Substantive Changes
+

Tentative corrections (see class 3 changes) may be annotated into a Recommendation using candidate corrections.

+

Note: Candidate corrections do not normatively modify the document; + they editorially indicate how one might do so. + They are therefore published following the provisions of § 6.3.10.1 Revising a Recommendation: Editorial Changes.

+

A candidate correction can be made normative + and be folded into the main text of the Recommendation, + once it has satisfied all the same criteria + as the rest of the Recommendation, + including review by the community to ensure + its technical and editorial soundness. + To validate this, the Working Group must request + a Last Call for Review of Proposed Amendments, + followed by an update request. + See § 6.3.10.4 Incorporating Candidate Amendments.

+

Alternatively, + a Working Group may incorporate the changes + and publish as a Working Draft—​or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—​and advance the specification from that state. + (See class 3 changes.)

+
6.3.10.3. Revising a Recommendation: New Features
+

For Recommendations explicitly identified as allowing new features, + tentative new features (see class 4 changes) may be added as candidate additions in annotations, + and class 4 changes may be normatively incorporated + in the same fashion as class 3 changes in § 6.3.10.2 Revising a Recommendation: Substantive Changes.

+

Note: Limiting the addition of new features to Recommendations that explicitly allow them + enables third parties to depend on a stable feature-set for Recommendations that do not advertise that ability, + as was the case for all Recommendations prior to the 2020 revision of this Process.

+

Note: When a Recommendation does not allow new features, + new features can be added by creating a new technical report and following the full process of advancing that technical report to Recommendation—​beginning with a new First Public Working Draft. + Such technical reports could be written to represent + additional modules building on top of the original Recommendation of the core technology, + or an expanded replacement of the original Recommendation of the core technology + (in which case the new technical report will typically have the same name as the original, + with an incremented version number).

+
6.3.10.4. Incorporating Candidate Amendments
+

A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.

+

The Last Call for Review of Proposed Amendments must be announced to other W3C groups, the public, and the Advisory Committee. + The announcement must:

+
    +
  • Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, + or Last Call for Review of Proposed Corrections and Additions. +
  • Identify the specific candidate amendments under review + as proposed amendments (proposed corrections/proposed additions). +
  • Specify the deadline for review comments, + which must not be any sooner than 60 days from the Call for Review. +
  • Solicit review and, if it does not already have it, implementation experience. +
+

The combination of the existing Recommendation with the proposed amendments included in the Last Call for Review of Proposed Amendments is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. + Also, the review initiated by the Last Call for Review of Proposed Amendments is an Advisory Committee Review.

+

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

+

A Working Group may batch + multiple proposed amendments into a single Last Call for Review of Proposed Amendments. + To facilitate review, + a Last Call for Review of Proposed Amendments on a given specification should not be issued more frequently + than approximately once every 6 months.

+

At the end of the Last Call for Review of Proposed Amendments, + the W3C Decision may either be + to reject the proposed amendment, + or to clear the proposed amendment for advancement as is, + or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. + If the Working Group needs to amend a proposed amendment in response to review feedback + it must issue another Last Call for Review of Proposed Amendments on the revised change + before it can be incorporated into the main text.

+

Once all comments on a proposed amendment have been formally addressed, + and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, + it may incorporate the proposed amendment into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

+

To ensure adequate review of proposed amendment combinations, + only proposed amendments included in the most recent Last Call for Review of Proposed Amendments can be incorporated into the normative Recommendation text. + (Thus if incorporation of a proposed amendment is postponed, + it may need to be included in multiple Last Calls for Review of Proposed Amendments.)

+

6.3.11. Regression on the Recommendation Track

+

A Working Group may republish a Recommendation-track technical report at a lower maturity stage by fulfilling the requirements to transition to that maturity stage, + as described above.

+

Additionally, + with the approvals (by group decision) of each of the TAG and the AB the Team may return + the technical report to a lower maturity stage in response to wide review or a formal objection.

+

6.3.12. Retiring Recommendation Track Documents

+

Work on a technical report may cease at any time. + Work should cease + if W3C or a Working Group determines + that it cannot productively carry the work any further.

+
6.3.12.1. Abandoning an Unfinished Recommendation
+

Any Recommendation-track technical report no longer intended + to advance or to be maintained, + and that is not being rescinded, should be published as a Discontinued Draft, + with no substantive change compared to the previous publication. + This can happen if + the Working Group decided + to abandon work on the report, + or as the result of an AC Review requiring the Working Group to discontinue work on the technical report before completion. + If a Working Group is made to close, + W3C must re-publish any unfinished technical report on the Recommendation track as Discontinued Draft.

+

Such a document should include in its status section + an explanation of why it was discontinued.

+

A Working Group may resume work + on such a technical report within the scope of its charter + at any time, + by re-publishing it as a Working Draft.

+
6.3.12.2. Rescinding a Candidate Recommendation
+

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

+
6.3.12.3. Abandoning a W3C Recommendation
+

It is possible that W3C decides + that implementing a particular Recommendation is no longer recommended. + There are three designations for such specifications, + chosen depending on the advice W3C wishes to give about further use of the specification.

+

W3C may obsolete a Recommendation, + for example if the W3C Community decides that the Recommendation no longer represents best practices, + or is not adopted and is not apparently likely to be adopted. + An Obsolete Recommendation may be restored to normal Recommendation, + for example because despite marking it Obsolete the specification is later more broadly adopted.

+

W3C may declare a Recommendation Superseded + if a newer version exists which W3C recommends for new adoption. + The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; + only the name and explanation change.

+

W3C may rescind a Recommendation + if W3C believes there is no reasonable prospect of it being restored + for example due to burdensome patent claims that affect implementers and cannot be resolved; + see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” + and “PAG Conclusion”.

+

W3C only rescinds, supersedes, or obsoletes entire Recommendations. + A Recommendation can be both superseded and obsolete. + To rescind, supersede, or obsolete some part of a Recommendation, + W3C follows the process for modifying a Recommendation.

+

Note: For the purposes of the W3C Patent Policy, [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, + although it is not advised for future implementation; + a Rescinded Recommendation ceases to be in effect + and no new licenses are granted under the Patent Policy.

+
+ + Supersede, Obsolete or Rescind a W3C Recommendation + + + + Recommendation (Rec) + + + + + A major problem and an AC review can lead to a Recommendation being Rescinded. + There are no new IPR licences issued under the W3C Patent Policy, + and reinstating the Recommendation requires going through the full Rec-track process again. + + Major problem, AC review + + + Rescinded Recommendation - no new IPR licenses + + + + + + + + + With little uptake, following AC review a specification may become an Obsolete Recommendation + + + + + Obsolete Recommendation + + + + + + + + If there is new uptake, with AC review an Obsolete Recommendation may return to normal Recommendation status + + + + + + + + + + + Replaced by a new version, AC review + + Superseded Recommendation + + + + + + + A Superseded Recommendation can become a normal Recommendation with AC review + + + + + + + + + + + +
Non-Normative Summary of the Paths to Retiring a W3C Recommendation
+
+
6.3.12.4. Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
+

The process of rescinding, obsoleting, + superseding, + or restoring + a Recommendation can be initiated + either by a request from the Team or via a request from any of the following:

+ +

The Team must then + submit the request to the Advisory Committee for review. + For any Advisory Committee review of a proposal to + rescind, + obsolete, + supersede, + or restore + a Recommendation the Team must:

+
    +
  • announce the proposal to all Working Group Chairs, + and to the Public, + as well as to the Advisory Committee +
  • indicate that this is a proposal to + Rescind, + Obsolete, + Supersede, + or restore, + a Recommendation as appropriate +
  • identify the Recommendation by URL +
  • publish a rationale for the proposal +
  • identify known dependencies + and solicit review from all dependent Working Groups +
  • solicit public review +
  • specify the deadline for review comments, + which must be at least 28 days + after the announcement +
+

and should

+
    +
  • identify known implementations. +
+

If there was any dissent in the Advisory Committee review, + the Team must publish + the substantive content of the dissent to W3C and the public, + and must formally address the dissent + at least 14 days + before publication as an Obsolete or Rescinded Recommendation.

+

The Advisory Committee may initiate an Advisory Committee Appeal of the Team’s decision.

+

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. + The updated version may remove the main body of the document. + The Status of this Document section should link + to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

+

Once W3C has published a Rescinded Recommendation, + future W3C technical reports must not include normative references + to that technical report.

+

Note: W3C strives to ensure that all Technical Reports + will continue to be available at their version-specific URL.

+

6.4. The Note Track (Notes and Statements)

+

6.4.1. Group Notes

+

A Group Note (NOTE) + is published + to provide a stable reference for a useful document + that is not intended to be a formal standard.

+

Working Groups, Interest Groups, + the TAG and the AB may publish work as Notes. + Examples include:

+
    +
  • supporting documentation for a specification, + such as explanations of design principles + or use cases and requirements +
  • non-normative guides to good practices +
+

Some Notes are developed through successive Note Drafts before publication as a full Notes, + while others are published directly as a Note. + There are few formal requirements to publish a document as a Note or Note Draft, + and they have no standing as a recommendation of W3C + but are simply documents preserved for historical reference.

+

Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Note Drafts.

+

6.4.2. Publishing Notes

+

In order to publish a Note or Note Draft, + the group:

+
    +
  • must record their decision + to request publication as a Note or Note Draft, and +
  • should publish documentation + of significant changes to the technical report + since any previous publication. +
+

Both Notes and Note Drafts can be updated by republishing + as a Note or Note Draft. + A technical report may remain + a Note indefinitely.

+

6.4.3. Elevating Group Notes to W3C Statement status

+

A W3C Statement is a Note that has been endorsed by W3C as a whole. + In order to elevate a Note to W3C Statement status, + A group must:

+ +

A Note specifying implementable technology should not be elevated to W3C Statement status; + if it does, + the request to publish as a Statement must include rationale + for why it should be elevated, + and why it is not on the Recommendation track.

+

Once these conditions are fulfilled, + the Team must then + begin an Advisory Committee Review on the question of + whether the document is appropriate to publish as a W3C Statement. + During this review period, + the Note must not be updated.

+

The decision to advance a document to W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

The Team must announce the publication of a W3C Statement to the Advisory Committee, other W3C groups, and the public.

+

6.4.4. Revising W3C Statements

+

Given a recorded group decision to do so, + groups can request publication of a W3C Statement with editorial changes—​including candidate amendment—​without any additional process.

+

A candidate amendment can be folded into the main text of the W3C Statement, + once it has satisfied all the same criteria + as the rest of the Statement, + including review by the community to ensure + the substantive and editorial soundness of the candidate amendments. + To validate this, the group must request + an Advisory Committee review of the changes it wishes to incorporate. + The specific candidate amendments under review must be identified as proposed amendments just as in a Last Call for Review of Proposed Corrections.

+

The decision to incorporate proposed amendments into W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

6.5. The Registry Track

+

A registry documents a data set + consisting of one or more registry tables, + each table representing an updatable collection + of logically independent, consistently-structured registry entries. + A registry consists of:

+ +

The purposes of maintaining a registry can include:

+
+
non-collision +
Avoiding the problem + of two entities using the same value with different semantics. +
non-duplication +
Avoiding the problem + of having two or more different values in use with the same semantics. +
information +
Providing a central index + where anyone can find out + what a value means + and what its formal definition is + (and where it is). +
submission +
Ease of adding new terms, + including by stakeholders external to the custodian organization. +
consensus +
Promoting a clear consensus of the community on the terms. +
+

This section of the W3C Process provides a specialized process + facilitating the publication and maintenance of such registry tables, + particularly those required by or closely related to W3C Recommendations.

+

Note: Not every table in a specification is a potential registry. + If the intent or effect is that the table enumerates + all the possibilities the authors of the specification expect or envisage, + then the table by itself is enough. + Similarly, if the table is managed by the Working Group + and only updated as part of specification update, + then the complexities of registry management are not needed.

+

6.5.1. Registry Definitions

+

A registry definition defines what each registry table is and how it is maintained. + It must:

+
    +
  • Define the scope and purpose of each registry table. +
  • Define the fields of each registry table and their constraints + (e.g. values must be drawn from a defined set, or be unique, + or only reference publicly available resources, + etc.) +
  • + Define the policy for changes to existing entries, such as +
      +
    • whether entries can be deleted or deprecated +
    • whether entries can be changed after being published, and what kinds of changes are allowed +
    • whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely +
    +
  • Define the method and criteria by which changes are proposed, approved, and incorporated. + (For example, a registry could define + that changes to registry entries can be proposed using a particular web form or email address, + that they must be accompanied by certain background information, + or that they do or do not need to be approved by any member of a particular Working Group.) +
  • + Identify the custodian of the registry table: + the entity to which requests for registry changes must be sent, + and which is responsible for evaluating whether such requests + satisfy the criteria defined in the registry definition. +

    The custodian may be the initiating group, the Team, or a delegated entity. + The custodian for all registry tables in a single registry should generally be the same entity.

    +

    If the custodian of a registry table ceases to exist or to operate as a custodian + (e.g., the relevant group is disbanded, or + the custodian is unresponsive to repeated attempts to make contact), + and the chartered or elected group that owns the registry definition is itself closed or + unresponsive, + the Team should propose replacing the custodian, + which must be confirmed + by an AC Review as a W3C Decision.

    +
+

6.5.2. Publishing Registries

+

A chartered or elected group can publish a registry as a stand-alone technical report on the Registry Track, + where it is called a registry report. Working Groups have the additional option of + incorporating a registry as part of a Recommendation, + as an embedded registry.

+

The registry report or embedded registry must:

+ +

The Team must make available + a means for interested parties to be notified of any updates to a registry table.

+

Note: Since the Process does not impose requirements + on changes to the contents of a registry table other than those imposed by the registry definition, + acceptance of proposed registry changes on behalf of the custodian and + publication of an updated registry report that contains + only registry changes since the previous publication + can be automated + if satisfaction of those rules can be automatically verified.

+

Rules for publication and advancement on the Registry Track are identical to that of the Recommendation Track with the following exceptions:

+ +

6.5.3. Updating Registry Tables

+

Changes to the contents of a registry table that are in accordance with the registry definition, + (i.e. Class 5 changes) + can be made by re-publishing the technical report that contains the affected table, + without needing to satisfy any other requirements for the publication + (not even a group decision, unless this is required by the registry definition). + Such registry changes do not trigger new Advisory Committee Reviews, + nor Exclusion Opportunities, + and do not require verification via an update request, + even for technical reports at maturities where this would normally be expected. + Such publications can be made + even in the absence of a group chartered to maintain the registry + when the custodian is another entity.

+

Note: The custodian is only empowered to make registry changes. + If the group establishing the registry wishes + to empower the custodian to add commentary on individual entries, + this needs to be part of the registry table’s definition. + If other changes are desired, + they need to be requested of the group responsible for maintaining the registry definition—​or in the absence of such a group, of the Team.

+

Changes to the registry tables made in accordance with candidate or proposed amendments to the registry definition which would not be allowed by the unamended registry definition must be identified as such.

+

6.5.4. Registry Data Reports

+

When the registry data is published in a separate technical report from its registry definition, + that report is called a Registry Data Report. + This technical report:

+ +

Registry Data Reports do not have maturity stages in and of themselves; + The maturity stage of the registry whose data they record + is that of the technical report holding the registry definition.

+

Anytime a change is made to a registry definition, + the group maintaining the registry definition must update and republish + any document holding the corresponding registry tables to make it consistent with these changes.

+

Given a recorded group decision to do so, + the group maintaining the registry definition may republish the Registry Data Report to incorporate editorial changes.

+

6.5.5. Specifications that Reference Registries

+

Registries document values, + they do not define any architectural or interoperability requirements + related to those values. + All architectural and interoperability requirements + pertaining to registry entries must be contained in the specifications that reference the registry, + and are therefore subject to the processes + (including approval and intellectual property provisions) + applicable to those referencing specifications.

+

If there are entries that must be implemented, + or any other such restrictions, + they must be defined or documented + in the referencing specification + without dependency on the registry.

+
For example, “All implementations must implement the Basic-Method as defined in the registry” is not acceptable because + a change to the definition of the Basic-Method in the registry would then affect conformance. + Instead, the requirement has to be complete in the specification, + directly or by reference to another specification. + For example “All implementations must recognize the name Basic-Method, + and implement it as defined by section yy of IETF RFC xxxx”. + (The Registry is nonetheless expected to contain Basic-Method as an entry.)
+

6.5.6. Registries and Patents

+

A registry report or embedded registry is not subject to the W3C Patent Policy, + and must not define any requirements on implementations. + For the purposes of the Patent Policy [PATENT-POLICY] (only), + any embedded registry in a Recommendation track document + is not a normative portion of that specification.

+

6.6. Switching Tracks

+

Given a Group decision to do so, Working Groups can republish a technical report on a different track than the one it is on, + under the following restrictions:

+ +

Technical reports that switch tracks start at + their new track’s initial maturity stage, + while retaining any established identity (url, shortname, etc.).

+

Note: The initial maturity stage of the Recommendation track is Working Draft. First Public Working Draft designates a specific type of Working Draft and is not a separate maturity stage. + A document which switches to the Recommendation track is only published as a First Public Working Draft if it was never previously published as such; + otherwise, it is simply a Working Draft.

+

6.7. Further reading

+

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews + and announcements of the various steps, + and tips on getting to Recommendation faster [REC-TIPS]. + Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

+

7. Dissemination Policies

+

7.1. Public Communication

+

The Team is responsible for managing communication within W3C + and with the general public + (e.g., news services, press releases, managing the website and access privileges, and managing calendars). + Members should solicit review by the Team + prior to issuing press releases about their work within W3C.

+

The Team makes every effort to ensure the persistence and availability of the following public information:

+ +

To keep the Members abreast of W3C meetings, Workshops, + and review deadlines, + the Team provides them with a regular (e.g., weekly) news service + and maintains a calendar [CALENDAR] of official W3C events. + Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

+

7.2. Confidentiality Levels

+

There are three principal levels of access to W3C information + (on the W3C website, in W3C meetings, etc.): + public, + Member-only, + and Team-only.

+

While much information made available by W3C is public, + “Member-only” information + is available to authorized parties only, + including representatives of Member organizations, Invited Experts (as described in https://www.w3.org/invited-experts/#memaccess), + the Advisory Board, + the TAG, + and the Team. + For example, + the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

+

“Team-only” information + is available to the Team and other authorized parties.

+

Those authorized to access Member-only and Team-only information:

+
    +
  • must treat the information as confidential within W3C, +
  • must use reasonable efforts to preserve that confidentiality, and +
  • must not release this information to the general public or press, + nor beyond the designated level of access. +
+

The Team must provide mechanisms + to protect the confidentiality of Member-only information + and ensure that authorized parties have proper access to this information. + Documents should clearly indicate + whether they require Member-only confidentiality. + Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

+

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member + who are considered appropriate recipients. + For instance, + it is the responsibility of the Advisory Committee representative and other employees + and official representatives of the organization + to ensure that Member-only news announcements + are distributed for internal use only within their organization. + Information about Member mailing lists is available + in the New Member Orientation [INTRO].

+

7.3. Changing Confidentiality Level

+

As a benefit of membership, + W3C provides some Team-only and Member-only channels + for certain types of communication. + For example, Advisory Committee representatives can send reviews to a Team-only channel. + However, for W3C processes with a significant public component, + such as the technical report development process, + it is also important for information that affects decision-making to be publicly available. + The Team may need to communicate Team-only information to a Working Group or the public. + Similarly, a Working Group whose proceedings are Member-only must make public + information pertinent to the technical report development process.

+

This document clearly indicates which information must be available to Members or the public, + even though that information was initially communicated on Team-only or Member-only channels. + Only the Team and parties authorized by the Team + may change the level of confidentiality of this information. + When doing so:

+
    +
  1. The Team must use a version of the information + that was expressly provided by the author for the new confidentiality level. + In Calls for Review and other similar messages, + the Team should remind recipients to provide such alternatives. +
  2. The Team must not attribute the version + for the new confidentiality level to the author without the author’s consent. +
  3. If the author has not conveyed to the Team a version + that is suitable for another confidentiality level, + the Team may make available a version that reasonably communicates what is required, + while respecting the original level of confidentiality, + and without attribution to the original author. +
+

8. Liaisons

+

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, + through a number of mechanisms + ranging from very informal + (e.g., an individual from another organization participates in a W3C Working Group, + or just follows its work) + to mutual membership, + to even more formal agreements. + Liaisons are not meant to substitute for W3C membership.

+

All liaisons must be coordinated by the Team due to requirements for public communication; + patent, + copyright, + and other IPR policies; + confidentiality agreements; + and mutual membership agreements.

+

W3C may negotiate technical agreements with another organization. + For purposes of the W3C Process, + a technical agreement is a formal contract, + or a Memorandum of Understanding (MoU), + or a similar document, + between W3C and another party or parties, + that relates to the technical activity of the Consortium + (e.g., its publications, groups, or liaisons). + It specifies rights and obligations of each party toward the others. + These rights and obligations may include joint deliverables, + an agreed share of technical responsibilities with due coordination, + and/or considerations for confidentiality and specific IPR.

+

Non-technical agreements, including + those between W3C and its Members for the purposes of membership, + between W3C and its Partners for the purposes of partnership [BYLAWS], + and other agreements related to the operation of the Consortium + or to the ordinary provision of services, + are not subject to these Process provisions.

+

When considering a technical agreement (i.e., before the decision whether to sign is made), + the Team should provide + the Advisory Committee with a draft of the proposed agreement, + along with an explanation of how W3C would benefit from signing this agreement, + for their review and discussion. + After addressing any comments, + and subject to any management or governance procedures that apply + (e.g., formal review of proposed contracts by legal counsel or by the Board), + if the Team decides to proceed with signing the agreement, + the Team must announce the intent to sign, + and provide the final text of the agreement, + with an explanation of signing rationale, to + the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the agreement. + If the proposal is rejected on appeal, + the Team must not sign the agreement on behalf of W3C + unless directed to do so by the Board. + A signed agreement should be made public.

+

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

+

9. Member Submissions

+

A Member Submission is a document or set of documents + developed outside of W3C, + and submitted to W3C + by one or more Members (the Submitter(s)) + to propose technology or other ideas. + After review, + the Team may make the material available at the W3C website.

+

Making a Member Submission available at the W3C website + does not indicate endorsement, acceptance, or adoption by W3C, + its Team, or its Members. + The acknowledgment of a Submission request + does not imply that any action will be taken by W3C. + It merely records publicly + that the Submission has been made by the Submitter(s). + A Member Submission made available by W3C + is not a W3C technical report and must not be referred to as + an output or “work in progress” of W3C.

+

The Member Submission process consists of the following steps:

+
+
Submission +
One of the Submitters, + copying the Advisory Committee representatives of the other Submitters (if any), + sends a request to the Team to acknowledge the Submission request. + The Team and Submitter(s) communicate to ensure that the Member Submission is complete. +
Review +
+ The Team reviews the Submission + to evaluate its scope, quality, and compliance with the Submission requirements, + including licensing requirements: + +

Detailed procedures and requirements are defined by the Team and documented in the “Member submissions guidebook” [MEMBER-SUB].

+
Decision +
+ After review, the Team must either acknowledge or reject the Submission request. + +
+

The Advisory Committee representative(s) of the Submitter(s) may initiate a Submission Appeal. + The procedure for handling Submission Appeals is the same as for Formal Objections, + except that an AC Appeal is not possible + and both the Formal Objection and the Council Report are confidential to the Team, TAG, and AB.

+

10. Process Evolution

+

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, + with the Advisory Board acting as the sponsoring Working Group. + The documents may be developed by the AB or by another group to whom the AB has delegated development. + Review includes + soliciting input from the W3C community, + and in particular the Team.

+

The documents covered by this section are:

+ +

The Advisory Board initiates review as follows:

+
    +
  1. The Team sends a Call for Review to the Advisory Committee and other W3C groups. +
  2. After comments have been formally addressed and the document possibly modified, + the Team seeks endorsement from the Members by initiating an Advisory Committee review. + The review period must last at least 28 days. +
  3. After the Advisory Committee review, + following a W3C decision to adopt the document(s), + the Team does so + and sends an announcement to the Advisory Committee. + Advisory Committee representatives may initiate + an Advisory Committee Appeal to W3C. +
+

Note: As of June 2020, + the Patent Policy is developed in the Patents and Standards Interest Group, + the Code of Conduct in the Positive Work Environment Community Group, + and the Process in the W3C Process Community Group.

+

Appendix A: Retired Terminology

+

This section is non-normative.

+

Previous versions of this process defined and used various concepts and document statuses + that have since been retired or renamed. + For ease of reference, + this appendix lists the more notable ones, + and it links to the the definition or relevant section + in the most recent version of the Process that used them, + and gives the more recent equivalent term when there is one.

+
+
Amended Recommendation (retired term) +
Last defined in section 6.2.1 of the 2020 Process. +
Edited Recommendation (retired term) +
Last defined in section 6.1.2 of the 2019 Process. +
Last Call (retired term) +
Last defined in section 7.4.2 of the 2005 Process. +
Maturity level (renamed term) +
Last defined in section 6.3.1 of the 2021 Process, + now called maturity stage. +
Member Consortium, plural: Member Consortia + (renamed term) +
Last defined in section 2.1.2.1 of the 2021 Process, + now called Member Association. +
Memorandum of Understanding, plural: Memoranda of Understanding, abbreviation: MoU + (renamed term) +
Last defined in section 9 of the 2021 Process, + now called technical agreement. +
Other Charter (renamed term) +
Last used in section 5.2.6 of the 2020 Process, + now called Exclusion Draft Charter. +
Proposed Recommendation (retired term) +
Last defined in section 6.3.1 of the 2023 Process. +
Team Submissions (retired term) +
Last defined in section 2.2.1 of the 2019 Process. +
W3C Chair (renamed term) +
Last defined in section 2.2 of the 2014 Process, + now called CEO. +
+

Appendix B: Acknowledgments

+

This section is non-normative.

+

The editors are grateful to the following people, + who as interested individuals and/or with the affiliation(s) listed, + have contributed to this proposal for a revised Process: + Adam Basha, + Anna Weinberg (Apple) + Charles McCathie Nevile, + Chris Lilley (W3C), + Chris Needham (BBC), + Chris Wilson (Google), + Coralie Mercier (W3C), + David W. Singer (Apple), + Denis Ah-Kang (W3C), + Dominique Hazael-Massieux (W3C), + Ian Jacobs (W3C), + Jeffrey Yasskin (Google), + Jill Schmidt (Apple), + Marcos Cáceres (Apple), + Mark Nottingham, + Martin Thomson (Mozilla), + Michael Champion, + Michael Sirtori (Intel), + Mike Smith (W3C), + Nick Doty (Center for Democracy and Technology), + Nigel Megitt (BBC), + Philippe Le Hégaret (W3C), + Sam Sneddon (Apple), + Shawn Lawton Henry (W3C), + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Theresa O’Connor (Apple), + Vivien Lacourba (W3C).

+

The editors are sorry for forgetting any names, + and grateful to those who have listened patiently to conversations about this document + without feeling a need to add more.

+

The following individuals contributed to the development of earlier versions of the Process: + Alex Russell (Google), + Andreas Tai (Institut fuer Rundfunktechnik), + Andrew Betts (Fastly), + Ann Bassetti (The Boeing Company), + Anne van Kesteren, + Art Barstow (Nokia, unaffiliated), + Bede McCall (MITRE), + Ben Wilson, + Brad Hill (Facebook), + Brian Kardell (JQuery, Igalia), + Carine Bournez (W3C), + Carl Cargill (Netscape, Sun Microsystems, Adobe), + Charles McCathie Nevile (ConsenSys), + Chris Lilley (W3C), + Chris Needham (BBC), + Chris Wilson (Google), + Claus von Riegen (SAP AG), + Coralie Mercier (W3C), + Cullen Jennings (Cisco), + Dan Appelquist (Telefonica, Samsung), + Dan Connolly (W3C), + Daniel Dardailler (W3C), + Daniel Glazman (Disruptive Innovations), + David Baron (Mozilla), + David Fallside (IBM), + David W. Singer (Apple), + David Singer (IBM), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Don Brutzman (Web3D), + Don Deutsch (Oracle), + Eduardo Gutentag (Sun Microsystems), + Elika J. Etemad aka fantasai, + Florian Rivoal, + Fuqiao Xue (W3C), + Geoffrey Creighton (Microsoft), + Giri Mandyam (Qualcomm), + Gregg Kellogg, + Hadley Beeman, + Håkon Wium Lie (Opera Software), + Helene Workman (Apple), + Henri Sivonen (Mozilla), + Ian Hickson (Google), + Ian Jacobs (W3C), + Ivan Herman (W3C), + J Alan Bird (W3C), + Jay Kishigami 岸上順一 (NTT), + Jean-Charles Verdié (MStar), + Jean-François Abramatic (IBM, ILOG, W3C), + Jeff Jaffe (W3C), + Jeffrey Yasskin (Google), + Jim Bell (HP), + Jim Miller (W3C), + Joe Hall (CDT), + John Klensin (MCI), + Josh Soref (BlackBerry, unaffiliated), + Judy Brewer (W3C), + Judy Zhu 朱红儒 (Alibaba), + Kari Laihonen (Ericsson), + Karl Dubost (Mozilla), + Ken Laskey (MITRE), + Kevin Fleming (Bloomberg), + Klaus Birkenbihl (Fraunhofer Gesellschaft), + Larry Masinter (Adobe Systems), + Lauren Wood (unaffiliated), + Léonie Watson (The Paciello Group), + Liam Quin (W3C), + Marcos Cáceres (Mozilla), + Maria Courtemanche (IBM), + Mark Crawford (SAP), + Mark Nottingham, + Michael Champion (Microsoft), + Michael Geldblum (Oracle), + Mike West (Google), + Mitch Stoltz (EFF), + Natasha Rooney (GSMA), + Nigel Megitt (BBC), + Olle Olsson (SICS), + Ora Lassila (Nokia), + Paul Cotton (Microsoft), + Paul Grosso (Arbortext), + Peter Linss, + Peter Patel-Schneider, + Philippe Le Hégaret (W3C), + Qiuling Pan (Huawei), + Ralph Swick (W3C), + Renato Iannella (IPR Systems), + Rigo Wenning (W3C), + Rob Sanderson (J Paul Getty Trust), + Robin Berjon (W3C), + Sally Khudairi (W3C), + Sam Ruby (IBM), + Sam Sneddon, + Samuel Weiler (W3C), + Sandro Hawke (W3C), + Sangwhan Moon (Odd Concepts), + Scott Peterson (Google), + Shawn Lawton Henry, + Steve Holbrook (IBM), + Steve Zilles (Adobe Systems) + Steven Pemberton (CWI), + TV Raman (Google), + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Terence Eden (Her Majesty’s Government), + Thomas Reardon (Microsoft), + Tim Berners-Lee (W3C), + Tim Krauskopf (Spyglass), + Travis Leithead (Microsoft), + Virginia Fournier (Apple), + Virginie Galindo (Gemalto), + Wayne Carr (Intel), + Wendy Fong (Hewlett-Packard), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

Appendix C: Changes

+

This section is non-normative.

+

Changes since the 3 November 2023 Process

+

This document is based on the 3 November 2023 Process. + A list of issues addressed, + a diff from Process 2023 to this latest version, + as well as + a detailed log of all changes since then are available.

+

In addition to a number of editorial adjustments and minor tweaks, the following is a summary of the main differences:

+
+
Changes to technical reports and their publication +
+
    +
  • Retire the Proposed Recommendation phase of the Recommendation track. It was only used as a short-lived transition + during which various verifications and votes about CR were done. + These can be done on a CR + without having to republish it as a separate thing. + This simplifies the Process without changing the actual quality or consensus expectations. + (See Issue 861) +
  • Retire “Streamlined Publication Approval”. + This was meant to enable REC track publication with fewer/faster approval steps + when some stricter than usual criteria were fulfilled. + However, regular REC track publication have improved enough + that this became unnecessary, + and nobody was using it. + (See Issue 856) +
  • Add a requirement to make progress on external issues for update requests + (See Issue 781) +
  • Drop the requirement to publish every 6 months if nothing has changed. + (See Issue 1013) +
  • Enable Team to replace defunct registry custodians when no-one else can. + (See Issue 699) +
  • Allow registries to be published by Interest Groups, the Advisory Board, and the TAG, + in addition to Working Groups. + (See Issue 902) +
  • Rename “registry sections” to embedded registries to avoid confusion over whether they can be split across multiple sections of a Recommendation. + (See Issue 800) +
  • Rename "Draft Note" into "Note Draft", + and "Draft Registry" into "Registry Draft" + to be consistent with other statuses that uses the word "Draft", + and to make that word stand out more. + (See Issue 779) +
  • Clarify the definition of a Registry (see Issue 800) + and of Recommendation Track Documents (see Pull Request 831). +
  • Consolidate and harmonize into one section the various parts of the Process + that described whether and how the Team can maintain technical reports + that no longer have a Group chartered to maintain them. + (See Pull Request 860) +
+
Changes to chartering +
+ +
Changes to formal decision making and escalation +
+
    +
  • Adjust the rules guiding initiation of Councils, + to make the deadline strict, + and to provide a fallback mechanism if they are not met. + (See Pull Request 925) +
  • Make the Council’s short-circuit a little more flexible. + (See Issue 852) +
  • Exclude TAG/AB Members from voting on TAG/AB proposals in Councils. + (See Issue 749) +
  • Limit the involvement of Tim Berners-Lee to the TAG proper, + not including the Council. + (See Pull Request 792) +
  • Council dismissal vote counts must be reported. + (See Issue 748) +
  • Require documentation of how Formal Objections get resolved. + (See Issue 953) +
  • Put constraints on the timing of making Formal Objections public. + (See Issue 735) +
  • Fine-tune the rules about + how changes can be incorporated into a proposal + following an AC Review. + (See Issue 825) +
  • Adjust AC appeal vote threshold based on participation, + aligning with the thresholds and super majority requirements + for "Requisite Member Vote" from the W3C Bylaws. + (See Issue 886) +
  • Let the originator of a proposal decide whether to try again + after addressing feedback + following an AC Appeal. + (See Issue 844) +
  • Simplify provisions regarding substitute representatives and proxies. + (See Issue 373) +
+
Other changes +
+
    +
  • Reuse the bylaws’ notion of Good Standing, + and restrict TAG and AB elections + as well as AC Votes where a decision is made based on counting ballots + to Members in Good Standing. + (See Issue 935 and Pull Request 954) +
  • The section on Member Submissions was significantly shortened and simplified, + reducing the complexity under formal Process authority, + and shifting much of the material to /Guide, + under Team authority. + (See Issue 412 and Pull Request 936) +
  • Clarify how the outcome of certain ballots are determined. + (See Issue 836, Issue 838) +
  • Stop citing the superseded TAG charter. + (See Issue 794) +
  • Clarify amount of leeway around incomplete nominations to TAG or AB elections. + (See Issue 464) +
  • Shift most of the non-normative discussion about Workshops to [GUIDE], + and reorganize the remaining normative requirements. + (See Pull Request 876) +
  • The URL of this document was changed + from /Consortium/Process/ to /policies/process/ + for better integration in the W3C website architecture. +
+

Changes since earlier versions

+

Changes since earlier versions of the Process are detailed + in the changes section of the previous version of the Process.

+
+
+
+

Conformance

+

Document conventions

+

Conformance requirements are expressed + with a combination of descriptive assertions + and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text + with class="example", + like this:

+
+ +

This is an example of an informative example.

+
+

Informative notes begin with the word “Note” + and are set apart from the normative text + with class="note", + like this:

+

Note, this is an informative note.

+
+ +
+

Index

+

Terms defined by this specification

+ +

Terms defined by reference

+ +

References

+

Normative References

+
+
[COC] +
W3C Code of Conduct. URL: https://www.w3.org/policies/code-of-conduct/ +
[COLLABORATORS-AGREEMENT] +
Invited expert and collaborators agreement. URL: https://www.w3.org/invited-experts/agreement-2023/ +
[CONFLICT-POLICY] +
Conflict of Interest Policy for the W3C Team. URL: https://www.w3.org/policies/conflict-of-interest-policy-for-w3c-team/ +
[DOC-LICENSE] +
W3C Document License. URL: https://www.w3.org/copyright/document-license-2023/ +
[PATENT-POLICY] +
The W3C Patent Policy. URL: https://www.w3.org/policies/patent-policy/ +
[PATENT-POLICY-2004] +
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/ +
[PATENT-POLICY-2020] +
The W3C 2020 Patent Policy. URL: https://www.w3.org/policies/patent-policy/20200915/ +
[PUBRULES] +
Publication Rules. URL: https://www.w3.org/pubrules/ +
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
[RFC3797] +
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://www.rfc-editor.org/rfc/rfc3797 +
[W3C-PATENT-POLICY] +
Wendy Seltzer. W3C Patent Policy. 15 September 2020. URL: https://www.w3.org/policies/patent-policy/ +
+

Informative References

+
+
[AB-HP] +
The Advisory Board home page. URL: https://www.w3.org/2002/ab/ +
[AC-MEETING] +
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/events/ac/ +
[BG-CG] +
Community and Business Group Process. URL: https://www.w3.org/community/about/process/ +
[BYLAWS] +
Amended and Restated Bylaws of World Wide Web Consortium, Inc.. URL: https://www.w3.org/2024/09/25-w3c-bylaws.pdf +
[CALENDAR] +
Calendar of all scheduled official W3C events. URL: https://www.w3.org/events/ +
[CHAIR] +
W3C Working/Interest Group Chair. URL: https://www.w3.org/guide/chair/role +
[CHARTER] +
How to Create a Working Group or Interest Group. URL: https://www.w3.org/guide/process/charter +
[COUNCIL-REPORT-INDEX] +
Council Report Index. URL: https://www.w3.org/about/council/ +
[CURRENT-AC] +
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList +
[DECISION-APPEAL] +
Appealing a W3C Decision. URL: https://www.w3.org/guide/process/ac-appeal +
[ELECTION-HOWTO] +
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/guide/process/election +
[FELLOWS] +
W3C Fellows Program. URL: https://www.w3.org/careers/fellows/ +
[GROUP-MAIL] +
Group mailing lists. URL: https://www.w3.org/groups/ +
[GUIDE] +
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/guide/ +
[INTRO] +
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro +
[JOIN] +
How to Join W3C. URL: https://www.w3.org/membership/join/ +
[LIAISON] +
W3C liaisons with other organizations. URL: https://www.w3.org/liaisons/ +
[MEMBER-AGREEMENT] +
W3C Membership Agreement. URL: https://www.w3.org/membership/agreement/ +
[MEMBER-HP] +
Member website (Member-only access). URL: https://www.w3.org/Member/ +
[MEMBER-LIST] +
The list of current W3C Members. URL: https://www.w3.org/membership/list/ +
[MEMBER-SUB] +
Member submissions guidebook. URL: https://www.w3.org/submissions/guide/ +
[MISSION] +
The W3C Mission statement. URL: https://www.w3.org/mission/ +
[OBS-RESC] +
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/guide/process/obsolete-rescinded-supserseded +
[REC-TIPS] +
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/guide/standards-track/rec-tips +
[REPUBLISHING] +
In-place modification of W3C Technical Reports. URL: https://www.w3.org/guide/standards-track/republishing +
[SUBMISSION-LIST] +
The list of acknowledged Member Submissions. URL: https://www.w3.org/submissions/ +
[TAG-HP] +
The TAG home page. URL: https://www.w3.org/2001/tag/ +
[TEAM-CONTACT] +
Role of the Team Contact. URL: https://www.w3.org/guide/teamcontact/role +
[TR] +
The W3C technical reports index. URL: https://www.w3.org/TR/ +
[TRANSITION] +
Organize a Technical Report Transition. URL: https://www.w3.org/guide/transitions/ +
[TRANSLATION] +
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/ +
[W3C-IPR] +
W3C IPR Policies. URL: https://www.w3.org/policies/ +
+ + + diff --git a/snapshots/2025-08-18.html b/snapshots/2025-08-18.html new file mode 100644 index 00000000..85cc8b15 --- /dev/null +++ b/snapshots/2025-08-18.html @@ -0,0 +1,6472 @@ + + + + + W3C Process Document + + + + + + + + + + + + + + + + + + +
+

+

W3C Process Document

+

Draft Community Group Report,

+
+ More details about this document +
+
+
This version: +
https://www.w3.org/policies/process/drafts/snapshots/2025-08-18 +
Editor’s Draft: +
https://www.w3.org/policies/process/drafts/ +
Latest published version: +
https://www.w3.org/policies/process/ +
Previous Versions: +
+
Feedback: +
Github (preferred) +
Public mailing list +
Member-only mailing list +
Editors: +
Elika J. Etemad / fantasai (Apple) +
Florian Rivoal (Invited Expert) +
Former Editors: +
Natasha Rooney (Invited Expert) +
Charles McCathie Nevile (Yandex) +
Ian Jacobs (W3C) +
+
+
+
+

Copyright © 2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

+
+
+
+

Abstract

+

The mission of the World Wide Web Consortium (W3C) is making the web work, for everyone. +W3C brings together global stakeholders to develop open standards that enable a World Wide Web that connects and empowers humanity. +The W3C Process Document describes the organizational structure of W3C and processes, +responsibilities and functions that enable W3C to accomplish its mission. +This document does not describe the internal workings of the Team.

+

For more information about the W3C mission and the history of W3C, +please refer to About W3C.

+
+

Status of this document

+
+

W3C, including all existing chartered groups, + follows the most recent operative Process Document announced to the Membership.

+

This document is developed by the Advisory Board’s Process Task Force + working within the W3C Process Community Group (which anyone can join). + This is the 18 August 2025 Draft Community Group Report for the proposed next version of the W3C Process Document.

+

This document, +having completed Advisory Committee Review, +is proposed to be the next version of the W3C Process +after the 3 November 2023 Process. +How it is adopted is detailed in Section 11 Process Changes.

+

A history of substantial changes from previous versions of the Process Document is provided.

+
+
+ +
+

Relation of Process Document to Patent Policy and Other Policies

+

W3C Members' attention is called to the fact + that provisions of the Process Document are binding on Members + per their Membership Agreement [MEMBER-AGREEMENT]. + The W3C Patent Policy [PATENT-POLICY] and other policies + incorporated by normative reference as a part of the Process Document + are equally binding.

+

The Patent Policy and Code of Conduct place additional obligations on Members, Team, and other participants in W3C. + The Process Document does not restate those requirements but includes references to them. + The Process Document, Patent Policy, and Code of Conduct have been designed to allow each to evolve independently.

+

In the Process Document, the term “participant” refers to an individual, not an organization.

+

Conformance and specialized terms

+

The terms must, must not, should, should not, required, + and may are used in accordance with RFC 2119. + The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

+

Some terms have been capitalized in this document (and in other W3C materials) + to indicate that they are entities with special relevance to the W3C Process. + These terms are defined within this document, + and readers are reminded that the ordinary English definitions are insufficient + for the purpose of understanding this document.

+ +
+

1. Introduction

+

W3C work revolves around the standardization of Web technologies. + To accomplish this work, W3C follows processes that promote the development of high-quality standards + based on the consensus of the Membership, Team, and public. + W3C processes promote fairness, responsiveness, and progress: + all facets of the W3C mission. + This document describes the processes W3C follows in pursuit of its mission.

+

The W3C Process promotes the goals of quality and fairness in technical decisions + by encouraging consensus, + soliciting reviews (by both Members and public), + incorporating implementation and interoperability experience, + and requiring Membership-wide approval as part of the technical report development process. Participants in W3C include representatives of its Members and the Team, + as well as Invited Experts who can bring additional expertise or represent additional stakeholders. Team representatives both contribute to the technical work + and help ensure each group’s proper integration with the rest of W3C.

+

W3C’s technical standards, called W3C Recommendations, + are developed by its Working Groups; + W3C also has other types of publications, + all described in § 6 W3C Technical Reports. + W3C has various types of groups; + this document describes the formation and policies + of its chartered Working Groups and Interest Groups, + see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. + W3C also operates Community and Business Groups, + which are separately described in their own process document [BG-CG].

+

In addition, several groups are formally established by the Consortium: + the W3C Advisory Committee, which has a representative from each Member, + and two oversight groups elected by its membership: + the Advisory Board (AB), + which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process; + and the Technical Architecture Group (TAG), + which helps resolve Consortium-wide technical issues.

+

Here is a general overview of how W3C initiates standardization of a Web technology:

+
    +
  1. People generate interest in a particular topic. + For instance, Members express interest by developing proposals in Community Groups + or proposing ideas in Member Submissions. + Also, the Team monitors work inside and outside of W3C for signs of interest, + and helps organize Workshops to bring people together + to discuss topics that interest the W3C community. +
  2. When there is enough interest and an engaged community, + the Team works with the Membership + to draft proposed Interest Group or Working Group charters. + W3C Members review the proposed charters, + and when there is support within W3C for investing resources in the topic of interest, + W3C approves the group(s), + and they begin their work. +
+

Further sections of this Process Document deal with topics including + liaisons (§ 8 Liaisons), + confidentiality (§ 7 Dissemination Policies), + and formal decisions and appeals (§ 5 Decisions).

+

2. Members and the Team

+

W3C’s mission is to lead the Web to its full potential. + W3C Member organizations provide resources to this end, + and the W3C Team provides the technical leadership + and organization to coordinate the effort.

+

2.1. Members

+

W3C Members are + organizations subscribed according to a Membership Agreement [MEMBER-AGREEMENT]. + They are represented in W3C processes as follows:

+
    +
  1. One representative per Member organization participates + in the Advisory Committee which oversees the work of W3C. +
  2. Representatives of Member organizations participate + in Working Groups and Interest Groups, + where they author and review technical reports. +
+

W3C membership is open to all entities, + as described in “How to Join W3C” [JOIN]; + (refer to the public list of current W3C Members [MEMBER-LIST]). + The Team must ensure + that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

+

While W3C does not have a class of membership tailored to individuals, + individuals may join W3C. + Restrictions pertaining to related Members apply + when the individual also represents another W3C Member.

+

2.1.1. Rights of Members

+

Each Member organization enjoys the following rights and benefits:

+ +

Furthermore, subject to further restrictions included in their Member Agreement, + representatives of Member organizations participate in W3C as follows:

+ +

The rights and benefits of W3C membership [MEMBER-AGREEMENT] are contingent upon conformance to the processes described in this document. + Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.

+

Additional information for Members is available at the Member website [MEMBER-HP].

+

2.1.2. Member Associations and Related Members

+
2.1.2.1. Membership Associations
+

A “Member Association” means a consortium, + user society, + or association of two or more individuals, + companies, + organizations or governments, + or any combination of these entities + which has the purpose of participating in a common activity + or pooling resources to achieve a common goal other than participation in, + or achieving certain goals in, + W3C. + A joint-stock corporation or similar entity is not a Member Association merely because it has shareholders or stockholders. + If it is not clear whether a prospective Member qualifies as a Member Association, + the CEO may reasonably make the determination. + For a Member Association, the rights and privileges of W3C Membership + described in the W3C Process Document extend to the Member Association’s paid staff + and Advisory Committee representative.

+

Member Associations may also designate + up to four (or more at the Team’s discretion) individuals + who, though not employed by the organization, may exercise the rights of Member representatives.

+

For Member Associations that have individual people as members, + these individuals must disclose their employment affiliation + when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For Member Associations that have organizations as Members, + all such designated representatives must be an official representative of the Member organization + (e.g. a Committee or Task Force Chairperson) + and must disclose their employment affiliation when participating in W3C work. + Provisions for related Members apply. + Furthermore, these individuals must represent the broad interests of the W3C Member organization + and not the particular interests of their employers.

+

For all representatives of a Member Association, + IPR commitments are made on behalf of the Member Association, + unless a further IPR commitment is made by the individuals' employers.

+
2.1.2.2. Related Members
+

In the interest of ensuring the integrity of the consensus process, + Member involvement in some of the processes in this document is affected by related Member status. + As used herein, two Members are related if:

+
    +
  1. Either Member is a subsidiary of the other, or +
  2. Both Members are subsidiaries of a common entity, or +
  3. The Members have an employment contract or consulting contract that affects W3C participation. +
+

A subsidiary is an organization of which effective control and/or majority ownership rests with another, + single organization.

+

Related Members must disclose these relationships + according to the mechanisms described in the New Member Orientation [INTRO].

+

2.1.3. Good Standing

+

Members who have not lost Good Standing as defined in the Amended and Restated Bylaws of World Wide Web Consortium, Inc. are considered, for the purposes of this Process, + to be in Good Standing. + A group of related Members is in Good Standing if + at least one of them is in Good Standing.

+

2.2. The W3C Team

+

The Team consists of CEO, + W3C paid staff, + unpaid interns, + and W3C Fellows. W3C Fellows are Member employees working as part of the Team; + see the W3C Fellows Program [FELLOWS]. + The Team provides technical leadership about Web technologies, + organizes and manages W3C activities to reach goals + within practical constraints (such as resources available), + and communicates with the Members and the public + about the Web and W3C technologies.

+

The CEO may delegate responsibility + (generally to other individuals in the Team) + for any of their roles described in this document. Team Decisions derive from the CEO’s authority, + even when they are carried out by other members of the Team.

+

Oversight over the Team, + budgeting, + and other business decisions, + is provided by the W3C Board of Directors, + rather than managed directly by the Process.

+

Note: See the W3C Bylaws for more details + on the Board and overall governance of W3C.

+

3. Groups and Participation

+

For the purposes of this Process, a W3C Group is one of W3C’s Working Groups, Interest Groups, Advisory Committee, Advisory Board, + or TAG, + and a participant is a member of such a group.

+

3.1. Policies for Participation in W3C Groups

+

3.1.1. Individual Participation Criteria

+
3.1.1.1. Expectations and Discipline
+

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

+
    +
  1. Technical competence in one’s role; +
  2. The ability to act fairly; +
  3. Social competence in one’s role. +
+

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities + are responsible for assessing and attesting to the qualities of those nominees.

+

Participants in any W3C activity must abide + by the terms and spirit of the W3C Code of Conduct [COC] and the participation requirements described in + “Disclosure” + in the W3C Patent Policy [PATENT-POLICY].

+

The CEO may take disciplinary action, + including suspending or removing for cause + a participant in any group (including the AB and TAG) + if serious and/or repeated violations occur, + such as failure to meet the requirements on individual behavior of + (a) this process + and in particular the Code of Conduct, + (b) their membership agreement, or + (c) applicable laws. + Refer to the Guidelines to suspend or remove participants from groups.

+
3.1.1.2. Conflict of Interest Policy
+

Individuals participating materially in W3C work must disclose significant relationships + when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. + These disclosures must be kept up-to-date + as the individual’s affiliations change and W3C membership evolves + (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). + Each section in this document that describes a W3C group + provides more detail about the disclosure mechanisms for that group.

+

The ability of an individual to fulfill a role within a group + without risking a conflict of interest depends on the individual’s affiliations. + When these affiliations change, + the individual’s assignment to the role must be evaluated. + The role may be reassigned according to the appropriate process. + For instance, + the Team may appoint a new group Chair when the current Chair changes affiliations + (e.g., if there is a risk of conflict of interest, + or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

+

The following are some scenarios where disclosure is appropriate:

+
    +
  • Paid consulting for an organization whose activity is relevant to W3C, + or any consulting compensated with equity + (shares of stock, stock options, or other forms of corporate equity). +
  • A decision-making role/responsibility + (such as participating on a Board) + in other organizations relevant to W3C. +
  • A position on a publicly visible advisory body, + even if no decision-making authority is involved. +
+

Individuals seeking assistance on these matters should contact the Team.

+

Team members are subject to the Conflict of Interest Policy for the W3C Team [CONFLICT-POLICY].

+
3.1.1.3. Individuals Representing a Member Organization
+

Generally, individuals representing a Member in an official capacity within W3C + are employees of the Member organization. + However, an Advisory Committee representative may designate a non-employee + to represent the Member. + Non-employee Member representatives must disclose + relevant affiliations to the Team and to any group in which the individual participates.

+

In exceptional circumstances + (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), + the CEO may decline + to allow an individual designated by an Advisory Committee representative to participate in a group.

+

A group charter may limit + the number of individuals representing a W3C Member + (or group of related Members).

+

3.1.2. Meetings

+

The requirements in this section apply to the official meetings of any W3C group, + as well as to official W3C meetings with open-ended participation from the Membership and/or the public, + such as Workshops.

+

W3C distinguishes two types of meetings:

+
    +
  1. A face-to-face meeting is one + where most of the attendees are expected to participate in the same physical location. +
  2. A distributed meeting is one + where most of the attendees are expected to participate from remote locations + (e.g., by telephone, video conferencing, or IRC). +
+

A Chair may invite an individual with a particular expertise + to attend a meeting on an exceptional basis. + This person is a meeting guest, + not a group participant. + Meeting guests do not have voting rights. + It is the responsibility of the Chair to ensure + that all meeting guests respect the chartered level of confidentiality and other group requirements.

+
3.1.2.1. Meeting Scheduling and Announcements
+

Meeting announcements should be sent to all appropriate group mailing lists, + i.e. those most relevant to the anticipated meeting participants.

+

The following table lists recommendations for organizing a meeting:

+ + + + + + + + + +
+ Face-to-face meetings + Distributed meetings +
Meeting announcement (before) + eight weeks* + one week* +
Agenda available (before) + two weeks + 24 hours (or longer if a meeting is scheduled after a weekend or holiday) +
Participation confirmed (before) + three days + 24 hours +
Action items available (after) + three days + 24 hours +
Minutes available (after) + two weeks + 48 hours +
+

* To allow proper planning (e.g., travel arrangements), + the Chair is responsible for giving sufficient advance notice + about the date and location of a meeting. + Shorter notice for a meeting is allowed + provided that there are no objections from group participants. + In the case of Workshops, + shorter notice is not allowed.

+
3.1.2.2. Meeting Minutes
+

Groups should take and retain minutes of their meetings, + and must record + any official group decisions made during the meeting discussions. + Details of the discussion leading to such decisions are not required, + provided that the rationale for the group decision is nonetheless clear.

+
3.1.2.3. Meeting Recordings and Transcripts
+

No-one may take an audio or video recording of a meeting, + or retain an automated transcript, + unless the intent is announced at the start of the meeting, + and no-one participating in the recorded portion of the meeting withholds consent. + If consent is withheld by anyone, recording/retention must not occur. + The announcement must cover: + (a) who will have access to the recording or transcript and + (b) the purpose/use of it and + (c) how it will be retained (e.g. privately, in a cloud service) and for how long.

+

3.1.3. Tooling and Archiving for Discussions and Publications

+

For W3C Groups operating under this Process, + a core operating principle is to allow access across disabilities, + across country borders, + and across time. + Thus in order to allow all would-be participants to effectively participate, + to allow future participants and observers to understand the rationale and origins of current decisions, + and to guarantee long-lived access to its publications, + W3C requires that:

+
    +
  • All reports, publications, or other deliverables + produced by the group for public consumption + (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, + and backed up by W3C systems + such that if the underlying service is discontinued, + W3C can continue to serve such content without breaking incoming links + or other key functionality. +
  • All reports, publications, or other deliverables + produced by the group for public consumption should follow best practices for internationalization + and for accessibility to people with disabilities. + Network access to W3C-controlled domains may be assumed. +
  • + Official meeting minutes and other records of decisions made must be archived by W3C for future reference; + and other persistent text-based discussions + sponsored by the group, + pertaining to their work + and intended to be referenceable by all group members should be. + This includes discussions conducted over email lists + or in issue-tracking services + or any equivalent fora. + Materials referenced from discussions + and necessary to understand them + should be available at a stable URL, + at a level of confidentiality no stricter than the discussion minutes. +

    Note: The lack, or loss, of such archives does not by itself + invalidate an otherwise-valid decision.

    +
  • + Any tooling used by the group + for producing its documentation and deliverables + or for official group discussions should be usable + (without additional cost) + by all who wish to participate, + including people with disabilities, + to allow their effective participation. +

    Note: If a new participant joins who cannot use the tool, + this can require the Working Group to change its tooling + or operate some workaround.

    +
  • All tools and archives used by the group + for its discussions and recordkeeping should be documented + such that new participants and observers + can easily find the group’s tools and records. +
+

The Team is responsible for ensuring adherence to these rules + and for bringing any group not in compliance into compliance.

+

3.1.4. Resignation from a Group

+

A W3C Member or Invited Expert may resign from a group. + On written notification from an Advisory Committee representative + or Invited Expert + to the Team, + the Member and their representatives + or the Invited Expert + will be deemed to have resigned from the relevant group. + The Team must record the notification. + See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

+

3.2. The Advisory Committee (AC)

+

3.2.1. Role of the Advisory Committee

+

The Advisory Committee represents + the Members of W3C at large. + It is responsible for:

+ +

Advisory Committee representatives may initiate + an Advisory Committee Appeal of a W3C decision or Team’s decision.

+

See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

+

3.2.2. Participation in the Advisory Committee

+

The Advisory Committee is composed of one representative from each Member organization + (refer to the Member-only list + of current Advisory Committee representatives. [CURRENT-AC])

+

When an organization joins W3C + (see “How to Join W3C” [JOIN]), + it must name its Advisory Committee representative as part of their Membership Agreement. + The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, + provides information about Advisory Committee Meetings, + explains how to name a new Advisory Committee representative, + and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.

+

The AC representative may delegate any of their rights and responsibilities + to an alternate (except the ability to designate an alternate).

+

3.2.3. Advisory Committee Mailing Lists

+

The Team must provide two mailing lists for use by the Advisory Committee:

+
    +
  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. + This list is read-only for Advisory Committee representatives. +
  2. One for discussion among Advisory Committee representatives. + Though this list is primarily for Advisory Committee representatives, + the Team must monitor discussion + and should participate in discussion when appropriate. + Ongoing detailed discussions should be moved to other appropriate lists + (new or existing, such as a mailing list created for a Workshop). +
+

An Advisory Committee representative may request + that additional individuals from their organization be subscribed to these lists. + Failure to contain distribution internally may result in suspension of additional email addresses, + at the discretion of the Team.

+

3.2.4. Advisory Committee Meetings

+

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. + The Team appoints the Chair of these meetings (generally the CEO). + At each Advisory Committee meeting, + the Team should provide an update to the Advisory Committee about:

+
+
Resources +
+
    +
  • The number of W3C Members at each level. +
  • An overview of the financial status of W3C. +
+
Allocations +
+
    +
  • The allocation of the annual budget, including size of the Team and their approximate deployment. +
  • A list of all activities (including but not limited to Working and Interest Groups) + and brief status statement about each, + in particular those started or terminated since the previous Advisory Committee meeting. +
  • The allocation of resources to pursuing liaisons with other organizations. +
+
+

Each Member organization should send one representative to each Advisory Committee Meeting. + In exceptional circumstances + (e.g., during a period of transition between representatives from an organization), + the meeting Chair may allow a Member organization to send two representatives to a meeting.

+

The Team must announce the date and location of each Advisory Committee meeting + no later than at the end of the previous meeting; one year’s notice is preferred. + The Team must announce the region of each Advisory Committee meeting + at least one year in advance.

+

More information about Advisory Committee meetings [AC-MEETING] is available at the Member website.

+

3.3. Elected Groups: The AB and the TAG

+

The W3C Process defines two types of elected groups: + the Advisory Board (AB) and + the Technical Architecture Group (TAG), + both elected by the Advisory Committee.

+

3.3.1. Advisory Board (AB)

+
3.3.1.1. Role of the Advisory Board
+

The Advisory Board provides ongoing guidance to the Team + on issues of strategy, + management, + legal matters, + process, + and conflict resolution. + The Advisory Board also serves the Members + by tracking issues raised between Advisory Committee meetings, + soliciting Member comments on such issues, + and proposing actions to resolve these issues. + The Advisory Board manages the evolution of the Process Document. + As part of a W3C Council, + members of the Advisory Board hear and adjudicate on Submission Appeals and Formal Objections.

+

The Advisory Board is distinct from the Board of Directors and has no decision-making authority within W3C; + its role is strictly advisory.

+

Note: While the AB as such does not have decision-making authority, + its members do when sitting as part of a W3C Council.

+

Details about the Advisory Board + (e.g., the list of Advisory Board participants, + mailing list information, and summaries of Advisory Board meetings) + are available at the Advisory Board home page [AB-HP].

+
3.3.1.2. Composition of the Advisory Board
+

The Advisory Board consists of nine to eleven elected participants and one Chair + (who may be one of the elected participants). + With the input of the AB, + the Team appoints the Chair, + who should choose a co-chair among the elected participants. + Upon appointment, + the Chair(s) are subject to ratification by secret ballot, + requiring approval by two thirds of the elected participants. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The team also appoints a Staff Contact, + as described in § 3.4.1 Requirements for All Chartered Groups. + The CEO and Staff Contact have a standing invitation + to all regular Advisory Board sessions.

+

The nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

+

The terms of elected Advisory Board participants are for two years. + Terms are staggered so that each year, + either five or six terms expire. + If an individual is elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular Advisory Board terms begin on 1 July and end on 30 June.

+
3.3.1.3. Communications of the Advisory Board
+

The Team must make available a mailing list, + confidential to the Advisory Board and Team, + for the Advisory Board to use for its communication.

+

The Advisory Board should send a summary of each of its meetings + to the Advisory Committee and other group Chairs. + The Advisory Board should also report on its activities + at each Advisory Committee meeting.

+
3.3.1.4. Liaisons between the Advisory Board and the Board of Directors
+

To ensure good communication between the AB and the Board of Directors and facilitate operational and management consistency, + the AB may appoint up to two of its participants as liaisons to the Board. + Such appointees are expected to attend and participate in Board meetings + and access Board materials + as Non-voting Observers. [BYLAWS] They do not form part of the Board’s decision-making body, + and may be excluded from such participation + in accordance with applicable Board procedures.

+

The Advisory Board should reevaluate + who is assigned to this role + at least at the beginning of each term, + and may swap its appointees more frequently + as they deem appropriate.

+

3.3.2. Technical Architecture Group (TAG)

+
3.3.2.1. Role of the Technical Architecture Group
+

The mission of the TAG is stewardship of the Web architecture. + There are three aspects to this mission:

+
    +
  1. to document and build consensus around principles of Web architecture + and to interpret and clarify these principles when necessary; +
  2. to resolve issues involving general Web architecture brought to the TAG; +
  3. to help coordinate cross-technology architecture developments inside and outside W3C. +
+

As part of a W3C Council, + the members of the TAG hear and adjudicate on Submission Appeals and Formal Objections.

+

The TAG’s scope is limited to technical issues about Web architecture. + The TAG should not consider + administrative, + process, + or organizational policy issues of W3C, + which are generally addressed by + the W3C Advisory Committee, + Advisory Board, + and Team.

+

When the TAG votes to resolve an issue, + each TAG participant + (whether appointed, elected, or the Chair) + has one vote; + see also the general section on votes in this Process Document.

+

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) + are available at the TAG home page [TAG-HP].

+
3.3.2.2. Composition of the Technical Architecture Group
+

The TAG consists of:

+ +

Participants in the TAG choose by consensus their Chair or co-Chairs; + in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG. + The Chair or co-Chairs must be selected from the participants of the TAG. + Chair selection must be run + at least at the start of each regular term, + as well as when a majority of the participants request it; + and may be run at other times when initiated by the current chairs or the Team, + for example if a chair steps down or if a minority of the participants make such a request.

+

The Team also appoints a Staff Contact [TEAM-CONTACT] for the TAG, + as described in § 3.4.1 Requirements for All Chartered Groups.

+

The terms of TAG participants last for two years. + Terms are staggered so that four elected terms + and either one or two appointed terms expire each year. + If an individual is appointed or elected to fill an incomplete term, + that individual’s term ends at the normal expiration date of that term. + Regular TAG terms begin on 1 February and end on 31 January.

+
3.3.2.3. Communications of the Technical Architecture Group
+

The Team must make available two mailing lists for the TAG:

+
    +
  • a public discussion (not just input) list for issues of Web architecture. + The TAG will conduct its public business on this list. +
  • a Member-only list for discussions within the TAG + and for requests to the TAG that, + for whatever reason, cannot be made on the public list. +
+

The TAG may also request the creation of additional topic-specific, public mailing lists. + For some TAG discussions (e.g., a Submission Appeal), + the TAG may use a list that will be Member-only.

+

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. + The TAG should also report on its activities at each Advisory Committee meeting.

+

3.3.3. Participation in Elected Groups

+
3.3.3.1. Expectations for Elected Groups Participants
+

Advisory Board and TAG participants have a special role within W3C: + they are elected by the Membership and appointed by the Team with the expectation that they will use their best judgment + to find the best solutions for the Web, + not just for any particular network, + technology, + vendor, + or user. + Advisory Board and TAG participants are expected to participate regularly and fully. + Advisory Board and TAG participants should attend Advisory Committee meetings.

+

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, + to serve the needs of the W3C membership as a whole, + and the Web community. + Whether they are Member representatives or Invited Experts, + their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

+

An individual participates on the Advisory Board or TAG + from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). + Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, + their participation does carry the responsibilities associated with Member representation, + Invited Expert status, + or Team representation + (as described in the section on the AB/TAG nomination and election process).

+

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, + and a participant’s seat must not be delegated to any other person.

+
3.3.3.2. Elected Groups Participation Constraints
+

Given the few seats available on the Advisory Board and the TAG, + and in order to ensure that the diversity of W3C Members is represented:

+ +
3.3.3.3. Advisory Board and Technical Architecture Group Elections
+

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, + using a Single Transferable Vote system. + An election begins when the Team sends a Call for Nominations to the Advisory Committee. + Any Call for Nominations specifies the minimum and maximum number of available seats, + the deadline for nominations, + details about the specific vote tabulation system selected by the Team for the election, + and operational information such as how to nominate a candidate. + The Team may modify the tabulation system after the Call for Nominations + but must stabilize it no later than the Call for Votes. + The Team announces appointments + after the results of the election are known, + and before the start of the term, + as described in § 3.3.3.4 Technical Architecture Group Appointments.

+

In the case of regularly scheduled elections of the TAG, + the minimum and maximum number of available seats are the same: + the 4 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

+

In the case of regularly scheduled elections of the AB, + the minimum and maximum number of available seats differ: + The maximum number is the 5 or 6 seats of the terms expiring that year, + plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; + the minimum number is such that when added to the occupied seats from the prior year, + the minimum size of the AB (9) is reached.

+

Each Member (or group of related Members) may nominate one individual. + A nomination must be made with the consent of the nominee. + In order for an individual to be nominated as a Member representative, + the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination + the (same) information required for a Member representative in a Working Group. + In order for an individual to be nominated as an Invited Expert, + the individual must provide + the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. + In order for an individual to be nominated as a Team representative, + the nominating Advisory Committee representative must first secure approval from Team management. + A nominee is not required to be an employee of a Member organization, + and may be a W3C Fellow. + The nomination form must ask for the nominee’s primary affiliation, + and this will be reported on the ballot. + For most nominees, + the primary affiliation is their employer and will match their affiliation in the W3C database. + For contractors and invited experts, + this will normally be their contracting company + or their invited expert status; + in some cases + (e.g. where a consultant is consulting for only one organization) + this may be the organization for whom the nominee is consulting. + A change of affiliation is defined + such that this field would carry a different answer + if the nominee were to be re-nominated + (therefore, + terminating employment, + or accepting new employment, + are changes of affiliation). + (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) + Each nomination should include + a few informative paragraphs about the nominee. + If an identified candidate’s nomination information is only partially complete + as of the deadline for nominations, + the Team may allow extra time for that candidate’s nomination to be completed, + so long as it does not delay the election as a whole.

+

If, after the deadline for nominations, the number of nominees is:

+
    +
  • Greater than or equal to the minimum number of available seats + and less than or equal to the maximum number of available seats, + those nominees are thereby elected. + This situation constitutes a tie for the purpose of assigning incomplete terms. + Furthermore, if the number is less than the maximum number of available seats, + the longest terms are filled first. +
  • Less than the minimum number of available seats, + Calls for Nominations are issued until a sufficient number of people have been nominated. + Those already nominated do not need to be renominated after a renewed call. +
  • Greater than the maximum number of available seats, + the Team issues a Call for Votes + that includes the names of all candidates, + the (maximum) number of available seats, + the deadline for votes, + details about the vote tabulation system selected by the Team for the election, + and operational information. +
+

When there is a vote, + each Member in Good Standing (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. + Once the deadline for votes has passed, + the Team announces the results to the Advisory Committee. + In case of a tie the verifiable random selection procedure described below + will be used to fill the available seats.

+

The shortest incomplete term is assigned to the elected candidate ranked lowest by the tabulation of votes, + the next shortest term to the next-lowest ranked elected candidate, + and so on. + In the case of a tie among those eligible for a incomplete term, + the verifiable random selection procedure described below + will be used to assign the incomplete term.

+

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

+
3.3.3.4. Technical Architecture Group Appointments
+

The Team is responsible for appointing + 3 of the participants to the Technical Architecture Group. + This mechanism complements the election process. + The Team should use its appointments to support + a diverse and well-balanced TAG, + including diversity of technical background, knowledge, and skill sets.

+

The Team should actively seek + candidates for appointment to the TAG, + and must make available to + the W3C community at large + a means to propose candidates for consideration, + explicitly soliciting input from at least + current and incoming TAG members, the Advisory Committee, and Working Group Chairs.

+

The constraints for appointment to the TAG are + the same as for elected participants + (see § 3.3.3.2 Elected Groups Participation Constraints and § 3.3.3.3 Advisory Board and Technical Architecture Group Elections), + with the additional constraint that + a person must not be appointed + for more than two consecutive terms. + (Partial terms used to fill a vacated seat do not count towards this limit.)

+

Note: Since there are no limits on elected terms, + this limit on appointed terms does not constrain + term-limited appointees + from running for election at any time.

+

The Team’s choice of appointee(s) + is subject to ratification by secret ballot + by both the AB and the TAG, + requiring a two-thirds approval from each. + In the case of regularly scheduled elections, + the TAG participants in this ratification are + its members for the upcoming term.

+

For regularly scheduled elections, + selection begins once the results of the elections are known, + and the Team should announce the ratified appointment(s) + no later than the start of the regularly scheduled term. + When an appointed seat is vacated outside of a regularly scheduled election, + the Team should seek to appoint a replacement + unless a regular Call for Nominations is scheduled within 2 months, + and it must announce the ratified appointment + no later than the Call for Nominations of the next scheduled election.

+
3.3.3.5. Verifiable Random Selection Procedure
+

When it is necessary to use a verifiable random selection process + (e.g., in an AB or TAG election, + to “draw straws” in case of a tie + or to fill a incomplete term), + W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. + The procedure orders an input list of names + (listed in alphabetical order by family name unless otherwise specified) + into a “result order”.

+

W3C applies this procedure as follows:

+
    +
  1. When N people have tied for M (less than N) seats. + In this case, only the names of the N individuals who tied + are provided as input to the procedure. + The M seats are assigned in result order. +
  2. After all elected individuals have been identified, + when N people are eligible for M (less than N) incomplete terms. + In this case, only the names of those N individuals are provided as input to the procedure. + The incomplete terms are assigned in result order. +
+
3.3.3.6. Elected Groups Vacated Seats
+

An Advisory Board or TAG participant’s seat is vacated when:

+ +

If a participant changes affiliation, + but the participation constraints are met, + that participant’s seat becomes vacant at the next regularly scheduled election for that group.

+

Vacated seats are filled according to this schedule:

+
    +
  • When an appointed TAG seat is vacated, + the Team appoints a replacement. +
  • + When an elected seat on either the AB or TAG is vacated, + the seat is filled at the next regularly scheduled election for the group + unless the group Chair requests that W3C hold an election before then + (for instance, due to the group’s workload). +
      +
    • The group Chair should not request such an election + if the next regularly scheduled election is fewer than three months away. +
    • The group Chair may request an election, + and the election may begin, as soon as a current member gives notice of a resignation, + including a resignation effective as of a given date in the future. +
    +

    When such an election is held, + the minimum number of available seats is such that + when added to the number of continuing participants, + the minimum total number of elected seats is met + (8 for the TAG, 9 for the AB); + and the maximum number corresponds to all unoccupied seats. + Except for the number of available seats and the length of the terms, + the usual rules for Advisory Board and Technical Architecture Group Elections apply.

    +
+

3.4. Chartered Groups: Working Groups and Interest Groups

+

This document defines two types of chartered groups:

+
+
Working Groups. +
+ Working Groups typically produce deliverables + (e.g., Recommendation Track technical reports, + software, + test suites, + and reviews of the deliverables of other groups) + as defined in their charter. +

Working Groups have additional participation requirements + described in the W3C Patent Policy [PATENT-POLICY], + see particularly the “Licensing Obligations of Working Group Participants” + and the patent claim exclusion process + in “Exclusion From W3C RF Licensing Requirements”.

+
Interest Groups. +
+ The primary goal of an Interest Group + is to bring together people who wish to evaluate potential Web technologies and policies. + An Interest Group is a forum for the exchange of ideas. +

Interest Groups do not publish Recommendation Track technical reports; + but can publish technical reports on the Note Track.

+
+

3.4.1. Requirements for All Chartered Groups

+

Each group must have a charter. + Requirements for the charter depend on the group type. + All group charters must be public + (even if other proceedings of the group are Member-only).

+

Each group must have a Chair (or co-Chairs) + to facilitate effective discussion and coordinate the group’s activities. + The Team appoints (and re-appoints) Chairs for all groups. + The Chair is a Member representative, + a Team representative, + or an Invited Expert (invited by the Team). + The requirements of this document that apply to those types of participants apply to Chairs as well.

+

Note: The role of the Chair [CHAIR] is described + in the Art of Consensus [GUIDE].

+

Each group must have a Staff Contact (also known as Team Contact), + who acts as the interface between the Chair, + group participants, + and the rest of the Team.

+

Note: The role of the Staff Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE].

+

The Chair and the Staff Contact of a group should not be the same individual.

+

Each group must have an archived mailing list + for formal group communication + (e.g., for meeting announcements and minutes, + documentation of decisions, + and Formal Objections to decisions). + It is the responsibility of the Chair and Staff Contact to ensure that new participants are subscribed to all relevant mailing lists. + Refer to the list of group mailing lists [GROUP-MAIL].

+

A Chair may form task forces + (composed of group participants) + to carry out assignments for the group. + The scope of these assignments must not exceed the scope of the group’s charter. + A group should document the process it uses + to create task forces + (e.g., each task force might have an informal "charter"). + Task forces do not publish technical reports; + the Working Group may choose to publish their results as part of a technical report.

+

3.4.2. Participation in Chartered Groups

+

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, + and Team representatives (including the Staff Contact).

+

There are four types of individual participants in an Interest Group: + the same three types as for Working Groups plus, + for an Interest Group where the only participation requirement is mailing list subscription, public participants.

+

Except where noted in this document or in a group charter, + all participants share the same rights and responsibilities in a group; + see also the individual participation criteria.

+

A participant may represent more than one organization + in a Working Group or Interest Group. + Those organizations must all be members of the group.

+

An individual may become + a Working or Interest Group participant + at any time during the group’s existence. + See also relevant requirements in + “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY].

+

On an exceptional basis, + a Working or Interest Group participant may designate + a substitute to attend a meeting and should inform the Chair. + The substitute may act on behalf of the participant, + including for votes. + For the substitute to vote, + the participant must inform the Chair in writing in advance.

+

To allow rapid progress, + Working Groups are intended to be small + (typically fewer than 15 people) + and composed of experts in the area defined by the charter. + In principle, + Interest Groups have no limit on the number of participants. + When a Working Group grows too large to be effective, + W3C may split it into an Interest Group + (a discussion forum) + and a much smaller Working Group + (a core group of highly dedicated participants).

+

3.4.3. Types of Participants in Chartered Groups

+
3.4.3.1. Member Representative in a Working Group
+

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Advisory Committee representative of the Member in question + has designated the individual as a Working Group participant, and +
  • the individual qualifies for Member representation. +
+

To designate an individual as a Member representative in a Working Group, + an Advisory Committee representative must provide the Chair and Staff Contact with all of the following information, + in addition to any other information required by the Call for Participation and charter + (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

+
    +
  1. The name of the W3C Member the individual represents + and whether the individual is an employee of that Member organization; +
  2. A statement that the individual accepts the participation terms + set forth in the charter + (with an indication of charter date or version); +
  3. A statement that the Member will provide the necessary financial support for participation + (e.g., for travel, telephone calls, and conferences). +
+

A Member participates in a Working Group from the moment the first Member representative joins the group + until either of the following occurs:

+
    +
  • the group closes, or +
  • the Member resigns from the Working Group; + this is done through the Member’s Advisory Committee representative. +
+
3.4.3.2. Member Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

+ +

To designate an individual as a Member representative in an Interest Group, + the Advisory Committee representative must follow the instructions + in the Call for Participation and charter.

+

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

+
3.4.3.3. Invited Expert in a Working Group
+

The Chair may invite an individual with a particular expertise + to participate in a Working Group. + This individual may represent an organization in the group + (e.g., if acting as a liaison with another organization).

+

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

+
    +
  • the Chair has designated the individual as a group participant, +
  • the Staff Contact has agreed with the Chair’s choice, and +
  • the individual has provided the information required of an Invited Expert to the Chair and Staff Contact. +
+

To designate an individual as an Invited Expert in a Working Group, + the Chair must inform the Staff Contact + and provide rationale for the choice. + When the Chair and the Staff Contact disagree about a designation, + the CEO determines + whether the individual will be invited to participate in the Working Group.

+

To participate in a Working Group as an Invited Expert, + an individual must:

+
    +
  • identify the organization, if any, the individual represents as a participant in this group, +
  • agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT], +
  • accept the participation terms set forth in the charter, + including the participation requirements of + the W3C Patent Policy [PATENT-POLICY], + especially in “Note on Licensing Commitments for Invited Experts” + and in “Disclosure”, + indicating a specific charter date or version, +
  • disclose whether the individual is an employee of a W3C Member; + see the conflict of interest policy, +
  • provide a statement of who will provide the necessary financial support + for the individual’s participation + (e.g., for travel, telephone calls, and conferences), and +
  • if the individual’s employer (including a self-employed individual) + or the organization the individual represents + is not a W3C Member, + indicate whether that organization intends to join W3C. + If the organization does not intend to join W3C, + indicate reasons the individual is aware of for this choice. +
+

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. + The Chair must not use Invited Expert status + to circumvent participation limits imposed by the charter.

+

An Invited Expert participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • the Chair or CEO withdraws the invitation to participate, or +
  • the individual resigns. +
+
3.4.3.4. Invited Expert in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

+
3.4.3.5. Team Representative in a Working Group
+

An individual is a Team representative in a Working Group when so designated by W3C management. + Team representatives both contribute to the technical work + and help ensure the group’s proper integration with the rest of W3C.

+

A Team representative participates in a Working Group + from the moment the individual joins the group + until any of the following occurs:

+
    +
  • the group closes, or +
  • W3C management changes Team representation by sending email to the Chair, + copying the group mailing list. +
+

The Team participates in a Working Group + from the moment the creation of the group is announced + until the group closes.

+
3.4.3.6. Team Representative in an Interest Group
+

When the participation requirements exceed Interest Group mailing list subscription, + an individual is a Team representative in an Interest Group when so designated by W3C management.

+

4. Lifecycle of Chartered Groups

+

W3C creates charters for chartered groups based on W3C community interest. + W3C fosters awareness of charters, + improves their quality, + and gauges Membership support in two formal phases:

+ +

4.1. Initiating Charter Refinement

+

Charters can originate in many venues, + including existing Working or Interest Groups, + Community Groups, + and from the Membership. + Prior to the formal refinement phase, + the Team engages with those various parties + to help prepare charters for broader audiences.

+

Formal charter refinement (see below) is initiated + by the Team sending a charter review notice to the Advisory Committee, + to the public, + and, in the case of rechartering, to the affected Group.

+

This charter review notice must include:

+
    +
  • +

    A short summary of the proposal.

    +
  • +

    The location of the charter draft, which must be public.

    +
  • +

    How to participate in the discussion of this charter draft and where to file issues.

    +
  • +

    The expected duration of the charter refinement phase, +which must not be less than 28 days, +and should not be more than 6 months.

    +
  • +

    Who the Chartering Facilitator is.

    +
+

The Team is responsible for initiating charter refinement at its discretion, in consideration of discussions with the community.

+

An Advisory Committee representative may formally request + that the Team initiate charter refinement. + The Team may deny such a request + if it thinks the proposal is insufficiently mature, + does not align with W3C’s scope and mission, + or otherwise does not meet the charter assessment criteria + described in the Guide (see How to Create a Working Group or Interest Group), + and must reply with its rationale. + This rejection is a Team Decision, + and can be appealed only by 5 or more Members, + through their Advisory Committee representative, + formally objecting to the decision within 8 weeks of the decision being announced. + In this case the Team must start an appeal vote on whether to overturn the Team Decision. + (No action is required to be taken when fewer than 5 members object.)

+

4.2. Charter Refinement

+

During charter refinement, + the W3C community, + under the guidance of the Team, + further develops the charter draft with the goal of achieving consensus on the proposal. + The Chartering Facilitator—​who is chosen (and may be replaced) by the Team—​is responsible for seeking community consensus among those participating in the refinement process + and making decisions reflecting that consensus. + In cases where consensus cannot be found, + the Chartering Facilitator may ask the Team to make a Team Decision, + and must document the rationale for the decision.

+

Note: The Chartering Facilitator is not necessarily the Chair of the group being chartered.

+

During charter refinement:

+ +

Before the end of the announced duration + for the charter refinement phase, + the Team (informed by the work of the Chartering Facilitator) must decide which of the following to do:

+
    +
  • +

    Complete charter refinement by initiating AC Review of the charter draft.

    +
  • +

    Abandon the proposal.

    +
  • +

    Extend the charter refinement period.

    +
+

The Team must announce its decision with the same visibility as the initial charter review notice, + and must include a rationale + if they are not initiating AC Review. + Reaching the end of the announced period (including any announced extension) + with no announced decision + is considered a de-facto Team decision to abandon the proposal. + The Team may revise such a decision + by announcing an alternative decision.

+

Formal Objections filed during the charter refinement phase + are specially handled:

+
    +
  • +

    Objections to decisions pertaining to the content of the charter, +as well as objections to initiating the AC Review, +are considered registered at the close of the Advisory Committee Review of the charter, +and are registered against that W3C Decision.

    +

    Note: This enables all Formal Objections on the same proposed charter to be handled together.

    +
  • +

    Objections to abandoning the proposal or to extending the refinement period can be appealed only if 5 or more Members, +through their Advisory Committee representative, +formally object to the decision within 8 weeks of the decision. +In this case, +the Team must do one of the following:

    +
      +
    • +

      Abide by the objectors' request, if they all agree on the +alternative course of action (e.g., to abandon, +extend, or complete charter refinement).

      +
    • +

      Initiate an AC Review to formally solicit the input of +the community and take a W3C Decision on the subsequent +course of action.

      +
    • +

      Convene a Council to decide the subsequent course of action.

      +
    +

    (No action is required to be taken when fewer than 5 members object.)

    +
  • +

    Any other objections are processed normally (See § 5.6 Addressing Formal Objections).

    +
+

4.3. Content of a Charter

+

A Working Group or Interest Group charter must include all of the following information.

+
    +
  • The group’s mission + (e.g., develop a technology or process, review the work of other groups). +
  • The scope of the group’s work and criteria for success. +
  • The duration of the proposed charter for the group. +
  • The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software). +
  • + Expected milestone dates where available. +

    Note: A charter does not need to include + schedules for review of other group’s deliverables.

    +
  • The process for the group to approve the release of deliverables + (including intermediate results). +
  • Any dependencies by groups within or outside of W3C on the deliverables of this group. + For any dependencies, the charter must specify + the mechanisms for communication about the deliverables. +
  • Any dependencies of this group on other groups within or outside of W3C. + Such dependencies include interactions with W3C Horizontal Groups [CHARTER]. +
  • The level of confidentiality of the group’s proceedings and deliverables. +
  • The name and affiliation of the Chair or co-Chairs. +
  • Meeting mechanisms and expected frequency. +
  • If known, + the date of the first face-to-face meeting. + The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal. +
  • Communication mechanisms to be employed within the group, + between the group and the rest of W3C, + and with the general public. +
  • Any voting procedures or requirements + other than those specified in § 5.2.3 Deciding by Vote. +
  • An estimate of the expected time commitment from participants. +
  • The expected time commitment and level of involvement by the Team + (e.g., to track developments, + write and edit technical reports, + develop code, + or organize pilot experiments). +
  • Intellectual property information. + What are the intellectual property (including patents and copyright) + considerations affecting the success of the Group? + In particular, is there any reason to believe + that it will be difficult to meet the Royalty-Free licensing goals + in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY]? +
+

See also the charter requirements in “Licensing Goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

For every Recommendation Track deliverable + that continues work on a technical report published under any other Charter (including a predecessor group of the same name), + for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

+
    +
  • The title, + stable URL, + and publication date of the Working Draft or other Recommendation-track document + that will serve as the basis for work on the deliverable + (labeled “Adopted Draft”); +
  • The title, + stable URL, + and publication date of the document + that was used as the basis for its most recent Exclusion Opportunity + as per + the W3C Patent Policy [PATENT-POLICY]. + (labeled “Exclusion Draft”); and +
  • The stable URL of the Working Group charter + under which the Exclusion Draft was published + (labeled the “Exclusion Draft Charter”). +
+

All of the above data must be identified + in the adopting Working Group’s charter using the labels indicated.

+

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. + The proposed charter must state + the dates on which the Exclusion Opportunity + that arose on publishing the Exclusion Draft began and ended. + As per “Joining an Already Established Working Group” + in the W3C Patent Policy [PATENT-POLICY], + this potentially means that exclusions can only be made immediately on joining a Working Group.

+

An Interest Group charter may include provisions regarding participation, + including specifying + that the only requirement for participation (by anyone) in + the Interest Group is subscription to the Interest Group mailing list. + This type of Interest Group may have public participants.

+

A charter may include + provisions other than those required by this document. + The charter should highlight + whether additional provisions impose constraints + beyond those of the W3C Process Document + (e.g., limits on the number of individuals in a Working Group + who represent the same Member organization or group of related Members).

+

4.4. Charter Review and Approval

+

4.4.1. New Charters and Major Changes

+

Any new charter (including re-chartering of existing chartered groups) + and any change that is not a minor change (per § 4.4.2 Minor Changes to Active Charters) to an already-approved charter of a Working Group or Interest Group must be approved by a W3C Decision following an AC Review of that charter. + Modifications to a charter should have the consensus of the group.

+

The review period must be at least 28 days. + Any Advisory Committee representative may request an extended review period + in response to the Call for Review; + upon receipt of any such request, + the Team must extend the review period + to at least 60 days.

+

The Call for Review of a modified charter must highlight important changes + (e.g., regarding changes in scope, deliverables, or resource allocation) + and must include rationale for those changes.

+

The Call for Review of a new or modified charter must include a disposition of comments received during the charter refinement process, + highlighting any issues that were closed despite sustained objections.

+

4.4.2. Minor Changes to Active Charters

+

Editorial changes or substantive changes to a charter (including extensions) + that do not affect the scope of the group’s work + or the way the group functions in any significant way + are deemed minor changes and may be approved by a Team Decision, + in which case they do not require charter refinement nor Advisory Committee Review. + Any change to the scope of the charter or addition of a new REC track deliverable + that does not fall within the scope of an existing deliverable + is a major, not minor, change. + The following are examples of minor changes: + the renaming or restructuring (e.g. splitting or combining) of existing in-scope deliverables, + the addition of new Note track deliverables that help explain the group’s work, + a change of Staff Contact, + or a change of Chair. Minor changes, other than a change of Staff Contact, should have the consensus of the group.

+

The Team may nevertheless choose + to initiate charter refinement and/or Advisory Committee Review when it thinks the changes would benefit from more scrutiny or explicit buy-in.

+

Though Advisory Committee Review is not required, + such changes must still be announced + to the Advisory Committee, + and to participants in the Working or Interest Group, + and a rationale must be provided.

+

4.5. Call for Participation in a Chartered Group

+

Deciding whether to adopt a proposed Working Group or Interest Group charter is a W3C Decision. + Charters may be amended based on review comments + per § 5.7.2 Determining the W3C Decision before the Call for Participation.

+

If the decision is to charter the group, + the Team must issue a Call for Participation to the Advisory Committee. + For a new group, this announcement officially creates the group. + The announcement must include a reference to the charter, + the name(s) of the group’s Chair(s), + and the name(s) of the Staff Contact(s).

+

After a Call for Participation, + any Member representatives and Invited Experts must be designated (or re-designated). + When a group is re-chartered, + individuals participating in the Working Group or Interest Group before the new Call for Participation + may attend any meetings held within forty-five (45) days of the Call for Participation + even if they have not yet formally rejoined the group + (i.e., committed to the terms of the charter and patent policy).

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against the decision to create + or substantially modify + a Working Group or Interest Group charter.

+

4.6. Charter Extension

+

The Team may decide + to extend a Working Group or Interest Group charter + with no other substantive modifications. + The Team must announce + such extensions to the Advisory Committee. + The announcement must indicate the new duration. + The announcement must also include rationale for the extension, + a reference to the charter, + and the Group homepage + (which includes at least + the name(s) of the group’s Chair(s), + the name of the Staff Contact, + and instructions for joining the group).

+

After a charter extension, + Advisory Committee representatives + and the Chair are not required to re-designate Member representatives and Invited Experts.

+

Advisory Committee representatives may initiate + an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.

+

4.7. Chartered Group Closure

+

A Working Group or Interest Group charter specifies a duration for the group.

+

The Team, the TAG, or the AB may propose to close a group + prior to the date specified in the charter in any of the following circumstances:

+
    +
  • +

    There are insufficient member resources to produce chartered deliverables +or to maintain the group, +according to priorities established within W3C.

    +
  • +

    A Patent Advisory Group concluded that the work should be terminated.

    +
  • +

    The TAG or AB determined that continuing operation of the chartered group or its work +would be detrimental to W3C or its mission.

    +
  • +

    The group produced all chartered deliverables ahead of schedule.

    +
+

Such a proposal to close a group must be accompanied by rationale, + and the proposal must be confirmed by an AC Review as a W3C Decision.

+

Closing a Working Group has implications + with respect to the W3C Patent Policy [PATENT-POLICY].

+

5. Decisions

+

W3C attempts to resolve issues through dialog. + Individuals who disagree strongly with a decision should register with the Chair any Formal Objections.

+

5.1. Types of Decisions

+

The Chair of a Working Group or Interest Group has the prerogative + to make certain decisions based on their own judgment. + Such decisions are called chair decisions.

+

In contrast, + decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group + or following a vote (see § 5.2.3 Deciding by Vote) + are called group decisions (also known as group “resolutions”).

+

Decisions made by members of the Team in connection with this Process, + based on their own individual or collective judgement, + are called Team Decisions.

+

In contrast, + a W3C decision is + determined by the Team on behalf of the W3C community + by assessing the consensus of the W3C Community after an Advisory Committee review.

+

5.2. Consensus Building

+

5.2.1. Consensus

+

Consensus is a core value of W3C. + To promote consensus, + the W3C process requires Chairs to ensure + that groups consider all legitimate views and objections, + and endeavor to resolve them, + whether these views and objections are expressed by the active participants of the group + or by others + (e.g., another W3C group, + a group in another organization, + or the general public). + Decisions may be made during meetings + (face-to-face or distributed) + as well as through persistent text-based discussions.

+

The following terms are used in this document + to describe the level of support for a decision among a set of eligible individuals:

+
+
Consensus: +
A substantial number of individuals in the set + support the decision + and there is no sustained objection from anybody in the set. + Individuals in the set may abstain. + Abstention is either an explicit expression of no opinion + or silence by an individual in the set. +
Unanimity: +
The particular case of consensus where all individuals in the set support the decision + (i.e., no individual in the set abstains). +
Dissent: +
At least one individual in the set sustains an objection. +
+

Note: A Formal Objection always indicates a sustained objection, + but isn’t necessary to express it + (except in the context of formal AC Reviews). + Disagreement with a proposed decision, + however, does not always rise to the level of sustained objection, + as individuals could be willing to accept a decision + while expressing disagreement.

+

By default, the set of individuals eligible to participate in a decision is the set of group participants. + The Process Document does not require a quorum for decisions + (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). + A charter may include a quorum requirement for consensus decisions.

+

Where unanimity is not possible, + a group should strive to make consensus decisions + where there is significant support and few abstentions. + The Process Document does not require a particular percentage of eligible participants + to agree to a motion in order for a decision to be made. + To avoid decisions where there is widespread apathy, + (i.e., little support and many abstentions), + groups should set minimum thresholds of active support before a decision can be recorded. + The appropriate percentage may vary depending on the size of the group + and the nature of the decision. + A charter may include threshold requirements for consensus decisions. + For instance, a charter might require a supermajority of eligible participants + (i.e., some established percentage above 50%) + to support certain types of consensus decisions.

+
+ Note: Chairs have substantial flexibility + in how they obtain and assess consensus among their groups. + Unless otherwise constrained by charter, + they can use modes including but not limited to explicit calls for consensus, + polls of participants, + “lazy consensus” in which lack of objection after sufficient notice is taken as assent; + they can also delegate and empower a document editor + to assess consensus on their behalf, + whether in general + or for specific pre-determined circumstances + (e.g. in non-controversial situations, for specific types of issues, etc.). +

If questions or disagreements arise, + the final determination of consensus remains with the chair.

+
+

5.2.2. Managing Dissent

+

In some cases, even after careful consideration of all points of view, + a group might find itself unable to reach consensus. + The Chair may record a decision where there is dissent so that the group can make progress + (for example, to produce a deliverable in a timely manner). + Dissenters cannot stop a group’s work + simply by saying that they cannot live with a decision. + When the Chair believes that the Group has duly considered + the legitimate concerns of dissenters as far as is possible and reasonable, + the group should move on.

+

Groups should favor proposals that create the weakest objections. + This is preferred over proposals that are supported by a large majority + but that cause strong objections from a few people. + As part of making a decision where there is dissent, + the Chair is expected to be aware of which participants work for the same + (or related) + Member organizations and weigh their input accordingly.

+

Note: Dissenters can escalate their sustained objection to a decision by registering a Formal Objection.

+

5.2.3. Deciding by Vote

+

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, + and that a vote is necessary to break a deadlock. + In this case the Chair must record + (e.g., in the minutes of the meeting or in an archived email message):

+
    +
  • an explanation of the issue being voted on; +
  • the decision to conduct a vote + (e.g., a simple majority vote) to resolve the issue; +
  • the outcome of the vote; +
  • any Formal Objections. +
+

In order to vote to resolve a substantive issue, + an individual must be a group participant. + Each organization represented in the group must have at most one vote, + even when the organization is represented by several participants in the group + (including Invited Experts). + For the purposes of voting:

+
    +
  • A Member or group of related Members is considered a single organization. +
  • The Team is considered an organization. +
+

Unless the charter states otherwise, Invited Experts may vote.

+

If a participant is unable to attend a vote, + that individual may authorize anyone at the meeting + to act as a proxy. + The absent participant must inform the Chair in writing + who is acting as proxy, with written instructions on the use of the proxy. + For a Working Group or Interest Group, + see the related requirements regarding an individual + who attends a meeting as a substitute for a participant.

+

A group may vote for other purposes than to resolve a substantive issue. + For instance, the Chair often conducts a “straw poll” vote + as a means of determining whether there is consensus about a potential decision.

+

A group may also vote to make a process decision. + For example, + it is appropriate to decide by simple majority + whether to hold a meeting in San Francisco or San Jose + (there’s not much difference geographically). + When simple majority votes are used to decide minor issues, + voters are not required to state the reasons for votes, + and the group is not required to record individual votes.

+

A group charter may include formal voting procedures + (e.g., quorum or threshold requirements) + for making decisions about substantive issues.

+

5.3. Formally Addressing an Issue

+

In the context of this document, + a group has formally addressed an issue when it has sent a public, substantive response + to the reviewer who raised the issue. + A substantive response is expected to include rationale for decisions + (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). + The adequacy of a response is measured + against what a W3C reviewer would generally consider to be technically sound. + If a group believes that a reviewer’s comments result from a misunderstanding, + the group should seek clarification before reaching a decision.

+

As a courtesy, + both Chairs and reviewers should set expectations + for the schedule of responses and acknowledgments. + The group should reply to a reviewer’s initial comments + in a timely manner. + The group should set a time limit + for acknowledgment by a reviewer of the group’s substantive response; + a reviewer cannot block a group’s progress. + It is common for a reviewer to require a week or more + to acknowledge and comment on a substantive response. + The group’s responsibility to respond to reviewers + does not end once a reasonable amount of time has elapsed. + However, reviewers should realize + that their comments will carry less weight + if not sent to the group in a timely manner.

+

Substantive responses should be recorded. + The group should maintain an accurate summary + of all substantive issues and responses to them + (e.g., in the form of an issues list with links to mailing list archives).

+

5.4. Reopening a Decision When Presented With New Information

+

The Chair may reopen a decision + when presented with new information, including:

+
    +
  • additional technical information, +
  • comments by email from participants who were unable to attend a scheduled meeting, +
  • comments by email from meeting attendees + who chose not to speak out during a meeting + (e.g., so they could confer later with colleagues or for cultural reasons). +
+

The Chair should record + that a decision has been reopened, + and must do so upon request from a group participant.

+

5.5. Registering Formal Objections

+

Any individual + (regardless of whether they are associated with a Member) may appeal any decision made in connection with this Process + (except those having a different appeal process) + by registering a Formal Objection with the Team. + Group participants should inform + their Staff Contact as well as the group’s Chair(s). + The Staff Contact must inform the CEO when a group participant has also raised concerns about due process.

+

Note: In this document, the term Formal Objection is used to emphasize this process implication: + Formal Objections receive formal consideration and a formal response. + The word “objection” used alone has its ordinary English connotations. + See § 5.2 Consensus Building.

+

A Formal Objection must include a summary of + the issue (whether technical or procedural), + the decision being appealed, + and the rationale for the objection. + It should cite technical arguments + and propose changes that would remove the Formal Objection; + these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments + or rationale are unlikely to receive serious consideration. + Counter-arguments, + rationales, + and decisions should also be recorded.

+

No later than when the relevant Council is initiated, + a record of each Formal Objection against a decision regarding a publicly-available document must be made publicly available; + likewise, a record of each Formal Objection against a Member-visible decision must be made available to Members. + A Call for Review to the Advisory Committee must identify any Formal Objections related to that review. + These requirements are waived + if the Formal Objection is resolved to the satisfaction of the objector + before its confidentiality is changed.

+

Note: Formal Objections against matter in a technical report are expected to be fully addressed before requesting advancement of the technical report.

+

A Formal Objection filed during an Advisory Committee Review is considered registered at the close of the review period.

+

Registering a Formal Objection initiates the process of addressing the Formal Objection. + The resolution of a recorded Formal Objection—​whether by a Council decision, adoption of a consensus proposal, retraction of the Formal Objection, etc.—​must be recorded and made available at the same level of visibility as the record of the Formal Objection itself.

+

5.6. Addressing Formal Objections

+

5.6.1. Investigation and Mediation by the Team

+

The Team considers the Formal objection, + researches the question, + interviews parties, + and so on, + to make sure the problem and the various viewpoints are well understood, + and to the extent possible, + to arrive at a recommended disposition.

+

In parallel, the Team should start the steps necessary + to convene a Council.

+

If the Team can resolve the issue + to the satisfaction of the individual that filed the Formal Objection, + the individual withdraws the objection and the disposition process terminates.

+

Otherwise, + upon concluding that consensus cannot be found, + and no later than 90 days after the Formal Objection being registered, + the Team must deliver to the Council a report + documenting its findings and attempts to find consensus, + and hand over the matter to the W3C Council.

+

5.6.2. W3C Council

+

A W3C Council is the body convened to resolve Formal Objections by combining the capabilities and perspectives of the AB, the TAG, and the Team, + and is tasked with doing so in the best interests of the Web and W3C.

+
5.6.2.1. Council Composition
+

Each W3C Council is composed of the following members (excepting any renounced or dismissed):

+ +

Participation in a W3C Council must not require attendance of face-to-face meetings.

+

A distinct instance of the W3C Council is convened for each decision being appealed or objected to. + The list of potential Council members evolves + as AB and TAG terms start and end + until dismissal and renunciation are concluded, + at which point the membership of the Council is fixed. + However, if the number of active members in a Council falls so low as to hinder effective and balanced deliberations, + the Council Chair should dissolve the Council and call for a new one to be convened.

+

Note: TAG and AB elections have no effect on the Council’s membership + once it is fixed.

+

A Team member is assigned + to act as the Council Staff Contact, + to support this Council + and to facilitate adherence to this Process.

+
5.6.2.2. Extraordinary Delegation
+

In extraordinary cases, + if they feel a Council would not be the appropriate deciding body, + a member of the Team (particularly the Legal Counsel) or + any potential Council member + may suggest that the decision for that specific Formal Objection be delegated + to the W3C Board of Directors, + to an officer of its corporation (such as the Legal Counsel), + or to one or more specific individuals from the Team. + The potential Council members then may confidentially discuss + and must vote + whether to delegate the decision for that specific Formal Objection. + A decision to delegate must be supported by a two-thirds supermajority vote + (i.e., at least twice as many votes in favor as against). + Delegation in such cases cannot be later revoked.

+

The Team must inform the Advisory Committee when a Formal Objection has been delegated, + and to whom it has been delegated.

+
5.6.2.3. Council Participation, Dismissal, and Renunciation
+

A potential Council member may be dismissed from the Council. + In order to apply consistent criteria, + the potential Council members decide collectively + which reasons against service + rise to a sufficient level for a potential member to be dismissed. + No-one is automatically dismissed, + and individual recusal is not used in the Council. Dismissal applies to an individual person in the context of a specific Council, + and should be used rarely in order to preserve the greatest diversity on the Council.

+

Note: A W3C Council is a deliberative body whose purpose is + to find the best way forward for the Web and for W3C. + It is not a judicial body tasked with determining right or wrong.

+

The Team must draft a list of potential Council members, + with annotations of possible reasons for dismissal against each one. + The W3C community, + including members and team, and potential council members, must be given an opportunity to contribute possible reasons to this list. + Affected members must be given + an opportunity to respond to such comments about themselves. + The Team may report comments verbatim + or may paraphrase them while preserving their intent; + they may also elide inappropriate comments, + such as any that violate applicable laws or the [COC].

+

Before a Council forms, + the Team presents the entire list of potential members + and collected reasons and responses + to the potential Council members, + who then consider for each potential member + whether that individual’s participation + would compromise the integrity of the Council decision, + and vote whether to dismiss that potential member. + No one is allowed to vote on their own dismissal; + each dismissal is enacted if there are at least as many ballots for as against.

+

Note: Since dismissal is individual, + when the decision being objected to was made by the TAG or AB acting as a body, + the entire TAG or AB is not expected to be dismissed.

+

An individual may also renounce their seat on a Council, for strong reason, + such as being forbidden by their employer to serve. The individual chooses the extent to which they explain + their renunciation. + Renunciation is disqualification from participation, + not abstention, + and should not be used + to excuse an absence of participation.

+

Any person who has been dismissed or who renounces their seat + does not receive Council materials, + take part in its deliberations, + help in the determination of consensus, + or vote. + The W3C Council may still solicit and hear their testimony, + as they can of anyone else in the W3C community.

+
5.6.2.4. Short Circuit
+

The full Council process may be short-circuited if + the Team recommends a resolution + and potential members of a Council who are not renouncing their seat + confirm it by a vote which results in both of the following:

+
    +
  • +

    at least 80% of them vote affirmatively to adopt this resolution

    +
  • +

    none of them vote against adopting the resolution

    +
+

The request for confirmation must be open for a period of at least two weeks, + or until every potential member of the Council not renouncing their seat + has voted, + whichever is shortest.

+

This step may be run concurrently with § 5.6.2.3 Council Participation, Dismissal, and Renunciation and prior to choosing a Chair.

+

Note: This is intended for exceptional cases + that don’t seem to warrant a full Council response + because they are, for instance, too trivial, duplicative, etc.

+
5.6.2.5. Council Chairing
+

The Chair of each W3C Council is chosen by its members, + by consensus if possible, + falling back to a vote if that fails. + The chair must be a member of that W3C Council. + Chair selection happens during formation of each Council, + and must be re-run + if requested by the Council Staff Contact or by the Chair during the Council’s operation.

+
5.6.2.6. Convening the Council
+

When dismissal, renunciation, and + appointment of the W3C Council Chair have concluded, + and the Team’s report has been delivered, + the W3C Council is considered to be convened and can start deliberations.

+

If a W3C Council has not yet been convened within 90 days of a Formal Objection + being registered, + the Chairs of the TAG and AB may take independent action to ensure + that the dismissal, renunciation, + and chair selection processes have been run. + If a report from the Team is not delivered within those 90 days, + the Council is considered convened upon selection of the Council Chair.

+
5.6.2.7. Council Deliberations
+

Once convened, + the Council may conduct additional research or analysis, + or request additional information or interviews from anyone, + including the Team.

+

The Council may further attempt to broker consensus on one or more of the formal objections, + which, if successful, would allow them to be resolved.

+

Otherwise, + after sufficient deliberation, + and with due consideration of each argument in the applicable Formal Objections, + the W3C Council decides whether to affirm or overturn the decision being objected to. + The W3C Council may affirm the decision + even if it agrees with some of the arguments made as part of a Formal Objection. + When a decision is affirmed, + all Formal Objections against it are said to be overruled. + Conversely, + aspects of Formal Objections that are found by the Council + to justify overturning a decision + are said to be upheld.

+

When overturning a decision, + the Council should recommend a way forward. + If the overturned decision has already had consequences + pertaining to upheld aspects of the Formal Objection(s) + (e.g., if the objection concerns material already in a published document) + the Council should suggest how these consequences might be mitigated. + The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion; + and the upheld aspects of the Formal Objection(s) (as identified in the Council Report) are not considered fully addressed until then.

+

Note: This does not create new powers for the Team, + such as the ability to “unpublish” documents. + The Team’s role is to ensure the responsible parties enact adequate mitigations, + by whatever means they already have at their disposal.

+

A Council may form sub-groups for deliberation, + who may return with a recommendation, + but the full Council issues the final decision. + The decision of the W3C Council should be unanimous, + and may be issued under consensus. + However, if despite careful deliberation + a W3C Council is unable to reach consensus, + the W3C Council Chair may instead resort to voting. + In that case, + the decision is adopted if there are more ballots for than against; + in case of a tie, + the W3C Council Chair determines the outcome. + However, + if the decision or proposal being objected to + originated with the TAG or AB, + then members of that group at the time the decision or proposal was made + must abstain in such a vote. + In case of a vote, + if two members of a Council who share the same affiliation cast an identical ballot, + then their ballots count as a one vote, + not two.

+

In the case of non-unanimous decisions, + members of a W3C Council who disagree with the Council’s decision may write a Minority Opinion explaining the reason for their disagreement.

+

The deliberations of a W3C Council are confidential to that W3C Council and its Council Staff Contact.

+

Note: This confidentiality requirement is put in place so that + the Council can receive sensitive information in confidence + and to enable Council members to speak freely in their individual expert capacity + without pressure or fear of retaliation + by those involved in the dispute, business relations, their employer, etc.

+

If a W3C Council is unable to come to a conclusion within 45 days of being convened, + the W3C Council Chair must inform the AC of this delay + and of the status of the discussions. + The W3C Council Chair may additionally make this report public.

+
5.6.2.8. Council Decision Report
+

A Council terminates by issuing a Council Report, + which:

+
    +
  • +

    must state whether the Council affirms or overturns the decision being objected to.

    +
  • +

    must provide a rationale supporting its conclusion, +which should address each argument raised in the Formal Objection(s).

    +
  • +

    must include any recommendation decided by the Council.

    +
  • +

    if the decision has been overturned, must identify which aspects of the Formal Objection(s) are being upheld, and should include any suggested mitigations.

    +
  • +

    must include the Minority Opinion(s), if any.

    +
  • +

    must report the names of those who were dismissed or renounced their seat as well as those who were qualified to serve.

    +
  • +

    must report the names of the individuals who participated in the final Council decision.

    +
  • +

    must report the number of votes for/against dismissing each participant.

    +
  • +

    may report vote totals for the Council’s decision, if a formal vote was held.

    +
  • +

    must not attribute any position to any individual on the Council.

    +
+

The Team must maintain a public page on the W3C website indexing all completed Council Reports. + If a Council decision is later overturned by an AC Appeal, + this must also be mentioned. Council Reports must be no more confidential + than the decision or document being objected to.

+

The Council may also issue a Supplemental Confidential Council Report with a more restricted level of confidentiality than its main report + when it believes that additional commentary on confidential aspects of the case + would be informative. + However, the main Council Report should be self-sufficient + and understandable without reference to Supplemental Confidential Council Reports.

+
5.6.2.9. Appealing Council Decisions
+

Advisory Committee representatives may initiate an Advisory Committee Appeal of a Council decision issued in a Council Report.

+

5.7. Advisory Committee Reviews and W3C Decisions

+

The Advisory Committee formally confers its approval + on charters, technical reports, + and other matters + through an Advisory Committee review and its resulting W3C Decision.

+

5.7.1. Initiating an Advisory Committee Review

+

Each Advisory Committee review period + begins with a Call for Review from the Team to the Advisory Committee. + The Call for Review describes the proposal, + raises attention to deadlines, + estimates when the decision will be available, + and includes other practical information. + The Team may share its perspective on the proposal + in the Call for Review. + Each Member organization may send one review, + which must be returned by its Advisory Committee representative.

+

For clarity, + in the context of an AC Review, dissent must be expressed as a Formal Objection.

+

The Team must provide two channels for Advisory Committee review comments:

+
    +
  1. an archived Team-only channel; +
  2. an archived Member-only channel. +
+

The Call for Review must specify + which channel is the default for review comments on that Call.

+

Reviewers may send information + to either or both channels. + A reviewer may also share their own reviews + with other Members on the Advisory Committee discussion list, + and may also make it available to the public.

+

A Member organization may modify its review + during a review period + (e.g., in light of comments from other Members).

+

5.7.2. Determining the W3C Decision

+

After the review period, + the Team determines the appropriate W3C Decision, + which they must announce to the Advisory Committee. + The announcement must indicate + the level of support for the proposal + (consensus or dissent), + and specifically + whether there were any Formal Objections, + with attention to changing the confidentiality level of the Formal Objections.

+

If there were Formal Objections, at least some of which were upheld, + or if there is not consensus because of insufficient support, W3C Decision must be one of:

+
    +
  • The proposal is returned for additional work, + with a request to the initiator to improve the proposal. +
  • The proposal is rejected. +
+

If the proposal has consensus, + or if all Formal Objections are retracted or overruled and the proposal otherwise has sufficient support to achieve consensus, + this W3C Decision must be one of:

+
    +
  • The proposal is adopted, + possibly with additional changes integrated + in order to address the comments of the AC (see below). +
  • The proposal is returned for additional work, + with a request to the initiator to make desirable changes identified during the review + and to resubmit. +
+

If the proposal is adopted with changes other than class 1 (markup) changes, + then those changes must be announced to the AC and to the Group that owns the document (if any). + Additionally, when adopting a proposal with substantive changes integrated, + the announcement must include rationale + for the substantive changes.

+

Substantive changes to the proposal may be adopted + only if the revised proposal has consensus of the subset of the AC that voted on the initial proposal + (including anyone who explicitly abstained), + or if all Formal Objections against the revised proposal are retracted or overruled and the revised proposal otherwise has sufficient support to achieve consensus. + For clarity, + the Team should seek a response from this subset of the AC using the same tooling and degree of formality as it did for the AC Review; + and as is the case during AC Reviews, dissent in this context must be expressed as a Formal Objection.

+

Any Formal Objection raised at this stage against the revised proposal + is handled by the same Council responsible for Formal Objections raised against the initial proposal, + if any.

+

Such a Council has the ability to affirm either the original or the revised proposal for advancement, + thereby overruling all Formal Objections against the original or revised proposal, + respectively.

+

For publications which have conditions in addition to AC approval + for introducing substantive changes (such as Group consensus or implementation experience + or going through a patent Exclusion Opportunity), + those other conditions must also be re-fulfilled.

+
For example, if substantive changes to a technical report are requested when assessing the transition from Candidate Recommendation to Recommendation, + the technical report would need to go through a new Update Request and be republished as a new Candidate Recommendation; + that new version would then need to satisfy the criteria for advancement. + Alternatively, the desired changes can be introduced as non-substantive amendments + using the process for revising a Recommendation. + However, with the exception of the removal of at-risk features, + they cannot be directly integrated between CRS and REC, + because that would fail to trigger a patent exclusion opportunity.
+

For charters, + substantive changes from the initial proposal that underwent AC Review must not include any increase to the scope. + If any such change is desired, + it must be returned for additional work + and go through a complete new AC Review.

+

This document does not specify + time intervals between the end of an Advisory Committee review period + and the W3C decision. + This is to ensure that the Members and Team have sufficient time to consider comments + gathered during the review. + The Advisory Committee should not expect an announcement + sooner than two weeks after the end of a review period. + If, after three weeks, the outcome has not been announced, + the Team should provide the Advisory Committee with an update.

+

5.8. Advisory Committee Votes

+

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, + and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. + Whenever the Advisory Committee votes, + each Member or group of related Members has one vote.

+

5.9. Appeal by Advisory Committee Representatives

+

Advisory Committee representatives may appeal certain decisions, + though appeals are only expected to occur in extraordinary circumstances. + For the purpose of this section, only Advisory Committee representatives of Members in Good Standing are counted.

+

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate + an Advisory Committee Appeal. + These W3C decisions include those related to group creation and modification, + and transitions to new maturity stages for Recommendation Track documents + and the Process document.

+

Advisory Committee representatives may also initiate an appeal + for decisions of a W3C Council, and + for certain decisions that do not involve an Advisory Committee review. + These cases are identified in the sections + which describe the requirements for the decision + and include + additional (non-reviewed) maturity stages of Recommendation Track documents, + group charter extensions and closures, + and technical agreements.

+

In all cases, + an appeal must be initiated within three weeks of the decision.

+

An Advisory Committee representative initiates an appeal by sending a request to the Team, + and should also share this request with the Advisory Committee. + The request should say “I appeal this Decision” + and identify the decision, + and may also include their rationale for appealing the decision.

+

Note: See Appealing a W3C Decision for a recommendation + on how to communicate an appeal request to the Team and the AC.

+

Within one week the Team must announce the appeal process + to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. + The archive of these statements must be member-only. + If, within one week of the Team’s announcement, + 5% or more of the Advisory Committee support the appeal request, + the Team must organize an appeal vote asking the Advisory Committee “Do you approve of the Decision?” + together with links to the decision and the appeal support.

+

The ballot must allow for three possible responses: + “Approve”, + “Reject”, + and “Abstain”, + together with Comments.

+

The level of support needed for an Advisory Committee Appeal to pass + depends on the level of ballot participation + (including explicit “abstain” ballots) + by Advisory Committee Representatives:

+
    +
  • +

    if fewer than 5% participate, +the vote fails.

    +
  • +

    if at least 5% but no more than 15% participate, +and the number of “Approve” ballots exceeds three times (3x) the number of “Reject” ballots, +the vote passes.

    +
  • +

    if more than 15% but fewer than 20% participate, +and the number of “Approve” ballots exceeds twice (2x) the number of “Reject” ballots, +the vote passes.

    +
  • +

    if 20% or more participate, +and the number of “Approve” ballots exceeds the number of “Reject” ballots, +the vote passes.

    +
+

If the vote passes, + the decision is overturned. + Following such rejection, + those who had initiated the proposal may revise it + to address the causes of rejection + and follow the ordinary applicable process + to submit the revised proposal.

+

6. W3C Technical Reports

+

The W3C technical report development process is the set of steps and requirements + followed by W3C Working Groups to standardize Web technology. + The W3C technical report development process is designed to:

+
    +
  • support multiple specification development methodologies +
  • maximize consensus about the content of stable technical reports +
  • ensure high technical and editorial quality +
  • promote consistency among specifications +
  • facilitate royalty-free, interoperable implementations of Web Standards, and +
  • earn endorsement by W3C and the broader community. +
+

See also “licensing goals for W3C Specifications” + in the W3C Patent Policy [PATENT-POLICY].

+

6.1. Types of Technical Reports

+

This chapter describes the formal requirements + for publishing and maintaining a W3C Recommendation, Note, + or Registry.

+
+
Recommendations +
Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines + as standards for the Web. + The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, + and consensus-building, + and is subject to the W3C Patent Policy [PATENT-POLICY], + under which participants commit to Royalty-Free IPR licenses for implementations. + See § 6.3 The W3C Recommendation Track for details. +
Notes +
Groups can also publish documents as Group Notes and W3C Statements, + typically either to document information + other than technical specifications, + such as use cases motivating a specification + and best practices for its use. + See § 6.4 The Note Track (Notes and Statements) for details. +
Registries +
Chartered and elected groups can also publish registries in order to document collections of values or other data. + A registry can be published either as a distinct registry report, + or directly within a Recommendation Track document + as an embedded registry. Defining a registry requires wide review and consensus, + but once set up, changes to registry entries are lightweight + and can even be done without the initiating group’s involvement. + See § 6.5 The Registry Track for details. +
+

Individual Working Groups and Interest Groups should adopt additional processes + for developing publications, + so long as they do not conflict with the requirements in this chapter.

+

6.2. General Requirements for Technical Reports

+

6.2.1. Publication of Technical Reports

+

Publishing as used in this document + refers to producing a version which is listed as a W3C Technical Report on its Technical Reports index at https://www.w3.org/TR [TR]. + Every document published as part of the technical report development process must be a public document. + W3C strives to make archival documents indefinitely available + at their original address in their original form.

+

Every document published as part of the technical report development process must clearly indicate its maturity stage, + and must include information about the status of the document. + This status information:

+
    +
  • must be unique each time a specification is published, +
  • must state which Working Group developed the specification, +
  • must state how to send comments or file bugs, + and where these are recorded, +
  • must include expectations about next steps, +
  • should explain how the technology relates to existing international standards + and related work inside or outside W3C, + and +
  • should explain + or link to + an explanation of significant changes from the previous version. +
+

Every Technical Report published + as part of the Technical Report development process + is edited by one or more editors + appointed by a Group Chair. + It is the responsibility of these editors to ensure that the decisions of the Group are + correctly reflected in subsequent drafts of the technical report. + An editor must be a participant, + per § 3.4.2 Participation in Chartered Groups in the Group responsible for the document(s) they are editing.

+

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, + status information, + style, + and copyright requirements). + These rules are subject to change by the Team from time to time. + The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

+

The primary language for W3C Technical Reports is English. + W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C website.

+

6.2.2. Reviews and Review Responsibilities

+

A document is available for review + from the moment it is first published. + Working Groups should formally address any substantive review comment + about a technical report in a timely manner.

+

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, + particularly if this would cause significant compatibility problems + due to existing implementation. Working Groups should record substantive + or interesting proposals raised by reviews + but not incorporated into a current specification.

+
6.2.2.1. Wide Review
+

The requirements for wide review are not precisely defined by the W3C Process. + The objective is to ensure that the entire set of stakeholders of the Web community, + including the general public, + have had adequate notice of the progress of the Working Group and were able to actually perform reviews of and provide comments on the specification. + A second objective is to encourage groups to request reviews + early enough that comments and suggested changes + can still be reasonably incorporated in response to the review. + Before approving transitions, + the Team will consider who has been explicitly offered + a reasonable opportunity to review the document, + who has provided comments, + the record of requests to and responses from reviewers, + especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter + or identified as liaisons [LIAISON], + and seek evidence of clear communication to the general public + about appropriate times and which content to review + and whether such reviews actually occurred.

+

Note: The Team documents best practices for wide review in the Guidebook. [GUIDE]

+

For example, + inviting review of new or significantly revised sections published in Working Drafts, + and tracking those comments + and the Working Group’s responses, + is generally a good practice which would often be considered positive evidence of wide review. Working Groups should follow the W3C Horizontal Groups’ review processes, + and should announce to other W3C Working Groups + as well as the general public, + especially those affected by this specification, + a proposal to enter Candidate Recommendation (for example in approximately 28 days). + By contrast a generic statement in a document + requesting review at any time + is likely not to be considered as sufficient evidence + that the group has solicited wide review.

+

A Working Group could present evidence that wide review has been received, + irrespective of solicitation. + But it is important to note that receiving many detailed reviews + is not necessarily the same as wide review, + since they might only represent comment + from a small segment of the relevant stakeholder community.

+

6.2.3. Classes of Changes

+

This document distinguishes the following 5 classes of changes to a document. + The first two classes of change are considered editorial changes, + the next two substantive changes, + and the last one registry changes.

+
+
+ +
    +
  1. +

    No changes to text content

    +
+
These changes include fixing broken links, style sheets, or invalid markup. +
+ +
    +
  1. +

    Changes that do not functionally affect interpretation of the document

    +
+
For Recommendation-track technical reports specifically, + this constitutes changes that do not affect conformance, + i.e. changes that reasonable implementers + would not interpret as changing architectural + or interoperability requirements + or their implementation. + Changes which resolve ambiguities in the specification + are considered to change (by clarification) the implementation requirements + and do not fall into this class. +
Examples of changes in this class include + correcting non-normative examples + which clearly conflict with normative requirements, + clarifying various other non-normative text, + fixing typos or grammatical errors + where the change does not change requirements. +
If there is any doubt or disagreement + as to whether a change functionally affects interpretation, + that change does not fall into this class. +
+ +
    +
  1. +

    Other changes that do not add new features

    +
+
+ For Recommendation-track documents, + these changes may affect conformance to the specification. + A change that affects conformance is one that: +
    +
  • makes conforming data, processors, or other conforming agents become non-conforming according to the new version, + or +
  • makes non-conforming data, processors, or other agents become conforming, + or +
  • clears up an ambiguity or under-specified part of the specification + in such a way that data, + a processor, + or an agent + whose conformance was once unclear + becomes clearly either conforming or non-conforming. +
+
+ +
    +
  1. +

    New features

    +
+
Changes that add new functionality, + such as new elements, new APIs, new rules, etc. +
+ +
    +
  1. +

    Changes to the contents of a registry table

    +
+
Changes that add, remove, or alter registry entries in a registry table. +
+

6.2.4. Errata Management

+

Tracking errors is an important part of a Working Group’s ongoing care of a technical report; + for this reason, + the scope of a Working Group charter generally allows time + for work after publication of a Recommendation. + In this Process Document, + the term “erratum” + (plural “errata”) refers to any error + that can be resolved by one or more changes in classes 1-3 + of section § 6.2.3 Classes of Changes.

+

Working Groups must keep + a public record of errors + that are reported by readers and implementers + for Recommendations. + Such error reports should be compiled + no less frequently than quarterly.

+

Working Groups decide how to document errata. + Such documentation must identify + the affected technical report text + and describe the error; + it may also describe some possible solution(s). + Readers of the technical report should be able easily + to find and see the errata + that apply to that specific technical report with their associated tests. + Errata may be documented + in a separate errata page or tracking system. + They may, + in addition or alternatively, + be annotated inline + alongside the affected technical report text + or at the start or end of the most relevant section(s).

+

6.2.5. Candidate Amendments

+

An erratum may be accompanied by a non-normative, candidate correction approved by group decision. + When annotated inline, + errata—​including their candidate corrections—​must be marked as such, + are treated as class 2 changes, + and are published accordingly.

+

Note: Annotating changes in this way allows more mature documents + such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, + even when the candidate amendments have not yet received + sufficient review or implementation experience + to be normatively incorporated into the specification proper.

+

A candidate addition is similar to a candidate correction, + except that it proposes a new feature + rather than an error correction.

+

Candidate corrections and candidate additions are collectively known as candidate amendments.

+

In addition to their actual maturity stage, published REC Track documents with candidate amendments are also considered, + for the purpose of the W3C Patent Policy [PATENT-POLICY], + to be Working Drafts with those candidate amendments treated as normative.

+

6.2.6. Maintenance Without a Group

+

For all types of technical reports and all maturity stages, + if there is no group chartered to maintain a technical report, + the Team may republish it + at the same maturity stage, + integrating as needed:

+
    +
  1. class 1 changes; +
  2. inline errata; +
  3. candidate corrections, + which must be marked as Team correction; +
  4. class 2 changes other than inline errata and Team corrections. +
+

To avoid any potential doubt or disagreement + about whether changes really do fall into class 2, + the Team should be conservative, + limiting itself to obvious and limited fixes, + and must avoid substantial rephrasing, + even of non-normative examples and notes. + If any such change is desired, + the Team must mark it as a Team correction.

+

Team corrections do not constitute + a normative portion of the Recommendation, + as defined in the Patent Policy [PATENT-POLICY] (i.e., they are not covered by the Patent Policy). + For Candidate Recommendations, W3C Recommendations, Candidate Registries, W3C Registries, + as well as W3C Statements, + the Team must solicit wide review on Team corrections that it produces.

+

6.2.7. License Grants from Non-Participants

+

When a party who is not already obligated under the Patent Policy + offers a change in class 3 or 4 + (as described in § 6.2.3 Classes of Changes) to a technical report under this process + the Team must request + a recorded royalty-free patent commitment; + for a change in class 4, the Team must secure such commitment. + Such commitment should cover, + at a minimum, + all the party’s Essential Claims both in the contribution, + and that become Essential Claims as a result of incorporating the contribution into the draft + that existed at the time of the contribution, + on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

+

6.3. The W3C Recommendation Track

+

Working Groups create specifications and guidelines + to complete the scope of work envisioned by a Working Group’s charter. + These technical reports undergo cycles of revision and review + as they advance towards W3C Recommendation status. + Once review suggests the Working Group has met their requirements for a new standard, + including wide review, + a Candidate Recommendation phase + allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. + At the end of the process, + the Advisory Committee reviews the mature technical report, + and if there is support from its Membership, + W3C publishes it as a Recommendation.

+

In summary, the main steps of the W3C Recommendation Track are:

+
    +
  1. Publication of the First Public Working Draft. +
  2. Publication of zero or more revised Working Drafts. +
  3. Publication of one or more Candidate Recommendations. +
  4. Publication as a W3C Recommendation. +
+
+ + Basic W3C Recommendation Track + + + + + First Public Working Draft (FPWD) - Exclusion opportunity + + + + WG Decision + + Team Approval + + + + + + + + + Working Draft (WD) + + + + + + + + Publish a new Working Draft + + + WG Decision + + + + + + + + + Advance to Candidate Recommendation + + WG Decision + + Team Approval + + + + + + + + + + Candidate Recommendation Snapshot (CRS) - Patent Policy exclusion opportunity + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG + Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + Team Approval + + + + + + + + Advance to Recommendation + + WG Decision + + Team Approval + + AC Review + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision with AB+TAG Approval) + + + + + + + + + + + Candidate Recommendation Draft (CRD) + + + + + + + + Publish revised Candidate Recommendation Draft + + + WG Decision + + + + + + + + + Publish revised Candidate Recommendation Snapshot + + + WG Decision + + Team Approval + + + + + + + + + + + Recommendation + + + + + + + + Return to Candidate Recommendation Snapshot + + + WG Decision + (or Team Decision + with AB+TAG + Approval) + + + + + + + + + Return to Working Draft + + + WG Decision + (or Team Decision + with AB+TAG + Approval) + + + + + + + + + Publish revised Recommendation with editorial changes + + + WG Decision + (editorial) + + + + + + + + + Publish revised Recommendation with substantive changes + + + WG Decision + + Team Approval + + AC Review + (substantive) + + + + + + + + + +
Non-Normative Summary of the Recommendation Track
+
+

Only sufficiently technically mature work should be advanced. + As described in § 6.3.3 Advancement on the Recommendation Track, + the Team will decline a request to advance in maturity stage + and return the specification to a Working Group for further work + if it determines that the requirements for advancement + have not been met.

+

Note: Should faster advancement to meet scheduling considerations be desired, + this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring + less stable features to other technical reports.

+

W3C may end work on a technical report at any time.

+

6.3.1. Maturity Stages on the Recommendation Track

+

A W3C Recommendation Track document is any document whose current status is one of those described in this section.

+
+
Working Draft (WD) +
+ A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, + and other technical organizations, + and for simple historical reference. + Some, but not all, Working Drafts are meant to advance to Recommendation; + see the document status section of a Working Draft + for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, + and do not imply any endorsement by W3C + or its members beyond agreement to work on a general area of technology. + Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. + A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity. +

For all Working Drafts a Working Group:

+
    +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, + and +
  • may request publication of a Working Draft + even if its content is considered unstable + and does not meet all Working Group requirements. +
+

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), + and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

+
Candidate Recommendation (CR) +
+ A Candidate Recommendation is a document that satisfies the technical + requirements of the Working Group that produced it and their dependencies, + and has already received wide review. + W3C publishes a Candidate Recommendation to + +

Note: Advancing to Candidate Recommendation indicates + that the document is considered complete and fit for purpose, + and that no further refinement to the text is expected + without additional implementation experience and testing; + however, additional features might be expected in a later revision. + A Candidate Recommendation is expected to be as well-written, + detailed, + self-consistent, + and technically complete + as a Recommendation, + and acceptable as such + if and when the requirements for further advancement are met.

+

Candidate Recommendation publications take one of two forms:

+
+
Candidate Recommendation Snapshot (CRS) +
+ A Candidate Recommendation Snapshot + corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. + Publishing a Patent Review Draft triggers a Call for Exclusions, + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy. +

Publication as a Candidate Recommendation Snapshot requires verification of either a Transition Request (for the first Candidate Recommendation publication from another maturity stage) + or an Update Request (for subsequent Candidate Recommendation Snapshots).

+
Candidate Recommendation Draft (CRD) +
+ A Candidate Recommendation Draft + is published + to solicit review of intended changes from the previous Candidate Recommendation Snapshot. + This allows for wider review of the changes + and for ease of reference to the integrated specification. +

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot. + However, the process requirements are minimized + so that the Working Group can easily keep the specification up to date.

+

A Candidate Recommendation Draft does not provide an exclusion opportunity; + instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

+
+

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered + such that W3C cannot endorse it or continue work on it, + for example due to burdensome patent claims that affect implementers and cannot be resolved + (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). + There is no path to restoration for a Rescinded Candidate Recommendation. + See “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

+
W3C Recommendation (REC) +
+ A W3C Recommendation is a specification + or set of guidelines + or requirements that, + after extensive consensus-building, + has received the endorsement of W3C and its Members. + W3C recommends the wide deployment + of its Recommendations as standards for the Web. + The W3C Royalty-Free IPR licenses + granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. +

After its initial publication, + a W3C Recommendation may be revised + (in accordance with § 6.3.10 Revising a W3C Recommendation) + to address editorial or substantive issues + that are discovered later. + However, new features can only be added + if the document already identifies itself + as intending to allow new features. + Adding or removing this allowance is a substantive change. + Such an allowance cannot be added + to a technical report previously published as a Recommendation that did not allow such changes; + this requires a new technical report (which could, for example, be similarly named but with an incremented version number).

+

As technology evolves, + a W3C Recommendation may become:

+
+
A Superseded Recommendation +
+ A Superseded Recommendation is a specification + that has been replaced by a newer version + that W3C recommends for new adoption. + An Obsolete or Superseded specification + has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy. +

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, + the latest version replaces the previous one, + without the need to invoke the steps of § 6.3.12.3 Abandoning a W3C Recommendation: + it is the same document, updated. + Explicitly declaring a documented superseded, using the process documented in § 6.3.12.3 Abandoning a W3C Recommendation, + is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

+
An Obsolete Recommendation +
An Obsolete Recommendation is a specification + that W3C has determined lacks sufficient market relevance + to continue recommending it for implementation, + but which does not have fundamental problems + that would require it to be Rescinded. + If an Obsolete specification gains sufficient market relevance, + W3C may decide to restore it to Recommendation status. +
Rescinded Recommendation +
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, + and believes is unlikely to ever be restored to Recommendation status. + See also “W3C Royalty-Free (RF) Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY]. +
+
Discontinued Draft +
A technical report representing the state of a Recommendation-track document + at the point at which work on it was discontinued. + See § 6.3.12.1 Abandoning an Unfinished Recommendation. +
+

This Process defines certain Recommendation Track publications as Patent Review Drafts. + Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004], + these correspond to “Last Call Working Draft” in the Patent Policy; + Starting from the 2020 Patent Policy [PATENT-POLICY-2020], + these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

+

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, + and do not necessarily imply consensus of a Working Group or Interest Group, + nor are their contents endorsed in any way by W3C.

+

When publishing an updated version of an existing Candidate Recommendation or Recommendation, + technical reports are expected to meet the same maturity criteria as when they are first published under that status. + However, in the interest of replacing stale documents with improved ones in a timely manner, + if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, + it is also permissible to publish an updated CR or REC following the usual process, + even if only some of these flaws have been satisfactorily addressed.

+

6.3.2. Implementation Experience

+

Implementation experience is required to show that a specification is sufficiently clear, + complete, + and relevant to market needs, + to ensure that independent interoperable implementations + of each feature of the specification will be realized. + While no exhaustive list of requirements is provided here, + when assessing that there is adequate implementation experience the Team will consider (though not be limited to):

+
    +
  • is each feature of the current specification implemented, + and how is this demonstrated? +
  • are there independent interoperable implementations of the current specification? +
  • are there implementations created by people other than the authors of the specification? +
  • are implementations publicly deployed? +
  • is there implementation experience + at all levels of the specification’s ecosystem + (authoring, consuming, publishing…)? +
  • are there reports of difficulties or problems with implementation? +
+

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. + Groups are often able to work more effectively + if they plan how they will demonstrate interoperable implementations + early in the development process; + for example, developing tests in concert with implementation efforts.

+

6.3.3. Advancement on the Recommendation Track

+

For all requests to advance a specification + to a new maturity stage + (called Transition Requests), + the Working Group:

+
    +
  • must record the group’s decision to request advancement. +
  • must obtain Team verification. Team verification (a Team decision) must be withheld if any Process requirements are not met + or if there remain any unresolved Formal Objections + (including any aspect upheld by a Council but not yet fully addressed), + or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). + If the Team rejects a Transition Request it must indicate its rationale + to the Advisory Committee and the Working Group. +
  • must publicly document all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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 stage. +
  • must provide public documentation of any Formal Objections. +
  • should report which, if any, of the Working Group’s requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

For a First Public Working Draft there is no “previous maturity stage”, + so many requirements do not apply, + and verification is normally fairly straightforward. + For later stages, + especially transitions to Candidate or Recommendation, + there is usually a formal review meeting + to verify that the requirements have been met.

+

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved + while a Working Group’s charter is undergoing or awaiting a decision + on an Advisory Committee Review.

+

6.3.4. Updating Mature Publications on the Recommendation Track

+

Certain requests to re-publish a specification + within its current maturity stage + (called Update Requests) + require extra verification. + For such update requests, the Working Group:

+
    +
  • must record the group’s decision to request the update. +
  • must show that the changes have received wide review. +
  • + must obtain Team verification. Team verification (a Team decision): +
      +
    • +

      should be withheld +if any Process requirements are not met,

      +
    • +

      may be withheld +in consideration of unresolved Formal Objections +(including any aspect upheld by a Council but not yet fully addressed),

      +
    • +

      may be withheld +if the document does not adequately reflect +all relevant decisions of a W3C Council (or its delegates),

      +
    • +

      may be withheld +if the Team believes the Group is not making reasonable progress +on addressing issues raised by individuals external to the Group.

      +
    +

    If the Team rejects an Update Request, + it must indicate its rationale to the Working Group. + If it waives any Process requirements, + it must indicate its rationale to the AC.

    +
  • must provide public documentation of any Formal Objections. +
  • must publicly document of all new features + (class 4 changes) to the technical report + since the previous publication. +
  • must publicly document if other substantive changes + (class 3 changes) have been made, + and should document the details of such changes. +
  • 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, + or explain why the requirements have changed or been deferred, +
  • should report which, if any, of the Working Group’s requirements + for this document have changed since the previous step. +
  • should report any changes in dependencies with other groups. +
  • should provide information about implementations known to the Working Group. +
+

There is usually a formal review meeting + to verify that the requirements have been met.

+

Note: Update request verification is expected to be fairly simple + compared to verification of a transition request.

+

The Team must announce the publication + of the revised specification + to other W3C groups and the Public.

+

6.3.5. Publishing a First Public Working Draft

+

To publish the First Public Working Draft of a document, + a Working Group must meet the applicable requirements for advancement.

+

The Team must announce + the publication of a First Public Working Draft to other W3C groups and to the public.

+

6.3.6. Revising a Working Draft

+

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.

+

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

+
    +
  • must record the group’s decision to request publication. Consensus is not required, + as this is a procedural step, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Working Draft, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous step, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups, +
+

Possible next steps for any Working Draft:

+ +

6.3.7. Transitioning to Candidate Recommendation

+

To publish a Candidate Recommendation, + in addition to meeting the requirements for advancement a Working Group:

+
    +
  • must show that the specification + has met all Working Group requirements, + or explain why the requirements have changed or been deferred, +
  • must document changes to dependencies during the development of the specification, +
  • must document + how adequate implementation experience will be demonstrated, +
  • must specify the deadline for comments, + delineating the Candidate Recommendation review period, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • must show that the specification has received wide review, and +
  • may identify features in the document as at risk. + These features may be removed + before advancement to Recommendation without requiring an Update Request. +
+

The first Candidate Recommendation publication + after verification of having met the requirements for a Transition Request is always a Candidate Recommendation Snapshot. + The Team must announce + the publication of the Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

Possible next steps after a Candidate Recommendation Snapshot:

+ +

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

6.3.8. Revising a Candidate Recommendation

+
6.3.8.1. Publishing a Candidate Recommendation Snapshot
+

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, + the Working Group must meet the requirements of an update request in order to republish.

+

In addition the Working Group:

+
    +
  • must specify the deadline for further comments, + which must be at least 28 days after publication, + and should be longer for complex documents, +
  • may identify features in the document as at risk. + These features may be removed + before advancement to Recommendation without requiring an Update Request. +
+

The Team must announce + the publication of a revised Candidate Recommendation Snapshot to other W3C groups + and to the public.

+

To provide timely updates and patent protection, + a Candidate Recommendation Snapshot should be published + within 24 months of the Working Group accepting + any proposal for a substantive change + (and preferably sooner). + To make scheduling reviews easier, + a Candidate Recommendation Snapshot should not be published + more often than approximately once every 6 months.

+

Note: Substantive changes trigger a new Exclusion Opportunity + per “Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.8.2. Publishing a Candidate Recommendation Draft
+

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 + that would benefit from review beyond the Working Group.

+

To publish a revision of a Candidate Recommendation Draft, + a Working Group:

+
    +
  • must record the group’s decision to request publication, +
  • must provide public documentation + of substantive changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should provide public documentation + of significant editorial changes to the technical report + since the previous Candidate Recommendation Snapshot, +
  • should document outstanding issues, + and parts of the document on which the Working Group does not have consensus, +
  • should report which, + if any, + of the Working Group’s requirements for this document + have changed since the previous step, +
  • should report any changes in dependencies with other groups. +
+

Note: A Working Group does not need to + meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

+

Possible next steps after a Candidate Recommendation Draft:

+ +

6.3.9. Transitioning to Recommendation

+

When a Working Group estimates + that a Candidate Recommendation has fulfilled all the relevant criteria, + it may decide to request advancement to W3C Recommendation.

+
6.3.9.1. Requirements for Transition
+

In addition to meeting the requirements for advancement, + the Working Group:

+ +

Additionally, + if the document has previously been published as a W3C Recommendation, the Working Group must not include any class 4 change to that publication + unless it was explicitly marked as allowing new features, + and must not include any such marking + if not already present.

+

If the document’s most recent publication is a Candidate Recommendation Draft, + the Team must verify + that it contains no changes since the previous Candidate Recommendation Snapshot other than:

+ +

Otherwise, the Working Group must republish it + as a Candidate Recommendation Snapshot prior to initiating the review.

+
6.3.9.2. Initiating Review
+

If all the criteria above are fulfilled, + the Team must begin an Advisory Committee Review on the question of whether the identified Candidate Recommendation is appropriate to publish as a W3C Recommendation. + The deadline for Advisory Committee review must allow at least 28 days, + and must end at least 10 days + after the end of the last Exclusion Opportunity + per ”Exclusion From W3C RF Licensing Requirements” + in the W3C Patent Policy [PATENT-POLICY].

+
6.3.9.3. Resolution of Review
+

If there was any Formal Objection during the Advisory Committee Review, + the Team must publish the substantive content of the dissent to W3C and the general public, + and the W3C Recommendation must not be published + unless all Formal Objections to the document have been retracted or overruled and at least 14 days have elapsed since the publication of the corresponding Council Report.

+

The decision to advance a document to Recommendation is a W3C Decision. + The Team must announce the publication of a W3C Recommendation to the Advisory Committee, + to other W3C groups + and to the public. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

+

The newly published Recommendation must not make any substantive changes to the document + compared to the Candidate Recommendation Snapshot submitted for AC Review, + other than dropping features identified at risk.

+
6.3.9.4. Next Steps from W3C Recommendation
+

Possible next steps: + A W3C Recommendation normally retains its status indefinitely. + However it may be:

+ +

6.3.10. Revising a W3C Recommendation

+
6.3.10.1. Revising a Recommendation: Editorial Changes
+

Editorial changes to a Recommendation require no technical review of the intended changes. + A Working Group, + provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity stages. + (See class 1 and class 2 changes.)

+
6.3.10.2. Revising a Recommendation: Substantive Changes
+

Tentative corrections (see class 3 changes) may be annotated into a Recommendation using candidate corrections.

+

Note: Candidate corrections do not normatively modify the document; + they editorially indicate how one might do so. + They are therefore published following the provisions of § 6.3.10.1 Revising a Recommendation: Editorial Changes.

+

A candidate correction can be made normative + and be folded into the main text of the Recommendation, + once it has satisfied all the same criteria + as the rest of the Recommendation, + including review by the community to ensure + its technical and editorial soundness. + To validate this, the Working Group must request + a Last Call for Review of Proposed Amendments, + followed by an update request. + See § 6.3.10.4 Incorporating Candidate Amendments.

+

Alternatively, + a Working Group may incorporate the changes + and publish as a Working Draft—​or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—​and advance the specification from that state. + (See class 3 changes.)

+
6.3.10.3. Revising a Recommendation: New Features
+

For Recommendations explicitly identified as allowing new features, + tentative new features (see class 4 changes) may be added as candidate additions in annotations, + and class 4 changes may be normatively incorporated + in the same fashion as class 3 changes in § 6.3.10.2 Revising a Recommendation: Substantive Changes.

+

Note: Limiting the addition of new features to Recommendations that explicitly allow them + enables third parties to depend on a stable feature-set for Recommendations that do not advertise that ability, + as was the case for all Recommendations prior to the 2020 revision of this Process.

+

Note: When a Recommendation does not allow new features, + new features can be added by creating a new technical report and following the full process of advancing that technical report to Recommendation—​beginning with a new First Public Working Draft. + Such technical reports could be written to represent + additional modules building on top of the original Recommendation of the core technology, + or an expanded replacement of the original Recommendation of the core technology + (in which case the new technical report will typically have the same name as the original, + with an incremented version number).

+
6.3.10.4. Incorporating Candidate Amendments
+

A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.

+

The Last Call for Review of Proposed Amendments must be announced to other W3C groups, the public, and the Advisory Committee. + The announcement must:

+
    +
  • Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, + or Last Call for Review of Proposed Corrections and Additions. +
  • Identify the specific candidate amendments under review + as proposed amendments (proposed corrections/proposed additions). +
  • Specify the deadline for review comments, + which must not be any sooner than 60 days from the Call for Review. +
  • Solicit review and, if it does not already have it, implementation experience. +
+

The combination of the existing Recommendation with the proposed amendments included in the Last Call for Review of Proposed Amendments is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. + Also, the review initiated by the Last Call for Review of Proposed Amendments is an Advisory Committee Review.

+

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

+

A Working Group may batch + multiple proposed amendments into a single Last Call for Review of Proposed Amendments. + To facilitate review, + a Last Call for Review of Proposed Amendments on a given specification should not be issued more frequently + than approximately once every 6 months.

+

At the end of the Last Call for Review of Proposed Amendments, + the W3C Decision may either be + to reject the proposed amendment, + or to clear the proposed amendment for advancement as is, + or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. + If the Working Group needs to amend a proposed amendment in response to review feedback + it must issue another Last Call for Review of Proposed Amendments on the revised change + before it can be incorporated into the main text.

+

Once all comments on a proposed amendment have been formally addressed, + and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, + it may incorporate the proposed amendment into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

+

To ensure adequate review of proposed amendment combinations, + only proposed amendments included in the most recent Last Call for Review of Proposed Amendments can be incorporated into the normative Recommendation text. + (Thus if incorporation of a proposed amendment is postponed, + it may need to be included in multiple Last Calls for Review of Proposed Amendments.)

+

6.3.11. Regression on the Recommendation Track

+

A Working Group may republish a Recommendation-track technical report at a lower maturity stage by fulfilling the requirements to transition to that maturity stage, + as described above.

+

Additionally, + with the approvals (by group decision) of each of the TAG and the AB the Team may return + the technical report to a lower maturity stage in response to wide review or a formal objection.

+

6.3.12. Retiring Recommendation Track Documents

+

Work on a technical report may cease at any time. + Work should cease + if W3C or a Working Group determines + that it cannot productively carry the work any further.

+
6.3.12.1. Abandoning an Unfinished Recommendation
+

Any Recommendation-track technical report no longer intended + to advance or to be maintained, + and that is not being rescinded, should be published as a Discontinued Draft, + with no substantive change compared to the previous publication. + This can happen if + the Working Group decided + to abandon work on the report, + or as the result of an AC Review requiring the Working Group to discontinue work on the technical report before completion. + If a Working Group is made to close, + W3C must re-publish any unfinished technical report on the Recommendation track as Discontinued Draft.

+

Such a document should include in its status section + an explanation of why it was discontinued.

+

A Working Group may resume work + on such a technical report within the scope of its charter + at any time, + by re-publishing it as a Working Draft.

+
6.3.12.2. Rescinding a Candidate Recommendation
+

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

+
6.3.12.3. Abandoning a W3C Recommendation
+

It is possible that W3C decides + that implementing a particular Recommendation is no longer recommended. + There are three designations for such specifications, + chosen depending on the advice W3C wishes to give about further use of the specification.

+

W3C may obsolete a Recommendation, + for example if the W3C Community decides that the Recommendation no longer represents best practices, + or is not adopted and is not apparently likely to be adopted. + An Obsolete Recommendation may be restored to normal Recommendation, + for example because despite marking it Obsolete the specification is later more broadly adopted.

+

W3C may declare a Recommendation Superseded + if a newer version exists which W3C recommends for new adoption. + The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; + only the name and explanation change.

+

W3C may rescind a Recommendation + if W3C believes there is no reasonable prospect of it being restored + for example due to burdensome patent claims that affect implementers and cannot be resolved; + see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” + and “PAG Conclusion”.

+

W3C only rescinds, supersedes, or obsoletes entire Recommendations. + A Recommendation can be both superseded and obsolete. + To rescind, supersede, or obsolete some part of a Recommendation, + W3C follows the process for modifying a Recommendation.

+

Note: For the purposes of the W3C Patent Policy, [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, + although it is not advised for future implementation; + a Rescinded Recommendation ceases to be in effect + and no new licenses are granted under the Patent Policy.

+
+ + Supersede, Obsolete or Rescind a W3C Recommendation + + + + Recommendation (Rec) + + + + + A major problem and an AC review can lead to a Recommendation being Rescinded. + There are no new IPR licences issued under the W3C Patent Policy, + and reinstating the Recommendation requires going through the full Rec-track process again. + + Major problem, AC review + + + Rescinded Recommendation - no new IPR licenses + + + + + + + + + With little uptake, following AC review a specification may become an Obsolete Recommendation + + + + + Obsolete Recommendation + + + + + + + + If there is new uptake, with AC review an Obsolete Recommendation may return to normal Recommendation status + + + + + + + + + + + Replaced by a new version, AC review + + Superseded Recommendation + + + + + + + A Superseded Recommendation can become a normal Recommendation with AC review + + + + + + + + + + + +
Non-Normative Summary of the Paths to Retiring a W3C Recommendation
+
+
6.3.12.4. Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
+

The process of rescinding, obsoleting, + superseding, + or restoring + a Recommendation can be initiated + either by a request from the Team or via a request from any of the following:

+ +

The Team must then + submit the request to the Advisory Committee for review. + For any Advisory Committee review of a proposal to + rescind, + obsolete, + supersede, + or restore + a Recommendation the Team must:

+
    +
  • announce the proposal to all Working Group Chairs, + and to the Public, + as well as to the Advisory Committee +
  • indicate that this is a proposal to + Rescind, + Obsolete, + Supersede, + or restore, + a Recommendation as appropriate +
  • identify the Recommendation by URL +
  • publish a rationale for the proposal +
  • identify known dependencies + and solicit review from all dependent Working Groups +
  • solicit public review +
  • specify the deadline for review comments, + which must be at least 28 days + after the announcement +
+

and should

+
    +
  • identify known implementations. +
+

If there was any dissent in the Advisory Committee review, + the Team must publish + the substantive content of the dissent to W3C and the public, + and must formally address the dissent + at least 14 days + before publication as an Obsolete or Rescinded Recommendation.

+

The Advisory Committee may initiate an Advisory Committee Appeal of the Team’s decision.

+

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. + The updated version may remove the main body of the document. + The Status of this Document section should link + to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

+

Once W3C has published a Rescinded Recommendation, + future W3C technical reports must not include normative references + to that technical report.

+

Note: W3C strives to ensure that all Technical Reports + will continue to be available at their version-specific URL.

+

6.4. The Note Track (Notes and Statements)

+

6.4.1. Group Notes

+

A Group Note (NOTE) + is published + to provide a stable reference for a useful document + that is not intended to be a formal standard.

+

Working Groups, Interest Groups, + the TAG and the AB may publish work as Notes. + Examples include:

+
    +
  • supporting documentation for a specification, + such as explanations of design principles + or use cases and requirements +
  • non-normative guides to good practices +
+

Some Notes are developed through successive Note Drafts before publication as a full Notes, + while others are published directly as a Note. + There are few formal requirements to publish a document as a Note or Note Draft, + and they have no standing as a recommendation of W3C + but are simply documents preserved for historical reference.

+

Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Note Drafts.

+

6.4.2. Publishing Notes

+

In order to publish a Note or Note Draft, + the group:

+
    +
  • must record their decision + to request publication as a Note or Note Draft, and +
  • should publish documentation + of significant changes to the technical report + since any previous publication. +
+

Both Notes and Note Drafts can be updated by republishing + as a Note or Note Draft. + A technical report may remain + a Note indefinitely.

+

6.4.3. Elevating Group Notes to W3C Statement status

+

A W3C Statement is a Note that has been endorsed by W3C as a whole. + In order to elevate a Note to W3C Statement status, + A group must:

+ +

A Note specifying implementable technology should not be elevated to W3C Statement status; + if it does, + the request to publish as a Statement must include rationale + for why it should be elevated, + and why it is not on the Recommendation track.

+

Once these conditions are fulfilled, + the Team must then + begin an Advisory Committee Review on the question of + whether the document is appropriate to publish as a W3C Statement. + During this review period, + the Note must not be updated.

+

The decision to advance a document to W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

The Team must announce the publication of a W3C Statement to the Advisory Committee, other W3C groups, and the public.

+

6.4.4. Revising W3C Statements

+

Given a recorded group decision to do so, + groups can request publication of a W3C Statement with editorial changes—​including candidate amendment—​without any additional process.

+

A candidate amendment can be folded into the main text of the W3C Statement, + once it has satisfied all the same criteria + as the rest of the Statement, + including review by the community to ensure + the substantive and editorial soundness of the candidate amendments. + To validate this, the group must request + an Advisory Committee review of the changes it wishes to incorporate. + The specific candidate amendments under review must be identified as proposed amendments just as in a Last Call for Review of Proposed Corrections.

+

The decision to incorporate proposed amendments into W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

+

6.5. The Registry Track

+

A registry documents a data set + consisting of one or more registry tables, + each table representing an updatable collection + of logically independent, consistently-structured registry entries. + A registry consists of:

+ +

The purposes of maintaining a registry can include:

+
+
non-collision +
Avoiding the problem + of two entities using the same value with different semantics. +
non-duplication +
Avoiding the problem + of having two or more different values in use with the same semantics. +
information +
Providing a central index + where anyone can find out + what a value means + and what its formal definition is + (and where it is). +
submission +
Ease of adding new terms, + including by stakeholders external to the custodian organization. +
consensus +
Promoting a clear consensus of the community on the terms. +
+

This section of the W3C Process provides a specialized process + facilitating the publication and maintenance of such registry tables, + particularly those required by or closely related to W3C Recommendations.

+

Note: Not every table in a specification is a potential registry. + If the intent or effect is that the table enumerates + all the possibilities the authors of the specification expect or envisage, + then the table by itself is enough. + Similarly, if the table is managed by the Working Group + and only updated as part of specification update, + then the complexities of registry management are not needed.

+

6.5.1. Registry Definitions

+

A registry definition defines what each registry table is and how it is maintained. + It must:

+
    +
  • Define the scope and purpose of each registry table. +
  • Define the fields of each registry table and their constraints + (e.g. values must be drawn from a defined set, or be unique, + or only reference publicly available resources, + etc.) +
  • + Define the policy for changes to existing entries, such as +
      +
    • whether entries can be deleted or deprecated +
    • whether entries can be changed after being published, and what kinds of changes are allowed +
    • whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely +
    +
  • Define the method and criteria by which changes are proposed, approved, and incorporated. + (For example, a registry could define + that changes to registry entries can be proposed using a particular web form or email address, + that they must be accompanied by certain background information, + or that they do or do not need to be approved by any member of a particular Working Group.) +
  • + Identify the custodian of the registry table: + the entity to which requests for registry changes must be sent, + and which is responsible for evaluating whether such requests + satisfy the criteria defined in the registry definition. +

    The custodian may be the initiating group, the Team, or a delegated entity. + The custodian for all registry tables in a single registry should generally be the same entity.

    +

    If the custodian of a registry table ceases to exist or to operate as a custodian + (e.g., the relevant group is disbanded, or + the custodian is unresponsive to repeated attempts to make contact), + and the chartered or elected group that owns the registry definition is itself closed or + unresponsive, + the Team should propose replacing the custodian, + which must be confirmed + by an AC Review as a W3C Decision.

    +
+

6.5.2. Publishing Registries

+

A chartered or elected group can publish a registry as a stand-alone technical report on the Registry Track, + where it is called a registry report. Working Groups have the additional option of + incorporating a registry as part of a Recommendation, + as an embedded registry.

+

The registry report or embedded registry must:

+ +

The Team must make available + a means for interested parties to be notified of any updates to a registry table.

+

Note: Since the Process does not impose requirements + on changes to the contents of a registry table other than those imposed by the registry definition, + acceptance of proposed registry changes on behalf of the custodian and + publication of an updated registry report that contains + only registry changes since the previous publication + can be automated + if satisfaction of those rules can be automatically verified.

+

Rules for publication and advancement on the Registry Track are identical to that of the Recommendation Track with the following exceptions:

+ +

6.5.3. Updating Registry Tables

+

Changes to the contents of a registry table that are in accordance with the registry definition, + (i.e. Class 5 changes) + can be made by re-publishing the technical report that contains the affected table, + without needing to satisfy any other requirements for the publication + (not even a group decision, unless this is required by the registry definition). + Such registry changes do not trigger new Advisory Committee Reviews, + nor Exclusion Opportunities, + and do not require verification via an update request, + even for technical reports at maturities where this would normally be expected. + Such publications can be made + even in the absence of a group chartered to maintain the registry + when the custodian is another entity.

+

Note: The custodian is only empowered to make registry changes. + If the group establishing the registry wishes + to empower the custodian to add commentary on individual entries, + this needs to be part of the registry table’s definition. + If other changes are desired, + they need to be requested of the group responsible for maintaining the registry definition—​or in the absence of such a group, of the Team.

+

Changes to the registry tables made in accordance with candidate or proposed amendments to the registry definition which would not be allowed by the unamended registry definition must be identified as such.

+

6.5.4. Registry Data Reports

+

When the registry data is published in a separate technical report from its registry definition, + that report is called a Registry Data Report. + This technical report:

+ +

Registry Data Reports do not have maturity stages in and of themselves; + The maturity stage of the registry whose data they record + is that of the technical report holding the registry definition.

+

Anytime a change is made to a registry definition, + the group maintaining the registry definition must update and republish + any document holding the corresponding registry tables to make it consistent with these changes.

+

Given a recorded group decision to do so, + the group maintaining the registry definition may republish the Registry Data Report to incorporate editorial changes.

+

6.5.5. Specifications that Reference Registries

+

Registries document values, + they do not define any architectural or interoperability requirements + related to those values. + All architectural and interoperability requirements + pertaining to registry entries must be contained in the specifications that reference the registry, + and are therefore subject to the processes + (including approval and intellectual property provisions) + applicable to those referencing specifications.

+

If there are entries that must be implemented, + or any other such restrictions, + they must be defined or documented + in the referencing specification + without dependency on the registry.

+
For example, “All implementations must implement the Basic-Method as defined in the registry” is not acceptable because + a change to the definition of the Basic-Method in the registry would then affect conformance. + Instead, the requirement has to be complete in the specification, + directly or by reference to another specification. + For example “All implementations must recognize the name Basic-Method, + and implement it as defined by section yy of IETF RFC xxxx”. + (The Registry is nonetheless expected to contain Basic-Method as an entry.)
+

6.5.6. Registries and Patents

+

A registry report or embedded registry is not subject to the W3C Patent Policy, + and must not define any requirements on implementations. + For the purposes of the Patent Policy [PATENT-POLICY] (only), + any embedded registry in a Recommendation track document + is not a normative portion of that specification.

+

6.6. Switching Tracks

+

Given a Group decision to do so, Working Groups can republish a technical report on a different track than the one it is on, + under the following restrictions:

+ +

Technical reports that switch tracks start at + their new track’s initial maturity stage, + while retaining any established identity (url, shortname, etc.).

+

Note: The initial maturity stage of the Recommendation track is Working Draft. First Public Working Draft designates a specific type of Working Draft and is not a separate maturity stage. + A document which switches to the Recommendation track is only published as a First Public Working Draft if it was never previously published as such; + otherwise, it is simply a Working Draft.

+

6.7. Further reading

+

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews + and announcements of the various steps, + and tips on getting to Recommendation faster [REC-TIPS]. + Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

+

7. Dissemination Policies

+

7.1. Public Communication

+

The Team is responsible for managing communication within W3C + and with the general public + (e.g., news services, press releases, managing the website and access privileges, and managing calendars). + Members should solicit review by the Team + prior to issuing press releases about their work within W3C.

+

The Team makes every effort to ensure the persistence and availability of the following public information:

+ +

To keep the Members abreast of W3C meetings, Workshops, + and review deadlines, + the Team provides them with a regular (e.g., weekly) news service + and maintains a calendar [CALENDAR] of official W3C events. + Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

+

7.2. Confidentiality Levels

+

There are three principal levels of access to W3C information + (on the W3C website, in W3C meetings, etc.): + public, + Member-only, + and Team-only.

+

While much information made available by W3C is public, + “Member-only” information + is available to authorized parties only, + including representatives of Member organizations, Invited Experts (as described in https://www.w3.org/invited-experts/#memaccess), + the Advisory Board, + the TAG, + and the Team. + For example, + the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

+

“Team-only” information + is available to the Team and other authorized parties.

+

Those authorized to access Member-only and Team-only information:

+
    +
  • must treat the information as confidential within W3C, +
  • must use reasonable efforts to preserve that confidentiality, and +
  • must not release this information to the general public or press, + nor beyond the designated level of access. +
+

The Team must provide mechanisms + to protect the confidentiality of Member-only information + and ensure that authorized parties have proper access to this information. + Documents should clearly indicate + whether they require Member-only confidentiality. + Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

+

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member + who are considered appropriate recipients. + For instance, + it is the responsibility of the Advisory Committee representative and other employees + and official representatives of the organization + to ensure that Member-only news announcements + are distributed for internal use only within their organization. + Information about Member mailing lists is available + in the New Member Orientation [INTRO].

+

7.3. Changing Confidentiality Level

+

As a benefit of membership, + W3C provides some Team-only and Member-only channels + for certain types of communication. + For example, Advisory Committee representatives can send reviews to a Team-only channel. + However, for W3C processes with a significant public component, + such as the technical report development process, + it is also important for information that affects decision-making to be publicly available. + The Team may need to communicate Team-only information to a Working Group or the public. + Similarly, a Working Group whose proceedings are Member-only must make public + information pertinent to the technical report development process.

+

This document clearly indicates which information must be available to Members or the public, + even though that information was initially communicated on Team-only or Member-only channels. + Only the Team and parties authorized by the Team + may change the level of confidentiality of this information. + When doing so:

+
    +
  1. The Team must use a version of the information + that was expressly provided by the author for the new confidentiality level. + In Calls for Review and other similar messages, + the Team should remind recipients to provide such alternatives. +
  2. The Team must not attribute the version + for the new confidentiality level to the author without the author’s consent. +
  3. If the author has not conveyed to the Team a version + that is suitable for another confidentiality level, + the Team may make available a version that reasonably communicates what is required, + while respecting the original level of confidentiality, + and without attribution to the original author. +
+

8. Liaisons

+

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, + through a number of mechanisms + ranging from very informal + (e.g., an individual from another organization participates in a W3C Working Group, + or just follows its work) + to mutual membership, + to even more formal agreements. + Liaisons are not meant to substitute for W3C membership.

+

All liaisons must be coordinated by the Team due to requirements for public communication; + patent, + copyright, + and other IPR policies; + confidentiality agreements; + and mutual membership agreements.

+

W3C may negotiate technical agreements with another organization. + For purposes of the W3C Process, + a technical agreement is a formal contract, + or a Memorandum of Understanding (MoU), + or a similar document, + between W3C and another party or parties, + that relates to the technical activity of the Consortium + (e.g., its publications, groups, or liaisons). + It specifies rights and obligations of each party toward the others. + These rights and obligations may include joint deliverables, + an agreed share of technical responsibilities with due coordination, + and/or considerations for confidentiality and specific IPR.

+

Non-technical agreements, including + those between W3C and its Members for the purposes of membership, + between W3C and its Partners for the purposes of partnership [BYLAWS], + and other agreements related to the operation of the Consortium + or to the ordinary provision of services, + are not subject to these Process provisions.

+

When considering a technical agreement (i.e., before the decision whether to sign is made), + the Team should provide + the Advisory Committee with a draft of the proposed agreement, + along with an explanation of how W3C would benefit from signing this agreement, + for their review and discussion. + After addressing any comments, + and subject to any management or governance procedures that apply + (e.g., formal review of proposed contracts by legal counsel or by the Board), + if the Team decides to proceed with signing the agreement, + the Team must announce the intent to sign, + and provide the final text of the agreement, + with an explanation of signing rationale, to + the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the agreement. + If the proposal is rejected on appeal, + the Team must not sign the agreement on behalf of W3C + unless directed to do so by the Board. + A signed agreement should be made public.

+

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

+

9. Member Submissions

+

A Member Submission is a document or set of documents + developed outside of W3C, + and submitted to W3C + by one or more Members (the Submitter(s)) + to propose technology or other ideas. + After review, + the Team may make the material available at the W3C website.

+

Making a Member Submission available at the W3C website + does not indicate endorsement, acceptance, or adoption by W3C, + its Team, or its Members. + The acknowledgment of a Submission request + does not imply that any action will be taken by W3C. + It merely records publicly + that the Submission has been made by the Submitter(s). + A Member Submission made available by W3C + is not a W3C technical report and must not be referred to as + an output or “work in progress” of W3C.

+

The Member Submission process consists of the following steps:

+
+
Submission +
One of the Submitters, + copying the Advisory Committee representatives of the other Submitters (if any), + sends a request to the Team to acknowledge the Submission request. + The Team and Submitter(s) communicate to ensure that the Member Submission is complete. +
Review +
+ The Team reviews the Submission + to evaluate its scope, quality, and compliance with the Submission requirements, + including licensing requirements: + +

Detailed procedures and requirements are defined by the Team and documented in the “Member submissions guidebook” [MEMBER-SUB].

+
Decision +
+ After review, the Team must either acknowledge or reject the Submission request. + +
+

The Advisory Committee representative(s) of the Submitter(s) may initiate a Submission Appeal. + The procedure for handling Submission Appeals is the same as for Formal Objections, + except that an AC Appeal is not possible + and both the Formal Objection and the Council Report are confidential to the Team, TAG, and AB.

+

10. Process Evolution

+

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, + with the Advisory Board acting as the sponsoring Working Group. + The documents may be developed by the AB or by another group to whom the AB has delegated development. + Review includes + soliciting input from the W3C community, + and in particular the Team.

+

The documents covered by this section are:

+ +

The Advisory Board initiates review as follows:

+
    +
  1. The Team sends a Call for Review to the Advisory Committee and other W3C groups. +
  2. After comments have been formally addressed and the document possibly modified, + the Team seeks endorsement from the Members by initiating an Advisory Committee review. + The review period must last at least 28 days. +
  3. After the Advisory Committee review, + following a W3C decision to adopt the document(s), + the Team does so + and sends an announcement to the Advisory Committee. + Advisory Committee representatives may initiate + an Advisory Committee Appeal to W3C. +
+

Note: As of June 2020, + the Patent Policy is developed in the Patents and Standards Interest Group, + the Code of Conduct in the Positive Work Environment Community Group, + and the Process in the W3C Process Community Group.

+

Appendix A: Retired Terminology

+

This section is non-normative.

+

Previous versions of this process defined and used various concepts and document statuses + that have since been retired or renamed. + For ease of reference, + this appendix lists the more notable ones, + and it links to the the definition or relevant section + in the most recent version of the Process that used them, + and gives the more recent equivalent term when there is one.

+
+
Amended Recommendation (retired term) +
Last defined in section 6.2.1 of the 2020 Process. +
Edited Recommendation (retired term) +
Last defined in section 6.1.2 of the 2019 Process. +
Last Call (retired term) +
Last defined in section 7.4.2 of the 2005 Process. +
Maturity level (renamed term) +
Last defined in section 6.3.1 of the 2021 Process, + now called maturity stage. +
Member Consortium, plural: Member Consortia + (renamed term) +
Last defined in section 2.1.2.1 of the 2021 Process, + now called Member Association. +
Memorandum of Understanding, plural: Memoranda of Understanding, abbreviation: MoU + (renamed term) +
Last defined in section 9 of the 2021 Process, + now called technical agreement. +
Other Charter (renamed term) +
Last used in section 5.2.6 of the 2020 Process, + now called Exclusion Draft Charter. +
Proposed Recommendation (retired term) +
Last defined in section 6.3.1 of the 2023 Process. +
Team Submissions (retired term) +
Last defined in section 2.2.1 of the 2019 Process. +
W3C Chair (renamed term) +
Last defined in section 2.2 of the 2014 Process, + now called CEO. +
+

Appendix B: Acknowledgments

+

This section is non-normative.

+

The editors are grateful to the following people, + who as interested individuals and/or with the affiliation(s) listed, + have contributed to this proposal for a revised Process: + Adam Basha, + Anna Weinberg (Apple) + Charles McCathie Nevile, + Chris Lilley (W3C), + Chris Needham (BBC), + Chris Wilson (Google), + Coralie Mercier (W3C), + David W. Singer (Apple), + Denis Ah-Kang (W3C), + Dominique Hazael-Massieux (W3C), + Ian Jacobs (W3C), + Jeffrey Yasskin (Google), + Jill Schmidt (Apple), + Marcos Cáceres (Apple), + Mark Nottingham, + Martin Thomson (Mozilla), + Michael Champion, + Michael Sirtori (Intel), + Mike Smith (W3C), + Nick Doty (Center for Democracy and Technology), + Nigel Megitt (BBC), + Philippe Le Hégaret (W3C), + Sam Sneddon (Apple), + Shawn Lawton Henry (W3C), + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Theresa O’Connor (Apple), + Vivien Lacourba (W3C).

+

The editors are sorry for forgetting any names, + and grateful to those who have listened patiently to conversations about this document + without feeling a need to add more.

+

The following individuals contributed to the development of earlier versions of the Process: + Alex Russell (Google), + Andreas Tai (Institut fuer Rundfunktechnik), + Andrew Betts (Fastly), + Ann Bassetti (The Boeing Company), + Anne van Kesteren, + Art Barstow (Nokia, unaffiliated), + Bede McCall (MITRE), + Ben Wilson, + Brad Hill (Facebook), + Brian Kardell (JQuery, Igalia), + Carine Bournez (W3C), + Carl Cargill (Netscape, Sun Microsystems, Adobe), + Charles McCathie Nevile (ConsenSys), + Chris Lilley (W3C), + Chris Needham (BBC), + Chris Wilson (Google), + Claus von Riegen (SAP AG), + Coralie Mercier (W3C), + Cullen Jennings (Cisco), + Dan Appelquist (Telefonica, Samsung), + Dan Connolly (W3C), + Daniel Dardailler (W3C), + Daniel Glazman (Disruptive Innovations), + David Baron (Mozilla), + David Fallside (IBM), + David W. Singer (Apple), + David Singer (IBM), + Delfí Ramírez, + Dominique Hazaël-Massieux (W3C), + Don Brutzman (Web3D), + Don Deutsch (Oracle), + Eduardo Gutentag (Sun Microsystems), + Elika J. Etemad aka fantasai, + Florian Rivoal, + Fuqiao Xue (W3C), + Geoffrey Creighton (Microsoft), + Giri Mandyam (Qualcomm), + Gregg Kellogg, + Hadley Beeman, + Håkon Wium Lie (Opera Software), + Helene Workman (Apple), + Henri Sivonen (Mozilla), + Ian Hickson (Google), + Ian Jacobs (W3C), + Ivan Herman (W3C), + J Alan Bird (W3C), + Jay Kishigami 岸上順一 (NTT), + Jean-Charles Verdié (MStar), + Jean-François Abramatic (IBM, ILOG, W3C), + Jeff Jaffe (W3C), + Jeffrey Yasskin (Google), + Jim Bell (HP), + Jim Miller (W3C), + Joe Hall (CDT), + John Klensin (MCI), + Josh Soref (BlackBerry, unaffiliated), + Judy Brewer (W3C), + Judy Zhu 朱红儒 (Alibaba), + Kari Laihonen (Ericsson), + Karl Dubost (Mozilla), + Ken Laskey (MITRE), + Kevin Fleming (Bloomberg), + Klaus Birkenbihl (Fraunhofer Gesellschaft), + Larry Masinter (Adobe Systems), + Lauren Wood (unaffiliated), + Léonie Watson (The Paciello Group), + Liam Quin (W3C), + Marcos Cáceres (Mozilla), + Maria Courtemanche (IBM), + Mark Crawford (SAP), + Mark Nottingham, + Michael Champion (Microsoft), + Michael Geldblum (Oracle), + Mike West (Google), + Mitch Stoltz (EFF), + Natasha Rooney (GSMA), + Nigel Megitt (BBC), + Olle Olsson (SICS), + Ora Lassila (Nokia), + Paul Cotton (Microsoft), + Paul Grosso (Arbortext), + Peter Linss, + Peter Patel-Schneider, + Philippe Le Hégaret (W3C), + Qiuling Pan (Huawei), + Ralph Swick (W3C), + Renato Iannella (IPR Systems), + Rigo Wenning (W3C), + Rob Sanderson (J Paul Getty Trust), + Robin Berjon (W3C), + Sally Khudairi (W3C), + Sam Ruby (IBM), + Sam Sneddon, + Samuel Weiler (W3C), + Sandro Hawke (W3C), + Sangwhan Moon (Odd Concepts), + Scott Peterson (Google), + Shawn Lawton Henry, + Steve Holbrook (IBM), + Steve Zilles (Adobe Systems) + Steven Pemberton (CWI), + TV Raman (Google), + Tantek Çelik (Mozilla), + Ted Thibodeau Jr (OpenLink Software), + Terence Eden (Her Majesty’s Government), + Thomas Reardon (Microsoft), + Tim Berners-Lee (W3C), + Tim Krauskopf (Spyglass), + Travis Leithead (Microsoft), + Virginia Fournier (Apple), + Virginie Galindo (Gemalto), + Wayne Carr (Intel), + Wendy Fong (Hewlett-Packard), + Wendy Seltzer (W3C), + Yves Lafon (W3C).

+

Appendix C: Changes

+

This section is non-normative.

+

Changes since the 3 November 2023 Process

+

This document is based on the 3 November 2023 Process. + A list of issues addressed, + a diff from Process 2023 to this latest version, + as well as + a detailed log of all changes since then are available.

+

In addition to a number of editorial adjustments and minor tweaks, the following is a summary of the main differences:

+
+
Changes to technical reports and their publication +
+
    +
  • Retire the Proposed Recommendation phase of the Recommendation track. It was only used as a short-lived transition + during which various verifications and votes about CR were done. + These can be done on a CR + without having to republish it as a separate thing. + This simplifies the Process without changing the actual quality or consensus expectations. + (See Issue 861) +
  • Retire “Streamlined Publication Approval”. + This was meant to enable REC track publication with fewer/faster approval steps + when some stricter than usual criteria were fulfilled. + However, regular REC track publication have improved enough + that this became unnecessary, + and nobody was using it. + (See Issue 856) +
  • Add a requirement to make progress on external issues for update requests + (See Issue 781) +
  • Drop the requirement to publish every 6 months if nothing has changed. + (See Issue 1013) +
  • Enable Team to replace defunct registry custodians when no-one else can. + (See Issue 699) +
  • Allow registries to be published by Interest Groups, the Advisory Board, and the TAG, + in addition to Working Groups. + (See Issue 902) +
  • Rename “registry sections” to embedded registries to avoid confusion over whether they can be split across multiple sections of a Recommendation. + (See Issue 800) +
  • Rename "Draft Note" into "Note Draft", + and "Draft Registry" into "Registry Draft" + to be consistent with other statuses that uses the word "Draft", + and to make that word stand out more. + (See Issue 779) +
  • Clarify the definition of a Registry (see Issue 800) + and of Recommendation Track Documents (see Pull Request 831). +
  • Consolidate and harmonize into one section the various parts of the Process + that described whether and how the Team can maintain technical reports + that no longer have a Group chartered to maintain them. + (See Pull Request 860) +
+
Changes to chartering +
+ +
Changes to formal decision making and escalation +
+
    +
  • Adjust the rules guiding initiation of Councils, + to make the deadline strict, + and to provide a fallback mechanism if they are not met. + (See Pull Request 925) +
  • Make the Council’s short-circuit a little more flexible. + (See Issue 852) +
  • Exclude TAG/AB Members from voting on TAG/AB proposals in Councils. + (See Issue 749) +
  • Limit the involvement of Tim Berners-Lee to the TAG proper, + not including the Council. + (See Pull Request 792) +
  • Council dismissal vote counts must be reported. + (See Issue 748) +
  • Require documentation of how Formal Objections get resolved. + (See Issue 953) +
  • Put constraints on the timing of making Formal Objections public. + (See Issue 735) +
  • Fine-tune the rules about + how changes can be incorporated into a proposal + following an AC Review. + (See Issue 825) +
  • Adjust AC appeal vote threshold based on participation, + aligning with the thresholds and super majority requirements + for "Requisite Member Vote" from the W3C Bylaws. + (See Issue 886) +
  • Let the originator of a proposal decide whether to try again + after addressing feedback + following an AC Appeal. + (See Issue 844) +
  • Simplify provisions regarding substitute representatives and proxies. + (See Issue 373) +
+
Other changes +
+
    +
  • Reuse the bylaws’ notion of Good Standing, + and restrict TAG and AB elections + as well as AC Votes where a decision is made based on counting ballots + to Members in Good Standing. + (See Issue 935 and Pull Request 954) +
  • The section on Member Submissions was significantly shortened and simplified, + reducing the complexity under formal Process authority, + and shifting much of the material to /Guide, + under Team authority. + (See Issue 412 and Pull Request 936) +
  • Clarify how the outcome of certain ballots are determined. + (See Issue 836, Issue 838) +
  • Stop citing the superseded TAG charter. + (See Issue 794) +
  • Clarify amount of leeway around incomplete nominations to TAG or AB elections. + (See Issue 464) +
  • Shift most of the non-normative discussion about Workshops to [GUIDE], + and reorganize the remaining normative requirements. + (See Pull Request 876) +
  • The URL of this document was changed + from /Consortium/Process/ to /policies/process/ + for better integration in the W3C website architecture. +
+

Changes since earlier versions

+

Changes since earlier versions of the Process are detailed + in the changes section of the previous version of the Process.

+
+
+ +
+

Index

+

Terms defined by this specification

+ +

Terms defined by reference

+ +

References

+

Normative References

+
+
[COC] +
W3C Code of Conduct. URL: https://www.w3.org/policies/code-of-conduct/ +
[COLLABORATORS-AGREEMENT] +
Invited expert and collaborators agreement. URL: https://www.w3.org/invited-experts/agreement-2023/ +
[CONFLICT-POLICY] +
Conflict of Interest Policy for the W3C Team. URL: https://www.w3.org/policies/conflict-of-interest-policy-for-w3c-team/ +
[DOC-LICENSE] +
W3C Document License. URL: https://www.w3.org/copyright/document-license-2023/ +
[PATENT-POLICY] +
The W3C Patent Policy. URL: https://www.w3.org/policies/patent-policy/ +
[PATENT-POLICY-2004] +
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/ +
[PATENT-POLICY-2020] +
The W3C 2020 Patent Policy. URL: https://www.w3.org/policies/patent-policy/20200915/ +
[PUBRULES] +
Publication Rules. URL: https://www.w3.org/pubrules/ +
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
[RFC3797] +
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://www.rfc-editor.org/rfc/rfc3797 +
[W3C-PATENT-POLICY] +
Wendy Seltzer. W3C Patent Policy. 15 September 2020. URL: https://www.w3.org/policies/patent-policy/ +
+

Informative References

+
+
[AB-HP] +
The Advisory Board home page. URL: https://www.w3.org/2002/ab/ +
[AC-MEETING] +
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/events/ac/ +
[BG-CG] +
Community and Business Group Process. URL: https://www.w3.org/community/about/process/ +
[BYLAWS] +
Amended and Restated Bylaws of World Wide Web Consortium, Inc.. URL: https://www.w3.org/2024/09/25-w3c-bylaws.pdf +
[CALENDAR] +
Calendar of all scheduled official W3C events. URL: https://www.w3.org/events/ +
[CHAIR] +
W3C Working/Interest Group Chair. URL: https://www.w3.org/guide/chair/role +
[CHARTER] +
How to Create a Working Group or Interest Group. URL: https://www.w3.org/guide/process/charter +
[COUNCIL-REPORT-INDEX] +
Council Report Index. URL: https://www.w3.org/about/council/ +
[CURRENT-AC] +
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList +
[DECISION-APPEAL] +
Appealing a W3C Decision. URL: https://www.w3.org/guide/process/ac-appeal +
[ELECTION-HOWTO] +
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/guide/process/election +
[FELLOWS] +
W3C Fellows Program. URL: https://www.w3.org/careers/fellows/ +
[GROUP-MAIL] +
Group mailing lists. URL: https://www.w3.org/groups/ +
[GUIDE] +
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/guide/ +
[INTRO] +
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro +
[JOIN] +
How to Join W3C. URL: https://www.w3.org/membership/join/ +
[LIAISON] +
W3C liaisons with other organizations. URL: https://www.w3.org/liaisons/ +
[MEMBER-AGREEMENT] +
W3C Membership Agreement. URL: https://www.w3.org/membership/agreement/ +
[MEMBER-HP] +
Member website (Member-only access). URL: https://www.w3.org/Member/ +
[MEMBER-LIST] +
The list of current W3C Members. URL: https://www.w3.org/membership/list/ +
[MEMBER-SUB] +
Member submissions guidebook. URL: https://www.w3.org/submissions/guide/ +
[MISSION] +
The W3C Mission statement. URL: https://www.w3.org/mission/ +
[OBS-RESC] +
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/guide/process/obsolete-rescinded-supserseded +
[REC-TIPS] +
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/guide/standards-track/rec-tips +
[REPUBLISHING] +
In-place modification of W3C Technical Reports. URL: https://www.w3.org/guide/standards-track/republishing +
[SUBMISSION-LIST] +
The list of acknowledged Member Submissions. URL: https://www.w3.org/submissions/ +
[TAG-HP] +
The TAG home page. URL: https://www.w3.org/2001/tag/ +
[TEAM-CONTACT] +
Role of the Team Contact. URL: https://www.w3.org/guide/teamcontact/role +
[TR] +
The W3C technical reports index. URL: https://www.w3.org/TR/ +
[TRANSITION] +
Organize a Technical Report Transition. URL: https://www.w3.org/guide/transitions/ +
[TRANSLATION] +
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/ +
[W3C-IPR] +
W3C IPR Policies. URL: https://www.w3.org/policies/ +
+ + + diff --git a/status.include b/status.include deleted file mode 100644 index 050be32d..00000000 --- a/status.include +++ /dev/null @@ -1,14 +0,0 @@ -

- W3C, including all existing chartered groups, - follows the most recent operative Process Document announced to the Membership. - -

- This document is developed by the Advisory Board's Process Task Force - working within the W3C Process Community Group - (which anyone can join). - This is the [DATE] [LONGSTATUS] for the proposed next version of the W3C Process Document. - - [STATUSTEXT] - -

- A history of substantial changes from previous versions of the Process Document is provided. diff --git a/w3c.json b/w3c.json index 4559ff96..719d6c42 100644 --- a/w3c.json +++ b/w3c.json @@ -1,6 +1,6 @@ { - "group": [ 7756, 50503 ] -, "contacts": ["jeffjaffe", "chaals", "dwsinger"] + "group": [ "other/ab", "cg/w3process" ] +, "contacts": ["plehegar", "fantasai", "frivoal"] , "policy": "restricted" , "repo-type": "process" }