Skip to content

Commit

Permalink
Attempt to address #9.
Browse files Browse the repository at this point in the history
  • Loading branch information
@hober
hober committed Apr 9, 2020
1 parent 2d9da77 commit 79e9639
Showing 1 changed file with 45 additions and 106 deletions.
151 changes: 45 additions & 106 deletions charter.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -223,6 +223,10 @@ <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.

<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 +237,41 @@ <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.

<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
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
Chairs and Champions 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.

<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
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 +299,23 @@ <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 when, in the judgement of its Champions and the Chairs,
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 into account when making their decision.

<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 appoionted 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,9 +335,6 @@ <h2 id=specifications>Specifications</h2>

<ul>
<li>because the Specification has been migrated elsewhere
<li>because the Specification no longer has the support of
multiple <a href=#implementer>implementers</a> and is unlikely to regain
it
<li>because the Specification no longer has
an <a href=#editors>Editor</a> and a replacement cannot be found
</ul>
Expand Down Expand Up @@ -371,19 +375,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 Specificaitons will likely result in pull requests on
various WHATWG specs.
</dl>

Expand Down Expand Up @@ -468,14 +468,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 +501,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 +529,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 +624,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

0 comments on commit 79e9639

Please sign in to comment.