diff.html
author Ralph Swick <swick+git@w3.org>
Wed, 04 Mar 2015 16:48:47 -0500
branchED-20150303
changeset 150 68f2be460152
parent 149 4549146b2696
permissions -rw-r--r--
Oops; can't default the file extension (.html)
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=utf-8" http-equiv="content-type">
<meta name="keywords" content="W3C, World Wide Web, WWW, Consortium, process, Team, Recommendation, Advisory Committee, Advisory Board, Working Group, Coordination Group, Interest Group, W3C Activity, Workshop, Symposium, charter, Activity Proposal,Working Draft, Process Document, Candidate Recommendation, Director, Proposed Recommendation, Last Call, 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}
</style>
<!--[if lt IE 9]><script src='undefined://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
<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="http://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
Draft
</ins>
Process
Document
</h1>
<h2 class="notoc">
<del class="diff-old">1
August
2014
</del>
<ins class="diff-chg">3
March
2015
Editor's
Draft
</ins>
</h2>
<dl>
<dt>
<del class="diff-old">This
version
-
permanent
URI:
http://www.w3.org/2014/Process-20140801/
</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>
<a href="http://www.w3.org/Consortium/Process/">
http://www.w3.org/Consortium/Process/
</a>
</dd>
<dt>
<del class="diff-old">Previous
operative
version:
14
October
2005
Process
</del>
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="http://www.w3.org/">
W3C
</a>
</dd>
</dl>
<p class="copyright">
<a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
Copyright
</a>
©
<del class="diff-old">1996-2014
</del>
<ins class="diff-chg">1996-2015
</ins>
<a href="/">
<abbr title="World Wide Web Consortium">
W3C
</abbr>
</a>
<sup>
®
</sup>
(
<a href="http://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
<a href="/Consortium/Legal/privacy-statement#Public">
public
</a>
and
<a href= "/Consortium/Legal/privacy-statement#Members">
Member
</a>
privacy
statements.
</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="http://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>
<ins class="diff-new">W3C,
including
all
existing
chartered
groups,
follows
the
</ins><a href="http://www.w3.org/Consortium/Process/"><ins class="diff-new">
most
recent
operative
Process
Document
</ins></a><ins class="diff-new">
announced
to
the
Membership.
</ins></p><p>
This
<ins class="diff-new">document
</ins>
is
<ins class="diff-new">developed
by
the
Advisory
Board's
Process
Task
Force
(which
anyone
may
join)
working
within
the
</ins><a href="http://www.w3.org/community/w3process/"><ins class="diff-new">
Revising
W3C
Process
Community
Group
</ins></a>.<ins class="diff-new">
This
is
the
25
January
2015
Editor's
draft
for
the
proposed
next
version
of
</ins>
the
<del class="diff-old">1
August
2014
</del>
W3C
Process
Document.
This
document
<del class="diff-old">was
</del>
<ins class="diff-chg">is
based
on
the
30
September
review
draft,
itself
based
on
the
1
August
2014
Process,
</ins>
developed
between
the
<a href="/2002/ab/">
W3C
Advisory
Board
</a>
and
the
<a href="http://www.w3.org/community/w3process/">
Revising
W3C
Process
Community
Group
</a>
and
<del class="diff-old">reviewed
twice
by
</del>
<ins class="diff-chg">adopted
as
</ins>
the
<del class="diff-old">W3C
Membership.
</del>
<ins class="diff-chg">currently
operative
Process.
</ins>
</p>
<p>
<del class="diff-old">W3C,
including
all
existing
chartered
groups,
follows
</del>
<ins class="diff-chg">This
draft
is
expected
to
be
proposed
to
</ins>
the
<del class="diff-old">most
recent
</del>
<ins class="diff-chg">Advisory
Committee
as
a
working
draft
with
an
explicit
request
for
comment,
as
a
"last
call"
before
a
formal
AC
review
on
whether
to
adopt
this
as
the
new
</ins>
operative
Process
<del class="diff-old">Document
</del>
<ins class="diff-chg">document.
Further
revision
is
expected,
to
be
adopted
in
2016.
</ins></p><p><ins class="diff-chg">
Note
that
sections
have
not
been
renumbered
from
the
current
Operative
version.
This
is
intended
to
facilitate
comparison
for
review.
Renumbering
will
occur
before
adoption
of
a
New
Process
document.
</ins></p><p><ins class="diff-chg">
In
</ins><em><ins class="diff-chg">
this
draft
</ins></em><ins class="diff-chg">
the
default
channel
for
</ins><a href="#ACReview"><ins class="diff-chg">
AC
review
</ins>
</a>
<del class="diff-old">announced
</del>
<ins class="diff-chg">has
been
removed
in
favor
of
a
requirement
for
each
review
to
specify
a
default
(
</ins><a href="http://www.w3.org/community/w3process/track/issues/154"><ins class="diff-chg">
ISSUE-154
</ins></a><ins class="diff-chg">
),
a
procedure
for
</ins><a href="#resignation"><ins class="diff-chg">
resignation
</ins></a><ins class="diff-chg">
from
Working
(and
Interest
Groups
has
been
provided
(
</ins><a href="http://www.w3.org/community/w3process/track/issues/151"><ins class="diff-chg">
ISSUE-151
</ins></a><ins class="diff-chg">
),
and
</ins><a href="http://www.w3.org/community/w3process/track/issues/152"><ins class="diff-chg">
ISSUE-152
</ins></a><ins class="diff-chg">
is
described.
A
</ins><a href="#changes"><ins class="diff-chg">
change
history
</ins></a><ins class="diff-chg">
(compared
</ins>
to
the
<del class="diff-old">Membership.
</del>
<ins class="diff-chg">2014
Process
Document)
forms
part
of
the
draft.
</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>
(
<a href="http://lists.w3.org/Archives/Public/public-w3process/">
Mailing
list
archive
</a>,
publicly
available)
or
to
process-issues@w3.org
(
<a href="http://lists.w3.org/Archives/Member/process-issues">
Member-only
archive
</a>
).
A
<a href="https://www.w3.org/community/w3process/track/">
Public
Issue
Tracker
</a>
and
<a href="https://dvcs.w3.org/hg/AB/">
detailed
changelogs
</a>
are
available
online.
</p>
<del class="diff-old">The
terms
must
,
must
not
,
should
,
should
not
,
required
,
and
may
are
used
in
accordance
with
RFC
2119
[
RFC2119
].
The
term
not
required
is
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>
<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="http://www.w3.org/Consortium/Agreement/Member-Agreement">
Membership
Agreement
</a>
[
<a href="#ref-member-agreement">
PUB6
</a>
].
The
Patent
Policy
<a href="http://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-chg">Conformance
and
specialized
terms
</ins></h2><p><ins class="diff-chg">
The
terms
</ins><em class="rfc2119"><ins class="diff-chg">
must
</ins></em>,<em class="rfc2119"><ins class="diff-chg">
must
not
</ins></em>,<em class="rfc2119"><ins class="diff-chg">
should
</ins></em>,<em class="rfc2119"><ins class="diff-chg">
should
not
</ins></em>,<em class="rfc2119"><ins class="diff-chg">
required
</ins></em>,<ins class="diff-chg">
and
</ins><em class="rfc2119"><ins class="diff-chg">
may
</ins></em><ins class="diff-chg">
are
used
in
accordance
with
</ins><a href="http://www.ietf.org/rfc/rfc2119.txt"><ins class="diff-chg">
RFC
2119
</ins></a><ins class="diff-chg">
[
</ins><a href="#ref-RFC2119"><ins class="diff-chg">
RFC2119
</ins></a><ins class="diff-chg">
].
The
term
</ins><dfn>
<em class="rfc2119">
<ins class="diff-chg">not
required
</ins></em></dfn><ins class="diff-chg">
is
equivalent
to
the
term
</ins><em class="rfc2119"><ins class="diff-chg">
may
</ins></em><ins class="diff-chg">
as
defined
in
RFC
2119.&#160;
</ins></p><p><ins class="diff-chg">
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">
<s>
5
Activities
</s>
</li>
<li class="tocline2">
<a href="#GAGeneral" class="tocxref">
6
Working
<del class="diff-old">Groups,
Interest
Groups,
</del>
<ins class="diff-chg">Groups
</ins>
and
<del class="diff-old">Coordination
</del>
<ins class="diff-chg">Interest
</ins>
Groups
</a>
</li>
<li class="tocline2">
<a href="#Reports" class="tocxref">
7
W3C
Technical
Report
Development
Process
</a>
</li>
<li class="tocline2">
<a href="#ReviewAppeal" class="tocxref">
8
Advisory
Committee
Reviews,
Appeals,
and
Votes
</a>
</li>
<li class="tocline2">
<a href="#GAEvents" class="tocxref">
9
Workshops
and
Symposia
</a>
</li>
<li class="tocline2">
<a href="#Liaisons" class="tocxref">
10
Liaisons
</a>
</li>
<li class="tocline2">
<a href="#Submission" class="tocxref">
11
Member
Submission
Process
</a>
</li>
<li class="tocline2">
<a href="#GAProcess" class="tocxref">
12
Process
Evolution
</a>
</li>
<li class="tocline2">
<a href="#references" class="tocxref">
13
References
</a>
</li>
<li class="tocline2">
<a href="#acks" class="tocxref">
14
Acknowledgments
</a>
</li>
<li class="tocline2">
<a href="#changes" class="tocxref">
15
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="#MemberRelated">
2.1.2
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">
<del class="diff-old">5
Activities
5.1
Activity
Proposal
Development
5.2
Advisory
Committee
Review
of
an
Activity
Proposal
5.3
Modification
of
an
Activity
5.4
Extension
of
an
Activity
5.5
Activity
Closure
5.6
Activity
Proposals
</del>
<a href="#GAGeneral">
6
Working
<del class="diff-old">Groups,
Interest
Groups,
</del>
<ins class="diff-chg">Groups
</ins>
and
<del class="diff-old">Coordination
</del>
<ins class="diff-chg">Interest
</ins>
Groups
</a>
<ul class="toc">
<li class="tocline3">
<a href="#ReqsAllGroups">
6.1
Requirements
for
All
<del class="diff-old">Working,
Interest,
</del>
<ins class="diff-chg">Working
</ins>
and
<del class="diff-old">Coordination
</del>
<ins class="diff-chg">Interest
</ins>
Groups
</a>
</li>
<li class="tocline3">
<a href="#GroupsWG">
6.2
Working
Groups
and
Interest
Groups
</a>
<ul class="toc">
<li class="tocline4">
<a href="#group-participation">
6.2.1
Working
Group
and
Interest
Group
Participation
Requirements
</a>
</li>
<li class="tocline4">
<a href="#WGCharterDevelopment">
6.2.2
Working
Group
and
Interest
Group
Charter
Development
</a>
</li>
<li class="tocline4">
<a href="#CharterReview">
6.2.3
Advisory
Committee
Review
of
a
Working
Group
or
Interest
Group
Charter
</a>
</li>
<li class="tocline4">
<a href="#cfp">
6.2.4
Call
for
Participation
in
a
Working
Group
or
Interest
Group
</a>
</li>
<li class="tocline4">
<a href="#charter-extension">
6.2.5
Working
Group
and
Interest
Group
Charter
Extension
</a>
</li>
<li class="tocline4">
<a href="#WGCharter">
6.2.6
Working
Group
and
Interest
Group
Charters
</a>
</li>
<li class="tocline4">
<del class="diff-old">6.2.7
Working
Group
"Heartbeat"
Requirement
</del>
<a href="#GeneralTermination">
6.2.8
Working
Group
and
Interest
Group
Closure
</a>
</li>
</ul>
</li>
<del class="diff-old">6.3
Coordination
Groups
6.3.1
Coordination
Group
Participation
Requirements
6.3.2
Coordination
Group
Creation
and
Closure
6.3.3
Coordination
Group
Charters
</del>
</ul>
</li>
<li class="tocline2">
<a href="#Reports">
7
W3C
Technical
Report
Development
Process
</a>
<ul class="toc">
<li>
<a href="#rec-advance">
7.1
W3C
Technical
Reports
</a>
<ul class="toc">
<li>
<a href="#recs-and-notes" id="return-to-wg">
7.1.1
Recommendations
and
Notes
</a>
</li>
<li>
<a href="#maturity-levels">
7.1.2
Maturity
Levels
</a>
</li>
</ul>
</li>
<li>
<a href="#requirements-and-definitions">
7.2
General
requirements
and
definitions
</a>
<ul class="toc">
<li>
<a href="#general-requirements">
7.2.1
General
requirements
for
Technical
Reports
</a>
</li>
<li>
<a href="#transition-reqs">
7.2.2
Advancement
on
the
Recommendation
Track
</a>
<ul class="toc">
<li>
<a href="#substantive-change">
7.2.2.1
Substantive
Change
</a>
</li>
</ul>
</li>
<li>
<a href="#doc-reviews">
7.2.3
Reviews
and
Review
Responsibilities
</a>
<ul class="toc">
<li>
<a href="#wide-review">
7.2.3.1
Wide
Review
</a>
</li>
</ul>
</li>
<li>
<a href="#implementation-experience">
7.2.4
Implementation
Experience
</a>
</li>
<li>
<a href="#correction-classes">
7.2.5
Classes
of
Changes
to
a
Recommendation
</a>
</li>
</ul>
</li>
<li>
<a href="#working-draft">
7.3
Working
Draft
</a>
<ul class="toc">
<li>
<a href="#first-wd">
7.3.1
First
Public
Working
Draft
</a>
</li>
<li>
<a href="#revised-wd">
7.3.2
Revising
Public
Working
Drafts
</a>
</li>
<li>
<a href="#tr-end">
7.3.3
Stopping
work
on
a
specification
</a>
</li>
</ul>
</li>
<li>
<a href="#candidate-rec" id="cfi">
7.4
Candidate
Recommendation
</a>
<ul class="toc">
<li>
<a href="#revised-cr">
7.4.1
Revising
a
Candidate
Recommendation
</a>
</li>
</ul>
</li>
<li>
<a href="#rec-pr" id="cfr">
7.5
Proposed
Recommendation
</a>
</li>
<li>
<a href="#rec-publication">
7.6
W3C
Recommendation
</a>
</li>
<li>
<a href="#rec-modify">
7.7
Modifying
a
W3C
Recommendation
</a>
<ul class="toc">
<li>
<a href="#errata">
7.7.1
Errata
Management
</a>
</li>
<li>
<a href="#revised-rec" id="cfr-edited">
7.7.2
Revising
a
Recommendation
</a>
</li>
</ul>
</li>
<li>
<a href="#Note">
7.8
Publishing
a
Working
Group
or
Interest
Group
Note
</a>
</li>
<li>
<a href="#rec-rescind">
7.9
Rescinding
a
W3C
Recommendation
</a>
</li>
<li>
<a href="#further-reading">
Further
reading
</a>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#ReviewAppeal">
8
Advisory
Committee
Reviews,
Appeals,
and
Votes
</a>
<ul class="toc">
<li class="tocline3">
<a href="#ACReview">
8.1
Advisory
Committee
Reviews
</a>
<ul class="toc">
<li class="tocline4">
<a href="#ACReviewStart">
8.1.1
Start
of
a
Review
Period
</a>
</li>
<li class="tocline4">
<a href="#ACReviewAfter">
8.1.2
After
the
Review
Period
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#ACAppeal">
8.2
Appeal
by
Advisory
Committee
Representatives
</a>
</li>
<li class="tocline3">
<a href="#ACVotes">
8.3
Advisory
Committee
Votes
</a>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#GAEvents">
9
Workshops
and
Symposia
</a>
</li>
<li class="tocline2">
<a href="#Liaisons">
10
Liaisons
</a>
</li>
<li class="tocline2">
<a href="#Submission">
11
Member
Submission
Process
</a>
<ul class="toc">
<li class="tocline3">
<a href="#SubmissionRights">
11.1
Submitter
Rights
and
Obligations
</a>
<ul class="toc">
<li class="tocline4">
<a href="#SubmissionScope">
11.1.1
Scope
of
Member
Submissions
</a>
</li>
<li class="tocline4">
<a href="#SubmissionReqs">
11.1.2
Information
Required
in
a
Submission
Request
</a>
</li>
</ul>
</li>
<li class="tocline3">
<a href="#TeamSubmissionRights">
11.2
Team
Rights
and
Obligations
</a>
</li>
<li class="tocline3">
<a href="#SubmissionYes">
11.3
Acknowledgment
of
a
Submission
Request
</a>
</li>
<li class="tocline3">
<a href="#SubmissionNo">
11.4
Rejection
of
a
Submission
Request
</a>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#GAProcess">
12
Process
Evolution
</a>
</li>
<li class="tocline2">
<a href="#references">
13
References
</a>
<ul class="toc">
<li class="tocline3">
<a href="#public-refs">
13.1
Public
Resources
</a>
</li>
<li class="tocline3">
<a href="#member-refs">
13.2
Member-only
Resources
</a>
</li>
<li class="tocline3">
<a href="#other-refs">
13.3
Other
References
</a>
</li>
</ul>
</li>
<li class="tocline2">
<a href="#acks">
14
Acknowledgments
</a>
</li>
<li class="tocline2">
<a href="#changes">
15
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
</a>,
the
W3C
equivalent
of
a
Web
standard.
</p>
<ol>
<li>
People
generate
interest
in
a
particular
topic
(e.g.,
Web
services).
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.
<del class="diff-old">This
was
the
case,
for
example,
with
Web
services.
</del>
</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
<a href="#ActivityDevelopment">
development
of
a
proposal
for
<del class="diff-old">a
</del>
<ins class="diff-chg">one
or
more
</ins>
new
<del class="diff-old">Activity
</del>
</a>
or
<ins class="diff-new">Interest
Group
or
</ins>
<a href="#WGCharterDevelopment">
Working
Group
charter
</a>,
depending
on
the
breadth
of
the
topic
of
interest.
<del class="diff-old">An
Activity
Proposal
describes
the
scope,
duration,
and
other
characteristics
of
the
intended
work,
and
includes
the
charters
of
one
or
more
Working
Groups,
Interest
Groups,
and
possibly
Coordination
Groups
to
carry
out
the
work.
</del>
W3C
Members
<a href="#ActivityCreation">
review
<del class="diff-old">each
Activity
Proposal
</del>
</a>
<del class="diff-old">and
</del>
the
<del class="diff-old">associated
Working
Group
</del>
<ins class="diff-chg">proposed
</ins>
charters.
When
there
is
support
within
W3C
for
investing
resources
in
the
topic
of
interest,
the
Director
approves
the
<del class="diff-old">new
Activity
</del>
<ins class="diff-chg">group(s)
</ins>
and
<del class="diff-old">groups
get
down
to
</del>
<ins class="diff-chg">they
begin
their
</ins>
work.
<del class="diff-old">For
the
Web
Services
Activity,
the
initial
Activity
Proposal
called
for
one
Working
Group
to
work
on
Web
Services
Architecture
and
one
to
work
on
a
language
for
Web
Services
Description.
The
Activity
Proposal
also
incorporated
an
existing
Working
Group
(from
another
Activity)
working
on
XML
Protocols.
</del>
</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">
appeal
process
</a>
for
the
Advisory
Committee.
</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="http://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:
<del class="diff-old">Activity
</del>
<a href="#CharterReview">
<ins class="diff-chg">Charter
</ins>
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
have
<a href="#ACAppeal">
appeal
</a>
powers
for
some
processes
described
in
this
document.
</li>
<li>
Representatives
of
Member
organizations
participate
in
<a href="#GAGeneral">
Working
<del class="diff-old">Groups,
Interest
Groups,
</del>
<ins class="diff-chg">Groups
</ins>
and
<del class="diff-old">Coordination
</del>
<ins class="diff-chg">Interest
</ins>
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="http://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="http://www.w3.org/Consortium/Member/List">
current
W3C
Members
</a>
[
<a href="#ref-current-mem">
PUB8
</a>
]).
Organizations
subscribe
according
to
the
<a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">
Membership
Agreement
</a>
[
<a href="#ref-member-agreement">
PUB6
</a>
].
The
<a href="#Team">
Team
</a>
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">individuals
.
</del>
<ins class="diff-chg">individuals.
</ins>
However,
an
individual
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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="http://www.w3.org/Member/Intro">
New
Member
Orientation
</a>
[
<a href="#ref-new-member">
MEM4
</a>
].
</li>
</ul>
<p>
Furthermore,
representatives
of
Member
organizations
participate
in
W3C
as
follows:
</p>
<ul>
<li>
In
<a href="#GAGeneral">
Working
<del class="diff-old">Groups,
Interest
Groups,
</del>
<ins class="diff-chg">Groups
</ins>
and
<del class="diff-old">Coordination
</del>
<ins class="diff-chg">Interest
</ins>
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>
In
the
case
(described
in
paragraph
5g
of
the
<a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">
Membership
Agreement
</a>
),
where
a
Member
organization
is
itself
a
consortium,
user
society,
or
otherwise
has
members
or
sponsors,
the
organization's
paid
staff
and
Advisory
Committee
representative
exercise
all
the
rights
and
privileges
of
W3C
membership.
In
addition,
the
Advisory
Committee
representative
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
designate
up
to
four
(or
more
at
the
Team's
discretion)
individuals
who,
though
not
employed
by
the
organization,
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
exercise
the
rights
of
<a href="#member-rep">
Member
representatives
</a>.
These
individuals
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
disclose
their
employment
affiliation
when
participating
in
W3C
work.
Provisions
for
<a href="#MemberRelated">
related
Members
</a>
apply.
Furthermore,
these
individuals
are
expected
to
represent
the
broad
interests
of
the
W3C
Member
organization
and
not
the
parochial
interests
of
their
employers.
</p>
<p>
The
rights
and
benefits
of
W3C
membership
are
contingent
upon
conformance
to
the
processes
described
in
this
document.
The
vast
majority
of
W3C
Members
faithfully
follow
the
spirit
as
well
as
the
letter
of
these
processes.
When
serious
and/or
repeated
violations
do
occur,
and
repeated
attempts
to
address
these
violations
have
not
resolved
the
situation,
the
Director
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
take
disciplinary
action.
Arbitration
in
the
case
of
further
disagreement
is
governed
by
paragraph
19
of
the
Membership
Agreement.
Refer
to
the
<a href="http://www.w3.org/2002/09/discipline">
Guidelines
for
Disciplinary
Action
</a>
[
<a href="#ref-discipline-gl">
MEM14
</a>
].
</p>
<h4 id="MemberRelated">
2.1.2
Related
Members
</h4>
<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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
disclose
these
relationships
according
to
the
mechanisms
described
in
the
<a href="http://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="http://www.w3.org/Consortium/join">
How
to
Join
W3C
</a>
"
[
<a href="#ref-join-w3c">
PUB5
</a>
]),
it
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
name
its
Advisory
Committee
representative
as
part
of
the
Membership
Agreement.
The
<a href="http://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
meetings,
explains
how
to
name
a
new
Advisory
Committee
representative,
and
more.
Advisory
Committee
representatives
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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="http://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="http://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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
monitor
discussion
and
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
participate
in
discussion
when
appropriate.
Ongoing
detailed
discussions
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
request
that
additional
individuals
from
their
organization
be
subscribed
to
these
lists.
Failure
to
contain
distribution
internally
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<a href="#def-W3CChair">
<del class="diff-old">W3C
Chair
or
Chief
Operating
Officer
</del>
<ins class="diff-chg">CEO
</ins>
</a>
).
At
each
Advisory
Committee
meeting,
the
Team
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
provide
an
update
to
the
Advisory
Committee
about:
</p>
<dl>
<dt>
<em>
Resources
</em>
</dt>
<dd>
<ul>
<li>
The
number
of
Full
and
Affiliate
W3C
Members.
</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
<del class="diff-old">Activities
</del>
<ins class="diff-chg">activities
(including
but
not
limited
to
Working
and
Interest
Groups)
</ins>
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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
send
one
<a href="#member-rep">
representative
</a>
to
each
Advisory
Committee
meeting.
In
exceptional
circumstances
(e.g.,
during
a
period
of
transition
between
representatives
from
an
organization),
the
meeting
Chair
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
allow
a
Member
organization
to
send
two
representatives
to
a
meeting.
</p>
<p>
The
Team
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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="http://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
<ins class="diff-new">Director,
CEO,
</ins>
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="http://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
<del class="diff-old">Activities
</del>
<ins class="diff-chg">activities
</ins>
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
<del class="diff-old">Team
is
led
by
the
Director,
W3C
Chair,
</del>
<ins class="diff-chg">Director
</ins>
and
<del class="diff-old">Chief
Operating
Officer.
These
individuals
MAY
</del>
<ins class="diff-chg">CEO
</ins><em class="rfc2119"><ins class="diff-chg">
may
</ins></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
<del class="diff-old">W3C
and
as
such,
is
responsible
for
</del>
<ins class="diff-chg">W3C.
His
responsibilities
are
identified
throughout
this
document
in
relevant
places
Some
key
ones
include:
</ins>
assessing
<a href="#def-Consensus" id="DirectorDecision">
consensus
</a>
within
W3C
for
architectural
choices,
publication
of
<a href="#Reports">
technical
reports
</a>,
and
new
<del class="diff-old">Activities
.
The
Director
appoints
</del>
<ins class="diff-chg">activities;
appointing
</ins>
group
<a href="#GeneralChairs">
Chairs
</a>
<del class="diff-old">and
has
the
role
of
</del>
<ins class="diff-chg">;
</ins>
"tie-breaker"
for
<del class="diff-old">questions
of
Good
Standing
in
a
Working
Group
or
</del>
<a href="#WGAppeals">
appeal
of
a
Working
Group
decision
<del class="diff-old">.
The
</del>
</a>
<ins class="diff-chg">and
deciding
on
the
outcome
of
formal
objections;
the
</ins>
Director
is
generally
Chair
of
the
<a href="#TAG">
TAG
</a>.
</p>
<p>
<del class="diff-old">The
W3C
Chair
leads
Member
relations,
and
liaisons
with
other
organizations,
governments,
and
the
public.
The
Chief
Operating
Officer
(
COO
)
leads
the
operation
of
W3C
as
an
organization:
a
collection
of
people,
Host
institutions
,
and
processes.
</del>
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
<del class="diff-old">three
</del>
<ins class="diff-chg">four
</ins><dfn id="hosts">
"Host"
institutions
<del class="diff-old">:
</del>
</dfn>:
<ins class="diff-chg">Beihang
University,
</ins>
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
<del class="diff-old">joint
sponsorship
contracts;
</del>
<ins class="diff-chg">hosting
agreements;
</ins>
the
Hosts
themselves
are
not
W3C
Members.
</p>
<h4 id="TeamSubmission">
2.2.1
Team
Submissions
</h4>
<p>
Team
members
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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="http://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
appeals
of
<a href="#SubmissionNo">
Member
Submission
requests
</a>
that
are
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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
send
a
summary
of
each
of
its
meetings
to
the
Advisory
Committee
and
other
group
Chairs.
The
Advisory
Board
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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="http://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
<a href="#def-W3CChair">
<del class="diff-old">W3C
Chair
</del>
<ins class="diff-chg">CEO
</ins>
</a>.
</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
appeals
of
<a href="#SubmissionNo">
Member
Submission
requests
</a>
that
are
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
<del class="diff-old">SHOULD
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">should
not
</ins></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="http://www.w3.org/2001/07/19-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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
also
request
the
creation
of
additional
topic-specific,
public
mailing
lists.
For
some
TAG
discussions
(e.g.,
an
appeal
of
a
<a href="#SubmissionNo">
rejected
Member
Submission
request
</a>
),
the
TAG
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
use
a
list
that
will
be
<a href="#Member-only">
Member-only
</a>.
</p>
<p>
The
TAG
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
send
a
summary
of
each
of
its
<a href="#GeneralMeetings">
meetings
</a>
to
the
Advisory
Committee
and
other
group
Chairs.
The
TAG
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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="http://www.w3.org/2001/07/19-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="http://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
<del class="diff-old">NOT
REQUIRED
</del>
<em class="rfc2119">
<ins class="diff-chg">not
required
</ins></em>
to
be
on
the
W3C
Team.
The
Director
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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.
<del class="diff-old">Good
Standing
rules
as
defined
for
Working
Group
participants
also
apply
to
Advisory
Board
and
TAG
participants.
</del>
Advisory
Board
and
TAG
participants
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">
section
3
</a>
of
the
<a href="http://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
],
and
the
claim
exclusion
process
of
<a href="http://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
<del class="diff-old">TAG.
</del>
<ins class="diff-chg">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
</ins><em class="rfc2119"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
have
returned
to
having
at
most
one
participant.
</ins>
</li>
<li>
A
Member
organization
is
permitted
at
most
one
participant
on
the
AB.
</li>
<li>
An
individual
<del class="diff-old">MUST
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">must
not
</ins></em>
participate
on
both
the
TAG
and
the
AB.
</li>
</ul>
<p>
If,
for
whatever
reason,
these
constraints
are
not
satisfied
(e.g.,
because
<del class="diff-old">a
TAG
or
</del>
<ins class="diff-chg">an
</ins>
AB
participant
changes
jobs),
one
participant
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
cease
<del class="diff-old">TAG
or
</del>
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
Committee.
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,
and
the
address
where
nominations
are
sent.
The
Director
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
announce
appointments
no
later
than
the
start
of
a
nomination
period,
and
generally
as
part
of
the
Call
for
Nominations.
</p>
<p>
Each
Member
(or
group
of
<a href="#MemberRelated">
related
Members
</a>
)
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
nominate
one
individual.
A
nomination
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
be
made
with
the
consent
of
the
nominee.
In
order
for
an
individual
to
be
nominated
as
a
Member
representative,
the
individual
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
qualify
for
<a href="#member-rep">
Member
representation
</a>
and
the
Member's
Advisory
Committee
representative
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
include
that
information
in
the
nomination.
In
order
for
an
individual
to
be
nominated
as
a
Team
representative,
the
nominating
Advisory
Committee
representative
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
first
secure
approval
from
Team
management.
A
nominee
is
<span class="rfc2119">
NOT
REQUIRED
</span>
to
be
an
employee
of
a
Member
organization,
and
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
be
a
<a href="#fellows">
W3C
Fellow
</a>.
Each
nomination
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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,
and
the
address
where
votes
are
sent.
</li>
</ul>
<p>
When
there
is
a
vote,
each
Member
(or
group
of
<a href="#MemberRelated">
related
Members
</a>
)
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
vote
for
as
many
candidates
as
there
are
available
seats;
see
the
section
on
<a href="#ACVotes">
Advisory
Committee
votes
</a>.
Once
the
deadline
for
votes
has
passed,
the
Team
announces
the
results
to
the
Advisory
Committee.
The
candidates
with
the
most
votes
are
elected
to
the
available
seats.
In
case
of
a
tie
where
there
are
more
apparent
winners
than
available
seats
(e.g.,
three
candidates
receive
10
votes
each
for
two
seats),
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
individual
who
received
the
fewest
votes,
the
next
shortest
to
the
elected
individual
who
received
the
next
fewest,
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="http://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
<del class="diff-old">,
for
example
because
the
participant
has
failed
to
remain
in
Good
Standing
</del>
</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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">SHOULD
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">should
not
</ins></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>,
<ins class="diff-new">and
</ins>
<a href="#igparticipant">
Interest
Groups
<del class="diff-old">,
and
Coordination
Groups
</del>
</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
<del class="diff-old">Activities
</del>
<ins class="diff-chg">activities
</ins>
are
responsible
for
assessing
and
attesting
to
the
qualities
of
those
nominees.
</p>
<p>
See
also
the
participation
requirements
described
in
<a href="http://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">
section
6
</a>
of
the
<a href="http://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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
is
clearly
a
function
of
the
individual's
affiliations.
When
these
affiliations
change,
the
individual's
assignment
to
the
role
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
be
evaluated.
The
role
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
be
reassigned
according
to
the
appropriate
process.
For
instance,
the
Director
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">Activity).
</del>
<ins class="diff-chg">activity).
</ins>
</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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
contact
the
Team.
</p>
<p>
Team
members
are
subject
to
the
<a href="http://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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
designate
a
non-employee
to
represent
the
Member.
Non-employee
Member
representatives
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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>
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
decline
to
allow
an
individual
designated
by
an
Advisory
Committee
representative
to
participate
in
a
group.
</p>
<p>
A
group
charter
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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>
)
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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,
<del class="diff-old">W3C
Chair,
</del>
<ins class="diff-chg">CEO,
</ins>
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
<del class="diff-old">:
</del>
</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
<del class="diff-old">:
</del>
</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
<del class="diff-old">participants
in
Good
Standing
.
</del>
<ins class="diff-chg">participants.
</ins>
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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
include
a
quorum
requirement
for
consensus
decisions.
</p>
<p>
Where
unanimity
is
not
possible,
a
group
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
set
minimum
thresholds
of
active
support
before
a
decision
can
be
recorded.
The
appropriate
percentage
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
vary
depending
on
the
size
of
the
group
and
the
nature
of
the
decision.
A
charter
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
move
on.
</p>
<p>
Groups
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
cite
technical
arguments
and
propose
changes
that
would
remove
the
Formal
Objection;
these
proposals
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
be
<a href="#confidentiality-change">
publicly
available
</a>.
A
Call
for
Review
(of
a
document)
to
the
Advisory
Committee
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
seek
clarification
before
reaching
a
decision.
</p>
<p>
As
a
courtesy,
both
Chairs
and
reviewers
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
set
expectations
for
the
schedule
of
responses
and
acknowledgments.
The
group
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
reply
to
a
reviewer's
initial
comments
in
a
timely
manner.
The
group
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
realize
that
their
comments
will
carry
less
weight
if
not
sent
to
the
group
in
a
timely
manner.
</p>
<p>
Substantive
responses
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
be
recorded.
The
group
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
record
that
a
decision
has
been
reopened,
and
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
do
so
upon
request
from
a
group
participant.
</p>
<h3 id="Votes">
3.4
Votes
</h3>
<p>
A
group
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
be
a
group
<a href="#participant">
participant
<del class="diff-old">in
Good
Standing
</del>
</a>.
Each
organization
represented
in
the
group
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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>
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
vote.
</p>
<p>
If
a
participant
is
unable
to
attend
a
vote,
that
individual
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
authorize
anyone
at
the
meeting
to
act
as
a
<dfn id="proxy">
proxy
<del class="diff-old">.
</del>
</dfn>.
The
absent
participant
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">NOT
REQUIRED
</del>
<em class="rfc2119">
<ins class="diff-chg">not
required
</ins></em>
to
state
the
reasons
for
their
dissent,
and
the
group
is
<del class="diff-old">NOT
REQUIRED
</del>
<em class="rfc2119">
<ins class="diff-chg">not
required
</ins></em>
to
record
individual
votes.
</p>
<p>
A
group
charter
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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.
The
participants
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
also
make
their
requests
known
to
the
<a href="#TeamContact">
Team
Contact
</a>.
The
Team
Contact
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
include
a
summary
of
the
issue
(whether
technical
or
procedural),
decision,
and
rationale
for
the
objection.
All
counter-arguments,
rationales,
and
decisions
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
resign
from
a
group.
<del class="diff-old">The
Team
</del>
<ins class="diff-chg">On
written
notification
from
an
Advisory
Committee
representative
or
Invited
Expert
to
the
team,
the
Member
and
their
representatives
or
the
Invited
Expert
</ins>
will
<del class="diff-old">establish
administrative
procedures
for
resignation.
</del>
<ins class="diff-chg">be
deemed
to
have
resigned
from
the
relevant
group.
</ins>
See
section
4.2.
of
the
<a href="http://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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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="http://www.w3.org/Consortium/Legal/copyright-documents">
W3C
Document
License
</a>
[
<a href="#ref-doc-license">
PUB18
</a>
]).
</li>
<li>
A
<a href="http://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="http://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
<del class="diff-old">Activities
</del>
<ins class="diff-chg">activities
</ins>
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="http://www.w3.org/Member/Eventscal">
calendar
</a>
[
<a href="#ref-calendar">
MEM3
</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>
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
treat
the
information
as
confidential
within
W3C,
</li>
<li>
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
use
reasonable
efforts
to
maintain
the
proper
level
confidentiality,
and
</li>
<li>
<del class="diff-old">MUST
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">must
not
</ins></em>
release
this
information
to
the
general
public
or
press.
</li>
</ul>
<p>
The
Team
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
provide
mechanisms
to
protect
the
confidentiality
of
Member-only
information
and
ensure
that
authorized
parties
have
proper
access
to
this
information.
Documents
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
clearly
indicate
whether
they
require
Member-only
confidentiality.
Individuals
uncertain
of
the
confidentiality
level
of
a
piece
of
information
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
contact
the
Team.
</p>
<p>
Advisory
Committee
representatives
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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="http://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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
need
to
communicate
Team-only
information
to
a
Working
Group
or
the
public.
Similarly,
a
Working
Group
whose
proceedings
are
Member-only
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
make
public
information
pertinent
to
the
technical
report
development
process.
</p>
<p>
This
document
clearly
indicates
which
information
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
remind
recipients
to
provide
such
alternatives.
</li>
<li>
The
Team
<del class="diff-old">MUST
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">must
not
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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>
<del class="diff-old">5
Activities
This
section
describes
the
mechanisms
for
establishing
consensus
within
the
areas
of
Web
development
the
Consortium
chooses
to
pursue.
An
Activity
organizes
the
work
necessary
for
the
development
or
evolution
of
a
Web
technology.
W3C
starts
an
Activity
based
on
interest
from
the
Members
and
Team.
W3C
Members
build
interest
around
new
work
through
discussions
among
Advisory
Committee
representatives,
Chairs,
and
Team,
and
through
the
Submission
process
.
The
Team
tracks
Web
developments
inside
and
outside
W3C,
manages
liaisons
,
and
organizes
Workshops
.
Based
on
input
from
the
Team
and
Members
about
the
structure
and
scope
of
an
Activity,
the
Team
sends
an
Activity
Proposal
to
the
Advisory
Committee.
This
is
a
proposal
to
dedicate
Team
and
Member
resources
to
a
particular
area
of
Web
technology
or
policy,
and
when
there
is
consensus
about
the
motivation,
scope,
and
structure
of
the
proposed
work,
W3C
starts
a
new
Activity.
Each
Activity
has
its
own
structure
that
generally
includes
</del>
</section>
<section id="ChapterGroups">
<h2 id="GAGeneral">
<ins class="diff-chg">6
</ins>
Working
<del class="diff-old">Groups,
Interest
Groups,
and
Coordination
Groups.
Within
the
framework
of
an
Activity,
these
groups
produce
technical
reports,
review
the
work
of
other
groups,
and
develop
sample
code
or
test
suites.
The
progress
of
each
Activity
is
documented
in
an
Activity
Statement
.
Activity
Statements
describe
the
goals
of
the
Activity,
completed
and
unfinished
deliverables,
changing
perspectives
based
on
experience,
and
future
plans.
At
least
before
each
Advisory
Committee
meeting
,
the
Team
SHOULD
revise
the
Activity
Statement
for
each
Activity
that
has
not
been
closed.
Refer
to
the
list
of
W3C
Activities
[
PUB9
].
Note:
This
list
MAY
include
some
Activities
that
began
prior
to
the
formalization
in
1997
of
the
Activity
creation
process.
5.1
Activity
Proposal
Development
The
Team
MUST
notify
the
Advisory
Committee
when
a
proposal
for
a
new
or
modified
Activity
is
in
development.
This
is
intended
to
raise
awareness,
even
if
no
formal
proposal
is
yet
available.
Advisory
Committee
representatives
MAY
express
their
general
support
on
the
Advisory
Committee
discussion
list
.
The
Team
MAY
incorporate
discussion
points
into
an
Activity
Proposal.
Refer
to
additional
tips
on
getting
to
Recommendation
faster
[
PUB27
].
5.2
Advisory
Committee
Review
of
an
Activity
Proposal
The
Director
MUST
solicit
Advisory
Committee
review
of
every
proposal
to
create,
substantively
modify,
or
extend
an
Activity.
After
a
Call
for
Review
from
the
Director,
the
Advisory
Committee
reviews
and
comments
on
the
proposal.
The
review
period
MUST
be
at
least
four
weeks
.
The
Director
announces
to
the
Advisory
Committee
whether
there
is
consensus
within
W3C
to
create
or
modify
the
Activity
(possibly
with
changes
suggested
during
the
review).
For
a
new
Activity,
this
announcement
officially
creates
the
Activity.
This
announcement
MAY
include
a
Call
for
Participation
in
any
groups
created
as
part
of
the
Activity.
If
there
was
dissent
,
Advisory
Committee
representatives
MAY
appeal
a
decision
to
create,
modify,
or
extend
the
Activity.
Note:
There
is
no
appeal
of
a
decision
not
to
create
an
Activity;
in
general,
drafting
a
new
Activity
Proposal
will
be
simpler
than
following
the
appeal
process.
5.3
Modification
of
an
Activity
Activities
are
intended
to
be
flexible.
W3C
expects
participants
to
be
able
to
adapt
in
the
face
of
new
ideas
(e.g.,
Member
Submission
requests)
and
increased
understanding
of
goals
and
context,
while
remaining
true
to
the
intent
of
the
original
Activity
Proposal.
If
it
becomes
necessary
to
make
substantive
changes
to
an
Activity
(e.g.,
because
significant
additional
resources
are
necessary
or
because
the
Activity's
scope
has
clearly
changed
from
the
original
proposal),
then
the
Director
MUST
solicit
Advisory
Committee
review
of
a
complete
Activity
Proposal
,
including
rationale
for
the
changes.
5.4
Extension
of
an
Activity
When
the
Director
solicits
Advisory
Committee
review
of
a
proposal
to
extend
the
duration
of
an
Activity
with
no
other
substantive
modifications
to
the
composition
of
the
Activity,
the
proposal
MUST
indicate
the
new
duration
and
include
rationale
for
the
extension.
The
Director
is
NOT
REQUIRED
to
submit
a
complete
Activity
Proposal
.
5.5
Activity
Closure
An
Activity
Proposal
specifies
a
duration
for
the
Activity.
The
Director,
subject
to
appeal
by
Advisory
Committee
representatives,
MAY
close
an
Activity
prior
to
the
date
specified
in
the
proposal
in
any
of
the
following
circumstances:
</del>
Groups
<del class="diff-old">in
the
Activity
fail
to
produce
chartered
deliverables.
Groups
in
the
Activity
produce
chartered
deliverables
ahead
of
schedule.
There
are
insufficient
resources
to
maintain
the
Activity,
according
to
priorities
established
within
W3C.
The
Director
closes
an
Activity
by
announcement
to
the
Advisory
Committee.
5.6
Activity
Proposals
An
Activity
Proposal
defines
the
initial
scope
</del>
and
<del class="diff-old">structure
of
an
Activity.
The
proposal
MUST
include
or
reference
the
following
information:
An
Activity
summary.
What
is
the
nature
of
the
Activity
(e.g.,
to
track
developments,
create
technical
reports,
develop
code,
organize
pilot
experiments,
or
for
education)?
Who
or
what
group
wants
this
(providers
or
users)?
Context
information.
Why
is
this
Activity
being
proposed
now?
What
is
the
situation
in
the
world
(e.g.,
with
respect
to
the
Web
community,
market,
research,
or
society)?
within
the
scope
of
the
proposal?
Who
or
what
currently
exists
that
is
pertinent
to
this
Activity?
Is
the
community
mature/growing/developing
a
niche?
What
competing
technologies
exist?
What
competing
organizations
exist?
A
description
of
the
Activity's
scope.
How
might
a
potential
Recommendation
interact
and
overlap
with
existing
international
standards
and
Recommendations?
What
organizations
are
likely
to
be
affected
by
potential
overlap
(see
the
section
on
liaisons
with
other
organizations
)?
What
should
be
changed
if
the
Activity
is
approved?
A
description
of
the
Activity's
initial
deployment,
including:
The
duration
of
the
Activity.
What
groups
will
be
created
as
part
of
this
Activity
and
how
those
groups
will
be
coordinated.
For
each
group,
the
proposal
MUST
include
a
provisional
charter.
Groups
MAY
be
scheduled
to
run
concurrently
or
sequentially
(either
because
of
a
dependency
or
an
expected
overlap
in
membership
and
the
desirability
of
working
on
one
subject
at
a
time).
These
charters
MAY
be
amended
based
on
review
comments
before
the
Director
issues
a
Call
for
Participation
.
The
expected
timeline
of
the
Activity,
including
proposed
deliverable
dates
and
scheduled
Workshops
and
Symposia
.
If
known,
the
date
of
the
first
face-to-face
meeting
of
each
proposed
group.
The
date
of
the
first
face-to-face
meeting
of
a
proposed
group
MUST
NOT
be
sooner
than
eight
weeks
after
the
date
of
the
Activity
Proposal
.
A
summary
of
resources
(Member,
Team,
administrative,
technical,
and
financial)
expected
to
be
dedicated
to
the
Activity.
The
proposal
MAY
specify
the
threshold
level
of
effort
that
Members
are
expected
to
pledge
in
order
for
the
Activity
to
be
accepted.
Information
about
known
dependencies
within
W3C
or
outside
of
W3C.
Intellectual
property
information.
What
are
the
intellectual
property
(including
patents
and
copyright)
considerations
affecting
the
success
of
the
Activity?
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
W3C
Patent
Policy
[
PUB33
]?
A
list
of
supporters
and
references.
What
community
is
expected
to
benefit
from
this
Activity?
Are
members
of
this
community
part
of
W3C
now?
Are
they
expected
to
join
the
effort?
6
Working
Groups,
</del>
Interest
<del class="diff-old">Groups,
and
Coordination
</del>
Groups
</h2>
<p id="GAGroups">
This
document
defines
<del class="diff-old">three
</del>
<ins class="diff-chg">two
</ins>
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
<del class="diff-old">Good
Standing
requirements
for
Working
Group
participation
as
well
as
</del>
additional
participation
requirements
described
in
the
<a href="http://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>
<del class="diff-old">Coordination
Groups.
A
Coordination
Group
manages
dependencies
and
facilitates
communication
with
other
groups,
within
or
outside
of
W3C.
</del>
</ol>
<p>
<del class="diff-old">Neither
</del>
Interest
Groups
<del class="diff-old">nor
Coordination
Groups
</del>
<ins class="diff-chg">do
not
</ins>
publish
<a href="#RecsW3C">
Recommendation
Track
technical
reports
</a>
;
see
information
about
<a href="#WGNote">
maturity
levels
for
Interest
Groups
<del class="diff-old">and
Coordination
Groups
</del>
</a>.
</p>
<h3 id="ReqsAllGroups">
6.1
Requirements
for
All
<del class="diff-old">Working,
Interest,
</del>
<ins class="diff-chg">Working
</ins>
and
<del class="diff-old">Coordination
</del>
<ins class="diff-chg">Interest
</ins>
Groups
</h3>
<p>
Each
group
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
have
a
charter.
Requirements
for
the
charter
depend
on
the
group
type.
All
group
charters
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
be
public
(even
if
other
proceedings
of
the
group
are
<a href="#Member-only">
Member-only
</a>
).
Existing
charters
that
are
not
yet
public
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
be
made
public
when
next
revised
or
extended
(with
attention
to
<a href="#confidentiality-change">
changing
confidentiality
level
</a>
).
</p>
<p>
Each
group
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
[MEM14]
</a>
is
described
in
the
<a href="http://www.w3.org/Guide/">
Member
guide
</a>
[
<a href="#ref-guide">
MEM9
</a>
].
</p>
<p>
Each
group
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
have
a
<dfn id="TeamContact">
Team
Contact
<del class="diff-old">,
</del>
</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
<del class="diff-old">SHOULD
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">should
not
</ins></em>
be
the
same
individual.
</p>
<p>
Each
group
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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="http://www.w3.org/Member/Mail/">
group
mailing
lists
</a>
[
<a href="#ref-mailing-lists">
MEM2
</a>
].
</p>
<p>
A
Chair
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
form
task
forces
(composed
of
group
participants)
to
carry
out
assignments
for
the
group.
The
scope
of
these
assignments
<del class="diff-old">MUST
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">must
not
</ins></em>
exceed
the
scope
of
the
group's
charter.
A
group
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
choose
to
publish
their
results
as
part
of
a
technical
report.
</p>
<h3>
6.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>
6.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
<del class="diff-old">:
</del>
</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
<del class="diff-old">:
</del>
</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
<del class="diff-old">.
</del>
</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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
represent
at
most
one
organization
in
a
Working
Group
or
Interest
Group.
</p>
<p>
An
individual
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
become
a
Working
or
Interest
Group
participant
at
any
time
during
the
group's
existence.
See
also
relevant
requirements
in
<a href="http://www.w3.org/Consortium/Patent-Policy#sec-join">
section
4.3
</a>
of
the
<a href="http://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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
designate
a
<dfn id="mtg-substitute">
substitute
</dfn>
to
attend
a
<a href="#GeneralMeetings">
meeting
</a>
and
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
inform
the
Chair.
The
substitute
<span class="rfc2119">
MAY
</span>
act
on
behalf
of
the
participant,
including
for
<a href="#Votes">
votes
</a>.
For
the
substitute
to
vote,
the
participant
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
authorize
another
participant
to
act
as
<a href="#proxy">
proxy
</a>
for
votes.
<del class="diff-old">For
the
purposes
of
Good
Standing
,
the
regular
representative
and
the
substitute
are
considered
the
same
participant.
</del>
</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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">
section
3
</a>
of
the
<a href="http://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="http://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">
section
4
</a>.
</p>
<h5>
6.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
<del class="diff-old">,
</del>
</dfn>,
an
Advisory
Committee
representative
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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="http://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>
6.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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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>
6.2.1.3
<dfn id="invited-expert-wg">
Invited
Expert
in
a
Working
Group
</dfn>
</h5>
<p>
The
Chair
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
invite
an
individual
with
a
particular
expertise
to
participate
in
a
Working
Group.
This
individual
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">,
</del>
</dfn>,
an
individual
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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="http://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="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">
section
3
</a>
(especially
3.4)
and
<a href="http://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">
section
6
</a>
(especially
6.10)
of
the
<a href="http://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
]).
Indicate
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
<del class="diff-old">SHOULD
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">should
not
</ins></em>
designate
as
an
Invited
Expert
in
a
Working
Group
an
individual
who
is
an
employee
of
a
W3C
Member.
The
Chair
<del class="diff-old">MUST
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">must
not
</ins></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>
6.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>
6.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>
<del class="diff-old">An
</del>
<ins class="diff-chg">A
</ins>
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>
6.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>
<del class="diff-old">6.2.1.7
Good
Standing
in
a
Working
Group
Participation
by
an
individual
in
a
Working
Group
on
an
ongoing
basis
implies
a
serious
commitment
to
the
charter,
including
all
of
the
following:
attending
most
meetings
of
the
Working
Group.
providing
deliverables
or
drafts
of
deliverables
in
a
timely
fashion.
being
familiar
with
the
relevant
documents
of
the
Working
Group,
including
minutes
of
past
meetings.
following
discussions
on
relevant
mailing
list(s).
At
the
first
Working
Group
meeting
that
follows
any
Call
for
Participation
,
all
participants
are
in
Good
Standing.
If
a
Member
or
Invited
Expert
joins
the
Working
Group
after
the
end
of
that
meeting,
the
Member
Representative
or
Invited
Expert
does
not
attain
Good
Standing
until
the
start
of
the
second
consecutive
meeting
that
individual
attends.
When
the
Chair
and
the
Team
Contact
agree,
the
Chair
MAY
declare
that
a
participant
is
no
longer
in
Good
Standing
(henceforth
called
"Bad
Standing").
If
there
is
disagreement
between
the
Chair
and
the
Team
Contact
about
standing,
the
Director
determines
the
participant's
standing.
The
Chair
MAY
declare
a
Team
participant
to
be
in
Bad
Standing,
but
it
is
clearly
preferable
for
the
Chair,
Team
participant,
and
W3C
management
to
resolve
issues
internally.
A
participant
MAY
be
declared
in
Bad
Standing
in
any
of
the
following
circumstances:
the
individual
has
missed
more
than
one
of
the
last
three
distributed
meetings
.
the
individual
has
missed
more
than
one
of
the
last
three
face-to-face
meetings
.
the
individual
has
not
provided
deliverables
in
a
timely
fashion
twice
in
sequence.
the
individual
has
not
followed
the
conflict
of
interest
policy
by
disclosing
information
to
the
rest
of
the
group.
Although
all
participants
representing
an
organization
SHOULD
attend
all
meetings,
attendance
by
one
representative
of
an
organization
satisfies
the
meeting
attendance
requirement
for
all
representatives
of
the
organization.
The
above
criteria
MAY
be
relaxed
if
the
Chair
and
Team
Contact
agree
that
doing
so
will
not
set
back
the
Working
Group.
For
example,
the
attendance
requirement
can
be
relaxed
for
reasons
of
expense
(e.g.,
cost
of
travel)
or
scheduling
(for
example,
an
exceptional
teleconference
is
scheduled
at
3:00
a.m.
local
time
for
the
participant).
It
is
the
responsibility
of
the
Chair
and
Team
Contact
to
apply
criteria
for
Good
Standing
consistently.
When
a
participant
risks
losing
Good
Standing,
the
Chair
and
Team
Contact
are
expected
to
discuss
the
matter
with
the
participant
and
the
participant's
Advisory
Committee
representative
(or
W3C
management
for
the
Team)
before
declaring
the
participant
in
Bad
Standing.
The
Chair
declares
a
participant
in
Bad
Standing
by
informing
the
participant's
Advisory
Committee
representative
and
the
participant
of
the
decision.
If
the
Advisory
Committee
representative
and
Chair
differ
in
opinion,
the
Advisory
Committee
representative
MAY
ask
the
Director
to
confirm
or
deny
the
decision.
Invited
Experts
declared
in
Bad
Standing
MAY
appeal
to
the
Director.
The
Chair
and
Team
Contact
restore
Good
Standing
and
SHOULD
do
so
when
the
individual
in
Bad
Standing
satisfies
the
above
criteria.
The
Chair
MUST
inform
the
individual's
Advisory
Committee
representative
of
any
change
in
standing.
When
a
Member
representative
permanently
replaces
another
(i.e.,
is
not
simply
a
temporary
substitute
),
the
new
participant
inherits
the
standing
of
the
departing
participant.
Changes
in
an
individual's
standing
in
a
Working
Group
have
no
effect
on
the
obligations
associated
with
Working
Group
participation
that
are
described
in
the
W3C
Patent
Policy
[
PUB33
].
Note:
In
general,
the
time
commitment
for
participating
in
an
Interest
Group
is
less
than
that
for
a
Working
Group;
see
the
section
on
participation
provisions
in
an
Interest
Group
charter
.
</del>
<h4>
6.2.2
<dfn id="WGCharterDevelopment">
Working
Group
and
Interest
Group
Charter
Development
</dfn>
</h4>
<p>
<ins class="diff-new">W3C
creates
a
charter
based
on
interest
from
the
Members
and
Team.
</ins>
The
Team
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
notify
the
Advisory
Committee
when
a
charter
for
a
new
Working
Group
or
Interest
Group
is
in
development.
<del class="diff-old">The
suggestions
for
building
support
around
an
Activity
Proposal
apply
</del>
<ins class="diff-chg">This
is
intended
</ins>
to
<del class="diff-old">charters
as
well.
</del>
<ins class="diff-chg">raise
awareness,
even
if
no
formal
proposal
is
yet
available.
Advisory
Committee
representatives
</ins><em class="rfc2119"><ins class="diff-chg">
may
</ins></em><ins class="diff-chg">
express
their
general
support
on
the
</ins><a href="#ACCommunication"><ins class="diff-chg">
Advisory
Committee
discussion
list
</ins></a>.
</p>
<p>
W3C
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
begin
work
on
a
Working
Group
or
Interest
Group
charter
at
any
time.
<del class="diff-old">A
Working
Group
or
Interest
Group
MUST
be
part
of
an
approved
Activity
.
</del>
</p>
<h4>
6.2.3
<dfn id="CharterReview">
Advisory
Committee
Review
of
a
Working
Group
or
Interest
Group
Charter
</dfn>
</h4>
<p>
The
Director
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
solicit
<a href="#ReviewAppeal">
Advisory
Committee
review
</a>
of
every
new
or
substantively
modified
Working
Group
or
Interest
Group
charter.
The
Director
is
<del class="diff-old">NOT
REQUIRED
</del>
<em class="rfc2119">
<ins class="diff-chg">not
required
</ins></em>
to
solicit
Advisory
Committee
review
prior
to
a
charter
extension
or
for
minor
changes.
<ins class="diff-new">The
review
period
</ins><em class="rfc2119"><ins class="diff-new">
must
</ins></em><ins class="diff-new">
be
at
least
four
weeks.
</ins>
</p>
<p>
The
Director's
Call
for
Review
of
a
substantively
modified
charter
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
highlight
important
changes
(e.g.,
regarding
deliverables
or
resource
allocation)
and
include
rationale
for
the
changes.
</p>
<h4>
6.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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
issue
a
Call
for
Participation
to
the
Advisory
Committee.
<ins class="diff-new">Charters
</ins><em class="rfc2119"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
be
amended
based
on
review
comments
before
the
Director
issues
a
Call
for
Participation.
</ins></p><p>
For
a
new
group,
this
announcement
officially
creates
the
group.
The
announcement
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
name
of
the
<a href="#TeamContact">
Team
Contact
</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>
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
be
designated
(or
re-designated).
</p>
<p>
Advisory
Committee
representatives
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
<a href="#ACAppeal">
appeal
</a>
creation
or
substantive
modification
of
a
Working
Group
or
Interest
Group
charter.
</p>
<h4>
6.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
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
indicate
the
new
<del class="diff-old">duration,
which
MUST
NOT
exceed
the
duration
of
the
Activity
to
which
the
group
belongs.
</del>
<ins class="diff-chg">duration.
</ins>
The
announcement
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
<del class="diff-old">NOT
REQUIRED
</del>
<em class="rfc2119">
<ins class="diff-chg">not
required
</ins></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
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
<a href="#ACAppeal">
appeal
</a>
the
extension
of
a
Working
Group
or
Interest
Group
charter.
</p>
<h4>
6.2.6
<dfn id="WGCharter">
Working
Group
and
Interest
Group
Charters
</dfn>
</h4>
<p>
A
Working
Group
or
Interest
Group
charter
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></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
software),
expected
milestones,
and
the
process
for
the
group
participants
to
approve
the
release
of
these
deliverables
(including
public
intermediate
results).
A
charter
is
<del class="diff-old">NOT
REQUIRED
</del>
<em class="rfc2119">
<ins class="diff-chg">not
required
</ins></em>
to
include
the
schedule
for
a
review
of
another
group's
deliverables;
</li>
<li>
Any
dependencies
by
groups
within
or
outside
of
W3C
on
the
deliverables
of
this
group.
For
any
dependencies,
the
charter
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
specify
the
mechanisms
for
communication
about
the
deliverables;
</li>
<li>
Any
dependencies
of
this
group
on
other
groups
within
or
outside
of
W3C.
For
example,
one
group's
charter
might
specify
that
another
group
is
expected
to
review
a
technical
report
before
it
can
become
a
Recommendation.
For
any
dependencies,
the
charter
<del class="diff-old">MUST
</del>
<em class="rfc2119">
<ins class="diff-chg">must
</ins></em>
specify
when
required
deliverables
are
expected
from
the
other
groups.
The
charter
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
set
expectations
about
how
coordination
with
those
groups
will
take
place;
see
the
section
on
<a href="#Liaisons">
liaisons
with
other
organizations
</a>.
Finally,
the
charter
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></em>
specify
expected
conformance
to
the
deliverables
of
the
other
groups;
</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>
<ins class="diff-new">If
known,
the
date
of
the
first
</ins><a href="#ftf-meeting"><ins class="diff-new">
face-to-face
meeting
</ins></a>.<ins class="diff-new">
The
date
of
the
first
face-to-face
meeting
of
a
proposed
group
</ins><em class="rfc2119"><ins class="diff-new">
must
not
</ins></em><ins class="diff-new">
be
sooner
than
</ins><span class="time-interval"><ins class="diff-new">
eight
weeks
</ins></span><ins class="diff-new">
after
the
date
of
the
proposal.
</ins></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>
<ins class="diff-new">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
</ins><a href="http://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></li>
</ul>
<p>
See
also
the
charter
requirements
of
<a href="http://www.w3.org/Consortium/Patent-Policy#sec-Licensing">
section
2
</a>
and
<a href="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">
section
3
</a>
of
the
<a href="http://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<p id="ig-charter-participation">
An
Interest
Group
charter
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></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
<del class="diff-old">list.
</del>
<ins class="diff-chg">list
</ins></dfn>.
This
type
of
Interest
Group
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
have
<a href="#public-participant-ig">
public
participants
</a>.
</p>
<p>
A
charter
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
include
additional
voting
procedures,
but
those
procedures
<del class="diff-old">MUST
NOT
</del>
<em class="rfc2119">
<ins class="diff-chg">must
not
</ins></em>
conflict
with
the
<a href="#Votes">
voting
requirements
</a>
of
the
Process
Document.
</p>
<p>
A
charter
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
include
provisions
other
than
those
required
by
this
document.
The
charter
<del class="diff-old">SHOULD
</del>
<em class="rfc2119">
<ins class="diff-chg">should
</ins></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">6.2.7
Working
Group
"Heartbeat"
Requirement
It
is
important
that
a
Working
Group
keep
the
Membership
and
public
informed
of
its
activity
and
progress.
To
this
end,
each
Working
Group
SHOULD
publish
in
the
W3C
technical
reports
index
a
new
draft
of
each
active
technical
report
at
least
once
every
three
months.
An
active
technical
report
is
a
Working
Draft,
Candidate
Recommendation,
Proposed
Recommendation,
or
Proposed
Edited
Recommendation.
Each
Working
Group
MUST
publish
a
new
draft
of
at
least
one
of
its
active
technical
reports
on
the
W3C
technical
reports
index
[
PUB11
]
at
least
once
every
three
months.
Public
progress
reports
are
also
important
when
a
Working
Group
does
not
update
a
technical
report
within
three
months
(for
example,
when
the
delay
is
due
to
a
challenging
technical
issue)
or
when
a
Working
Group
has
no
active
technical
reports
(for
example,
because
it
is
developing
a
test
suite).
In
exceptional
cases,
the
Chair
MAY
ask
the
Director
to
be
excused
from
this
publication
requirement.
However,
in
this
case,
the
Working
Group
MUST
issue
a
public
status
report
with
rationale
why
a
new
draft
has
not
been
published.
There
are
several
reasons
for
this
Working
Group
"heartbeat"
requirement:
To
promote
public
accountability;
To
encourage
Working
Groups
to
keep
moving
forward,
and
to
incorporate
their
decisions
into
readable
public
documents.
People
cannot
be
expected
to
read
several
months
of
a
group's
mailing
list
archive
to
understand
where
the
group
stands;
To
notify
interested
parties
of
updated
work
in
familiar
a
place
such
as
the
W3C
home
page
and
index
of
technical
reports.
As
an
example,
suppose
a
Working
Group
has
one
technical
report
as
a
deliverable,
which
it
publishes
as
a
Proposed
Recommendation.
Per
the
heartbeat
requirement,
the
Working
Group
is
required
to
publish
a
new
draft
of
the
Proposed
Recommendation
at
least
once
every
three
months,
even
if
it
is
only
to
revise
the
status
of
the
Proposed
Recommendation
document
(e.g.,
to
provide
an
update
on
the
status
of
the
decision
to
advance).
The
heartbeat
requirement
stops
when
the
document
becomes
a
Recommendation
(or
a
Working
Group
Note).
</del>
6.2.8
<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
<a href="#ACAppeal">
appeal
</a>
by
Advisory
Committee
representatives,
<del class="diff-old">MAY
</del>
<em class="rfc2119">
<ins class="diff-chg">may
</ins></em>
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>
<del class="diff-old">The
Activity
to
which
the
group
belongs
terminates.
</del>
</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="http://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<del class="diff-old">6.3
Coordination
Groups
W3C
Activities
interact
in
many
ways.
There
are
dependencies
between
groups
within
the
same
Activity
or
in
different
Activities.
There
are
also
dependencies
between
W3C
Activities
and
the
activities
of
other
organizations.
Examples
of
dependencies
include
the
use
by
one
technology
of
another
being
developed
elsewhere,
scheduling
constraints
between
groups,
and
the
synchronization
of
publicity
for
the
announcement
of
deliverables.
Coordination
Groups
are
created
to
manage
dependencies
so
that
issues
are
resolved
fairly
and
the
solutions
are
consistent
with
W3C's
mission
and
results.
Where
a
Coordination
Group's
scope
covers
two
groups
with
unresolved
disputes
or
tensions,
it
is
the
first
locus
of
resolution
of
these
disputes.
6.3.1
Coordination
Group
Participation
Requirements
There
are
four
types
participants
in
a
Coordination
Group
:
the
Chair
,
the
Chair
of
each
coordinated
group
(to
promote
effective
communication
among
the
groups),
Invited
Experts
(e.g.,
liaisons
to
groups
inside
or
outside
W3C),
and
Team
representatives
(including
the
Team
Contact
).
The
requirements
for
Invited
Expert
participation
are
the
same
as
for
an
Invited
Expert
in
a
Working
Group
.
Coordination
Group
participants
MUST
follow
the
conflict
of
interest
policy
by
disclosing
information
to
the
rest
of
the
group.
There
are
no
Good
Standing
requirements
for
Coordination
Group
participation;
regular
participation
in
a
relevant
Coordination
Group
is
one
of
the
roles
of
a
group
Chair
[MEM14]
.
6.3.2
Coordination
Group
Creation
and
Closure
The
Director
creates
or
modifies
a
Coordination
Group
by
sending
the
Coordination
Group
charter
to
the
Advisory
Committee.
A
Coordination
Group
MAY
be
created
as
part
of
an
Activity
Proposal
(for
example
to
coordinate
other
groups
in
the
Activity
or
to
draw
up
charters
of
future
groups),
or
during
the
life
of
an
Activity
when
dependencies
arise.
A
Coordination
Group
MAY
operate
as
part
of
several
W3C
Activities.
A
Coordination
Group
SHOULD
close
when
there
is
no
longer
a
perceived
need
for
coordination.
6.3.3
Coordination
Group
Charters
A
Coordination
Group
charter
MUST
include
all
of
the
following
information:
The
group's
mission;
The
scope
of
the
group's
work,
including
the
names
of
coordinated
groups
and
contact
information
for
those
groups;
Any
dependencies
by
groups
within
or
outside
of
W3C
on
this
group;
Any
dependencies
of
this
group
on
other
groups
within
or
outside
of
W3C;
see
the
section
on
liaisons
with
other
organizations
.
The
level
of
confidentiality
of
the
group's
proceedings;
Meeting
mechanisms
and
expected
frequency;
Communication
mechanisms
to
be
employed
within
the
group,
between
the
group
and
the
rest
of
W3C,
and
with
the
general
public;
An
estimate
of
the
expected
time
commitment
from
participants;
The
expected
level
of
involvement
by
the
Team.
A
charter
MAY
include
additional
voting
procedures,
but
those
procedures
MUST
NOT
conflict
with
the
voting
requirements
of
the
Process
Document.
A
charter
MAY
include
provisions
other
than
those
required
by
this
document.
The
charter
SHOULD
highlight
whether
additional
provisions
impose
constraints
beyond
those
of
the
W3C
Process
Document.
</del>
</section>
<h2 id="Reports">
7
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
to
</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="http://www.w3.org/Consortium/Patent-Policy#sec-Licensing">
section
2
</a>
of
the
<a href="http://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</p>
<h3 id="rec-advance">
7.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="http://www.w3.org/TR/">
Technical
Reports
page
http://www.w3.org/TR
</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
Candidate
Recommendation
phase.
This
allows
the
entire
W3C
membership
to
provide
feedback
on
whether
the
specification
<del class="diff-old">should
become
</del>
<ins class="diff-chg">is
appropriate
as
</ins>
a
W3C
Recommendation,
while
the
Working
Group
formally
<del class="diff-old">collects&#160;
</del>
<ins class="diff-chg">collects
</ins>
implementation
experience
to
demonstrate
that
the
specification
works
in
practice.
The
next
phase
is
a
Proposed
Recommendation,
to
finalize
the
review
of
W3C
Members.
If
the
Director
determines
that
W3C
member
review
supports
a
specification
becoming
a
standard,
W3C
publishes
it
as
a
Recommendation.
</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">
7.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 xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" viewbox="0 0 450 60" height="5em" width="45em">
<g id="ToFPWD" stroke="black" fill="black">
<a xlink:href="#first-wd">
</a>
<text font-size="8" font-family="Times,serif" y="38" x="66" text-anchor="start" stroke="none">
First
WD
</text>
<path d="M66,40h33">
</path>
<polygon points="98,36 108,40 98,44">
</polygon>
</g>
<g id="nodeWD">
<ellipse ry="18" rx="38" cy="40" cx="147" stroke="black" fill="none">
</ellipse>
<a xlink:href="#RecsWD">
</a>
<text font-size="14" font-family="Times,serif" y="44" x="147" text-anchor="middle">
WD
</text>
</g>
<g id="repeatWD" stroke="black">
<path d="M128,24C123,14 129,4 147,4 158,4 165,8 167,14" fill="none" stroke-dasharray="6 1">
</path>
<polygon points="170,14 166,24 164,13">
</polygon>
</g>
<g class="edge" id="toCR" stroke="black" fill="black">
<path d="M185,40h31">
</path>
<polygon points="211,36 221,40 211,44">
</polygon>
</g>
<g id="nodeCR">
<ellipse ry="18" rx="38" cy="40" cx="260" stroke="black" fill="none">
</ellipse>
<a xlink:href="#RecsCR">
</a>
<text font-size="14" font-family="Times,serif" y="44" x="260" text-anchor="middle">
CR
</text>
</g>
<g class="edge" id="repeatCR" stroke="black" fill="black">
<path d="M242,24C238,14 244,4 260,4 271,4 277,8 279,14" stroke-dasharray="5 3" fill="none">
</path>
<polygon points="282,14 277,24 275,13">
</polygon>
</g>
<g id="backToWD" stroke="#666" fill="#666">
<path d="M190,47h34" stroke-dasharray="4 4">
</path>
<polygon points="190,45 183,47 190,49">
</polygon>
</g>
<g class="edge" id="ToPR" stroke="black" fill="black">
<path d="M298,40h27">
</path>
<polygon points="324,36 334,40 324,44">
</polygon>
</g>
<g id="nodePR">
<ellipse ry="18" rx="28" cy="40" cx="363" stroke="black" fill="none">
</ellipse>
<a xlink:href="#RecsPR">
</a>
<text font-size="14" font-family="Times,serif" y="44" x="363" text-anchor="middle">
PR
</text>
</g>
<g id="BackToCR" stroke="#aaa" fill="#aaa">
<path d="M301,47h38" stroke-dasharray="2 5">
</path>
<polygon points="301,45 296,47 301,49">
</polygon>
</g>
<g id="ToRec" stroke="black" fill="black">
<path d="M391,40h20">
</path>
<polygon points="404,36 414,40 404,44">
</polygon>
</g>
<g id="nodeRec">
<ellipse ry="18" rx="28" cy="40" cx="443" stroke="black" fill="none">
</ellipse>
<a xlink:href="#RecsW3C">
</a>
<text font-size="14" font-family="Times,serif" y="44" x="443" text-anchor="middle">
REC
</text>
</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">
7.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
<ins class="diff-new">it
is
time
to
do
</ins>
a
final
review
<del class="diff-old">should
be
done
</del>
</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
as
per
the
<a href="http://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
which
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="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>
<dt id="RescindedRec">
Rescinded
Recommendation
</dt>
<dd>
A
Rescinded
Recommendation
is
an
entire
Recommendation
that
W3C
no
longer
endorses.
See
also
clause
10
of
the
licensing
requirements
for
W3C
Recommendations
in
<a href="http://www.w3.org/Consortium/Patent-Policy#sec-Requirements">
section
5
</a>
of
the
<a href="http://www.w3.org/Consortium/Patent-Policy">
W3C
Patent
Policy
</a>
[
<a href="#ref-patentpolicy">
PUB33
</a>
].
</dd>
</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">
7.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="http://www.w3.org/TR/">
Technical
Reports
page
http://www.w3.org/TR
<del class="diff-old">.
</del>
</a>
<ins class="diff-chg">[
</ins><a href="#rdf-doc-list"><ins class="diff-chg">
PUB11
</ins></a><ins class="diff-chg">
].
</ins>
</p>
<h4 id="general-requirements">
7.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="http://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
<