W3C手続き文書
W3C Process Document


15 September 2020

このヴァージョン:
This version:
最新公表ヴァージョン:
Latest published version:
https://www.w3.org/Consortium/Process/
編集者草案
Editor's Draft:
https://www.w3.org/Consortium/Process/Drafts/
以前のヴァージョン:
Previous Versions:
課題の追跡:
Issue Tracking:
GitHub
編集者:
Editors:
Elika J. Etemad / fantasai (外部の専門家)
Elika J. Etemad / fantasai (Invited Expert)
Florian Rivoal (外部の専門家)
Florian Rivoal (Invited Expert)
従前の編集者:
Former Editors:
Natasha Rooney (外部の専門家)
Natasha Rooney (Invited Expert)
Charles McCathie Nevile (Yandex)
Charles McCathie Nevile (Yandex)
Ian Jacobs (W3C)
Ian Jacobs (W3C)

概要
Abstract

ワールド・ワイド・コンソーシアム(W3C)の使命は, ワールド・ワイド・ウェブの発展を促進し, 相互運用性を確かなものにする共通の通信規約を開発することで, ワールド・ワイド・ウェブが完全な潜在能力を発揮するよう導くことです. W3C手続き文書は, W3Cの組織の構造, また, W3Cがその使命を成し遂げることを確実にする手続き, 責任範囲, 役割について述べています. この文書は, 事務局内部の作業について述べてはいません.

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.

W3Cの使命やW3Cの歴史についてのより詳しい情報は, W3Cについてを参照して下さい.

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

この文書の位置付け
Status of this Document

この文書は2020年9月15日時点の手続き文書です.

This document is the 15 September 2020 Process.

W3Cは, 全ての現存する認可された部会を含めて, 会員に示された最新の有効な手続き文書に従います. この文書は, (誰でも参加することができる)W3C手続き改訂部会での, 諮問会議の手続きプロジェクトチームの働きにより開発されました.

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 Revising W3C Process Community Group (which anyone can join).

手続き文書の以前のヴァージョンからの重要な変更履歴が提供されています. この文書は, 手続き文書の編集者草案へのリンクを更新するために, 2021年2月まで適宜修正されます.

A history of substantial changes from previous versions of the Process Document is provided. The document was modified in place in February 2021 to update the link to the editor's draft of the Process.

手続き文書において, 意見が推奨されています. 課題としての意見をw3c/w3process GitHub レポジトリで提起して下さい. このような操作ができない場合, public-w3process@w3.org (公開された履歴)またはprocess-issues@w3.org (会員限定の履歴)にメールで送ることもできます.

Comment is invited on the Process. Please file comments as issues in the w3c/w3process GitHub Repository. If you are unable to do this you may send them in email to public-w3process@w3.org (publicly archived) or to process-issues@w3.org (Member-only archive).

特許指針に対する手続き文書の関係
Relation of Process Document to Patent Policy

W3C会員が考慮すべきことは, 手続き文書の規定が, 会員規約 [会員規約]を通して会員を拘束するという事実によるものです. W3C特許指針[特許指針]は, 手続き文書の一部として標準の参考文献によって組み込まれており, そのため, 同様に拘束します.

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.

特許指針は, W3Cの会員, 事務局, 他の参加者に追加の義務を付しています. 手続き文書は, それら必要なことを言い直していませんが, 参照を含んでいます. 手続き文書と特許指針は, 独立して効力があるように設計されています.

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

用語しなければなりません(must), してはなりません(must not), すべきです(should), すべきではありません(should not), 必須です(required), してもよいです(may)は, RFC 2119と一致するように用いられています. 用語必須ではありません(not required)は, RFC2119 [RFC2119]で定義されている用語してもよいです(may)と等価です. (訳注:英語の助動詞等の意味合いを定義しているものですが, 日本語訳では文脈等から自然な日本語となるよう100%一致させているわけではありません.)

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

用語の中には, それらの用語がW3Cの手続きに特別に関係する存在であることを示すために, この文書(や他のW3Cの資料)で大文字で書かれているものもあります. それらの用語はこの文書で定義されており, 読者は, 通常の言葉の定義では, この文書を理解するために不十分であることを覚えておくべきです.

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の仕事は, ウェブ技術の標準化を中心に展開されています. この仕事を成し遂げるために, W3Cは, 会員, 事務局, 社会全体の合意を基にした, 質の高い標準の開発を推進する手続きに従います. W3Cの手続きは, 全てW3Cの使命の一面である公正, 責任 前進を推進します. この文書は, W3Cが使命の遂行において従う手続きについて述べています.

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

ここに, どのようにW3Cがウェブ技術を標準化するかを示した一般的な概要があります. たくさんの場合に, この仕事の目標は, W3C勧告, すなわちWeb標準です.

Here is a general overview of how W3C standardizes a Web technology. In many cases, the goal of this work is a W3C Recommendationa Web standard.

  1. 特定の項目に関心を持った人がいるとします. 例えば, 会員が会員投稿のフォームで関心を表したり, 事務局が, W3C内外での関心の現れに対する仕事について監視したりします. また, 同じように, W3Cが, W3C界隈で関心が持たれている項目について議論するために, 人々を集めようとワークショップを開催したりします.
    People generate interest in a particular topic. For instance, Members express interest in the form of Member Submissions, and the Team monitors work inside and outside of W3C for signs of interest. Also, W3C is likely to organize a Workshop to bring people together to discuss topics that interest the W3C community.
  2. 項目に十分な関心が寄せられた場合(例えば, 成功したワークショップや諮問委員会メーリングリストの議論の後), ディレクターは, 関心の寄せられた項目の範囲に応じて, 1つ以上の新しい関連部会または作業部会の開発の提案を発表します. 関心の寄せられた項目に資源を割り振るW3Cの対応が可能な場合, ディレクターは, 部会とその部会が作業を始めることを承認します.
    When there is enough interest in a topic (e.g., after a successful Workshop and/or discussion on an Advisory Committee mailing list), the Director announces the development of a proposal for one or more new Interest Group or Working Group charters, depending on the breadth of the topic of interest. W3C Members review the proposed charters. When there is support within W3C for investing resources in the topic of interest, the Director approves the group(s) and they begin their work.
  3. 3つの形式の作業部会の参加者がいます. 会員の代表者, 外部の専門家, 事務局の委員. 事務局の委員は, 技術的作業に寄与し, W3Cの他の部会と, 対象の部会との統合を確かなものにするように手助けします. 作業部会憲章は, 部会の各成果(例えば, 技術報告書, テストツール, 教本)についての可能性を設定します.
    There are three types of Working Group participants: Member representatives, Invited Experts, and Team representatives. Team representatives both contribute to the technical work and help ensure the group’s proper integration with the rest of W3C. The Working Group charter sets expectations about each group’s deliverables (e.g., technical reports, test suites, and tutorials).
  4. 作業部会は, 一般に, W3C勧告の状態になるように, 改訂と審査の過程を経た仕様書や手引きを作成します. それらの技術報告書を提供するW3Cの手続きは, 会員や社会全体からの重要な意見が反映され, 作業部会が実装や相互運用性の例を示すことができる必要があります. 手続きの最後には, 諮問委員会が熟慮された技術報告書を審査し, 技術的に対応しているものがあれば, W3Cは, それを勧告として公表します.
    Working Groups generally create specifications and guidelines that undergo cycles of revision and review as they advance to W3C Recommendation status. The W3C process for producing these technical reports includes significant review by the Members and public, and requirements that the Working Group be able to show implementation and interoperability experience. At the end of the process, the Advisory Committee reviews the mature technical report, and if there is support, W3C publishes it as a Recommendation.

手続き文書は, 合意を促し, 技術報告書の開発手続きの一部や諮問委員会への抗議手続きを通して(会員と一般両方の)審査を必須とすることで, 技術的な決定における, 質と公正さの目標をより高めています.

The Process Document promotes the goals of quality and fairness in technical decisions by encouraging consensus, requiring reviews (by both Members and public) as part of the technical report development process, and through an Advisory Committee Appeal process.

手続き文書の他の節では次のことについて述べています.

The other sections of the Process Document:

  1. W3C部会の参加者に対する4つの指針の設定.
    set forth policies for participation in W3C groups,
  2. W3Cの中に2つの常設の部会の設置. コンソーシアム内を横断する技術的な課題の解決を手助けする技術諮問委員会(TAG). また, コンソーシアム内を横断する技術的でない課題の解決を助け, W3C手続きの発展を管理する諮問会議(AB).
    establish two permanent groups within W3C: the Technical Architecture Group (TAG), to help resolve Consortium-wide technical issues; and the Advisory Board (AB), to help resolve Consortium-wide non-technical issues, and to manage the evolution of the W3C process, and
  3. (W3C諮問委員会によって代表されている)会員, 事務局, 一般の社会全体との間の他の相互作用の説明.
    describe other interactions between the Members (as represented by the W3C Advisory Committee), the Team, and the general public.

W3Cは, 独自の手続き文書 [BG-CG]で別個に説明している共同部会とビジネス部会についても管理しています.

The W3C also operates Community and Business Groups, which are separately described in their own process document [BG-CG].

2. 会員, 諮問委員会, 事務局, 諮問会議, 技術諮問委員会
Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group

W3Cの使命は, ウェブの完全な潜在能力を引き出すように導くことです. W3Cの会員組織は, この完了のために資源を提供し, W3C事務局は, 取組みを調整するために, 技術的な指揮と組織を提供します.

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の会員は, 第一にW3C手続き文書の中で次のように表現されます.

W3C Members are primarily represented in W3C processes as follows:

  1. 諮問委員会は, (最新の諮問委員会の委員 [最新のAC]会員限定の一覧にあるように)各会員組織から1名の委員で構成されます. 諮問委員会は次のことを行います.
    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]) The Advisory Committee:

    諮問委員会の委員は, この文書で述べられているいくつかの状況で諮問委員会への抗議を提出してもよいです.

    Advisory Committee representatives may initiate an Advisory Committee Appeal in some cases described in this document.

  2. 会員組織の代表者は, 作業部会や関連部会に参加して, 技術報告書を書いたり, 審査したりします.
    Representatives of Member organizations participate in Working Groups and Interest Groups and author and review technical reports.

W3Cの会員になることは, “W3Cに加入するには[加入]で述べられているように, (最新のW3C会員 [会員一覧]にあるように)全ての団体に開かれています. 組織は, 会員規約 [会員規約]に同意します. 事務局は, 会員の参加の同意を事務局内にとどまらせ, どの会員にもW3Cの中で優先の取扱いを受けないことを確かなものにしなければなりません.

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]). Organizations subscribe according to the Membership Agreement [MEMBER-AGREEMENT]. The Team must ensure that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

W3Cは個人に合わせた会員の種類を持っていないにも関わらず, 個人はW3Cに加入してもよいです. 個人が他の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:

さらに, 会員規約に含まれるさらに細かい制限を条件として, 会員組織の代表者は, 次のようにW3Cに参加します.

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

W3C会員の権利や恩恵は, この文書で述べられている手続きに合致するか次第です. W3C会員の大多数は, 正確に, それらの手続きの精神と文章に従います. 深刻な, また繰り返しの違反が起こった場合で, なおかつ, それらの違反に取り組む努力を繰り返しても状況が改善しない場合, ディレクターは, 懲戒処分を行ってもよいです. それ以上の不適合の場合の仲裁は, 会員規約[会員規約]の第19項によって左右されます. 懲戒処分の基準 [懲戒基準]を参照して下さい.

The rights and benefits of W3C membership are contingent upon conformance to the processes described in this document. The vast majority of W3C Members faithfully follow the spirit as well as the letter of these processes. When serious and/or repeated violations do occur, and repeated attempts to address these violations have not resolved the situation, the Director may take disciplinary action. Arbitration in the case of further disagreement is governed by paragraph 19 of the Membership Agreement [MEMBER-AGREEMENT]. Refer to the Guidelines for Disciplinary Action [DISCIPLINARY-GL].

2.1.2. 会員共同体と関連会員
Member Consortia and Related Members

2.1.2.1. 会員共同体
Membership Consortia

会員共同体”は, 2つ以上の個人, 企業, 組織, 政府による, 共同体, 利用者社会, 提携を意味します. もしくは, W3Cの確かな目標に向けて参加してその目標を成し遂げるのとは別に, 共通の目標を成し遂げるために資源を共同出資したり, 共通の活動に参加したりする目的を持った, 個人, 企業, 組織, 政府の連携を意味します. 共同資本の会社や類似した組織は, 単に同じ株主を持つに過ぎないことから, 会員共同体ではありません. 見込まれている会員が会員共同体として適任であるか明確でない場合, ディレクターは賢明に判断するでしょう. 会員共同体に対して, W3C手続き文書の中で述べたW3C会員の権利や恩恵は, 会員共同体の有償職員や諮問委員会の委員にまで及びます.

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

会員共同体は, 組織によって雇用されているが, 会員の代表として権利を行使してもよい, 4名の(事務局の裁量でそれ以上の)個人を指名してもよいです.

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.

メンバーとして個人を含む会員共同体に対して, それらの個人は, W3Cの仕事に参加するときに, 雇用されている所属を開示しなければなりません. 関連会員に対する規定も適用されます. さらに, それらの個人は, 自分達の雇用主特有の利益ではなく, W3C会員の広範囲に及ぶ利益を代表しなければなりません.

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.

会員としての組織の側面を持つ会員共同体に対して, 全てのそのような組織の指名された代表者は, 会員組織の公式な代表者(例えば, 諮問委員会の委員またはプロジェクトチームの議長)でなければなりません. また, それらの代表者は, W3Cの仕事に参加するときに, 雇用されている所属を開示しなければなりません. 関連会員に対する規定も適用されます. さらに, それらの個人は, 自分達の雇用主特有の利益ではなく, W3C会員の広範囲に及ぶ利益を代表しなければなりません.

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.

全ての会員共同体の代表者に対して, 会員共同体のためのIPR(訳注:知的所有権)の取り組みが必要になります. ただし, 代表者の雇用主によって, それ以上のIPRの取り組みが必要になっていない場合に限ってです.

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

合意の手続きの誠実さを確実にする利益の点で, この文書における手続きの中では, 場合によって会員の関係が, 関連会員の状態によって影響されます. ここでは, 2つの会員が, 次の場合に関連していると言います.

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. 会員が, W3Cの参加に影響する雇用契約またはコンサルタント契約を結んでいる場合.
    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. 諮問委員会(AC)
Advisory Committee (AC)

組織がW3Cに加入するとき(“W3Cに加入するには[加入]参照), 組織は, 会員規約の一環として諮問委員会の委員を指名しなければなりません. 新会員オリエンテーション [導入]は, 諮問委員会メーリングリストへの参加申込の仕方と脱退の仕方について説明し, 諮問委員会の会議の情報を提供し, 新しい諮問委員会の委員の指名の仕方を説明するなどしています. 諮問委員会の委員は, 新会員オリエンテーションで説明されている仕組みによって情報を開示することで, 利益衝突の指針に従わなければなりません. W3C特許指針[特許指針]で説明されている諮問委員会の委員の追加の役割についても参照して下さい.

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. See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

会員についての追加の情報は, 会員ウェブサイト [会員HP]で確認できます.

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

2.1.3.1. 諮問委員会メーリングリスト
Advisory Committee Mailing Lists

事務局は, 諮問委員会の利用のために, 2つのメーリングリストを提供しなければなりません.

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.

2.1.3.2. 諮問委員会の会議
Advisory Committee Meetings

事務局は, 諮問委員会対面での会議年2回開催します. 事務局は, (一般にCEO(訳注:最高経営責任者)である)それらの会議の議長を指名します. 諮問委員会の各会議では, 事務局は, 次の内容について諮問委員会に関する最新情報を提供すべきです.

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
  • 各段階のW3C会員の数
    The number of W3C Members at each level.
  • W3Cの財務状態の概要
    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.

各会員組織は, 諮問委員会の各会議に1名の代表者を送るべきです. 特別な事情がある場合に(例えば, 組織からの代表者の交代の時期である場合に), 会議の議長は, 会員組織が会議に2名の代表者を送ることを認めてもよいです.

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.

事務局は, 諮問委員会の各会議の時間と場所を, 遅くとも前回の会議の終了までに通知しなければなりません. 1年分の通知が望ましいです. 事務局は, 前もって直近1年の諮問委員会の各会議の地域を通知しなければなりません.

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.

諮問委員会の会議 [AC会議]についてのより詳しい情報は, 会員ウェブページで確認できます.

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

2.2. W3C事務局
The W3C Team

事務局は, ディレクター, CEO, W3C有償職員, 無償研修生, W3C特別研究員で構成されています. W3C特別研究員は, 事務局の一部として働く, 会員組織の従業員です. W3C特別研究員プログラム [特別研究員]を参照して下さい. 事務局は, ウェブ技術についての技術的指揮を提供し, (利用可能な資源といった)現実的な制限の中で目標に届くためにW3Cの活動を組織して管理し, ウェブやW3Cの技術について, 会員と社会全体を通じ合わせます.

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.

ディレクターとCEOは, この文書で述べられている何らかの自分達の役割について, TAGでの委員を除いて, (一般に事務局内の他の人物に)責任を委任してもよいです.

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.

ディレクターは, この文書の関係する所を通じて責任が規定されている, W3Cの技術的な設計者を指揮します. 鍵となる働きは, W3Cの技術体系の選択における合意を判断すること, 技術報告書の公表, 新しい部会の認可です. また, 部会の議長を指名すること, 部会の決定の要求に対して"タイブレーカー"として決着を付けること, 正式な異議の結果を判断することです. そして, ディレクターは, TAGの議長です.

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.

注意: W3Cは現在, 法人組織ではありません. 法的な契約によると, W3Cは4つのホスト組織, 北京航空航天大学, 欧州情報処理数学コンソーシアム(ERCIM), 慶応義塾大学, マサチューセッツ工科大学(MIT)によって代表されています. W3Cの中において, ホスト機関は, ホスト規約によって統治されています. ホスト自身は, W3Cの会員ではありません.
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.

2.3. 諮問会議(AB)
Advisory Board (AB)

1998年3月に創られた, 諮問会議は, 計画, 管理, 法的問題, 手続き, 利益衝突の解決の課題において, 事務局に継続的な助言を提供しています. 諮問会議は, 諮問委員会で挙げられた課題を追跡したり, そのような課題に会員の意見を求めたり, それらの課題を解決するための活動を提案したりすることで, 会員のために尽くしてもいます. 諮問会議は, 手続き文書の発展を管理しています. 諮問会議は, 会員提案がウェブ技術体系とは無関係な理由で却下されたときに, 提案の抗議を聞き取りします. TAGも参照して下さい.

Created in March 1998, 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.

諮問会議は, 管理者の理事会ではなく, W3Cの中で何ら決定を行う権限を持っていません. その役割は, 厳密に諮問を行うことです.

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

事務局は, 諮問会議と事務局限定のメーリングリストを, 諮問会議の連絡のために利用可能にしなければなりません.

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.

諮問会議の詳細(例えば, 諮問会議の委員の一覧, メーリングリストの情報, 諮問会議の議事の要約)は, 諮問会議ホームページ [AB-HP]で確認できます.

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

2.3.1. 諮問会議の委員
Advisory Board Participation

諮問会議は, 9名から11名の委員と議長で構成されています. 事務局が, 一般にCEOである諮問会議の議長を指名します. 事務局は, § 5.1 全ての作業部会と関連部会に対する要件で述べているように, ABに対する事務局の連絡員も指名します.

The Advisory Board consists of nine to eleven elected participants and a Chair. The Team appoints the Chair of the Advisory Board, who is generally the CEO. The team also appoints a Team Contact for the AB, as described in § 5.1 Requirements for All Working and Interest Groups.

残りの9名から11名の諮問会議の委員は, W3C諮問委員会によって, AB/TAG 推薦と選挙の手続きに従って選ばれます.

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

議長を除いて, 全ての諮問会議の委員の任期は, 2年間です. 任期はずれているので, 毎年5名もしくは6名の任期が終了します. 誰か個人が未完了の任期を埋めるために選ばれたなら, その個人の任期は, その任期の通常の満期に終了します. 通常の諮問会議の任期は, 7月1日に始まり, 6月30日に終了します.

With the exception of the Chair, the terms of all 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.

2.4. 技術諮問委員会(TAG)
Technical Architecture Group (TAG)

2001年2月に創られた, TAGの使命は, ウェブ技術体系について, まとめ役を果たすことです. この使命には, 次の3つの側面があります.

Created in February 2001, 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. TAGに提起された一般的なウェブ技術体系に関係する課題を解決すること.
    to resolve issues involving general Web architecture brought to the TAG;
  3. W3C内外の複数分野にまたがった技術に関して, 技術開発の調整を手助けすること.
    to help coordinate cross-technology architecture developments inside and outside W3C.

TAGは, 会員提案がウェブ技術体系に関係した理由で却下されたときに, 提案の抗議を聞き取りします. 諮問会議も参照して下さい.

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

TAGの権限の範囲は, ウェブ技術体系の技術的課題に限られます. TAGは, 一般にW3C諮問委員会, 諮問会議, 事務局が処理すべきW3Cの管理, 手続き, 組織統治の課題について議論すべきではありません. TAGの背景や権限の範囲についての詳しい情報, またTAG委員に期待される適正に関しては, TAG憲章 [TAG憲章]を参照して下さい.

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.

事務局は, TAGに対する2つのメーリングリストを利用できるようにしなければなりません.

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

TAGは, 追加の特定の項目に対する公開のメーリングリストの作成を要求してもよいです. TAGのいくつかの議論(例えば, 提案の抗議)のためであれば, TAGは, 会員限定となるメーリングリストを利用してもよいです.

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.

TAGは, 会議ごとの要約を, 諮問委員会や他の部会の議長に送るべきです. TAGは, 諮問委員会の会議の度に, 自身の活動報告も行うべきです.

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.

TAGが課題の解決のために投票を行う場合, TAGの各参加者は, (指名されたか, 選任されたか, 議長であるかに関わらず)1票を持ちます. TAG憲章の投票 [TAG憲章]の節, およびこの手続き文書の一般的な投票についての節も参照して下さい.

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.

TAGの詳細(例えば, TAGの委員の一覧, メーリングリストの情報, TAGの議事の要約)は, TAGホームページ [TAG-HP]で確認できます.

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

2.4.1. 技術諮問委員会の委員 Technical Architecture Group Participation

TAGは, 次の人々から構成されます.

The TAG consists of:

事務局は, 委員の1人でなければならないTAGの議長を指名します. 事務局は§ 5.1 全ての作業部会と関連部会に対する要件で述べているように, TAGに対する事務局の連絡員 [事務局の連絡員]も指名します.

The Team appoints the Chair of the TAG, who must be one of the participants. The team also appoints a Team Contact [TEAM-CONTACT] for the TAG, as described in § 5.1 Requirements for All Working and Interest Groups.

選任された, またはディレクターに指名されたTAGの委員の任期は2年間です. 任期はずれているので, 毎年3名の選任された委員の任期と, 1名もしくは2名の指名された委員の任期が終了します. 誰か個人が未完了の任期を埋めるために指名されたか選任されたならば, その個人の任期は, その任期の通常の満期に終了します.

The terms of elected and Director-appointed 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.

ディレクターは, 諮問委員会が委員を選任した結果を公表した後に, 指名した委員を公表してもよいです.

The Director may announce the appointed participants after the results for the Advisory Committee election of participants have been announced.

2.5. 諮問会議と技術諮問委員会の委員
Advisory Board and Technical Architecture Group Participation

諮問会議TAGの委員は, W3Cで特別な役割を持っています. 委員らは, 特定の通信網, 技術, 企業, 利用者のためだけでなく, ウェブのための最善の解決方法を見つけるよう, 最善の判断を行うことを期待されて, 会員から選任され, ディレクターから指名されています. 諮問会議とTAGの委員は, 定期的に全てに参加することを期待されています. 諮問会議とTAGの委員は, 諮問委員会の会議に出席すべきです.

Advisory Board and TAG participants have a special role within W3C: they are elected by the Membership and appointed by the Director 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.

諮問会議とTAGに選任または指名された人物は, W3C会員全体やウェブ界隈の必要性を満たすために, 個々の能力の中で活動します. その人物が会員の代表者であろうが, 外部の専門家であろうが, その役割における活動は, 諮問会議またはTAGでの活動とは引き離され, 別個のものです.

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.

個人が諮問会議またはTAGに参加するのは, その個人の任期が始まった瞬間から, (例えば, 任期の終了によって)席を退任するまでの間です. 諮問会議やTAGの委員は, その委員の雇用主の営業利益を主張しないにも関わらず, その委員らの参加は, (AB/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).

TAGまたはABへの参加は, 選任または指名された特定の人物に地位を与え, 委員の席は, 他の誰にも委任してはなりません.

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.

2.5.1. 諮問会議と技術諮問委員会の委員の制限
Advisory Board and Technical Architecture Group Participation Constraints

W3C会員の多様性が表現されることを確実にするため, 諮問会議TAGにおける若干の席が割り当てられています.

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:

2.5.2. 諮問会議と技術諮問委員会の選挙
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 Director should announce appointments no later than the start of a nomination period as part of the Call for Nominations.

TAGの定期で予定されている選挙において, 最小と最大の対象となる席は同じです. その年に任期が終わる3席に, 退任したか, もしくは新しく選任されたメンバーが席を努め始めるまでに, 退任するであろう他の席の数を加えた数です.

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.

ABの定期で予定されている選挙において, 最小と最大の対象となる席は異なります. 最大の数は, その年に任期が終了する5席または6席に, 退任したか, もしくは新しく選任されたメンバーが席を努め始めるまでに, 退任するであろう他の席の数を加えた数です. 最小の数は, 前の年から占められている席にその数を加えたときに, ABの最小の大きさ(9名)に達するような数です.

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.

各会員(または関連会員のグループ)は, 1名の候補者を推薦してもよいです. 推薦は, 候補者の同意を得なければなりません. 候補者が会員の代表として推薦されるためには, その候補者は会員の代表の資格を得なければならず, 会員の諮問委員会の委員は, 推薦に作業部会における会員の代表者に対して必要な情報(と同じ内容)を付け加えなければなりません. 候補者が外部の専門家として推薦されるためには, その候補者は作業部会における外部の専門家に対して必要な情報(と同じ内容)を提供しなければならず, 推薦した諮問委員会の委員はその情報を推薦に付け加えなければなりません. 候補者が事務局の代表者として推薦されるためには, 推薦する諮問委員会の委員は, 事務局の運営から最善の確実な賛成を得なければなりません. 候補者は, 会員組織の従業員である必要はなく, W3C特別研究員でもよいです. 推薦の書式は, 候補者の第一の所属を問わなければならず, その所属は投票用紙に報告されるでしょう. ほとんどの候補者において, 第一の所属は, その人の雇用主で, W3Cのデータベースのその人の所属と一致するでしょう. 契約者や外部の専門家において, 第一の所属は, 通常, その契約者が契約している企業か, 外部の専門家の状況によります. 状況によって(例えば, コンサルタントが1つの組織のみをコンサルティングしている場合には), 第一の所属は, 候補者がコンサルティングしている組織になってよいです. 所属の変更は, 候補者が再度推薦された場合に, 候補者の分野が異なる回答となるような場合に限定されます(その結果, 雇用の終了, また新しい雇用の了承は, 所属の変更です). (他の契約といった他の公式な関係は, 潜在的な利益衝突として開示されるべきです.) 各推薦は, 候補者についての若干の有益な寸評を付け加えるべきです.

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:

投票の際, 各会員(関連会員のグループ)は, 会員の望ましい順に候補者を並べた1票を提出してもよいです. 一旦, 投票を締め切った後, 事務局諮問委員会に結果を通知します. 同票の場合は, 後で述べる証明可能な無作為選択手続きが対象となる席を埋めるために利用されるでしょう.

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 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 short term, the verifiable random selection procedure described below will be used to assign the short term.

より詳細な内容については, 諮問会議とTAGの選挙をどのように系統立てるか [選挙の方法]を参照して下さい.

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

2.5.2.1. 証明可能な無作為選択手続き
Verifiable Random Selection Procedure

証明可能な無作為選択手続きを利用する必要がある場合(例えば, ABまたはTAGの選挙で同点の状況, もしくは短い任期を埋めるために“くじ引き”を行う必要がある場合), W3Cは, RFC 3797 [RFC3797]で定義された無作為で証明可能な選択手続きを利用します. この手続きは, (他に指定がなければ, 姓のアルファベット順の)名前の入力された一覧を“結果の順番”で並び替えます.

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 short 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は, 次の場合にこの手続きを適用します.

W3C applies this procedure as follows:

  1. N人が(Nより少ない)M席に対して同点の場合. この場合, 同点だったN人の人物の名前のみが, 手続きに入力として提供されます. M席は, 結果の順番を基に割り当てられます.
    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. 全ての選任される人物か確定した後で, N人が(Nより少ない)M席の短い任期に適任な場合. この場合, それらのN人の人物の名前のみが, 手続きに入力として提供されます. 短い任期は, 結果の順番を基に割り当てられます.
    After all elected individuals have been identified, when N people are eligible for M (less than N) short terms. In this case, only the names of those N individuals are provided as input to the procedure. The short terms are assigned in result order.

2.5.3. 諮問会議と技術諮問委員会の退任
Advisory Board and Technical Architecture Group Vacated Seats

諮問会議またはTAGの委員は, 次のいずれかの場合に席を退任します.

An Advisory Boardまたは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:

3. W3C部会の共通の指針
General Policies for W3C Groups

この節は, W3C部会に対する参加, 会議の要件, 最終決定に関する共通の指針について述べています. これらの指針は, 諮問委員会, 諮問会議, TAG, 作業部会, 関連部会参加者に適用されます.

This section describes general policies for W3C groups regarding participation, meeting requirements, and decision-making. These policies apply to participants in the following groups: Advisory Committee, Advisory Board, TAG, Working Groups, and Interest Groups.

3.1. 個人の参加基準
Individual Participation Criteria

W3Cに参加するために, 個人が証明を期待されている3つの資質があります.

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.

W3Cの活動への参加のために, 自分の組織から個人を指名した諮問委員会の委員は, 指名した人の資質を評価し証明することに責任があります.

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.

何らかのW3Cの活動の参加者は, W3C倫理規定および職業行為規定 [CEPC]の条件と精神, およびW3C特許指針[特許指針]の“開示情報”で説明されている参加者の要件を遵守しなければなりません.

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

ディレクターは, (ABおよびTAGも含め)何らかの部会の参加者を, 参加者の原因で活動停止にしたり, 解任したりしてもよいです. なお, その原因には, この手続き文書の要件, 会員規約, 有効な法令に応じなかった場合を含みます.

The Director may suspend or remove for cause a participant in any group (including the AB and TAG), where cause includes failure to meet the requirements of this process, the membership agreement, or applicable laws.

3.1.1. 利益衝突の指針
Conflict of Interest Policy

W3Cの作業に実質的に加わっている個人は, W3Cでの個人の役割と利益衝突が生じる関係性が分かった場合に, その重要な関係性を開示しなければなりません. これらの開示情報は, 個人の所属が変わった場合や, (例えば, 個人がW3Cに加入または離脱した組織と関係があることで)W3Cとの関係が変わった場合に, 最新に保たれなければなりません. W3Cの部会について述べたこの文書の各節は, それらの部会に対する開示の仕組みについてより詳細な情報を提供します.

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.

部会内の役割を果たす, 利益衝突が生じる恐れのある個人の力量は, その個人の所属に依存します. それらの所属が変わった場合, その個人の役割の割り当ては, 評価されなければなりません. 役割は, 適切な手続きによって再び割り当てられてもよいです. 例えば, ディレクターは, 現在の部会の議長が所属を変えたときに, (例えば, 利益衝突の恐れがある場合, もしくは, 議長の新しい雇い主がW3Cの活動の中で多くの代表を務めていることになるであろう恐れがある場合,) 新しい議長を指名してもよいです.

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

これらの事実について助言を求める個人は, 事務局に連絡すべきです.

Individuals seeking assistance on these matters should contact the Team.

事務局の人員は, W3C事務局の利益衝突指針 [衝突指針]を前提としています.

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

3.1.2. 会員組織を代表する個人
Individuals Representing a Member Organization

一般に, W3Cの公式な定員の中の会員を代表する個人は, 会員組織の従業員です. ただし, 諮問委員会の委員は, 会員を代表するのに, 従業員でない人を指名してもよいです. 従業員でない会員の代表者は, その個人が参加している事務局や部会において, 所属との関係を開示しなければなりません.

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 Director may decline to allow an individual designated by an Advisory Committee representative to participate in a group.

部会の憲章は, W3Cの会員(もしくは関連会員のグループ)を代表する個人の人数を制限してもよいです.

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

3.2. 会議
Meetings

W3Cの部会は, (諮問委員会, 諮問会議, TAG, 作業部会を含めて)この節の会議の要件に注意すべきです.

W3C groups (including the Advisory Committee, Advisory Board, TAG, and Working Groups) should observe the meeting requirements in this section.

W3Cは, 会議を次の2つの形式に区分しています.

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. 分散型の会議は, ほとんどの出席者が, 遠隔で(例えば, 電話, ビデオ会議, IRC(訳注:インテリジェント遠隔制御)で)参加することが期待される会議です.
    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.

会議の案内は, 全ての適切な部会のメーリングリスト, すなわち, 予期される会議の参加者に最も関係するメーリングリストに送られるべきです.

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 requirements for organizing a meeting:

対面での会議
Face-to-face meetings
分散型の会議
Distributed meetings
会議の案内
Meeting announcement (before)
8週間前*
eight weeks
1週間前*
one week
協議事項の共有
Agenda available (before)
2週間前
two weeks
24時間前 (ただし, 会議が週末または祝日の後に予定されている場合は, もっと早い時期)
24 hours (or longer if a meeting is scheduled after a weekend or holiday)
参加の確認
articipation confirmed (before)
3日前
three days
24時間前
24 hours
要処理事項の共有
Action items available (after)
3日後
three days
24時間後
24 hours
議事録の共有
Minutes available (after)
2週間後
two weeks
48時間後
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.3. 合意
Consensus

合意は, W3Cの核となる価値です. 合意を促進するために, W3C手続き文書は, 部会が全ての見解や異議, また, それらを解決する試みを確実に熟慮するよう, 議長に求めています. それらの見解や異議が部会の活動的な参加者から述べられていようが, 他の所(例えば, 他のW3C部会, 他の組織の部会, 一般の社会全体)から述べられていようが, どちらであってもです. 決定は, (対面または分散型の)会議を通して, もしくは, eメールを通して行われてもよいです.

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

注意: ディレクター, CEO, COO(訳注:最高業務執行責任者)は, 諮問委員会の中の合意を判断する役割があります.
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:
集まりの中の少なくとも1人が正式な異議を示している場合.
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.

全員の合意は可能性が非常に低いので, 部会は, 相当数の支持や少数の棄権であれば, 決定の合意を形成するように努力すべきです. 手続き文書は, 決定を行うための動きに同意する, 参加者の割合を特段必要としていません. 広い範囲に及ぶ無関心(すなわち, わずかな支持とたくさんの棄権)がある場合の決定を避けるため, 部会は, 決定を記録しようとする前に, 効力のある支持の最小の閾値を決定すべきです. 適切な割合は, 部会の大きさや決定の性質によって変わってもよいです. 憲章は, 決定の合意の閾値の要件を含んでもよいです. 例えば, 適切な参加者の過半数(すなわち, 50%以上の何らかの値)を必要とするかもしれません.

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.

3.3.1. 不同意の管理
Managing Dissent

場合によっては, 憲章の全ての観点の注意深い考察の後でさえ, 部会は, 部会自身で合意に至ることができないかもしれません. 議長は, 不同意だった(すなわち, 少なくとも1つの正式な異議があった)決定と記録してもよく, そのため, 部会は(例えば, 適切な時期に成果を提供するといった)進展を行うことができます. 反対者は, 単に決定を受け入れられないというだけでは, 部会の作業を止めることができません. 議長が, 部会は反対者の正当な関心事に可能な限り責任において適切に熟慮したと考えるならば, 部会は進むべきです.

In some cases, even after careful consideration of all points of view,0 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 progress1 (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.

3.3.2. 正式な異議の記録と報告
Recording and Reporting Formal Objections

W3Cの手続きにおいて, 個人は, 決定に正式な異議を表明してもよいです. 部会の決定への正式な異議は, ディレクターが関連する決定を評価する一部として(例えば, 技術報告書を前進させる要請の返答の中で)熟慮するよう, 審査者が要請するものです.

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 by the Director.

それぞれの正式な異議の記録は, 誰でも利用できなければなりません. 諮問委員会への(文書の)審査の要請は, どんな正式な異議があるか明確にしなければなりません.

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.

3.3.3. 課題への正式な取組み
Formally Addressing an Issue

この文書の文脈で, ある課題が公開され, その課題を挙げた審査者に実質的に返答したとき, 部会はその課題を正式に取り組んだことになります. 実質的な返答は, 決定に対する論理的根拠(例えば, 技術的説明, 憲章の該当範囲を指し示すこと,文書の必要な部分を指し示すこと)を含んでいるべきです. 返答の適切さは, W3Cの審査者が一般的に技術的に何を感じるのかを考えることで測られます. 部会が審査者の意見が誤解に基いていると考えるならば, 部会は, 決定に至る前に説明を求めるべきです.

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.

礼儀として, 議長と審査者は, 返答と承認の日程の見込みを設定すべきです. 部会は, 審査者の最初の意見に適時返答すべきです. 部会は, 部会の実質的な返答を審査者が承認する期限を設定すべきです. 審査者は, 部会の工程を止めることはできません. 審査者にとって, 実質的な返答を承認したり, それに意見したりするのに1週間以上必要なのが一般的です. 部会の審査者に返答する責務は, 無理の無い時間が経過すると終わる訳ではありません. しかしながら, 審査者は, 自分達の意見が適時部会に送られていないとき, より軽く扱われるであろうことを理解すべきです.

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

3.3.4. 新しい情報が提供された場合の決定の再考
Reopening a Decision When Presented With New Information

議長は, 次のものを含む新しい情報が提供されたときに, 決定を再考してもよいです.

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

議長は, 決定が再考されることになったことを記録すべきで, 部会の参加者から要求があった場合は記録しなければなりません.

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

3.4. 投票
Votes

技術的な議論を通して合意に至る全ての可能な手段と妥協が上手くいかず, 膠着状態を打破するには投票が必要であると, 議長が決めた後にのみ, 部会は, 実質的な課題を解決するために, 投票を行うべきです. この場合, 議長は, (例えば, 会議の議事録または記録されたeメールの文面の中に)次のことを記録しなければなりません.

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

実質的な課題を解決する目的で投票するためには, 投票者は部会の参加者なければなりません. 各組織が部会の中で(外部の専門家も含め)複数の参加者を代表している場合でさえ, その代表する組織は多くて1票しか持ってはなりません. 投票の目的のために次のように扱われます.

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:

他に憲章で決まっていない限り, 外部の専門家は投票してもよいです.

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.

諮問委員会の投票についての手続きは別途説明します.

Procedures for Advisory Committee votes are described separately.

3.5. 議長決定および部会決定への抗議
Appeal of Chair Decisions and Group Decisions

部会は, 対話を通じて課題を解決します. 決定に強く異議を唱える個人は, 議長に(例えば, 投票の結果として決まった決定に対して)何らかの正式な異議を表明すべきです.

Groups resolve issues through dialog. Individuals who disagree strongly with a decision should register with the Chair any Formal Objections (e.g., to a decision made as the result of a vote).

この文書の別の部分で詳細に述べているとおり, 作業部会または関連部会議長は, 自分自身の判断に基き明確な決定を行う特権を持っています. このような決定は, 議長決定と呼ばれます. 対照的に, 作業部会または関連部会議長が部会の合意を判断することに基づいて, もしくは投票(§ 3.4 投票参照)に従って行った決定は, 部会決定と呼ばれます.

As detailed in other parts of this document, 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 § 3.4 Votes) are called Group Decisions.

部会の参加者が, それらの事案は, 部会または議長によって十分に熟慮されたものでないと考える場合には, その参加者は, ディレクターに(諮問委員会の委員を通じて会員組織の代表者が)その決定を承認するか否認するか要求してもよいです. このことは, 部会決定への抗議または議長決定への抗議と呼ばれます. 参加者は, 事務局の連絡員に自分達の要請のことを知らせることもすべきです. 事務局への連絡は, 部会の参加者が正当な手続きに関係する事案を挙げた場合, ディレクターに知らせなければなりません.

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.

3.6. 部会からの辞任
Resignation from a Group

W3C会員または外部の専門家は, 部会を辞めてもよいです. 諮問委員会の委員または外部の専門家から事務局への書面での告知によって, 会員とその代表者, または外部の専門家は, 関係する部会から辞めることになると考えられるでしょう. 事務局は, その告知を記録しなければなりません. ある部会を辞めた後に残る債務についての情報については, W3C特許指針[特許指針]の“作業部会からの除名と辞任” を参照して下さい.

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.

4. 普及指針
Dissemination Policies

事務局は, W3Cの中や一般社会への情報伝達(例えば, ニュースの配信, 公式発表, ウェブサイトの管理や特典の利用, カレンダーの管理)に対して責任があります. 会員は, W3Cの中の自分達の仕事について, 発行された公式発表より重要な, 事務局による審査を要求すべきです.

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:

W3Cの会議, ワークショップ, 審査の締切と並行して会員を維持するために, 事務局は定期的な(例えば, 毎週の)ニュースの配信を会員に提供したり, W3Cの公式行事のカレンダー [カレンダー]を管理します. 会員は, そのカレンダーに入れ込むために, 事務局に予定や行事の情報を送ることを促されています.

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.

4.1. 機密レベル
Confidentiality Levels

(W3Cウェブサイトや, W3Cの会議などで)W3Cの情報を利用する3つの主な機密レベルがあります. 公開, 会員限定, 事務局限定です.

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.

W3Cによって利用可能にされる多数の情報は公開である一方, “会員限定”の情報は, 会員組織の代表者, 外部の専門家, 諮問会議, TAG, 事務局を含む, 認定された関係者のみ利用可能です. 例えば, 作業部会の憲章の中には, 部会の出来事に対して, 会員限定の機密レベルを指定してもよいです.

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:

事務局は, 会員限定の情報の機密を保護する仕組みを提供しなければならず, 認定された関係者がその情報を望ましく利用できることを確実にしなければなりません. 文書は, 会員限定の機密レベルが必要かどうか, 明確に示すべきです. 情報の断片の機密レベルに確信がない人物は, 事務局に連絡すべきです.

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

4.1.1. 機密レベルの変更
Changing Confidentiality Level

会員の恩恵として, W3Cは, 確かな形の情報伝達のために, 事務局限定会員限定の経路をいくつか提供しています. 例えば, 諮問委員会の委員は, 事務局限定の経路に審査意見を送ることができます. しかしながら, 技術報告書の開発手続きといった, 重要な公開の成果のW3C手続きにおいて, 意思決定に影響する情報としては, 公に利用可能なことも重要です. 事務局は, 事務局限定の情報を作業部会や一般とやり取りする必要があるかもしれません. 同様に, 部会自体の出来事が会員限定の作業部会は, 技術報告書の開発手続きに属する公開の情報を出さなければなりません.

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.

5. 作業部会と関連部会
Working Groups and Interest Groups

この文書は, 2種類の部会を定義しています.

This document defines two types of groups:

作業部会.
Working Groups.
作業部会は, 典型的に成果(例えば, 勧告工程にある技術報告書, ソフトウェア, テストツール, 他の部会の成果の審査)を作り出します. W3C特許指針[特許指針]で述べられている追加の参加者の要件があります.
Working Groups typically produce deliverables (e.g., Recommendation Track technical reports, software, test suites, and reviews of the deliverables of other groups). There are additional participation requirements described in the W3C Patent Policy [PATENT-POLICY].
関連部会.
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; see information about maturity levels for Interest Groups.

5.1. 全ての作業部会と関連部会に対する要件
Requirements for All Working and Interest 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 Director appoints (and re-appoints) Chairs for all groups. The Chair is a Member representative, a Team representative, or an Invited Expert (invited by the Director). 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.

5.2. 作業部会と関連部会
Working Groups and Interest Groups

作業部会関連部会は, 異なる目的を持つにも関わらず, 同じ特質を持っているので, 次からの節で一緒に定義します.

Although Working Groups and Interest Groups have different purposes, they share some characteristics, and so are defined together in the following sections.

5.2.1. 作業部会と関連部会の参加者の要件
Working Group and Interest Group Participation Requirements

3種類の作業部会の参加者がいます. 会員の代表者, 外部の専門家, (事務局の連絡員を含む)事務局の代表者 です.

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

4種類の関連部会の参加者がいます. 作業部会と同じ3種類に加えて, 参加要件がメーリングリストに参加することのみである関連部会には, 一般の参加者がいます.

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.

個人は, 作業部会または関連部会の実在している間に, いつ部会の参加者になってもよいです. W3C特許指針[特許指針]の“既に設立されている作業部会に参加する”の関係する要件を参照して下さい.

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.

速やかに進展させるため, 作業部会は, 小さく(典型的に15名より少なく)なるように意図されており, 憲章で定義した分野の専門家で構成されます. 作業部会が効率的であるには大きく成長し過ぎた場合, W3Cは, 関連部会(議論の公共の場)とより小さい作業部会(強く専念する参加者の核と成る部会)に分割してもよいです.

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

W3C特許指針[特許指針]の“ライセンス義務”にある, 作業部会参加者のライセンス義務や, 特許指針の“W3C RF(訳注:ロイヤリティフリー)ライセンス要件からの除外”の特許請求除外手続も参照して下さい.

See also the licensing obligations on Working Group participants in “Licensing Obligations” in the W3C Patent Policy [PATENT-POLICY], and the patent claim exclusion process in “Exclusion From W3C RF Licensing Requirements” in the Patent Policy.

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

作業部会における会員の代表者として個人を指名するために, 諮問委員会の委員は, 議長事務局の連絡員に, 全ての次に示す情報を, (W3C特許指針[特許指針]の参加者の要件を含めて)参加の要請や憲章で必要とされている全ての他の情報を加えたうえで, 提供しなければなりません.

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. その人物が代表するW3C会員の名称と, その人物がその会員組織の従業員であるかどうか.
    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:

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

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

誰かを作業部会における外部の専門家として指名するために, 議長は, 事務局の連絡員に通知し, 選んだ根拠を提供しなければなりません. 議長事務局の連絡員が指名について合意しない場合, ディレクターは, その人物が作業部会に参加するために招待されるかどうか決定します.

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

議長は, 作業部会における外部の専門家として, W3C会員の従業員である人物を指名すべきではありません. 議長は, 憲章によって課された参加の条件を出し抜くために, 外部の専門家の立場を利用してはなりません.

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:

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

5.2.1.5. 作業部会における事務局の代表者
Team Representative in a Working Group

W3Cの運営から指名された場合, その人物は, 作業部会における事務局の代表者です.

An individual is a Team representative in a Working Group when so designated by W3C management.

事務局の代表者は, その人物が作業部会に参加した瞬間から, 次のいずれかが起こるまで作業部会に参加します.

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

事務局は, ディレクターが作業部会の作成を通知してから, 部会が終了するまで作業部会に参加します.

The Team participates in a Working Group from the moment the Director announces the creation of the group until the group closes.

5.2.1.6. 関連部会における事務局の代表者
Team Representative in an Interest Group

参加要件が関連部会のメーリングリストの購読だけでない場合で, W3Cの運営から指名された場合, その人物は, 関連部会における事務局の代表者です.

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.

5.2.2. 作業部会と関連部会の憲章の開発
Working Group and Interest Group Charter Development

W3Cは, 会員や事務局の関心に基づいた憲章を作成します. 事務局は, 新しい作業部会または関連部会の憲章を開発し始めたとき, 諮問委員会に通知しなければなりません. このことは, 正式な提案が確認できるようになる前であっても配慮されるべきです. 諮問委員会の委員は, 諮問委員会の議論一覧に意見を返してもよいです.

W3C creates a charter 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.

W3Cは, いつでも作業部会または関連部会の憲章の作業に取り掛かってよいです.

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

5.2.3. 作業部会または関連部会の憲章の諮問委員会による審査
Advisory Committee Review of a Working Group or Interest Group Charter

ディレクターは, 新しいまたは本質的に修正された, 作業部会または関連部会の憲章ごとに, 次のいずれかの場合を除いて諮問委員会による審査を依頼しなければなりません.

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

審査の期間は, 少なくとも28日間取らなければなりません. 次に示す内容は, 諮問委員会による審査を必要としないであろう本質的な変更の例です. 例えば, 範囲内の成果の追加, 事務局の連絡員の変更, 議長の変更です. ただし, このような変更は, 諮問委員会および作業部会の参加者または関連部会の参加者に通知されなければならず, 根拠が提供されなければなりません.

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 Director’s 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.

そのような要求は, 審査の要請に対する会員の回答意見と一緒に提出されなければなりません. 何らかのそのような要求を受領した上で, ディレクターは, 作業部会の参加の要請が, 憲章の審査の要請から少なくとも60日後に行われることを確実にしなければなりません.

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 Director must ensure that the Call for Participation for the Working Group occurs at least 60 days after the Call for Review of the charter.

5.2.4. 作業部会または関連部会における参加の要請
Call for Participation in a Working Group or Interest Group

作業部会または関連部会憲章に対する諮問委員会による審査の後, ディレクターは, 諮問委員会に参加の要請を行ってもよいです. ディレクターが参加の要請を行う前に, 憲章は, 審査意見によって修正されてもよいです.

After Advisory Committee review of a Working Group or Interest Group charter, the Director may issue a Call for Participation to the Advisory Committee. Charters may be amended based on review comments before the Director issues a Call for Participation.

新しい部会に対して, この要請の発表は, 公式に部会を作ります. その発表は, 憲章への参照, 部会の議長(ら)の名前, 事務局の連絡員(ら)の名前を含まなければなりません.

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

諮問委員会の委員は, 作業部会または関連部会の憲章を, 作成もしくは実質的に修正するディレクターの決定に対して, 諮問委員会への抗議を提出してもよいです.

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

5.2.5. 作業部会と関連部会の憲章の延長
Working Group and Interest Group Charter Extension

何も他の実質的な修正無しに, 作業部会または関連部会の憲章を延長するために, ディレクターは, 諮問委員会に延長を通知します. また, その通知は, 新しい期間を示さなければなりません. その通知は, 延長の根拠, 憲章への参照, 部会の議長(ら)の名前, 事務局の連絡員(ら)の名前, 部会に参加する場合の説明も含まなければなりません.

To extend a Working Group or Interest Group charter with no other substantive modifications, the Director announces the extension 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, 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 Director’s decision regarding the extension of a Working Group or Interest Group charter.

5.2.6. 作業部会と関連部会の憲章
Working Group and Interest Group Charters

作業部会または関連部会の憲章は, 全ての次に示す情報を含まなければなりません.

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

W3C特許指針[特許指針]の“W3C仕様書のライセンスの目標”における憲章の要件も参照して下さい.

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:

上記の全てのデータは, 示された分類を使用して, 採用する作業部会の憲章の中で特定されなければなりません.

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

採用された草案除外された草案は, それぞれ全体が何らかの修正なしに採用されなければなりません. 提案された憲章は, 開始され終了された除外された草案を公表する中で生じた, どの除外された時期のものか日付をはっきりと述べなければなりません. W3C特許指針[特許指針]の“既に設立されている作業部会に参加する”を通じて, このことは, 作業部会に参加する中で除外が直接行われるのみであることを, 潜在的に意味しています.

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

憲章は, この文書で必要とされる規定以外の規定を含んでもよいです. 憲章は, どの追加の規定がW3C手続き文書の規定を超えた制限(例えば, 作業部会内の同じ会員組織や関連会員のグループを代表する参加者の人数の制限)を課しているか強調して示すべきです.

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

5.2.7. 作業部会と関連部会の終了
Working Group and Interest Group Closure

作業部会または関連部会の憲章は, 部会の期間を指定します. ディレクターは, 次のいずれかの状況において, 憲章で指定された期日以外を優先して, 部会を終了することを決めてもよいです.

A Working Group or Interest Group charter specifies a duration for the group. The Director may decide to close a group prior to the date specified in the charter in any of the following circumstances:

ディレクターは, 諮問委員会への通知によって, 作業部会または関連部会を終了します. 諮問委員会の委員は, 諮問委員会への抗議を提出してもよいです.

The Director closes a Working Group or Interest Group by announcement to the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal.

作業部会を終了することは, W3C特許指針[特許指針]に関する影響があります.

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

6. W3C Technical Report Development Process

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:

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

6.1. W3C 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 page https://www.w3.org/TR [TR].

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

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] which grants Royalty-Free IPR licenses to implementations. See § 6.2 The W3C Recommendation Track for details.
Notes
Groups can also publish documents as W3C Notes, typically either to document information other than technical specifications, such as use cases motivating a specification and best practices for its use, or to clarify the status of work that is abandoned. See § 6.3 Working Group and Interest Group Notes 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.1.1. General requirements for Technical Reports

Every document published as part of the technical report development process must be a public document. The index of W3C technical reports [TR] is available at the W3C Web site. 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:

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 § 5.2.1 Working Group and Interest Group Participation Requirements 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.1.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.1.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 Director 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 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.1.3. Classes of Changes

This document distinguishes the following 4 classes of changes to a specification. The first two classes of change are considered editorial changes, the latter two substantive 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.

6.1.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.1.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.1.5. Candidate Changes

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

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

6.1.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.1.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.2. The W3C Recommendation Track

When advancing a technical report to Recommendation, typically a series of Working Drafts are published, each of which refines a document under development to complete the scope of work envisioned by a Working Group's charter. For a technical specification, once review suggests the Working Group has met their requirements satisfactorily for a new standard, there is a Candidate Recommendation phase. This allows the entire W3C membership to provide feedback on the specification, while the Working Group formally collects implementation experience to demonstrate that the specification works in practice. The next phase is a Proposed Recommendation, to finalize the review of W3C Members. If the Director determines that W3C Member review supports a specification becoming a standard, 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.
  6. Possibly, publication as an Amended Recommendation.
Basic W3C Recommendation Track First Public Working Draft (FPWD) - Exclusion opportunity WG decision Director's approval Working Draft (WD) Publish a new Working Draft WG Decision: review needed, or No change for 6 months Advance to Candidate Recommendation Director'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 + Director’s approval Publish revised Candidate Recommendation WG Decision Director’s approval Advance to Proposed Recommendation Director's approval Return to Working Draft WG or Director decision e.g. for further review Proposed Recommendation (PR) - Advisory Committee review Advance to Recommendation Advisory Committee Review Director's Decision Return to Candidate Recommendation AC Review, Director Decision e.g. for editorial changes Return to Working Draft Advisory Committee review and Director'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 (updated in 2017) Patent Policy, these correspond to “Last Call Working Draft” in the Patent Policy [PATENT-POLICY-2017]; Under the 2020 Patent Policy, these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

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

The Director may decline a request to advance in maturity level, requiring a Working Group to conduct further work, and may require the specification to return to a lower maturity level. The Director must inform the Advisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity level is declined and the specification is returned to a Working Group for further work.

6.2.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, or makes substantive corrections to a Recommendation that is not maintained by a Working Group, 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 the 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 the 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:
An Amended Recommendation
An Amended Recommendation is a Recommendation that is amended to include substantive changes that do not add new features, and is produced by the W3C at a time when the Recommendation does not fit within the charter of any active Working Group. Since the W3C team rather than a Working Group moves it through the Process, there are implications regarding the scope of Royalty-Free IPR licenses granted under the W3C Patent Policy [PATENT-POLICY].
A Superseded Recommendation
A Superseded Recommendation is a specification that has been replaced by a newer version that the 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.2.12.3 Abandoning a W3C Recommendation: it is the same document, updated. Explicitly declaring a documented superseded, using the process documented in § 6.2.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 the 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, the 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].

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.2.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 Director will consider (though not be limited to):

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.2.3. Advancement on the Recommendation Track

For all requests to advance a specification to a new maturity level other than Note (called Transition Requests), 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 Director's 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 Director's decision on an Advisory Committee Review.

6.2.4. Updating Mature Publications on the Recommendation Track

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

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

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

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

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

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.2.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 Director must announce the publication of a First Public Working Draft to other W3C groups and to the public.

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

Possible next steps for any Working Draft:

6.2.7. Transitioning to Candidate Recommendation

To publish a Candidate Recommendation, in addition to meeting the requirements for advancement a Working Group, or in the case of a candidate Amended Recommendation (a document intended to become an Amended Recommendation), the W3C:

The first Candidate Recommendation publication after approval of a Transition Request is always a Candidate Recommendation Snapshot. The Director 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.2.8. Revising a Candidate Recommendation

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

The Director 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.2.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:

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.2.9. Transitioning to Proposed Recommendation

In addition to meeting the requirements for advancement,

A Working Group, or for a proposed Amended Recommendation, the W3C:

The Director:

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.2.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.2.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.2.11. Revising a W3C Recommendation

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

6.2.11.1. Revising a Recommendation: Markup Changes

A Working group may request republication of a Recommendation, or if there is no Working Group chartered to maintain a Recommendation W3C may republish the Recommendation, to make corrections that do not result in any changes to the text of the specification. (See class 1 changes.)

6.2.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 resolution to publish, may request publication of a Recommendation or W3C may publish a Recommendation to make this class of change without passing through earlier maturity levels. (See class 2 changes.)

6.2.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 change. To validate this, the Working Group must request a Last Call for Review of Proposed Changes, followed by an update request. See § 6.2.11.5 Incorporating Candidate Changes.

Alternatively, a Working Group may incorporate the changes and publish as a Candidate Recommendation, or if no Working Group is chartered to maintain a Recommendation W3C may publish a candidate Amended Recommendation, and advance the specification from that state. If the publication was requested by the W3C team in the absence of a Working Group, the resulting Recommendation will be called an Amended Recommendation. (See class 3 changes.)

6.2.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, 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 change. To validate this, the Working Group must request a Last Call for Review of Proposed Changes, followed by an update request. See § 6.2.11.5 Incorporating Candidate 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 was not approved for accepting 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.2.11.5. Incorporating Candidate Changes

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

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

The combination of the existing Recommendation with the proposed changes included in the Last Call for Review of Proposed Changes 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 Additions 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 changes into a single Last Call for Review of Proposed Changes. To facilitate review, a Last Call for Review of Proposed Changes 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 Changes, the W3C Decision may either be to reject the proposed change, or to clear the proposed change 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 change in response to review feedback it must issue another Last Call for Review of Proposed Change on the revised change before it can be incorporated into the main text.

Once all comments on a proposed change 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 change into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

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

6.2.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.2.12.1. Abandoning an Unfinished Technical Report

Any technical report no longer intended to advance or to be maintained, and that is not being rescinded, should be published as a Working Group Note. This can happen if the Working Group decided to abandon work on the report, or the Director required the Working Group to discontinue work on the technical report before completion. If the Director closes a Working Group W3C must publish any unfinished technical report on the Recommendation track as Working Group Notes.

6.2.12.2. Rescinding a Candidate Recommendation

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

6.2.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 the 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.2.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 Director or via a request from any of the following:

The Director 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 Director must:

and should

If there was any dissent in the Advisory Committee review, the Director 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 Director'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.3. Working Group and Interest Group Notes

A Working Group Note or Interest Group Note (NOTE) is published by a chartered Working Group or Interest Group to provide a stable reference for a useful document that is not intended to be a formal standard, or to document work that was abandoned without producing a Recommendation.

Working Groups and Interest Groups may publish work as W3C Notes. Examples include:

Some W3C Notes are developed through successive Working Drafts, with an expectation that they will become Notes, while others are simply published. There are few formal requirements to publish a document as a W3C Note, and they have no standing as a recommendation of W3C but are simply documents preserved for historical reference.

In order to publish a Note, a Working Group or Interest Group:

Possible next steps:

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

6.4. 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. Advisory Committee Reviews, Appeals, and Votes

This section describes how the Advisory Committee reviews proposals from the Director and how Advisory Committee representatives initiate an Advisory Committee Appeal of a W3C decision or Director's decision. 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.

7.1. Advisory Committee Reviews

The Advisory Committee reviews:

7.1.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. They may also share their reviews with other Members on the Advisory Committee discussion list.

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

7.1.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 Director’s 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 Director has not announced the outcome, the Director should provide the Advisory Committee with an update.

7.2. 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 Director's decisions that do not involve an Advisory Committee review. These cases are identified in the sections which describe the requirements for the Director's 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.

7.3. 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. In the case of Advisory Board and TAG elections, “one vote” means “one vote per available seat”.

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 W3C Director 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 Director 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 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 Team review, the Director 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 the 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 request must also answer the following questions.

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

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 Director may reject a Submission request for a variety of reasons, including any of the following:

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 Boardacting 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 the 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), 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 1 March 2019 Process

This document is based on the 1 March 2019 Process. A Disposition of Comments, as well as a detailed log of all changes since then are available.

A diff comparing it to the 2019 edition of the Process is available. Note that due to overlapping changes, this diff may be somewhat difficult to review. In order to make review easier, several partial diffs, grouping related changes, are available as well, as detailed below.

Major Update to the Recommendation Track

Significant additions and modifications were made to the Recommendation Track. While the meaning of the various maturities and associated transition criteria are unchanged, important additions have been made to what can be done during CR and REC phases. These aim to facilitate maintenance of specifications, and to provide a Living Standards capability as a native capability of the W3C Recommendation Track.

Some minor simplifications have also been made:

A diff comparing the state before/after these changes is available.

Other Substantive Changes and Clarifications

A diff comparing the state before/after these changes is available.

Notable Editorial Changes

Final adjustements

Based on a cycle of review by the Advisory Committee and the broader community of the changes described above, a few final adjustments were made:

A diff comparing the state before/after these changes is available.

Changes since earlier versions

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

参考文献
References

標準の参考文献
Normative References

[CEPC]
[CEPC]
W3C倫理規定および職業行為規定. URL: https://www.w3.org/Consortium/cepc/
W3C Code of Ethics and Professional Conduct. URL: https://www.w3.org/Consortium/cepc/
[協力者規約]
[COLLABORATORS-AGREEMENT]
外部の専門家・協力者規約. URL: https://www.w3.org/Consortium/Legal/collaborators-agreement
Invited expert and collaborators agreement. URL: https://www.w3.org/Consortium/Legal/collaborators-agreement
[衝突指針]
[CONFLICT-POLICY]
外部の職業活動に従事するW3C事務局人員のための利益衝突指針. URL: https://www.w3.org/2000/09/06-conflictpolicy
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文書ライセンス. URL: https://www.w3.org/Consortium/Legal/copyright-documents
W3C Document License. URL: https://www.w3.org/Consortium/Legal/copyright-documents
[特許指針]
[PATENT-POLICY]
W3C 2020 特許指針. URL: https://www.w3.org/Consortium/Patent-Policy-20200915/
The W3C 2020 Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy-20200915/
[PATENT-POLICY-2017]
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/
[PUBRULES]
Publication Rules. URL: https://www.w3.org/pubrules/
[RFC2119]
[RFC2119]
S. Bradner. 要求レベル指示のためのRFC用キーワード. 1997年3月. 現時点における最善の実践(ベストカレントプラクティス). URL: https://tools.ietf.org/html/rfc2119
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3797]
[RFC3797]
D. Eastlake 3rd. 公的に証明可能なNomcomランダム選択. 2004年7月. 情報. URL: https://tools.ietf.org/html/rfc3797
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://tools.ietf.org/html/rfc3797

有益な参考文献
Informative References

[AB-HP]
[AB-HP]
諮問会議ホームページ. URL: https://www.w3.org/2002/ab/
The Advisory Board home page. URL: https://www.w3.org/2002/ab/
[AC会議]
[AC-MEETING]
諮問委員会の会議(会員限定利用). URL: https://www.w3.org/Member/Meeting/
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/Member/Meeting/
[BG-CG]
[BG-CG]
共同部会とビジネス部会の手続き. URL: https://www.w3.org/community/about/agreements/
Community and Business Group Process. URL: https://www.w3.org/community/about/agreements/
[カレンダー]
[CALENDAR]
全ての予定されているW3C公式行事のカレンダー. URL: https://www.w3.org/participate/eventscal
Calendar of all scheduled official W3C events. URL: https://www.w3.org/participate/eventscal
[議長]
[CHAIR]
W3C作業/関連部会の議長. URL: https://www.w3.org/Guide/chair/role.html
W3C Working/Interest Group Chair. URL: https://www.w3.org/Guide/chair/role.html
[憲章]
[CHARTER]
作業部会または関連部会をどのように作るのか. URL: https://www.w3.org/Guide/process/charter.html
How to Create a Working Group or Interest Group. URL: https://www.w3.org/Guide/process/charter.html
[最新のAC]
[CURRENT-AC]
最新の諮問委員会の委員 (会員限定利用). URL: https://www.w3.org/Member/ACList
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList
[懲戒基準]
[DISCIPLINARY-GL]
懲戒処分の基準. URL: https://www.w3.org/2002/09/discipline
Guidelines for Disciplinary Action. URL: https://www.w3.org/2002/09/discipline
[選挙の方法]
[ELECTION-HOWTO]
諮問会議とTAGの選挙をどのように系統立てるか. URL: https://www.w3.org/2002/10/election-howto
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/2002/10/election-howto
[特別研究員]
[FELLOWS]
W3C特別研究員プログラム. URL: https://www.w3.org/Consortium/Recruitment/Fellows
W3C Fellows Program. URL: https://www.w3.org/Consortium/Recruitment/Fellows
[部会メール]
[GROUP-MAIL]
部会のメーリングリスト(会員限定利用). URL: https://www.w3.org/Member/Groups
Group mailing lists (Member-only access). URL: https://www.w3.org/Member/Groups
[案内]
[GUIDE]
合意の要領, a guidebook for W3C作業部会議長や協力者への案内書. URL: https://www.w3.org/Guide/
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/Guide/
[導入]
[INTRO]
手続き, 特許指針, 財務, 投資管理, 戦略的未来像(会員限定利用). URL: https://www.w3.org/Member/Intro
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro
[加入]
[JOIN]
W3Cに加入するには. URL: https://www.w3.org/Consortium/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会員規約. URL: https://www.w3.org/Consortium/Agreement/Member-Agreement
W3C Membership Agreement. URL: https://www.w3.org/Consortium/Agreement/Member-Agreement
[会員HP]
[MEMBER-HP]
会員ウェブサイト(会員限定利用). URL: https://www.w3.org/Member/
Member Web site (Member-only access). URL: https://www.w3.org/Member/
[会員一覧]
[MEMBER-LIST]
最新のW3C会員の一覧. URL: https://www.w3.org/Consortium/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]
W3Cの活動理念. URL: https://www.w3.org/Consortium/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憲章]
[TAG-CHARTER]
技術諮問委員会(TAG)憲章. URL: https://www.w3.org/2004/10/27-tag-charter.html
Technical Architecture Group (TAG) Charter. URL: https://www.w3.org/2004/10/27-tag-charter.html
[TAG-HP]
[TAG-HP]
TAGホームページ. URL: https://www.w3.org/2001/tag/
The TAG home page. URL: https://www.w3.org/2001/tag/
[事務局の連絡員]
[TEAM-CONTACT]
事務局の連絡員の役割. URL: https://www.w3.org/Guide/teamcontact/role.html
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/

索引
Index

この仕様書で定義された用語
Terms defined by this specification