W3C手続き文書
W3C Process Document

1. 導入
Introduction

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

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

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

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

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

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

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

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

The other sections of the Process Document:

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

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

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

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

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

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

2.1. 会員
Members

W3Cの会員は, 第一にW3C手続き文書の中で次のように表現されます.

W3C Members are primarily represented in W3C processes as follows:

1. 諮問委員会は, (最新の諮問委員会の委員 [最新のAC]の会員限定の一覧にあるように)各会員組織から1名の委員で構成されます. 諮問委員会は次のことを行います.
   The Advisory Committee is composed of one representative from each Member organization (refer to the Member-only list of current Advisory Committee representatives. [CURRENT-AC]) The Advisory Committee:
   • 毎回の諮問委員会の会議でのW3Cの計画の審査.
     reviews plans for W3C at each Advisory Committee meeting;
   • W3Cディレクターからの公式な提案である憲章の提案, 勧告案, 手続き文書案の審査.
     reviews formal proposals from the W3C Director: Charter Proposals, Proposed Recommendations, and Proposed Process Documents.
   • 諮問会議の議長以外の委員の選定.
     elects the Advisory Board participants other than the Advisory Board Chair.
   • 技術諮問委員会の委員の過半数(6名)の選定.
     elects a majority (6) of the participants on the Technical Architecture Group.

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

   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:

• 諮問委員会の席.
  A seat on the Advisory Committee;
• 会員限定の情報の利用.
  Access to Member-only information;
• 会員提案の手続き.
  The Member Submission process;
• W3C会員ロゴの広報資料への利用と, W3Cに会員が参加していることの公表. より詳細な情報については, 新会員オリエンテーション [導入]で述べられている会員ロゴ利用指針を参照して下さい.
  Use of the W3C Member logo on promotional material and to publicize the Member’s participation in W3C. For more information, please refer to the Member logo usage policy described in the New Member Orientation [INTRO].

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

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

• 作業部会や関連部会への参加.
  In Working Groups and Interest Groups.
• ワークショップやシンポジウムへの参加.
  In Workshops and Symposia;
• W3C特別研究員として事務局への参加.
  On the Team, as W3C Fellows.

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

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

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

2.1.2.1. 会員共同体
Membership Consortia

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

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

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

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

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

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

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

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

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

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

2.1.2.2. 関連会員
Related Members

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

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

1. どちらかの会員が, もう一方の系列組織である場合.
   Either Member is a subsidiary of the other, or
2. 両方の会員が, 共通の組織の系列組織である場合.
   Both Members are subsidiaries of a common entity, or
3. 会員が, W3Cの参加に影響する雇用契約またはコンサルタント契約を結んでいる場合.
   The Members have an employment contract or consulting contract that affects W3C participation.

系列組織は, 他の単独の組織に, 事実上の管理下に置かれているか, 過半数の資本金を所有されているかする組織です.

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

関連会員は, 新会員オリエンテーション [導入]で述べられている仕組みによって, 自分達の関係を開示しなければなりません.

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

2.1.3. 諮問委員会(AC)
Advisory Committee (AC)

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

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

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

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

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

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

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

1. 事務局から諮問委員会への公式な通知(例えば, この文書で必要とされている通知)のためのメーリングリスト. このメーリングリストは, 諮問委員会の委員に対しては, 受け取り専用です.
   One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. This list is read-only for Advisory Committee representatives.
2. 諮問委員会の委員間の議論のためのメーリングリスト. このメーリングリストは, 第一に諮問委員会の委員のためのものですが, 事務局は議論を監視しなければならず, 適切なときに議論に参加すべきです. 進行中の詳細な議論は, (新規または既存の, ワークショップのために作られるメーリングリストといった)他の適切なメーリングリストに移るべきです.
   One for discussion among Advisory Committee representatives. Though this list is primarily for Advisory Committee representatives, the Team must monitor discussion and should participate in discussion when appropriate. Ongoing detailed discussions should be moved to other appropriate lists (new or existing, such as a mailing list created for a Workshop).

諮問委員会の委員は, 自分達の組織から追加の人物を, これらのメーリングリストに参加させるよう依頼してもよいです. 配信に含められない場合は, 事務局の裁量で, 内部的に追加のメールアドレスの一時停止に至ってもよいです.

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

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

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

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

資源
Resources

• 各段階のW3C会員の数.
  The number of W3C Members at each level.
• W3Cの財務状態の概要.
  An overview of the financial status of W3C.

配分
Allocations

• 事務局の大きさや, おおよその配置を含めた, 年次予算の配分.
  The allocation of the annual budget, including size of the Team and their approximate deployment.
• (主に作業部会や関連部会を含めた)全ての活動の一覧, および特に前回の諮問委員会以降に開始または終了した活動を中心とした各活動の簡潔な報告書.
  A list of all activities (including but not limited to Working and Interest Groups) and brief status statement about each, in particular those started or terminated since the previous Advisory Committee meeting.
• 他の組織との連絡体制を続けるための資源の配分.
  The allocation of resources to pursuing liaisons with other organizations.

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

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

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

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

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

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

2.2. W3C事務局
The W3C Team

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

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

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

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

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

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

事務局の給料, 細かい予算化, 他の営業上の決定といった事務局の管理上の情報は, ホスト機関による管理を条件として, 事務局内限定です.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Created in February 2001, the mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:

1. ウェブ技術体系の基本原則について, 根拠を提供し, 合意を形成すること. また, 必要な場合にその基本原則を解釈し, 明確化すること.
   to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;
2. TAGに提起された一般的なウェブ技術体系に関係する課題を解決すること.
   to resolve issues involving general Web architecture brought to the TAG;
3. W3C内外の複数分野にまたがった技術に関して, 技術開発の調整を手助けすること.
   to help coordinate cross-technology architecture developments inside and outside W3C.

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

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

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

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

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

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

• ウェブ技術体系の課題に対する, 公開の議論の(単に入力に限らない)メーリングリスト. TAGは, このメーリングリストでの公の業務を管理するでしょう.
  a public discussion (not just input) list for issues of Web architecture. The TAG will conduct its public business on this list.
• TAGとの議論や, 何らかの理由で公開のメーリングリストに送ることができない依頼のための, 会員限定のメーリングリスト.
  a Member-only list for discussions within the TAG and for requests to the TAG that, for whatever reason, cannot be made on the public list.

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:

• 終身会員であるTim Berners-Lee.
  Tim Berners-Lee, who is a life member;
• 職務上のディレクター.
  The Director, sitting ex officio;
• ディレクターに指名された3名の委員.
  Three participants appointed by the Director;
• 諮問委員会により, AB/TAG 推薦と選挙の手続きに従って選任された6名の委員.
  Six participants elected by the Advisory Committee following the AB/TAG nomination and election process.

事務局は, 委員の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 諮問会議と技術諮問委員会の選挙を通じて, 第一の所属が同じ2名の委員は, 既存の委員の所属が変わったことに起因する場合を除いて, TAGの選任された席を同時に占有してはなりません. TAGに対する次の定期で予定されている選任期間が完了したとき, その組織は、多くても1つの持っている席を返さなければなりません.
  Two participants with the same primary affiliation per § 2.5.2 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the TAG except when this is caused by a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the organization must have returned to having at most one seat.
• § 2.5.2 諮問会議と技術諮問委員会の選挙を通じて, 第一の所属が同じ2名の委員は, ABの選任された席を同時に占有してはなりません. いかなる理由でも(例え, ABの委員が仕事を変わったためであっても), この制限が満たされない場合, その状況が解消しない限り, 1名の委員は, ABの委員を退任しなければなりません. 30日経ってもその状況が解消しない場合, 議長は, 後で述べる証明可能な無作為選択手続きを適用して, 委員を続ける1名を選び, 他の席の退任を宣言するでしょう.
  Two participants with the same primary affiliation per § 2.5.2 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the AB. If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs), one participant must cease AB participation until the situation has been resolved. If after 30 days the situation has not been resolved, the Chair will apply the verifiable random selection procedure described below to choose one person for continued participation and declare the other seat(s) vacant.
• 同じ人物が, TAGとAB両方の委員をしてはなりません.
  An individual must not participate on both the TAG and the AB.

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:

• 対象となる席の最小の数より大きいか等しく, 対象となる席の最大の数より小さいか等しい場合, 候補者は, そのことをもって選任されます. この状況は, 短い任期に割り当てる結果と同様と考えられます. さらに, 数が対象となる席の最大の数より小さい場合, 長い任期がまず埋められます.
  Greater than or equal to the minimum number of available seats and less than or equal to the maximum number of available seats, those nominees are thereby elected. This situation constitutes a tie for the purpose of assigning short terms. Furthermore, if the number is less than the maximum number of available seats, the longest terms are filled first.
• 対象となる席の最小の数より小さい場合, 十分な人数の人々が推薦されるまで, 推薦の要請が発せられます. 既に推薦されている候補者は, 新たに発せられる要請の後に, 再度推薦される必要はありません.
  Less than the minimum number of available seats, Calls for Nominations are issued until a sufficient number of people have been nominated. Those already nominated do not need to be renominated after a renewed call.
• 対象となる席の最大の数より大きい場合, 事務局は, 全ての候補の名前, 対象となる席の(最大の)数, 投票の締切, 選挙のために事務局が選んだ投票集計システムの詳細, 運営上の情報を含む投票の要請を発します.
  Greater than the maximum number of available seats, the Team issues a Call for Votes that includes the names of all candidates, the (maximum) number of available seats, the deadline for votes, details about the vote tabulation system selected by the Team for the election, and operational information.

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

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

最も短い任期は, 投票の集計で最も低かった選任された候補者に割り当てられ, 次に短い任期は, 次に低かった選任された候補者にといった具合になります. 短い任期に適当な候補者の間で同点の状況では, 後で述べる証明可能な無作為選択手続きが短い任期を割り当てるのに利用されるでしょう.

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

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

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

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

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

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

W3Cは, 次の場合にこの手続きを適用します.

W3C applies this procedure as follows:

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

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

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

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

• 委員が辞任した場合.
  the participant resigns, or
• 諮問会議とTAGの委員が, 諮問会議とTAGの委員の制限にもはや抵触するような所属に変わった場合.
  an Advisory Board or TAG participant changes affiliations such that the Advisory Board and TAG participation constraints are no longer met, or
• ディレクターが§ 3.1 個人の参加基準の節に示した基準に抵触する過失を犯した委員を解任した場合.
  the Director dismisses the participant for failing to meet the criteria in section § 3.1 Individual Participation Criteria, or
• 委員の任期が終了した場合.
  their term ends.

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

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:

• 退任された席が指名されたTAGの席の場合, ディレクターは, 直ちに誰かを再指名してもよいです. ただし, 次の定期で予定されている選挙より遅くなることの無いように指名します.
  When an appointed TAG seat is vacated, the Director may re-appoint someone immediately, but no later than the next regularly scheduled election.
• 退任された席がABまたはTAGのどちらかの選任された席の場合, その委員会の議長が, 次の定期で予定されている選挙より前に, (例えば, その委員会の仕事量のために)W3Cが選挙を開催するよう求めない限り, 次の定期のときに埋められます.
  When an elected seat on either the AB or TAG is vacated, the seat is filled at the next regularly scheduled election for the group unless the group Chair requests that W3C hold an election before then (for instance, due to the group’s workload).
  • 委員会の議長は, 次の定期で予定されている選挙が3ヵ月以内である場合, そのような選挙の要請を行うべきではありません.
    The group Chair should not request such an election if the next regularly scheduled election is fewer than three months away.
  • 将来の特定の日に辞任する場合も含め, 現在の委員が辞任の意向を示したらすぐに委員会の議長が選挙を求めてもよく, 選挙が始まってもよいです.
    The group Chair may request an election, and the election may begin, as soon as a current member gives notice of a resignation, including a resignation effective as of a given date in the future.

  そのような選挙が開催された場合, 対象となる席の最小の数は, 選任された席の合計の最小の数(TAGは6名, ABは9名)から継続する委員の数を引いた数です. 最大の数は, 全ての空いている席の数に一致します. 対象となる席の数と任期の長さを除いて, 諮問会議と技術諮問委員会の選挙の通常の規則が適用されます.

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

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

• W3Cに関わる活動を行っている組織の有償のコンサルタント, もしくは, 資本の持ち分(株式の分担, ストックオプション, 企業の資本の他の形式)によって報酬を支払われたコンサルタント.
  Paid consulting for an organization whose activity is relevant to W3C, or any consulting compensated with equity (shares of stock, stock options, or other forms of corporate equity).
• W3Cに関係する他の組織で(理事会における代表といった)意思決定の役割, 責任を追うもの.
  A decision-making role/responsibility (such as participating on the Board) in other organizations relevant to W3C.
• 一切, 意思決定の権限に関係しないとしても, 公に理事者に見える立場の者.
  A position on a publicly visible advisory body, even if no decision-making authority is involved.

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

Individuals seeking assistance on these matters should contact the Team.

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

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

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

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

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

例外的な状況(例えば, 部会の進展を阻んだり, 利益衝突を生じたりしてるであろう状況)において, ディレクターは, 諮問委員会の委員が指名した個人の部会への参加を拒否してもよいです.

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

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

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

3.2. 会議
Meetings

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

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

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

W3C distinguishes two types of meetings:

1. 対面での会議は, ほとんどの出席者が, 同じ物理的な場所で参加することが期待される会議です.
   A face-to-face meeting is one where most of the attendees are expected to participate in the same physical location.
2. 分散型の会議は, ほとんどの出席者が, 遠隔で(例えば, 電話, ビデオ会議, IRC(訳注:インテリジェント遠隔制御)で)参加することが期待される会議です.
   A distributed meeting is one where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC).

議長は, 例外的な基準で会議に出席するように, 特に高度な専門知識を持った人物を紹介してもよいです. この人物は, 会議の来賓で, 部会の参加者ではありません. 会議の来賓は, 投票権を持ちません. 全ての会議の来賓に憲章で定めれらた秘密保持の水準や部会の他の要件を確実に尊重させることは, 議長の責任です.

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

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

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

次の表は, 会議を体系付けるために要件を一覧にしたものです.

The following table lists requirements for organizing a meeting:

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

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

3.3. 合意
Consensus

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

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

注意: ディレクター, CEO, COO(訳注:最高業務執行責任者)は, 諮問委員会の中の合意を判断する役割があります.

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

次の用語は, この文書の中で, 適切な人々の集まりの中の, 決定に対する支持の水準を説明しています.

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

合意:
Consensus:

集まりの中の人々の相当な数が決定を支持し, その集まりの中の誰も正式な異議を示していないこと. その集まりの中の人々は, 棄権してもよいです. 棄権は, 意見が無いことを表明するか, 沈黙するかです.

A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection. Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set.

全員の合意:
Unanimity:

集まりの中の全ての人々が決定を支持する(すなわち, その集まりの誰も棄権しない)合意の特別な状況.

The particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).

不同意:
Dissent:

集まりの中の少なくとも1人が正式な異議を示している場合.

At least one individual in the set registers a Formal Objection.

通常, 決定において参加するのに適切な人々の集まりは, 部会の参加者の集まりです. 手続き文書は, 決定のための定数(すなわち, 議長が質問を投げ掛ける前に出席する必要がある適切な人々の最小の数)を必須としていません. 憲章は, 合意の決定に定数の要件を含んでもよいです.

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

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

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

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:

• 追加の技術的情報.
  additional technical information,
• 予定されていた会議に出席できなかった参加者からのeメールによる意見.
  comments by email from participants who were unable to attend a scheduled meeting,
• 会議中, 話さないことを選んだ出席者からのeメールによる意見(そのため, 例えば, 後で同僚と協議したり, 文化的な理由が原因で協議したりできます).
  comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues or for cultural reasons).

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

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

3.4. 投票
Votes

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

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

• 投票されることとなった課題の説明.
  an explanation of the issue being voted on;
• 課題を解決するための投票(例えば, 単純な多数決)を行う決定.
  the decision to conduct a vote (e.g., a simple majority vote) to resolve the issue;
• 投票の結果.
  the outcome of the vote;
• 正式な異議.
  any Formal Objections.

実質的な課題を解決する目的で投票するためには, 投票者は部会の参加者でなければなりません. 各組織が部会の中で(外部の専門家も含め)複数の参加者を代表している場合でさえ, その代表する組織は多くて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:

• 会員または関連会員のグループは, 単独の組織と見なされます.
  A Member or group of related Members is considered a single organization.
• 事務局は, 組織と見なされます.
  The Team is considered an organization.

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

Unless the charter states otherwise, Invited Experts may vote.

参加者が投票に参加できない場合, その参加者は, 誰かに会議で代理として行動する権限を与えてもよいです. 欠席する参加者は, 代理を利用する指示書と一緒に, 誰が代理として行動するのか議長に書面で知らせなければなりません. 作業部会または関連部会に対する, 参加者の代理人として会議に参加する個人についての関係する必要事項を参照して下さい.

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

部会は, 実質的な課題を解決する以外の, 他の目的で投票を行ってもよいです. 例えば, 議長は, 可能性のある決定について, 合意があるかどうかを決定する手段として“世論調査”の投票をよく行います.

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

部会は, 手続きを決定するにも投票を行ってもよいです. 例えば, 会議を(地理的にほとんど変わらない)サンフランシスコまたはサンノゼのどちらで開催するか, 単純な多数決で決めることは適当です. 重要でない課題を決定するのに単純な多数決を用いる場合, 投票者にとって投票する理由を表明することは必須ではなく, 部会にとって個人の投票を記録することは必須ではありません.

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

部会の憲章は, 実質的な課題についての決定を行うのに, (例えば, 必要な定数または閾値といった)正式な投票の手続きを含んでもよいです.

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

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

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技術報告書(とソフトウェア)は, 一般社会で使用料無しに利用できます(W3C文書ライセンス [文書ライセンス]を参照して下さい).
  W3C technical reports whose publication has been approved by the Director. Per the Membership Agreement, W3C technical reports (and software) are available free of charge to the general public; (refer to the W3C Document License [DOC-LICENSE]).
• W3Cの目的と使命, 会員への鍵となる恩恵, W3Cの組織構成を説明した活動理念 [理念].
  A mission statement [MISSION] that explains the purpose and mission of W3C, the key benefits for Members, and the organizational structure of W3C.
• 会員規約 [会員規約]や, W3Cが他の団体と交わした何らかの法的債務の文書を含む, 法的文書.
  Legal documents, including the Membership Agreement [MEMBER-AGREEMENT] and documentation of any legal commitments W3C has with other entities.
• 手続き文書.
  The Process Document.
• W3Cの活動とワークショップの結果の公開.
  Public results of W3C activities and Workshops.

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:

• W3Cの中で機密として情報を扱わなければなりません.
  must treat the information as confidential within W3C,
• 機密の望ましいレベルを管理するための理性的な努力を働かせなければなりません.
  must use reasonable efforts to maintain the proper level of confidentiality, and
• それらの情報を一般社会や報道に公開してはなりません.
  must not release this information to the general public or press.

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

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

諮問委員会の委員は, 会員の代表者や, 受領者として適切だと考えられる会員の他の従業員に, 会員限定の利用を認定してもよいです. 例えば, 会員限定のニュースの通知を自分達の組織の中のみの内部利用のために配布するかどうかは, 諮問委員会の委員, 他の従業員, 組織の公式な代表者の責任です. 会員メーリングリストについての情報は, 新会員オリエンテーション [導入]で確認できます.

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

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

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

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

この文書は, どの情報が会員または一般に利用可能でなければならないかを, 例え, その情報が最初は事務局限定または会員限定の経路でやりとりしていたとしても, 明確に示します. 事務局と事務局に認定された関係者のみが, それらの情報の機密レベルを変更してもよいです. その場合, 次のように行います.

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

1. 事務局は, 著者によって新しい機密レベルのものとして明確に提供されたバージョンの情報を使用しなければなりません. 審査の要請や他の似た情報伝達において, 事務局は, 受領者にそのどのバージョンを提供したか念を押すべきです.
   The Team must use a version of the information that was expressly provided by the author for the new confidentiality level. In Calls for Review and other similar messages, the Team should remind recipients to provide such alternatives.
2. 事務局は, 著者の同意無しに, 新しい機密レベルのバージョンを著者のものであると考えてはいけません.
   The Team must not attribute the version for the new confidentiality level to the author without the author’s consent.
3. 著者が, 他の機密レベルに適したバージョンを事務局に伝えなかった場合, 事務局は, 元々の機密レベルを尊重しながら, 元々の著者のせいにすることなく, 必要な内容を分別よく情報伝達できるバージョンを利用可能にしてもよいです.
   If the author has not conveyed to the Team a version that is suitable for another confidentiality level, the Team may make available a version that reasonably communicates what is required, while respecting the original level of confidentiality, and without attribution to the original author.

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

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

This document defines two types of groups:

作業部会.

Working Groups.

作業部会は, 典型的に成果(例えば, 勧告工程にある技術報告書, ソフトウェア, テストツール, 他の部会の成果の審査)を生み出します. W3C特許指針[特許指針]で述べられている追加の参加者の要件があります.

Working Groups typically produce deliverables (e.g., Recommendation Track technical reports, software, test suites, and reviews of the deliverables of other groups). There are additional participation requirements described in the W3C Patent Policy [PATENT-POLICY].

関連部会.
Interest Groups.

関連部会の第一の目標は, 潜在的なウェブ技術や指針を計画しようとしている人々を呼び集めることです. 関連部会は, 意見交換のための公共の場です.

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

関連部会は, 勧告工程にある技術報告書を公表しません. 関連部会に対する成熟レベルについての情報を参照して下さい.

Interest Groups do not publish Recommendation Track technical reports; see information about maturity levels for Interest Groups.

5.1. 全ての作業部会と関連部会に対する要件
Requirements for All Working and Interest Groups

各部会は, 憲章を持たなければなりません. 憲章に対する要件は, 部会の種類に依存します. 全ての部会憲章は, (例え, 部会の他の進捗状況が会員限定であっても)公開でなければなりません.

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

各部会は, 部会の仕事を調整する議長(または共同議長)を持たなければなりません. ディレクターは, 全ての部会の議長を指名(および再指名)します. 議長は, 会員の代表者, 事務局の代表者, (ディレクターにより招待された)外部の専門家のどれかです. それらの形式の参加者に適用される, この文書に書かれた要件が, 議長にも同様に適用されます. 議長の役割 [議長]は, 合意の要領 [案内]で述べられています.

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

各部会は, 議長, 部会の参加者, 事務局の間の連絡を担う事務局の連絡員を置かなければなりません. 事務局の連絡員の役割 [事務局の連絡員]は, 合意の要領 [案内]で述べられています. 議長と事務局の連絡員は同一人物でない方がよいです.

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

各部会は, 公式な部会のやり取り(例えば, 会議の案内や議事録, 決定の文書化, 決定への正式な異議)を一覧に記録したメーリングリストを持たなければなりません. 新しい参加者の全ての関係するメーリングリストへの参加を確実にするのは, 議長と事務局の連絡員の責任です. 部会のメーリングリスト [部会メール]の一覧を参照して下さい.

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

議長は, 部会の割り当てた任務を遂行するために(部会の参加者で構成される)プロジェクトチームを形作ってもよいです. プロジェクトチームの任務の範囲は, 部会の憲章の範囲を超えてはなりません. 部会は, プロジェクトチームを作る過程を文書化すべきです(例えば, 各プロジェクトチームは略式の"憲章"を持ってもよいでしょう). プロジェクトチームは, 技術報告書を公表しません. 部会は, プロジェクトチームの成果を技術報告書の一部として採用してもよいです.

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

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

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

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

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

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

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

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

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

この文書または部会の憲章に注意書きがある場合を除いて, 全ての参加者は, 部会の中で同じ権利と責任を持っています. 個人の参加基準も参照して下さい.

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

参加者は, 作業部会または関連部会の中の複数の組織を代表してもよいです. それらの組織は, 全て部会のメンバーでなければなりません.

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

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

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

例外的な基準として, 作業部会や関連部会の参加者は, 会議に出席する代理人を指名してもよく, その場合, 議長に通知すべきです. 代理人は, 投票も含めて, 参加者の代理として行動してもよいです. 投票する代理人について, 参加者は, 前もって書面で議長に通知しなければなりません. 部会への礼儀として, 代理人が部会の議論をよく知らないのなら, 元の参加者は, 投票で代理として行動する権限を他の参加者に渡すべきです.

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

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

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

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

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

5.2.1.1. 作業部会における会員の代表者
Member Representative in a Working Group

全ての次の条件を満たす場合, その人物は, 作業部会における会員の代表者です.

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

• 当該会員の諮問委員会の委員が, 作業部会の参加者としてその人物を指名してきた場合.
  the Advisory Committee representative of the Member in question has designated the individual as a Working Group participant, and
• その人物が会員の代表者に適任である場合.
  the individual qualifies for Member representation.

作業部会における会員の代表者として個人を指名するために, 諮問委員会の委員は, 議長と事務局の連絡員に, 全ての次に示す情報を, (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:

• 部会が終了するまで.
  the group closes, or
• 会員が作業部会を辞めるまで. このことは, 会員の諮問委員会の委員を通して行われます.
  the Member resigns from the Working Group; this is done through the Member’s Advisory Committee representative.

5.2.1.2. 関連部会における会員の代表者
Member Representative in an Interest Group

参加要件が関連部会のメーリングリストの購読だけでない場合で, 次の全ての要件を満たす場合, その人物は関連部会における会員の代表者です.

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

• 当該会員の諮問委員会の委員が, 関連部会の参加者としてその人物を指名してきた場合.
  the Advisory Committee representative of the Member in question has designated the individual as an Interest Group participant, and
• その人物が会員の代表者に適任である場合.
  the individual qualifies for Member representation.

関連部会における会員の代表者として個人を指名するために, 諮問委員会の委員は, 参加の要請の指示に従わなければなりません.

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

関連部会への会員の参加は, 作業部会と同じ条件によって終了します.

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

5.2.1.3. 作業部会における外部の専門家
Invited Expert in a Working Group

議長は, 作業部会に参加する特定の専門知識を持った人物を招待してもよいです. その人物は, (例えば, 他の組織との連絡係として行動してるといった具合に)部会の中で組織を代表してもよいです.

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

次の全ての要件を満たす場合, その人物は, 作業部会における外部の専門家です.

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

• 議長が, 部会の参加者として, その人物を指名している場合.
  the Chair has designated the individual as a group participant,
• 事務局の連絡員が, 議長の選抜に合意している場合.
  the Team Contact has agreed with the Chair’s choice, and
• その人物が, 外部の専門家として必要な情報を, 議長と事務局の連絡委員に提供している場合.
  the individual has provided the information required of an Invited Expert to the Chair and Team Contact.

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

To designate an individual as an Invited Expert in a Working Group, the Chair must inform the Team Contact and provide rationale for the choice. When the Chair and the Team Contact disagree about a designation, the 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:

• もし, その人物が, その部会で参加者として組織を代表しているならば, その組織を特定しなければなりません.
  identify the organization, if any, the individual represents as a participant in this group,
• 外部の専門家・協力者規約 [協力者規約]の条件に合意しなければなりません.
  agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT],
• 憲章に明記されている参加条件を, W3C特許指針[特許指針]の参加の要件, 特に“外部の専門家に対するライセンス義務における注意”と“開示情報”を含めて, 特定の憲章の日付とバージョンを示して受け入れなければなりません.
  accept the participation terms set forth in the charter, including the participation requirements of the W3C Patent Policy [PATENT-POLICY], especially in “Note on Licensing Commitments for Invited Experts” and in “Disclosure”, indicating a specific charter date or version,
• その人物がW3C会員の従業員であるかどうか開示しなければなりません. 利益衝突の指針を参照して下さい.
  disclose whether the individual is an employee of a W3C Member; see the conflict of interest policy,
• その人物が参加のために(例えば, 旅行, 通信, 会議のために)誰が財務上の支援を行うのかを記した声明書を提供しなければなりません.
  provide a statement of who will provide the necessary financial support for the individual’s participation (e.g., for travel, telephone calls, and conferences), and
• その人物の雇用主(または自営業である場合のその人物自身), もしくはその人物が代表している組織がW3C会員でない場合, それらの組織がW3Cに参加するつもりであるかどうか示さなければなりません. それらの組織がW3Cに参加するつもりがない場合, その選択に対し, その人物が知っている理由を示さなければなりません.
  if the individual’s employer (including a self-employed individual) or the organization the individual represents is not a W3C Member, indicate whether that organization intends to join W3C. If the organization does not intend to join W3C, indicate reasons the individual is aware of for this choice.

議長は, 作業部会における外部の専門家として, 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:

• 部会が終了するまで.
  the group closes, or
• 議長またはディレクターが参加の招待を取り消すまで.
  the Chair or Director withdraws the invitation to participate, or
• その人物が辞めるまで.
  the individual resigns.

5.2.1.4. 関連部会における外部の専門家
Invited Expert in an Interest Group

参加要件が関連部会のメーリングリストの購読だけでない場合, 関連部会における外部の専門家に対する参加要件は, 作業部会における外部の専門家の要件と同じになります.

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

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

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

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

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

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

• 部会が終了するまで.
  the group closes, or
• W3Cの運営が, 議長にeメールを送り, そのコピーを部会のメーリングリストへも送ることによって, 事務局の代表者を変更するまで.
  W3C management changes Team representation by sending email to the Chair, copying the group mailing list.

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

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

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

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

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

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

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

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

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

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

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

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

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

• 憲章の延長.

  a charter extension

• 重大な点で部会が役割を果たす方法に影響を与えない憲章の本質的な変更.

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

審査の期間は, 少なくとも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.

• 部会の使命(例えば, 技術または手続きの開発, 他の部会の成果の審査).
  The group’s mission (e.g., develop a technology or process, review the work of other groups);
• 部会の仕事の範囲と成功の基準.
  The scope of the group’s work and criteria for success;
• 部会の活動期間(典型的に6ヵ月から2年までの間).
  The duration of the group (typically from six months to two years);
• 何らかの成果(技術報告書, 他の部会の成果の審査, ソフトウェア)の特質.
  The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software);
• 可能であれば, 期待される重要な段階の期日.
  Expected milestone dates where available.

  注意:憲章において, 他の部会の成果の審査の計画を含むことは必須ではありません.

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

• (中間の結果も含めた)成果の公開を承認する部会の手続き.
  The process for the group to approve the release of deliverables (including intermediate results);
• この部会の成果における, W3C内外の部会との依存関係. どの依存関係に対しても, 憲章は, 成果についてのやり取りの仕組みを指定しなければなりません.
  Any dependencies by groups within or outside of W3C on the deliverables of this group. For any dependencies, the charter must specify the mechanisms for communication about the deliverables;
• W3C内外の部会における, この部会の依存関係. この依存関係は, W3Cの対等の部会 [憲章]を含みます.
  Any dependencies of this group on other groups within or outside of W3C. Such dependencies include interactions with W3C Horizontal Groups [CHARTER];
• 部会の進捗状況と成果の機密レベル.
  The level of confidentiality of the group’s proceedings and deliverables;
• 会議の仕組みと予定されている頻度.
  Meeting mechanisms and expected frequency;
• 決まっていれば, 最初の対面での会議の日程. 提案された部会の最初の対面での会議の日程は, 提案の日から8週間後以降でなければなりません.
  If known, the date of the first face-to-face meeting. The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal.
• 部会に従事する際の, 部会とW3Cの残りの部会, 一般社会とのやり取りの仕組み.
  Communication mechanisms to be employed within the group, between the group and the rest of W3C, and with the general public;
• § 3.4 投票で指定されている以外の, 何らかの投票の手続きまたは要件.
  Any voting procedures or requirements other than those specified in § 3.4 Votes;
• 参加者に期待される従事期間の見込み.
  An estimate of the expected time commitment from participants;
• 事務局に期待される従事期間やその水準(例えば, 開発の経緯の記録, 技術報告書を書いたり編集すること, コードの開発, 試験手続きの体系化).
  The expected time commitment and level of involvement by the Team (e.g., to track developments, write and edit technical reports, develop code, or organize pilot experiments).
• 知的所有権の情報. 部会の成功に影響する(特許と著作権を含む)知的所有権の考慮すべきことは何か? 特に, W3C特許指針[特許指針]の“W3C仕様書のライセンスの目標”における, ロイヤリティフリーライセンスの目標を満たすことが困難となると考えられる, 何らかの理由があるか?
  Intellectual property information. What are the intellectual property (including patents and copyright) considerations affecting the success of the Group? In particular, is there any reason to believe that it will be difficult to meet the Royalty-Free licensing goals in “Licensing Goals for W3C Specifications” in the W3C Patent Policy [PATENT-POLICY]?

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

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

(同じ名前の前身となる部会を含む)何らかの他の憲章の下で公表された技術報告書の作業を継続する, 全ての勧告工程にある成果に対して, 少なくとも存在する初期草案に対して, 採用する作業部会の提案された憲章の中の説明は, 次に示す情報を提供しなければなりません.

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

• 表題, 不変のURL, 成果における作業の基礎になるであろう, (“採用された草案”に分類される)草案や他の勧告工程にある文書の公表された日付.
  The title, stable URL, and publication date of the Working Draft or other Recommendation-track document that will serve as the basis for work on the deliverable (labeled “Adopted Draft”);
• 表題, 不変のURL, W3C特許指針[特許指針]を通して, 最も直近の除外機会(注釈:W3C特許指針で特許所有者がRFライセンスから除外されることを表明できる機会)に基礎として使われていた(“除外された草案”に分類される)文書の公開された日付.
  The title, stable URL, and publication date of the document that was used as the basis for its most recent Exclusion Opportunity as per the W3C Patent Policy [PATENT-POLICY]. (labeled “Exclusion Draft”); and
• 除外された草案を公表した作業部会の(“他の憲章”に分類される)憲章の不変のURL.
  The stable URL of the Working Group charter under which the Exclusion Draft was published (labeled the “Other Charter”).

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

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:

• W3Cの中で認められた優先順位によって, 憲章に書かれた成果を生み出したり, 部会を管理したりするのに不十分な資源しか無い場合.
  There are insufficient resources to produce chartered deliverables or to maintain the group, according to priorities established within W3C.
• 部会が憲章に書かれた成果を, 予定よりも早く生み出した場合.
  The group produces chartered deliverables ahead of schedule.

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

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:

• 多様な仕様書開発の方法論に対応する.
  support multiple specification development methodologies
• 安定した技術報告書の内容に対する合意を最大化する.
  maximize consensus about the content of stable technical reports
• 高い技術および編集上の質を確かなものにする.
  ensure high technical and editorial quality
• 仕様書間の一貫性を促進する.
  promote consistency among specifications
• ロイヤリティフリーで相互運用性のある, ウェブ標準の実装を手助けする.
  facilitate royalty-free, interoperable implementations of Web Standards, and
• W3Cや広く社会から支持を得る.
  earn endorsement by W3C and the broader community.

W3C特許指針[特許指針]の“W3C仕様書のライセンスの目標”も参照して下さい.

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.

勧告
Recommendations

作業部会は, ウェブの標準として標準仕様書または手引きを生み出すために, 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.

メモ
Notes

部会は, 典型的に, 仕様書に刺激を与える使用方法やその使用の最善の実施例といった技術仕様書でない情報を文書化するか, もしくは, 思いのままの作業の状態を明確にするのに, 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:

• 仕様書が発行されるたびに一意のものでなければなりません.
  must be unique each time a specification is published,
• どの作業部会が仕様書を開発したのかをはっきり述べなければなりません.
  must state which Working Group developed the specification,
• どのように意見やバグの報告を送るか, また, それらがどこに記録されるかをはっきり述べなければなりません.
  must state how to send comments or file bugs, and where these are recorded,
• 次の段階で期待される内容を含まなければなりません.
  must include expectations about next steps,
• どのようにその技術が国際標準やW3Cの内外の関連する作業に関係しているかを説明すべきです.
  should explain how the technology relates to existing international standards and related work inside or outside W3C, and
• 前回のバージョンからの重大な変更について説明するか, 説明へのリンクを貼るかすべきです.
  should explain or link to an explanation of significant changes from the previous version.

技術報告書開発手続きの一部として発行された技術報告書は, 部会の議長に指名された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.

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

2. 適合に影響しない訂正

   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.

3. 新しい機能を追加しない訂正

   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.

4. 新しい機能

   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 corrections—must be marked as such, are treated as class 2 changes, and are published accordingly.

注意:この方法で注釈として付けられた変更は, 勧告や勧告候補といったより熟慮された文書を, 例え, 変更候補が重要な審査意見や適切に仕様書に標準的に組み入れる実装の実績がまだだったとしても, 作業部会の最新のものと一緒に早急に更新することを認めています.

Note: Annotating changes in this way allows more mature documents such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, even when the candidate 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度示すと, 勧告候補の段階となります. このことは, 仕様書が実際に機能することを証明する実装の実績を作業部会が正式に集める間, 全てのＷ3Ｃ会員に仕様書に意見を提供することを認めています. その次の段階は, 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.

この手続き文書は, 特許審査草案として最新の勧告工程の発行物を定義しています. 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
• 実装の実績を集めるため.
  gather implementation experience

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

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.

注意:勧告として以前に発行されていた技術報告書が, その文書を改訂するのに必要な工程に従って勧告として再度発行されたとき, 最新のバージョンは, § 6.2.12.3 W3C勧告の断念の工程を実施する必要無しに以前のものを置き換えます. その文書は, 更新された同じ文書です. 文書が置換されたと明確に宣言し, § 6.2.12.3 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 § 6.2.12.3 Abandoning a W3C Recommendation: it is the same document, updated. Explicitly declaring a documented superseded, using the process documented in § 6.2.12.3 Abandoning a W3C Recommendation, is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

旧式勧告
An Obsolete Recommendation

旧式勧告は, 実装するための推奨を継続する十分な市場性を欠いていると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):

• 最新の仕様書の各機能は実装されているか, また, どのようにそのことを証明しているか?
  is each feature of the current specification implemented, and how is this demonstrated?
• 最新の仕様書の独立した相互運用可能な実装があるか?
  are there independent interoperable implementations of the current specification?
• 仕様書の著者以外の人々によって作られた実装があるか?
  are there implementations created by people other than the authors of the specification?
• 実装は公然と展開されているか?
  are implementations publicly deployed?
• 仕様書の各段階の実装システム(編集, 利用, 配布など)で実装の実績があるか?
  is there implementation experience at all levels of the specification’s ecosystem (authoring, consuming, publishing…)?
• 実装に伴う困難な点または問題点の報告があるか?
  are there reports of difficulties or problems with implementation?

(相互運用可能な)実装の証明を計画し成し遂げることは, たくさんの時間を費やすことになるでしょう. 部会は, 開発手続きの早いうちに, どのように相互運用可能な実装を証明するか計画すれば, より効果的に作業できます. 例えば, 実装の努力と協力して開発テストを行うことです.

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

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

• 進展を要求する部会決定を記録しなければなりません.
  must record the group’s decision to request advancement.
• ディレクターの承認を得なければなりません.
  must obtain Director approval.
• 前回の公開以降の技術報告書に対する全ての新しい機能(種類4の変更)を公然と文書化しなければなりません.
  must publicly document all new features (class 4 changes) to the technical report since the previous publication.
• 他の実質的な変更(種類3の変更)が行われたかどうか公然と文書化しなければならず, そのような変更の詳細について文書化すべきです.
  must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.
• 編集上の変更が行われたかどうか公然と文書化すべきで, そのような変更の詳細について文書化してもよいです.
  should publicly document if editorial changes have been made, and may document the details of such changes.
• 以前の成熟レベル以降に文書に挙げられた課題を正式に取り組まなければなりません.
  must formally address all issues raised about the document since the previous maturity level.
• どの公式な異議の公開の文書も提供しなければなりません.
  must provide public documentation of any Formal Objections.
• もし, 前回の段階以降にその文書に対する作業部会の要求するもので変わったものがあるのならば, その内容を報告すべきです.
  should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
• 他の部会との依存関係における変更があれば報告すべきです.
  should report any changes in dependencies with other groups.
• 作業部会が知っている実装についての情報を提供すべきです.
  should provide information about implementations known to the Working Group.

初期草案に対して何も“以前の成熟レベル”は無いので, 多くの要件は適用されず, 承認は, 通常かなり自動的です. 後の段階では, 特に勧告候補または勧告案への遷移においては, 通常, ディレクターの承認が下りる前に, 要件が満たされていることを確かなものにする正式な審査の会議があります.

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

• 更新を要求する部会決定を記録しなければなりません.
  must record the group’s decision to request the update.
• 変更が広範囲にわたる審査を受けていたことを示さなければなりません.
  must show that the changes have received wide review.
• ディレクターの承認を得るか, § 6.2.4.1 合理化された発行承認の基準を満たさなければなりません.
  must obtain Director approval, or fulfill the criteria for § 6.2.4.1 Streamlined Publication Approval.
• どの公式な異議の公開の文書も提供しなければなりません.
  must provide public documentation of any Formal Objections.
• 前回の公開以降の技術報告書に対する全ての新しい機能(種類4の変更)を公然と文書化しなければなりません.
  must publicly document of all new features (class 4 changes) to the technical report since the previous publication.
• 他の実質的な変更(種類3の変更)が行われたかどうか公然と文書化しなければならず, そのような変更の詳細について文書化すべきです.
  must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.
• 編集上の変更が行われたかどうか公然と文書化すべきで, そのような変更の詳細について文書化してもよいです.
  should publicly document if editorial changes changes have been made, and may document the details of such changes.
• 改訂された仕様書が作業部会の要求するものを全て処理したことを示すか, その要求するものが変更されたか延期されていることを説明しなければなりません.
  must show that the revised specification meets all Working Group requirements, or explain why the requirements have changed or been deferred,
• もし, 前回の段階以降にその文書に対する作業部会の要求するもので変わったものがあるのならば, その内容を報告すべきです.
  should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
• 他の部会との依存関係における変更があれば報告すべきです.
  should report any changes in dependencies with other groups.
• 作業部会が知っている実装についての情報を提供すべきです.
  should provide information about implementations known to the Working Group.

通常, ディレクターの承認が下りる前に, 要件が満たされていることを確かなものにする正式な審査の会議があります.

There is usually a formal review meeting to ensure the requirements have been met before 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.

6.2.4.1. 合理化された発行承認
Streamlined Publication Approval

注意:これらの基準は, 故意に更新要求に対する一般的な要件より厳格です. このことは, あいまいさや専門家の判断の必要性を最小限とし, 自己評価を現実的なものにするためです.

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

議論の余地のない場合の発行手続きを合理化するために, 更新要求の承認は, 次の示す追加の基準が満たされているとき, 正式な審査無しに認められます.

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

• その文書について作業部会の要求するものに何も変更があってはなりません.
  There must have been no changes to Working Group requirements about this document.
• それぞれのW3Cの対等な部会 [憲章]に対して, 対等な審査を行う部会が審査が必要ない状況での一通りの基準を認めているのであれば, 作業部会は, それらの基準が満たされていることを文書化しなければなりません. そうでなければ, 作業部会は, そららの部会からの審査を要求し受領しなければなりません.
  For each of the W3C Horizontal Groups [CHARTER], if the Horizontal Review Group has made available a set criteria under which their review is not necessary, the Working Group must document that these criteria have been fulfilled. Otherwise, the Working Group must show that review from that group has been solicited and received.
• 何も正式な異議が文書に対して示されていてはなりません.
  No Formal Objection has been registered against the document.
• 作業部会は, 次のことに正式に取り組まなければなりません.
  The Working Group must have formally addressed:

  • 前回の発行以降の変更によって生じた, 文書に対して挙げられた全ての課題

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

  • 前回の発行以降の変更に対して挙げられた全ての課題

    all issues raised against changes since the previous publication

  • 前回の発行以降に, 何も変更無しにまとめられた文書に対して挙げられた全ての課題

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

  これらの各課題に対する回答は, その課題を挙げた人を満足するものでなければなりません. そららの提案が受け入れられるか, 折衷案が見つかけられるか, 提案を却下した作業部会の根拠を提案した人が受け入れるかです.

  The response to each of these issues must be to the satisfaction of the person who raised it: their proposal has been accepted, or a compromise has been found, or they accepted the Working Group’s rationale for rejecting it.

  注意:これらは, 一般的な遷移要求の基準より厳格です.

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

加えて, 実質的な変更または新しい機能を伴って勧告を更新する場合, 次の基準が満たされているときに, 認められます.

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

• 文書への変更が, 訂正案審査の最終要請に含まれている訂正案か, 場合によっては種類1または2の変更を組合わせたもの, または(新しい機能を認めている勧告の場合に)追加案審査の最終要請に含まれている追加案に限られていなければなりません.
  Changes to the document are limited to proposed corrections that were included in a Last Call for Review of Proposed Corrections possibly combined with class 1 or 2 changes, and/or (in the case of a Recommendation that allows new features) proposed additions that were included in a Last Call for Review of Proposed Additions.
• 作業部会は, 全ての変更が少なくとも2つの別個の実装者による2つの別個の製品で実装されていることを示さなければなりません. 変更を広範囲にわたって対応するテストツールによる試験を通ること, または, 作業部会憲章で述べられている代替の合理化され認められた実装要件を取り扱うことによって, 立証しなければなりません.
  The Working Group must show that all changes have been implemented in at least 2 distinct products by 2 different implementers, as evidenced by passing tests of a test suite providing extensive coverage of the changes, or an alternative streamlined approval implementation requirement described in the working Group charter has been met.

  注意:これらは一般的な十分な実装の実績の基準より厳格です.

  Note: This is stricter than the general criteria for adequate implementation experience.

作業部会は, これらの主張に対する文書化された証拠を提供しなければならず, 事務局は, その回答を公に永久に利用できるようにしねければなりません.

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:

• 発行を要求した部会決定を記録しなければなりません. これは手続き上の段階で, 合意は必須ではありません.
  must record the group’s decision to request publication. Consensus is not required, as this is a procedural step,
• 以前の草案以降の技術報告書に対する実質的な変更の公開の文書を提供しなければなりません.
  must provide public documentation of substantive changes to the technical report since the previous Working Draft,
• 前回の段階以降の技術報告書に対する重大な編集上の変更の公開の文書を提供すべきです.
  should provide public documentation of significant editorial changes to the technical report since the previous step,
• もし前回の段階以降に, その文書に対する作業部会の要求するもので変わったものがあるのならば, その内容を報告すべきです.
  should report which, if any, of the Working Group’s requirements for this document have changed since the previous step,
• 他の部会との依存関係に変更があれば報告すべきです.
  should report any changes in dependencies with other groups,

可能性のある草案の次の段階は, 次のとおりです.

Possible next steps for any Working Draft:

• 改訂された草案
  Revised Working Draft
• 勧告候補
  Candidate Recommendation
• 作業部会のメモ
  Working Group Note

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:

• 仕様書が作業部会の要件全てを処理していることを示すか, その要件が変更されているか延期されていることを説明しなければなりません.
  must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,
• 仕様書の開発の間に起こった依存関係への変更を文書化しなければなりません.
  must document changes to dependencies during the development of the specification,
• どのように十分な実装の実績を証明するか文書化しなければなりません.
  must document how adequate implementation experience will be demonstrated,
• 意見の締切を指定しなければなりません. 締切は, 少なくとも発行後28日間空けなければならず, 複雑な文書ではもっと長く空けるべきです.
  must specify the deadline for comments, which must be at least 28 days after publication, and should be longer for complex documents,
• 仕様書が広範囲にわたる審査を受けたことを示さなければなりません.
  must show that the specification has received wide review, and
• 文書の中で潜在的な問題をはらんでいる機能を特定してもよいです. それらの機能は, 勧告案に進展する際に, 新しい勧告候補を発行する必要無しに削除されてもよいです.
  may identify features in the document as at risk. These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

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

• 草案への差戻し
  Return to Working Draft
• 改訂された勧告候補全体版
  A revised Candidate Recommendation Snapshot
• 改訂された勧告候補草案版
  A revised Candidate Recommendation Draft
• 勧告案
  Proposed Recommendation
• 作業部会のメモ
  Working Group Note

諮問委員会の委員は, 技術報告書の進展の決定に対し, 諮問委員会の抗議を提出してもよいです.

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

6.2.8. 勧告候補の改訂
Revising a Candidate Recommendation

6.2.8.1. 勧告候補全体版の発行
Publishing a Candidate Recommendation Snapshot

以前の勧告候補全体版から, 潜在的な問題をはらんでいるとはっきり示された機能を削除する以外の, 勧告候補への何か実質的な変更があった場合, 作業部会は, 再発行するために更新要求の要件を満たさなければなりません.

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

加えて, 作業部会は次のとおりです.

In addition the Working Group:

• 意見の締切を指定なければなりません. 締切は, 少なくとも発行後28日間空けなければならず, 複雑な文書ではもっと長く空けるべきです.
  must specify the deadline for further comments, which must be at least 28 days after publication, and should be longer for complex documents,
• 文書の中で潜在的な問題をはらんでいる機能を特定してもよいです. それらの機能は, 勧告案に進展する際に, 新しい勧告候補を発行する必要無しに削除されてもよいです.
  may identify features in the document as at risk. These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

ディレクターは, 改訂された勧告候補全体版の発行を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].

6.2.8.2. 勧告候補草案版の発行
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:

• 発行を要求した部会決定を記録しなければなりません.
  must record the group’s decision to request publication,
• 以前の勧告候補全体版以降の技術報告書に対する実質的な変更の公開の文書を提供しなければなりません.
  must provide public documentation of substantive changes to the technical report since the previous Candidate Recommendation Snapshot,
• 以前の勧告候補全体版以降の技術報告書に対する重大な編集上の変更の公開の文書を提供すべきです.
  should provide public documentation of significant editorial changes to the technical report since the previous Candidate Recommendation Snapshot,
• 目立った課題や, 作業部会で合意を得られていない文書の部分を明文化すべきです.
  should document outstanding issues, and parts of the document on which the Working Group does not have consensus,
• もし前回の段階以降に, その文書に対する作業部会の要求するもので変わったものがあるのならば, その内容を報告すべきです.
  should report which, if any, of the Working Group’s requirements for this document have changed since the previous step,
• 他の部会との依存関係に変更があれば報告すべきです.
  should report any changes in dependencies with other groups.

注意:作業部会は, 勧告候補草案版を発行するために, 勧告候補全体版の更新要求の要件を満たす必要はありません.

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

可能性のある勧告候補会草案版の次の段階は, 次のとおりです.

Possible next steps after a Candidate Recommendation Draft:

• 草案への差戻し
  Return to Working Draft
• 改訂された勧告候補全体版
  A revised Candidate Recommendation Snapshot
• 改訂された勧告候補草案版
  A revised Candidate Recommendation Draft
• 潜在的な問題をはらんでいる機能を落とすこと以外の実質的な変更が何も無いのであれば, 勧告案
  Proposed Recommendation, if there are no substantive change other than dropping at risk features
• 作業部会のメモ
  Working Group Note

6.2.9. 勧告案への遷移
Transitioning to Proposed Recommendation

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

In addition to meeting the requirements for advancement,

• 状態の情報は, 諮問委員会の審査の締切を指定しなければなりません. 締切は, 勧告案の発行後少なくとも28日間空けなければならず, W3C特許指針[特許指針]の”W3C RFライセンス要件からの除外”を通して, 最後の除外機会の終了から少なくとも10日間空けるべきです.
  The status information must specify the deadline for Advisory Committee review, which must be at least 28 days after the publication of the Proposed Recommendation and should be at least 10 days after the end of the last Exclusion Opportunity per ”Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY].

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

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

• ディレクターによって認められた例外を除いて, 十分な実装の実績を示さなければなりません.
  must show adequate implementation experience except where an exception is approved by the Director,
• 文書が広範囲にわたる審査を受けたことを示さなければなりません.
  must show that the document has received wide review,
• 正式な諮問委員会委員の役割を担っているAC委員からのもの以外の, 勧告候補の審査期間に挙げられた全ての課題が, 正式に取り組まれていたことを示さなければなりません.
  must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed,
• 勧告候補の審査期間が終わった後に挙げられた実質的な課題を特定しなければなりません.
  must identify any substantive issues raised since the close of the Candidate Recommendation review period,
• 潜在的な問題をはらんでいるとされた機能を落とす以外の, 最も直近の勧告候補全体版以降の, 文書に対する何か実質的な変更を行ってはなりません.
  must not have made any substantive changes to the document since the most recent Candidate Recommendation Snapshot, other than dropping features identified at risk.
• 仕様書を勧告候補全体版として再発行することなく, 勧告候補全体版の文書の中で潜在的な問題をはらんでいると特定された機能を削除してもよいです.
  may have removed features identified in the Candidate Recommendation Snapshot document as at risk without republishing the specification as a Candidate Recommendation Snapshot.

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

The Director:

• 勧告案の発行を諮問委員会に周知しなければなりません. また, 仕様書がW3C勧告として発行するのにふさわしいかどうかの問いについての諮問委員会の審査を始めなければなりません.
  must announce the publication of a Proposed Recommendation to the Advisory Committee, and must begin an Advisory Committee Review on the question of whether the specification is appropriate to publish as a W3C Recommendation.
• 無理やり承認する理由があるのであれば, 勧告案を最小限の実装の実績で承認してもよいです. そのような場合, ディレクターは, その決定の理由を説明すべきです.
  may approve a Proposed Recommendation with minimal implementation experience where there is a compelling reason to do so. In such a case, the Director should explain the reasons for that decision.

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.

勧告案は, § 6.2.11.4 勧告の改訂:新しい機能で述べられているように, 勧告として最初に発行した後に(種類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 § 6.2.11.4 Revising a Recommendation: New Features. Such an allowance cannot be added to a technical report previously published as a Recommendation that did not allow such changes.

可能性のある次の段階は次のとおりです.

Possible Next Steps:

• 草案への差戻し
  Return to Working Draft
• 勧告候補への差戻し
  Return to Candidate Recommendation
• 修正勧告(期待される次の段階)も含めた勧告の状態
  Recommendation status, including Amended Recommendation (the expected next step).
• 作業部会のメモ
  Working Group Note

諮問委員会の委員は, 技術報告書を進展させる決定に対して, 諮問委員会の抗議を提出してもよいです.

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,

• 勧告は, どこで正誤表が記録されているか特定しなければなりません.
  A Recommendation must identify where errata are tracked, and
• 勧告は元となった勧告案から何か実質的な変更を含んではなりません.
  A Recommendation must not include any substantive changes from the Proposed Recommendation on which it is based.
• 諮問委員会の審査で何らかの不同意があった場合, ディレクターは, 不同意の実質的な内容をW3Cと一般社会に公表しなければならず, W3C勧告の発行の遅くとも14日前までにその意見に正式に取り組まなければなりません.
  If there was any dissent in Advisory Committee reviews, the Director must publish the substantive content of the dissent to W3C and the general public, and must formally address the comment at least 14 days before publication as a W3C Recommendation.
• 諮問委員会の委員は, W3C決定に対して, 諮問委員会の抗議を提出してもよいです.
  Advisory Committee representatives may initiate an Advisory Committee Appeal of the W3C decision
• ディレクターは, W3C勧告の発行を, 諮問委員会, W3Cの他の部会, 一般社会に周知しなければなりません.
  The Director must announce the publication of a W3C Recommendation to Advisory Committee, other W3C groups and to the public.

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

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

• 改訂勧告または修正勧告として再発行される.
  republished as a revised Recommendation or Amended Recommendation, or
• 改訂勧告または修正勧告に向けて開発される勧告候補として再発行される.
  republished as a Candidate Recommendation to be developed towards a revised Recommendation or Amended Recommendation, or
• 置換済または旧式と宣言される.
  declared superseded or obsolete, or
• 廃止される.
  rescinded.

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

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

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

6.2.11.1. 勧告の改訂:マークアップの変更
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.)

6.2.11.2. 勧告の改訂:編集上の変更
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.)

6.2.11.3. 勧告の改訂:実質的な変更
Revising a Recommendation: Substantive Changes

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

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

代わりに, 作業部会は, その変更を組み入れ, 勧告候補を発行してもよく, また, どの作業部会も勧告を維持することを憲章に書いていない場合は, 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.)

6.2.11.4. 勧告の改訂:新しい機能
Revising a Recommendation: New Features

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

New features (see class 4 changes) may be incorporated into a Recommendation explicitly identified as allowing new features using candidate additions. A candidate addition can be made normative and be folded into the main text of the Recommendation, once it has satisfied all the same criteria as the rest of the Recommendation, including review by the community to ensure the technical and editorial soundness of the candidate change. To validate this, the Working Group must request a Last Call for Review of Proposed Changes, followed by an update request. See § 6.2.11.5 Incorporating Candidate Changes.

注意:この新しい機能の禁止は, はっきり認められていない限り, この手続き文書の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.

6.2.11.5. 変更候補の組み入れ
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:

• 訂正案審査の最終要請, 追加案審査の最終要請, 訂正案審査および追加案審査の最終要請のいずれであるか特定しなければなりません.
  Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, or Last Call for Review of Proposed Corrections and Additions.
• 変更案(訂正案/追加案)としての審査の下で, 変更候補を特定しなければなりません.
  Identify the specific candidate changes under review as proposed changes (proposed corrections/proposed addition).
• 審査意見の締切を指定しなければなりません. 締切は, 審査の要請から60日以上空けなければなりません.
  Specify the deadline for review comments, which must not be any sooner than 60 days from the Call for Review.
• 審査と, まだなのであれば実装の実績を要求しなければなりません.
  Solicit review and, if it does not already have it, implementation experience.

既存の勧告と変更案審査の最終要請に含まれた変更案を組合せたものは, 特許指針[特許指針]の意図する特許審査草案と見なされます. また, 追加案審査の最終要請によって発議された審査は, 諮問委員会の審査です.

The combination of the existing Recommendation with the proposed 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.

6.2.12.1. 未完成の技術報告書の断念
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.

6.2.12.2. 勧告候補の廃止
Rescinding a Candidate Recommendation

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

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

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

6.2.12.4. 勧告の廃止, 旧式化, 置換, 復活の手続き
Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation

勧告を廃止したり, 旧式としたり, 置換済にしたり, 復活させたりする手続きは, ディレクターからの要求によってか, または次のいずれかからの要求を通して発議されます.

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

• 勧告を生み出したか, 維持すると憲章に書いている作業部会
  The Working Group who produced, or is chartered to maintain, the Recommendation
• そのような作業部会が無い場合, TAG
  The TAG, if there is no such Working Group
• 上で述べた関連する作業部会に, またはそのような作業部会が存在しな場合はTAGに, 勧告を旧式としたり, 廃止したり, 置換済にしたり, 復活させたりする要求を行った, 90日以内に回答を得られなかった個人
  Any individual who made a request to the relevant Working Group as described above, or the TAG if such a group does not exist, to obsolete, rescind, supersede, or restore a Recommendation, where the request was not answered within 90 days
• 諮問委員会のメンバーの5%
  5% of the members of the Advisory Committee

その後, ディレクターは, 諮問委員会に審査の要求を提出しなければなりません. 勧告を廃止したり, 旧式としたり, 置換済にしたり, 復活させたりする提案への何らかの諮問委員会の審査に対して, ディレクターは, 次のとおりしなければなりません.

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:

• 提案を全ての作業部会の議長, 一般社会, 諮問委員会に周知しなければなりません.
  announce the proposal to all Working Group Chairs, and to the Public, as well as to the Advisory Committee
• 提案が, 勧告を廃止したり, 旧式としたり, 置換済にしたり, 復活させたりするものであることを適切に示さなければなりません.
  indicate that this is a proposal to Rescind, Obsolete, Supersede, or restore, a Recommendation as appropriate
• URLによって勧告を特定しなければなりません.
  identify the Recommendation by URL
• 提案の根拠を公開しなければなりません.
  publish a rationale for the proposal
• 分かっている依存関係を特定し, 全ての依存している作業部会に審査を要求しなければなりません.
  identify known dependencies and solicit review from all dependent Working Groups
• 一般社会の審査を要求しなければなりません.
  solicit public review
• 審査意見の締切を指定しなければなりません. 締切は, ディレクターの周知から少なくとも28日後でなければなりません.
  specify the deadline for review comments, which must be at least 28 days after the Director's announcement

また, 次のとおりすべきです.

and should

• 分かっている実装を特定すべきです.
  identify known implementations.

諮問委員会の審査において何らかの不同意があった場合, ディレクターは, 不同意の実質的な意見を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:

• 設計原理または利用事例と要件の説明といった, 仕様書を支援する文書.
  supporting documentation for a specification, such as explanations of design principles or use cases and requirements,
• 良い慣行についての標準でない手引き.
  non-normative guides to good practices,
• 作業が止められ, もはや新しい標準にする合意がない仕様書.
  specifications where work has been stopped and there is no longer consensus for making them a new standard.

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:

• 草案として以前に発行されたものと一緒でも別々にでもメモを発行してもよいです.
  may publish a Note with or without its prior publication as a Working Draft.
• メモとして発行を要求した部会決定を記録しなければなりません.
  must record the group’s decision to request publication as a Note, and
• 何らかの以前の発行以降の技術報告書への重大な変更を文書化したものを公表すべきです.
  should publish documentation of significant changes to the technical report since any previous publication.

可能性のある次の段階は, 次のとおりです.

Possible next steps:

• 終了した状態: 技術報告書は, 作業部会または関連部会のメモとして無期限に残ってもよいです.
  End state: A technical report may remain a Working or Interest Group Note indefinitely
• 作業部会は, いつでも憲章の範囲内で技術報告書の作業を, メモとして発行される前に仕様書が持っていた成熟レベルで再開してもよいです.
  A Working Group may resume work on a technical report within the scope of its charter at any time, at the maturity level the specification had before publication as a Note

注意: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:

• 新しいまたは修正された作業部会と関連部会
  new and modified Working and Interest Groups,
• 勧告案, 勧告の旧式化, 廃止, 置換, 復活の提案
  Proposed Recommendations, Proposals to Obsolete, Rescind, Supersede, or Restore Recommendations, and
• W3C手続き文書の変更案
  Proposed changes to the W3C process.

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

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:

• W3C手続きの外部で開発された1つ以上の文書.
  One or more documents developed outside of the W3C process, and
• 提案者から提供された, 文書についての情報.
  Information about the documents, provided by the Submitter.

(提案者と呼ばれる)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.
   • 承認された場合, 事務局は, 会員提案についての事務局の意見を加えて, 会員提案を公開されているW3Cのウェブサイトで利用できるようにしなければなりません.
     If acknowledged, the Team must make the Member Submission available at the public W3C Web site, in addition to Team comments about the Member Submission.
   • 却下された場合, 提案者は, 提案の抗議を, TAGまたは諮問会議のどちらかに提出してもよいです.
     If rejected, the Submitter(s) may initiate a Submission Appeal to either the TAG or the Advisory Board.

会員提案を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 list of all submitting Members.
• (提案者によって集められた)提案した全ての会員からの意見表明報告書. 意見表明報告書は, 分割された文書全てに現れなければなりません.
  Position statements from all submitting Members (gathered by the Submitter). All position statements must appear in a separate document.
• 考察のために提案された文書の完全な電子的コピー(例えば, 技術仕様書, 方針説明書など). 提案要求が承認された場合, それらの文書は, W3Cによって利用可能な状態にされ, その結果, 事務局の発行の決まり [発行の決まり]を満たさなければなりません. 提案者は, それらの文書に含まれている内容に対する著作権を保持してもよいですが, W3Cによって利用可能な状態にされた場合, それらの文書は, W3C文書ライセンス [文書ライセンス]の規定に従わなければなりません.
  Complete electronic copies of any documents submitted for consideration (e.g., a technical specification, a position paper, etc.) If the Submission request is acknowledged, these documents will be made available by W3C and therefore must satisfy the Team’s Publication Rules [PUBRULES]. Submitters may hold the copyright for the material contained in these documents, but when made available by W3C, these documents must be subject to the provisions of the W3C Document License [DOC-LICENSE].

要求は, 次の質問にも答えなければなりません.

The request must also answer the following questions.

• 何の所有する技術が, 要求が取り組む分野を実装するのに必要か, また, 何の条件がその利用に関連するのか? たくさんの回答が可能ですが, 特定の回答は, 事務局の決定に影響します.
  What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its use? Again, many answers are possible, but the specific answer will affect the Team’s decision.
• W3Cが提案を承認したら, もしあれば, 何の資源を, 提案者は利用可能にするつもりか, また, 何の資源で提案に取り掛かるのか?
  What resources, if any, does the Submitter intend to make available if the W3C acknowledges the Submission request and takes action on it?
• 提案要求が承認されたら, 何の活動を提案者はW3Cに行ってほしいか?
  What action would the Submitter like W3C to take if the Submission request is acknowledged?
• 何の仕組みが, 提案された仕様書に変更を行うためにあるのか? このことは, 要求が承認された場合, 変更の制御がどこに備わっているかを述べることを, それに限らず含みます.
  What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating where change control will reside if the request is acknowledged.

提案要求に関係する他の運営上の要件については, “どのように提案要求を送るか” [会員提案]を参照して下さい.

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

10.2. 事務局の権利と義務
Team Rights and Obligations

会員提案の文書は, 技術報告書ではないにも関わらず, 事務局の発行の決まり [発行の決まり]を含め, 事務局によって制定された要件を満たさなければなりません.

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

事務局が提案要求を審査し, 一旦, 完全で正確であると判断したならば, 事務局は, 提案者に有効かどうかの通知を送ります.

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

要求を承認するか却下するか決める前は, 要求は事務局限定で, 事務局は, 要求を最も厳格な機密レベルにして置かなければなりません. 特に, 事務局は, 提案要求について報道機関に述べてはなりません.

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

10.3. 提案要求の承認
Acknowledgment of a Submission Request

ディレクターは, 諮問委員会に通知を送ることによって, 提案要求を承認します. 通知は, いつでも行ってよいですが, 提案者は, 有効かどうかの通知の後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:

• 会員提案をW3Cのウェブサイトで利用できるようにしなければなりません.
  Make the Member Submission available at the W3C website.
• 会員提案についての事務局の意見をW3Cのウェブサイトで利用できるようにしなければなりません.
  Make the Team comments about the Submission request available at the W3C website.

提案者が, 承認の結果として利用可能な状態になった文書を修正しようとする場合, 提案者は, 単に編集上の変更を修正するだけであったとしても, 最初から提案手続きを始めなければなりません.

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

10.4. 提案要求の却下, 提案の抗議
Rejection of a Submission Request, and Submission Appeals

ディレクターは, 次のいずれかを含む様々な理由で, 提案要求を却下してもよいです.

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

• 要求で表現されている着想が, 憲章のある作業部会の作業と範囲が被っており, また, 承認が部会の進展を危険にさらすかもしれない場合.
  The ideas expressed in the request overlap in scope with the work of a chartered Working Group, and acknowledgment might jeopardize the progress of the group.
• 提案者によって作られたIPRの声明が, W3C特許指針[特許指針], 特に“W3C提案のライセンス義務”, 文書ライセンス [文書ライセンス], 他のIPR指針と矛盾する場合.
  The IPR statement made by the Submitter(s) is inconsistent with the W3C’s Patent Policy [PATENT-POLICY] and in particular the “Licensing Commitments in W3C Submissions”, Document License [DOC-LICENSE], or other IPR policies.
• 要求で表現されている着想が, 粗末か, ウェブに損害を与えるか, W3Cの活動理念 [理念]と逆方向に進んでいるかする場合.
  The ideas expressed in the request are poor, might harm the Web, or run counter to W3C’s mission [MISSION].
• 要求で表現されている着想が, W3Cの活動理念の大分外側に位置する場合.
  The ideas expressed in the request lie well outside the scope of W3C’s mission.

却下された場合, 事務局は, 提案者の諮問委員会の委員に通知しなければなりません. 提案者から要求された場合, 事務局は, 提案者に却下についての根拠を提供しなければなりません. 提案者以外には, 事務局は, なぜ提案要求が却下されたのかについて意見を述べてはなりません.

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

提案者の諮問委員会の委員は, 事務局の決定に対する提案の抗議を, 理由がウェブ技術体系に関係するものなら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 Board—acting as the sponsoring Working Group. The documents may be developed by the AB or by another group to whom the AB has delegated development. Review includes soliciting input from the W3C community, and in particular the Team.

この節で対象とされる文書は, 次のとおりです.

The documents covered by this section are:

• W3C手続き文書(この文書)

  the W3C Process (this document)

• W3C特許指針[特許指針]

  the W3C Patent Policy [PATENT-POLICY]

• W3C倫理規定および職業行為規定[CEPC]

  the W3C Code of Ethics and Professional Conduct [CEPC]

諮問会議は, 次のとおり審査を発議します.

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. 謝辞
Acknowledgments

この節は標準ではありません.

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

この節は標準ではありません.

This section is non-normative.

2019年3月1日版の手続き文書からの変更点
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.

• CRを更新する進展中の作業は, 勧告候補草案版としてTRで発行されるようになりました. このことは, 非公式の編集者草案を読者に向けて発行する必要無しに, 作業部会が作業の最新の状態を発行したり, 公式の写しで広範囲にわたる審査を受けたりすることを認めます.
  Work-in-progress updates to CRs can be published on TR as Candidate Recommendation Drafts. This allows the Working Group to publish the latest state of their work and to get wide review on the official copy, without having to direct readers to an unofficial Editor’s Draft.
• 特許指針の同時の更新が計画され, 手続き文書は, その指針と結び付くように調整されました. 同時に, それらは, 今まで, 勧告を待つ必要があったのに対して, CR段階からの特許の保護を提供します.
  An simultaneous update of the Patent Policy is planned and the Process has been adjusted to tie into it. Together, they provide patent protection from the CR stage, as opposed to having to wait for the Recommendation as needed today.
• 正誤表や関係する変更が, 勧告の行の中に有益に付け加えられるようになり, W3Cの承認無しに再発行されるようになりました. このことは, 非公式の編集者草案を読者に向けて発行したり, 正誤表の文書を分けたりする必要無しに, 作業部会が作業の最新の状態を発行したり, 公式の写しで広範囲にわたる審査を受けたりすることを認めます.
  Errata and related changes can be informatively annotated inline in a Recommendation, and republished without W3C approval. This too allows the Working Group to publish the latest state of their work and to get wide review on the official copy, without having to direct readers to an unofficial Editor’s Draft, or separate errata documents.
• これら変更候補の中に, 勧告の一部となるのに十分な成熟レベルに1度達したものがあるか, 通常の承認(ディレクターの審査, ACの審査)を1度確保したものがあるなら, 作業部会は, それらを標準の文章とし勧告に混ぜ込み, CRまたはPRとしての中間の発行無しに, 直接勧告として再発行できるようになりました.
  Once some of these candidate changes have reached sufficient maturity to be part of the Recommendation, and once it has secured the usual approvals (Director review, AC Review), the Working Group can fold them into the Recommendation as normative text, republish the Recommendation directly, without intermediate publication as CR or PR.
• 何かが再発行される前に全てを修正する必要無しに, 複雑な仕様書が段々と改良されることを認めることで, 勧告への新しい変更候補の追加と, 成熟した変更案の標準的な編入の両方を少しずつ実施できるようになりました.
  Both the addition of new candidate changes and the normative incorporation of mature proposed changes into the Recommendation can be done incrementally, allowing complex specifications to be gradually improved without having to fix everything before anything can be republished.
• エラーを訂正する訂正候補と同じように, 勧告への追加候補が行の中に付け加えられ, 十分に成熟レベルがある場合に標準となるようになりました. このことは, 新しい機能を認めるという注意書き無しに既に発行されている勧告の一連の機能の安定性への期待を破ることを避けるため, 自身を新しい機能を認めるものと特定している勧告に限られます.
  Similarly to candidate corrections which correct errors, candidate additions to a Recommendation can be annotated inline, then made normative when sufficiently mature. This is limited to Recommendations explicitly identifying themselves as allowing new features, so as to avoid breaking expectation of feature-set stability on Recommendations that have already been published without this note.
• 確かな客観的な基準で処理されるとき, CRからRECへの遷移と, RECからRECへの更新の両方を, 自動的に承認し, 通常の“遷移の要請”を飛ばすことができるようになりました. これらの工程における更なる開発は, 後でこの“最速の工程”における摩擦を減らすかもしれません.
  When certain objective criteria are met, both the CR-to-REC transition and the REC-to-REC update can be automatically approved and skip the usual “transition call”. Further developments in tooling may later reduce friction on this “fast-path”.

重要でない単純化として, 次のようなことも行われました.

Some minor simplifications have also been made:

• 勧告と編集勧告の間の区別を止めました.
  Drop the distinction between Recommendation and Edited Recommendation.
• CRより前からの編集上の変更を文書化する必要を無くしました.
  Don’t require documenting editorial changes since the previous CR.

これらの変更前後の状態を比較した差分が利用できます.

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.

• (“会員提案”ではない)“事務局提案”の仕組みの廃止. この仕組みが, 利用されず, 今までに持っている能力を事務局に提供しておらず, 事務局の意思疎通に意義のある管理を提供していないことから廃止しました.
  Retire the “Team Submissions” (not “Member Submissions”) mechanism, as it is unused, does not provide the Team with abilities it doesn’t already have, nor provides meaningful governance of the Team’s communications.
• CEPCと特許指針を改訂する手続きを, 手続き文書を改訂する際のものと同じと定義.
  Define that the process to revise the CEPC and Patent Policy are the same as for revising the Process
• 特別な用語“発行”を, 文書をTRに置く以外の何かを意味して利用することの回避.
  Avoid using the specialized term “publish” to mean anything other than putting documents on TR.
• 特別な用語“不同意”を, 公式な異議に関係しない状況で利用することの回避.
  Avoid using the specialized term “dissent” in situations that do not involve Formal Objections.
• § 2.5.1 諮問会議と技術諮問委員会の委員の制限と§ 7.1.2 審査期間の終了後の中の表現の明確化と不要な文章の除去.
  Phrasing clarifications and removal of unnecessary text in § 2.5.1 Advisory Board and Technical Architecture Group Participation Constraints and § 7.1.2 After the Review Period.
• 抗議の声明が会員限定として処理されることの明確化.
  Clarify that appeal statements are meant to be member-only.
• 草案が持っている立ち位置を, それに限らず明確化.
  Clarify that Working Drafts have some, even if limited, standing.
• 憲章が公式な投票手続きを含む"べき"なのか含ん"でよい"なのか, 重大でない言葉の衝突の解決.
  Resolve minor wording conflict as to whether charters "should" or "may" include formal voting procedures.
• 以前のTAG参加の節で行っていた, 特許指針の存在しない部分への参照の削除.
  Delete references to non existing parts of the Patent policy, previously invoked in the TAG participation section.
• TAGまたはABへの任命の参加者に含まれていた, ACの委員のように見える間違ったリンクの除去.
  Remove a spurious link that made it look like AC-Reps were involved when participants in the TAG or AB resign.
• 可読性や節相互のリンクを改良するために, 小節の見出しをいくつか追加.
  Add some sub-section headings to improve readability and cross-section linking
• § 2.5.2 諮問会議と技術諮問委員会の選挙の空席の決まりの明確化.
  Clarify the rule on vacant seats in § 2.5.2 Advisory Board and Technical Architecture Group Elections
• 定義されていない“重要でない変更”という用語の利用の廃止.
  Eliminate the use of the undefined “minor changes” term
• 部会決定と議長決定の定義, それらの区別.
  Define and differentiate between Group Decisions and Chair Decisions.
• 置換する手続きを利用するのが適当な場合とそうでない場合を明確化する注意書きの追加.
  Add note clarifying when it is appropriate to use the superseding process, and when not.
• 合意の柔軟性についての注意書きの追加.
  Add Note about the flexibility of Consensus.

注目すべき編集上の変更点
Notable Editorial Changes

• 管理の容易さを改良し, より良い相互リンクの能力と, 同様に手続き文書の索引を得られるよう, 手続き文書のソースコードをBikeshed文書書式に変換しました. このことは, 手続き文書の文章に変更を行わす, ソースコードの大きな変更で, また, 前後の状態を比較する手助けになりそうにもないことに注意して下さい.
  Converted the source code of the process to the Bikeshed document format, improving the ease of maintenance, and gaining better cross linking capabilities as well as an Index in the process. Note that while this makes no change to the text of the process, it is a large change of the source code, and source level diffs are unlikely to be of help to compare the before and after state.

  この変更前後の状態を比較した差分が利用できます.

  A diff comparing the state before/after this change is available.

• 発行したり, 1つの成熟レベルから他のレベルへ遷移したりするのに必要な段階に混乱が生じていたことから, 節§ 6 W3C技術報告書開発手続きは, 成熟レベルの定義を整理するために再編成されました.
  Section § 6 W3C Technical Report Development Process has been reorganized, to disentangle definitions of the various maturities from the steps needed to publish and to transition form one maturity to another.

  この変更前後の状態を比較した差分が利用できます. この再編成は, 前で述べた勧告工程の重大な変更の前に行われたことに注意して下さい.

  A diff comparing the state before/after this change is available. Note that this reorganization was done prior to the major changes to the Recommendation track mentioned earlier.

最終調整
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:

• ディレクターが実質的に決定する権限を持ち, 全ての関係者からの意見を報告に盛り込むことを明確にするための, W3C決定の定義の明確化.
  Clarify the definition of W3C Decision, to make it clear that the Director actually has decision power, and does take the input of the whole community into account.
• 責任を明確にするための, 節§ 11 手続き文書の発展の言葉の調整.
  Adjust the wording of section § 11 Process Evolution to clarify responsibilities.
• 特許指針の対象とする草案として取り扱われるための発行された変更候補の定義.
  Define the published candidate changes to be treated as Working Drafts for the purpose of the Patent Policy.
• CRの段階中にACが提供すると期待された意見の種類についての, REC工程における前置きの文章からの声明の除去.
  Remove statement from introductory text on the REC track about the kind of feedback the AC is expected to provide during the CR phase.
• "変更案"の"変更候補"への名称変更. また, "変更案"という用語は, ACの審査の下で変更部分を参照するのに使用します.
  Rename "proposed changes" to "candidate changes", and use the term "proposed changes" to refer to the subset which is under AC review.
• 簡単な参照のための節の題名の調整.
  Adjust a section title for easier referencing.
• 要件の一覧の文法の調整. このことによって, 全ての項目が同じ主語を持つようになります.
  Adjust grammar in a list of requirements so that all entries have the same subject.
• 勧告候補概要版を参照する同一の用語の使用.
  Use consistent terminology to refer to Candidate Recommednation Snapshotsa.
• 植字の修正と, より適当な語彙("古い"より "前の")の使用
  Fix a typo and use more appropriate vocabulary ("previous" rather than "old")

これらの変更前後の状態を比較した差分が利用できます.

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.