Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Try to address #9. #25

Merged
merged 10 commits into from
Apr 14, 2020
Merged

Try to address #9. #25

Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
79e9639
Attempt to address #9.
hober Apr 9, 2020
b194ff2
Other expressions of implementer interest are also good information t…
hober Apr 9, 2020
7cfa08c
s/judgment/consensus/
hober Apr 9, 2020
fd1bbda
Prefer archiving over transferring repositories.
hober Apr 9, 2020
bb2e3af
fix typo.
hober Apr 9, 2020
9c36e9c
Whitespace.
hober Apr 9, 2020
a89dc39
Fix typos.
hober Apr 9, 2020
7ff0490
Champions may ask for a dedicated reposoitory, and the Chairs will ge…
hober Apr 13, 2020
2dd8162
Ensure the set of Champions for each Proposal is documented.
hober Apr 13, 2020
12a64a7
Restore and reword one of the possible reasons for removing a specifi…
hober Apr 13, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
167 changes: 57 additions & 110 deletions charter.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -223,6 +223,12 @@ <h2 id=proposals>Proposals</h2>
consideration and potential adoption as
a <a href=#specifications>Specification</a>.

<p>Each Proposal has one or more <dfn>Champions</dfn>, beginning with
the Community Group Participant who proposed it. Champions are
self-organized. Proposals should explicitly list their Champions, and
Champions should keep this list updated as the set of Champions for the
Proposal changes.

<p>Any Community Group Participant may make a Proposal by filing
<a href=https://github.com/privacycg/proposals/issues>an issue</a> in
the
Expand All @@ -233,44 +239,42 @@ <h2 id=proposals>Proposals</h2>
<p>The Community Group may discuss the Proposal on GitHub and during
teleconferences or face-to-face <a href=#meetings>meetings</a>.

<p>The <a href=#chairs>Chairs</a> may create a dedicated repository for
a Proposal. They may do this for any reason, such as but not limited to:
<p>Champions are responsible for the technical content of their
Proposal. They are expected to solicit input from Community Group
Participants, and they may consider and respond to comments,
suggestions, and objections on their Proposal from Participants and the
public.

<ul>
<li>because the Proposal has become sufficiently complex that writing an
explainer is warranted
<li>because the Proposal is sufficiently complex that having a dedicated
issue tracker for it is warranted
<li>because multiple <a href=#implementer>implementers</a> have
expressed interest in the Proposal
</ul>
<p>Champions may ask the <a href=#chairs>Chairs</a> to create a
dedicated repository for their Proposal. The Chairs will generally honor
such requests, though they may choose not to (if, for example, they
believe the Proposal to be <a href=#out-of-scope>out of scope</a>).

<p>Proposals begin as or evolve into
<a href=https://w3ctag.github.io/explainers>explainers</a> which
describe the proposed changes to the web platform, and which may serve
as the basis for a Specification (should the Proposal be adopted as
one).

<p class=note>While explainers are Community Group Reports as defined in
the <a href=https://www.w3.org/community/about/agreements/>Community and
Business Group Process</a>, they are not Specifications as defined in
that document.
describe a user-facing problem which needs to be solved and how the
authors propose to solve it. Explainers are Community Group Reports as
defined in the
<a href=https://www.w3.org/community/about/agreements/>Community and
Business Group Process</a>, but they are not Specifications as defined
in that document.

<p>Proposals may be withdrawn by their originators, or may be closed by
<p>Proposals may be withdrawn by their Champions, or may be closed by
the Chairs (if, for example, the Chairs deem the Proposal to
be <a href=out-of-scope>out of scope</a> or the Proposal fails to gain
sufficient <a href=#implementer>implementer</a> support to be adopted as
a Specification). If such a Proposal has a dedicated repository, the
Chairs should take steps to ensure the data is not lost, perhaps by
transferring the repository to a different organization or user, or by
archiving it.
be <a href=out-of-scope>out of scope</a>, or if its number of Champions
drops to zero). If such a Proposal has a dedicated repository, the
hober marked this conversation as resolved.
Show resolved Hide resolved
Chairs and Champions should take steps to ensure the data is not lost,
perhaps by archiving the repository or by transferring it to a different
organization or user.

<div id=work-items hidden><!-- keep old links working --></div>
<h2 id=specifications>Specifications</h2>

<p>The Community Group may produce <dfn>Specifications</dfn>—as defined
in the <a href=https://www.w3.org/community/about/agreements/>Community
and Business Group Process</a>—a special kind of Community Group Report
<p>Per the
<a href=https://www.w3.org/community/about/agreements/>Community and
Business Group Process</a>, this Community Group may
produce <dfn>Specifications</dfn>—a special kind of Community
hober marked this conversation as resolved.
Show resolved Hide resolved
Group Report
whose purpose is to enable interoperability between independent
implementations of the features it defines. Each Specification has one
or more <a href=#editors>Editors</a>, who are appointed by
Expand Down Expand Up @@ -298,17 +302,25 @@ <h2 id=specifications>Specifications</h2>
<p>This list will be kept <a href=#amendments>updated</a> by the Chairs
to reflect the current set of Specifications of the Community Group.

<p>The Chairs may add Specifications, but must not add Specifications
which lack the support of at least
two <a href=#implementer>implementers</a>.
<p>The Community Group may adopt a <a href="#proposals">Proposal</a> as
a Specification if it is the <a href=#consensus>consensus</a> of its
Champions and the Chairs that such a Specification would be likely to
enable and lead to independent, interoperable implementations. The
Chairs and Champions may solicit commitments from organizations to
provide
<a href="https://www.w3.org/2019/Process-20190301/#implementation-experience">adequate
implementation experience</a> of the Proposal's features, and may take
such commitments or other such expressions of implementer interest into
account when making their decision.
hober marked this conversation as resolved.
Show resolved Hide resolved

<p>Each Specification should be accompanied by an explainer describing
its proposed changes to the web platform. Editors should keep the
Specification's explainer up-to-date with the Specification as it
evolves.

<p class=note>Since Specifications typically begin life as a Proposal
before being formally adopted, they usually start out with an explainer.
<p class=note>Because Specifications begin life as Proposals, they
typically start out with an explainer already written, and Proposal
Champions are typically appointed Editors.

<p>When a Specification's Editors deem the Specification ready for
migration, they will notify the Chairs. The CG may produce a Final
Expand All @@ -328,16 +340,16 @@ <h2 id=specifications>Specifications</h2>

<ul>
<li>because the Specification has been migrated elsewhere
<li>because the Specification no longer has the support of
hober marked this conversation as resolved.
Show resolved Hide resolved
multiple <a href=#implementer>implementers</a> and is unlikely to regain
it
<li>because it is no longer the <a href=#consensus>consensus</a> of its
Champions and the Chairs that the Specification is likely to enable and
lead to independent, interoperable implementations.
<li>because the Specification no longer has
an <a href=#editors>Editor</a> and a replacement cannot be found
</ul>

<p>The Chairs should take steps to ensure the repositories of removed
Specifications are not lost, perhaps by transferring the repository to a
different organization or user, or by archiving it.
Specifications are not lost, perhaps by archiving the repository or by
transferring it to a different organization or user.

<h2 id=coordination>Coordination</h2>

Expand Down Expand Up @@ -371,19 +383,15 @@ <h3 id=w3c-coordination>W3C Groups</h3>

<dt><a href=https://www.w3.org/community/wicg/>Web Platform Incubator
Community Group (WICG)</a>
<dd>WICG is expected to be a major source of Specifications for this
group.
<p class=note>Only privacy-related WICG proposals which have the support
of at least two <a href=#implementer>implementers</a> are eligible for
this group to take up as Specifications.
<dd>WICG is expected to be a major source of Proposals for this group.
</dl>

<h3 id=external-coordination>External Organizations</h3>

<dl>
<dt><a href=https://whatwg.org/>Web Hypertext Application Technology
Working Group (WHATWG)</a>
<dd>Much of this group’s work will likely result in pull requests on
<dd>Many of our Specifications will likely result in pull requests on
various WHATWG specs.
</dl>

Expand Down Expand Up @@ -468,14 +476,6 @@ <h3 id=work-mode>Work Mode</h3>
<a href=https://github.com/privacycg/.github/blob/master/SECURITY.md>posted
on GitHub</a> and kept up-to-date.

<p>Any change to a <a href=#specifications>Specification</a> that
represents a feature addition must have the support of at least
two <a href=#implementer>implementers</a>.

<p>For any change that removes a feature from a Specification, the
feature being removed must either be not widely implemented, or must be
in the process of being removed from implementations.

<h4 id=meetings>Meetings</h4>

<p>The Community Group may hold teleconferences and face-to-face
Expand Down Expand Up @@ -509,19 +509,14 @@ <h3 id=decisions>Decision Policy</h3>
<p>In case of a conflict among Community Group Participants, Editors are
expected to go to significant lengths to resolve disagreements. In the
end, they make a judgment call to pick the best option they believe will
have <a href=#implementer>multi-implementer support</a>.
preserve privacy and lead to independent, interoperable implementations.

<p>If a Community Group Participant is not satisfied with the resolution
of an issue, they may request that the Editors revisit the issue. If not
satisfied with the Editors’ final response, Community Group Participants
may <a href=#appeals>appeal to the Chairs</a>.

<p>If a Community Group Participant believes the Editors’ choice will
not have <a href=#implementer>multi-implementer support</a>, and they
cannot convince the Editors, then they may <a href=#appeals>appeal to
the Chairs</a>. The Chairs may correct or uphold the decision based on
their own understanding of support
from <a href=#implementer>implementers</a>.
may <a href=#appeals>appeal to the Chairs</a>. The Chairs may correct or
uphold the decision based on their own understanding of what will best
preserve privacy and lead to independent, interoperable implementations.

<p>It is the Chairs’ responsibility to ensure that the decision process
is fair and does not unreasonably favor or discriminate against any
Expand All @@ -542,7 +537,7 @@ <h3 id=decisions>Decision Policy</h3>
approach. If there isn’t enough existing web content affected by the
change to make compatibility a concern, the Editors will, to the extent
possible, be consistent with our goal to increase user privacy and align
with <a href=#implementer>implementer</a> majority.
with implementer majority.

<p>Specifications should not make references to or rely on specific
browser engine implementation details.
Expand Down Expand Up @@ -637,54 +632,6 @@ <h2 id=glossary>Glossary</h2>
then Consensus may be established simply by moving forward on the
proposal or a course of action; this is anticipated to be the norm
for most matters.”
<dt id=implementer>implementer
<dd>
<p>The WHATWG
<a href=https://whatwg.org/sg-agreement#qualifying-entity>defines
implementer</a> as "an entity that develops one of the core
end-to-end integrated web browser platform engines and distributes
its integrated implementations widely." This definition is useful
for determining multi-implementer support of core web platform
features, features which are typically and reasonably implemented
within the core end-to-end integrated web browser platform engines,
and this Community Group relies on this definition for such
features.
<p>Some privacy-related features ship in browsers but are not
implemented within browser engines. In cases where multiple entities
share a browser engine in common, they only count as multiple
implementers of a feature if that feature’s implementations are
separate and are not believed to be specific to the internals of the
engine.
<p class=example title="Example: two browsers, separate engines">The
Peach Foundation ships Walkabout, a web browser built on the
MeshTools browser engine. Nanoware also ships a web browser, Vertex,
built on the Shrug browser engine. If a feature has the support in
both MeshTools and Shrug, as shipping (or as is expected to ship) in
Walkabout and Vertex, it can be said to have multi-implementer
support.
<p class=example title="Example: two browsers, shared engine, shared
implementation">Valiant Inc. ships Valiant, a web browser built on
the Shrug browser engine. The Avogadro Corporation ships a web
browser, Veneer, also built on the Shrug browser engine. A feature
implemented in Shrug counts as having one implementer supporting it,
even if that feature ships in both Valiant and Veneer.
<p class=example title="Example: two browsers, shared engine,
separate implementations (existing)">Valiant and Vertex both ship a
feature, but it is not a feature with a shared, underlying
implementation in the Shrug engine. Such a feature counts as having
two implementers supporting it, even though Valiant and Vertex are
both built on Shrug, because this particular feature has seperate,
non-shared implementations.
<p class=example title="Example: two browsers, shared engine,
separate implementations (expected)">Valiant and Vertex (who, again,
share an engine) both express implementer interest in a feature that
does not yet have any implementations. If both implementers indicate
that they do not expect to share an implementation (they do not
expect to land their implementations in Shrug), the feature counts
as having two implementers supporting it. If both implementers
expect they’d share an implementation in Shrug, it counts as having
one implementer supporting it.
</dd>
</dl>

<h2 id=about>About this Charter</h2>
Expand Down