diff --git a/charter.html b/charter.html index 1cc0c51..59d3f95 100644 --- a/charter.html +++ b/charter.html @@ -223,6 +223,10 @@

Proposals

consideration and potential adoption as a Specification. +

Each Proposal has one or more Champions, beginning with +the Community Group Participant who proposed it. Champions are +self-organized. +

Any Community Group Participant may make a Proposal by filing an issue in the @@ -233,44 +237,41 @@

Proposals

The Community Group may discuss the Proposal on GitHub and during teleconferences or face-to-face meetings. -

The Chairs may create a dedicated repository for -a Proposal. They may do this for any reason, such as but not limited to: +

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. -

+

Champions may ask the Chairs to create a +dedicated repository for their Proposal.

Proposals begin as or evolve into explainers 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). - -

While explainers are Community Group Reports as defined in -the Community and -Business Group Process, 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 +Community and +Business Group Process, but they are not Specifications as defined +in that document. -

Proposals may be withdrawn by their originators, or may be closed by +

Proposals may be withdrawn by their Champions, or may be closed by the Chairs (if, for example, the Chairs deem the Proposal to -be out of scope or the Proposal fails to gain -sufficient implementer 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 out of scope, 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.

Specifications

-

The Community Group may produce Specifications—as defined -in the Community -and Business Group Process—a special kind of Community Group Report +

Per the +Community and +Business Group Process, this Community Group may +produce Specifications—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 Editors, who are appointed by @@ -298,17 +299,23 @@

Specifications

This list will be kept updated by the Chairs to reflect the current set of Specifications of the Community Group. -

The Chairs may add Specifications, but must not add Specifications -which lack the support of at least -two implementers. +

The Community Group may adopt a Proposal 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 adequate +implementation experience of the Proposal's features, and may take +such commitments into account when making their decision.

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. -

Since Specifications typically begin life as a Proposal -before being formally adopted, they usually start out with an explainer. +

Because Specifications begin life as Proposals, they +typically start out with an explainer already written, and Proposal +Champions are typically appoionted Editors.

When a Specification's Editors deem the Specification ready for migration, they will notify the Chairs. The CG may produce a Final @@ -328,9 +335,6 @@

Specifications

@@ -371,11 +375,7 @@

W3C Groups

Web Platform Incubator Community Group (WICG) -
WICG is expected to be a major source of Specifications for this -group. -

Only privacy-related WICG proposals which have the support -of at least two implementers are eligible for -this group to take up as Specifications. +

WICG is expected to be a major source of Proposals for this group.

External Organizations

@@ -383,7 +383,7 @@

External Organizations

Web Hypertext Application Technology Working Group (WHATWG) -
Much of this group’s work will likely result in pull requests on +
Many of our Specificaitons will likely result in pull requests on various WHATWG specs.
@@ -468,14 +468,6 @@

Work Mode

posted on GitHub and kept up-to-date. -

Any change to a Specification that -represents a feature addition must have the support of at least -two implementers. - -

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. -

Meetings

The Community Group may hold teleconferences and face-to-face @@ -509,19 +501,14 @@

Decision Policy

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 multi-implementer support. +preserve privacy and lead to independent, interoperable implementations.

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 appeal to the Chairs. - -

If a Community Group Participant believes the Editors’ choice will -not have multi-implementer support, and they -cannot convince the Editors, then they may appeal to -the Chairs. The Chairs may correct or uphold the decision based on -their own understanding of support -from implementers. +may appeal to the Chairs. 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.

It is the Chairs’ responsibility to ensure that the decision process is fair and does not unreasonably favor or discriminate against any @@ -542,7 +529,7 @@

Decision Policy

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 implementer majority. +with implementer majority.

Specifications should not make references to or rely on specific browser engine implementation details. @@ -637,54 +624,6 @@

Glossary

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.” -
implementer -
-

The WHATWG - defines - implementer 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. -

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. -

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. -

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. -

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. -

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. -

About this Charter