1 Introduction
Most W3C work revolves around the standardization of Web technologies. To accomplish this work, W3C follows processes that promote the development of high-quality standards based on the consensus of the Membership, Team, and public. W3C processes promote fairness, responsiveness, and progress: all facets of the W3C mission. This document describes the processes W3C follows in pursuit of its mission.
Here is a general overview of how W3C standardizes a Web technology. In many cases, the goal of this work is a W3C Recommendation , the W3C equivalent of a Web standard.
-
People
generate
interest
in
a
particular
topic
(e.g.,
Web
services).
For
instance,
Members
express
interest
in
the
form
of
Member
Submissions
,
and
the
Team
monitors
work
inside
and
outside
of
W3C
for
signs
of
interest.
Also,
W3C
is
likely
to
organize
a
Workshop
to
bring
people
together
to
discuss
topics
that
interest
the
W3C
community.
This was the case, for example, with Web services. -
When
there
is
enough
interest
in
a
topic
(e.g.,
after
a
successful
Workshop
and/or
discussion
on
an
Advisory
Committee
mailing
list
),
the
Director
announces
the
development
of
a
proposal
for
a new Activityone or more new Interest Group or Working Groupchartercharters , depending on the breadth of the topic of interest.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.W3C Members revieweach Activity Proposalandtheassociated Working Groupproposed charters. When there is support within W3C for investing resources in the topic of interest, the Director approves thenew Activitygroup(s) andgroups get down tothey begin their work.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. - There are three types of Working Group participants: Member representatives , Invited Experts , and Team representatives . Team representatives both contribute to the technical work and help ensure the group's proper integration with the rest of W3C. The Working Group charter sets expectations about each group's deliverables (e.g., technical reports , test suites, and tutorials).
- Working Groups generally create specifications and guidelines that undergo cycles of revision and review as they advance to W3C Recommendation status. The W3C process for producing these technical reports includes significant review by the Members and public, and requirements that the Working Group be able to show implementation and interoperability experience. At the end of the process, the Advisory Committee reviews the mature technical report, and if there is support, W3C publishes it as a Recommendation .
The Process Document promotes the goals of quality and fairness in technical decisions by encouraging consensus , requiring reviews (by both Members and public) as part of the technical report development process , and through an appeal process for the Advisory Committee.
The other sections of the Process Document:
- set forth policies for participation in W3C groups,
- establish two permanent groups within W3C: the Technical Architecture Group (TAG) , to help resolve Consortium-wide technical issues; and the Advisory Board (AB) , to help resolve Consortium-wide non-technical issues, and to manage the evolution of the W3C process , and
- describe other interactions between the Members (as represented by the W3C Advisory Committee ), the Team, and the general public.
2 Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group
W3C's mission is to lead the Web to its full potential. W3C Member organizations provide resources to this end, and the W3C Team provides the technical leadership and organization to coordinate the effort.
2.1 Members
W3C Members are primarily represented in W3C processes as follows:
-
The
Advisory
Committee
is
composed
of
one
representative
from
each
Member
organization
(refer
to
the
Member-only
list
of
current
Advisory
Committee
representatives
[
MEM1
]).
The
Advisory
Committee:
- reviews plans for W3C at each Advisory Committee meeting ;
-
reviews
formal
proposals
from
the
W3C
Director:
ActivityCharter Proposals , Proposed Recommendations , and Proposed Process Documents . - elects the Advisory Board participants other than the Advisory Board Chair.
- elects 5 of the 9 participants on the Technical Architecture Group .
-
Representatives
of
Member
organizations
participate
in
Working
Groups, Interest Groups,Groups andCoordinationInterest Groups and author and review technical reports .
W3C
membership
is
open
to
all
entities,
as
described
in
"
How
to
Join
W3C
"
[
PUB5
];
(refer
to
the
public
list
of
current
W3C
Members
[
PUB8
]).
Organizations
subscribe
according
to
the
Membership
Agreement
[
PUB6
].
The
Team
MUST
must
ensure
that
Member
participation
agreements
remain
Team-only
and
that
no
Member
receives
preferential
treatment
within
W3C.
W3C
does
not
have
a
class
of
membership
tailored
to,
or
priced
for
individuals
.
individuals.
However,
an
individual
MAY
may
join
W3C
as
an
Affiliate
Member.
In
this
case
the
same
restrictions
pertaining
to
related
Members
apply
when
the
individual
also
represents
another
W3C
Member.
2.1.1 Rights of Members
Each Member organization enjoys the following rights and benefits:
- A seat on the Advisory Committee ;
- Access to Member-only information;
- The Member Submission process;
- Use of the W3C Member logo on promotional material and to publicize the Member's participation in W3C. For more information, please refer to the Member logo usage policy described in the New Member Orientation [ MEM4 ].
Furthermore, representatives of Member organizations participate in W3C as follows:
-
In
Working
Groups, Interest Groups,Groups andCoordinationInterest Groups . - In Workshops and Symposia ;
- On the Team, as W3C Fellows .
In
the
case
(described
in
paragraph
5g
of
the
Membership
Agreement
),
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
MAY
may
designate
up
to
four
(or
more
at
the
Team's
discretion)
individuals
who,
though
not
employed
by
the
organization,
MAY
may
exercise
the
rights
of
Member
representatives
.
These
individuals
MUST
must
disclose
their
employment
affiliation
when
participating
in
W3C
work.
Provisions
for
related
Members
apply.
Furthermore,
these
individuals
are
expected
to
represent
the
broad
interests
of
the
W3C
Member
organization
and
not
the
parochial
interests
of
their
employers.
The
rights
and
benefits
of
W3C
membership
are
contingent
upon
conformance
to
the
processes
described
in
this
document.
The
vast
majority
of
W3C
Members
faithfully
follow
the
spirit
as
well
as
the
letter
of
these
processes.
When
serious
and/or
repeated
violations
do
occur,
and
repeated
attempts
to
address
these
violations
have
not
resolved
the
situation,
the
Director
MAY
may
take
disciplinary
action.
Arbitration
in
the
case
of
further
disagreement
is
governed
by
paragraph
19
of
the
Membership
Agreement.
Refer
to
the
Guidelines
for
Disciplinary
Action
[
MEM14
].
2.1.2 Related Members
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:
- Either Member is a subsidiary of the other, or
- Both Members are subsidiaries of a common entity, or
- The Members have an employment contract or consulting contract that affects W3C participation.
A subsidiary is an organization of which effective control and/or majority ownership rests with another, single organization.
Related
Members
MUST
must
disclose
these
relationships
according
to
the
mechanisms
described
in
the
New
Member
Orientation
[
MEM4
].
2.1.3 Advisory Committee (AC)
When
an
organization
joins
W3C
(see
"
How
to
Join
W3C
"
[
PUB5
]),
it
MUST
must
name
its
Advisory
Committee
representative
as
part
of
the
Membership
Agreement.
The
New
Member
Orientation
explains
how
to
subscribe
or
unsubscribe
to
Advisory
Committee
mailing
lists,
provides
information
about
Advisory
Committee
meetings,
explains
how
to
name
a
new
Advisory
Committee
representative,
and
more.
Advisory
Committee
representatives
MUST
must
follow
the
conflict
of
interest
policy
by
disclosing
information
according
to
the
mechanisms
described
in
the
New
Member
Orientation.
See
also
the
additional
roles
of
Advisory
Committee
representatives
described
in
the
W3C
Patent
Policy
[
PUB33
].
Additional information for Members is available at the Member Web site [ MEM6 ].
2.1.3.1 Advisory Committee Mailing Lists
The
Team
MUST
must
provide
two
mailing
lists
for
use
by
the
Advisory
Committee:
- 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.
-
One
for
discussion
among
Advisory
Committee
representatives.
Though
this
list
is
primarily
for
Advisory
Committee
representatives,
the
Team
MUSTmust monitor discussion andSHOULDshould participate in discussion when appropriate. Ongoing detailed discussionsSHOULDshould be moved to other appropriate lists (new or existing, such as a mailing list created for a Workshop ).
An
Advisory
Committee
representative
MAY
may
request
that
additional
individuals
from
their
organization
be
subscribed
to
these
lists.
Failure
to
contain
distribution
internally
MAY
may
result
in
suspension
of
additional
email
addresses,
at
the
discretion
of
the
Team.
2.1.3.2 Advisory Committee Meetings
The
Team
organizes
a
face-to-face
meeting
for
the
Advisory
Committee
twice
a
year
.
The
Team
appoints
the
Chair
of
these
meetings
(generally
the
W3C
Chair
or
Chief
Operating
Officer
CEO
).
At
each
Advisory
Committee
meeting,
the
Team
SHOULD
should
provide
an
update
to
the
Advisory
Committee
about:
- Resources
-
- The number of Full and Affiliate W3C Members.
- An overview of the financial status of W3C.
- Allocations
-
- The allocation of the annual budget, including size of the Team and their approximate deployment.
-
A
list
of
all
Activitiesactivities (including but not limited to Working and Interest Groups) and brief status statement about each, in particular those started or terminated since the previous Advisory Committee meeting. - The allocation of resources to pursuing liaisons with other organizations.
Each
Member
organization
SHOULD
should
send
one
representative
to
each
Advisory
Committee
meeting.
In
exceptional
circumstances
(e.g.,
during
a
period
of
transition
between
representatives
from
an
organization),
the
meeting
Chair
MAY
may
allow
a
Member
organization
to
send
two
representatives
to
a
meeting.
The
Team
MUST
must
announce
the
date
and
location
of
each
Advisory
Committee
meeting
no
later
than
at
the
end
of
the
previous
meeting;
one
year's
notice
is
preferred.
The
Team
MUST
must
announce
the
region
of
each
Advisory
Committee
meeting
at
least
one
year
in
advance.
More information about Advisory Committee meetings [ MEM5 ] is available at the Member Web site.
2.2 The W3C Team
The
Team
consists
of
the
Director,
CEO,
W3C
paid
staff,
unpaid
interns,
and
W3C
Fellows.
W3C
Fellows
are
Member
employees
working
as
part
of
the
Team;
see
the
W3C
Fellows
Program
[
PUB32
].
The
Team
provides
technical
leadership
about
Web
technologies,
organizes
and
manages
W3C
Activities
activities
to
reach
goals
within
practical
constraints
(such
as
resources
available),
and
communicates
with
the
Members
and
the
public
about
the
Web
and
W3C
technologies.
The
Team
is
led
by
the
Director,
W3C
Chair,
Director
and
Chief
Operating
Officer.
These
individuals
MAY
CEO
may
delegate
responsibility
(generally
to
other
individuals
in
the
Team)
for
any
of
their
roles
described
in
this
document.
The
Director
is
the
lead
technical
architect
at
W3C
and
as
such,
is
responsible
for
W3C.
His
responsibilities
are
identified
throughout
this
document
in
relevant
places
Some
key
ones
include:
assessing
consensus
within
W3C
for
architectural
choices,
publication
of
technical
reports
,
and
chartering
new
Activities
.
The
Director
appoints
Groups;
appointing
group
Chairs
and
has
the
role
of
;
"tie-breaker"
for
questions
of
Good
Standing
in
a
Working
Group
or
appeal
of
a
Working
Group
decision
.
The
and
deciding
on
the
outcome
of
formal
objections;
the
Director
is
generally
Chair
of
the
TAG
.
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.
Team
administrative
information
such
as
Team
salaries,
detailed
budgeting,
and
other
business
decisions
are
Team-only
,
subject
to
oversight
by
the
Host
institutions.
Note:
W3C
is
not
currently
incorporated.
For
legal
contracts,
W3C
is
represented
by
three
four
"Host"
institutions
:
:
Beihang
University,
the
European
Research
Consortium
for
Informatics
and
Mathematics
(
ERCIM
),
Keio
University,
and
the
Massachusetts
Institute
of
Technology
(
MIT
).
Within
W3C,
the
Host
institutions
are
governed
by
joint
sponsorship
contracts;
hosting
agreements;
the
Hosts
themselves
are
not
W3C
Members.
2.2.1 Team Submissions
Team
members
MAY
may
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
Member
Submissions
(e.g.,
in
expected
scope
).
However,
there
is
no
additional
Team
comment.
The
document
status
section
of
a
Team
Submission
indicates
the
level
of
Team
consensus
about
the
published
material.
Team Submissions are not part of the technical report development process .
The list of published Team Submissions [ PUB16 ] is available at the W3C Web site.
2.3 Advisory Board (AB)
Created in March 1998, the Advisory Board provides ongoing guidance to the Team on issues of strategy, management, legal matters, process, and conflict resolution. The Advisory Board also serves the Members by tracking issues raised between Advisory Committee meetings, soliciting Member comments on such issues, and proposing actions to resolve these issues. The Advisory Board manages the evolution of the Process Document . The Advisory Board hears appeals of Member Submission requests that are rejected for reasons unrelated to Web architecture; see also the TAG .
The Advisory Board is not a board of directors and has no decision-making authority within W3C; its role is strictly advisory.
The
Team
MUST
must
make
available
a
mailing
list
for
the
Advisory
Board
to
use
for
its
communication,
confidential
to
the
Advisory
Board
and
Team.
The
Advisory
Board
SHOULD
should
send
a
summary
of
each
of
its
meetings
to
the
Advisory
Committee
and
other
group
Chairs.
The
Advisory
Board
SHOULD
should
also
report
on
its
activities
at
each
Advisory
Committee
meeting
.
Details about the Advisory Board (e.g., the list of Advisory Board participants, mailing list information, and summaries of Advisory Board meetings) are available at the Advisory Board home page [ PUB30 ].
2.3.1 Advisory Board Participation
The
Advisory
Board
consists
of
nine
elected
participants
and
a
Chair.
The
Team
appoints
the
Chair
of
the
Advisory
Board
,
who
is
generally
the
W3C
Chair
CEO
.
The remaining nine Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process .
With the exception of the Chair, the terms of all Advisory Board participants are for two years . Terms are staggered so that each year, either 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.
2.4 Technical Architecture Group (TAG)
Created in February 2001, the mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:
- to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;
- to resolve issues involving general Web architecture brought to the TAG;
- to help coordinate cross-technology architecture developments inside and outside W3C.
The TAG hears appeals of Member Submission requests that are rejected for reasons related to Web architecture; see also the Advisory Board .
The
TAG's
scope
is
limited
to
technical
issues
about
Web
architecture.
The
TAG
SHOULD
NOT
should
not
consider
administrative,
process,
or
organizational
policy
issues
of
W3C,
which
are
generally
addressed
by
the
W3C
Advisory
Committee,
Advisory
Board,
and
Team.
Please
refer
to
the
TAG
charter
[
PUB25
]
for
more
information
about
the
background
and
scope
of
the
TAG,
and
the
expected
qualifications
of
TAG
participants.
The
Team
MUST
must
make
available
two
mailing
lists
for
the
TAG:
- a public discussion (not just input) list for issues of Web architecture. The TAG will conduct its public business on this list.
- a Member-only list for discussions within the TAG and for requests to the TAG that, for whatever reason, cannot be made on the public list.
The
TAG
MAY
may
also
request
the
creation
of
additional
topic-specific,
public
mailing
lists.
For
some
TAG
discussions
(e.g.,
an
appeal
of
a
rejected
Member
Submission
request
),
the
TAG
MAY
may
use
a
list
that
will
be
Member-only
.
The
TAG
SHOULD
should
send
a
summary
of
each
of
its
meetings
to
the
Advisory
Committee
and
other
group
Chairs.
The
TAG
SHOULD
should
also
report
on
its
activities
at
each
Advisory
Committee
meeting
.
When the TAG votes to resolve an issue, each TAG participant (whether appointed, elected, or the Chair) has one vote; see also the section on voting in the TAG charter [ PUB25 ] and the general section on votes in this Process Document.
Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) are available at the TAG home page [ PUB26 ].
2.4.1 Technical Architecture Group Participation
The TAG consists of eight elected or appointed participants and a Chair. The Team appoints the Chair of the TAG, who is generally the Director .
Three
TAG
participants
are
appointed
by
the
Director.
Appointees
are
NOT
REQUIRED
not
required
to
be
on
the
W3C
Team.
The
Director
MAY
may
appoint
W3C
Fellows
to
the
TAG.
The remaining five TAG participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process .
With the exception of the Chair, the terms of all TAG participants are for two years . 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.
2.5 Advisory Board and Technical Architecture Group Participation
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.
Good
Standing
rules
as
defined
for
Working
Group
participants
also
apply
to
Advisory
Board
and
TAG
participants.
Advisory
Board
and
TAG
participants
SHOULD
should
attend
Advisory
Committee
meetings
.
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 vacated . Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, their participation does carry the responsibilities associated with Member representation, Invited Expert status, or Team representation (as described in the section on the AB/TAG nomination and election process ). See also the licensing obligations on TAG participants in section 3 of the W3C Patent Policy [ PUB33 ], and the claim exclusion process of section 4 .
2.5.1 Advisory Board and Technical Architecture Group Participation Constraints
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:
-
A
Member
organization
is
permitted
at
most
one
participant
on
the
TAG.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 must have returned to having at most one participant. - A Member organization is permitted at most one participant on the AB.
-
An
individual
MUST NOTmust not participate on both the TAG and the AB.
If,
for
whatever
reason,
these
constraints
are
not
satisfied
(e.g.,
because
a
TAG
or
an
AB
participant
changes
jobs),
one
participant
MUST
must
cease
TAG
or
AB
participation
until
the
situation
has
been
resolved.
If
after
30
days
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
verifiable
random
selection
procedure
described
below
will
be
used
to
choose
one
person
for
continued
participation.
2.5.2 Advisory Board and Technical Architecture Group Elections
The
Advisory
Board
and
a
portion
of
the
Technical
Architecture
Group
are
elected
by
the
Advisory
Committee.
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
SHOULD
should
announce
appointments
no
later
than
the
start
of
a
nomination
period,
and
generally
as
part
of
the
Call
for
Nominations.
Each
Member
(or
group
of
related
Members
)
MAY
may
nominate
one
individual.
A
nomination
MUST
must
be
made
with
the
consent
of
the
nominee.
In
order
for
an
individual
to
be
nominated
as
a
Member
representative,
the
individual
MUST
must
qualify
for
Member
representation
and
the
Member's
Advisory
Committee
representative
MUST
must
include
in
the
nomination
the
(same)
information
required
for
a
Member
representative
in
a
Working
Group
.
In
order
for
an
individual
to
be
nominated
as
an
Invited
Expert,
the
individual
MUST
must
provide
the
(same)
information
required
for
an
Invited
Expert
in
a
Working
Group
and
the
nominating
Advisory
Committee
representative
MUST
must
include
that
information
in
the
nomination.
In
order
for
an
individual
to
be
nominated
as
a
Team
representative,
the
nominating
Advisory
Committee
representative
MUST
must
first
secure
approval
from
Team
management.
A
nominee
is
NOT
REQUIRED
not
required
to
be
an
employee
of
a
Member
organization,
and
MAY
may
be
a
W3C
Fellow
.
Each
nomination
SHOULD
should
include
a
few
informative
paragraphs
about
the
nominee.
If, after the deadline for nominations, the number of nominees is:
- Equal to the number of available seats, those nominees are thereby elected. This situation constitutes a tie for the purposes of assigning short terms .
- 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.
- 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.
When
there
is
a
vote,
each
Member
(or
group
of
related
Members
)
MAY
may
vote
for
as
many
candidates
as
there
are
available
seats;
see
the
section
on
Advisory
Committee
votes
.
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
verifiable
random
selection
procedure
described
below
will
be
used
to
fill
the
available
seats.
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 verifiable random selection procedure described below will be used to assign the short term.
Refer to How to Organize an Advisory Board or TAG election [ MEM15 ] for more details.
2.5.2.1 Verifiable Random Selection Procedure
When it is necessary to use a verifiable random selection process (e.g., in an AB or TAG election, to "draw straws" in case of a tie or to fill a short term), W3C uses the random and verifiable procedure defined in RFC 2777 [ RFC2777 ]. The procedure orders an input list of names (listed in alphabetical order by family name unless otherwise specified) into a "result order."
W3C applies this procedure as follows:
- 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.
- After all elected individuals have been identified, when N people are eligible for M (less than N) short terms. In this case, only the names of those N individuals are provided as input to the procedure. The short terms are assigned in result order.
2.5.3 Advisory Board and Technical Architecture Group Vacated Seats
An Advisory Board or TAG participant's seat is vacated when either of the following occurs:
- the participant resigns , or
-
the
Chair
asks
the
participant
to
resign
, for example because the participant has failed to remain in Good Standing.
When
an
Advisory
Board
or
TAG
participant
changes
affiliations,
as
long
as
Advisory
Board
and
TAG
participation
constraints
are
respected,
the
individual
MAY
may
continue
to
participate
until
the
next
regularly
scheduled
election
for
that
group.
Otherwise,
the
seat
is
vacated.
Vacated seats are filled according to this schedule:
-
When
an
appointed
TAG
seat
is
vacated,
the
Director
MAYmay re-appoint someone immediately, but no later than the next regularly scheduled election. -
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
SHOULD NOTshould not request an exceptional election if the next regularly scheduled election is fewer than three months away.
3 General Policies for W3C Groups
This
section
describes
general
policies
for
W3C
groups
regarding
participation,
meeting
requirements,
and
decision-making.
These
policies
apply
to
participants
in
the
following
groups:
Advisory
Committee
,
Advisory
Board
,
TAG
,
Working
Groups
,
and
Interest
Groups
,
and
Coordination
Groups
.
3.1 Individual Participation Criteria
There are three qualities an individual is expected to demonstrate in order to participate in W3C:
- Technical competence in one's role
- The ability to act fairly
- Social competence in one's role
Advisory
Committee
representatives
who
nominate
individuals
from
their
organization
for
participation
in
W3C
Activities
activities
are
responsible
for
assessing
and
attesting
to
the
qualities
of
those
nominees.
See also the participation requirements described in section 6 of the W3C Patent Policy [ PUB33 ].
3.1.1 Conflict of Interest Policy
Individuals
participating
materially
in
W3C
work
MUST
must
disclose
significant
relationships
when
those
relationships
might
reasonably
be
perceived
as
creating
a
conflict
of
interest
with
the
individual's
role
at
W3C.
These
disclosures
MUST
must
be
kept
up-to-date
as
the
individual's
affiliations
change
and
W3C
membership
evolves
(since,
for
example,
the
individual
might
have
a
relationship
with
an
organization
that
joins
or
leaves
W3C).
Each
section
in
this
document
that
describes
a
W3C
group
provides
more
detail
about
the
disclosure
mechanisms
for
that
group.
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
MUST
must
be
evaluated.
The
role
MAY
may
be
reassigned
according
to
the
appropriate
process.
For
instance,
the
Director
MAY
may
appoint
a
new
group
Chair
when
the
current
Chair
changes
affiliations
(e.g.,
if
there
is
a
risk
of
conflict
of
interest,
or
if
there
is
risk
that
the
Chair's
new
employer
will
be
over-represented
within
a
W3C
Activity).
activity).
The following are some scenarios where disclosure is appropriate:
- 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).
- A decision-making role/responsibility (such as participating on the Board) in other organizations relevant to W3C.
- A position on a publicly visible advisory body, even if no decision making authority is involved.
Individuals
seeking
assistance
on
these
matters
SHOULD
should
contact
the
Team.
Team members are subject to the W3C Team conflict of interest policy [ PUB23 ].
3.1.2 Individuals Representing a Member Organization
Generally,
individuals
representing
a
Member
in
an
official
capacity
within
W3C
are
employees
of
the
Member
organization.
However,
an
Advisory
Committee
representative
MAY
may
designate
a
non-employee
to
represent
the
Member.
Non-employee
Member
representatives
MUST
must
disclose
relevant
affiliations
to
the
Team
and
to
any
group
in
which
the
individual
participates.
In
exceptional
circumstances
(e.g.,
situations
that
might
jeopardize
the
progress
of
a
group
or
create
a
conflict
of
interest
),
the
Director
MAY
may
decline
to
allow
an
individual
designated
by
an
Advisory
Committee
representative
to
participate
in
a
group.
A
group
charter
MAY
may
limit
the
number
of
individuals
representing
a
W3C
Member
(or
group
of
related
Members
).
3.2 Meetings
W3C
groups
(including
the
Advisory
Committee
,
Advisory
Board
,
TAG
,
and
Working
Groups
)
SHOULD
should
observe
the
meeting
requirements
in
this
section.
W3C distinguishes two types of meetings:
- A face-to-face meeting is one where most of the attendees are expected to participate in the same physical location.
- A distributed meeting is one where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC ).
A
Chair
MAY
may
invite
an
individual
with
a
particular
expertise
to
attend
a
meeting
on
an
exceptional
basis.
This
person
is
a
meeting
guest,
not
a
group
participant
.
Meeting
guests
do
not
have
voting
rights
.
It
is
the
responsibility
of
the
Chair
to
ensure
that
all
meeting
guests
respect
the
chartered
level
of
confidentiality
and
other
group
requirements.
Meeting
announcements
SHOULD
should
be
sent
to
all
appropriate
group
mailing
lists,
i.e.,
those
most
relevant
to
the
anticipated
meeting
participants.
The following table lists requirements for organizing a meeting:
|
Face-to-face meetings | Distributed meetings |
---|---|---|
Meeting announcement (before) | eight weeks * | one week * |
Agenda available (before) | two weeks | 24 hours (or longer if a meeting is scheduled after a weekend or holiday) |
Participation confirmed (before) | three days | 24 hours |
Action items available (after) | three days | 24 hours |
Minutes available (after) | two weeks | 48 hours |
* To allow proper planning (e.g., travel arrangements), the Chair is responsible for giving sufficient advance notice about the date and location of a meeting. Shorter notice for a meeting is allowed provided that there are no objections from group participants.
3.3 Consensus
Consensus
is
a
core
value
of
W3C.
To
promote
consensus,
the
W3C
process
requires
Chairs
to
ensure
that
groups
consider
all
legitimate
views
and
objections,
and
endeavor
to
resolve
them,
whether
these
views
and
objections
are
expressed
by
the
active
participants
of
the
group
or
by
others
(e.g.,
another
W3C
group,
a
group
in
another
organization,
or
the
general
public).
Decisions
MAY
may
be
made
during
meetings
(
face-to-face
or
distributed
)
as
well
as
through
email.
Note:
The
Director,
W3C
Chair,
CEO,
and
COO
have
the
role
of
assessing
consensus
within
the
Advisory
Committee.
The following terms are used in this document to describe the level of support for a decision among a set of eligible individuals:
-
Consensus
:: A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection . Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set. Unanimity is the particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains). -
Dissent
:: At least one individual in the set registers a Formal Objection .
By
default,
the
set
of
individuals
eligible
to
participate
in
a
decision
is
the
set
of
group
participants
in
Good
Standing
.
participants.
The
Process
Document
does
not
require
a
quorum
for
decisions
(i.e.,
the
minimal
number
of
eligible
participants
required
to
be
present
before
the
Chair
can
call
a
question).
A
charter
MAY
may
include
a
quorum
requirement
for
consensus
decisions.
Where
unanimity
is
not
possible,
a
group
SHOULD
should
strive
to
make
consensus
decisions
where
there
is
significant
support
and
few
abstentions.
The
Process
Document
does
not
require
a
particular
percentage
of
eligible
participants
to
agree
to
a
motion
in
order
for
a
decision
to
be
made.
To
avoid
decisions
where
there
is
widespread
apathy,
(i.e.,
little
support
and
many
abstentions),
groups
SHOULD
should
set
minimum
thresholds
of
active
support
before
a
decision
can
be
recorded.
The
appropriate
percentage
MAY
may
vary
depending
on
the
size
of
the
group
and
the
nature
of
the
decision.
A
charter
MAY
may
include
threshold
requirements
for
consensus
decisions.
For
instance,
a
charter
might
require
a
supermajority
of
eligible
participants
(i.e.,
some
established
percentage
above
50%)
to
support
certain
types
of
consensus
decisions.
3.3.1 Managing Dissent
In
some
cases,
even
after
careful
consideration
of
all
points
of
view,
a
group
might
find
itself
unable
to
reach
consensus.
The
Chair
MAY
may
record
a
decision
where
there
is
dissent
(i.e.,
there
is
at
least
one
Formal
Objection
)
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
SHOULD
should
move
on.
Groups
SHOULD
should
favor
proposals
that
create
the
weakest
objections.
This
is
preferred
over
proposals
that
are
supported
by
a
large
majority
but
that
cause
strong
objections
from
a
few
people.
As
part
of
making
a
decision
where
there
is
dissent,
the
Chair
is
expected
to
be
aware
of
which
participants
work
for
the
same
(or
related
)
Member
organizations
and
weigh
their
input
accordingly.
3.3.2 Recording and Reporting Formal Objections
In the W3C process, an individual may register a Formal Objection to a decision. A Formal Objection to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g., in response to a request to advance a technical report). Note: In this document, the term "Formal Objection" is used to emphasize this process implication: Formal Objections receive Director consideration. The word "objection" used alone has ordinary English connotations.
An
individual
who
registers
a
Formal
Objection
SHOULD
should
cite
technical
arguments
and
propose
changes
that
would
remove
the
Formal
Objection;
these
proposals
MAY
may
be
vague
or
incomplete.
Formal
Objections
that
do
not
provide
substantive
arguments
or
rationale
are
unlikely
to
receive
serious
consideration
by
the
Director.
A
record
of
each
Formal
Objection
MUST
must
be
publicly
available
.
A
Call
for
Review
(of
a
document)
to
the
Advisory
Committee
MUST
must
identify
any
Formal
Objections.
3.3.3 Formally Addressing an Issue
In
the
context
of
this
document,
a
group
has
formally
addressed
an
issue
when
it
has
sent
a
public,
substantive
response
to
the
reviewer
who
raised
the
issue.
A
substantive
response
is
expected
to
include
rationale
for
decisions
(e.g.,
a
technical
explanation,
a
pointer
to
charter
scope,
or
a
pointer
to
a
requirements
document).
The
adequacy
of
a
response
is
measured
against
what
a
W3C
reviewer
would
generally
consider
to
be
technically
sound.
If
a
group
believes
that
a
reviewer's
comments
result
from
a
misunderstanding,
the
group
SHOULD
should
seek
clarification
before
reaching
a
decision.
As
a
courtesy,
both
Chairs
and
reviewers
SHOULD
should
set
expectations
for
the
schedule
of
responses
and
acknowledgments.
The
group
SHOULD
should
reply
to
a
reviewer's
initial
comments
in
a
timely
manner.
The
group
SHOULD
should
set
a
time
limit
for
acknowledgment
by
a
reviewer
of
the
group's
substantive
response;
a
reviewer
cannot
block
a
group's
progress.
It
is
common
for
a
reviewer
to
require
a
week
or
more
to
acknowledge
and
comment
on
a
substantive
response.
The
group's
responsibility
to
respond
to
reviewers
does
not
end
once
a
reasonable
amount
of
time
has
elapsed.
However,
reviewers
SHOULD
should
realize
that
their
comments
will
carry
less
weight
if
not
sent
to
the
group
in
a
timely
manner.
Substantive
responses
SHOULD
should
be
recorded.
The
group
SHOULD
should
maintain
an
accurate
summary
of
all
substantive
issues
and
responses
to
them
(e.g.,
in
the
form
of
an
issues
list
with
links
to
mailing
list
archives).
3.3.4 Reopening a Decision When Presented With New Information
The
Chair
MAY
may
reopen
a
decision
when
presented
with
new
information,
including:
- additional technical information,
- comments by email from participants who were unable to attend a scheduled meeting,
- comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues or for cultural reasons).
The
Chair
SHOULD
should
record
that
a
decision
has
been
reopened,
and
MUST
must
do
so
upon
request
from
a
group
participant.
3.4 Votes
A
group
SHOULD
should
only
conduct
a
vote
to
resolve
a
substantive
issue
after
the
Chair
has
determined
that
all
available
means
of
reaching
consensus
through
technical
discussion
and
compromise
have
failed,
and
that
a
vote
is
necessary
to
break
a
deadlock.
In
this
case
the
Chair
MUST
must
record
(e.g.,
in
the
minutes
of
the
meeting
or
in
an
archived
email
message):
- an explanation of the issue being voted on;
- the decision to conduct a vote (e.g., a simple majority vote) to resolve the issue;
- the outcome of the vote;
- any Formal Objections.
In
order
to
vote
to
resolve
a
substantive
issue,
an
individual
MUST
must
be
a
group
participant
in
Good
Standing
.
Each
organization
represented
in
the
group
MUST
must
have
at
most
one
vote,
even
when
the
organization
is
represented
by
several
participants
in
the
group
(including
Invited
Experts).
For
the
purposes
of
voting:
- A Member or group of related Members is considered a single organization.
- The Team is considered an organization.
Unless
the
charter
states
otherwise,
Invited
Experts
MAY
may
vote.
If
a
participant
is
unable
to
attend
a
vote,
that
individual
MAY
may
authorize
anyone
at
the
meeting
to
act
as
a
proxy
.
.
The
absent
participant
MUST
must
inform
the
Chair
in
writing
who
is
acting
as
proxy,
with
written
instructions
on
the
use
of
the
proxy.
For
a
Working
Group
or
Interest
Group,
see
the
related
requirements
regarding
an
individual
who
attends
a
meeting
as
a
substitute
for
a
participant.
A
group
MAY
may
vote
for
other
purposes
than
to
resolve
a
substantive
issue.
For
instance,
the
Chair
often
conducts
a
"straw
poll"
vote
as
a
means
of
determining
whether
there
is
consensus
about
a
potential
decision.
A
group
MAY
may
also
vote
to
make
a
process
decision.
For
example,
it
is
appropriate
to
decide
by
simple
majority
whether
to
hold
a
meeting
in
San
Francisco
or
San
Jose
(there's
not
much
difference
geographically).
When
simple
majority
votes
are
used
to
decide
minor
issues,
the
minority
are
NOT
REQUIRED
not
required
to
state
the
reasons
for
their
dissent,
and
the
group
is
NOT
REQUIRED
not
required
to
record
individual
votes.
A
group
charter
SHOULD
should
include
formal
voting
procedures
(e.g.,
quorum
or
threshold
requirements)
for
making
decisions
about
substantive
issues.
Procedures for Advisory Committee votes are described separately.
3.5 Appeal of a Chair's Decision
Groups
resolve
issues
through
dialog.
Individuals
who
disagree
strongly
with
a
decision
SHOULD
should
register
with
the
Chair
any
Formal
Objections
(e.g.,
to
a
decision
made
as
the
result
of
a
vote
).
When
group
participants
believe
that
their
concerns
are
not
being
duly
considered
by
the
group,
they
MAY
may
ask
the
Director
(for
representatives
of
a
Member
organization,
via
their
Advisory
Committee
representative)
to
confirm
or
deny
the
decision.
The
participants
SHOULD
should
also
make
their
requests
known
to
the
Team
Contact
.
The
Team
Contact
MUST
must
inform
the
Director
when
a
group
participant
has
raised
concerns
about
due
process.
Any
requests
to
the
Director
to
confirm
a
decision
MUST
must
include
a
summary
of
the
issue
(whether
technical
or
procedural),
decision,
and
rationale
for
the
objection.
All
counter-arguments,
rationales,
and
decisions
MUST
must
be
recorded.
Procedures for Advisory Committee appeals are described separately.
3.6 Resignation from a Group
A
W3C
Member
or
Invited
Expert
MAY
may
resign
from
a
group.
The
Team
On
written
notification
from
an
Advisory
Committee
representative
or
Invited
Expert
to
the
team,
the
Member
and
their
representatives
or
the
Invited
Expert
will
establish
administrative
procedures
for
resignation.
be
deemed
to
have
resigned
from
the
relevant
group.
See
section
4.2.
of
the
W3C
Patent
Policy
[
PUB33
]
for
information
about
obligations
remaining
after
resignation
from
certain
groups.
4 Dissemination Policies
The
Team
is
responsible
for
managing
communication
within
W3C
and
with
the
general
public
(e.g.,
news
services,
press
releases,
managing
the
Web
site
and
access
privileges,
and
managing
calendars).
Members
SHOULD
should
solicit
review
by
the
Team
prior
to
issuing
press
releases
about
their
work
within
W3C.
The Team makes every effort to ensure the persistence and availability of the following public information:
- W3C technical reports whose publication has been approved by the Director. Per the Membership Agreement, W3C technical reports (and software) are available free of charge to the general public; (refer to the W3C Document License [ PUB18 ]).
- A mission statement [ PUB15 ] that explains the purpose and mission of W3C, the key benefits for Members, and the organizational structure of W3C.
- Legal documents, including the Membership Agreement [ PUB6 ]) and documentation of any legal commitments W3C has with other entities.
- The Process Document.
-
Public
results
of
W3C
Activitiesactivities and Workshops .
To keep the Members abreast of W3C meetings, Workshops, and review deadlines, the Team provides them with a regular (e.g., weekly) news service and maintains a calendar [ MEM3 ] of official W3C events. Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.
4.1 Confidentiality Levels
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.
While much information made available by W3C is public, "Member-only" information is available to authorized parties only, including representatives of Member organizations, Invited Experts , the Advisory Board, the TAG, and the Team. For example, the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.
"Team-only" information is available to the Team and other authorized parties.
Those authorized to access Member-only and Team-only information:
-
MUSTmust treat the information as confidential within W3C, -
MUSTmust use reasonable efforts to maintain the proper level confidentiality, and -
MUST NOTmust not release this information to the general public or press.
The
Team
MUST
must
provide
mechanisms
to
protect
the
confidentiality
of
Member-only
information
and
ensure
that
authorized
parties
have
proper
access
to
this
information.
Documents
SHOULD
should
clearly
indicate
whether
they
require
Member-only
confidentiality.
Individuals
uncertain
of
the
confidentiality
level
of
a
piece
of
information
SHOULD
should
contact
the
Team.
Advisory
Committee
representatives
MAY
may
authorize
Member-only
access
to
Member
representatives
and
other
individuals
employed
by
the
Member
who
are
considered
appropriate
recipients.
For
instance,
it
is
the
responsibility
of
the
Advisory
Committee
representative
and
other
employees
and
official
representatives
of
the
organization
to
ensure
that
Member-only
news
announcements
are
distributed
for
internal
use
only
within
their
organization.
Information
about
Member
mailing
lists
is
available
in
the
New
Member
Orientation
.
4.1.1 Changing Confidentiality Level
As
a
benefit
of
membership,
W3C
provides
some
Team-only
and
Member-only
channels
for
certain
types
of
communication.
For
example,
Advisory
Committee
representatives
can
send
reviews
to
a
Team-only
channel.
However,
for
W3C
processes
with
a
significant
public
component,
such
as
the
technical
report
development
process,
it
is
also
important
for
information
that
affects
decision-making
to
be
publicly
available.
The
Team
MAY
may
need
to
communicate
Team-only
information
to
a
Working
Group
or
the
public.
Similarly,
a
Working
Group
whose
proceedings
are
Member-only
MUST
must
make
public
information
pertinent
to
the
technical
report
development
process.
This
document
clearly
indicates
which
information
MUST
must
be
available
to
Members
or
the
public,
even
though
that
information
was
initially
communicated
on
Team-only
or
Member-only
channels.
Only
the
Team
and
parties
authorized
by
the
Team
change
the
level
of
confidentiality
of
this
information.
When
doing
so:
-
The
Team
MUSTmust 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 TeamSHOULDshould remind recipients to provide such alternatives. -
The
Team
MUST NOTmust not attribute the version for the new confidentiality level to the author without the author's consent. -
If
the
author
has
not
conveyed
to
the
Team
a
version
that
is
suitable
for
another
confidentiality
level,
the
Team
MAYmay make available a version that reasonably communicates what is required, while respecting the original level of confidentiality, and without attribution to the original author.
5
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
Working
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:
Groups
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
and
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,
Interest
Groups,
and
Coordination
Groups
This
document
defines
three
two
types
of
groups:
-
Working
Groups.
Working
Groups
typically
produce
deliverables
(e.g.,
Recommendation
Track
technical
reports
,
software,
test
suites,
and
reviews
of
the
deliverables
of
other
groups).
There
are
Good Standing requirements for Working Group participation as well asadditional participation requirements described in the W3C Patent Policy [ PUB33 ]. - Interest Groups. The primary goal of an Interest Group is to bring together people who wish to evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas.
Neither
Interest
Groups
nor
Coordination
Groups
do
not
publish
Recommendation
Track
technical
reports
;
see
information
about
maturity
levels
for
Interest
Groups
and
Coordination
Groups
.
5.1
Requirements
for
All
Working,
Interest,
Working
and
Coordination
Interest
Groups
Each
group
MUST
must
have
a
charter.
Requirements
for
the
charter
depend
on
the
group
type.
All
group
charters
MUST
must
be
public
(even
if
other
proceedings
of
the
group
are
Member-only
).
Existing
charters
that
are
not
yet
public
MUST
must
be
made
public
when
next
revised
or
extended
(with
attention
to
changing
confidentiality
level
).
Each
group
MUST
must
have
a
Chair
(or
co-Chairs)
to
coordinate
the
group's
tasks.
The
Director
appoints
(and
re-appoints)
Chairs
for
all
groups.
The
Chair
is
a
Member
representative
,
a
Team
representative
,
or
an
Invited
Expert
(invited
by
the
Director).
The
requirements
of
this
document
that
apply
to
those
types
of
participants
apply
to
Chairs
as
well.
The
role
of
the
Chair
[MEM14]
is
described
in
the
Member
guide
[
MEM9
].
Each
group
MUST
must
have
a
Team
Contact
,
,
who
acts
as
the
interface
between
the
Chair,
group
participants,
and
the
rest
of
the
Team.
The
role
of
the
Team
Contact
is
described
in
the
Member
guide.
The
Chair
and
the
Team
Contact
of
a
group
SHOULD
NOT
should
not
be
the
same
individual.
Each
group
MUST
must
have
an
archived
mailing
list
for
formal
group
communication
(e.g.,
for
meeting
announcements
and
minutes,
documentation
of
decisions,
and
Formal
Objections
to
decisions).
It
is
the
responsibility
of
the
Chair
and
Team
Contact
to
ensure
that
new
participants
are
subscribed
to
all
relevant
mailing
lists.
Refer
to
the
list
of
group
mailing
lists
[
MEM2
].
A
Chair
MAY
may
form
task
forces
(composed
of
group
participants)
to
carry
out
assignments
for
the
group.
The
scope
of
these
assignments
MUST
NOT
must
not
exceed
the
scope
of
the
group's
charter.
A
group
SHOULD
should
document
the
process
it
uses
to
create
task
forces
(e.g.,
each
task
force
might
have
an
informal
"charter").
Task
forces
do
not
publish
technical
reports
;
the
Working
Group
MAY
may
choose
to
publish
their
results
as
part
of
a
technical
report.
6.2
5.2
Working
Groups
and
Interest
Groups
Although Working Groups and Interest Groups have different purposes, they share some characteristics, and so are defined together in the following sections.
6.2.1
5.2.1
Working
Group
and
Interest
Group
Participation
Requirements
There
are
three
types
of
individual
participants
in
a
Working
Group
:
:
Member
representatives
,
Invited
Experts
,
and
Team
representatives
(including
the
Team
Contact
).
There
are
four
types
of
individual
participants
in
an
Interest
Group
:
:
the
same
three
types
as
for
Working
Groups
plus,
for
an
Interest
Group
where
the
only
participation
requirement
is
mailing
list
subscription
,
public
participants
.
.
Except where noted in this document or in a group charter, all participants share the same rights and responsibilities in a group; see also the individual participation criteria .
A
participant
MUST
must
represent
at
most
one
organization
in
a
Working
Group
or
Interest
Group.
An
individual
MAY
may
become
a
Working
or
Interest
Group
participant
at
any
time
during
the
group's
existence.
See
also
relevant
requirements
in
section
4.3
of
the
W3C
Patent
Policy
[
PUB33
].
On
an
exceptional
basis,
a
Working
or
Interest
Group
participant
MAY
may
designate
a
substitute
to
attend
a
meeting
and
SHOULD
should
inform
the
Chair.
The
substitute
MAY
may
act
on
behalf
of
the
participant,
including
for
votes
.
For
the
substitute
to
vote,
the
participant
MUST
must
inform
the
Chair
in
writing
in
advance.
As
a
courtesy
to
the
group,
if
the
substitute
is
not
well-versed
in
the
group's
discussions,
the
regular
participant
SHOULD
should
authorize
another
participant
to
act
as
proxy
for
votes.
For
the
purposes
of
Good
Standing
,
the
regular
representative
and
the
substitute
are
considered
the
same
participant.
To
allow
rapid
progress,
Working
Groups
are
intended
to
be
small
(typically
fewer
than
15
people)
and
composed
of
experts
in
the
area
defined
by
the
charter.
In
principle,
Interest
Groups
have
no
limit
on
the
number
of
participants.
When
a
Working
Group
grows
too
large
to
be
effective,
W3C
MAY
may
split
it
into
an
Interest
Group
(a
discussion
forum)
and
a
much
smaller
Working
Group
(a
core
group
of
highly
dedicated
participants).
See also the licensing obligations on Working Group participants in section 3 of the W3C Patent Policy [ PUB33 ], and the patent claim exclusion process of section 4 .
6.2.1.1
5.2.1.1
Member
Representative
in
a
Working
Group
An individual is a Member representative in a Working Group if all of the following conditions are satisfied:
- the Advisory Committee representative of the Member in question has designated the individual as a Working Group participant, and
- the individual qualifies for Member representation .
To
designate
an
individual
as
a
Member
representative
in
a
Working
Group
,
,
an
Advisory
Committee
representative
MUST
must
provide
the
Chair
and
Team
Contact
with
all
of
the
following
information,
in
addition
to
any
other
information
required
by
the
Call
for
Participation
and
charter
(including
the
participation
requirements
of
the
W3C
Patent
Policy
[
PUB33
]):
- The name of the W3C Member the individual represents and whether the individual is an employee of that Member organization;
- A statement that the individual accepts the participation terms set forth in the charter (with an indication of charter date or version);
- A statement that the Member will provide the necessary financial support for participation (e.g., for travel, telephone calls, and conferences).
A Member participates in a Working Group from the moment the first Member representative joins the group until either of the following occurs:
- the group closes, or
- the Member resigns from the Working Group; this is done through the Member's Advisory Committee representative.
6.2.1.2
5.2.1.2
Member
Representative
in
an
Interest
Group
When the participation requirements exceed Interest Group mailing list subscription , an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:
- the Advisory Committee representative of the Member in question has designated the individual as an Interest Group participant, and
- the individual qualifies for Member representation .
To
designate
an
individual
as
a
Member
representative
in
an
Interest
Group,
the
Advisory
Committee
representative
MUST
must
follow
the
instructions
in
the
Call
for
Participation
and
charter.
Member participation in an Interest Group ceases under the same conditions as for a Working Group.
6.2.1.3
5.2.1.3
Invited
Expert
in
a
Working
Group
The
Chair
MAY
may
invite
an
individual
with
a
particular
expertise
to
participate
in
a
Working
Group.
This
individual
MAY
may
represent
an
organization
in
the
group
(e.g.,
if
acting
as
a
liaison
with
another
organization).
An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:
- the Chair has designated the individual as a group participant,
- the Team Contact has agreed with the Chair's choice, and
- the individual has provided the information required of an Invited Expert to the Chair and Team Contact.
To
designate
an
individual
as
an
Invited
Expert
in
a
Working
Group,
the
Chair
MUST
must
inform
the
Team
Contact
and
provide
rationale
for
the
choice.
When
the
Chair
and
the
Team
Contact
disagree
about
a
designation,
the
Director
determines
whether
the
individual
will
be
invited
to
participate
in
the
Working
Group.
To
be
able
to
participate
in
a
Working
Group
as
an
Invited
Expert
,
,
an
individual
MUST
must
do
all
of
the
following:
- identify the organization, if any, the individual represents as a participant in this group,
- agree to the terms of the invited expert and collaborators agreement [ PUB17 ],
- accept the participation terms set forth in the charter (including the participation requirements of section 3 (especially 3.4) and section 6 (especially 6.10) of the W3C Patent Policy [ PUB33 ]). Indicate a specific charter date or version,
- disclose whether the individual is an employee of a W3C Member; see the conflict of interest policy ,
- provide a statement of who will provide the necessary financial support for the individual's participation (e.g., for travel, telephone calls, and conferences), and
- 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.
The
Chair
SHOULD
NOT
should
not
designate
as
an
Invited
Expert
in
a
Working
Group
an
individual
who
is
an
employee
of
a
W3C
Member.
The
Chair
MUST
NOT
must
not
use
Invited
Expert
status
to
circumvent
participation
limits
imposed
by
the
charter
.
An Invited Expert participates in a Working Group from the moment the individual joins the group until any of the following occurs:
- the group closes, or
- the Chair or Director withdraws the invitation to participate, or
- the individual resigns .
6.2.1.4
5.2.1.4
Invited
Expert
in
an
Interest
Group
When the participation requirements exceed Interest Group mailing list subscription , the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group .
6.2.1.5
5.2.1.5
Team
Representative
in
a
Working
Group
An individual is a Team representative in a Working Group when so designated by W3C management.
An
A
Team
representative
participates
in
a
Working
Group
from
the
moment
the
individual
joins
the
group
until
any
of
the
following
occurs:
- the group closes, or
- W3C management changes Team representation by sending email to the Chair, cc'ing the group mailing list.
The Team participates in a Working Group from the moment the Director announces the creation of the group until the group closes.
6.2.1.6
5.2.1.6
Team
Representative
in
an
Interest
Group
When the participation requirements exceed Interest Group mailing list subscription , an individual is a Team representative in an Interest Group when so designated by W3C management.
6.2.2
5.2.2
Working
Group
and
Interest
Group
Charter
Development
W3C
creates
a
charter
based
on
interest
from
the
Members
and
Team.
The
Team
MUST
must
notify
the
Advisory
Committee
when
a
charter
for
a
new
Working
Group
or
Interest
Group
is
in
development.
The
suggestions
for
building
support
around
an
Activity
Proposal
apply
This
is
intended
to
charters
as
well.
raise
awareness,
even
if
no
formal
proposal
is
yet
available.
Advisory
Committee
representatives
may
provide
feedback
on
the
Advisory
Committee
discussion
list
.
W3C
MAY
may
begin
work
on
a
Working
Group
or
Interest
Group
charter
at
any
time.
A
Working
Group
or
Interest
Group
MUST
be
part
of
an
approved
Activity
.
6.2.3
5.2.3
Advisory
Committee
Review
of
a
Working
Group
or
Interest
Group
Charter
The
Director
MUST
must
solicit
Advisory
Committee
review
of
every
new
or
substantively
modified
Working
Group
or
Interest
Group
charter.
The
Director
is
NOT
REQUIRED
not
required
to
solicit
Advisory
Committee
review
prior
to
a
charter
extension
or
for
minor
changes.
The
review
period
must
be
at
least
four
weeks.
The
Director's
Call
for
Review
of
a
substantively
modified
charter
MUST
must
highlight
important
changes
(e.g.,
regarding
deliverables
or
resource
allocation)
and
include
rationale
for
the
changes.
6.2.4
5.2.4
Call
for
Participation
in
a
Working
Group
or
Interest
Group
After
Advisory
Committee
review
of
a
Working
Group
or
Interest
Group
charter,
the
Director
MAY
may
issue
a
Call
for
Participation
to
the
Advisory
Committee.
Charters
may
be
amended
based
on
review
comments
before
the
Director
issues
a
Call
for
Participation.
For
a
new
group,
this
announcement
officially
creates
the
group.
The
announcement
MUST
must
include
a
reference
to
the
charter
,
the
name(s)
of
the
group's
Chair(s)
,
and
the
name
of
the
Team
Contact
.
After
a
Call
for
Participation,
any
Member
representatives
and
Invited
Experts
MUST
must
be
designated
(or
re-designated).
Advisory
Committee
representatives
MAY
may
appeal
creation
or
substantive
modification
of
a
Working
Group
or
Interest
Group
charter.
6.2.5
5.2.5
Working
Group
and
Interest
Group
Charter
Extension
To
extend
a
Working
Group
or
Interest
Group
charter
with
no
other
substantive
modifications,
the
Director
announces
the
extension
to
the
Advisory
Committee.
The
announcement
MUST
must
indicate
the
new
duration,
which
MUST
NOT
exceed
the
duration
of
the
Activity
to
which
the
group
belongs.
duration.
The
announcement
MUST
must
also
include
rationale
for
the
extension,
a
reference
to
the
charter
,
the
name(s)
of
the
group's
Chair(s)
,
the
name
of
the
Team
Contact
,
and
instructions
for
joining
the
group.
After
a
charter
extension,
Advisory
Committee
representatives
and
the
Chair
are
NOT
REQUIRED
not
required
to
re-designate
Member
representatives
and
Invited
Experts
.
Advisory
Committee
representatives
MAY
may
appeal
the
extension
of
a
Working
Group
or
Interest
Group
charter.
6.2.6
5.2.6
Working
Group
and
Interest
Group
Charters
A
Working
Group
or
Interest
Group
charter
MUST
must
include
all
of
the
following
information.
- The group's mission (e.g., develop a technology or process, review the work of other groups);
- The scope of the group's work and criteria for success;
- The duration of the group (typically from six months to two years);
-
The
nature
of
any
deliverables
(technical
reports,
reviews
of
the
deliverables
of
other
groups,
or
software),
expected
milestones,
and
the
process
for
the
group
participants
to
approve
the
release
of
these
deliverables
(including
public
intermediate
results).
A
charter
is
NOT REQUIREDnot required to include the schedule for a review of another group's deliverables; -
Any
dependencies
by
groups
within
or
outside
of
W3C
on
the
deliverables
of
this
group.
For
any
dependencies,
the
charter
MUSTmust specify the mechanisms for communication about the deliverables; -
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 MUST specify when required deliverables are expected from the other groups. The charter SHOULD set expectations about how coordination with those groups will take place; see the section on liaisonsSuch dependencies include interactions withother organizations . Finally, the charter SHOULD specify expected conformance to the deliverables of the other groups;W3C Horizontal Groups ; - The level of confidentiality of the group's proceedings and deliverables;
- Meeting mechanisms and expected frequency;
- If known, the date of the first face-to-face meeting . The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal.
- 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 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).
- 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 W3C Patent Policy [ PUB33 ]?
See also the charter requirements of section 2 and section 3 of the W3C Patent Policy [ PUB33 ].
An
Interest
Group
charter
MAY
may
include
provisions
regarding
participation,
including
specifying
that
the
only
requirement
for
participation
(by
anyone)
in
the
Interest
Group
is
subscription
to
the
Interest
Group
mailing
list.
list
.
This
type
of
Interest
Group
MAY
may
have
public
participants
.
A
charter
MAY
may
include
additional
voting
procedures,
but
those
procedures
MUST
NOT
must
not
conflict
with
the
voting
requirements
of
the
Process
Document.
A
charter
MAY
may
include
provisions
other
than
those
required
by
this
document.
The
charter
SHOULD
should
highlight
whether
additional
provisions
impose
constraints
beyond
those
of
the
W3C
Process
Document
(e.g.,
limits
on
the
number
of
individuals
in
a
Working
Group
who
represent
the
same
Member
organization
or
group
of
related
Members
).
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).
6.2.8
5.2.8
Working
Group
and
Interest
Group
Closure
A
Working
Group
or
Interest
Group
charter
specifies
a
duration
for
the
group.
The
Director,
subject
to
appeal
by
Advisory
Committee
representatives,
MAY
may
close
a
group
prior
to
the
date
specified
in
the
charter
in
any
of
the
following
circumstances:
- There are insufficient resources to produce chartered deliverables or to maintain the group, according to priorities established within W3C.
- The group produces chartered deliverables ahead of schedule.
The Director closes a Working Group or Interest Group by announcement to the Advisory Committee.
Closing a Working Group has implications with respect to the W3C Patent Policy [ PUB33 ].
7
6
W3C
Technical
Report
Development
Process
The W3C technical report development process is the set of steps and requirements followed by W3C Working Groups to standardize Web technology. The W3C technical report development process is designed to
- support multiple specification development methodologies
- maximize consensus about the content of stable technical reports
- ensure high technical and editorial quality
- promote consistency among specifications
- facilitate royalty-free, interoperable implementations of Web Standards, and
- earn endorsement by W3C and the broader community.
See also the licensing goals for W3C Recommendations in section 2 of the W3C Patent Policy [ PUB33 ].
7.1
6.1
W3C
Technical
Reports
Please note that publishing as used in this document refers to producing a version which is listed as a W3C Technical Report on its Technical Reports page http://www.w3.org/TR .
This chapter describes the formal requirements for publishing and maintaining a W3C Recommendation or Note.
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
should
become
is
appropriate
as
a
W3C
Recommendation,
while
the
Working
Group
formally
collects
collects
implementation
experience
to
demonstrate
that
the
specification
works
in
practice.
The
next
phase
is
a
Proposed
Recommendation,
to
finalize
the
review
of
W3C
Members.
If
the
Director
determines
that
W3C
member
review
supports
a
specification
becoming
a
standard,
W3C
publishes
it
as
a
Recommendation.
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.
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.
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.
7.1.1
6.1.1
Recommendations
and
Notes
W3C follows these steps when advancing a technical report to Recommendation.
- Publication of the First Public Working Draft ,
- Publication of zero or more revised Public Working Drafts .
- Publication of a Candidate Recommendation .
- Publication of a Proposed Recommendation .
- Publication as a W3C Recommendation .
- Possibly, Publication as an Edited Recommendation
W3C may end work on a technical report at any time.
The Director may decline a request to advance in maturity level, requiring a Working Group to conduct further work, and may require the specification to return to a lower maturity level . The Director must inform the Advisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity level is declined and the specification is returned to a Working Group for further work.
7.1.2
6.1.2
Maturity
Levels
- Working Draft (WD)
- 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 document status section of a Working Draft for the group's expectations. Any Working Draft not, or no longer, intended to advance to Recommendation should 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.
- Candidate Recommendation (CR)
-
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
-
signal
to
the
wider
community
that
it
is
time
to
do
a
final
review
should be done - gather implementation experience
- begin formal review by the Advisory Committee, who may recommend that the document be published as a W3C Recommendation, returned to the Working Group for further work, or abandoned.
- Provide an exclusion opportunity as per the W3C Patent Policy [ PUB33 ]. A Candidate Recommendation under this process corresponds to the "Last Call Working Draft" discussed in the Patent Policy.
-
signal
to
the
wider
community
that
it
is
time
to
do
a
final
review
- Note: Candidate Recommendations are expected to be acceptable as Recommendations. Announcement of a different next step should include the reasons why the change in expectations comes at so late a stage.
- Proposed Recommendation
- 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 must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation.
- W3C Recommendation (REC)
- A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has received the endorsement of 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.
- Working Group Note, Interest Group Note (NOTE)
- 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.
- Rescinded Recommendation
- A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses. See also clause 10 of the licensing requirements for W3C Recommendations in section 5 of the W3C Patent Policy [ PUB33 ].
Working Groups and Interest Groups may 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.
7.2
6.2
General
requirements
and
definitions
Please
note
that
publishing
as
used
in
this
document
refers
to
producing
a
version
which
is
listed
as
a
W3C
Technical
Report
on
its
Technical
Reports
page
http://www.w3.org/TR
.
[
PUB11
].
7.2.1
6.2.1
General
requirements
for
Technical
Reports
Every document published as part of the technical report development process must be a public document. The index of W3C technical reports [ PUB11 ] is available at the W3C Web site. W3C strives to make archival documents indefinitely available at their original address in their original form.
Every document published as part of the technical report development process must clearly indicate its maturity level , and must include information about the status of the document. This status information
- must be unique each time a specification is published,
- must state which Working Group developed the specification,
- must state how to send comments or file bugs, and where these are recorded,
- must include expectations about next steps,
- should explain how the technology relates to existing international standards and related work inside or outside W3C, and
- should explain or link to an explanation of significant changes from the previous version.
Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair. It is the responsibility of these editors to ensure that the decisions of the Group are correctly reflected in subsequent drafts of the technical report. An editor must be a participant, as a Member representative, Team representative, or Invited Expert in the Group responsible for the document(s) they are editing.
The
Team
is
not
required
to
publish
a
Technical
Report
that
does
not
conform
to
the
Team's
Publication
Rules
(e.g.,
[
PUB31
](e.g.,
for
naming
,
,
status
information,
style,
and
copyright
requirements
).
These
rules
are
subject
to
change
by
the
Team
from
time
to
time.
The
Team
must
inform
group
Chairs
and
the
Advisory
Committee
of
any
changes
to
these
rules.
The primary language for W3C Technical Reports is English. W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [ PUB18 ] is available at the W3C Web site.
7.2.2
6.2.2
Advancement
on
the
Recommendation
Track
For all requests to advance a specification to a new maturity level other than Note the Working Group:
- must record the group's decision to request advancement.
- must obtain Director approval.
- must provide public documentation of all substantive changes to the technical report since the previous publication.
- must formally address all issues raised about the document since the previous maturity level.
- must provide public documentation of any Formal Objections .
- should provide public documentation of changes that are not substantive.
- should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
- should report any changes in dependencies with other groups.
- should provide information about implementations known to the Working Group.
For a First Public Working Draft there is no "previous maturity level", so many requirements do not apply, and approval is normally fairly automatic. For later stages, especially transition to Candidate or Proposed Recommendation, there is generally a formal review meeting to ensure the requirements have been met before Director's approval is given.
7.2.3
6.2.3
Reviews
and
Review
Responsibilities
A document is available for review from the moment it is first published. Working Groups should formally address any substantive review comment about a technical report in a timely manner.
Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, particularly if this would cause significant compatibility problems due to existing implementation. Working Groups should record substantive or interesting proposals raised by reviews but not incorporated into a current specification.6.2.3.1 Wide Review
The
requirements
for
wide
review
are
not
precisely
defined
by
the
W3C
Process.
The
objective
is
to
ensure
that
the
entire
set
of
stakeholders
of
the
Web
community,
including
the
general
public,
have
had
adequate
notice
of
the
progress
of
the
Working
Group
(for
example
through
notices
posted
to
public-review-announce@w3.org
)
and
thereby
an
opportunity
were
able
to
comment
actually
perform
reviews
of
and
provide
comments
on
the
specification.
A
second
objective
is
to
encourage
groups
to
request
reviews
early
enough
that
comments
and
suggested
changes
may
still
be
reasonably
incorporated
in
response
to
the
review.
Before
approving
transitions,
the
Director
will
consider
who
has
been
explicitly
offered
a
reasonable
opportunity
to
review
the
document,
who
has
provided
comments,
the
record
of
requests
to
and
responses
from
reviewers,
especially
W3C
Horizontal
Groups
and
groups
identified
as
dependencies
in
the
charter,
charter
or
identified
as
liaisons
[
PUB29
],
and
seek
evidence
of
clear
communication
to
the
general
public
about
appropriate
times
and
which
content
to
review.
review
and
whether
such
reviews
actually
occurred.
For example, inviting review of new or significantly revised sections published in Working Drafts, and tracking those comments and the Working Group's responses, is generally a good practice which would often be considered positive evidence of wide review. Working Groups should announce to other W3C Working Groups as well as the general public, especially those affected by this specification, a proposal to enter Candidate Recommendation (for example in approximately four weeks). By contrast a generic statement in a document requesting review at any time is likely not to be considered as sufficient evidence that the group has solicited wide review.
A Working Group could present evidence that wide review has been received, irrespective of solicitation. But it is important to note that receiving many detailed reviews is not necessarily the same as wide review, since they may only represent comment from a small segment of the relevant stakeholder community.
7.2.4
6.2.4
Implementation
Experience
Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized. While no exhaustive list of requirements is provided here, when assessing that there is adequate implementation experience the Director will consider (though not be limited to):
- is each feature of the current specification implemented, and how is this demonstrated?
- are there independent interoperable implementations of the current specification?
- are there implementations created by people other than the authors of the specification?
- are implementations publicly deployed?
- is there implementation experience at all levels of the specification's ecosystem (authoring, consuming, publishing…)?
- are there reports of difficulties or problems with implementation?
Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. Groups are often able to work more effectively if they plan how they will demonstrate interoperable implementations early in the development process; for example, they may wish to develop tests in concert with implementation efforts.
7.2.5
6.2.5
Classes
of
Changes
This document distinguishes the following 4 classes of changes to a specification. The first two classes of change are considered editorial changes , the latter two substantive changes .
- 1. No changes to text content
- These changes include fixing broken links, style sheets or invalid markup.
- 2. Corrections that do not affect conformance
-
Editorial changes or clarificationsChanges thatdoreasonable implementers would not interpret as changing architectural or interoperability requirements or their implementation. Changes which resolve ambiguities in the specification are considered to change (by clarification) thetechnical contentimplementation requirements and do not fall into this class. -
Examples
of
changes
in
this
class
are
correcting
non-normative
code
examples
where
the
specification.code clearly conflicts with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change implementation requirements. If there is any doubt or dissent as to whether requirements are changed, such changes do not belong to this class.. - 3. Corrections that do not add new features
-
These
changes
may
affect
conformance
to
the
specification.
A
change
that
affects
conformance
is
one
that:
- makes conforming data, processors, or other conforming agents become non-conforming according to the new version, or
- makes non-conforming data, processors, or other agents become conforming, or
- clears up an ambiguity or under-specified part of the specification in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming.
- 4. New features
- Changes that add a new functionality, element, etc.
7.3
6.3
Working
Draft
A
Public
Working
Draft
is
published
on
the
W3C's
Technical
Reports
page
[TR]
[
PUB11
]
for
review,
and
for
simple
historical
reference.
For
all
Public
Working
Drafts
a
Working
Group
- should document outstanding issues, and parts of the document on which the Working Group does not have consensus, and
- may request publication of a Working Draft even if its content is considered unstable and does not meet all Working Group requirements.
7.3.1
6.3.1
First
Public
Working
Draft
To publish the First Public Working Draft of a document, a Working Group must meet the applicable general requirements for advancement .
The Director must announce the publication of a First Public Working Draft publication to other W3C groups and to the public.
Publishing the First Public Working Draft triggers a Call for Exclusions, per section 4 of the W3C Patent Policy [ PUB33 ].
7.3.2
6.3.2
Revising
Public
Working
Drafts
A Working Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.
If 6 months elapse without significant changes to a specification a Working Group should publish a revised Working Draft, whose status section should indicate reasons for the lack of change.
To publish a revision of a Working draft, a Working Group
- must record the group's decision to request publication. Consensus is not required, as this is a procedural step,
- must provide public documentation of substantive changes to the technical report since the previous Working Draft,
- should provide public documentation of significant editorial changes to the technical report since the previous step,
- should report which, if any, of the Working Group's requirements for this document have changed since the previous step,
- should report any changes in dependencies with other groups,
Possible next steps for any Working Draft:
7.3.3
6.3.3
Stopping
Work
on
a
specification
Work on a technical report may cease at any time. Work should cease if W3C or a Working Group determines that it cannot productively carry the work any further. If the Director closes a Working Group W3C must publish any unfinished specifications on the Recommendation track as Working Group Notes . If a Working group decides, or the Director requires, the Working Group to discontinue work on a technical report before completion, the Working Group should publish the document as a Working Group Note .
7.4
6.4
Candidate
Recommendation
To publish a Candidate recommendation, in addition to meeting the general requirements for advancement a Working Group:
- must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,
- must document changes to dependencies during the development of the specification,
- must document how adequate implementation experience will be demonstrated,
- must specify the deadline for comments, which must be at least four weeks after publication, and should be longer for complex documents,
- must show that the specification has received wide review , and
- may identify features in the document as "at risk". These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.
The
Director
must
announce
the
publication
of
a
Candidate
Recommendation
to
other
W3C
groups
and
to
the
public,
and
must
begin
an
Advisory
Committee
Review
on
the
question
of
whether
W3C
should
publish
the
specification
is
appropriate
to
publish
as
a
W3C
Recommendation.
A Candidate Recommendation corresponds to a "Last Call Working Draft" as used in the W3C Patent Policy [ PUB33 ]. Publishing a Candidate Recommendation triggers a Call for Exclusions, per section 4 of the W3C Patent Policy [ PUB33 ].
Possible next steps:
- Return to Working Draft
- A revised Candidate Recommendation
- Proposed Recommendation (The expected next step)
- Working Group Note
If
there
was
any
dissent
to
to
the
Working
Group
decision
to
request
advancement
Advisory
Committee
representatives
may
appeal
the
decision
to
advance
the
technical
report.
7.4.1
6.4.1
Revising
a
Candidate
Recommendation
If there are any substantive changes made to a Candidate Recommendation other than to remove features explicitly identified as "at risk", the Working Group must obtain the Director's approval to publish a revision of a Candidate Recommendation. This is because substantive changes will generally require a new Exclusion Opportunity per section 4 of the W3C Patent Policy [ PUB33 ]. Note that approval is expected to be fairly simple compared to getting approval for a transition from Working Draft to Candidate Recommendation.
In addition the Working Group:
- must show that the revised specification meets all Working Group requirements, or explain why the requirements have changed or been deferred,
- must specify the deadline for further comments, which must be at least four weeks after publication, and should be longer for complex documents,
- must document the changes since the previous Candidate Recommendation,
- must show that the proposed changes have received wide review , and
- may identify features in the document as "at risk". These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.
The Director must announce the publication of a revised Candidate Recommendation to other W3C groups and the Public.
7.5
6.5
Proposed
Recommendation
In addition to meeting the general requirements for advancement ,
- The status information must specify the deadline for Advisory Committee review, which must be at least 28 days after the publication of the Proposed Recommendation and should be at least 10 days after the end of the last Exclusion Opportunity per section 4 of the W3C Patent Policy [ PUB33 ].
A Working Group:
- must show adequate implementation experience except where an exception is approved by the Director,
- must show that the document has received wide review,
- must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed ,
- must identify any substantive issues raised since the close of the Candidate Recommendation review period by parties other than Advisory Committee representatives acting in their formal AC representative role,
- may have removed features identified in the Candidate Recommendation document as "at risk" without republishing the specification as a Candidate Recommendation.
The Director:
- must announce the publication of a Proposed Recommendation to the Advisory Committee , and
- may approve a Proposed Recommendation with minimal implementation experience where there is a compelling reason to do so. In such a case, the Director should explain the reasons for that decision.
Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on, to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft.
Possible Next Steps:
- Return to Working Draft
- Return to Candidate Recommendation
- Recommendation status (The expected next step)
- Working Group Note
7.6
6.6
W3C
Recommendation
The decision to advance a document to Recommendation is a W3C Decision .
In addition to meeting the general requirements for advancement ,
- A Recommendation must identify where errata are tracked, and
- A Recommendation must not include any substantive changes from the Proposed Recommendation on which it is based.
- If there was any dissent in Advisory Committee reviews, the Director must publish the substantive content of the dissent to W3C and the general public, and must formally address the comment at least 14 days before publication as a W3C Recommendation. In this case the Advisory Committee may appeal the decision,
- The Director must announce the publication of a W3C Recommendation to Advisory Committee , other W3C groups and to the public.
Possible next steps:
A W3C Recommendation normally retains its status indefinitely. However it
- may be republished as an (Edited) Recommendation , or
- may be rescinded .
7.7
6.7
Modifying
a
W3C
Recommendation
This section details the management of errors in, and the process for making changes to a Recommendation. Please see also the Requirements for modification of W3C Technical Reports [ PUB35 ].
7.7.1
6.7.1
Errata
Management
Tracking
errors
is
an
important
part
of
a
Working
Group's
ongoing
care
of
a
Recommendation;
for
this
reason,
the
scope
of
a
Working
Group
charter
generally
allows
time
for
work
after
publication
of
a
Recommendation.
In
this
Process
Document,
the
term
"erratum"
(plural
"errata")
refers
to
any
class
of
mistake,
from
mere
editorial
to
a
serious
error
that
may
affect
the
conformance
with
the
Recommendation
can
be
resolved
by
software
one
or
content
(e.g.,
content
validity).
more
changes
in
classes
1-3
of
section
7.2.5
Classes
of
Changes
.
Working
Groups
must
track
errata
on
an
"errata
page."
An
errata
page
is
keep
a
list
of
enumerated
errors,
possibly
accompanied
record
as
errors
are
reported
by
corrections.
Each
readers
and
implementers.
Such
error
reports
should
be
processed
no
less
frequently
than
quarterly.
Readers
of
the
Recommendation
links
should
be
able
easily
to
an
errata
page;
find
and
see
the
Team's
Publication
Rules
.
errata
that
apply
to
that
specific
Recommendation.
A
correction
Working
groups
may
decide
how
to
document
errata.
The
best
practice
is
first
a
document
that
identifies
itself
as
based
on
the
Recommendation
text
and
clearly
identifies
the
errata
and
any
proposed
corrections;
other
approaches
include
various
forms
of
an
errata
page,
possibly
auto-generated
from
a
database.
An erratum is resolved by an informative, "proposed" correction generated by the Working Group. A correction becomes part of the Recommendation by the process for Revising a Recommendation described in the next section.
7.7.2
6.7.2
Revising
a
Recommendation
A Working group may request republication of a Recommendation, or W3C may republish a Recommendation, to make corrections that do not result in any changes to the text of the specification.
Editorial
changes
to
a
Recommendation
require
no
technical
review
of
the
proposed
changes.
A
Working
Group
Group,
provided
there
are
no
votes
against
the
resolution
to
publish
may
request
publication
of
a
Proposed
Recommendation
or
W3C
may
publish
a
Proposed
Recommendation
to
make
this
class
of
change
without
passing
through
earlier
maturity
levels.
Such
publications
are
may
be
called
a
Proposed
Edited
Recommendation
.
To make corrections to a Recommendation that produce substantive changes but do not add new features, or where there were votes against publishing the corrections directly as a Proposed Recommendation , a Working Group may request publication of a Candidate Recommendation , without passing through earlier maturity levels.
In the latter two cases, the resulting Recommendation may be called an Edited Recommendation .
When requesting the publication of an edited Recommendation as described in this section, in addition to meeting the requirements for the relevant maturity level, a Working Group
- must show that the changes to the document have received wide review , and
- should address all recorded errata.
For changes which introduces a new feature or features, W3C must follow the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.
7.8
6.8
Publishing
a
Working
Group
or
Interest
Group
Note
Working Groups and Interest Groups publish material that is not a formal specification as Notes. This includes supporting documentation for a specification such as explanations of design principles or use cases and requirements, non-normative guides to good practices, as well as specifications where work has been stopped and there is no longer consensus for making them a new standard.
In order to publish a Note, a Working Group or Interest Group:
- may publish a Note with or without its prior publication as a Working Draft.
- must record the group's decision to request publication as a Note, and
- should publish documentation of significant changes to the technical report since any previous publication.
Possible next steps:
- End state: A technical report may remain a Working Group Note indefinitely
- A Working Group may resume work on technical report within the scope of its charter at any time, at the maturity level the specification had before publication as a Note
The W3C Patent Policy [ PUB33 ] does not specify any licensing requirements or commitments for Working Group Notes.
7.9
6.9
Rescinding
a
W3C
Recommendation
W3C may rescind a Recommendation, for example if the Recommendation contains many errors that conflict with a later version or if W3C discovers burdensome patent claims that affect implementers and cannot be resolved; see the W3C Patent Policy [ PUB33 ] and in particular section 5 (bullet 10) and section 7.5 . A Working Group may request the Director to rescind a Recommendation which was a deliverable, or the Director may directly propose to rescind a Recommendation.
W3C only rescinds entire specifications. To rescind some part of a Recommendation, W3C follows the process for modifying a Recommendation .
Once W3C has published a Rescinded Recommendation, future W3C technical reports must not include normative references to that technical report.
To propose rescinding a W3C Recommendation, a Working Group or the Director
- must publish rationale for rescinding the Recommendation.
- should document known implementation.
In addition a Working Group requesting to rescind a Recommendation
- must show that the request to rescind has received wide review
In addition the Director, if proposing to rescind a Recommendation
- must show that the request to rescind is based on public comment
The Director must announce the proposal to rescind a W3C Recommendation to other W3C groups, the public, and the Advisory Committee . The announcement must :
- indicate that this is a Proposal to Rescind a Recommendation
- specify the deadline for review comments, which must be at least four weeks after announcing the proposal to rescind.
- identify known dependencies and solicit review from all dependent Working Groups;
- solicit public review.
If there was any dissent in Advisory Committee reviews, the Director must publish the substantive content of the dissent to W3C and the public , and must formally address the comment at least 14 days before publication as a Rescinded Recommendation. In this case the Advisory Committee may appeal the decision.
A Rescinded Recommendation must be published with up to date status. The updated version may remove the rescinded content (i.e. the main body of the document).
Note: the original Recommendation document will continue to be available at its version-specific URL.
Further reading
Refer to "How to Organize a Recommendation Track Transition" in the Member guide for practical information about preparing for the reviews and announcements of the various steps, and tips on getting to Recommendation faster [ PUB27 ].
7 Advisory Committee Reviews, Appeals, and Votes
This
section
describes
how
the
Advisory
Committee
reviews
proposals
from
the
Director
and
how
Advisory
Committee
representatives
appeal
W3C
decisions
and
decisions
by
the
Director.
A
W3C
decision
is
one
where
the
Director
(or
the
Director's
delegate)
has
exercised
the
role
of
assessing
consensus
after
an
Advisory
Committee
review
of
an
Activity
Charter
Proposal
,
after
a
Call
for
Review
of
a
Proposed
Recommendation
,
after
a
Call
for
Review
of
a
Proposed
Recommendation
,
after
a
Proposal
to
Rescind
a
W3C
Recommendation
,
and
after
a
Proposed
Process
Document
review.
7.1 Advisory Committee Reviews
The Advisory Committee reviews:
-
proposals for new , modified , and extended Activities ,new and modified Working and Interest Groups , - Proposed Recommendations , Proposed Edited Recommendations , Proposal to Rescind a Recommendation , and
- Proposed changes to the W3C process .
7.1.1 Start of a Review Period
Each
Advisory
Committee
review
period
begins
with
a
Call
for
Review
from
the
Team
to
the
Advisory
Committee.
The
review
form
describes
the
proposal,
raises
attention
to
deadlines,
estimates
when
the
decision
will
be
available,
and
includes
other
practical
information.
Each
Member
organization
MAY
may
send
one
review,
which
MUST
must
be
returned
by
its
Advisory
Committee
representative.
The
Team
MUST
must
provide
two
channels
for
Advisory
Committee
review
comments:
-
an
archived
Team-only
channel;
this is the default channel for reviews. - an archived Member-only channel.
The Call for Review must specify which channel is the default for review comments on that Call.
Reviewers
MAY
may
send
information
to
either
or
both
channels.
They
MAY
may
also
share
their
reviews
with
other
Members
on
the
Advisory
Committee
discussion
list
.
A
Member
organization
MAY
may
modify
its
review
during
a
review
period
(e.g.,
in
light
of
comments
from
other
Members).
7.1.2 After the Review Period
After
the
review
period,
the
Director
MUST
must
announce
to
the
Advisory
Committee
the
level
of
support
for
the
proposal
(
consensus
or
dissent
).
The
Director
MUST
must
also
indicate
whether
there
were
any
Formal
Objections,
with
attention
to
changing
confidentiality
level
.
This
W3C
decision
is
generally
one
of
the
following:
- The proposal is approved, possibly with minor changes integrated.
-
The
proposal
is
approved,
possibly
with
substantive
changes
integrated.
In
this
case
the
Director's
announcement
MUSTmust include rationale for the decision to advance the document despite the proposal for a substantive change. - The proposal is returned for additional work, with a request to the initiator to formally address certain issues.
- The proposal is rejected.
This
document
does
not
specify
time
intervals
between
the
end
of
an
Advisory
Committee
review
period
and
the
W3C
decision
.
This
is
to
ensure
that
the
Members
and
Team
have
sufficient
time
to
consider
comments
gathered
during
the
review.
The
Advisory
Committee
SHOULD
NOT
should
not
expect
an
announcement
sooner
than
two
weeks
after
the
end
of
a
Proposed
Recommendation
review
period.
If,
after
three
weeks
,
the
Director
has
not
announced
the
outcome,
the
Director
SHOULD
should
provide
the
Advisory
Committee
with
an
update.
7.2 Appeal by Advisory Committee Representatives
Advisory
Committee
representatives
MAY
may
appeal
certain
decisions,
though
appeals
are
only
expected
to
occur
in
extraordinary
circumstances.
When
Advisory
Committee
review
immediately
precedes
a
decision,
Advisory
Committee
representatives
MAY
may
only
appeal
when
there
is
dissent
.
These
decisions
are:
- Publication of a Recommendation or Publication of a Rescinded Recommendation ,
-
Activity creation , modification , or extension ,Working or Interest Group creation , substantive modification or extension , - Changes to the W3C process .
Advisory
Committee
representatives
MAY
may
always
appeal
the
following
decisions:
-
Activity closure ,Working or Interest Group extension or closure , - Call for Implementations , Call for Review of a Proposed Recommendation , Call for Review of an Edited Recommendation , or Proposal to Rescind a Recommendation
- the Director's intention to sign a Memorandum of Understanding with another organization.
In
all
cases,
an
appeal
MUST
must
be
initiated
within
three
weeks
of
the
decision.
An
Advisory
Committee
representative
initiates
an
appeal
by
sending
a
request
to
the
Team
(explained
in
detail
in
the
New
Member
Orientation
).
The
Team
MUST
must
announce
the
appeal
process
to
the
Advisory
Committee
and
provide
an
address
for
comments
from
Advisory
Committee
representatives.
The
archive
of
these
comments
MUST
must
be
Member-visible.
If,
within
one
week
of
the
Team's
announcement,
5%
or
more
of
the
Advisory
Committee
support
the
appeal
request,
the
Team
MUST
must
organize
an
appeal
vote
asking
the
Advisory
Committee
to
approve
or
reject
the
decision.
7.3 Advisory Committee Votes
The Advisory Committee votes in elections for seats on the TAG or Advisory Board , and in the event of a formal appeal of a W3C decision . Whenever the Advisory Committee votes, each Member or group of related Members has one vote. In the case of Advisory Board and TAG elections , "one vote" means "one vote per available seat".
8 Workshops and Symposia
The
Team
organizes
Workshops
and
Symposia
to
promote
early
involvement
in
the
development
of
W3C
Activities
activities
from
Members
and
the
public.
The
goal
of
a
Workshop
is
usually
either
to
convene
experts
and
other
interested
parties
for
an
exchange
of
ideas
about
a
technology
or
policy,
or
to
address
the
pressing
concerns
of
W3C
Members.
Organizers
of
the
first
type
of
Workshop
MAY
may
solicit
position
papers
for
the
Workshop
program
and
MAY
may
use
those
papers
to
choose
attendees
and/or
presenters.
The goal of a Symposium is usually to educate interested parties about a particular subject.
The
Call
for
Participation
in
a
Workshop
or
Symposium
MAY
may
indicate
participation
requirements
or
limits,
and
expected
deliverables
(e.g.,
reports
and
minutes).
Organization
of
an
event
does
not
guarantee
further
investment
by
W3C
in
a
particular
topic,
but
MAY
may
lead
to
proposals
for
new
Activities
activities
or
groups.
Workshops
and
Symposia
generally
last
one
to
three
days.
If
a
Workshop
is
being
organized
to
address
the
pressing
concerns
of
Members,
the
Team
MUST
must
issue
the
Call
for
Participation
no
later
than
six
weeks
prior
to
the
Workshop's
scheduled
start
date.
For
other
Workshops
and
Symposia,
the
Team
MUST
must
issue
a
Call
for
Participation
no
later
than
eight
weeks
prior
to
the
meeting's
scheduled
start
date.
This
helps
ensure
that
speakers
and
authors
have
adequate
time
to
prepare
position
papers
and
talks.
Note:
In
general,
W3C
does
not
organize
conferences
.
.
Currently,
W3C
presents
its
work
to
the
public
at
the
annual
World
Wide
Web
Conference,
which
is
coordinated
by
the
International
World
Wide
Web
Conference
Committee
(
IW3C2
).
9 Liaisons
W3C uses the term "liaison" to refer to coordination of activities with a variety of organizations, through a number of mechanisms ranging from very informal (e.g., an individual from another organization participates in a W3C Working Group, or just follows its work) to mutual membership, to even more formal agreements. Liaisons are not meant to substitute for W3C membership.
All
liaisons
MUST
must
be
coordinated
by
the
Team
due
to
requirements
for
public
communication;
patent,
copyright,
and
other
IPR
policies;
confidentiality
agreements;
and
mutual
membership
agreements.
The
W3C
Director
MAY
may
negotiate
and
sign
a
Memorandum
of
Understanding
(
MoU
)
with
another
organization.
Before
signing
the
MoU,
the
Team
MUST
must
inform
the
Advisory
Committee
of
the
intent
to
sign
and
make
the
MoU
available
for
Advisory
Committee
review;
the
Advisory
Committee
MAY
may
appeal
.
Once
approved,
a
Memorandum
of
Understanding
SHOULD
should
be
made
public.
Information about W3C liaisons with other organizations and the guidelines W3C follows when creating a liaison [ PUB28 ] is available on the Web.
10 Member Submission Process
The
Member
Submission
process
allows
Members
to
propose
technology
or
other
ideas
for
consideration
by
the
Team.
After
review,
the
Team
MAY
may
publish
the
material
at
the
W3C
Web
site.
The
formal
process
affords
Members
a
record
of
their
contribution
and
gives
them
a
mechanism
for
disclosing
the
details
of
the
transaction
with
the
Team
(including
IPR
claims).
The
Team
also
publishes
review
comments
on
the
Submitted
materials
for
W3C
Members,
the
public,
and
the
media.
A Member Submission consists of:
- One or more documents developed outside of the W3C process, and
- Information about the documents, provided by the Submitter.
One
or
more
Members
(called
the
"Submitter(s)")
MAY
may
participate
in
a
Member
Submission.
Only
W3C
Members
MAY
may
be
listed
as
Submitter(s).
The Submission process consists of the following steps:
- One of the Submitter(s) sends a request to the Team to acknowledge the Submission request. The Team and Submitter(s) communicate to ensure that the Member Submission is complete.
-
After
Team
review,
the
Director
MUSTmust either acknowledge or reject the Submission request.-
If
acknowledged
,
the
Team
MUSTmust publish the Member Submission at the public W3C Web site, in addition to Team comments about the Member Submission. -
If
rejected
,
the
Submitter(s)
MAYmay appeal to either the TAG or the Advisory Board .
-
If
acknowledged
,
the
Team
Note: To avoid confusion about the Member Submission process, please note that:
-
Documents
in
a
Member
Submission
are
developed
outside
of
W3C.
These
documents
are
not
part
of
the
technical
report
development
process
(and
therefore
are
not
included
in
the
index
of
W3C
technical
reports
).
Members
wishing
to
have
documents
developed
outside
of
W3C
published
by
W3C
MUSTmust follow the Member Submission process. - The Submission process is not a means by which Members ask for "ratification" of these documents as W3C Recommendations .
- There is no requirement or guarantee that technology which is part of an acknowledged Submission request will receive further consideration by W3C (e.g., by a W3C Working Group).
Publication
of
a
Member
Submission
by
W3C
does
not
imply
endorsement
by
W3C,
including
the
W3C
Team
or
Members.
The
acknowledgment
of
a
Submission
request
does
not
imply
that
any
action
will
be
taken
by
W3C.
It
merely
records
publicly
that
the
Submission
request
has
been
made
by
the
Submitter.
A
Member
Submission
published
by
W3C
MUST
NOT
must
not
be
referred
to
as
"work
in
progress"
of
the
W3C.
The list of acknowledged Member Submissions [ PUB10 ] is available at the W3C Web site.
10.1 Submitter Rights and Obligations
When
more
than
one
Member
jointly
participates
in
a
Submission
request,
only
one
Member
formally
sends
in
the
request.
That
Member
MUST
must
copy
each
of
the
Advisory
Committee
representatives
of
the
other
participating
Members,
and
each
of
those
Advisory
Committee
representatives
MUST
must
confirm
(by
email
to
the
Team)
their
participation
in
the
Submission
request.
At
any
time
prior
to
acknowledgment,
any
Submitter
MAY
may
withdraw
support
for
a
Submission
request
(described
in
"
How
to
send
a
Submission
request
").
A
Submission
request
is
"withdrawn"
when
no
Submitter(s)
support
it.
The
Team
MUST
NOT
must
not
make
statements
about
withdrawn
Submission
requests.
Prior
to
acknowledgment,
the
Submitter(s)
MUST
NOT
,
must
not
,
under
any
circumstances
,
refer
to
a
document
as
"submitted
to
the
World
Wide
Web
Consortium"
or
"under
consideration
by
W3C"
or
any
similar
phrase
either
in
public
or
Member
communication.
The
Submitter(s)
MUST
NOT
must
not
imply
in
public
or
Member
communication
that
W3C
is
working
(with
the
Submitter(s))
on
the
material
in
the
Member
Submission.
The
Submitter(s)
MAY
may
publish
the
documents
in
the
Member
Submission
prior
to
acknowledgment
(without
reference
to
the
Submission
request).
After
acknowledgment,
the
Submitter(s)
MUST
NOT
,
must
not
,
under
any
circumstances
,
imply
W3C
investment
in
the
Member
Submission
until,
and
unless,
the
material
has
been
adopted
as
part
a
deliverable
of
a
W3C
Activity
.
Working
Group
10.1.1 Scope of Member Submissions
When
a
technology
overlaps
in
scope
with
the
work
of
a
chartered
Working
Group,
Members
SHOULD
should
participate
in
the
Working
Group
and
contribute
the
technology
to
the
group's
process
rather
than
seek
publication
through
the
Member
Submission
process.
The
Working
Group
MAY
may
incorporate
the
contributed
technology
into
its
deliverables.
If
the
Working
Group
does
not
incorporate
the
technology,
it
SHOULD
NOT
should
not
publish
the
contributed
documents
as
Working
Group
Notes
since
Working
Group
Notes
represent
group
output,
not
input
to
the
group.
On
the
other
hand,
while
W3C
is
in
the
early
stages
of
developing
an
Activity
Proposal
or
a
charter,
Members
SHOULD
should
use
the
Submission
process
to
build
consensus
around
concrete
proposals
for
new
work.
Members
SHOULD
NOT
should
not
submit
materials
covering
topics
well
outside
the
scope
of
W3C's
mission
[
PUB15
].
10.1.2 Information Required in a Submission Request
The
Submitter(s)
and
any
other
authors
of
the
submitted
material
MUST
must
agree
that,
if
the
request
is
acknowledged,
the
documents
in
the
Member
Submission
will
be
subject
to
the
W3C
Document
License
[
PUB18
]
and
will
include
a
reference
to
it.
The
Submitter(s)
MAY
may
hold
the
copyright
for
the
documents
in
a
Member
Submission.
The request must satisfy the Member Submission licensing commitments of section 3.3 of the W3C Patent Policy [ PUB33 ].
The
Submitter(s)
MUST
must
include
the
following
information:
- The list of all submitting Members.
- Position statements from all submitting Members (gathered by the Submitter). All position statements must appear in a separate document.
-
Complete
electronic
copies
of
any
documents
submitted
for
consideration
(e.g.,
a
technical
specification,
a
position
paper,
etc.)
If
the
Submission
request
is
acknowledged,
these
documents
will
be
published
by
W3C
and
therefore
must
satisfy
the
Communication
Team's
Publication
Rules
[
PUB31
].
Submitters
may
hold
the
copyright
for
the
material
contained
in
these
documents,
but
when
published
by
W3C,
these
documents
MUSTmust be subject to the provisions of the W3C Document License [ PUB18 ].
The
request
MUST
must
also
answer
the
following
questions.
- What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its use? Again, many answers are possible, but the specific answer will affect the Team's decision.
- What resources, if any, does the Submitter intend to make available if the W3C acknowledges the Submission request and takes action on it?
- What action would the Submitter like W3C to take if the Submission request is acknowledged?
- What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating where change control will reside if the request is acknowledged.
For other administrative requirements related to Submission requests, see " How to send a Submission request " [ MEM8 ].
10.2 Team Rights and Obligations
Although
they
are
not
technical
reports,
the
documents
in
a
Member
Submission
MUST
must
fulfill
the
requirements
established
by
the
Team,
including
the
Team's
Publication
Rules
.
The Team sends a validation notice to the Submitter(s) once the Team has reviewed a Submission request and judged it complete and correct.
Prior
to
a
decision
to
acknowledge
or
reject
the
request,
the
request
is
Team-only
,
and
the
Team
MUST
must
hold
it
in
the
strictest
confidentiality.
In
particular,
the
Team
MUST
NOT
must
not
comment
to
the
media
about
the
Submission
request.
10.3 Acknowledgment of a Submission Request
The
Director
acknowledges
a
Submission
request
by
sending
an
announcement
to
the
Advisory
Committee.
Though
the
announcement
MAY
may
be
made
at
any
time,
the
Submitter(s)
can
expect
an
announcement
between
four
to
six
weeks
after
the
validation
notice
.
The
Team
MUST
must
keep
the
Submitter(s)
informed
of
when
an
announcement
is
likely
to
be
made.
Once
a
Submission
request
has
been
acknowledged,
the
Team
MUST
:
must
:
- Publish the Member Submission.
- Publish Team comments about the Submission request.
If
the
Submitter(s)
wishes
to
modify
a
document
published
as
the
result
of
acknowledgment,
the
Submitter(s)
MUST
must
start
the
Submission
process
from
the
beginning,
even
just
to
correct
editorial
changes.
10.4 Rejection of a Submission Request
The
Director
MAY
may
reject
a
Submission
request
for
a
variety
of
reasons,
including
any
of
the
following:
- The ideas expressed in the request overlap in scope with the work of a chartered Working Group, and acknowledgment might jeopardize the progress of the group.
- The IPR statement made by the Submitter(s) is inconsistent with the W3C's Patent Policy [ PUB33 ], Document License [ PUB18 ], or other IPR policies.
- The ideas expressed in the request are poor, might harm the Web, or run counter to W3C's mission .
- The ideas expressed in the request lie well outside the scope of W3C's mission.
In
case
of
a
rejection,
the
Team
MUST
must
inform
the
Advisory
Committee
representative(s)
of
the
Submitter(s).
If
requested
by
the
Submitter(s),
the
Team
MUST
must
provide
rationale
to
the
Submitter(s)
about
the
rejection.
Other
than
to
the
Submitter(s),
the
Team
MUST
NOT
must
not
make
statements
about
why
a
Submission
request
was
rejected.
The
Advisory
Committee
representative(s)
of
the
Submitters(s)
MAY
may
appeal
the
rejection
to
the
TAG
if
the
reasons
are
related
to
Web
architecture,
or
to
the
Advisory
Board
if
the
request
is
rejected
for
other
reasons.
In
this
case
the
Team
SHOULD
should
make
available
its
rationale
for
the
rejection
to
the
appropriate
body.
The
Team
will
establish
a
process
for
such
appeals
that
ensures
the
appropriate
level
of
confidentiality
.
11 Process Evolution
The W3C Process Document undergoes similar consensus-building processes as technical reports, with the Advisory Board acting as the sponsoring Working Group.
The Advisory Board initiates review of a Process Document as follows:
- The Team sends a Call for Review to the Advisory Committee and other W3C groups.
-
After
comments
have
been
formally
addressed
and
the
document
possibly
modified,
the
Team
seeks
endorsement
from
the
Members
by
initiating
an
Advisory
Committee
review
of
a
Proposed
Process
Document.
The
review
period
MUSTmust last at least four weeks . -
After
the
Advisory
Committee
review
,
if
there
is
consensus,
the
Team
enacts
the
new
process
officially
by
announcing
the
W3C
decision
to
the
Advisory
Committee.
If
there
was
dissent
,
Advisory
Committee
representatives
MAYmay appeal the decision.
W3C
MAY
may
also
modify
a
Process
Document
by
following
the
processes
for
modifying
a
Recommendation
.
Reviews of the Process Document are not public reviews.
12 References
12.1 Public Resources
The following public information is available at the W3C Web site .
- [PUB5]
- How to Join W3C
- [PUB6]
- Membership Agreement
- [PUB8]
- The list of current W3C Members
- [PUB9]
- The list of W3C Activities
- [PUB10]
- The list of acknowledged Member Submissions
- [PUB11]
- The W3C technical reports index
- [PUB13]
- Submission request overview
- [PUB14]
- The W3C Team
- [PUB15]
- About the World Wide Web Consortium
- [PUB16]
- The list of published Team Submissions
- [PUB17]
- Invited expert and collaborators agreement
- [PUB18]
- W3C Document License
- [PUB19]
- W3C Software Notice and License
- [PUB20]
- Translations of W3C technical reports
- [PUB21]
- Public W3C mailing lists
- [PUB23]
- Conflict of Interest Policy for W3C Team Members Engaged in Outside Professional Activities
- [PUB25]
- Technical Architecture Group (TAG) Charter
- [PUB26]
- The TAG home page
- [PUB27]
- Tips for Getting to Recommendation Faster
- [PUB28]
- W3C liaisons with other organizations
- [PUB30]
- The Advisory Board home page
- [PUB31]
- Publication Rules
- [PUB32]
- W3C Fellows Program
- [PUB33]
- 5 Feb 2004 version of the W3C Patent Policy . The latest version of the W3C Patent Policy is available at http://www.w3.org/Consortium/Patent-Policy/.
- [PUB35]
- In-place modification of W3C Technical Reports
13.2
12.2
Member-only
Resources
The following Member-only information is available at the W3C Web site .
- [MEM1]
- Current Advisory Committee representatives
- [MEM2]
- Group mailing lists
- [MEM3]
- The calendar of all scheduled official W3C events
- [MEM4]
- The New Member Orientation , which includes an introduction to W3C processes from a practical standpoint, including relevant email addresses.
- [MEM5]
- Advisory Committee meetings
- [MEM6]
- Member Web site
- [MEM8]
- How to send a Submission request
- [MEM9]
- The Art of Consensus , a guidebook for W3C Working Group Chairs and other collaborators
- [MEM14]
- Guidelines for Disciplinary Action
- [MEM15]
- How to Organize an Advisory Board or TAG election
12.3 Other References
- [RFC2119]
- "Key words for use in RFCs to Indicate Requirement Levels" , S. Bradner, March 1997.
- [RFC2777]
- "Publicly Verifiable Nomcom Random Selection" , D. Eastlake 3rd, February 2000.
13 Acknowledgments
The
following
individuals,
either
through
the
Revising
W3C
Process
Community
Group
or
independently,
individuals
have
contributed
to
the
development
of
this
version
of
the
proposal
for
a
revised
Process:
Dan
Daniel
Appelquist
(Telefonica),
Art
Barstow
(Nokia),
(Nokia,
unaffiliated),
Robin
Berjon
(W3C),
Wayne
Carr
(Intel),
Judy
Brewer
(W3C),
Marcos
Cáceres
(Mozilla),
Wayne
Carr
(Intel),
Michael
Champion
(W3C),
Mark
Crawford
(SAP),
Fantasai
Karl
Dubost
(Mozilla),
Fantasai
(unaffiliated),
Virginie
Galindo
(Gemalto),
Daniel
Glazman
(Disruptive
Innovations),
Joe
Hall
(CDT),
Ivan
Herman
(W3C),
Ian
Hickson
(Google),
Ian
Jacobs
(W3C),
Eduardo
Gutentag
(unaffiiliated),
Brad
Hill
(Facebook),
Jeff
Jaffe
(W3C),
Cullen
Jennings
(Cisco),
Chris
Lilley
(W3C),
Giri
Mandyam
(Qualcomm),
Larry
Masinter
(Adobe
Systems),
TV
Raman
(Google),
Brain
Kardell
(JQuery),
Peter
Linss
(HP),
Nigel
Megitt
(BBC),
Olle
Olsson
(SICS),
Natasha
Rooney
(GSMA),
Sam
Ruby
(IBM),
David
Singer
(Apple),
Ralph
Swick
(W3C),
Henri
Sivonen
(Mozilla),
Josh
Soref
(BlackBerry),
Anne
van
Kesteren,
Kesteren
(Mozilla),
Léonie
Watson
(The
Paciello
Group),
Mike
West
(Google),
Chris
Wilson
(Google),
Steve
Zilles
(Adobe
Systems).
(Adobe).
The
following
individuals
participated
in
contributed
to
the
preparation
development
of
earlier
versions
of
W3C
Process
Documents,
including
this
draft,
while
serving
(at
different
times)
on
the
W3C
Advisory
Board:
Process:
Jean-François
Abramatic
(IBM,
and
previously
ILOG
and
W3C),
Dan
Appelquist
(Telefonica),
Art
Barstow
(Nokia),
Ann
Bassetti
(The
Boeing
Company),
Jim
Bell
(HP),
Robin
Berjon
(W3C),
Tim
Berners-Lee
(W3C),
Klaus
Birkenbihl
(Fraunhofer
Gesellschaft),
Don
Brutzman
(Web3D),
Carl
Cargill
(Sun
(Netscape,
Sun
Microsystems),
Wayne
Carr
(Intel),
Marcos
Cáceres
(Mozilla),
Michael
Champion
(Microsoft),
Paul
Cotton
(Microsoft),
Mark
Crawford
(SAP),
Tantek
Çelik
(Mozilla),
Don
Deutsch
(Oracle),
David
Fallside
(IBM),
Fantasai
(Mozilla),
Wendy
Fong
(Hewlett-Packard),
Virginie
Galindo
(Gemalto),
Daniel
Glazman
(Disruptive
Innovations),
Paul
Grosso
(Arbortext),
Eduardo
Gutentag
(Sun
Microsystems),
Joe
Hall
(CDT),
Ivan
Herman
(W3C),
Ian
Hickson
(Google),
Steve
Holbrook
(IBM),
Renato
Iannella
(IPR
Systems),
Ian
Jacobs
(W3C),
Jeff
Jaffe
(W3C),
Cullen
Jennings
(Cisco),
Sally
Khudairi
(W3C),
John
Klensin
(MCI),
Tim
Krauskopf
(Spyglass),
Kari
Laihonen
(Ericsson),
Ken
Laskey
(MITRE),
Ora
Lassila
(Nokia),
Håkon
Wium
Lie
(Opera
Software),
Chris
Lilley
(W3C),
Bede
McCall
(MITRE),
Giri
Mandyam
(Qualcomm),
Larry
Masinter
(Adobe
Systems),
Bede
McCall
(MITRE),
Qiuling
Pan
(Huawei),
TV
Raman
(Google),
Thomas
Reardon
(Microsoft),
Claus
von
Riegen
(SAP
AG),
David
Singer
(Apple),
David
Singer
(IBM),
Ralph
Swick
(W3C),
Anne
van
Kesteren,
Jean-Charles
Verdié
(MStar),
Chris
Wilson
(Google),
Lauren
Wood
(unaffiliated),
and
Steve
Zilles
(Adobe
Systems).
15
14
Changes
This
version
of
the
process
incorporates
editorial
changes
to
Chapter
7
.
document
is
based
on
1
August
2014
Process.
Detailed
change
logs
are
available.
The
major
focus
has
been
to
clarify
obligations,
and
who
is
obliged
to
meet
them,
in
the
process
of
developing
a
specification
notable
changes
include:
Current draft
-
A
working
group
can
propose
non-substantive
editorial
corrections
directly
as
a
W3CProposed Recommendationor Note. A particular change, removing the Last Call phase is intended to clarify that Working( ISSUE-152 ) - Sections above 5 have been renumbered (reduced by one since chapter 5 was removed)
-
More
explicit
mention
of
W3C
Horizontal
Groups
are responsible for ensuring that their specification ishas been madeavailable for review and is actively reviewed at appropriate pointsinits development by appropriate stakeholders. This is particularly intended to stop the cycling of specifications between Last Call (for Patent review) and Candidate Recommendation, as well asregards tomore generally support methodologies such as test-driven standardisation, without enforcing a specific methodology on any groupwide review andwithout losing the overall benefit of W3C's requirement for "horizontal" review. Other notable changes from the 14 October 2005 Process Document include:dependencies - Various minimal editorial cleanups
3 March "AC last call" draft
-
The
Director must address dissentingdefault channel for AC reviewcomments publicly , 2 weeks before publicationhas been removed in favor of aRecommendation.requirement for each review to specify a default ( ISSUE-154 ) -
If W3C closes aA procedure for resignation from WorkingGroup, they must republish its unfinished work as Notes.and Interest Groups has been provided ( ISSUE-151 ) -
Errata must not be made normative except by revising a RecommendationEditorial cleanups to 7.2.3.1 Wide Review -
New requirements that Working groups should document known implementation and must document expected next steps for all publicationsEditorial Changes to 7.7.1 Errata Management - ISSUE-141 -
New requirement that WorkingRemove Coordination groupsshould publish abandoned work as a W3C Note- ISSUE-129 -
Recognition that Interest Groups may publish W3C NotesRemove vestigial traces of Good Standing throughout -
Last Call and Candidate Recommendation have been collapsed together. SomeLoosen constraints on multiple employees ofthe requirements are therefore enforced earlier in the process.a single member being on TAG - section 2.5.1 -
Advisory Committee review now begins at the same time as Candidate recommendation, but still ends no less than 4 weeks after publication as a Proposed Recommendation.Replace "W3C Chair" with "CEO" throughout -
Implementation requirements for passing beyond Candidate Recommendation are not simply listed as "2 interoperable implementations", instead a new sections gives guidance onEditorial tweaks to what isconsidered when assessing " adequate implementation experiencerequested in 7.2.3.1 Wide Review". -
InsteadRemove section 6.2.7 "Heartbeat" publishing requirement, redundant with the first requirement ofrelying on a Last Call publication for adequate review Working Groups need to demonstrate " wide reviewsection 7.3.2" as part of
30 September "AC intermediate review" draft
Provided
to
the
requirements
Advisory
Committee
to
publish
a
spec
as
Candidate
Recommendation,
while
leaving
them
review
the
following
changes
made
compared
to
achieve
this
as
they
see
fit.
the
1
August
2014
Operative
Process
document
- Remove Activities from the Process (as resolved multiple times since 2007)
-
There isRemove 6.2.1.7 Good Standing in astronger emphasis (without creating new formal requirements) on getting review and testing implementation as early as possible. How to do this is left toWorkingGroups to determine.Group