161009-050901-diff.html
author charles
Fri, 16 Dec 2016 17:11:17 +0100
changeset 215 2ddb5be7fe6e
parent 195 f5c7bf573dc2
permissions -rw-r--r--
Update status for new editor's draft.
<!DOCTYPE html>
<html lang="en">
<head><script>var js = document.createElement('script');js.id = 'OPTSmartBannerScript';js.src = 'https://securenet.vodafone.es/js/icon_es.js?preview=0&policystate=2&modality=family&client=XYL2zxlLRoQ9tb0c%2FdsUFc%2FM%2F2NnKDnDQ%2BFOJHE1sDgoNSoXYPHO9SXrqiqqGSAc&view=default';var first = document.getElementsByTagName('script')[0];first.parentNode.insertBefore(js, first);</script>
<meta charset="utf-8">
<meta name="keywords" content="W3C Process, Consortium, Team, Recommendation, Advisory Committee, Advisory Board, Working Group, Coordination Group, Interest Group, W3C Activity, Workshop, charter, Working Draft, Process Document, Candidate Recommendation, Director, Proposed Recommendation, Submission request">
<link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/base.css">
<title>World Wide Web Consortium Process Document</title>

<style type="text/css">
     .about { margin-left: 3em; margin-right: 3em; font-size: .83em}
     table { margin-left: auto; margin-right: auto }
     .diagram { text-align: center; margin: 2.5em 0 }
      .issue:before {content: "Issue: "}
      .issue {border: 2px dashed red; background-color: #ffa;}
      .issue .issue {background-color: #fcc;}
      .rfc2119 {font-variant:small-caps}

/*for the SVG - navigation highlighting */

     :focus path, :focus polygon, :focus ellipse { stroke-width: 4}
     g g:hover path, g g:hover polygon, g g:hover ellipse { stroke-width: 4}
     :focus text, g g:hover text { stroke: black; stroke-width: .5}

</style>
<!--[if lt IE 9]><script src='undefined://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
<title>Flowchart: The basic W3C Recommendation Track</title>
<title id="Rectrac-fpwd-label">First Public Working Draft - Exclusion Opportunity</title>
<title id="Rectrac-nodewd-label">Working Draft</title>
<title id="Rectrac-repeatwd-label">Publish a New Working Draft</title>
<title id="Rectrac-tocr-label">Advance to Candidate Recommendation</title>
<title id="Rectrac-nodecr-label">Candidate recommendation - Patent Policy Exclusion Opportunity</title>
<title id="Rectrac-repeatcr-label">Publish a revised CR</title>
<title id="Rectrac-topr-label">Advance to Proposed Recommendation</title>
<title id="Rectrac-backtowd-label">Return to Working Draft</title>
<title id="Rectrac-nodepr-label">Proposed Recommendation - Advisory Committee Review</title>
<title id="Rectrac-torec-label">Advance to Recommendation</title>
<title id="Rectrac-backtocr-label">Return to Working Draft</title>
<title id="Rectrac-prbacktowd-label">Return to Working Draft</title>
<title id="Rectrac-noderec-label">W3C Recommendation</title>
<title>Flowchart: Revising a W3C Recommendation</title>
<title id="modif-fpwd-label">First Public Working Draft - Exclusion Opportunity</title>
<title id="modif-nodewd-label">Working Draft</title>
<title id="modif-repeatwd-label">Publish a New Working Draft</title>
<title id="modif-tocr-label">Advance to Candidate Recommendation</title>
<title id="modif-nodecr-label">Candidate recommendation - Patent Policy Exclusion Opportunity</title>
<title id="modif-repeatcr-label">Publish a revised CR</title>
<title id="modif-topr-label">Advance to Proposed Recommendation</title>
<title id="modif-backtowd-label">Return to Working Draft</title>
<title id="modif-nodepr-label">Proposed Recommendation - Advisory Committee Review</title>
<title id="modif-torec-label">Advance to Recommendation</title>
<title id="modif-backtocr-label">Return to Working Draft</title>
<title id="modif-prbacktowd-label">Return to Working Draft</title>
<title id="modif-noderec-label">W3C Recommendation</title>
<title id="Modif-changeproposal-tit">Proposed change to a Recommendation</title>
<title id="modif-overall-title">Initial maturity levels for a modification</title>
<title id="modif-editedrec-title">No text changes: Edited Recommendation</title>
<title id="modif-rectocr-title">No substantive changes: Proposed Edited Recommendation</title>
<title id="modif-nonewfeatures-label">No new features - return to Candidate Recommendation</title>
<style type='text/css'>
.diff-old-a {
  font-size: smaller;
  color: red;
}

.diff-new { background-color: yellow; }
.diff-chg { background-color: lime; }
.diff-new:before,
.diff-new:after
    { content: "\2191" }
.diff-chg:before, .diff-chg:after
    { content: "\2195" }
.diff-old { text-decoration: line-through; background-color: #FBB; }
.diff-old:before,
.diff-old:after
    { content: "\2193" }
:focus { border: thin red solid}
</style>
</head>
<body>
<div class="head">
<a href="https://www.w3.org/">
<img alt="W3C" src="https://www.w3.org/Icons/w3c_home" height="48" width="72">
</a>
<h1>
<del class="diff-old">World
Wide
Web
Consortium
</del>
<ins class="diff-chg">W3C
Editor's
Draft
</ins>
Process
Document
</h1>
<h2 class="notoc">
<del class="diff-old">1
September
2015
</del>
<ins class="diff-chg">9
October
2016
Editor's
Draft
</ins>
</h2>
<dl>
<dt>
<del class="diff-old">This
version
-
permanent
URI:
http://www.w3.org/2015/Process-20150901/
</del>
Latest
Editor's
version:
</dt>
<dd>
<a href="https://dvcs.w3.org/hg/AB/raw-file/default/cover.html">
https://dvcs.w3.org/hg/AB/raw-file/default/cover.html
</a>
</dd>
<dt>
Latest
operative
version:
</dt>
<dd>
<del class="diff-old">http://www.w3.org/Consortium/Process/
Previous
operative
version:
1
August
2014
Process
</del>
<a href="https://www.w3.org/Consortium/Process/">
<ins class="diff-chg">https://www.w3.org/Consortium/Process/
</ins>
</a>
</dd>
<dt>
Editor:
</dt>
<dd>
Charles
McCathie
Nevile,
<a style="color:black" href="http://yandex.com">
<span style="color: red;">
Y
</span>
andex
</a>

<a style="color:black" href="http://yandex.ru">
<span style="color: red;">
Я
</span>
ндекс
</a>
</dd>
<dt>
Previous
editor:
</dt>
<dd>
Ian
Jacobs,
<a href="https://www.w3.org/">
W3C
</a>
</dd>
</dl>
<p class="copyright">
<a href="https://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
Copyright
</a>
©
<del class="diff-old">1996-2015
</del>
<ins class="diff-chg">1996-2016
</ins>
<a href="/">
<abbr title="World Wide Web Consortium">
W3C
</abbr>
</a>
<sup>
®
</sup>
(
<a href="https://www.csail.mit.edu/">
<abbr title="Massachusetts Institute of Technology">
MIT
</abbr>
</a>,
<a href="http://www.ercim.eu/">
<abbr title="European Research Consortium for Informatics and Mathematics">
ERCIM
</abbr>
</a>,
<a href="http://www.keio.ac.jp/">
Keio
</a>,
<a href="http://ev.buaa.edu.cn/">
Beihang
</a>
),
All
Rights
Reserved.
W3C
<a href="/Consortium/Legal/ipr-notice#Legal_Disclaimer">
liability
</a>,
<a href="/Consortium/Legal/ipr-notice#W3C_Trademarks">
trademark
</a>,
<a rel="Copyright" href="/Consortium/Legal/copyright-documents">
document
use
</a>
and
<a rel="Copyright" href="/Consortium/Legal/copyright-software">
software
licensing
</a>
rules
apply.
Your
interactions
with
this
site
are
in
accordance
with
our
<del class="diff-old">W3C
</del>
<a href="/Consortium/Legal/privacy-statement#Public">
<ins class="diff-chg">public
</ins></a><ins class="diff-chg">
and
</ins><a href= "/Consortium/Legal/privacy-statement#Members"><ins class="diff-chg">
Member
</ins></a>
privacy
<del class="diff-old">statements
.
</del>
<ins class="diff-chg">statements.
</ins>
</p>
<hr>
</div>
<h2 class="notoc">
<a id="abstract">
Abstract
</a>
</h2>
<p>
The
mission
of
the
World
Wide
Web
Consortium
(
<abbr>
W3C
</abbr>
)
is
to
lead
the
World
Wide
Web
to
its
full
potential
by
developing
common
protocols
that
promote
its
evolution
and
ensure
its
interoperability.
The
W3C
Process
Document
describes
the
organizational
structure
of
the
W3C
and
the
processes
related
to
the
responsibilities
and
functions
they
exercise
to
enable
W3C
to
accomplish
its
mission.
This
document
does
not
describe
the
internal
workings
of
the
Team
or
W3C's
public
communication
mechanisms.
</p>
<p>
For
more
information
about
the
W3C
mission
and
the
history
of
W3C,
please
refer
to
<a href="https://www.w3.org/Consortium/">
About
W3C
</a>
[
<a href="#ref-mission">
PUB15
</a>
].
</p>
<h2 class="notoc" id="status">
Status
of
this
Document
</h2>
<p>
<del class="diff-old">This
is
</del>
<ins class="diff-chg">W3C,
including
all
existing
chartered
groups,
follows
</ins>
the
<del class="diff-old">1
September
2015
W3C
</del>
<a href="https://www.w3.org/Consortium/Process/">
<ins class="diff-chg">most
recent
operative
</ins>
Process
<del class="diff-old">Document.
</del>
<ins class="diff-chg">Document
</ins></a><ins class="diff-chg">
announced
to
the
Membership.
</ins></p><p>
This
document
<del class="diff-old">was
</del>
<ins class="diff-chg">is
</ins>
developed
<del class="diff-old">between
</del>
<ins class="diff-chg">by
</ins>
the
<del class="diff-old">W3C
</del>
Advisory
<del class="diff-old">Board
and
</del>
<ins class="diff-chg">Board's
Process
Task
Force
working
within
</ins>
the
<a href="https://www.w3.org/community/w3process/">
Revising
W3C
Process
Community
Group
</a>
<del class="diff-old">and
reviewed
by
</del>
<ins class="diff-chg">(which
anyone
may
join).
This
is
the
9
October
2016
Editor's
draft
for
the
proposed
next
version
of
</ins>
the
W3C
<del class="diff-old">Membership.
</del>
<ins class="diff-chg">Process
Document.
This
document
is
based
on
the
</ins><a href="http://www.w3.org/2015/Process-20150901/"><ins class="diff-chg">
1
September
2015
Process
Document
</ins></a>,<ins class="diff-chg">
which
is
the
currently
operative
W3C
Process.
</ins>
</p>
<p>
<del class="diff-old">W3C,
including
all
existing
chartered
groups,
follows
</del>
<ins class="diff-chg">This
draft
is
proposed
to
</ins>
the
<del class="diff-old">most
recent
</del>
<ins class="diff-chg">W3C
Advisory
Board,
for
approval
to
request
formal
Advisory
Committee
review
on
whether
to
adopt
this
as
the
new
</ins>
operative
Process
<ins class="diff-new">document.
</ins></p><p><ins class="diff-new">
Further
revision
is
expected
to
take
place
in
a
new
version
of
the
Process
as
required.
</ins></p><p><ins class="diff-new">
A
</ins><a href="#changes"><ins class="diff-new">
history
of
changes
</ins></a><ins class="diff-new">
since
the
1
September
2015
Process
</ins>
Document
<ins class="diff-new">is
provided.
A
log
of
</ins><a href="https://dvcs.w3.org/hg/AB/"><ins class="diff-new">
all
changes
in
diff
format
</ins></a><ins class="diff-new">
is
available,
as
is
an
</ins><a href="https://dvcs.w3.org/hg/AB/raw-file/default/161009-050901-diff.html"><ins class="diff-new">
"HTML
diff-marked"
comparison
</ins>
</a>
<del class="diff-old">announced
</del>
to
the
<del class="diff-old">Membership.
</del>
<ins class="diff-chg">1
September
document.
</ins>
</p>
<p>
<ins class="diff-new">Comment
is
invited
on
the
draft.
</ins>
Please
send
comments
<del class="diff-old">about
this
document
</del>
to
<del class="diff-old">the
Revising
W3C
Process
Community
Group
</del>
<a href="mailto:public-w3process@w3.org">
<ins class="diff-chg">public-w3process@w3.org
</ins>
</a>
(
<del class="diff-old">mailing
</del>
<a href="https://lists.w3.org/Archives/Public/public-w3process/">
<ins class="diff-chg">Mailing
</ins>
list
archive
</a>,
publicly
available)
or
to
process-issues@w3.org
(
<a href="https://lists.w3.org/Archives/Member/process-issues">
Member-only
<del class="diff-old">list
</del>
archive
<del class="diff-old">.
The
terms
must
,
must
not
,
should
,
should
not
,
required
,
and
may
are
used
in
accordance
with
RFC
2119
</del>
</a>
<del class="diff-old">[
RFC2119
</del>
<ins class="diff-chg">).
A
</ins><a href="https://www.w3.org/community/w3process/track/"><ins class="diff-chg">
Public
Issue
Tracker
</ins>
</a>
<del class="diff-old">].
The
term
not
required
</del>
is
<del class="diff-old">equivalent
to
the
term
may
as
defined
in
RFC
2119.
Some
terms
have
been
capitalized
in
this
document
(and
in
other
W3C
materials)
to
indicate
that
they
are
entities
with
special
relevance
to
the
W3C
Process.
These
terms
are
defined
herein,
and
readers
should
be
aware
that
the
ordinary
(English)
definitions
are
incomplete
for
purposes
of
understanding
this
document.
</del>
<ins class="diff-chg">available
online.
</ins>
</p>
<h2 class="notoc" id="pp">
Relation
of
Process
Document
to
Patent
Policy
</h2>
<p>
W3C
Members'
attention
is
called
to
the
fact
that
provisions
of
the
Process
Document
are
binding
on
Members
per
the
<a href="https://www.w3.org/Consortium/Agreement/Member-Agreement">
Membership
Agreement
</a>
[
<a href="#ref-member-agreement">
PUB6
</a>
].
The
Patent
Policy
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
]
is
incorporated
by
normative
reference
as
a
part
of
the
Process
Document,
and
is
thus
equally
binding.
</p>
<p>
The
Patent
Policy
places
additional
obligations
on
Members,
Team,
and
other
participants
in
W3C.
The
Process
Document
does
not
restate
those
requirements
but
includes
references
to
them.
The
Process
Document
and
Patent
Policy
have
been
designed
so
that
they
may
evolve
independently.
</p>
<p>
In
the
Process
Document,
the
term
"participant"
refers
to
an
individual,
not
an
organization.
</p>
<h2 class=".notoc">
<ins class="diff-new">Conformance
and
specialized
terms
</ins></h2><p><ins class="diff-new">
The
terms
</ins><em class="rfc2119"><ins class="diff-new">
must
</ins></em>,<em class="rfc2119"><ins class="diff-new">
must
not
</ins></em>,<em class="rfc2119"><ins class="diff-new">
should
</ins></em>,<em class="rfc2119"><ins class="diff-new">
should
not
</ins></em>,<em class="rfc2119"><ins class="diff-new">
required
</ins></em>,<ins class="diff-new">
and
</ins><em class="rfc2119"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
are
used
in
accordance
with
</ins><a href="http://www.ietf.org/rfc/rfc2119.txt"><ins class="diff-new">
RFC
2119
</ins></a><ins class="diff-new">
[
</ins><a href="#ref-RFC2119"><ins class="diff-new">
RFC2119
</ins></a><ins class="diff-new">
].
The
term
</ins><dfn><em class="rfc2119"><ins class="diff-new">
not
required
</ins></em></dfn><ins class="diff-new">
is
equivalent
to
the
term
</ins><em class="rfc2119"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
as
defined
in
[
</ins><a href="#ref-RFC2119"><ins class="diff-new">
RFC2119
</ins></a><ins class="diff-new">
].
</ins></p><p><ins class="diff-new">
Some
terms
have
been
capitalized
in
this
document
(and
in
other
W3C
materials)
to
indicate
that
they
are
entities
with
special
relevance
to
the
W3C
Process.
These
terms
are
defined
herein,
and
readers
should
be
aware
that
the
ordinary
(English)
definitions
are
incomplete
for
purposes
of
understanding
this
document.
</ins></p>
<div class="toc" role="navigation">
<h2 class="notoc" id="toc">
Table
of
Contents
</h2>
<div class="noprint">
<ul class="toc">
<li class="tocline2">
<a href="#Intro" class="tocxref">
1
Introduction
</a>
</li>
<li class="tocline2">
<a href="#Organization" class="tocxref">
2
Members,
Advisory
Committee,
Team,
Advisory
Board,
Technical
Architecture
Group
</a>
</li>
<li class="tocline2">
<a href="#Policies" class="tocxref">
3
General
Policies
for
W3C
Groups
</a>
</li>
<li class="tocline2">
<a href="#dissemination" class="tocxref">
4
Dissemination
Policies
</a>
</li>
<li class="tocline2">
<a href="#GAGeneral" class="tocxref">
5
Working
Groups
and
Interest
Groups
</a>
</li>
<li class="tocline2">
<a href="#Reports" class="tocxref">
6
W3C
Technical
Report
Development
Process
</a>
</li>
<li class="tocline2">
<a href="#ReviewAppeal" class="tocxref">
7
Advisory
Committee
Reviews,
Appeals,
and
Votes
</a>
</li>
<li class="tocline2">
<a href="#GAEvents" class="tocxref">
8
Workshops
and
Symposia
</a>
</li>
<li class="tocline2">
<a href="#Liaisons" class="tocxref">
9
Liaisons
</a>
</li>
<li class="tocline2">
<a href="#Submission" class="tocxref">
10
Member
Submission
Process
</a>
</li>
<li class="tocline2">
<a href="#GAProcess" class="tocxref">
11
Process
Evolution
</a>
</li>
<li class="tocline2">
<a href="#references" class="tocxref">
12
References
</a>
</li>
<li class="tocline2">
<a href="#acks" class="tocxref">
13
Acknowledgments
</a>
</li>
<li class="tocline2">
<a href="#changes" class="tocxref">
14
Changes
</a>
</li>
</ul>
</div>
</div>
<div class="longtoc">
<div class="noprint">
<h3 class="notoc" id="fulltoc">
Expanded
table
of
contents
</h3>
</div>
<ul class="toc">
<li class="tocline2">
<a href="#Intro">
1
Introduction
</a>
</li>
<li class="tocline2">
<a href="#Organization">
2
Members,
Advisory
Committee,
Team,
Advisory
Board,
Technical
Architecture
Group
</a>
<ul class="toc">
<li class="tocline3">
<a href="#Members">
2.1
Members
</a>
<ul class="toc">
<li class="tocline4">
<a href="#MemberBenefits">
2.1.1
Rights
of
Members
</a>
</li>
<li class="tocline4">
<a href="#RelatedAndConsortiumMembers">
2.1.2
<ins class="diff-new">Member
Consortia,
and
</ins>
Related
Members
</a>
</li>
<li class="tocline4">
<a href="#AC">
2.1.3
Advisory
Committee
(AC)
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#Team">
2.2
The
W3C
Team
</a>
<ul class="toc">
<li class="tocline4">
<a href="#TeamSubmission">
2.2.1
Team
Submissions
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#AB">
2.3
Advisory
Board
(AB)
</a>
<ul class="toc">
<li class="tocline4">
<a href="#ABParticipation">
2.3.1
Advisory
Board
Participation
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#TAG">
2.4
Technical
Architecture
Group
(TAG)
</a>
<ul class="toc">
<li class="tocline4">
<a href="#tag-participation">
2.4.1
Technical
Architecture
Group
Participation
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#AB-TAG-participation">
2.5
Advisory
Board
and
Technical
Architecture
Group
Participation
</a>
<ul class="toc">
<li class="tocline4">
<a href="#AB-TAG-constraints">
2.5.1
Advisory
Board
and
Technical
Architecture
Group
Participation
Constraints
</a>
</li>
<li class="tocline4">
<a href="#AB-TAG-elections">
2.5.2
Advisory
Board
and
Technical
Architecture
Group
Elections
</a>
</li>
<li class="tocline4">
<a href="#AB-TAG-vacated">
2.5.3
Advisory
Board
and
Technical
Architecture
Group
Vacated
Seats
</a>
</li>
</ul>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#Policies">
3
General
Policies
for
W3C
Groups
</a>
<ul class="toc">
<li class="tocline3">
<a href="#ParticipationCriteria">
3.1
Individual
Participation
Criteria
</a>
<ul class="toc">
<li class="tocline4">
<a href="#coi">
3.1.1
Conflict
of
Interest
Policy
</a>
</li>
<li class="tocline4">
<a href="#member-rep">
3.1.2
Individuals
Representing
a
Member
Organization
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#GeneralMeetings">
3.2
Meetings
</a>
</li>
<li class="tocline3">
<a href="#Consensus">
3.3
Consensus
</a>
<ul class="toc">
<li class="tocline4">
<a href="#managing-dissent">
3.3.1
Managing
Dissent
</a>
</li>
<li class="tocline4">
<a href="#WGArchiveMinorityViews">
3.3.2
Recording
and
Reporting
Formal
Objections
</a>
</li>
<li class="tocline4">
<a href="#formal-address">
3.3.3
Formally
Addressing
an
Issue
</a>
</li>
<li class="tocline4">
<a href="#WGChairReopen">
3.3.4
Reopening
a
Decision
When
Presented
With
New
Information
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#Votes">
3.4
Votes
</a>
</li>
<li class="tocline3">
<a href="#WGAppeals">
3.5
Appeal
of
a
Chair's
Decision
</a>
</li>
<li class="tocline3">
<a href="#resignation">
3.6
Resignation
from
a
Group
</a>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#dissemination">
4
Dissemination
Policies
</a>
<ul class="toc">
<li class="tocline3">
<a href="#confidentiality-levels">
4.1
Confidentiality
Levels
</a>
<ul class="toc">
<li class="tocline4">
<a href="#confidentiality-change">
4.1.1
Changing
Confidentiality
Level
</a>
</li>
</ul>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#GAGeneral">
5
Working
Groups
and
Interest
Groups
</a>
<ul class="toc">
<li class="tocline3">
<a href="#ReqsAllGroups">
5.1
Requirements
for
All
Working
and
Interest
Groups
</a>
</li>
<li class="tocline3">
<a href="#GroupsWG">
5.2
Working
Groups
and
Interest
Groups
</a>
<ul class="toc">
<li class="tocline4">
<a href="#group-participation">
5.2.1
Working
Group
and
Interest
Group
Participation
Requirements
</a>
</li>
<li class="tocline4">
<a href="#WGCharterDevelopment">
5.2.2
Working
Group
and
Interest
Group
Charter
Development
</a>
</li>
<li class="tocline4">
<a href="#CharterReview">
5.2.3
Advisory
Committee
Review
of
a
Working
Group
or
Interest
Group
Charter
</a>
</li>
<li class="tocline4">
<a href="#cfp">
5.2.4
Call
for
Participation
in
a
Working
Group
or
Interest
Group
</a>
</li>
<li class="tocline4">
<a href="#charter-extension">
5.2.5
Working
Group
and
Interest
Group
Charter
Extension
</a>
</li>
<li class="tocline4">
<a href="#WGCharter">
5.2.6
Working
Group
and
Interest
Group
Charters
</a>
</li>
<li class="tocline4">
<a href="#GeneralTermination">
<del class="diff-old">5.2.8
</del>
<ins class="diff-chg">5.2.7
</ins>
Working
Group
and
Interest
Group
Closure
</a>
</li>
</ul>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#Reports">
6
W3C
Technical
Report
Development
Process
</a>
<ul class="toc">
<li>
<a href="#rec-advance">
6.1
W3C
Technical
Reports
</a>
<ul class="toc">
<li>
<a href="#recs-and-notes" id="return-to-wg">
6.1.1
Recommendations
and
Notes
</a>
</li>
<li>
<a href="#maturity-levels">
6.1.2
Maturity
Levels
</a>
</li>
</ul>
</li>
<li>
<a href="#requirements-and-definitions">
6.2
General
requirements
and
definitions
</a>
<ul class="toc">
<li>
<a href="#general-requirements">
6.2.1
General
requirements
for
Technical
Reports
</a>
</li>
<li>
<a href="#transition-reqs">
6.2.2
Advancement
on
the
Recommendation
Track
</a>
<ul class="toc">
<li>
<a href="#substantive-change">
6.2.2.1
Substantive
Change
</a>
</li>
</ul>
</li>
<li>
<a href="#doc-reviews">
6.2.3
Reviews
and
Review
Responsibilities
</a>
<ul class="toc">
<li>
<a href="#wide-review">
6.2.3.1
Wide
Review
</a>
</li>
</ul>
</li>
<li>
<a href="#implementation-experience">
6.2.4
Implementation
Experience
</a>
</li>
<li>
<a href="#correction-classes">
6.2.5
Classes
of
Changes
to
a
Recommendation
</a>
</li>
</ul>
</li>
<li>
<a href="#working-draft">
6.3
Working
Draft
</a>
<ul class="toc">
<li>
<a href="#first-wd">
6.3.1
First
Public
Working
Draft
</a>
</li>
<li>
<a href="#revised-wd">
6.3.2
Revising
Public
Working
Drafts
</a>
</li>
<li>
<a href="#tr-end">
6.3.3
Stopping
work
on
a
specification
</a>
</li>
</ul>
</li>
<li>
<a href="#candidate-rec" id="cfi">
6.4
Candidate
Recommendation
</a>
<ul class="toc">
<li>
<a href="#revised-cr">
6.4.1
Revising
a
Candidate
Recommendation
</a>
</li>
</ul>
</li>
<li>
<a href="#rec-pr" id="cfr">
6.5
Proposed
Recommendation
</a>
</li>
<li>
<a href="#rec-publication">
6.6
W3C
Recommendation
</a>
</li>
<li>
<a href="#rec-modify">
6.7
Modifying
a
W3C
Recommendation
</a>
<ul class="toc">
<li>
<a href="#errata">
6.7.1
Errata
Management
</a>
</li>
<li>
<a href="#revised-rec" id="cfr-edited">
6.7.2
Revising
a
Recommendation
</a>
</li>
</ul>
</li>
<li>
<a href="#Note">
6.8
Publishing
a
Working
Group
or
Interest
Group
Note
</a>
</li>
<li>
<a href="#rec-rescind">
6.9
Rescinding
a
W3C
Recommendation
</a>
</li>
<li>
<a href="#further-reading">
Further
reading
</a>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#ReviewAppeal">
7
Advisory
Committee
Reviews,
Appeals,
and
Votes
</a>
<ul class="toc">
<li class="tocline3">
<a href="#ACReview">
7.1
Advisory
Committee
Reviews
</a>
<ul class="toc">
<li class="tocline4">
<a href="#ACReviewStart">
7.1.1
Start
of
a
Review
Period
</a>
</li>
<li class="tocline4">
<a href="#ACReviewAfter">
7.1.2
After
the
Review
Period
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#ACAppeal">
7.2
Appeal
by
Advisory
Committee
Representatives
</a>
</li>
<li class="tocline3">
<a href="#ACVotes">
7.3
Advisory
Committee
Votes
</a>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#GAEvents">
8
Workshops
and
Symposia
</a>
</li>
<li class="tocline2">
<a href="#Liaisons">
9
Liaisons
</a>
</li>
<li class="tocline2">
<a href="#Submission">
10
Member
Submission
Process
</a>
<ul class="toc">
<li class="tocline3">
<a href="#SubmissionRights">
10.1
Submitter
Rights
and
Obligations
</a>
<ul class="toc">
<li class="tocline4">
<a href="#SubmissionScope">
10.1.1
Scope
of
Member
Submissions
</a>
</li>
<li class="tocline4">
<a href="#SubmissionReqs">
10.1.2
Information
Required
in
a
Submission
Request
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#TeamSubmissionRights">
10.2
Team
Rights
and
Obligations
</a>
</li>
<li class="tocline3">
<a href="#SubmissionYes">
10.3
Acknowledgment
of
a
Submission
Request
</a>
</li>
<li class="tocline3">
<a href="#SubmissionNo">
10.4
Rejection
of
a
Submission
Request
</a>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#GAProcess">
11
Process
Evolution
</a>
</li>
<li class="tocline2">
<a href="#references">
12
References
</a>
<ul class="toc">
<li class="tocline3">
<a href="#public-refs">
12.1
Public
Resources
</a>
</li>
<li class="tocline3">
<a href="#member-refs">
12.2
Member-only
Resources
</a>
</li>
<li class="tocline3">
<a href="#other-refs">
12.3
Other
References
</a>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#acks">
13
Acknowledgments
</a>
</li>
<li class="tocline2">
<a href="#changes">
14
Changes
</a>
</li>
</ul>
</div>
<main>
<h2 id="Intro">
1
Introduction
</h2>
<p>
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
<a href="#Consensus">
consensus
</a>
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.
</p>
<p>
Here
is
a
general
overview
of
how
W3C
standardizes
a
Web
technology.
In
many
cases,
the
goal
of
this
work
is
a
<a href="#RecsW3C">
W3C
Recommendation
<del class="diff-old">,
the
W3C
equivalent
of
</del>
</a>
<ins class="diff-chg">-
</ins>
a
Web
standard.
</p>
<ol>
<li>
People
generate
interest
in
a
particular
<del class="diff-old">topic
(e.g.,
Web
services).
</del>
<ins class="diff-chg">topic.
</ins>
For
instance,
Members
express
interest
in
the
form
of
<a href="#Submission">
Member
Submissions
</a>,
and
the
<a href="#Team">
Team
</a>
monitors
work
inside
and
outside
of
W3C
for
signs
of
interest.
Also,
W3C
is
likely
to
organize
a
<a href="#GAEvents">
Workshop
</a>
to
bring
people
together
to
discuss
topics
that
interest
the
W3C
community.
</li>
<li>
When
there
is
enough
interest
in
a
topic
(e.g.,
after
a
successful
Workshop
and/or
discussion
on
an
<a href="#ACCommunication">
Advisory
Committee
mailing
list
</a>
),
the
Director
announces
the
development
of
a
proposal
for
one
or
more
new
<a href="#WGCharterDevelopment">
Interest
Group
or
Working
Group
charters
</a>,
depending
on
the
breadth
of
the
topic
of
interest.
W3C
Members
<a href="#CharterReview">
review
</a>
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.
</li>
<li>
There
are
three
types
of
Working
Group
participants:
<a href="#member-rep">
Member
representatives
</a>,
<a href="#invited-expert-wg">
Invited
Experts
</a>,
and
<a href="#Team">
Team
representatives
</a>.
Team
representatives
both
contribute
to
the
technical
work
and
help
ensure
the
group's
proper
integration
with
the
rest
of
W3C.
The
<a href="#WGCharter">
Working
Group
charter
</a>
sets
expectations
about
each
group's
deliverables
(e.g.,
<a href="#Reports">
technical
reports
</a>,
test
suites,
and
tutorials).
</li>
<li>
Working
Groups
generally
create
specifications
and
guidelines
that
undergo
cycles
of
revision
and
review
as
they
<a href="#rec-advance">
advance
to
W3C
Recommendation
</a>
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
<a href="#RecsW3C">
Recommendation
</a>.
</li>
</ol>
<p>
The
Process
Document
promotes
the
goals
of
quality
and
fairness
in
technical
decisions
by
encouraging
<a href="#Consensus">
consensus
</a>,
requiring
reviews
(by
both
Members
and
public)
as
part
of
the
<a href="#Reports">
technical
report
development
process
</a>,
and
through
an
<a href="#ACAppeal">
<del class="diff-old">appeal
process
for
the
</del>
Advisory
<del class="diff-old">Committee.
</del>
<ins class="diff-chg">Committee
Appeal
process
</ins></a>.
</p>
<p>
The
other
sections
of
the
Process
Document:
</p>
<ol>
<li>
set
forth
<a href="#Policies">
policies
</a>
for
participation
in
W3C
groups,
</li>
<li>
establish
two
permanent
groups
within
W3C:
the
<a href="#TAG">
Technical
Architecture
Group
(TAG)
</a>,
to
help
resolve
Consortium-wide
technical
issues;
and
the
<a href="#AB">
Advisory
Board
(AB)
</a>,
to
help
resolve
Consortium-wide
non-technical
issues,
and
to
manage
the
<a href="#GAProcess">
evolution
of
the
W3C
process
</a>,
and
</li>
<li>
describe
other
interactions
between
the
<a href="#Members">
Members
</a>
(as
represented
by
the
<a href="#AC">
W3C
Advisory
Committee
</a>
),
the
Team,
and
the
general
public.
</li>
</ol>
<h2 id="Organization">
2
Members,
Advisory
Committee,
Team,
Advisory
Board,
Technical
Architecture
Group
</h2>
<p>
W3C's
mission
is
to
lead
the
Web
to
its
full
potential.
W3C
<a href="#Members">
Member
</a>
organizations
provide
resources
to
this
end,
and
the
W3C
<a href="#Team">
Team
</a>
provides
the
technical
leadership
and
organization
to
coordinate
the
effort.
</p>
<h3 id="Members">
2.1
Members
</h3>
<p>
W3C
Members
are
primarily
represented
in
W3C
processes
as
follows:
</p>
<ol>
<li>
The
<a href="#AC">
Advisory
Committee
</a>
is
composed
of
one
representative
from
each
Member
organization
(refer
to
the
<a href="#Member-only">
Member-only
</a>
list
of
<a href="https://www.w3.org/Member/ACList">
current
Advisory
Committee
representatives
</a>
[
<a href="#ref-current-ac">
MEM1
</a>
]).
The
Advisory
Committee:
<ul>
<li>
reviews
plans
for
W3C
at
each
<a href="#ACMeetings">
Advisory
Committee
meeting
</a>
;
</li>
<li>
reviews
formal
proposals
from
the
W3C
Director:
<a href="#CharterReview">
Charter
Proposals
</a>,
<a href="#RecsPR">
Proposed
Recommendations
</a>,
and
<a href="#GAProcess">
Proposed
Process
Documents
</a>.
</li>
<li>
elects
the
<a href="#AB">
Advisory
Board
</a>
participants
other
than
the
Advisory
Board
Chair.
</li>
<li>
elects
5
of
the
9
participants
on
the
<a href="#TAG">
Technical
Architecture
Group
</a>.
</li>
</ul>
Advisory
Committee
representatives
<del class="diff-old">have
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em><ins class="diff-chg">
initiate
an
</ins>
<a href="#ACAppeal">
<del class="diff-old">appeal
</del>
<ins class="diff-chg">Advisory
Committee
Appeal
</ins>
</a>
<del class="diff-old">powers
for
</del>
<ins class="diff-chg">in
</ins>
some
<del class="diff-old">processes
</del>
<ins class="diff-chg">cases
</ins>
described
in
this
document.
</li>
<li>
Representatives
of
Member
organizations
participate
in
<a href="#GAGeneral">
Working
Groups
and
Interest
Groups
</a>
and
author
and
review
<a href="#Reports">
technical
reports
</a>.
</li>
</ol>
<p id="MemberSubscription">
W3C
membership
is
open
to
all
entities,
as
described
in
"
<a href="https://www.w3.org/Consortium/join">
How
to
Join
W3C
</a>
"
[
<a href="#ref-join-w3c">
PUB5
</a>
];
(refer
to
the
public
list
of
<a href="https://www.w3.org/Consortium/Member/List">
current
W3C
Members
</a>
[
<a href="#ref-current-mem">
PUB8
</a>
]).
Organizations
subscribe
according
to
the
<a href="https://www.w3.org/Consortium/Agreement/Member-Agreement">
Membership
Agreement
</a>
[
<a href="#ref-member-agreement">
PUB6
</a>
].
The
<a href="#Team">
Team
</a>
<em class="rfc2119">
must
</em>
ensure
that
Member
participation
agreements
remain
<a href="#Team-only">
Team-only
</a>
and
that
no
Member
receives
preferential
treatment
within
W3C.
</p>
<p id="IndividualParticipation">
W3C
does
not
have
a
class
of
membership
tailored
to,
or
priced
for
individuals.
However,
an
individual
<em class="rfc2119">
may
</em>
join
W3C
as
an
Affiliate
Member.
In
this
case
the
same
restrictions
pertaining
to
<a href="#MemberRelated">
related
Members
</a>
apply
when
the
individual
also
<a href="#member-rep">
represents
</a>
another
W3C
Member.
</p>
<h4 id="MemberBenefits">
2.1.1
Rights
of
Members
</h4>
<p>
Each
Member
organization
enjoys
the
following
rights
and
benefits:
</p>
<ul>
<li>
A
seat
on
the
<a href="#AC">
Advisory
Committee
</a>
;
</li>
<li>
Access
to
<a href="#Member-only">
Member-only
</a>
information;
</li>
<li>
The
<a href="#Submission">
Member
Submission
</a>
process;
</li>
<li>
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
<a href="https://www.w3.org/Member/Intro">
New
Member
Orientation
</a>
[
<a href="#ref-new-member">
MEM4
</a>
].
</li>
</ul>
<p>
Furthermore,
<ins class="diff-new">subject
to
further
restrictions
included
in
the
Member
Agreement,
</ins>
representatives
of
Member
organizations
participate
in
W3C
as
follows:
</p>
<ul>
<li>
In
<a href="#GAGeneral">
Working
Groups
and
Interest
Groups
</a>.
</li>
<li>
In
<a href="#GAEvents">
Workshops
and
Symposia
</a>
;
</li>
<li>
On
the
Team,
as
<a href="#fellows">
W3C
Fellows
</a>.
</li>
</ul>
<p>
<del class="diff-old">In
</del>
<ins class="diff-chg">The
rights
and
benefits
of
W3C
membership
are
contingent
upon
conformance
to
</ins>
the
<del class="diff-old">case
(described
</del>
<ins class="diff-chg">processes
described
</ins>
in
<ins class="diff-new">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
</ins><em class="rfc2119"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
take
disciplinary
action.
Arbitration
in
the
case
of
further
disagreement
is
governed
by
</ins>
paragraph
<del class="diff-old">5g
</del>
<ins class="diff-chg">19
</ins>
of
the
Membership
<del class="diff-old">Agreement
</del>
<ins class="diff-chg">Agreement.
Refer
to
the
</ins><a href="https://www.w3.org/2002/09/discipline"><ins class="diff-chg">
Guidelines
for
Disciplinary
Action
</ins>
</a>
<del class="diff-old">),
where
a
</del>
<ins class="diff-chg">[
</ins><a href="#ref-discipline-gl"><ins class="diff-chg">
MEM14
</ins></a><ins class="diff-chg">
].
</ins></p><h4 id="RelatedAndConsortiumMembers"><ins class="diff-chg">
2.1.2
Membership
Consortia
and
related
Members
</ins></h4><h5 id="MemberConsortia"><ins class="diff-chg">
2.1.2.1
Membership
Consortia
</ins></h5><p><ins class="diff-chg">
If
the
</ins>
Member
<del class="diff-old">organization
</del>
is
itself
a
consortium,
user
society,
or
otherwise
has
members
or
sponsors,
<ins class="diff-new">as
described
in
paragraph
5g
of
</ins>
the
<del class="diff-old">organization's
paid
staff
</del>
<a href="https://www.w3.org/Consortium/Agreement/Member-Agreement">
<ins class="diff-chg">Membership
Agreement
</ins></a>
and
<del class="diff-old">Advisory
Committee
representative
exercise
all
</del>
<ins class="diff-chg">hereafter
called
a
"
</ins><dfn><ins class="diff-chg">
Member
Consortium
</ins></dfn><ins class="diff-chg">
"
</ins>
the
rights
and
privileges
of
W3C
<del class="diff-old">membership.
In
addition,
</del>
<ins class="diff-chg">Membership
granted
by
W3C
Process
extend
to
</ins>
the
<ins class="diff-new">the
organization's
paid
staff
and
</ins>
Advisory
Committee
<del class="diff-old">representative
</del>
<ins class="diff-chg">representative.
</ins></p><p><ins class="diff-chg">
Member
Consortia
</ins>
<em class="rfc2119">
may
</em>
<ins class="diff-new">also
</ins>
designate
up
to
four
(or
more
at
the
Team's
discretion)
individuals
who,
though
not
employed
by
the
organization,
<em class="rfc2119">
may
</em>
exercise
the
rights
of
<a href="#member-rep">
Member
representatives
</a>.
<del class="diff-old">These
</del>
</p>
<p>
<ins class="diff-chg">For
Member
Consortia
that
have
individual
people
as
members
these
</ins>
individuals
<em class="rfc2119">
must
</em>
disclose
their
employment
affiliation
when
participating
in
W3C
work.
Provisions
for
<a href="#MemberRelated">
related
Members
</a>
apply.
Furthermore,
these
individuals
<del class="diff-old">are
expected
to
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
represent
the
broad
interests
of
the
W3C
Member
organization
and
not
the
<del class="diff-old">parochial
</del>
<ins class="diff-chg">particular
</ins>
interests
of
their
employers.
</p>
<p>
<del class="diff-old">The
rights
and
benefits
</del>
<ins class="diff-chg">For
Member
Consortia
that
have
organizations
as
Members,
all
such
designated
representatives
must
be
an
official
representative
</ins>
of
<del class="diff-old">W3C
membership
are
contingent
upon
conformance
to
</del>
the
<del class="diff-old">processes
described
</del>
<ins class="diff-chg">Member
organization
(i.e.
a
Committee
or
Task
Force
Chairperson)
and
</ins><em class="rfc2119"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
disclose
their
employment
affiliation
when
participating
</ins>
in
<del class="diff-old">this
document.
The
vast
majority
of
</del>
W3C
<ins class="diff-new">work.
Provisions
for
</ins><a href="#MemberRelated"><ins class="diff-new">
related
</ins>
Members
<del class="diff-old">faithfully
follow
the
spirit
as
well
as
</del>
</a>
<ins class="diff-chg">apply.
Furthermore,
these
individuals
</ins><em class="rfc2119"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
represent
</ins>
the
<del class="diff-old">letter
</del>
<ins class="diff-chg">broad
interests
</ins>
of
<del class="diff-old">these
processes.
When
serious
and/or
repeated
violations
do
occur,
</del>
<ins class="diff-chg">the
W3C
Member
organization
</ins>
and
<del class="diff-old">repeated
attempts
to
address
these
violations
have
</del>
not
<del class="diff-old">resolved
</del>
the
<del class="diff-old">situation,
the
Director
may
take
disciplinary
action.
Arbitration
in
the
case
</del>
<ins class="diff-chg">particular
interests
</ins>
of
<ins class="diff-new">their
employers.
</ins></p><p><ins class="diff-new">
For
all
representatives
of
a
Member
Consortium,
IPR
commitments
are
made
on
behalf
of
the
Member
Consortium,
unless
a
</ins>
further
<del class="diff-old">disagreement
</del>
<ins class="diff-chg">IPR
commitment
</ins>
is
<del class="diff-old">governed
</del>
<ins class="diff-chg">made
</ins>
by
<del class="diff-old">paragraph
19
of
the
Membership
Agreement.
Refer
to
</del>
the
<del class="diff-old">Guidelines
for
Disciplinary
Action
[
MEM14
].
</del>
<ins class="diff-chg">individuals'
employers.
</ins>
</p>
<del class="diff-old">2.1.2
</del>
<h5 id="MemberRelated">
<ins class="diff-chg">2.1.2.2
</ins>
Related
Members
</h5>
<p>
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:
</p>
<ol>
<li>
Either
Member
is
a
subsidiary
of
the
other,
or
</li>
<li>
Both
Members
are
subsidiaries
of
a
common
entity,
or
</li>
<li>
The
Members
have
an
employment
contract
or
consulting
contract
that
affects
W3C
participation.
</li>
</ol>
<p>
A
<em>
subsidiary
</em>
is
an
organization
of
which
effective
control
and/or
majority
ownership
rests
with
another,
single
organization.
</p>
<p>
Related
Members
<em class="rfc2119">
must
</em>
disclose
these
relationships
according
to
the
mechanisms
described
in
the
<a href="https://www.w3.org/Member/Intro">
New
Member
Orientation
</a>
[
<a href="#ref-new-member">
MEM4
</a>
].
</p>
<h4 id="AC">
2.1.3
Advisory
Committee
(AC)
</h4>
<p>
When
an
organization
joins
W3C
(see
"
<a href="https://www.w3.org/Consortium/join">
How
to
Join
W3C
</a>
"
[
<a href="#ref-join-w3c">
PUB5
</a>
]),
it
<em class="rfc2119">
must
</em>
name
its
Advisory
Committee
representative
as
part
of
the
Membership
Agreement.
The
<a href="https://www.w3.org/Member/Intro">
New
Member
Orientation
</a>
explains
how
to
subscribe
or
unsubscribe
to
Advisory
Committee
mailing
lists,
provides
information
about
Advisory
Committee
<del class="diff-old">meetings,
</del>
<ins class="diff-chg">Meetings,
</ins>
explains
how
to
name
a
new
Advisory
Committee
representative,
and
more.
Advisory
Committee
representatives
<em class="rfc2119">
must
</em>
follow
the
<a href="#coi">
conflict
of
interest
policy
</a>
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
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<p>
Additional
information
for
Members
is
available
at
the
<a href="https://www.w3.org/Member/">
Member
Web
site
</a>
[
<a href="#ref-member-web">
MEM6
</a>
].
</p>
<h5 id="ACCommunication">
2.1.3.1
Advisory
Committee
Mailing
Lists
</h5>
<p>
The
Team
<em class="rfc2119">
must
</em>
provide
two
mailing
lists
for
use
by
the
Advisory
Committee:
</p>
<ol>
<li>
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.
</li>
<li>
One
for
discussion
among
Advisory
Committee
representatives.
Though
this
list
is
primarily
for
Advisory
Committee
representatives,
the
Team
<em class="rfc2119">
must
</em>
monitor
discussion
and
<em class="rfc2119">
should
</em>
participate
in
discussion
when
appropriate.
Ongoing
detailed
discussions
<em class="rfc2119">
should
</em>
be
moved
to
other
appropriate
lists
(new
or
existing,
such
as
a
mailing
list
created
for
a
<a href="#GAEvents">
Workshop
</a>
).
</li>
</ol>
<p>
An
Advisory
Committee
representative
<em class="rfc2119">
may
</em>
request
that
additional
individuals
from
their
organization
be
subscribed
to
these
lists.
Failure
to
contain
distribution
internally
<em class="rfc2119">
may
</em>
result
in
suspension
of
additional
email
addresses,
at
the
discretion
of
the
Team.
</p>
<h5 id="ACMeetings">
2.1.3.2
Advisory
Committee
Meetings
</h5>
<p>
The
Team
organizes
a
<a href="#ftf-meeting">
face-to-face
meeting
</a>
for
the
Advisory
Committee
<span class="time-interval">
twice
a
year
</span>.
The
Team
appoints
the
Chair
of
these
meetings
(generally
the
CEO).
At
each
Advisory
Committee
meeting,
the
Team
<em class="rfc2119">
should
</em>
provide
an
update
to
the
Advisory
Committee
about:
</p>
<dl>
<dt>
<em>
Resources
</em>
</dt>
<dd>
<ul>
<li>
The
number
of
<del class="diff-old">Full
and
Affiliate
</del>
W3C
<del class="diff-old">Members.
</del>
<ins class="diff-chg">Members
at
each
level.
</ins>
</li>
<li>
An
overview
of
the
financial
status
of
W3C.
</li>
</ul>
</dd>
<dt>
<em>
Allocations
</em>
</dt>
<dd>
<ul>
<li>
The
allocation
of
the
annual
budget,
including
size
of
the
Team
and
their
approximate
deployment.
</li>
<li>
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.
</li>
<li>
The
allocation
of
resources
to
pursuing
<a href="#Liaisons">
liaisons
</a>
with
other
organizations.
</li>
</ul>
</dd>
</dl>
<p>
Each
Member
organization
<em class="rfc2119">
should
</em>
send
one
<a href="#member-rep">
representative
</a>
to
each
Advisory
Committee
<del class="diff-old">meeting.
</del>
<ins class="diff-chg">Meeting.
</ins>
In
exceptional
circumstances
(e.g.,
during
a
period
of
transition
between
representatives
from
an
organization),
the
meeting
Chair
<em class="rfc2119">
may
</em>
allow
a
Member
organization
to
send
two
representatives
to
a
meeting.
</p>
<p>
The
Team
<em class="rfc2119">
must
</em>
announce
the
date
and
location
of
each
Advisory
Committee
meeting
no
later
than
at
the
end
of
the
previous
meeting;
<span class="time-interval">
one
year's
</span>
notice
is
preferred.
The
Team
<em class="rfc2119">
must
</em>
announce
the
region
of
each
Advisory
Committee
meeting
at
least
<span class="time-interval">
one
year
</span>
in
advance.
</p>
<p>
More
information
about
<a href="https://www.w3.org/Member/Meeting/">
Advisory
Committee
meetings
</a>
[
<a href="#ref-ac-meetings">
MEM5
</a>
]
is
available
at
the
Member
Web
site.
</p>
<h3 id="Team">
2.2
The
W3C
Team
</h3>
<p>
The
Team
consists
of
the
Director,
CEO,
W3C
paid
staff,
unpaid
interns,
and
W3C
Fellows.
<dfn id="fellows">
W3C
Fellows
</dfn>
are
Member
employees
working
as
part
of
the
Team;
see
the
<a href="https://www.w3.org/Consortium/Recruitment/Fellows">
W3C
Fellows
Program
</a>
[
<a href="#ref-fellows">
PUB32
</a>
].
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.
</p>
<p>
The
Director
and
CEO
<em class="rfc2119">
may
</em>
delegate
responsibility
(generally
to
other
individuals
in
the
Team)
for
any
of
their
roles
described
in
this
document.
</p>
<p>
The
<dfn id="def-Director">
Director
</dfn>
is
the
lead
technical
architect
at
W3C.
His
responsibilities
are
identified
throughout
this
document
in
relevant
places.
Some
key
ones
include:
assessing
<a href="#def-Consensus" id="DirectorDecision">
consensus
</a>
within
W3C
for
architectural
choices,
publication
of
<a href="#Reports">
technical
reports
</a>,
and
chartering
new
Groups;
appointing
group
<a href="#GeneralChairs">
Chairs
</a>
;
<ins class="diff-new">adjudicating
as
</ins>
"tie-breaker"
for
<a href="#WGAppeals">
<del class="diff-old">appeal
of
a
Working
</del>
Group
decision
<ins class="diff-new">appeals
</ins>
</a>
and
deciding
on
the
outcome
of
formal
objections;
the
Director
is
generally
Chair
of
the
<a href="#TAG">
TAG
</a>.
</p>
<p>
Team
administrative
information
such
as
Team
salaries,
detailed
budgeting,
and
other
business
decisions
are
<a href="#Team-only">
Team-only
</a>,
subject
to
oversight
by
the
Host
institutions.
</p>
<p>
<strong>
Note:
</strong>
W3C
is
not
currently
incorporated.
For
legal
contracts,
W3C
is
represented
by
four
<dfn id="hosts">
"Host"
institutions
</dfn>:
Beihang
University,
the
European
Research
Consortium
for
Informatics
and
Mathematics
(
<abbr>
ERCIM
</abbr>
),
Keio
University,
and
the
Massachusetts
Institute
of
Technology
(
<abbr>
MIT
</abbr>
).
Within
W3C,
the
Host
institutions
are
governed
by
hosting
agreements;
the
Hosts
themselves
are
not
W3C
Members.
</p>
<h4 id="TeamSubmission">
2.2.1
Team
Submissions
</h4>
<p>
Team
members
<em class="rfc2119">
may
</em>
request
that
the
Director
publish
information
at
the
W3C
Web
site.
At
the
Director's
discretion,
these
documents
are
published
as
"Team
Submissions".
These
documents
are
analogous
to
<a href="#Submission">
Member
Submissions
</a>
(e.g.,
in
<a href="#SubmissionScope">
expected
scope
</a>
).
However,
there
is
no
additional
Team
comment.
The
<a href="#DocumentStatus">
document
status
section
</a>
of
a
Team
Submission
indicates
the
level
of
Team
consensus
about
the
published
material.
</p>
<p>
Team
Submissions
are
<strong>
not
</strong>
part
of
the
<a href="#Reports">
technical
report
development
process
</a>.
</p>
<p>
The
list
of
<a href="https://www.w3.org/TeamSubmission/">
published
Team
Submissions
</a>
[
<a href="#ref-team-submission-list">
PUB16
</a>
]
is
available
at
the
W3C
Web
site.
</p>
<h3 id="AB">
2.3
Advisory
Board
(AB)
</h3>
<p>
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
<a href="#GAProcess">
evolution
of
the
Process
Document
</a>.
The
Advisory
Board
hears
<del class="diff-old">appeals
of
</del>
<ins class="diff-chg">a
</ins>
<a href="#SubmissionNo">
<del class="diff-old">Member
</del>
Submission
<del class="diff-old">requests
</del>
<ins class="diff-chg">Appeal
</ins>
</a>
<del class="diff-old">that
are
</del>
<ins class="diff-chg">when
a
Member
Submission
is
</ins>
rejected
for
reasons
unrelated
to
Web
architecture;
see
also
the
<a href="#TAG">
TAG
</a>.
</p>
<p>
The
Advisory
Board
is
<strong>
not
</strong>
a
board
of
directors
and
has
no
decision-making
authority
within
W3C;
its
role
is
strictly
advisory.
</p>
<p>
The
Team
<em class="rfc2119">
must
</em>
make
available
a
mailing
list
for
the
Advisory
Board
to
use
for
its
communication,
confidential
to
the
Advisory
Board
and
Team.
</p>
<p>
The
Advisory
Board
<em class="rfc2119">
should
</em>
send
a
summary
of
each
of
its
meetings
to
the
Advisory
Committee
and
other
group
Chairs.
The
Advisory
Board
<em class="rfc2119">
should
</em>
also
report
on
its
activities
at
each
<a href="#ACMeetings">
Advisory
Committee
meeting
</a>.
</p>
<p>
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
<a href="https://www.w3.org/2002/ab/">
Advisory
Board
home
page
</a>
[
<a href="#ref-ab-home">
PUB30
</a>
].
</p>
<h4 id="ABParticipation">
2.3.1
Advisory
Board
Participation
</h4>
<p>
The
Advisory
Board
consists
of
nine
elected
participants
and
a
Chair.
The
Team
appoints
the
Chair
of
the
<a href="#AB">
Advisory
Board
</a>,
who
is
generally
the
CEO.
</p>
<p>
The
remaining
nine
Advisory
Board
participants
are
elected
by
the
W3C
Advisory
Committee
following
the
<a href="#AB-TAG-elections">
AB/TAG
nomination
and
election
process
</a>.
</p>
<p>
With
the
exception
of
the
Chair,
the
terms
of
all
Advisory
Board
participants
are
for
<span class="time-interval">
two
years
</span>.
Terms
are
staggered
so
that
each
year,
either
four
or
five
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.
</p>
<h3 id="TAG">
2.4
Technical
Architecture
Group
(TAG)
</h3>
<p>
Created
in
February
2001,
the
mission
of
the
TAG
is
stewardship
of
the
Web
architecture.
There
are
three
aspects
to
this
mission:
</p>
<ol>
<li>
to
document
and
build
consensus
around
principles
of
Web
architecture
and
to
interpret
and
clarify
these
principles
when
necessary;
</li>
<li>
to
resolve
issues
involving
general
Web
architecture
brought
to
the
TAG;
</li>
<li>
to
help
coordinate
cross-technology
architecture
developments
inside
and
outside
W3C.
</li>
</ol>
<p>
The
TAG
hears
<del class="diff-old">appeals
of
</del>
<ins class="diff-chg">a
</ins>
<a href="#SubmissionNo">
<del class="diff-old">Member
</del>
Submission
<del class="diff-old">requests
</del>
<ins class="diff-chg">Appeal
</ins>
</a>
<del class="diff-old">that
are
</del>
<ins class="diff-chg">when
a
Member
Submission
is
</ins>
rejected
for
reasons
related
to
Web
architecture;
see
also
the
<a href="#AB">
Advisory
Board
</a>.
</p>
<p>
The
TAG's
scope
is
limited
to
technical
issues
about
Web
architecture.
The
TAG
<em class="rfc2119">
should
not
</em>
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
<a href="https://www.w3.org/2004/10/27-tag">
TAG
charter
</a>
[
<a href="#ref-tag-charter">
PUB25
</a>
]
for
more
information
about
the
background
and
scope
of
the
TAG,
and
the
expected
qualifications
of
TAG
participants.
</p>
<p>
The
Team
<em class="rfc2119">
must
</em>
make
available
two
mailing
lists
for
the
TAG:
</p>
<ul>
<li>
a
public
discussion
(not
just
input)
list
for
issues
of
Web
architecture.
The
TAG
will
conduct
its
public
business
on
this
list.
</li>
<li>
a
<a href="#Member-only">
Member-only
</a>
list
for
discussions
within
the
TAG
and
for
requests
to
the
TAG
that,
for
whatever
reason,
cannot
be
made
on
the
public
list.
</li>
</ul>
<p>
The
TAG
<em class="rfc2119">
may
</em>
also
request
the
creation
of
additional
topic-specific,
public
mailing
lists.
For
some
TAG
discussions
(e.g.,
<del class="diff-old">an
appeal
of
</del>
a
<a href="#SubmissionNo">
<del class="diff-old">rejected
Member
</del>
Submission
<del class="diff-old">request
</del>
<ins class="diff-chg">Appeal
</ins>
</a>
),
the
TAG
<em class="rfc2119">
may
</em>
use
a
list
that
will
be
<a href="#Member-only">
Member-only
</a>.
</p>
<p>
The
TAG
<em class="rfc2119">
should
</em>
send
a
summary
of
each
of
its
<a href="#GeneralMeetings">
meetings
</a>
to
the
Advisory
Committee
and
other
group
Chairs.
The
TAG
<em class="rfc2119">
should
</em>
also
report
on
its
activities
at
each
<a href="#ACMeetings">
Advisory
Committee
meeting
</a>.
</p>
<p>
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
<a href="https://www.w3.org/2004/10/27-tag#Voting">
voting
in
the
TAG
charter
</a>
[
<a href="#ref-tag-charter">
PUB25
</a>
]
and
the
general
section
on
<a href="#Votes">
votes
</a>
in
this
Process
Document.
</p>
<p>
Details
about
the
TAG
(e.g.,
the
list
of
TAG
participants,
mailing
list
information,
and
summaries
of
TAG
meetings)
are
available
at
the
<a href="https://www.w3.org/2001/tag/">
TAG
home
page
</a>
[
<a href="#ref-tag-home">
PUB26
</a>
].
</p>
<h4 id="tag-participation">
2.4.1
Technical
Architecture
Group
Participation
</h4>
<p>
The
TAG
consists
of
eight
elected
or
appointed
participants
and
a
Chair.
The
Team
appoints
the
Chair
of
the
TAG,
who
is
generally
the
<a href="#def-Director">
Director
</a>.
</p>
<p>
Three
TAG
participants
are
appointed
by
the
Director.
Appointees
are
<em class="rfc2119">
not
required
</em>
to
be
on
the
W3C
Team.
The
Director
<em class="rfc2119">
may
</em>
appoint
<a href="#fellows">
W3C
Fellows
</a>
to
the
TAG.
</p>
<p>
The
remaining
five
TAG
participants
are
elected
by
the
W3C
Advisory
Committee
following
the
<a href="#AB-TAG-elections">
AB/TAG
nomination
and
election
process
</a>.
</p>
<p>
With
the
exception
of
the
Chair,
the
terms
of
all
TAG
participants
are
for
<span class="time-interval">
two
years
</span>.
Terms
are
staggered
so
that
each
year,
either
two
or
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.
</p>
<h3 id="AB-TAG-participation">
2.5
Advisory
Board
and
Technical
Architecture
Group
Participation
</h3>
<p>
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
<em class="rfc2119">
should
</em>
attend
<a href="#ACMeetings">
Advisory
Committee
meetings
</a>.
</p>
<p>
An
individual
participates
on
the
Advisory
Board
or
TAG
from
the
moment
the
individual's
term
begins
until
the
term
ends
or
the
seat
is
<a href="#AB-TAG-vacated">
vacated
</a>.
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
<a href="#AB-TAG-elections">
AB/TAG
nomination
and
election
process
</a>
).
See
also
the
licensing
obligations
on
TAG
participants
in
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Obligations">
section
3
</a>
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
],
and
the
claim
exclusion
process
of
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">
section
4
</a>.
</p>
<h4 id="AB-TAG-constraints">
2.5.1
Advisory
Board
and
Technical
Architecture
Group
Participation
Constraints
</h4>
<p>
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:
</p>
<ul>
<li>
A
Member
organization
is
permitted
at
most
one
participant
on
the
TAG
except
when
having
more
than
one
participant
is
caused
by
a
change
of
affiliation
of
an
existing
participant.
At
the
completion
of
the
next
regularly
scheduled
election
for
the
TAG,
the
Member
organization
<em class="rfc2119">
must
</em>
have
returned
to
having
at
most
one
participant.
</li>
<li>
A
Member
organization
is
permitted
at
most
one
participant
on
the
AB.
</li>
<li>
An
individual
<em class="rfc2119">
must
not
</em>
participate
on
both
the
TAG
and
the
AB.
</li>
</ul>
<p>
If,
for
whatever
reason,
these
constraints
are
not
satisfied
(e.g.,
because
an
AB
participant
changes
jobs),
one
participant
<em class="rfc2119">
must
</em>
cease
AB
participation
until
the
situation
has
been
resolved.
If
after
<span class="time-interval">
30
days
</span>
the
situation
has
not
been
resolved,
the
Chair
will
declare
one
participant's
seat
to
be
vacant.
When
more
than
one
individual
is
involved,
the
<a href="#random">
verifiable
random
selection
procedure
</a>
described
below
will
be
used
to
choose
one
person
for
continued
participation.
</p>
<h4 id="AB-TAG-elections">
2.5.2
Advisory
Board
and
Technical
Architecture
Group
Elections
</h4>
<p>
The
Advisory
Board
and
a
portion
of
the
Technical
Architecture
Group
are
elected
by
the
Advisory
<del class="diff-old">Committee.
</del>
<ins class="diff-chg">Committee,
using
a
Single
Transferable
Vote
system.
</ins>
An
election
begins
when
the
Team
sends
a
Call
for
Nominations
to
the
Advisory
Committee.
Any
Call
for
Nominations
specifies
the
number
of
available
seats,
the
deadline
for
nominations,
<ins class="diff-new">details
about
the
specific
vote
tabulation
system
selected
by
the
Team
for
the
election,
</ins>
and
<ins class="diff-new">operational
information.
The
Team
may
modify
</ins>
the
<del class="diff-old">address
where
nominations
are
sent.
</del>
<ins class="diff-chg">tabulation
system
after
the
Call
for
Nominations
but
must
stabilize
it
no
later
than
the
Call
for
Votes.
</ins>
The
Director
<em class="rfc2119">
should
</em>
announce
appointments
no
later
than
the
start
of
a
nomination
<del class="diff-old">period,
and
generally
</del>
<ins class="diff-chg">period
</ins>
as
part
of
the
Call
for
Nominations.
</p>
<p>
Each
Member
(or
group
of
<a href="#MemberRelated">
related
Members
</a>
)
<em class="rfc2119">
may
</em>
nominate
one
individual.
A
nomination
<em class="rfc2119">
must
</em>
be
made
with
the
consent
of
the
nominee.
In
order
for
an
individual
to
be
nominated
as
a
Member
representative,
the
individual
<em class="rfc2119">
must
</em>
qualify
for
<a href="#member-rep">
Member
representation
</a>
and
the
Member's
Advisory
Committee
representative
<em class="rfc2119">
must
</em>
include
in
the
nomination
the
(same)
<a href="#member-rep-info">
information
required
for
a
Member
representative
in
a
Working
Group
</a>.
In
order
for
an
individual
to
be
nominated
as
an
Invited
Expert,
the
individual
<em class="rfc2119">
must
</em>
provide
the
(same)
<a href="#inv-expert-info">
information
required
for
an
Invited
Expert
in
a
Working
Group
</a>
and
the
nominating
Advisory
Committee
representative
<em class="rfc2119">
must
</em>
include
that
information
in
the
nomination.
In
order
for
an
individual
to
be
nominated
as
a
Team
representative,
the
nominating
Advisory
Committee
representative
<em class="rfc2119">
must
</em>
first
secure
approval
from
Team
management.
A
nominee
is
<em class="rfc2119">
not
required
</em>
to
be
an
employee
of
a
Member
organization,
and
<em class="rfc2119">
may
</em>
be
a
<a href="#fellows">
W3C
Fellow
</a>.
Each
nomination
<em class="rfc2119">
should
</em>
include
a
few
informative
paragraphs
about
the
nominee.
</p>
<p>
If,
after
the
deadline
for
nominations,
the
number
of
nominees
is:
</p>
<ul>
<li>
Equal
to
the
number
of
available
seats,
those
nominees
are
thereby
elected.
This
situation
constitutes
a
tie
for
the
purposes
of
assigning
<a href="#short-term">
short
terms
</a>.
</li>
<li>
Less
than
the
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.
</li>
<li>
Greater
than
the
number
of
available
seats,
the
Team
issues
a
Call
for
Votes
that
includes
the
names
of
all
candidates,
the
number
of
available
seats,
the
deadline
for
votes,
<del class="diff-old">and
</del>
<ins class="diff-chg">details
about
</ins>
the
<del class="diff-old">address
where
votes
are
sent.
</del>
<ins class="diff-chg">vote
tabulation
system
selected
by
the
Team
for
the
election,
and
operational
information.
</ins>
</li>
</ul>
<p>
When
there
is
a
vote,
each
Member
(or
group
of
<a href="#MemberRelated">
related
Members
</a>
)
<em class="rfc2119">
may
</em>
<del class="diff-old">vote
for
as
many
</del>
<ins class="diff-chg">submit
one
ballot
that
ranks
</ins>
candidates
<del class="diff-old">as
there
are
available
seats;
see
</del>
<ins class="diff-chg">in
</ins>
the
<del class="diff-old">section
on
Advisory
Committee
votes
.
</del>
<ins class="diff-chg">Member's
preferred
order.
</ins>
Once
the
deadline
for
votes
has
passed,
the
Team
announces
the
results
to
the
Advisory
Committee.
<del class="diff-old">The
candidates
with
the
most
votes
are
elected
to
the
available
seats.
</del>
In
case
of
a
tie
<del class="diff-old">where
there
are
more
apparent
winners
than
available
seats
(e.g.,
three
candidates
receive
10
votes
each
for
two
seats),
</del>
the
<a href="#random">
verifiable
random
selection
procedure
</a>
described
below
will
be
used
to
fill
the
available
seats.
</p>
<p id="short-term">
The
shortest
term
is
assigned
to
the
elected
<del class="diff-old">individual
who
received
</del>
<ins class="diff-chg">candidate
ranked
lowest
by
</ins>
the
<del class="diff-old">fewest
</del>
<ins class="diff-chg">tabulation
of
</ins>
votes,
the
next
shortest
<ins class="diff-new">term
</ins>
to
the
<ins class="diff-new">next-lowest
ranked
</ins>
elected
<del class="diff-old">individual
who
received
the
next
fewest,
</del>
<ins class="diff-chg">candidate,
</ins>
and
so
on.
In
the
case
of
a
tie
among
those
eligible
for
a
short
term,
the
<a href="#random">
verifiable
random
selection
procedure
</a>
described
below
will
be
used
to
assign
the
short
term.
</p>
<p>
Refer
to
<a href="https://www.w3.org/2002/10/election-howto">
How
to
Organize
an
Advisory
Board
or
TAG
election
</a>
[
<a href="#ref-election-howto">
MEM15
</a>
]
for
more
details.
</p>
<h5 id="random">
2.5.2.1
Verifiable
Random
Selection
Procedure
</h5>
<p>
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
<a href="http://www.ietf.org/rfc/rfc2777.txt">
RFC
2777
</a>
[
<a href="#ref-RFC2777">
RFC2777
</a>
].
The
procedure
orders
an
input
list
of
names
(listed
in
alphabetical
order
by
family
name
unless
otherwise
specified)
into
a
"result
order."
</p>
<p>
W3C
applies
this
procedure
as
follows:
</p>
<ol>
<li>
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.
</li>
<li>
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.
</li>
</ol>
<h4 id="AB-TAG-vacated">
2.5.3
Advisory
Board
and
Technical
Architecture
Group
Vacated
Seats
</h4>
<p>
An
Advisory
Board
or
TAG
participant's
seat
is
vacated
when
either
of
the
following
occurs:
</p>
<ul>
<li>
the
participant
<a href="#resignation">
resigns
</a>,
or
</li>
<li>
the
Chair
asks
the
participant
to
<a href="#resignation">
resign
</a>.
</li>
</ul>
<p>
When
an
Advisory
Board
or
TAG
participant
changes
affiliations,
as
long
as
<a href="#AB-TAG-constraints">
Advisory
Board
and
TAG
participation
constraints
</a>
are
respected,
the
individual
<em class="rfc2119">
may
</em>
continue
to
participate
until
the
next
regularly
scheduled
election
for
that
group.
Otherwise,
the
seat
is
vacated.
</p>
<p>
Vacated
seats
are
filled
according
to
this
schedule:
</p>
<ul>
<li>
When
an
appointed
TAG
seat
is
vacated,
the
Director
<em class="rfc2119">
may
</em>
re-appoint
someone
immediately,
but
no
later
than
the
next
regularly
scheduled
election.
</li>
<li>
When
an
elected
seat
on
either
the
AB
or
TAG
is
vacated,
the
seat
is
filled
at
the
next
regularly
scheduled
election
for
the
group
unless
the
group
Chair
requests
that
W3C
hold
an
election
before
then
(for
instance,
due
to
the
group's
workload).
The
group
Chair
<em class="rfc2119">
should
not
</em>
request
an
exceptional
election
if
the
next
regularly
scheduled
election
is
fewer
than
three
months
away.
</li>
</ul>
<h2 id="Policies">
3
General
Policies
for
W3C
Groups
</h2>
<p>
This
section
describes
general
policies
for
W3C
groups
regarding
participation,
meeting
requirements,
and
decision-making.
These
policies
apply
to
<span id="participant">
participants
</span>
in
the
following
groups:
<a href="#AC">
Advisory
Committee
</a>,
<a href="#ABParticipation">
Advisory
Board
</a>,
<a href="#tag-participation">
TAG
</a>,
<a href="#wgparticipant">
Working
Groups
</a>,
and
<a href="#igparticipant">
Interest
Groups
</a>.
</p>
<h3 id="ParticipationCriteria">
3.1
Individual
Participation
Criteria
</h3>
<p>
There
are
three
qualities
an
individual
is
expected
to
demonstrate
in
order
to
participate
in
W3C:
</p>
<ol>
<li>
Technical
competence
in
one's
role
</li>
<li>
The
ability
to
act
fairly
</li>
<li>
Social
competence
in
one's
role
</li>
</ol>
<p>
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.
</p>
<p>
See
also
the
participation
requirements
described
in
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">
section
6
</a>
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<h4 id="coi">
3.1.1
Conflict
of
Interest
Policy
</h4>
<p>
Individuals
participating
materially
in
W3C
work
<em class="rfc2119">
must
</em>
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
<em class="rfc2119">
must
</em>
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.
</p>
<p>
The
ability
of
an
individual
to
fulfill
a
role
within
a
group
without
risking
a
conflict
of
interest
<del class="diff-old">is
clearly
a
function
of
</del>
<ins class="diff-chg">depends
on
</ins>
the
individual's
affiliations.
When
these
affiliations
change,
the
individual's
assignment
to
the
role
<em class="rfc2119">
must
</em>
be
evaluated.
The
role
<em class="rfc2119">
may
</em>
be
reassigned
according
to
the
appropriate
process.
For
instance,
the
Director
<em class="rfc2119">
may
</em>
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).
</p>
<p>
The
following
are
some
scenarios
where
disclosure
is
appropriate:
</p>
<ul>
<li>
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).
</li>
<li>
A
decision-making
role/responsibility
(such
as
participating
on
the
Board)
in
other
organizations
relevant
to
W3C.
</li>
<li>
A
position
on
a
publicly
visible
advisory
body,
even
if
no
decision
making
authority
is
involved.
</li>
</ul>
<p>
Individuals
seeking
assistance
on
these
matters
<em class="rfc2119">
should
</em>
contact
the
Team.
</p>
<p>
Team
members
are
subject
to
the
<a href="https://www.w3.org/2000/09/06-conflictpolicy">
W3C
Team
conflict
of
interest
policy
</a>
[
<a href="#ref-coi">
PUB23
</a>
].
</p>
<h4 id="member-rep">
3.1.2
Individuals
Representing
a
Member
Organization
</h4>
<p>
Generally,
individuals
representing
a
Member
in
an
official
capacity
within
W3C
are
employees
of
the
Member
organization.
However,
an
Advisory
Committee
representative
<em class="rfc2119">
may
</em>
designate
a
non-employee
to
represent
the
Member.
Non-employee
Member
representatives
<em class="rfc2119">
must
</em>
disclose
relevant
affiliations
to
the
Team
and
to
any
group
in
which
the
individual
participates.
</p>
<p>
In
exceptional
circumstances
(e.g.,
situations
that
might
jeopardize
the
progress
of
a
group
or
create
a
<a href="#coi">
conflict
of
interest
</a>
),
the
<a href="#def-Director">
Director
</a>
<em class="rfc2119">
may
</em>
decline
to
allow
an
individual
designated
by
an
Advisory
Committee
representative
to
participate
in
a
group.
</p>
<p>
A
group
charter
<em class="rfc2119">
may
</em>
limit
the
number
of
individuals
representing
a
W3C
Member
(or
group
of
<a href="#MemberRelated">
related
Members
</a>
).
</p>
<h3 id="GeneralMeetings">
3.2
Meetings
</h3>
<p>
W3C
groups
(including
the
<a href="#ACMeetings">
Advisory
Committee
</a>,
<a href="#AB">
Advisory
Board
</a>,
<a href="#TAG">
TAG
</a>,
and
<a href="#GroupsWG">
Working
Groups
</a>
)
<em class="rfc2119">
should
</em>
observe
the
meeting
requirements
in
this
section.
</p>
<p>
W3C
distinguishes
two
types
of
meetings:
</p>
<ol>
<li>
A
<dfn id="ftf-meeting">
face-to-face
meeting
</dfn>
is
one
where
most
of
the
attendees
are
expected
to
participate
in
the
same
physical
location.
</li>
<li>
A
<dfn id="distributed-meeting">
distributed
meeting
</dfn>
is
one
where
most
of
the
attendees
are
expected
to
participate
from
remote
locations
(e.g.,
by
telephone,
video
conferencing,
or
<abbr title="Internet Relay Chat">
IRC
</abbr>
).
</li>
</ol>
<p>
A
Chair
<em class="rfc2119">
may
</em>
invite
an
individual
with
a
particular
expertise
to
attend
a
meeting
on
an
exceptional
basis.
This
person
is
a
meeting
guest,
not
a
group
<a href="#participant">
participant
</a>.
Meeting
guests
do
not
have
<a href="#Votes">
voting
rights
</a>.
It
is
the
responsibility
of
the
Chair
to
ensure
that
all
meeting
guests
respect
the
chartered
<a href="#confidentiality-levels">
level
of
confidentiality
</a>
and
other
group
requirements.
</p>
<p>
Meeting
announcements
<em class="rfc2119">
should
</em>
be
sent
to
all
appropriate
group
mailing
lists,
i.e.,
those
most
relevant
to
the
anticipated
meeting
participants.
</p>
<p>
The
following
table
lists
requirements
for
organizing
a
meeting:
</p>
<table border="1">
<tbody>
<tr>
<th>
<br>
</th>
<th>
Face-to-face
meetings
</th>
<th>
Distributed
meetings
</th>
</tr>
<tr>
<th>
Meeting
announcement
(before)
</th>
<td>
<span class="time-interval">
eight
weeks
<sup>
*
</sup>
</span>
</td>
<td>
<span class="time-interval">
one
week
<sup>
*
</sup>
</span>
</td>
</tr>
<tr>
<th>
Agenda
available
(before)
</th>
<td>
<span class="time-interval">
two
weeks
</span>
</td>
<td>
<span class="time-interval">
24
hours
</span>
(or
longer
if
a
meeting
is
scheduled
after
a
weekend
or
holiday)
</td>
</tr>
<tr>
<th>
Participation
confirmed
(before)
</th>
<td>
<span class="time-interval">
three
days
</span>
</td>
<td>
<span class="time-interval">
24
hours
</span>
</td>
</tr>
<tr>
<th>
Action
items
available
(after)
</th>
<td>
<span class="time-interval">
three
days
</span>
</td>
<td>
<span class="time-interval">
24
hours
</span>
</td>
</tr>
<tr>
<th>
Minutes
available
(after)
</th>
<td>
<span class="time-interval">
two
weeks
</span>
</td>
<td>
<span class="time-interval">
48
hours
</span>
</td>
</tr>
</tbody>
</table>
<p>
<sup>
*
</sup>
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.
</p>
<h3 id="Consensus">
3.3
Consensus
</h3>
<p>
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
<em class="rfc2119">
may
</em>
be
made
during
meetings
(
<a href="#ftf-meeting">
face-to-face
</a>
or
<a href="#distributed-meeting">
distributed
</a>
)
as
well
as
through
email.
<strong>
Note:
</strong>
The
Director,
CEO,
and
COO
have
the
role
of
assessing
consensus
within
the
Advisory
Committee.
</p>
<p>
The
following
terms
are
used
in
this
document
to
describe
the
level
of
support
for
a
decision
among
a
set
of
eligible
individuals:
</p>
<ol>
<li>
<dfn id="def-Consensus">
Consensus
</dfn>:
A
substantial
number
of
individuals
in
the
set
support
the
decision
and
nobody
in
the
set
registers
a
<a href="#FormalObjection">
Formal
Objection
</a>.
Individuals
in
the
set
may
abstain.
Abstention
is
either
an
explicit
expression
of
no
opinion
or
silence
by
an
individual
in
the
set.
<dfn id="def-Unanimity">
Unanimity
</dfn>
is
the
particular
case
of
consensus
where
all
individuals
in
the
set
support
the
decision
(i.e.,
no
individual
in
the
set
abstains).
</li>
<li>
<dfn id="def-Dissent">
Dissent
</dfn>:
At
least
one
individual
in
the
set
registers
a
<a href="#FormalObjection">
Formal
Objection
</a>.
</li>
</ol>
<p>
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
<em class="rfc2119">
may
</em>
include
a
quorum
requirement
for
consensus
decisions.
</p>
<p>
Where
unanimity
is
not
possible,
a
group
<em class="rfc2119">
should
</em>
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
<em class="rfc2119">
should
</em>
set
minimum
thresholds
of
active
support
before
a
decision
can
be
recorded.
The
appropriate
percentage
<em class="rfc2119">
may
</em>
vary
depending
on
the
size
of
the
group
and
the
nature
of
the
decision.
A
charter
<em class="rfc2119">
may
</em>
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.
</p>
<h4 id="managing-dissent">
3.3.1
Managing
Dissent
</h4>
<p>
In
some
cases,
even
after
careful
consideration
of
all
points
of
view,
a
group
might
find
itself
unable
to
reach
consensus.
The
Chair
<em class="rfc2119">
may
</em>
record
a
decision
where
there
is
dissent
(i.e.,
there
is
at
least
one
<a href="#FormalObjection">
Formal
Objection
</a>
)
so
that
the
group
may
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
<em class="rfc2119">
should
</em>
move
on.
</p>
<p>
Groups
<em class="rfc2119">
should
</em>
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
<a href="#MemberRelated">
related
</a>
)
Member
organizations
and
weigh
their
input
accordingly.
</p>
<h4 id="WGArchiveMinorityViews">
3.3.2
Recording
and
Reporting
Formal
Objections
</h4>
<p>
In
the
W3C
process,
an
individual
may
register
a
Formal
Objection
to
a
decision.
A
<dfn id="FormalObjection">
Formal
Objection
</dfn>
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
<a href="#rec-advance">
request
to
advance
</a>
a
technical
report).
<strong>
Note:
</strong>
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.
</p>
<p>
An
individual
who
registers
a
Formal
Objection
<em class="rfc2119">
should
</em>
cite
technical
arguments
and
propose
changes
that
would
remove
the
Formal
Objection;
these
proposals
<em class="rfc2119">
may
</em>
be
vague
or
incomplete.
Formal
Objections
that
do
not
provide
substantive
arguments
or
rationale
are
unlikely
to
receive
serious
consideration
by
the
Director.
</p>
<p>
A
record
of
each
Formal
Objection
<em class="rfc2119">
must
</em>
be
<a href="#confidentiality-change">
publicly
available
</a>.
A
Call
for
Review
(of
a
document)
to
the
Advisory
Committee
<em class="rfc2119">
must
</em>
identify
any
Formal
Objections.
</p>
<h4 id="formal-address">
3.3.3
Formally
Addressing
an
Issue
</h4>
<p>
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
<em class="rfc2119">
should
</em>
seek
clarification
before
reaching
a
decision.
</p>
<p>
As
a
courtesy,
both
Chairs
and
reviewers
<em class="rfc2119">
should
</em>
set
expectations
for
the
schedule
of
responses
and
acknowledgments.
The
group
<em class="rfc2119">
should
</em>
reply
to
a
reviewer's
initial
comments
in
a
timely
manner.
The
group
<em class="rfc2119">
should
</em>
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
<em class="rfc2119">
should
</em>
realize
that
their
comments
will
carry
less
weight
if
not
sent
to
the
group
in
a
timely
manner.
</p>
<p>
Substantive
responses
<em class="rfc2119">
should
</em>
be
recorded.
The
group
<em class="rfc2119">
should
</em>
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).
</p>
<h4 id="WGChairReopen">
3.3.4
Reopening
a
Decision
When
Presented
With
New
Information
</h4>
<p>
The
Chair
<em class="rfc2119">
may
</em>
reopen
a
decision
when
presented
with
new
information,
including:
</p>
<ul>
<li>
additional
technical
information,
</li>
<li>
comments
by
email
from
participants
who
were
unable
to
attend
a
scheduled
meeting,
</li>
<li>
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).
</li>
</ul>
<p>
The
Chair
<em class="rfc2119">
should
</em>
record
that
a
decision
has
been
reopened,
and
<em class="rfc2119">
must
</em>
do
so
upon
request
from
a
group
participant.
</p>
<h3 id="Votes">
3.4
Votes
</h3>
<p>
A
group
<em class="rfc2119">
should
</em>
only
conduct
a
vote
to
resolve
a
<em>
substantive
issue
</em>
after
the
Chair
has
determined
that
all
available
means
of
<a href="#Consensus">
reaching
consensus
</a>
through
technical
discussion
and
compromise
have
failed,
and
that
a
vote
is
necessary
to
break
a
deadlock.
In
this
case
the
Chair
<em class="rfc2119">
must
</em>
record
(e.g.,
in
the
minutes
of
the
meeting
or
in
an
archived
email
message):
</p>
<ul>
<li>
an
explanation
of
the
issue
being
voted
on;
</li>
<li>
the
decision
to
conduct
a
vote
(e.g.,
a
simple
majority
vote)
to
resolve
the
issue;
</li>
<li>
the
outcome
of
the
vote;
</li>
<li>
any
Formal
Objections.
</li>
</ul>
<p>
In
order
to
vote
to
resolve
a
substantive
issue,
an
individual
<em class="rfc2119">
must
</em>
be
a
group
<a href="#participant">
participant
</a>.
Each
organization
represented
in
the
group
<em class="rfc2119">
must
</em>
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:
</p>
<ul>
<li>
A
Member
or
group
of
<a href="#MemberRelated">
related
Members
</a>
is
considered
a
single
organization.
</li>
<li>
The
<a href="#Team">
Team
</a>
is
considered
an
organization.
</li>
</ul>
<p>
Unless
the
charter
states
otherwise,
<a href="#invited-expert-wg">
Invited
Experts
</a>
<em class="rfc2119">
may
</em>
vote.
</p>
<p>
If
a
participant
is
unable
to
attend
a
vote,
that
individual
<em class="rfc2119">
may
</em>
authorize
anyone
at
the
meeting
to
act
as
a
<dfn id="proxy">
proxy
</dfn>.
The
absent
participant
<em class="rfc2119">
must
</em>
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
<a href="#mtg-substitute">
substitute
</a>
for
a
participant.
</p>
<p>
A
group
<em class="rfc2119">
may
</em>
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.
</p>
<p>
A
group
<em class="rfc2119">
may
</em>
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,
the
minority
are
<em class="rfc2119">
not
required
</em>
to
state
the
reasons
for
their
dissent,
and
the
group
is
<em class="rfc2119">
not
required
</em>
to
record
individual
votes.
</p>
<p>
A
group
charter
<em class="rfc2119">
should
</em>
include
formal
voting
procedures
(e.g.,
quorum
or
threshold
requirements)
for
making
decisions
about
substantive
issues.
</p>
<p>
Procedures
for
<a href="#ACVotes">
Advisory
Committee
votes
</a>
are
described
separately.
</p>
<h3 id="WGAppeals">
3.5
Appeal
of
a
Chair's
Decision
</h3>
<p>
Groups
resolve
issues
through
dialog.
Individuals
who
disagree
strongly
with
a
decision
<em class="rfc2119">
should
</em>
register
with
the
Chair
any
<a href="#FormalObjection">
Formal
Objections
</a>
(e.g.,
to
a
decision
made
as
the
result
of
a
<a href="#Votes">
vote
</a>
).
</p>
<p>
When
group
participants
believe
that
their
concerns
are
not
being
duly
considered
by
the
group,
they
<em class="rfc2119">
may
</em>
ask
the
<a href="#def-Director">
Director
</a>
(for
representatives
of
a
Member
organization,
via
their
Advisory
Committee
representative)
to
confirm
or
deny
the
decision.
<ins class="diff-new">This
is
a
</ins><dfn><ins class="diff-new">
Group
Decision
Appeal
</ins></dfn>.
The
participants
<em class="rfc2119">
should
</em>
also
make
their
requests
known
to
the
<a href="#TeamContact">
Team
Contact
</a>.
The
Team
Contact
<em class="rfc2119">
must
</em>
inform
the
Director
when
a
group
participant
has
raised
concerns
about
due
process.
</p>
<p>
Any
requests
to
the
Director
to
confirm
a
decision
<em class="rfc2119">
must
</em>
include
a
summary
of
the
issue
(whether
technical
or
procedural),
decision,
and
rationale
for
the
objection.
All
counter-arguments,
rationales,
and
decisions
<em class="rfc2119">
must
</em>
be
recorded.
</p>
<p>
Procedures
for
<a href="#ACAppeal">
Advisory
Committee
appeals
</a>
are
described
separately.
</p>
<h3 id="resignation">
3.6
Resignation
from
a
Group
</h3>
<p>
A
W3C
Member
or
Invited
Expert
<em class="rfc2119">
may
</em>
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.
See
section
4.2.
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
]
for
information
about
obligations
remaining
after
resignation
from
certain
groups.
</p>
<section id="chapterDissemination">
<h2 id="dissemination">
4
Dissemination
Policies
</h2>
<p>
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
<em class="rfc2119">
should
</em>
solicit
review
by
the
Team
prior
to
issuing
press
releases
about
their
work
within
W3C.
</p>
<p>
The
Team
makes
every
effort
to
ensure
the
persistence
and
availability
of
the
following
public
information:
</p>
<ul>
<li>
<a href="#Reports">
W3C
technical
reports
</a>
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
<a href="https://www.w3.org/Consortium/Legal/copyright-documents">
W3C
Document
License
</a>
[
<a href="#ref-doc-license">
PUB18
</a>
]).
</li>
<li>
A
<a href="https://www.w3.org/Consortium/mission">
mission
statement
</a>
[
<a href="#ref-mission">
PUB15
</a>
]
that
explains
the
purpose
and
mission
of
W3C,
the
key
benefits
for
Members,
and
the
organizational
structure
of
W3C.
</li>
<li>
Legal
documents,
including
the
<a href="https://www.w3.org/Consortium/Agreement/Member-Agreement">
Membership
Agreement
</a>
[
<a href="#ref-member-agreement">
PUB6
</a>
])
and
documentation
of
any
legal
commitments
W3C
has
with
other
entities.
</li>
<li>
The
Process
Document.
</li>
<li>
Public
results
of
W3C
activities
and
<a href="#GAEvents">
Workshops
</a>.
</li>
</ul>
<p>
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
<a href="https://www.w3.org/participate/eventscal">
calendar
</a>
[
<a href="#ref-calendar">
<del class="diff-old">MEM3
</del>
<ins class="diff-chg">PUB36
</ins>
</a>
]
of
official
W3C
events.
Members
are
encouraged
to
send
schedule
and
event
information
to
the
Team
for
inclusion
on
this
calendar.
</p>
<h3>
4.1
Confidentiality
Levels
</h3>
<p>
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.
</p>
<p>
While
much
information
made
available
by
W3C
is
public,
<dfn id="Member-only">
"Member-only"
information
</dfn>
is
available
to
authorized
parties
only,
including
representatives
of
Member
organizations,
<a href="#invited-expert-wg">
Invited
Experts
</a>,
the
Advisory
Board,
the
TAG,
and
the
Team.
For
example,
the
<a href="#WGCharter">
charter
</a>
of
some
Working
Groups
may
specify
a
Member-only
confidentiality
level
for
group
proceedings.
</p>
<p id="Team-only">
"Team-only"
information
is
available
to
the
Team
and
other
authorized
parties.
</p>
<p>
Those
authorized
to
access
Member-only
and
Team-only
information:
</p>
<ul>
<li>
<em class="rfc2119">
must
</em>
treat
the
information
as
confidential
within
W3C,
</li>
<li>
<em class="rfc2119">
must
</em>
use
reasonable
efforts
to
maintain
the
proper
level
confidentiality,
and
</li>
<li>
<em class="rfc2119">
must
not
</em>
release
this
information
to
the
general
public
or
press.
</li>
</ul>
<p>
The
Team
<em class="rfc2119">
must
</em>
provide
mechanisms
to
protect
the
confidentiality
of
Member-only
information
and
ensure
that
authorized
parties
have
proper
access
to
this
information.
Documents
<em class="rfc2119">
should
</em>
clearly
indicate
whether
they
require
Member-only
confidentiality.
Individuals
uncertain
of
the
confidentiality
level
of
a
piece
of
information
<em class="rfc2119">
should
</em>
contact
the
Team.
</p>
<p>
Advisory
Committee
representatives
<em class="rfc2119">
may
</em>
authorize
Member-only
access
to
<a href="#member-rep">
Member
representatives
</a>
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
<a href="https://www.w3.org/Member/Intro">
New
Member
Orientation
</a>.
</p>
<h4 id="confidentiality-change">
4.1.1
Changing
Confidentiality
Level
</h4>
<p>
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
<a href="#ACReview">
reviews
</a>
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
<em class="rfc2119">
may
</em>
need
to
communicate
Team-only
information
to
a
Working
Group
or
the
public.
Similarly,
a
Working
Group
whose
proceedings
are
Member-only
<em class="rfc2119">
must
</em>
make
public
information
pertinent
to
the
technical
report
development
process.
</p>
<p>
This
document
clearly
indicates
which
information
<em class="rfc2119">
must
</em>
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
change
the
level
of
confidentiality
of
this
information.
When
doing
so:
</p>
<ol>
<li>
The
Team
<em class="rfc2119">
must
</em>
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
<em class="rfc2119">
should
</em>
remind
recipients
to
provide
such
alternatives.
</li>
<li>
The
Team
<em class="rfc2119">
must
not
</em>
attribute
the
version
for
the
new
confidentiality
level
to
the
author
without
the
author's
consent.
</li>
<li>
If
the
author
has
not
conveyed
to
the
Team
a
version
that
is
suitable
for
another
confidentiality
level,
the
Team
<em class="rfc2119">
may
</em>
make
available
a
version
that
reasonably
communicates
what
is
required,
while
respecting
the
original
level
of
confidentiality,
and
without
attribution
to
the
original
author.
</li>
</ol>
</section>
<section id="ChapterGroups">
<h2 id="GAGeneral">
5
Working
Groups
and
Interest
Groups
</h2>
<p id="GAGroups">
This
document
defines
two
types
of
groups:
</p>
<ol>
<li>
<a href="#GroupsWG">
Working
Groups.
</a>
Working
Groups
typically
produce
deliverables
(e.g.,
<a href="#rec-advance">
Recommendation
Track
technical
reports
</a>,
software,
test
suites,
and
reviews
of
the
deliverables
of
other
groups).
There
are
additional
participation
requirements
described
in
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</li>
<li>
<a href="#GroupsIG">
Interest
Groups.
</a>
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.
</li>
</ol>
<p>
Interest
Groups
do
not
publish
<a href="#RecsW3C">
Recommendation
Track
technical
reports
</a>
;
see
information
about
<a href="#WGNote">
maturity
levels
for
Interest
Groups
</a>.
</p>
<h3 id="ReqsAllGroups">
5.1
Requirements
for
All
Working
and
Interest
Groups
</h3>
<p>
Each
group
<em class="rfc2119">
must
</em>
have
a
charter.
Requirements
for
the
charter
depend
on
the
group
type.
All
group
charters
<em class="rfc2119">
must
</em>
be
public
(even
if
other
proceedings
of
the
group
are
<a href="#Member-only">
Member-only
</a>
).
<del class="diff-old">Existing
charters
that
are
not
yet
public
must
be
made
public
when
next
revised
or
extended
(with
attention
to
changing
confidentiality
level
).
</del>
</p>
<p>
Each
group
<em class="rfc2119">
must
</em>
have
a
<dfn id="GeneralChairs">
Chair
</dfn>
(or
co-Chairs)
to
coordinate
the
group's
tasks.
The
Director
appoints
(and
re-appoints)
Chairs
for
all
groups.
The
Chair
is
a
<a href="#member-rep">
Member
representative
</a>,
a
<a href="#Team">
Team
representative
</a>,
or
an
<a href="#invited-expert-wg">
Invited
Expert
</a>
(invited
by
the
Director).
The
requirements
of
this
document
that
apply
to
those
types
of
participants
apply
to
Chairs
as
well.
The
<a href="/Guide/chair-roles">
role
of
the
Chair
<del class="diff-old">[MEM14]
</del>
</a>
is
described
in
the
<del class="diff-old">Member
guide
</del>
<a href="https://www.w3.org/Guide/">
<ins class="diff-chg">Art
of
Consensus
</ins>
</a>
[
<a href="#ref-guide">
<del class="diff-old">MEM9
</del>
<ins class="diff-chg">PUB37
</ins>
</a>
].
</p>
<p>
Each
group
<em class="rfc2119">
must
</em>
have
a
<dfn id="TeamContact">
Team
Contact
</dfn>,
who
acts
as
the
interface
between
the
Chair,
group
participants,
and
the
rest
of
the
Team.
The
<a href="/Guide/staff-contact">
role
of
the
Team
Contact
</a>
is
described
in
the
Member
guide.
The
Chair
and
the
Team
Contact
of
a
group
<em class="rfc2119">
should
not
</em>
be
the
same
individual.
</p>
<p>
Each
group
<em class="rfc2119">
must
</em>
have
an
archived
mailing
list
for
formal
group
communication
(e.g.,
for
meeting
announcements
and
minutes,
documentation
of
decisions,
and
<a href="#FormalObjection">
Formal
Objections
</a>
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
<a href="https://www.w3.org/Member/Mail/">
group
mailing
lists
</a>
[
<a href="#ref-mailing-lists">
MEM2
</a>
].
</p>
<p>
A
Chair
<em class="rfc2119">
may
</em>
form
task
forces
(composed
of
group
participants)
to
carry
out
assignments
for
the
group.
The
scope
of
these
assignments
<em class="rfc2119">
must
not
</em>
exceed
the
scope
of
the
group's
charter.
A
group
<em class="rfc2119">
should
</em>
document
the
process
it
uses
to
create
task
forces
(e.g.,
each
task
force
might
have
an
informal
"charter").
Task
forces
do
not
publish
<a href="#Reports">
technical
reports
</a>
;
the
Working
Group
<em class="rfc2119">
may
</em>
choose
to
publish
their
results
as
part
of
a
technical
report.
</p>
<h3>
5.2
<dfn id="GroupsWG">
Working
Groups
</dfn>
and
<dfn id="GroupsIG">
Interest
Groups
</dfn>
</h3>
<p>
Although
Working
Groups
and
Interest
Groups
have
different
purposes,
they
share
some
characteristics,
and
so
are
defined
together
in
the
following
sections.
</p>
<h4>
5.2.1
<dfn id="group-participation">
Working
Group
and
Interest
Group
Participation
Requirements
</dfn>
</h4>
<p>
There
are
three
types
of
individual
<dfn id="wgparticipant">
participants
in
a
Working
Group
</dfn>:
<a href="#member-rep">
Member
representatives
</a>,
<a href="#invited-expert-wg">
Invited
Experts
</a>,
and
<a href="#Team">
Team
representatives
</a>
(including
the
<a href="#TeamContact">
Team
Contact
</a>
).
</p>
<p>
There
are
four
types
of
individual
<dfn id="igparticipant">
participants
in
an
Interest
Group
</dfn>:
the
same
three
types
as
for
Working
Groups
plus,
for
an
Interest
Group
where
the
only
<a href="#ig-mail-only">
participation
requirement
is
mailing
list
subscription
</a>,
<dfn id="public-participant-ig">
public
participants
</dfn>.
</p>
<p>
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
<a href="#ParticipationCriteria">
individual
participation
criteria
</a>.
</p>
<p>
A
participant
<em class="rfc2119">
must
</em>
represent
at
most
one
organization
in
a
Working
Group
or
Interest
Group.
</p>
<p>
An
individual
<em class="rfc2119">
may
</em>
become
a
Working
or
Interest
Group
participant
at
any
time
during
the
group's
existence.
See
also
relevant
requirements
in
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-join">
section
4.3
</a>
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<p>
On
an
exceptional
basis,
a
Working
or
Interest
Group
participant
<em class="rfc2119">
may
</em>
designate
a
<dfn id="mtg-substitute">
substitute
</dfn>
to
attend
a
<a href="#GeneralMeetings">
meeting
</a>
and
<em class="rfc2119">
should
</em>
inform
the
Chair.
The
substitute
<em class="rfc2119">
may
</em>
act
on
behalf
of
the
participant,
including
for
<a href="#Votes">
votes
</a>.
For
the
substitute
to
vote,
the
participant
<em class="rfc2119">
must
</em>
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
<em class="rfc2119">
should
</em>
authorize
another
participant
to
act
as
<a href="#proxy">
proxy
</a>
for
votes.
</p>
<p>
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
<em class="rfc2119">
may
</em>
split
it
into
an
Interest
Group
(a
discussion
forum)
and
a
much
smaller
Working
Group
(a
core
group
of
highly
dedicated
participants).
</p>
<p>
See
also
the
licensing
obligations
on
Working
Group
participants
in
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Obligations">
section
3
</a>
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
],
and
the
patent
claim
exclusion
process
of
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">
section
4
</a>.
</p>
<h5>
5.2.1.1
<dfn id="member-rep-wg">
Member
Representative
</dfn>
in
a
Working
Group
</h5>
<p>
An
individual
is
a
Member
representative
in
a
Working
Group
if
all
of
the
following
conditions
are
satisfied:
</p>
<ul>
<li>
the
Advisory
Committee
representative
of
the
Member
in
question
has
designated
the
individual
as
a
Working
Group
participant,
and
</li>
<li>
the
individual
qualifies
for
<a href="#member-rep">
Member
representation
</a>.
</li>
</ul>
<p>
<dfn id="member-rep-info">
To
designate
an
individual
as
a
Member
representative
in
a
Working
Group
</dfn>,
an
Advisory
Committee
representative
<em class="rfc2119">
must
</em>
provide
the
Chair
and
Team
Contact
with
all
of
the
following
information,
in
addition
to
any
other
information
required
by
the
<a href="#cfp">
Call
for
Participation
</a>
and
charter
(including
the
participation
requirements
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
]):
</p>
<ol>
<li>
The
name
of
the
W3C
Member
the
individual
represents
and
whether
the
individual
is
an
employee
of
that
Member
organization;
</li>
<li>
A
statement
that
the
individual
accepts
the
participation
terms
set
forth
in
the
charter
(with
an
indication
of
charter
date
or
version);
</li>
<li>
A
statement
that
the
Member
will
provide
the
necessary
financial
support
for
participation
(e.g.,
for
travel,
telephone
calls,
and
conferences).
</li>
</ol>
<p>
A
Member
participates
in
a
Working
Group
from
the
moment
the
first
Member
representative
joins
the
group
until
either
of
the
following
occurs:
</p>
<ul>
<li>
the
group
closes,
or
</li>
<li>
the
Member
<a href="#resignation">
resigns
</a>
from
the
Working
Group;
this
is
done
through
the
Member's
Advisory
Committee
representative.
</li>
</ul>
<h5>
5.2.1.2
<dfn id="member-rep-ig">
Member
Representative
</dfn>
in
an
Interest
Group
</h5>
<p>
When
the
participation
requirements
exceed
<a href="#ig-mail-only">
Interest
Group
mailing
list
subscription
</a>,
an
individual
is
a
Member
representative
in
an
Interest
Group
if
all
of
the
following
conditions
are
satisfied:
</p>
<ul>
<li>
the
Advisory
Committee
representative
of
the
Member
in
question
has
designated
the
individual
as
an
Interest
Group
participant,
and
</li>
<li>
the
individual
qualifies
for
<a href="#member-rep">
Member
representation
</a>.
</li>
</ul>
<p>
To
designate
an
individual
as
a
Member
representative
in
an
Interest
Group,
the
Advisory
Committee
representative
<em class="rfc2119">
must
</em>
follow
the
instructions
in
the
<a href="#cfp">
Call
for
Participation
</a>
and
charter.
</p>
<p>
Member
participation
in
an
Interest
Group
ceases
under
the
same
conditions
as
for
a
Working
Group.
</p>
<h5>
5.2.1.3
<dfn id="invited-expert-wg">
Invited
Expert
in
a
Working
Group
</dfn>
</h5>
<p>
The
Chair
<em class="rfc2119">
may
</em>
invite
an
individual
with
a
particular
expertise
to
participate
in
a
Working
Group.
This
individual
<em class="rfc2119">
may
</em>
represent
an
organization
in
the
group
(e.g.,
if
acting
as
a
liaison
with
another
organization).
</p>
<p>
An
individual
is
an
Invited
Expert
in
a
Working
Group
if
all
of
the
following
conditions
are
satisfied:
</p>
<ul>
<li>
the
Chair
has
designated
the
individual
as
a
group
participant,
</li>
<li>
the
Team
Contact
has
agreed
with
the
Chair's
choice,
and
</li>
<li>
the
individual
has
provided
the
<a href="#inv-expert-info">
information
required
of
an
Invited
Expert
</a>
to
the
Chair
and
Team
Contact.
</li>
</ul>
<p>
To
designate
an
individual
as
an
Invited
Expert
in
a
Working
Group,
the
Chair
<em class="rfc2119">
must
</em>
inform
the
Team
Contact
and
provide
rationale
for
the
choice.
When
the
Chair
and
the
Team
Contact
disagree
about
a
designation,
the
<a href="#def-Director">
Director
</a>
determines
whether
the
individual
will
be
invited
to
participate
in
the
Working
Group.
</p>
<p>
<dfn id="inv-expert-info">
To
be
able
to
participate
in
a
Working
Group
as
an
Invited
Expert
</dfn>,
an
individual
<em class="rfc2119">
must
</em>
do
all
of
the
following:
</p>
<ul>
<li>
identify
the
organization,
if
any,
the
individual
represents
as
a
participant
in
this
group,
</li>
<li>
agree
to
the
terms
of
the
<a href="https://www.w3.org/Consortium/Legal/collaborators-agreement">
invited
expert
and
collaborators
agreement
</a>
[
<a href="#ref-invited-expert">
PUB17
</a>
],
</li>
<li>
accept
the
participation
terms
set
forth
in
the
charter
(including
the
participation
requirements
of
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Obligations">
section
3
</a>
(especially
3.4)
and
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">
section
6
</a>
(especially
6.10)
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
<del class="diff-old">]).
Indicate
</del>
<ins class="diff-chg">]),
indicating
</ins>
a
specific
charter
date
or
version,
</li>
<li>
disclose
whether
the
individual
is
an
employee
of
a
W3C
Member;
see
the
<a href="#coi">
conflict
of
interest
policy
</a>,
</li>
<li>
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
</li>
<li>
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.
</li>
</ul>
<p>
The
Chair
<em class="rfc2119">
should
not
</em>
designate
as
an
Invited
Expert
in
a
Working
Group
an
individual
who
is
an
employee
of
a
W3C
Member.
The
Chair
<em class="rfc2119">
must
not
</em>
use
Invited
Expert
status
to
circumvent
participation
limits
imposed
by
the
<a href="#WGCharter">
charter
</a>.
</p>
<p>
An
Invited
Expert
participates
in
a
Working
Group
from
the
moment
the
individual
joins
the
group
until
any
of
the
following
occurs:
</p>
<ul>
<li>
the
group
closes,
or
</li>
<li>
the
Chair
or
Director
withdraws
the
invitation
to
participate,
or
</li>
<li>
the
individual
<a href="#resignation">
resigns
</a>.
</li>
</ul>
<h5>
5.2.1.4
<dfn id="invited-expert-ig">
Invited
Expert
in
an
Interest
Group
</dfn>
</h5>
<p>
When
the
participation
requirements
exceed
<a href="#ig-mail-only">
Interest
Group
mailing
list
subscription
</a>,
the
participation
requirements
for
an
Invited
Expert
in
an
Interest
Group
are
the
same
as
those
for
an
<a href="#invited-expert-wg">
Invited
Expert
in
a
Working
Group
</a>.
</p>
<h5>
5.2.1.5
<dfn id="team-rep-wg">
Team
Representative
in
a
Working
Group
</dfn>
</h5>
<p>
An
individual
is
a
Team
representative
in
a
Working
Group
when
so
designated
by
W3C
management.
</p>
<p>
A
Team
representative
participates
in
a
Working
Group
from
the
moment
the
individual
joins
the
group
until
any
of
the
following
occurs:
</p>
<ul>
<li>
the
group
closes,
or
</li>
<li>
W3C
management
changes
Team
representation
by
sending
email
to
the
Chair,
cc'ing
the
group
mailing
list.
</li>
</ul>
<p>
The
Team
participates
in
a
Working
Group
from
the
moment
the
Director
announces
the
creation
of
the
group
until
the
group
closes.
</p>
<h5>
5.2.1.6
<dfn id="team-rep-ig">
Team
Representative
in
an
Interest
Group
</dfn>
</h5>
<p>
When
the
participation
requirements
exceed
<a href="#ig-mail-only">
Interest
Group
mailing
list
subscription
</a>,
an
individual
is
a
Team
representative
in
an
Interest
Group
when
so
designated
by
W3C
management.
</p>
<h4>
5.2.2
<dfn id="WGCharterDevelopment">
Working
Group
and
Interest
Group
Charter
Development
</dfn>
</h4>
<p>
W3C
creates
a
charter
based
on
interest
from
the
Members
and
Team.
The
Team
<em class="rfc2119">
must
</em>
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
<em class="rfc2119">
may
</em>
provide
feedback
on
the
<a href="#ACCommunication">
Advisory
Committee
discussion
list
</a>.
</p>
<p>
W3C
<em class="rfc2119">
may
</em>
begin
work
on
a
Working
Group
or
Interest
Group
charter
at
any
time.
</p>
<h4>
5.2.3
<dfn id="CharterReview">
Advisory
Committee
Review
of
a
Working
Group
or
Interest
Group
Charter
</dfn>
</h4>
<p>
The
Director
<em class="rfc2119">
must
</em>
solicit
<a href="#ACReview">
Advisory
Committee
review
</a>
of
every
new
or
substantively
modified
Working
Group
or
Interest
Group
charter.
The
Director
is
<em class="rfc2119">
not
required
</em>
to
solicit
Advisory
Committee
review
prior
to
a
charter
extension
or
for
minor
changes.
The
review
period
<em class="rfc2119">
must
</em>
be
at
least
four
weeks.
</p>
<p>
The
Director's
Call
for
Review
of
a
substantively
modified
charter
<em class="rfc2119">
must
</em>
highlight
important
changes
(e.g.,
regarding
deliverables
or
resource
allocation)
and
include
rationale
for
the
changes.
</p>
<p>
<ins class="diff-new">Transition
requests
to
First
Public
Working
Draft
or
</ins><a href="#last-call"><ins class="diff-new">
Candidate
Recommendation
</ins></a><ins class="diff-new">
will
not
normally
be
approved
while
a
Working
Group's
charter
is
undergoing,
or
awaiting
a
Director's
decision
on,
an
Advisory
Committee
Review,
until
the
Director
issues
a
Call
for
Participation
for
the
Working
Group.
</ins></p>
<h4>
5.2.4
<dfn id="cfp">
Call
for
Participation
in
a
Working
Group
or
Interest
Group
</dfn>
</h4>
<p>
After
Advisory
Committee
review
of
a
Working
Group
or
Interest
Group
charter,
the
Director
<em class="rfc2119">
may
</em>
issue
a
Call
for
Participation
to
the
Advisory
Committee.
Charters
<em class="rfc2119">
may
</em>
be
amended
based
on
review
comments
before
the
Director
issues
a
Call
for
Participation.
</p>
<p>
For
a
new
group,
this
announcement
officially
creates
the
group.
The
announcement
<em class="rfc2119">
must
</em>
include
a
reference
to
the
<a href="#WGCharter">
charter
</a>,
the
name(s)
of
the
group's
<a href="#GeneralChairs">
Chair(s)
</a>,
and
the
<del class="diff-old">name
</del>
<ins class="diff-chg">name(s)
</ins>
of
the
<a href="#TeamContact">
Team
<del class="diff-old">Contact
</del>
<ins class="diff-chg">Contact(s)
</ins>
</a>.
</p>
<p>
After
a
Call
for
Participation,
any
<a href="#member-rep">
Member
representatives
</a>
and
<a href="#invited-expert-wg">
Invited
Experts
</a>
<em class="rfc2119">
must
</em>
be
designated
(or
re-designated).
</p>
<p>
Advisory
Committee
representatives
<em class="rfc2119">
may
</em>
<ins class="diff-new">initiate
an
</ins>
<a href="#ACAppeal">
<del class="diff-old">appeal
</del>
<ins class="diff-chg">Advisory
Committee
Appeal
</ins>
</a>
<del class="diff-old">creation
</del>
<ins class="diff-chg">against
a
Director's
decision
to
create
</ins>
or
<del class="diff-old">substantive
modification
of
</del>
<ins class="diff-chg">substantially
modify
</ins>
a
Working
Group
or
Interest
Group
charter.
</p>
<h4>
5.2.5
<dfn id="charter-extension">
Working
Group
and
Interest
Group
Charter
Extension
</dfn>
</h4>
<p>
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
<em class="rfc2119">
must
</em>
indicate
the
new
duration.
The
announcement
<em class="rfc2119">
must
</em>
also
include
rationale
for
the
extension,
a
reference
to
the
<a href="#WGCharter">
charter
</a>,
the
name(s)
of
the
group's
<a href="#GeneralChairs">
Chair(s)
</a>,
the
name
of
the
<a href="#TeamContact">
Team
Contact
</a>,
and
instructions
for
joining
the
group.
</p>
<p>
After
a
charter
extension,
Advisory
Committee
representatives
and
the
Chair
are
<em class="rfc2119">
not
required
</em>
to
re-designate
<a href="#member-rep">
Member
representatives
</a>
and
<a href="#invited-expert-wg">
Invited
Experts
</a>.
</p>
<p>
Advisory
Committee
representatives
<em class="rfc2119">
may
</em>
<ins class="diff-new">initiate
an
</ins>
<a href="#ACAppeal">
<del class="diff-old">appeal
</del>
<ins class="diff-chg">Advisory
Committee
Appeal
</ins>
</a>
<ins class="diff-new">against
a
Director's
decision
regarding
</ins>
the
extension
of
a
Working
Group
or
Interest
Group
charter.
</p>
<h4>
5.2.6
<dfn id="WGCharter">
Working
Group
and
Interest
Group
Charters
</dfn>
</h4>
<p>
A
Working
Group
or
Interest
Group
charter
<em class="rfc2119">
must
</em>
include
all
of
the
following
information.
</p>
<ul>
<li>
The
group's
mission
(e.g.,
develop
a
technology
or
process,
review
the
work
of
other
groups);
</li>
<li>
The
scope
of
the
group's
work
and
criteria
for
success;
</li>
<li>
The
duration
of
the
group
(typically
from
six
months
to
two
years);
</li>
<li>
The
nature
of
any
deliverables
(technical
reports,
reviews
of
the
deliverables
of
other
groups,
or
<del class="diff-old">software),
expected
milestones,
and
the
process
for
the
group
participants
to
approve
the
release
of
these
deliverables
(including
public
intermediate
results).
</del>
<ins class="diff-chg">software);
</ins></li><li><ins class="diff-chg">
Expected
milestone
dates
where
available.
</ins><strong><ins class="diff-chg">
Note
</ins></strong>:
A
charter
is
<em class="rfc2119">
not
required
</em>
to
include
<del class="diff-old">the
schedule
</del>
<ins class="diff-chg">schedules
</ins>
for
<del class="diff-old">a
</del>
review
of
<del class="diff-old">another
</del>
<ins class="diff-chg">other
</ins>
group's
deliverables;
</li>
<li>
<ins class="diff-new">The
process
for
the
group
participants
to
approve
the
release
of
deliverables
(including
intermediate
results);
</ins></li><li>
Any
dependencies
by
groups
within
or
outside
of
W3C
on
the
deliverables
of
this
group.
For
any
dependencies,
the
charter
<em class="rfc2119">
must
</em>
specify
the
mechanisms
for
communication
about
the
deliverables;
</li>
<li>
Any
dependencies
of
this
group
on
other
groups
within
or
outside
of
W3C.
Such
dependencies
include
interactions
with
<a href="https://www.w3.org/Guide/Charter.html#horizontal-review">
W3C
Horizontal
Groups
</a>
;
</li>
<li>
The
<a href="#confidentiality-levels">
level
of
confidentiality
</a>
of
the
group's
proceedings
and
deliverables;
</li>
<li>
Meeting
mechanisms
and
expected
frequency;
</li>
<li>
If
known,
the
date
of
the
first
<a href="#ftf-meeting">
face-to-face
meeting
</a>.
The
date
of
the
first
face-to-face
meeting
of
a
proposed
group
<em class="rfc2119">
must
not
</em>
be
sooner
than
<span class="time-interval">
eight
weeks
</span>
after
the
date
of
the
proposal.
</li>
<li>
Communication
mechanisms
to
be
employed
within
the
group,
between
the
group
and
the
rest
of
W3C,
and
with
the
general
public;
</li>
<li>
An
estimate
of
the
expected
time
commitment
from
participants;
</li>
<li>
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).
</li>
<li>
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
of
section
2
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
]?
</li>
</ul>
<p>
See
also
the
charter
requirements
of
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Licensing">
section
2
</a>
and
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Obligations">
section
3
</a>
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
<ins class="diff-chg">W3C
Patent
Policy
</ins></a><ins class="diff-chg">
[
</ins><a href="#ref-patentpolicy"><ins class="diff-chg">
PUB33
</ins></a><ins class="diff-chg">
].
</ins></p><p><ins class="diff-chg">
For
every
Recommendation
Track
deliverable
that
continues
work
on
a
Working
Draft
(WD)
published
under
any
other
Charter
(including
a
predecessor
group
of
the
same
name),
for
which
there
is
an
existing
Reference
Draft
or
Candidate
Recommendation,
the
description
of
that
deliverable
in
the
proposed&#160;charter
of
the
adopting
Working
Group
</ins><em class="rfc2119"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
provide
the
following
information:
</ins></p><ul><li><ins class="diff-chg">
The
title,
stable
URL,
and
publication
date
of
the
</ins><dfn><ins class="diff-chg">
Adopted
Working
Draft
</ins></dfn><ins class="diff-chg">
which
will
serve
as
the
basis
for
work
on
the
deliverable
</ins></li><li><ins class="diff-chg">
The
title,
stable
URL,
and
publication
date
of
the
most
recent
Reference
Draft
or
</ins><a href="#last-call"><ins class="diff-chg">
Candidate
Recommendation
</ins></a><ins class="diff-chg">
which
triggered
an
Exclusion
Opportunity
per
the
Patent
Process
</ins></li><li><ins class="diff-chg">
The
stable
URL
of
the
Working
Group
charter
under
which
the
most
recent
Reference
Draft
or
Candidate
Recommendation
was
published.
</ins></li></ul><p><ins class="diff-chg">
These
data
</ins><em class="rfc2119"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
be
identified
in
the
charter
with
the
labels
"Adopted
Working
Draft",
"most
recent
Reference
Draft",
"most
recent
Candidate
Recommendation",
and
"Other
Charter",
respectively.
</ins></p><p><ins class="diff-chg">
The
</ins><dfn><ins class="diff-chg">
Reference
Draft
</ins></dfn><ins class="diff-chg">
is
the
latest
Working
Draft
published
within
90
days
of
the
</ins><a href="#first-wd"><ins class="diff-chg">
First
Public
Working
Draft
</ins></a><ins class="diff-chg">
or
if
no
Public
Working
Draft
has
been
published
within
90
days
of
the
First
Public
Working
Draft
it
is
that
First
Public
Working
Draft.
It
is
the
specific
draft
against
which
exclusions
are
made,
as
per
</ins><a href="https://www.w3.org/Consortium/Patent-Policy/#sec-exclusion-with"><ins class="diff-chg">
section
4.1
</ins></a><ins class="diff-chg">
of
the
</ins><a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<p>
<ins class="diff-new">The
Adopted
Working
Draft
and
the
most
recent
Reference
Draft
or
</ins><a href="#last-call"><ins class="diff-new">
Candidate
Recommendation
</ins></a><em class="rfc2119"><ins class="diff-new">
must
</ins></em><ins class="diff-new">
each
be
adopted
in
their
entirety
and
without
any
modification.
The
proposed
charter
</ins><em class="rfc2119"><ins class="diff-new">
must
</ins></em><ins class="diff-new">
state
that
the
most
recent
Reference
Draft
or
Candidate
Recommendation
is
deemed
to
be
the
Reference
Draft
or
Candidate
Recommendation
of
the
Adopted
Working
Draft,
and
the
date
when
the
Exclusion
Opportunity
that
arose
on
publishing
the
First
Public
Working
Draft
or
Candidate
Recommendation
began
and
ended.
As
per
</ins><a href="https://www.w3.org/Consortium/Patent-Policy/#sec-join"><ins class="diff-new">
section
4.3
</ins></a><ins class="diff-new">
of
the
</ins><a href="https://www.w3.org/Consortium/Patent-Policy"><ins class="diff-new">
W3C
Patent
Policy
</ins></a><ins class="diff-new">
[
</ins><a href="#ref-patentpolicy"><ins class="diff-new">
PUB33
</ins></a><ins class="diff-new">
],
this
potentially
means
that
exclusions
can
only
be
made
immediately
on
joining
a
Working
Group.
</ins></p>
<p id="ig-charter-participation">
An
Interest
Group
charter
<em class="rfc2119">
may
</em>
include
provisions
regarding
participation,
including
specifying
that
the
<dfn id="ig-mail-only">
only
requirement
for
participation
(by
anyone)
in
the
Interest
Group
is
subscription
to
the
Interest
Group
mailing
list
</dfn>.
This
type
of
Interest
Group
<em class="rfc2119">
may
</em>
have
<a href="#public-participant-ig">
public
participants
</a>.
</p>
<p>
A
charter
<em class="rfc2119">
may
</em>
include
additional
voting
procedures,
but
those
procedures
<em class="rfc2119">
must
not
</em>
conflict
with
the
<a href="#Votes">
voting
requirements
</a>
of
the
Process
Document.
</p>
<p>
A
charter
<em class="rfc2119">
may
</em>
include
provisions
other
than
those
required
by
this
document.
The
charter
<em class="rfc2119">
should
</em>
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
<a href="#MemberRelated">
related
Members
</a>
).
</p>
<h4>
<del class="diff-old">5.2.8
</del>
<ins class="diff-chg">5.2.7
</ins>
<dfn id="GeneralTermination">
Working
Group
and
Interest
Group
Closure
</dfn>
</h4>
<p>
A
Working
Group
or
Interest
Group
charter
specifies
a
duration
for
the
group.
The
Director,
subject
to
<ins class="diff-new">an
</ins>
<a href="#ACAppeal">
<del class="diff-old">appeal
</del>
<ins class="diff-chg">Advisory
Committee
Appeal
</ins>
</a>
<ins class="diff-new">initiated
</ins>
by
Advisory
Committee
representatives,
<em class="rfc2119">
may
</em>
<ins class="diff-new">decide
to
</ins>
close
a
group
prior
to
the
date
specified
in
the
charter
in
any
of
the
following
circumstances:
</p>
<ul>
<li>
There
are
insufficient
resources
to
produce
chartered
deliverables
or
to
maintain
the
group,
according
to
priorities
established
within
W3C.
</li>
<li>
The
group
produces
chartered
deliverables
ahead
of
schedule.
</li>
</ul>
<p>
The
Director
closes
a
Working
Group
or
Interest
Group
by
announcement
to
the
Advisory
Committee.
</p>
<p>
Closing
a
Working
Group
has
implications
with
respect
to
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
</section>
<h2 id="Reports">
6
W3C
Technical
Report
Development
Process
</h2>
<p>
The
W3C
technical
report
development
process
is
the
set
of
steps
and
requirements
followed
by
W3C
<a href="#GroupsWG">
Working
Groups
</a>
to
standardize
Web
technology.
The
W3C
technical
report
development
process
is
designed
<del class="diff-old">to
</del>
<ins class="diff-chg">to:
</ins>
</p>
<ul>
<li>
support
multiple
specification
development
methodologies
</li>
<li>
maximize
<a href="#def-Consensus" rel="glossary" title="Definition of Consensus">
<span class="dfn-instance">
consensus
</span>
</a>
about
the
content
of
stable
technical
reports
</li>
<li>
ensure
high
technical
and
editorial
quality
</li>
<li>
promote
consistency
among
specifications
</li>
<li>
facilitate
royalty-free,
interoperable
implementations
of
Web
Standards,
and
</li>
<li>
earn
endorsement
by
W3C
and
the
broader
community.
</li>
</ul>
<p>
See
also
the
licensing
goals
for
W3C
Recommendations
in
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Licensing">
section
2
</a>
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<h3 id="rec-advance">
6.1
W3C
Technical
Reports
</h3>
<p>
Please
note
that
<dfn>
publishing
</dfn>
as
used
in
this
document
refers
to
producing
a
version
which
is
listed
as
a
W3C
Technical
Report
on
its
<a href="https://www.w3.org/TR/">
Technical
Reports
page
<del class="diff-old">http://www.w3.org/TR
</del>
<ins class="diff-chg">https://www.w3.org/TR
</ins>
</a>.
</p>
<p>
This
chapter
describes
the
formal
requirements
for
publishing
and
maintaining
a
W3C
Recommendation
or
Note.
</p>
<p>
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
<a href="#last-call">
Candidate
Recommendation
</a>
phase.
This
allows
the
entire
W3C
membership
to
provide
feedback
on
whether
the
specification
is
appropriate
as
a
W3C
Recommendation,
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
<del class="diff-old">member
</del>
<ins class="diff-chg">Member
</ins>
review
supports
a
specification
becoming
a
standard,
W3C
publishes
it
as
a
Recommendation.
</p>
<p>
Groups
may
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.
</p>
<p>
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.
</p>
<p>
Individual
Working
Groups
and
Interest
Groups
may
adopt
additional
processes
for
developing
publications,
so
long
as
they
do
not
conflict
with
the
requirements
in
this
chapter.
</p>
<h4 id="recs-and-notes">
6.1.1
Recommendations
and
Notes
</h4>
<p>
W3C
follows
these
steps
when
advancing
a
technical
report
to
Recommendation.
</p>
<ol>
<li>
Publication
of
the
<a href="#first-wd">
First
Public
Working
Draft
</a>,
</li>
<li>
Publication
of
zero
or
more
revised
<a href="#revised-wd">
Public
Working
Drafts
</a>.
</li>
<li>
Publication
of
a
<a href="#last-call">
Candidate
Recommendation
</a>.
</li>
<li>
Publication
of
a
<a href="#rec-pr">
Proposed
Recommendation
</a>.
</li>
<li>
Publication
as
a
<a href="#rec-publication">
W3C
Recommendation
</a>.
</li>
<li>
Possibly,
Publication
as
an
<a href="#rec-edited">
Edited
Recommendation
</a>
</li>
</ol>
<p>
</p>
<svg xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" viewbox="0 60 640 140" height="12em" width="60em">
<g id="basicProcess" role="list">
<g id="Rectrac-FPWD" role="listitem" aria-labelledby="Rectrac-fpwd-label Rectrac-fpwd-text">
<a xlink:href="#Rectrac-nodeWD">
</a>
<text font-size="8">
<tspan y="136" x="6">
First
WD
</tspan>
<tspan x="4" y="150">
<ins class="diff-new">WG
Decision
</ins></tspan><tspan x="4" y="158"><ins class="diff-new">
Director's
approval
</ins></tspan>
</text>
<path d="M0,140h53" fill="none" stroke="#000">
</path>
<polygon points="47,136 57,140 47,144">
</polygon>
</g>
<g id="Rectrac-nodeWD" role="list" aria-labelledby="Rectrac-nodewd-label">
<a xlink:href="#RecsWD" aria-labelledby="Rectrac-nodewd-label">
</a>
<ellipse ry="18" rx="38" cy="140" cx="97" stroke="black" fill="#fff">
</ellipse>
<text font-size="14" y="144" x="97" text-anchor="middle">
WD
</text>
<g id="Rectrac-repeatWD" role="listitem">
<a xlink:href="#Rectrac-nodeWD" aria-labelledby="Rectrac-repeatwd-label Rectrac-repeatwd-text">
</a>
<text id="Rectrac-repeatwd-text" font-size="8">
<tspan x="30" y="92">
<ins class="diff-chg">WG
Decision:
review
needed,
or
</ins></tspan><tspan x="40" y="100"><ins class="diff-chg">
No
change
for
6
months
</ins></tspan></text><path d="M78,124C73,114 79,104 97,104 108,104 115,108 117,114" fill="none" stroke="black" stroke-dasharray="6 1">
</path>
<polygon points="120,114 116,124 114,113">
</polygon>
</g>
<g id="Rectrac-toCR" role="listitem" fill="#060">
<a xlink:href="#Rectrac-nodeCR" aria-labelledby="Rectrac-tocr-label Rectrac-tocr-text">
</a>
<text role="none" id="Rectrac-tocr-text" x="138" y="136" font-size="8">
<ins class="diff-chg">Director's
approval
</ins></text><path stroke="#060" d="M135,140h81">
</path>
<polygon points="211,136 221,140 211,144">
</polygon>
</g>
</g>
<g id="Rectrac-nodeCR" role="list" aria-labelledby="Rectrac-nodecr-label">
<a xlink:href="#RecsCR">
</a>
<ellipse ry="18" rx="38" cy="140" cx="260" stroke="black" fill="#fff">
</ellipse>
<text font-size="14" y="144" x="260" text-anchor="middle">
CR
</text>
<a xlink:href="#Rectrac-nodeCR" id="Rectrac-repeatCR" aria-labelledby="Rectrac-repeatcr-label Rectrac-repeatcr-text" fill="#060">
</a>
<text role="none" font-size="8" id="Rectrac-repeatcr-text">
<tspan x="225" y="80">
<ins class="diff-chg">Working
Group
Decision,
</ins></tspan><tspan x="225" y="90"><ins class="diff-chg">
Directors
approval
for
</ins></tspan><tspan x="230" y="100"><ins class="diff-chg">
substantive
changes
</ins></tspan></text><path stroke="#000" d="M242,124C238,114 244,104 260,104 271,104 277,108 279,114" stroke-dasharray="5 11" fill="none">
</path>
<path stroke="#060" d="M242,124C238,114 244,104 260,104 271,104 277,108 279,114" stroke-dasharray="5 11" stroke-dashoffset="8" fill="none">
</path>
<polygon points="282,114 277,124 275,113">
</polygon>
<a xlink:href="#Rectrac-nodePR" id="Rectrac-ToPR" aria-labelledby="Rectrac-topr-label Rectrac-topr-text" fill="#060">
</a>
<text role="none" id="Rectrac-topr-text" x="300" y="136" font-size="8">
<ins class="diff-chg">Director's
approval
</ins></text><path d="M298,140h77" stroke="#060">
</path>
<polygon points="374,136 384,140 374,144">
</polygon>
<a xlink:href="#Rectrac-nodeWD" id="Rectrac-backToWD" aria-labelledby="Rectrac-backtowd-label Rectrac-backtowd-text" fill="#600">
</a>
<text role="none" id="Rectrac-backtowd-text" font-size="8">
<tspan x="142" y="156">
<ins class="diff-chg">WG
or
Director
decision
</ins></tspan><tspan x="144" y="164"><ins class="diff-chg">
e.g.
for
further
review
</ins></tspan></text><path d="M140,147h84" stroke-dasharray="4 4" stroke="#600">
</path>
<polygon points="140,145 133,147 140,149">
</polygon>
</g>
<g id="Rectrac-nodePR" role="list" aria-labelledby="Rectrac-nodepr-label">
<a xlink:href="#RecsPR">
</a>
<ellipse ry="18" rx="28" cy="140" cx="413" stroke="black" fill="#fff">
</ellipse>
<text font-size="14" font-family="Times,serif" y="144" x="413" text-anchor="middle">
PR
</text>
<a xlink:href="#Rectrac-nodeRec" id="Rectrac-ToRec" role="listitem" aria-labelledby="Rectrac-torec-label Rectrac-torec-text" fill="#060">
</a>
<text role="none" id="Rectrac-torec-text" x="300" y="138" font-size="8">
<tspan x="445" y="128">
<ins class="diff-chg">Advisory
Committee
Review
</ins></tspan><tspan x="445" y="136"><ins class="diff-chg">
Director's
Decision
</ins></tspan></text><path d="M441,140h100" stroke="#060">
</path>
<polygon points="534,136 544,140 534,144">
</polygon>
<a xlink:href="#Rectrac-nodeCR" id="Rectrac-BackToCR" role="listitem" aria-labelledby="Rectrac-backtocr-label Rectrac-backtocr-text" fill="#600">
</a>
<text id="Rectrac-backtocr-text" font-size="8">
<tspan x="306" y="156">
<ins class="diff-chg">AC
Review,
</ins></tspan><tspan x="302" y="164"><ins class="diff-chg">
Director
Decision
</ins></tspan><tspan x="304" y="172"><ins class="diff-chg">
e.g.
for
minor
changes
</ins></tspan></text><path d="M301,147h88" stroke-dasharray="3 5" stroke="#600">
</path>
<polygon points="301,145 296,147 301,149">
</polygon>
<a xlink:href="#Rectrac-nodeWD" id="Rectrac-PRBackToWD" role="listitem" aria-labelledby="Rectrac-prbacktowd-label Rectrac-prbacktowd-text" fill="#c00">
</a>
<text role="none" id="Rectrac-prbacktowd-text" font-size="8">
<tspan x="102" y="188">
<ins class="diff-chg">Advisory
Committee
review
and
Director's
Decision,
e.g.
for
further
work
and
review
</ins></tspan></text><path d="M413,158v22h-316v-16" stroke-dasharray="2 2" stroke="#c00" fill="none"></path><polygon points="95,164 97,159 99,164">
</polygon>
</g>
<g id="Rectrac-nodeRec" stroke="black" aria-labelledby="Rectrac-noderec-label" role="list">
<a xlink:href="#RecsW3C" aria-labelledby="Rectrac-noderec-label">
</a>
<ellipse ry="18" rx="28" cy="140" cx="573" fill="#fff" stroke-width="2">
</ellipse>
<text font-size="16" y="144" x="573" text-anchor="middle" stroke-width=".3">
REC
</text>
</g>
</g>
</svg>
<p>
<p>
W3C
<em class="rfc2119">
may
</em>
<a href="#tr-end">
end
work
on
a
technical
report
</a>
at
any
time.
</p>
<p>
The
Director
<em class="rfc2119">
may
</em>
decline
a
request
to
advance
in
maturity
level,
requiring
a
Working
Group
to
conduct
further
work,
and
<em class="rfc2119">
may
</em>
require
the
specification
to
return
to
a
lower
<a href="#maturity-levels">
maturity
level
</a>.
The
Director
<em class="rfc2119">
must
</em>
inform
the
<a href="#AC">
Advisory
Committee
</a>
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.
</p>
<h4 id="maturity-levels">
6.1.2
Maturity
Levels
</h4>
<dl>
<dt id="RecsWD">
Working
Draft
(WD)
</dt>
<dd>
A
Working
Draft
is
a
document
that
W3C
has
published
for
review
by
the
community,
including
W3C
Members,
the
public,
and
other
technical
organizations.
Some,
but
not
all,
Working
Drafts
are
meant
to
advance
to
Recommendation;
see
the
<a href="#DocumentStatus">
document
status
section
</a>
of
a
Working
Draft
for
the
group's
expectations.
Any
Working
Draft
not,
or
no
longer,
intended
to
advance
to
Recommendation
<em class="rfc2119">
should
</em>
be
published
as
a
Working
Group
Note.
Working
Drafts
do
not
necessarily
represent
a
consensus
of
the
Working
Group,
and
do
not
imply
any
endorsement
by
W3C
or
its
members
beyond
agreement
to
work
on
a
general
area
of
technology.
</dd>
<dt id="RecsCR">
Candidate
Recommendation
(CR)
</dt>
<dd class="changed">
A
Candidate
Recommendation
is
a
document
that
satisfies
the
Working
Group's
technical
requirements,
and
has
already
received
wide
review.
W3C
publishes
a
Candidate
Recommendation
to
<ul>
<li>
signal
to
the
wider
community
that
it
is
time
to
do
a
final
review
</li>
<li>
gather
<a href="#implementation-experience">
implementation
experience
</a>
</li>
<li>
begin
formal
review
by
the
Advisory
Committee,
who
<em class="rfc2119">
may
</em>
recommend
that
the
document
be
published
as
a
W3C
Recommendation,
returned
to
the
Working
Group
for
further
work,
or
abandoned.
</li>
<li>
Provide
an
exclusion
opportunity
<del class="diff-old">as
</del>
per
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
A
Candidate
Recommendation
under
this
process
corresponds
to
the
"Last
Call
Working
Draft"
discussed
in
the
Patent
Policy.
</li>
</ul>
</dd>
<dd>
<strong>
Note:
</strong>
Candidate
Recommendations
are
expected
to
be
acceptable
as
Recommendations.
Announcement
of
a
different
next
step
<em class="rfc2119">
should
</em>
include
the
reasons
why
the
change
in
expectations
comes
at
so
late
a
stage.
</dd>
<dt id="RecsPR">
Proposed
Recommendation
</dt>
<dd>
A
Proposed
Recommendation
is
a
document
that
has
been
accepted
by
the
W3C
Director
as
of
sufficient
quality
to
become
a
W3C
Recommendation.
This
phase
establishes
a
deadline
for
the
Advisory
Committee
review
<del class="diff-old">which
</del>
<ins class="diff-chg">that
</ins>
begins
with
Candidate
Recommendation.
Substantive
changes
<em class="rfc2119">
must
</em>
not
be
made
to
a
Proposed
Recommendation
except
by
publishing
a
new
Working
Draft
or
Candidate
Recommendation.
</dd>
<dt id="RecsW3C">
W3C
Recommendation
(REC)
</dt>
<dd>
A
W3C
Recommendation
is
a
specification
or
set
of
guidelines
or
requirements
that,
after
extensive
consensus-building,
has
received
the
endorsement
of
W3C
Members
and
the
Director.
W3C
recommends
the
wide
deployment
of
its
Recommendations
as
standards
for
the
Web.
The
W3C
Royalty-Free
IPR
licenses
granted
under
the
Patent
Policy
apply
to
W3C
Recommendations.
</dd>
<dt id="RecsObs">
<ins class="diff-new">Obsolete
Recommendation
</ins></dt><dd><ins class="diff-new">
An
Obsolete
Recommendation
is
a
specification
that
W3C
does
not
believe
has
sufficient
market
relevance
to
continue
recommending
that
the
community
implement
it,
but
does
not
consider
that
there
are
fundamental
problems
that
require
the
Recommendation
be
Rescinded.
It
is
possible
for
an
Obsolete
Recommendation
to
receive
sufficient
market
uptake
that
W3C
decides
to
restore
it
to
Recommendation
status.
An
Obsolete
Recommendation
has
the
same
status
as
a
W3C
Recommendation
with
regards
to
W3C
Royalty-Free
IPR
licenses
granted
under
the
Patent
Policy.
</ins></dd><dt id="RescindedRec"><ins class="diff-new">
Rescinded
Recommendation
</ins></dt><dd><ins class="diff-new">
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
clause
10
of
the
licensing
requirements
for
W3C
Recommendations
in
</ins><a href="https://www.w3.org/Consortium/Patent-Policy#sec-Requirements"><ins class="diff-new">
section
5
</ins></a><ins class="diff-new">
of
the
</ins><a href="https://www.w3.org/Consortium/Patent-Policy"><ins class="diff-new">
W3C
Patent
Policy
</ins></a><ins class="diff-new">
[
</ins><a href="#ref-patentpolicy"><ins class="diff-new">
PUB33
</ins></a><ins class="diff-new">
].
</ins></dd>
<dt id="WGNote">
Working
Group
Note,
Interest
Group
Note
(NOTE)
</dt>
<dd>
A
Working
Group
Note
or
Interest
Group
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.
</dd>
<del class="diff-old">Rescinded
Recommendation
A
Rescinded
Recommendation
is
an
entire
Recommendation
that
W3C
no
longer
endorses.
See
also
clause
10
of
the
licensing
requirements
for
W3C
Recommendations
in
section
5
of
the
W3C
Patent
Policy
[
PUB33
].
</del>
</dl>
<p>
Working
Groups
and
Interest
Groups
<em class="rfc2119">
may
</em>
make
available
"Editor's
drafts".
Editor's
drafts
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.
</p>
<h3 id="requirements-and-definitions">
6.2
General
requirements
and
definitions
</h3>
<p>
Please
note
that
<dfn>
publishing
</dfn>
as
used
in
this
document
refers
to
producing
a
version
which
is
listed
as
a
W3C
Technical
Report
on
its
<a href="https://www.w3.org/TR/">
Technical
Reports
page
<del class="diff-old">http://www.w3.org/TR
</del>
<ins class="diff-chg">https://www.w3.org/TR
</ins>
</a>
[
<a href="#ref-doc-list">
PUB11
</a>
].
</p>
<h4 id="general-requirements">
6.2.1
General
requirements
for
Technical
Reports
</h4>
<p>
Every
document
published
as
part
of
the
technical
report
development
process
<em class="rfc2119 old">
must
</em>
be
a
public
document.
The
<a href="https://www.w3.org/TR/">
index
of
W3C
technical
reports
</a>
[
<a href="#ref-doc-list">
PUB11
</a>
]
is
available
at
the
W3C
Web
site.
W3C
strives
to
make
archival
documents
indefinitely
available
at
their
original
address
in
their
original
form.
</p>
<p>
Every
document
published
as
part
of
the
technical
report
development
process
<em class="rfc2119 old">
must
</em>
clearly
indicate
its
<a href="#maturity-levels">
maturity
level
</a>,
and
<em id="DocumentStatus" class="rfc2119">
must
</em>
include
information
about
the
status
of
the
document.
This
status
information
</p>
<ul>
<li>
<em class="rfc2119">
must
</em>
be
unique
each
time
a
specification
is
published,
</li>
<li>
<em class="rfc2119">
must
</em>
state
which
Working
Group
developed
the
specification,
</li>
<li>
<em class="rfc2119">
must
</em>
state
how
to
send
comments
or
file
bugs,
and
where
these
are
recorded,
</li>
<li>
<em class="rfc2119">
must
</em>
include
expectations
about
next
steps,
</li>
<li>
<em class="rfc2119">
should
</em>
explain
how
the
technology
relates
to
existing
international
standards
and
related
work
inside
or
outside
W3C,
and
</li>
<li>
<em class="rfc2119">
should
</em>
explain
or
link
to
an
explanation
of
significant
changes
from
the
previous
version.
</li>
</ul>
<p>
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
<em class="rfc2119">
must
</em>
be
a
participant,
<del class="diff-old">as
a
Member
representative,
Team
representative,
or
Invited
Expert
</del>
<ins class="diff-chg">per
</ins><a href="#group-participation"><ins class="diff-chg">
section
5.2.1
</ins></a>
in
the
Group
responsible
for
the
document(s)
they
are
editing.
</p>
<p>
The
Team
is
<em class="rfc2119">
not
required
</em>
to
publish
a
Technical
Report
that
does
not
conform
to
the
Team's
<a href="https://www.w3.org/Guide/pubrules">
Publication
Rules
</a>
[
<a href="#ref-pubrules">
PUB31
</a>
](e.g.,
for
<span id="DocumentName">
naming
</span>,
status
information,
style,
and
<span id="document-copyright">
copyright
requirements
</span>
).
These
rules
are
subject
to
change
by
the
Team
from
time
to
time.
The
Team
<em class="rfc2119">
must
</em>
inform
group
Chairs
and
the
Advisory
Committee
of
any
changes
to
these
rules.
</p>
<p>
The
primary
language
for
W3C
Technical
Reports
is
English.
W3C
encourages
the
translation
of
its
Technical
Reports.
<a href="https://www.w3.org/Consortium/Translation/">
Information
about
translations
of
W3C
technical
reports
</a>
[
<a href="#ref-translations">
PUB18
</a>
]
is
available
at
the
W3C
Web
site.
</p>
<h4 id="transition-reqs">
6.2.2
Advancement
on
the
Recommendation
Track
</h4>
<p>
For
<em>
all
</em>
<del class="diff-old">requests
</del>
<dfn>
<ins class="diff-chg">Transition
Requests
</ins></dfn>,
to
advance
a
specification
to
a
new
maturity
level
other
than
<del class="diff-old">Note
</del>
<ins class="diff-chg">Note,
</ins>
the
Working
Group:
</p>
<ul>
<li>
<em class="rfc2119">
must
</em>
record
the
group's
decision
to
request
advancement.
</li>
<li>
<em class="rfc2119">
must
</em>
obtain
Director
approval.
</li>
<li>
<em class="rfc2119">
must
</em>
provide
public
documentation
of
all
<a href="#substantive-change">
substantive
changes
</a>
to
the
technical
report
since
the
previous
publication.
</li>
<li>
<em class="rfc2119">
must
</em>
<a href="#formal-address">
formally
address
</a>
all
issues
raised
about
the
document
since
the
previous
maturity
level.
</li>
<li>
<em class="rfc2119">
must
</em>
provide
public
documentation
of
any
<a href="#FormalObjection">
Formal
Objections
</a>.
</li>
<li>
<em class="rfc2119">
should
</em>
provide
public
documentation
of
changes
that
are
not
substantive.
</li>
<li>
<em class="rfc2119">
should
</em>
report
which,
if
any,
of
the
Working
Group's
requirements
for
this
document
have
changed
since
the
previous
step.
</li>
<li>
<em class="rfc2119">
should
</em>
report
any
changes
in
dependencies
with
other
groups.
</li>
<li>
<em class="rfc2119">
should
</em>
provide
information
about
implementations
known
to
the
Working
Group.
</li>
</ul>
<p>
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
<del class="diff-old">generally
</del>
<ins class="diff-chg">usually
</ins>
a
formal
review
meeting
to
ensure
the
requirements
have
been
met
before
Director's
approval
is
given.
</p>
<p>
<ins class="diff-new">Transition
Requests
to
First
Public
Working
Draft
or
</ins><a href="#last-call"><ins class="diff-new">
Candidate
Recommendation
</ins></a><ins class="diff-new">
will
not
normally
be
approved
while
a
Working
Group's
charter
is
undergoing
or
awaiting
a
Director's
decision
on
an
Advisory
Committee
Review.
</ins></p>
<h4 id="doc-reviews">
6.2.3
Reviews
and
Review
Responsibilities
</h4>
<p>
A
document
is
available
for
review
from
the
moment
it
is
first
published.
Working
Groups
<em class="rfc2119">
should
</em>
<a href="#formal-address">
formally
address
</a>
<em>
any
</em>
substantive
review
comment
about
a
technical
report
in
a
timely
manner.
</p>
<p>
Reviewers
<em class="rfc2119">
should
</em>
send
substantive
technical
reviews
as
early
as
possible.
Working
Groups
are
often
reluctant
to
make
<a href="#substantive-change">
substantive
changes
</a>
to
a
mature
document,
particularly
if
this
would
cause
significant
compatibility
problems
due
to
existing
implementation.
Working
Groups
<em class="rfc2119">
should
</em>
record
substantive
or
interesting
proposals
raised
by
reviews
but
not
incorporated
into
a
current
specification.
</p>
<h5 id="wide-review">
6.2.3.1
Wide
Review
</h5>
<p>
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
<a href="mailto:public-review-announce@w3.org">
public-review-announce@w3.org
</a>
)
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
may
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
<a href="https://www.w3.org/Guide/Charter.html#horizontal-review">
W3C
Horizontal
Groups
</a>
and
groups
identified
as
dependencies
in
the
charter
or
identified
as
<a href="https://www.w3.org/2001/11/StdLiaison.html">
liaisons
</a>
[
<a href="#ref-liaison-list">
PUB29
</a>
],
and
seek
evidence
of
clear
communication
to
the
general
public
about
appropriate
times
and
which
content
to
review
and
whether
such
reviews
actually
occurred.
</p>
<p>
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
<em class="rfc2119">
should
</em>
announce
to
other
W3C
Working
Groups
as
well
as
the
general
public,
especially
those
affected
by
this
specification,
a
proposal
to
enter
<a href="#last-call">
Candidate
Recommendation
</a>
(for
example
in
approximately
four
weeks).
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.
</p>
<p>
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
may
only
represent
comment
from
a
small
segment
of
the
relevant
stakeholder
community.
</p>
<h4 id="implementation-experience">
6.2.4
Implementation
Experience
</h4>
<p>
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
<dfn>
adequate
implementation
experience
</dfn>
the
Director
will
consider
(though
not
be
limited
to):
</p>
<ul>
<li>
is
each
feature
of
the
current
specification
implemented,
and
how
is
this
demonstrated?
</li>
<li>
are
there
independent
interoperable
implementations
of
the
current
specification?
</li>
<li>
are
there
implementations
created
by
people
other
than
the
authors
of
the
specification?
</li>
<li>
are
implementations
publicly
deployed?
</li>
<li>
is
there
implementation
experience
at
all
levels
of
the
specification's
ecosystem
(authoring,
consuming,
publishing…)?
</li>
<li>
are
there
reports
of
difficulties
or
problems
with
implementation?
</li>
</ul>
<p>
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,
they
may
wish
to
develop
tests
in
concert
with
implementation
efforts.
</p>
<h4 id="correction-classes">
6.2.5
Classes
of
Changes
</h4>
<p>
This
document
distinguishes
the
following
4
classes
of
changes
to
a
specification.
The
first
two
classes
of
change
are
considered
<dfn id="editorial-change">
editorial
changes
</dfn>,
the
latter
two
<dfn id="substantive-change">
substantive
changes
</dfn>.
</p>
<dl>
<dt>
1.
No
changes
to
text
content
</dt>
<dd>
These
changes
include
fixing
broken
links,
style
sheets
or
invalid
markup.
</dd>
<dt>
2.
Corrections
that
do
not
affect
conformance
</dt>
<dd>
Changes
that
reasonable
implementers
would
not
interpret
as
changing
architectural
or
interoperability
requirements
or
their
<del class="diff-old">implementation.&#160;
</del>
<ins class="diff-chg">implementation.
</ins>
Changes
which
resolve
ambiguities
in
the
specification
are
considered
to
change
(by
clarification)
the
implementation
requirements
and
do
not
fall
into
this
class.
</dd>
<dd>
Examples
of
changes
in
this
class
<del class="diff-old">are
</del>
<ins class="diff-chg">include
</ins>
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
dissent
as
to
whether
requirements
are
changed,
such
changes
do
not
<del class="diff-old">belong
to
</del>
<ins class="diff-chg">fall
into
</ins>
this
<del class="diff-old">class..
</del>
<ins class="diff-chg">class.
</ins>
</dd>
<dt>
3.
Corrections
that
do
not
add
new
features
</dt>
<dd>
These
changes
<em class="rfc2119">
may
</em>
affect
conformance
to
the
specification.
A
change
that
affects
conformance
is
one
that:
<ul>
<li>
makes
conforming
data,
processors,
or
other
conforming
agents
become
non-conforming
according
to
the
new
version,
or
</li>
<li>
makes
non-conforming
data,
processors,
or
other
agents
become
conforming,
or
</li>
<li>
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.
</li>
</ul>
</dd>
<dt>
4.
New
features
</dt>
<dd>
Changes
that
add
a
new
functionality,
element,
etc.
</dd>
</dl>
<h3 id="working-draft">
6.3
Working
Draft
</h3>
<p>
A
Public
Working
Draft
is
published
on
the
<a href="https://www.w3.org/TR/">
W3C's
Technical
Reports
page
</a>
[
<a href="#ref-doc-list">
PUB11
</a>
]
for
review,
and
for
simple
historical
reference.
For
all
Public
Working
Drafts
a
Working
<del class="diff-old">Group
</del>
<ins class="diff-chg">Group:
</ins>
</p>
<ul>
<li>
<em class="rfc2119">
should
</em>
document
outstanding
issues,
and
parts
of
the
document
on
which
the
Working
Group
does
not
have
consensus,
and
</li>
<li>
<em class="rfc2119">
may
</em>
request
publication
of
a
Working
Draft
even
if
its
content
is
considered
unstable
and
does
not
meet
all
Working
Group
requirements.
</li>
</ul>
<h4 id="first-wd">
6.3.1
First
Public
Working
Draft
</h4>
<p>
To
publish
the
First
Public
Working
Draft
of
a
document,
a
Working
Group
<em class="rfc2119">
must
</em>
meet
the
applicable
<a href="#transition-reqs">
general
requirements
for
advancement
</a>.
</p>
<p>
The
Director
<em class="rfc2119">
must
</em>
announce
the
publication
of
a
First
Public
Working
Draft
publication
to
other
W3C
groups
and
to
the
public.
</p>
<p>
Publishing
the
First
Public
Working
Draft
triggers
a
Call
for
Exclusions,
per
<a href="https://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">
section
4
</a>
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<h4 id="revised-wd">
6.3.2
Revising
Public
Working
Drafts
</h4>
<p>
A
Working
Group
<em class="rfc2119">
should
</em>
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.
</p>
<p>
If
6
months
elapse
without
significant
changes
to
a
specification
a
Working
Group
<em class="rfc2119">
should
</em>
publish
a
revised
Working
Draft,
whose
status
section
<em class="rfc2119">
should
</em>
indicate
reasons
for
the
lack
of
change.
</p>
<p>
To
publish
a
revision
of
a
Working
draft,
a
Working
<del class="diff-old">Group
</del>
<ins class="diff-chg">Group:
</ins>
</p>
<ul>
<li>
<em class="rfc2119">
must
</em>
record
the
group's
decision
to
request
publication.
Consensus
is
not
required,
as
this
is
a
procedural
step,
</li>
<li>
<em class="rfc2119">
must
</em>
provide
public
documentation
of
<a href="#substantive-change">
substantive
changes
</a>
to
the
technical
report
since
the
previous
Working
Draft,
</li>
<li>
<em class="rfc2119">
should
</em>
provide
public
documentation
of
significant
<a href="#editorial-change">
editorial
changes
</a>
to
the
technical
report
since
the
previous
step,
</li>
<li>
<em class="rfc2119">
should
</em>
report
which,
if
any,
of
the
Working
Group's
requirements
for
this
document
have
changed
since
the
previous
step,
</li>
<li>
<em class="rfc2119">
should
</em>
report
any
changes
in
dependencies
with
other
groups,
</li>
</ul>
<p>
Possible
next
steps
for
any
Working
Draft:
</p>
<ul>
<li>
Revised
<a href="#revised-wd">
Public
Working
Draft
</a>
</li>
<li>
<a href="#last-call">
Candidate
recommendation
</a>.
</li>
<li>
<a href="#Note">
Working
Group
Note
</a>
</li>
</ul>
<h4 id="tr-end">
6.3.3
Stopping
Work
on
a
specification
</h4>
<p>
Work
on
a
technical
report
<em class="rfc2119">
may
</em>
cease
at
any
time.
Work
<em class="rfc2119 new">
should
</em>
cease
if
W3C
or
a
Working
Group
determines
that
it
cannot
productively
carry
the
work
any
further.
If
the
Director
<a href="#GeneralTermination">
closes
a
Working
Group
</a>
W3C
<em class="rfc2119">
must
</em>
publish
any
unfinished
specifications
on
the
Recommendation
track
as
<a href="#Note">
Working
Group
Notes
</a>.
If
a
Working
group
decides,
or
the
Director
requires,
the
Working
Group
to
discontinue
work
on
a
technical
report
before
completion,
the
Working
Group
<em class="rfc2119">
should
</em>
publish
the
document
as
a
<a href="#Note">
Working
Group
Note
</a>.
</p>
<h3 id="candidate-rec">
<a id="last-call">
6.4
Candidate
Recommendation
</a>
</h3>
<p>
To
publish
a
Candidate
recommendation,
in
addition
to
meeting
the
<a href="#transition-reqs">
general
requirements
for
advancement
</a>
a
Working
Group:
</p>
<ul>
<li>
<em class="rfc2119">
must
</em>
show
that
the
specification
has
met
all
Working
Group
requirements,
or
explain
why
the
requirements
have
changed
or
been
deferred,
</li>
<li>
<em class="rfc2119">
must
</em>
document
changes
to
dependencies
during
the
development
of
the
specification,
</li>
<li>
<em class="rfc2119">
must
</em>
document
how
adequate
<a href="#implementation-experience">
implementation
experience
</a>
will
be
demonstrated,
</li>
<li>
<em class="rfc2119">
must
</em>
specify
the
deadline
for
comments,
which
<em class="rfc2119">
must
</em>
be
<strong>
at
least
</strong>
four
weeks
after
publication,
and
<em class="rfc2119">
should
</em>
be
longer
for
complex
documents,
</li>
<li>
<em class="rfc2119">
must
</em>
show
that
the
specification
has
received
<a href="#wide-review">
wide
review
</a>,
and
</li>
<li>
<em class="rfc2119">
may
</em>
identify
features
in
the
document
as
"at
risk".
These
features
<em class="rfc2119">
may
</em>
be
removed
before
advancement
to
Proposed
Recommendation
without
a
requirement
to
publish
a
new
Candidate
Recommendation.
</li>
</ul>
<p>
The
Director
<em class="rfc2119">
must
</em>
announce
the
publication
of
a
Candidate
Recommendation
to
other
W3C
groups
and
to
the
public,
and
<em class="rfc2119">
must
</em>
begin
an
Advisory
Committee
Review
on
the
question
of
whether
the
specification
is
appropriate
to
publish
as
a
W3C
Recommendation.
</p>
<p>
A
Candidate
Recommendation
corresponds
to
a
"Last
Call
Working
Draft"
as
used
in
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
Publishing
a
Candidate
Recommendation
triggers
a
Call
for
Exclusions,
per
<a href="https://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">
section
4
</a>
of
the
<a href="https://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<p>
Possible
next
steps:
</p>
<ul>
<li>
Return
to
<a href="#revised-wd">
Working
Draft
</a>
</li>
<li>
A
revised
<a href="#last-call">
Candidate
Recommendation
</a>
</li>
<li>
<a href="#rec-pr">
Proposed
Recommendation
</a>
(The
expected
next
step)
</li>
<li>
<a href="#Note">
Working
Group
Note
</a>
</li>