W3C Process Document

15 September 2020

置換済. 最新のW3C手続き文書を参照して下さい.
Superseded; see the current W3C Process Document.

This version:
Latest published version:
最新のヴァージョンの日本語訳ではなく, 日本語訳で最新のものです.)
Editor's Draft:
Previous Versions:
Issue Tracking:
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)


ワールド・ワイド・ウェブ・コンソーシアム(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


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

ほとんどの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. 会員

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 会員共同体
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. 関連会員
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]. 諮問委員会メーリングリスト
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. 諮問委員会の会議
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:

  • 各段階のW3C会員の数.
    The number of W3C Members at each level.
  • W3Cの財務状態の概要.
    An overview of the financial status of W3C.
  • 事務局の大きさや, おおよその配置を含めた, 年次予算の配分.
    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. 証明可能な無作為選択手続き
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 or TAG participant’s seat is vacated when:

委員が所属を変わったが, 委員の制限に抵触しない場合, その委員の席は, 次の定期で予定されているその委員会の選挙のときに退任します.

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

退任された席は, 次の日程で埋められます.

Vacated seats are filled according to this schedule:

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

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)
eight weeks
one week
Agenda available (before)
two weeks
24時間前 (ただし, 会議が週末または祝日の後に予定されている場合は, もっと早い時期)
24 hours (or longer if a meeting is scheduled after a weekend or holiday)
Participation confirmed (before)
three days
24 hours
Action items available (after)
three days
24 hours
Minutes available (after)
two weeks
48 hours

* (例えば, 旅行の準備など)適切な計画となるよう, 議長は, 会議の日程や場所を十分に前もって通知する責任があります. 会議についてのより期間の短い通知は, 部会の参加者から何も異議が無いという条件で認められます.

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

3.3. 合意

合意は, 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:

集まりの中の人々の相当な数が決定を支持し, その集まりの中の誰も正式な異議を示していないこと. その集まりの中の人々は, 棄権してもよいです. 棄権は, 意見が無いことを表明するか, 沈黙するかです.
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.
集まりの中の全ての人々が決定を支持する(すなわち, その集まりの誰も棄権しない)合意の特別な状況.
The particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).
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, a group might find itself unable to reach consensus. The Chair may record a decision where there is dissent (i.e., there is at least one Formal Objection) so that the group can make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot stop a group’s work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group should move on.

部会は, 弱い異議しか生じない提案を支持すべきです. このような提案は, 大半から支持されるが, 若干の人から強い異議がある提案より望ましいです. 不同意がある決定を行う部分において, 議長は, 不同意の参加者が同じ会員組織(または関連会員組織)で働いているかを意識し, 状況に応じて参加者の貢献度に重きを置くことが期待されます.

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

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

技術的な議論を通して合意に至る全ての可能な手段と妥協が上手くいかず, 膠着状態を打破するには投票が必要であると, 議長が決めた後にのみ, 部会は, 実質的な課題を解決するために, 投票を行うべきです. この場合, 議長は, (例えば, 会議の議事録または記録された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:

作業部会は, 典型的に成果(例えば, 勧告工程にある技術報告書, ソフトウェア, テストツール, 他の部会の成果の審査)を生み出します. 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. 作業部会における会員の代表者
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: 関連部会における会員の代表者
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. 作業部会における外部の専門家
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: 関連部会における外部の専門家
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. 作業部会における事務局の代表者
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. 関連部会における事務局の代表者
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.


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

憲章は, この文書で必要とされる規定以外の規定を含んでもよいです. 憲章は, どの追加の規定が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技術報告書開発手続き
W3C Technical Report Development Process

W3C技術報告書開発手続きは, ウェブ技術を標準化するために, 作業部会が従う工程と要件をまとめたものです. W3C技術報告書開発手続きは, 次のように設計されています.

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技術報告書
W3C Technical Reports

この文書で使われている発行は, W3C技術報告書として, W3Cの技術報告書のページ https://www.w3.org/TR [TR]で一覧にされた報告を生み出すことに当てはまります.

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

この章は, W3C勧告またはメモ発行や維持に対する正式な要件について説明しています.

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

作業部会は, ウェブの標準として標準仕様書または手引きを生み出すために, W3C勧告工程における技術報告書を開発します. 勧告工程の手続きは, 広範囲にわたる審査, 十分な実装の実績, 合意形成のための要件を含んでおり, 実装に対してロイヤリティフリーIPRライセンスを認めているW3C特許指針[特許指針]に左右されます. 詳細については, § 6.2 W3C勧告工程を参照して下さい.
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.
部会は, 典型的に, 仕様書に刺激を与える使用方法やその使用の最善の実施例といった技術仕様書でない情報を文書化するか, もしくは, 思いのままの作業の状態を明確にするのに, W3Cメモとして文書を発行することもできます. 詳細については, § 6.3 作業部会と関連部会のメモを参照して下さい.
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

技術報告書開発手続きの一部として発行された文書は, 全て公開の文書でなければなりません. W3C技術報告書の索引 [TR]は, W3Cのウェブサイトで利用できます. W3Cは, 記録された文書が, 無期限に元々の場所で元々の形で利用できるように努力します.

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:

技術報告書開発手続きの一部として発行された技術報告書は, 部会の議長に指名された1人以上の編集者によって編集されます. 部会の議論を技術報告書の次の草案に正確に確実に反映させることは, 編集者の責務です. 編集者は, § 5.2.1 作業部会と関連部会の参加者の要件を通じて, 自分達が編集した文書に対する部会の責任において, 部会の参加者でなければなりません.

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.

W3C技術報告書の第一の言語は英語です. W3Cは, 技術報告書の翻訳を促しています. W3C技術報告書の翻訳についての情報 [翻訳]は, W3Cのウェブサイトで利用できます.

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. 広範囲にわたる審査
Wide Review

広範囲にわたる審査は, W3C手続き文書では正確には定義していません. この審査の目的は, ウェブ界隈の利害関係者全体が, 一般社会を含めて, (例えば, public-review-announce@w3.orgへと公表された周知を通して)作業部会の経過を十分に周知され, 仕様書を審査したり, 仕様書に意見を提供したりできることを, 確かなものにすることです. 2番目の目的は, 意見や提案された変更を分別よく, 審査者への返答にまだ組み込める十分早い段階で, 部会に審査を依頼するよう促すことです. 遷移を承認する前に, ディレクターは, 誰が文書の審査をするのに無理のない時期にはっきりと依頼していたか, 誰が意見を提供していたか, 審査者, 特にW3Cの対等な部会 [憲章]と, 憲章で依存関係が特定されている部会または連絡体制 [連絡体制]が特定されている部会からの依頼と返答の記録を考慮し, 適切な時期に一般社会と明確に情報交換を行ったか, どの内容が審査され, そのような審査者が実際に存在するかどうか, 証拠を求めるでしょう.

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.

例えば, 草案の中で発行された, 新しい, または著しく改訂された節への審査意見を求めることや, それらの意見や作業部会の返答を記録することは, 広範囲にわたる審査の明確な証拠とたびたび見なされるだろう良い例です. 作業部会は, 他のW3Cの作業部会や同様に一般社会, 特にその仕様書によって影響を受ける団体に, 提案が勧告候補になったことを(例えば, およそ28日間にわたって)知らせるべきです. 対照的に, いつでも審査を依頼するという文書の文言は, 部会が広範囲にわたる審査を要求した十分な証拠とは見なされないでしょう.

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

この文書は, 仕様書への変更を次の4種類に区分しています. 最初の2種類の変更は編集上の変更, 後の2種類は実質的な変更です.

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

誤りを記録することは, 作業部会技術報告書の継続している配慮の重要な部分です. この理由から, 作業部会憲章の範囲は, 一般に勧告の発行後の作業時間を認めています. この手続き文書において“正誤表(訳注:原文の英語では単数形の“erratum”と複数形の“errata”について述べていますが, どちらも正誤表に当たります.)という用語は, § 6.1.3 変更の種類の節の種類1-3の1つ以上の変更で解消できる何らかの誤りを参照しています.

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.

作業部会は, 勧告に対して読者や実装者から報告された誤りの公開の記録を維持しなければなりません. そのような誤りの報告は, 3ヵ月に1度以上の頻度で編集されるべきです.

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

正誤表は, 作業部会の合意によって承認された, 有益な訂正候補に加えられてもよいです. 行中で注釈として付けられたとき, 正誤表は, 訂正候補を含めて, 相応に記述され, 種類2の変更として扱われ, 状況に応じて公開されなければなりません.

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.

それらの変更の成熟レベルに加えて, 変更候補と一緒に発行された勧告工程の文書は, W3C特許指針[特許指針]の目的のために, それらの標準として扱われる変更候補と一緒に草案とみなされます.

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

特許指針にまだ縛られていない団体から, この手続き文書下の技術報告書に(§ 6.1.3 変更の種類で述べた)種類3または4の変更の提案があった場合, 事務局は, 記録されたロイヤリティフリー特許の言質を依頼しなければなりません. そのような言質は, W3C特許指針[特許指針]の“W3Cロイヤリティフリー(RF)ライセンス要件”の節で指定された条件において, 少なくとも, 提案の中の団体の本質的な主張(訳注:当該日本語訳では"Essential Claim"の日本語訳に"本質的主張"を当てていますが, "Essential Claim"という用語はW3C特許指針で定義された用語です.), その時点で存在している草案に提案を組み込んだ結果として本質的な主張になるもの両方を網羅すべきです.

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. W3C勧告工程
The W3C Recommendation Track

技術報告書を勧告へと進展させるとき, 典型的に, 一連の草案発行され, それらの1つ1つは, 作業部会憲章で予想された作業範囲を完成させるための開発の下で, 内容を洗練されます. 技術報告書について, 新しい標準として満足いくように, 作業部会が自分達の要件を満たしていることを審査が1度示すと, 勧告候補の段階となります. このことは, 仕様書が実際に機能することを証明する実装の実績作業部会が正式に集める間, 全てのW3C会員に仕様書に意見を提供することを認めています. その次の段階は, W3C会員の審査を完了させる勧告案です. 仕様書が標準となることをW3C会員による審査が支持していると, ディレクターが決定した場合, W3Cは, その仕様書を勧告として発行します.

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.

要約すると, W3C勧告工程は, 次のものから構成されます.

In summary, the W3C Recommendation Track consists of:

  1. 初期草案の発行.
    Publication of the First Public Working Draft.
  2. 0回以上の改訂された草案の発行.
    Publication of zero or more revised Working Drafts.
  3. 1回以上の勧告候補の発行.
    Publication of one or more Candidate Recommendations.
  4. 勧告案の発行.
    Publication of a Proposed Recommendation.
  5. W3C勧告の発行.
    Publication as a W3C Recommendation.
  6. 場合によっては, 修正勧告の発行.
    Possibly, publication as an Amended Recommendation.
基本となるW3C勧告工程 初期草案(FPWD) - 除外機会 WG決定 ディレクターの承認 草案(WD) 新しい草案の発行 WG決定: 審査が必要, または 6ヵ月以上変更無し 勧告候補への進展 ディレクターの承認 勧告候補(CR) - 特許指針の除外機会 勧告候補草案(CRD) 改訂勧告候補草案の発行 WG決定 改訂勧告候補草案の発行 WG決定 改訂勧告候補の発行 WG決定 + ディレクターの承認 改訂勧告候補の発行 WG決定 ディレクターの承認 勧告案への進展 ディレクターの承認 草案への差戻し WGまたはディレクターの決定 例えば, 更なる審査 勧告案(PR) - 諮問委員会の審査 勧告への進展 諮問委員会の審査 ディレクターの決定 勧告候補への差戻し AC審査, ディレクターの決定 例えば, 編集上の変更 草案への差戻し 諮問委員会の審査とディレクターの決定, 例えば, 更なる作業と審査 勧告(Rec)
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)

この手続き文書は, 特許審査草案として最新の勧告工程の発行物を定義しています. 2004年の(2017年に更新された)特許指針の下で, それらは, 特許指針[特許指針2017]での“最終草案”に相当しています. 2020年の特許指針の下で, それらは, 特許指針[特許指針]での“特許審査草案”に相当します.

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は, いつでも技術報告書の作業を終了してよいです.

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

草案 (WD)
Working Draft (WD)
草案は, (W3C会員を含めた)関係者, 一般社会, 他の技術団体の審査のためや, 単に履歴の参照のために, W3CがW3Cの技術報告書のページ [TR]発行した文書です. 全てではありませんが, 草案の中には, 勧告へ進展するつもりであるものもあります. 作業部会の将来の見込みについて, 草案の文書の位置付けの節を参照して下さい. 草案は, その内容に関して作業部会合意の結果である必要はなく, 技術の一般的な分野での作業への同意以上のW3CやW3C会員による何らかの支援を意図しておりません. それでも作業部会は, 採用時点の作業状況に基づいて, 草案の採用を決定します. 草案は, 成熟レベルの次の段階に進むために重要な広範囲にわたる審査の意見を集めるのに適しています.
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.

技術報告書の最初の草案は, 初期草案 (FPWD)と呼ばれ, W3C特許指針[特許指針]で定義されたとおり特許に関連しています.

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

勧告候補 (CR)
Candidate Recommendation (CR)
勧告候補は, 文書を生み出した作業部会の技術的な要件や依存関係を満たす, 作業部会によって維持されていない, 既に広範囲にわたる審査意見を受け取っている勧告に向けた実質的な訂正を行う文書です. W3Cは, 次のために勧告候補を発行します.
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
  • 最終的な審査を行う時期にあるより広範囲の関係者に合図するため.
    signal to the wider community that it is time to do a final review
  • 実装の実績を集めるため.

注意:勧告候補への進展は, その文書が完璧と見なされ, 目的に合致していること, また, 何も追加の実装の実績や試験無しに文書への更なる改善が期待されていないことを意図しています. ただし, 後の改訂で追加の機能が期待されてもよいです. 勧告候補は, しっかり書かれ, 詳細で, 自己矛盾の無い, 勧告として技術的に完璧なことを期待され, 更なる進展の必要性に直面しても満足できるものです.

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.

勧告候補の発行は, 次の2つの形式のうち1つとなります.

Candidate Recommendation publications take one of two forms:

Candidate Recommendation Snapshot
勧告候補全体版は, W3C特許指針[特許指針]で使われている特許審査草案に合致します. 特許審査草案の公開は, W3C特許指針における“W3C RFライセンス要件からの除外”を通して, 除外の要請のきっかけとなります.
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
勧告候補草案版は, 作業部会がすぐ次の勧告候補全体版に含めることを意図している, 前の勧告候補全体版からの変更をまとめるために, W3Cの技術報告書のページ [TR]に公開されます. このことは, 変更の広範囲にわたる審査を可能にし, まとまった仕様書への参照を簡単にしています.
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.

勧告候補草案版は, その代わり, 除外機会を提供せず, W3C特許指針 [特許指針]の目的のための草案と見なされます.

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

廃止勧告候補は, 例えば, 実装に影響して解決できないやっかいな特許の主張によって(W3C特許指針[特許指針]と特に“PAG決定”(訳注:PAGは"Patent Advisory Group"(特許助言部会)の略)の中を参照), W3Cが支持できない, または作業を継続できない重大な問題が見つかった勧告候補です. 廃止勧告候補に対して何も復活の道筋はありません. 特許ライセンス義務における実装に対しては, W3C特許指針[特許指針]の“W3Cロイヤリティフリー(RF)ライセンス要件”を参照して下さい.

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.

勧告案 (PR)
Proposed Recommendation (PR)
勧告案は, W3CによってW3C勧告となるのに十分な品質のものとして承認された文書です. この段階は, 文書をW3C勧告として発行すること, または, 更なる作業のために作業部会に差し戻すこと, 断念することを推奨してもよい諮問委員会による公式な審査のきっかけとなります. 実質的な変更は, 新しい草案または勧告候補発行することを除いて, 勧告案に対して行ってはなりません.
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勧告 (REC)
W3C Recommendation (REC)
W3C勧告は, 広範囲にわたる合意形成の後, W3Cとその会員から支持を得た, 仕様書, もしくは手引きまたは要件の集合です. W3Cは, ウェブの標準として勧告の広範囲にわたる展開を推奨しています. W3C特許指針[特許指針]の下で認められているW3CロイヤリティフリーIPRライセンスが, W3C勧告に適用されます. 技術の発展に従って, W3C勧告は次のようになるかもしれません.
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
修正勧告は, 新しい機能を追加しない実質的な変更を含むように修正された勧告で, 勧告がどの活動中の作業部会の憲章にも含まれていないときに, W3Cによって生み出されます. 作業部会ではなく, W3C事務局がその文書を手続きに移行することから, W3C特許指針[特許指針]の下で認められているロイヤリティーフリーIPRライセンスの適用範囲に関する影響があります.
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
置換済勧告は, W3Cが新しく採用するように推奨している, より新しいヴァージョンによって置き換えられた仕様書です. 旧式または置換済の仕様書は, 特許指針の下で認められているW3CロイヤリティフリーIPRライセンスに関して, W3C勧告と同じ位置付けを持ちます.
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.

注意:勧告として以前に発行されていた技術報告書が, その文書を改訂するのに必要な工程に従って勧告として再度発行されたとき, 最新のヴァージョンは, § W3C勧告の断念の工程を実施する必要無しに以前のものを置き換えます. その文書は, 更新された同じ文書です. 文書が置換されたと明確に宣言し, § W3C勧告の断念で文書化された工程を用いることは, 勧告が分割された技術報告書(またはW3C以外に管理された文書)によって置き換えられる状況を意味しています.

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 § Abandoning a W3C Recommendation: it is the same document, updated. Explicitly declaring a documented superseded, using the process documented in § 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
旧式勧告は, 実装するための推奨を継続する十分な市場性を欠いているとW3Cが判断したが, 廃止する必要があるほどの根本的な問題を持たない仕様書です. 旧式の仕様書が十分な市場性を得た場合, W3Cは, その文書を勧告の状態に戻すことを決定してもよいです.
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
廃止勧告は, W3Cがもはや支持しておらず, 絶対に勧告の状態に戻される見込みがないと考えている勧告全体です. W3C特許指針[特許指針]の“W3Cロイヤリティフリー(RF)ライセンス要件”を参照して下さい.
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.

既存の勧告候補または勧告の更新版を発行するとき, 技術報告書は, その状態の下で初めて発行されたときと同じ成熟レベルの基準で扱われることが期待されます. しかしながら, 古くなった文書を改善したもので迅速に置き換える観点において, 発行文書が遅れずに周知されることを却下するには十分現実的でないだろうCRまたはRECとしての最初の発行後に, 不備が技術報告書に見つかった場合, 例え, 不備の一部だけが満足のいくように処理されるとしても, 通常の手続きに従って更新されたCRまたはRECを発行することは差し支えないでしょう.

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.

作業部会関連部会は, 利用可能な編集者草案を作成してもよいです. 編集者草案 (ED)は, 何ら公式な状態は持っておらず, 作業部会または関連部会の合意は必ずしも意味せず, W3Cから何ら支持された内容でもないです.

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.

ディレクターは, 改訂された仕様書の公開をW3Cの他の部会や一般社会に周知しなければなりません.

The Director must announce the publication of the revised specification to other W3C groups and the Public. 合理化された発行承認
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.

発行した後, AC委員または事務局メンバーは, 示された証拠が主張に対応していることに疑義がある場合, 実際に後で正式な審査の会議が開かれることを要求してもよいです. 要件が満たされていることを, その審査が見つけたのであれば, 事務局は, 元に戻されたことを示す状態の節をきちんと更新することや, 技術報告書の以前に承認されたヴァージョンを再発行することによって, 変更を元に戻してもよいです.

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.

ディレクターは, 初期草案の発行をW3Cの他の部会や一般社会に周知しなければなりません.

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

作業部会は, 以前に発行された文書に, 作業部会を超えた審査によってより良いものとなる重大な変更があったとき, 草案をW3C技術報告書のページに発行べきです.

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.

仕様書に重大な変更が無いまま6ヵ月経過した場合, 作業部会は, 状態の節に変更の無い理由を示した改訂された草案を発行すべきです.

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

勧告候補を発行するに当たって, 遷移の要件を処理することに加え, 作業部会は, また, (修正勧告となることが示された文書である)修正勧告候補の場合にW3Cは, 次のとおりです.

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:

遷移要求の承認後の最初の勧告候補は, 常に勧告候補全体版です. ディレクターは, 勧告候補全体版の発行を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 勧告候補全体版の発行
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:

ディレクターは, 改訂された勧告候補全体版の発行をW3Cの他の部会や一般社会に周知しなければなりません.

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

素早い更新と特許の保護を提供するために, 勧告候補全体版は, 作業部会が実質的な変更に対する提案を受けてから24ヵ月以内に(できる限り早く)発行されるべきです. 審査の計画を簡単にするために, 勧告候補全体版は, おおよそ6ヵ月に1回より多い頻度で発行されるべきではありません.

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.

注意: 実質的な変更 は, W3C特許指針[特許指針]の“W3C RFライセンス要件からの除外”を通して, 新しい除外機会のきっかけとなります.

Note: Substantive changes trigger a new Exclusion Opportunity per “Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY]. 勧告候補草案版の発行
Publishing a Candidate Recommendation Draft

作業部会は, 以前に発行された文書に, 作業部会を超えた審査によってより良いものとなる重大な変更があったとき, 更新された勧告候補草案版をW3C技術報告書のページに発行べきです.

A Working Group should publish an Update Draft to the W3C Technical Reports page when there have been significant changes to the previous published document 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,

作業部会は, また, 修正勧告案に対してW3Cは, 次のとおりです.

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

ディレクターは, 次のとおりです.

The Director:

W3C勧告は, 元となった勧告案から何か実質的な変更を含んではならないことから, 勧告案に何か実質的な変更を行うために, 作業部会は, 仕様書を勧告候補または草案に戻さなければなりません.

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.

勧告案は, § 勧告の改訂:新しい機能で述べられているように, 勧告として最初に発行した後に(種類4の変更に当たる)新しい機能を認めることを示しているものとして自身を特定してもよいです. そのような承認は, そのような変更を認めていない勧告を発行する前に, 技術報告書に加えることはできません.

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 § 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. W3C勧告への遷移
Transitioning to W3C Recommendation

文書を勧告に進展させることは, W3C決定です.

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

進展の要件を満たすことに加えて, 次のとおりです.

In addition to meeting the requirements for advancement,

可能性のある次の段階について, W3C勧告はその状態を無期限に保持しますが, 次のようになってもよいです.

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

6.2.11. W3C勧告の改訂
Revising a W3C Recommendation

この節は, 勧告に変更を加えるための手続きについて詳細に述べています.

This section details the process for making changes to a Recommendation. 勧告の改訂:マークアップの変更
Revising a Recommendation: Markup Changes

仕様書の文章に何も変更を与えない結果となる訂正を行うのに, 作業部会は , 勧告の再発行を要求してもよく, また, どの作業部会勧告を維持するよう憲章に書いていない場合は, W3Cが勧告を再発行してもよいです. (種類1の変更を参照して下さい.)

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.) 勧告の改訂:編集上の変更
Revising a Recommendation: Editorial Changes

勧告に対する編集上の変更は, 示された変更の技術的な審査を何も必要としていません. 作業部会は, 発行の決断に当たって何も投票をしていなければ, 勧告の発行を要求してもよく, また, W3Cは, これらの変更を行うために低い段階の成熟レベルを通すことなく, 勧告を発行してもよいです. (種類2の変更を参照して下さい.)

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.) 勧告の改訂:実質的な変更
Revising a Recommendation: Substantive Changes

訂正候補は, 変更候補が技術上かつ編集上十分なことを確かなものにするために, 関係者の審査を含め, 勧告の残りの部分と同じ基準を1度全て満足したのならば, 標準にすることができ, 勧告の主要な文章に織り交ぜることができます. その訂正が有効か確認するために, 作業部会は, 更新要求に従って変更案審査の最終要請を要求しなければなりません. § 変更候補の組み入れを参照して下さい.

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 § Incorporating Candidate Changes.

代わりに, 作業部会は, その変更を組み入れ, 勧告候補を発行してもよく, また, どの作業部会勧告を維持することを憲章に書いていない場合は, W3Cが, 修正勧告候補を発行し, その状態から仕様書を進展させてもよいです. 作業部会が無い状態でW3C事務局によって発行が要求された場合, その結果生じた勧告は, 修正勧告と呼ばれます. (種類3の変更を参照して下さい.)

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.) 勧告の改訂:新しい機能
Revising a Recommendation: New Features

新しい機能(種類4の変更参照)は, 追加候補を用いて新しい機能を認めているとはっきり特定されている勧告に組み込まれてもよいです. 追加候補は, 変更候補が技術上かつ編集上十分なことを確かなものにするために, 関係者の審査を含め, 勧告の残りの部分と同じ基準を1度全て満足したのならば, 標準にすることができ, 勧告の主要な文章に織り交ぜることができます. その追加が有効か確認するために, 作業部会は, 更新要求に従って変更案審査の最終要請を要求しなければなりません. § 変更候補の組み入れを参照して下さい.

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 § Incorporating Candidate Changes.

注意:この新しい機能の禁止は, はっきり認められていない限り, この手続き文書の2020改訂版を優先することで, 第3者が安定した機能群を持つ勧告に依存することを可能にします.

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.

新しい機能を受け入れるために進展されなかった勧告に, 新しい機能を導入する変更を行うために, W3Cは, 新しい初期草案から始まる技術報告書を勧告に進展させる手続きに従って, 新しい技術報告書を作らなければなりません.

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. 変更候補の組み入れ
Incorporating Candidate Changes

変更案審査の最終要請は, AC審査と特許除外機会を組合せることで, 変更候補のW3C関係者による承諾を確認します.

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.

変更案審査の最終要請は, W3Cの他の部会, 一般社会, 諮問委員会に周知しなければなりません. 周知は, 次のとおりでなければなりません.

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.

作業部会は, 複数の変更案を単独の変更案審査の最終要請にまとめて処理してもよいです. 審査を促すため, 与えられた仕様書における変更案審査の最終要請は, おおよそ6ヵ月に1回より多い頻度で発せられるべきではありません.

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.

変更案審査の最終要請の最後に, W3C決定は, 変更案を却下するか, 進展のために変更案を取り除くか, 審査の下で変更に寄せられた意見を正式に取り組む要求と一緒に提案を作業部会戻すかのいずれかでしょう. 作業部会が審査の反応に対する回答の中で変更案を修正する必要があるのならば, 作業部会は, 変更が主要な文章に組み入れられる前に, 他の改訂された変更に対する変更案審査の最終要請を発しなければなりません.

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

技術報告書の作業は, いつでも辞めてよいです. 作業は, W3Cまたは作業部会がそれ以上に作業を生産的に進めることができないと判断した場合に辞めるべきです.

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. 未完成の技術報告書の断念
Abandoning an Unfinished Technical Report

もはや進展されたり, 維持されたりする予定がなく, 廃止されていない何らかの技術報告書は, 作業部会のメモとして発行されるべきです. このことは, 作業部会が報告書の作業を断念したか, ディレクター作業部会に技術報告書の作業を完了する前に辞めるように求めた場合に起こります. ディレクター作業部会を閉めた場合, W3Cは, 勧告工程にある何らかの完了していない技術報告書作業部会のメモとして発行なければなりません.

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. 勧告候補の廃止
Rescinding a Candidate Recommendation

勧告候補を廃止する手続きは, 勧告を廃止する場合と一緒です.

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation. W3C勧告の断念
Abandoning a W3C Recommendation

W3Cが, 特定の勧告を実装することがもはや推奨されないと決めることは可能です. そのような仕様書に対し, W3Cがその仕様書の更なる利用について与えようとしている助言に応じて選ばれた, 3つの状態があります.

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関係者が, その勧告がもはや最適な慣行を表していないか, 採用されていないうえに明らかに採用されそうにないと決めた場合, W3Cは, 勧告を旧式としてもよいです. 旧式勧告は, 例えば, 旧式とされたにも関わらず, 後で仕様書がより幅広く採用された場合, 通常の勧告に復活させてもよいです.

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が新たに採用するよう推奨する新しいヴァージョンが存在する場合, W3Cは勧告が置換済であると宣言してもよいです. 勧告が置換済であると宣言する手続きは, 後で示す勧告が旧式と宣言する手続きと一緒です.

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が復活させる筋の通った見込みが何もないと考える場合, W3Cは勧告を廃止してもよいです. W3C特許指針[特許指針], 特に“W3Cロイヤリティフリー(RF)ライセンス要件”と“PAG決定”を参照して下さい.

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は, 勧告全体をまとめて廃止したり, 置換済にしたり, 旧式としたりします. 勧告は, 置換済にされ, 同時に旧式とされることがあります. 勧告の一部を廃止したり, 置換済にしたり, 旧式としたりするには, W3Cは勧告を修正する手続きに従います.

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.

注意:W3C特許指針[特許指針]の意図することろでは, 旧式勧告または置換済勧告は, 将来の実装が推奨されないにも関わらず, 有効な勧告の状態を持ちます. 廃止勧告は有効ではなくなり, 何も新しいライセンスは, 特許指針の下で認められません.

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 勧告 (Rec) 主要な問題とAC審査は, 勧告を廃止に導きます. W3C特許指針の下で, 何も新しいIPRライセンスは発せられませんし, 勧告に復活するには, 勧告工程の手続きを再度全て通る必要があります. 主要な問題, AC審査 廃止勧告 - 新しいIPRライセンス無し 最小限の持ち上げの場合, AC審査に従って仕様書は旧式勧告となるでしょう 旧式勧告 新たな持ち上げがあった場合, AC審査によって旧式勧告は通常の勧告の状態に戻ってもよいです 新しいヴァージョンによる置換, AC審査 置換済勧告 置換済勧告は, AC審査によって通常の勧告になることがあります
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 勧告の廃止, 旧式化, 置換, 復活の手続き
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

諮問委員会の審査において何らかの不同意があった場合, ディレクターは, 不同意の実質的な意見をW3Cと一般社会に公表しなければならず, 旧式勧告または廃止勧告として遅くとも14日前までに不同意に正式に取り組まなければなりません.

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は, 旧式勧告または廃止勧告を最新の状態と一緒に発行しなければなりません. 更新版は, 文書の主要部分を取り除いてもよいです. その文書の状態の節は, W3C仕様書の旧式化と廃止 [旧式-廃止]の説明を適切にリンクすべきです.

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.

一度W3Cが廃止勧告を発行すると, 将来のW3C技術報告書は, その技術報告書を標準の参考文献として含むことはできません.

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

注意: W3Cは, 全ての技術報告書がそれら自身のヴァージョン特有のURLで利用可能であり続けることを, 確かなものにしようと努力します.

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.

作業部会関連部会は, W3Cメモとして作業を公表してもよいです. 例えば次のものを含みます.

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

W3Cメモの中には, 連続する草案を通して, それらがメモとなる期待と共に, 他のものが単に発行されるまで開発されるものもあります. 文書をW3Cメモとして発行するには若干の正式な要件があり, それらの文書は, W3Cの勧告の状態ではありませんが, 履歴の参照のために単に保存される文書です.

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:

注意:W3C特許指針[特許指針]は, 作業部会のメモに対して, 何らかのライセンス要件や義務は指定しません.

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

6.4. より踏み込んだ見解
Further reading

様々な段階の審査と周知のための準備に関する実用的な情報は, 合意の要領 [案内]の中の"どのように勧告工程の遷移を系統立てるか" [遷移], また, 早く勧告を得るに当たっての情報 [勧告情報]を参照して下さい. また, W3C技術報告書の修正に対する要件 [再発行]も参照して下さい.

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

この節は, どのように諮問委員会ディレクターからの提案を審議するか, どのように諮問委員会の委員W3C決定またはディレクターの決定に対し諮問委員会の抗議を提出するかについて説明しています. W3C決定は, 諮問委員会の審査の後に, W3C関係者の合意について判断する役割を発揮してディレクターが決めるものです.

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

それぞれの諮問委員会の審査の期間は, 事務局から諮問委員会への審査の要請によって始まります. 審査の要請は, 提案について説明し, 締切に注意を引き, 決定が利用できるようになる時期を推定し, 他の実用的な情報を含みます. 各会員組織は, 1つの審査意見を送ってよく, その意見は, 諮問委員会の委員によって返されなければなりません.

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.

事務局は, 諮問委員会の審査意見のために2つの経路を提供しなければなりません.

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

審査期間の終了後, ディレクターは, 諮問委員会に提案の支持の水準(合意または不同意)を周知しなければなりません. ディレクターは, 何らかの正式な異議があったかどうかも, 機密レベルの変更に注意して示さなければなりません. このW3C決定は, 一般に次のうちの1つです.

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.

この文書は, 諮問委員会の審査期間の終了からW3C決定までの時間間隔を指定していません. このことは, 審査の間に集められた意見を熟慮する十分な時間を, 会員や事務局が持つことを確かなものにするためです. 諮問委員会は, 審査期間の終了後2週間より早く周知を期待すべきではなく, もし3週間経っても, ディレクターが結果を周知しない場合, ディレクターは, 最新情報を諮問委員会に提供すべきです.

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.

W3C決定諮問委員会の審査に従って行われたとき, 諮問委員会の委員は, 諮問委員会の抗議を提出してもよいです. それらのW3C決定は, 部会の作成や修正に関係する決定, また, 勧告工程にある文書や手続き文書の新しい成熟レベルへの遷移を含みます.

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.

全ての場合に, 抗議は, 決定から3週間以内に提出されなければなりません.

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

諮問委員会の委員は, 事務局に要求を送ることで抗議を提出します. 要求は, “ディレクター決定に抗議する”と言い, 決定を特定すべきです. 1週間以内に, 事務局は, 諮問委員会に抗議の流れを周知し, その抗議に対する賛成の支持の声明を回答する仕組みを, 諮問委員会の委員に提供しなければなりません. それらの声明の記録は, 会員限定なければなりません. もし, 事務局の周知から1週間以内に, 諮問委員会の5%以上が抗議の要求を支持したならば, 事務局は, ディレクター決定と抗議の支持へのリンクを一緒に付けて, “ディレクター決定を承認するか?”を諮問委員会に問う投票を開催しなければなりません.

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.

投票は, 意見と一緒に3つの選択可能な回答“承認”, “却下”,“棄権”を認めなければなりません.

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

諮問委員会は, TAGまたは諮問会議の席の選挙や, 抗議の投票のきっかけとなるのに必要な支持を達成した諮問委員会の抗議の中で, 投票します. 諮問委員会が投票するときはいつでも, 各会員または関連会員のグループは, 1票を持ちます. 諮問会議とTAGの選挙の場合, “1票”は“選択可能な席への1票”を意味します.

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

事務局は, W3Cの活動の開発における, 会員や一般社会からの早くからの関わり合いを促すために, ワークショップシンポジウムを開催します.

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

ワークショップの目的は, 通常, 技術や方針についての意見交換のために, 専門家や他の興味を持っている団体を招待すること, もしくは, W3C会員の強く求めている関心に対応することです. 最初の形式のワークショップの開催者は, ワークショップのプログラムについての方針説明書を要求してもよいですし, それらの資料を出席者や発表者を選ぶのに利用してもよいです.

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.

ワークショップまたはシンポジウムの参加の要請は, 参加の要件または範囲, 期待される成果(例えば, 報告書や議事録)を示してもよいです. それらの催しの主催者は, 特定の題目におけるW3Cによる更なる投資は保証しませんが, 新しい活動や部会の提案を先導してもよいです.

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.

ワークショップとシンポジウムは, 通常, 1日から3日間続きます. ワークショップが会員の表明した関心に焦点を当てるために開催されるならば, 事務局は, ワークショップの開催予定日の6週間前までに参加の要請を発しなければなりません. 他のワークショップやシンポジウムに対しては, 事務局は, 催しの開始予定日の8週間前までに参加の要請を発しなければなりません. このことは, 方針説明書や講演の準備を行う十分な時間を, 講演者や著者が持つことを確実にすることを助けます.

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. 連絡体制

W3Cは, 連絡体制という用語を, (例えば, 他の組織から個人がW3C作業部会に参加するか, もしくは単に作業を追跡するといった)とても簡略なものから, 相互に会員であること, さらにより正確な契約といったもものまで及ぶ, 様々な組織との活動の調整を表すのに用います. 連絡体制は, W3Cとの会員関係の代わりになるものを意味しません.

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.

全ての連絡体制は, 一般の意思疎通, 特許, 著作権, 他のIPR方針に対する必要性, 機密契約, 相互会員契約に応じて, 事務局によって調整されなければなりません.

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

W3Cディレクターは, 他の組織と覚書を結んでもよいです. W3C手続き文書の目的のために, 覚書(MoU)は, 各団体の他者に対する権利と義務を指定した正式な契約, もしくは, W3Cと他の団体との間の契約上の類似した枠組みです. なお, 会員関係を意図するホスト機関 の間, もしくはホスト機関とW3C会員組織の間の契約, W3Cを運営する目的の業務の通常の規定に関係した契約以外です. 覚書の権利と義務は, 共同の成果, しかるべき調整と一緒の技術的な責任の同意の上の分散, 機密と特定のIPRに対する調整を含みます. その契約は, “覚書”以外の名前で呼ばれるかもしれませんし, “覚書”と呼ばれるものが手続き文書の意図するMoUでないかもしれません.

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.

MoUに署名する前に, 事務局は, 諮問委員会に署名の意思を通知し, MoUを諮問委員会の審査が可能な状態にしなければなりません. 諮問委員会の委員は, MoUへの署名の決定に対し諮問委員会の抗議を提出してもよいです. 抗議がMoUに署名する提案を却下しない限り, ディレクターは, W3Cを代表してMoUに署名してもよいです. 署名された覚書は公開されるべきです.

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.

他の組織とのW3C連絡体制 [連絡体制]についての情報, また, 連絡体制を構築するときにW3Cが従う手続きは, ウェブで利用可能です.

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

会員提案手続きは, 事務局による考察を受ける技術や意見を提案することを, 会員に認めています. 審査の後, 事務局は, その内容をW3Cのウェブサイトで利用できるようにしてもよいです. 正式な手続きは, その貢献の記録を会員に提供し, 事務局と(IPRの主張を含めて)詳細な意見交換を開示するための仕組みを会員に提供します. 事務局は, 提案された内容に対する審査意見もW3C会員, 一般社会, 報道機関に利用できるようにします.

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:

(提案者と呼ばれる)1つ以上の会員は, 会員提案に参加してもよいです. W3C会員のみが提案者として一覧にされてよいです.

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. 提案者の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:

会員提案をW3Cのウェブサイトで利用できるようにすることは, W3C事務局または会員を含めた, W3Cからの支持を意味しません. 提案要求の承認は, 何らかの活動がW3Cによって行われることを意図しません. この承認は, 単に提案要求が提案者によって行われたことを公開の場で記録するだけです. W3Cにより利用可能になった会員提案は, W3Cの“進展中の作業”として参照されてはなりません.

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.

承認された会員提案の一覧[提案一覧]は, W3Cのウェブサイトで利用できます.

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

10.1. 提案者の権利と義務
Submitter Rights and Obligations

複数の会員が一緒に提案要求に参加している場合, 1つの会員のみが要求を送ります. その会員は, 他の参加している会員それぞれの諮問委員会の委員に, 要求の写しを送らなければならず, それぞれのその諮問委員会の委員は, (事務局にメールで)提案要求に参加していることをはっきりと言わなければなりません.

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.

承認の前に, 提案者は. どんな状況でも, 文書を“ワールド・ワイド・ウェブ・コンソーシアムに提出された”または“W3Cによる考察の下にある”ものとして, もしくは, 一般社会または会員間のやりとりにおける何らかの同じような表現を参照してはなりません. 提案者は, 一般社会または会員間のやり取りでW3Cが(提案者と)会員提案の内容について作業していることを示してはなりません. 提案者は, 会員提案の文書を, 承認の前に(提案要求を参照すること無しに)一般社会に公開してもよいです.

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

承認の後, 提案者は, どんな状況でも, 会員提案において, その内容がW3C作業部会の成果として採用されない限り, 採用されるまでW3Cの投資を必要としてはなりません.

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.

一方で, W3Cが憲章を開発する初期の段階の間, 会員は, 提案手続きを新しい作業に対する具体的な提案への合意形成のために利用すべきです.

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.

会員は, W3Cの活動理念 [理念]の範囲外の題目を相当含む内容を提案すべきではありません.

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

提案者と提案された内容の何らかの他の著者は, 要求が承認されたならば, 会員提案の中の文書がW3C文書ライセンス [文書ライセンス]の下に置かれ, そのライセンスへの参照を含むことに同意しなければなりません. 提案者は, 会員提案の中の文書の著作権を保持してもよいです.

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.

要求は, W3C特許指針[特許指針]の中の“W3C提案におけるライセンス義務”の会員提案ライセンスを満たさなければなりません.

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

ディレクターは, 諮問委員会に通知を送ることによって, 提案要求を承認します. 通知は, いつでも行ってよいですが, 提案者は, 有効かどうかの通知の後4から6週間の間に通知があることを期待できます. 事務局は, 提案者にいつごろ通知が行われそうか知らせ続けなければなりません.

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.

提案要求が1度承認されたならば, 事務局は, 次のとおりしなければなりません.

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.

提案者諮問委員会の委員は, 事務局の決定に対する提案の抗議を, 理由がウェブ技術体系に関係するものならTAGへ, 要求が他の理由で却下されたのなら諮問会議へ提出してもよいです. その場合, 事務局は, 却下の根拠を適切な形で利用できるようにすべきです. 事務局は, 適切な機密レベルを確かにした, そのような抗議に対する手続きを立ち上げるでしょう.

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

W3C手続き文書および関連する文書(下記参照)の改訂は, 作業部会をまとめる働きをしている諮問会議によって, 技術報告書に対するものと似た合意形成手続きを経ます. それらの文書は, ABによって開発されるか, もしくはABに開発を委任された他の部会によって開発されてよいです. 審査は, W3C関係者, 特に事務局から要求された内容を含みます.

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. 事務局が, 審査の要請を諮問委員会とW3Cの他の部会に送ります.
    The Team sends a Call for Review to the Advisory Committee and other W3C groups.
  2. 意見が正式に取り組まれ, 場合によっては文書が修正された後, 事務局は, 諮問委員会の審査を発議することで, 会員からの支持を得ようとします. 審査の期間は, 少なくとも28日以上としなければなりません.
    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. 諮問委員会の審査の後, 文書を採用するW3C決定に従って, 事務局は文書を採用し, 諮問委員会に通知を送ります. 諮問委員会の委員は, W3Cに諮問委員会の抗議を提出してもよいです.
    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.

注意:2020年7月時点で, 特許指針特許および標準関連部会で, W3C倫理規定および職業行為規定積極的作業環境共同部会で, 手続き文書は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. 謝辞


This section is non-normative.

編集者は, 改訂された手続き文書の提案に寄与した次に示す方々に, 関係した個人と所属を一覧にして感謝します. Brian Kardell, Carine Bournez (W3C), Charles McCathie Nevile (ConsenSys), Chris Wilson (Google), David Singer (Apple), Delfi Ramirez, Dominique Hazael-Massieux (W3C), Elika J. Etemad aka fantasai, Fuqiao Xue (W3C), Jeff Jaffe (W3C), Kevin Fleming (ブルームバーグ), Leonie Watson (The Paciello Group), Michael Champion (マイクロソフト), Nigel Megitt (BBC), Philippe Le Hegaret (W3C), Ralph Swick (W3C), Samuel Weiler (W3C), Sandro Hawke (W3C), Tantek Celik (Mozilla), Virginia Fournier (Apple), Wendy Seltzer (W3C), Yves Lafon (W3C).

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.

次の方々は, 手続き文書の以前のヴァージョンの開発に寄与しました. Alex Russell (Google), Andreas Tai (Institut fuer Rundfunktechnik), Andrew Betts (Fastly), Ann Bassetti (ボーイング社), Anne van Kesteren, Art Barstow (ノキア, 独立), Bede McCall (MITRE), Ben Wilson, Brad Hill (Facebook), Brian Kardell (JQuery), Carine Bournez (W3C), Carl Cargill (ネットスケープ, サン・マイクロシステムズ, アドビ), Chris Lilley (W3C), Chris Wilson (Google), Claus von Riegen (SAP AG), Coralie Mercier (W3C), Cullen Jennings (シスコ), Dan Appelquist (テレフォニカ, サムスン), Dan Connolly (W3C), Daniel Dardailler (W3C), Daniel Glazman (Disruptive Innovations), David Baron (Mozilla), David Fallside (IBM), David Singer (Apple), David Singer (IBM), Delfi Ramirez, Dominique Hazael-Massieux (W3C), Don Brutzman (Web3D), Don Deutsch (オラクル), Eduardo Gutentag (サン・マイクロシステムズ), Elika J. Etemad aka fantasai, Florian Rivoal, Fuqiao Xue (W3C), Geoffrey Creighton (マイクロソフト), Geoffrey Snedden, Giri Mandyam (クアルコム), Gregg Kellogg, Hadley Beeman, Helene Workman (Apple), Henri Sivonen (Mozilla), Hakon Wium Lie (オペラソフトウェア), Ian Hickson (Google), Ian Jacobs (W3C), Ivan Herman (W3C), J Alan Bird (W3C), Jay Kishigami 岸上順一 (NTT), Jean-Charles Verdie (MStar), Jean-Francois Abramatic (IBM, ILOG, W3C), Jeff Jaffe (W3C), Jim Bell (HP), Jim Miller (W3C), Joe Hall (CDT), John Klensin (MCI), Josh Soref (BlackBerry, 独立), Judy Brewer (W3C), Judy Zhu 朱红儒 (アリババ), Kari Laihonen (エリクソン), Karl Dubost (Mozilla), Ken Laskey (MITRE), Kevin Fleming (ブルームバーグ), Klaus Birkenbihl (フランホーファー研究機構), Larry Masinter (アドビシステムズ), Lauren Wood (独立), Liam Quin (W3C), Leonie Watson (The Paciello Group), Marcos Caceres (Mozilla), Maria Courtemanche (IBM), Mark Crawford (SAP), Mark Nottingham, Michael Champion (マイクロソフト), Michael Geldblum (オラクル), Mike West (Google), Mitch Stoltz (EFF), Natasha Rooney (GSMA), Nigel Megitt (BBC), Olle Olsson (SICS), Ora Lassila (ノキア), Paul Cotton (マイクロソフト), Paul Grosso (Arbortext), Peter Linss, Peter Patel-Schneider, Philippe Le Hegaret (W3C), Qiuling Pan (ファーウェイ), Ralph Swick (W3C), Renato Iannella (IPR Systems), Rigo Wenning (W3C), Rob Sanderson (ゲティ財団), Robin Berjon (W3C), Sally Khudairi (W3C), Sam Ruby (IBM), Sandro Hawke (W3C), Sangwhan Moon (Odd Concepts), Scott Peterson (Google), Steve Holbrook (IBM), Steve Zilles (アドビシステムズ) Steven Pemberton (CWI), TV Raman (Google), Tantek Celik (Mozilla), Terence Eden (英国政府), Thomas Reardon (マイクロソフト), Tim Berners-Lee (W3C), Tim Krauskopf (Spyglass), Travis Leithead (マイクロソフト), Virginia Fournier (Apple), Virginie Galindo (ジェムアルト), Wayne Carr (インテル), Wendy Fong (ヒューレッドパッカード), Wendy Seltzer (W3C), Yves Lafon (W3C).

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. 変更点


This section is non-normative.

Changes since the 1 March 2019 Process

この文書は, 2019年3月1日版の手続き文書を基にしています. 意見の傾向, また同様にそれ以降の全ての変更の詳細な記録が利用できます.

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.

この文書と2019年版の手続き文書を比較した差分が利用できます. 変更を網羅するために, この差分は, 審査するにはやや難解かもしれないことに注意して下さい. 審査を簡単にするために, 様々な部分的差分, 関係する変更をまとめたものも, 下記の詳細のとおり利用できます.

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

重大な追加と修正が勧告工程にありました. 様々な成熟レベルの意味や関連する遷移の基準は変わっていませんが, 何がCRとRECの段階の間にできるかに対して重要な追加が行われました. これらは, 仕様書の管理を容易にすること, W3Cの勧告工程の本来の性能として, 日々更新される基準としての情報を提供することを目指しています.

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.


Normative References

W3C倫理規定および職業行為規定. URL: https://www.w3.org/Consortium/cepc/
W3C Code of Ethics and Professional Conduct. URL: https://www.w3.org/Consortium/cepc/
外部の専門家・協力者規約. URL: https://www.w3.org/Consortium/Legal/collaborators-agreement
Invited expert and collaborators agreement. URL: https://www.w3.org/Consortium/Legal/collaborators-agreement
外部の職業活動に従事する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
W3C文書ライセンス. URL: https://www.w3.org/Consortium/Legal/copyright-documents
W3C Document License. URL: https://www.w3.org/Consortium/Legal/copyright-documents
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/
2017に更新されたW3C 2004 特許指針. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/ The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/
発行の決まり. URL: https://www.w3.org/pubrules/
Publication Rules. URL: https://www.w3.org/pubrules/
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
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

諮問会議ホームページ. URL: https://www.w3.org/2002/ab/
The Advisory Board home page. URL: https://www.w3.org/2002/ab/
諮問委員会の会議(会員限定利用). URL: https://www.w3.org/Member/Meeting/
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/Member/Meeting/
共同部会とビジネス部会の手続き. URL: https://www.w3.org/community/about/agreements/
Community and Business Group Process. URL: https://www.w3.org/community/about/agreements/
全ての予定されているW3C公式行事のカレンダー. URL: https://www.w3.org/participate/eventscal
Calendar of all scheduled official W3C events. URL: https://www.w3.org/participate/eventscal
W3C作業/関連部会の議長. URL: https://www.w3.org/Guide/chair/role.html
W3C Working/Interest Group Chair. URL: https://www.w3.org/Guide/chair/role.html
作業部会または関連部会をどのように作るのか. 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
最新の諮問委員会の委員 (会員限定利用). URL: https://www.w3.org/Member/ACList
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList
懲戒処分の基準. URL: https://www.w3.org/2002/09/discipline
Guidelines for Disciplinary Action. URL: https://www.w3.org/2002/09/discipline
諮問会議と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
W3C特別研究員プログラム. URL: https://www.w3.org/Consortium/Recruitment/Fellows
W3C Fellows Program. URL: https://www.w3.org/Consortium/Recruitment/Fellows
部会のメーリングリスト(会員限定利用). URL: https://www.w3.org/Member/Groups
Group mailing lists (Member-only access). URL: https://www.w3.org/Member/Groups
合意の要領, 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/
手続き, 特許指針, 財務, 投資管理, 戦略的未来像(会員限定利用). 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
W3Cに加入するには. URL: https://www.w3.org/Consortium/join
How to Join W3C. URL: https://www.w3.org/Consortium/join
他の組織とのW3C連絡体制. URL: https://www.w3.org/2001/11/StdLiaison
W3C liaisons with other organizations. URL: https://www.w3.org/2001/11/StdLiaison
W3C会員規約. URL: https://www.w3.org/Consortium/Agreement/Member-Agreement
W3C Membership Agreement. URL: https://www.w3.org/Consortium/Agreement/Member-Agreement
会員ウェブサイト(会員限定利用). URL: https://www.w3.org/Member/
Member Web site (Member-only access). URL: https://www.w3.org/Member/
最新のW3C会員の一覧. URL: https://www.w3.org/Consortium/Member/List
The list of current W3C Members. URL: https://www.w3.org/Consortium/Member/List
どのように提案要求を送るか. URL: https://www.w3.org/2000/09/submission
How to send a Submission request. URL: https://www.w3.org/2000/09/submission
W3Cの活動理念. URL: https://www.w3.org/Consortium/mission
The W3C Mission statement. URL: https://www.w3.org/Consortium/mission
W3C仕様書の旧式化と廃止. URL: https://www.w3.org/2016/11/obsoleting-rescinding/
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/2016/11/obsoleting-rescinding/
早く勧告を得るに当たっての情報. URL: https://www.w3.org/2002/05/rec-tips
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/2002/05/rec-tips
W3C技術報告書の現位置での修正. URL: https://www.w3.org/2003/01/republishing/
In-place modification of W3C Technical Reports. URL: https://www.w3.org/2003/01/republishing/
承認された会員提案の一覧. URL: https://www.w3.org/Submission/ The list of acknowledged Member Submissions. URL: https://www.w3.org/Submission/
会員提案要求の実施または撤回(会員限定利用). URL: https://www.w3.org/2000/09/submission Make or Withdraw a Member Submission Request (Member-only access). URL: https://www.w3.org/2000/09/submission
技術諮問委員会(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ホームページ. URL: https://www.w3.org/2001/tag/
The TAG home page. URL: https://www.w3.org/2001/tag/
事務局の連絡員の役割. URL: https://www.w3.org/Guide/teamcontact/role.html
Role of the Team Contact. URL: https://www.w3.org/Guide/teamcontact/role.html
W3C技術報告書の索引. URL: https://www.w3.org/TR/
The W3C technical reports index. URL: https://www.w3.org/TR/
どのように勧告工程の遷移を系統立てるか. URL: https://www.w3.org/Guide/transitions
Organize a Technical Report Transition. URL: https://www.w3.org/Guide/transitions
W3C技術報告書の翻訳についての情報. URL: https://www.w3.org/Consortium/Translation/
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/


Terms defined by this specification