From ddf20911b2c738815d2b190b8c1e810054971d3a Mon Sep 17 00:00:00 2001 From: Theresa O'Connor Date: Thu, 2 Apr 2020 08:32:38 -0700 Subject: [PATCH 1/4] Since Work Items are Specifications, let's call them that. --- charter.html | 161 ++++++++++++++++++++++++++------------------------- 1 file changed, 83 insertions(+), 78 deletions(-) diff --git a/charter.html b/charter.html index b164bfe..b36deb8 100644 --- a/charter.html +++ b/charter.html @@ -143,9 +143,9 @@

Chairs

  • ensuring the group adheres to its Process,
  • judging features or ideas as in or out of scope, -
  • focusing the group's limited time on the Proposals and Work Items -most likely to positively impact privacy on the web via wide -implementation and adoption, +
  • focusing the group's limited time on the Proposals and +Specifications most likely to positively impact privacy on the web via +wide implementation and adoption,
  • moderating the group's discussions, whatever the forum (GitHub, mailing lists, face to face, etc.),
  • running teleconferences and @@ -220,8 +220,8 @@

    Chair Selection

    Proposals

    A Proposal is an idea brought to the Community Group for -consideration and potential adoption as a Work -Item. +consideration and potential adoption as +a Specification.

    Any Community Group Participant may make a Proposal by filing an issue in @@ -248,7 +248,8 @@

    Proposals

    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 Work Item (should the Proposal be adopted as one). +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 @@ -259,22 +260,23 @@

    Proposals

    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 Work Item). 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. +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. -

    Work Items

    +
    +

    Specifications

    -

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

    The Community Group may produce Specifications—as defined +in the Community +and Business Group Process—a special kind of Community Group Report whose purpose is to enable interoperability between independent -implementations of the features it defines. Each Work Item has one +implementations of the features it defines. Each Specification has one or more Editors, who are appointed by the Chairs. -

    The current set of Work Items of the Community Group are: +

    The current set of Specifications of the Community Group are: @@ -294,45 +296,47 @@

    Work Items

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

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

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

    Each Work Item should be accompanied by an explainer describing its -proposed changes to the web platform. Editors should keep the Work -Item's explainer up-to-date with the Work Item as it evolves. +

    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 Work Items typically begin life as a Proposal before -being formally adopted, they usually start out with an explainer. +

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

    When a Work Item's Editors deem the Work Item ready for migration, -they will notify the Chairs. The CG may produce a Final Community Group -Report at this time. The Editors and Chairs will identify the best -destination standards body or bodies, and will then work with those -bodies to successfully migrate the Work Item. +

    When a Specification's Editors deem the Specification ready for +migration, they will notify the Chairs. The CG may produce a Final +Community Group Report at this time. The Editors and Chairs will +identify the best destination standards body or bodies, and will then +work with those bodies to successfully migrate the Specification. -

    When migrated to the standards track, Work Items might +

    When migrated to the standards track, Specifications might become standalone specifications, they might be integrated into one or more existing specifications, or they might result in a combination of these options. -

    The Chairs may remove Work Items. The Chairs -must notify the group of the removal of Work Items, -and this notice must include rationale. Some possible reasons for -removing a Work Item are: +

    The Chairs may remove Specifications. The Chairs +must notify the group of the removal of +Specifications, and this notice must include rationale. Some possible +reasons for removing a Specification are:

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

    Coordination

    @@ -345,10 +349,10 @@

    Coordination

    Ecma, IETF, and elsewhere, -and will migrate Work Items to them when they’re -ready for the standards track. Groups most likely to be close partners -are listed below, but this group is expected to coordinate with other -groups as relevant. +and will migrate Specifications to them when +they’re ready for the standards track. Groups most likely to be close +partners are listed below, but this group is expected to coordinate with +other groups as relevant.

    W3C Groups

    @@ -357,21 +361,21 @@

    W3C Groups

    (PING)
    This group will coordinate with PING and will take into consideration outputs of PING when -evaluating Proposals and Work -Items. +evaluating Proposals +and Specifications.
    Web Application Security Working Group (WebAppSec) -
    WebAppSec is expected to be a destination for transitioning CG Work -Items to the standards track. +
    WebAppSec is expected to be a destination for transitioning +Specifications to the standards track.
    Web Platform Incubator Community Group (WICG) -
    WICG is expected to be a major source of Work Items for this +
    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 Work Items. +this group to take up as Specifications.

    External Organizations

    @@ -400,8 +404,8 @@

    Process

    Professional Conduct.

    Contributions to Proposals -and Work Items can only be made by Community -Group Participants who have agreed to the +and Specifications can only be made by +Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA). @@ -417,9 +421,9 @@

    Process

    Editors

    Editors are responsible for the technical content of -their Work Item and have sole authority to -modify the Work Item (though their decisions may be overridden by the -Chairs; see below). +their Specification and have sole authority +to modify the Specification (though their decisions may be overridden by +the Chairs; see below).

    Editors are responsible for

      @@ -430,13 +434,13 @@

      Editors

    • helping to manage the corresponding tests.
    • ensuring (together with implementers) implementations follow the requirements and vice versa. (The “don’t write fiction” rule.) -
    • ensuring contributions to their Work Item are only made by +
    • ensuring contributions to their Specification are only made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA), and
    • ensuring that there are no unresolved substantive objections from Community Group Participants before merging contributions or otherwise -modifying their Work Item. +modifying their Specification.

    Changes of an editorial nature can be made, accepted, or rejected by @@ -446,7 +450,7 @@

    Editors

    consider and respond to comments, suggestions, and objections from Participants and the public. -

    Editors may commit changes to their Work Items without further +

    Editors may commit changes to their Specifications without further review, provided they adhere to the requirements in this document.

    Work Mode

    @@ -464,13 +468,13 @@

    Work Mode

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

    Any change to a Work Item that represents a -feature addition must have the support of at least +

    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 Work Item, the feature -being removed must either be not widely implemented, or must be in the -process of being removed from implementations. +

    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

    @@ -488,8 +492,8 @@

    Meetings

    Decision Policy

    Editors must respond to substantive issues -raised on their Work Item by Community Group -Participants. Editors have discretion to resolve issues based on +raised on their Specification by Community +Group Participants. Editors have discretion to resolve issues based on available information.

    To afford asynchronous decisions and organizational deliberation, any @@ -540,16 +544,16 @@

    Decision Policy

    possible, be consistent with our goal to increase user privacy and align with implementer majority. -

    Work Items should not make references to or rely on specific browser -engine implementation details. +

    Specifications should not make references to or rely on specific +browser engine implementation details.

    Appeals

    Community Group Participants may raise substantive issues for resolution by the Chairs. -

    To raise an issue on a Work Item for review -by the Editors and other Community Group +

    To raise an issue on a Specification for +review by the Editors and other Community Group Participants, a Community Group Participant must:

      @@ -557,7 +561,7 @@

      Appeals

      issue, inconsistency with the W3C TAG Ethical Web Principles, etc.) and recommend a solution; -
    1. Post the issue for review in the Work Item’s repository; and +
    2. Post the issue for review in the Specification’s repository; and
    3. Endeavor to resolve the issue with the Editors or in concert with other Community Group Participants.
    @@ -587,19 +591,19 @@

    Patent Policy

    with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual’s first request to make a contribution to a -group Work Item. +group Specification.

    Licensing

    -

    Work Items of this Community Group will use the +

    Specifications of this Community Group will use the W3C Software and Document License, unless -the Editors expect the Work -Item to transition to a standards body which uses a different -license. In such cases, the Editors may use the license of the target -standards body. +the Editors expect +the Specification to transition to a +standards body which uses a different license. In such cases, the +Editors may use the license of the target standards body. -

    A Work Item +

    A Specification expected to end up as a pull request on the HTML Living Standard could be licensed under the @@ -610,8 +614,9 @@

    Amendments to this Charter

    This Charter may be amended at any time by unanimous consent of the Chairs. The Chairs will periodically update this -Charter to reflect the addition and removal of Work -Items, Editors, and Chairs. +Charter to reflect the addition and removal +of Specifications, Editors, +and Chairs.

    Per the Community and From 53308b4aa26f3c619e4a3da50b534a90749bf0d2 Mon Sep 17 00:00:00 2001 From: Theresa O'Connor Date: Thu, 9 Apr 2020 12:12:10 -0700 Subject: [PATCH 2/4] Don't show an extraneous hash. --- charter.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/charter.html b/charter.html index b36deb8..1cc0c51 100644 --- a/charter.html +++ b/charter.html @@ -265,7 +265,7 @@

    Proposals

    transferring the repository to a different organization or user, or by archiving it. -
    +

    Specifications

    The Community Group may produce Specifications—as defined From 2d9da779d6a07075d2f5987ab74f479c3377a3b1 Mon Sep 17 00:00:00 2001 From: Theresa O'Connor Date: Thu, 9 Apr 2020 14:38:04 -0700 Subject: [PATCH 3/4] s/work item/specification/ on the home page too. --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 1dbf334..82a74b6 100644 --- a/index.html +++ b/index.html @@ -53,9 +53,9 @@

    Our Work

    but also in periodic teleconferences and face-to-face meetings.
      -
    • We try to keep the list of our -current work items in our charter -up-to-date. You can follow links from there to each work item’s GitHub +
    • We try to keep the list of our +current specifications in our charter +up-to-date. You can follow links from there to each spec’s GitHub repository, where you can see the latest text, and file or comment on issues.
    • We discuss new proposals in our From e8d2ac933f24f21dc6b4d3ec4d9231181995a370 Mon Sep 17 00:00:00 2001 From: Theresa O'Connor Date: Tue, 14 Apr 2020 13:34:24 -0700 Subject: [PATCH 4/4] Try to address #9. (#25) * Attempt to address #9. * Other expressions of implementer interest are also good information to have. * s/judgment/consensus/ * Prefer archiving over transferring repositories. * fix typo. * Whitespace. * Fix typos. * Champions may ask for a dedicated reposoitory, and the Chairs will generally honor such requests. * Ensure the set of Champions for each Proposal is documented. * Restore and reword one of the possible reasons for removing a specification. --- charter.html | 167 ++++++++++++++++++--------------------------------- 1 file changed, 57 insertions(+), 110 deletions(-) diff --git a/charter.html b/charter.html index 1cc0c51..bd43479 100644 --- a/charter.html +++ b/charter.html @@ -223,6 +223,12 @@

      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. Proposals should explicitly list their Champions, and +Champions should keep this list updated as the set of Champions for the +Proposal changes. +

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

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

        -
      • because the Proposal has become sufficiently complex that writing an -explainer is warranted -
      • because the Proposal is sufficiently complex that having a dedicated -issue tracker for it is warranted -
      • because multiple implementers have -expressed interest in the Proposal -
      +

      Champions may ask the Chairs 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 out of scope).

      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 -transferring the repository to a different organization or user, or by -archiving it. +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 archiving the repository or by transferring it to a different +organization or user.

      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 +302,25 @@

      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 if it is the consensus 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 +adequate +implementation experience of the Proposal's features, and may take +such commitments or other such expressions of implementer interest 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 appointed Editors.

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

      Specifications

      • because the Specification has been migrated elsewhere -
      • because the Specification no longer has the support of -multiple implementers and is unlikely to regain -it +
      • because it is no longer the consensus of its +Champions and the Chairs that the Specification is likely to enable and +lead to independent, interoperable implementations.
      • because the Specification no longer has an Editor and a replacement cannot be found

      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.

      Coordination

      @@ -371,11 +383,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 +391,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 Specifications will likely result in pull requests on various WHATWG specs.
      @@ -468,14 +476,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 +509,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 +537,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 +632,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