From e61da47a0920575f92a20aa16a4f5a814fa9e5a6 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Fri, 4 Oct 2024 17:23:55 +0200 Subject: [PATCH 01/13] merge core language from fep-37f2 into cg charter template --- CGCharter-1727386911.html | 46 ++++++++++++++++++++++++++------------- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/CGCharter-1727386911.html b/CGCharter-1727386911.html index 3537c06..73c4695 100644 --- a/CGCharter-1727386911.html +++ b/CGCharter-1727386911.html @@ -214,20 +214,18 @@

Decision Process

-

- If the decision policy is documented somewhere, update this section accordingly to link to it. -

This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have earned Committer status for a history of useful contributions assess consensus, or the Chair assesses consensus, or where consensus isn't - clear there is a Call for Consensus [CfC] to allow multi-day online - feedback for a proposed course of action). It is expected that + clear there is a Call for Consensus [CfC] (see below) to allow multi-day + online feedback for a proposed course of action). It is expected that participants can earn Committer status through a history of valuable - contributions as is common in open source projects. After discussion and - due consideration of different opinions, a decision should be publicly - recorded (where GitHub is used as the resolution of an Issue). + discursive contributions as is common in open source projects. + After discussion and due consideration of different opinions, a decision + should be publicly recorded (where GitHub is used as the resolution + of an Issue).

If substantial disagreement remains (e.g. the group is divided) and the @@ -241,15 +239,33 @@

ahead with.

- Any decisions reached at any meeting are tentative and should be recorded - in a GitHub Issue for groups that use GitHub and otherwise on the group's - public mail list. Any group participant may object to a decision reached - at an online or in-person meeting within 7 days of publication of the - decision provided that they include clear technical reasons for their - objection. The Chairs will facilitate discussion to try to resolve the - objection according to this decision process. + To afford asynchronous decisions and organizational deliberation, any + resolution (including publication decisions) taken in a face-to-face + meeting or teleconference will be considered provisional. + A call for consensus (CfC) will be issued for all resolutions via + email to public-swicg@w3.org, preferably with the abbreviation CfC early + in the subject line to catch more attention. +

+

+ Any group participant may object to a + decision reached at an online or in-person meeting within 14 days of + publication of the decision, provided that they include + clear reasons for their objection grounded in the scope and documented + goals of the CG and its work items. +

+

+ Calls for Consensus +

+

+ The presence of formal resolutions will be indicated by a "CFC" prefix in the subject line of an email on the list. + Additional outreach to community venues for more affirmative consent is strongly encouraged. + There will be a response period of 14 days. + If no sustained objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Community Group, i.e. a group decision. + All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

+ The Chairs will facilitate discussion to try to resolve the + objection according to this decision process. It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer. From a3f0af7746f60afc24242858cfa8c5ede1146433 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Tue, 15 Mar 2016 11:32:42 -0500 Subject: [PATCH 02/13] Draft from Wayne Carr --- CGCharter.html | 335 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 335 insertions(+) create mode 100644 CGCharter.html diff --git a/CGCharter.html b/CGCharter.html new file mode 100644 index 0000000..df5ff1a --- /dev/null +++ b/CGCharter.html @@ -0,0 +1,335 @@ + + + + + {TBD: name} Community Group Charter + + + + + + + +

{TBD: This is a draft template that Community or Business Groups MAY choose + to use for their Group Charter. You may edit your charter to remove or change + the text provided here. Community Groups SHOULD have charters as a way to build + shared understanding within a group about activities, and to attract new + participants who appreciate a clear description of the group's scope and + deliverables.}

+ +

{TBD: The charter sections below include notes (marked with “{TBD”) + on what to include and recommended text. Please remember to remove + the notes in your specific charter.}

+ +

+ [DRAFT] {TBD: name} Community Group Charter +

+ +

{TBD: remove next sentence before submitting for approval} + This Charter is work in progress. To submit feedback, please use + {TBD:GitHub repository URL} Issues where Charter is being developed.

+ + + +

+ Goals +

+ +

{TBD: describe the mission and goals of the Community Group. + This should be a brief description describing the reason the group has been formed.} +

+ +

+ Scope of Work +

+ +

+ {TBD: Describe topics that are in scope. For specifications that the CLA + patent section applies to, it is helpful to describe the scope in a way + that it is clear what types of technologies will be defined in specifications, + as opposed to adoption by reference or underlying technology not defined in the + proposed spec. Key use cases are often helpful in describing scope. If no + specifications will be defined in the group that the CLA patent section applies + to, the charter should clearly state that. A clear scope is particularly important + where patent licensing obligations may apply.} +

+ +

+ Out of Scope +

+ +

{TBD: Identify topics known in advance to be out of scope}

+ +

+ Deliverables +

+ +

+ Specifications +

+ +

+ {TBD: Provide a brief description of each specification the group plans + to produce. Where an estimate is possible, it can be useful to provide + an estimated schedule for key deliverables. As described below, + the group may later modify the charter deliverables. if no specifications, + include: "No Specifications will be produced under the current charter."} +

+ +

+ Non-Normative Reports +

+ +

The group may produce other Community Group Reports within + the scope of this charter but that are not Specifications, for instance use cases, + requirements, or white papers.

+ +

+ Test Suites and Other Software +

+ +

{TBD: State whether test suites or any other software + will be created for any Specifications and list the relevant licenses. + For information about contributions to W3C test suites, please see + Test the Web Forward, + and take note of the W3C's + test suite contribution policy and + licenses + for W3C test suites>. If there are no plans to create a test suite + or other software, please state that.}

+ +

+ Dependencies or Liaisons +

+ +

{TBD: List any significant dependencies on other groups + (inside or outside W3C) or materials. } +

+ +

+ Community and Business Group Process +

+ +

The group operates under the Community and Business + Group Process. Terms in this Charter that conflict with those of the + Community and Business Group Process are void. +

+ +

As with other Community Groups, W3C seeks organizational licensing + commitments under the W3C Community + Contributor License Agreement (CLA). When people + request to participate without representing their organization's legal + interests, W3C will in general approve those requests for this group 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 Deliverable. The + section on Contribution Mechanics describes how + W3C expects to monitor these contribution requests. +

+ +

+ Work Limited to Charter Scope +

+ +

The group will not publish Specifications on topics other than those + listed under Specifications above. + See below for how to modify the charter. +

+ +

+ Contribution Mechanics +

+ +

+ Substantive Contributions to Specifications can only be made by Community + Group Participants who have agreed to the + W3C Community + Contributor License Agreement (CLA). +

+ +

+ Specifications created in the Community Group must use the + + W3C Software and Document License. All other documents produced + by the group should use that License where possible. +

+ +

+ {TBD: if CG doesn't use GitHub replace the remaining paragraphs in this + section with: "All Contributions are made on the groups public mail list + or public contrib list"} +

+ +

+ Community Group participants agree to make all contributions + in the GitHub repo the group is using for the particular document. + This may be in the form of a pull request (preferred), by raising an issue, + or by adding a comment to an existing issue. +

+ +

+ All Github repositories attached to the Community Group must contain a + copy of the + CONTRIBUTING + and LICENSE files. +

+ +

+ Note: this Community Group will not use a contrib mailing list for contributions + since all contributions will be tracked via Github mechanisms + (e.g. pull requests). For the same reason, the Community Group + mailing list must not be used for making or discussing substantive contributions + to Specifications. +

+ +

+ Transparency +

+ +

+ The group will conduct all of its technical work in public. If the group + uses GitHub, all technical work will occur in its GitHub repositories + (and not in mailing list discussions). This is to ensure contributions + can be tracked through a software tool. +

+ +

+ Meetings may be restricted to Community Group participants, but a + public summary or minutes must be posted to the group's public mailing + list, or to a GitHub issue if the group uses GitHub. +

+ +

+ Decision Process +

+ +

This group will seek to make decisions where there is consensus. + Groups are free to decide how to make decisions (e.g. Participants + who have earned Committer status for a history of useful contributions + assess consensus, or the Chair assesses consensus, or where consensus + isn't clear there is a Call for Consensus [CfC] to allow multi-day online + feedback for a proposed course of action). It is expected that participants + can earn Committer status through a history of valuable contributions as is + common in open source projects. After discussion and due consideration of + different opinions, a decision should be publicly recorded (where GitHub is + used as the resolution of an Issue). +

+ +

+ If substantial disagreement remains (e.g. the group is divided) + and the group needs to decide an Issue in order to continue to make progress, + the Committers will choose an alternative that had substantial support + (with a vote of Committers if necessary). Individuals who disagree + with the choice are strongly encouraged to take ownership + of their objection by taking ownership of an alternative fork. + This is explicitly allowed (and preferred to blocking progress) + with a goal of letting implementation experience inform which + spec is ultimately chosen by the group to move ahead with. +

+ +

+ Any decisions reached at any meeting are tentative and should be + recorded in a GitHub Issue for groups that use GitHub and otherwise + on the group's public mail list. Any group participant may object to + a decision reached at an online or in-person meeting within 7 days of + publication of the decision provided that they include clear technical + reasons for their objection. The Chairs will facilitate discussion to try + to resolve the objection according to the decision + process. +

+ +

+ It is the Chairs' responsibility to ensure that the decision process is fair, + respects the consensus of the CG, and does not unreasonably favour or + discriminate against any group participant or their employer. +

+ + +

+ Chair Selection +

+ +

+ Participants in this group choose their Chair(s) and can replace their + Chair(s) at any time using whatever means they prefer. However, if 5 + participants, no two from the same organisation, call for an election, + the group must use the following process to replace any current Chair(s) + with a new Chair, consulting the Community Development Lead on election + operations (e.g., voting infrastructure and using + RFC 2777). +

+ +
    +
  1. Participants announce their candidacies. Participants have 14 days to + announce their candidacies, but this period ends as soon as all + participants have announced their intentions. If there is only one + candidate, that person becomes the Chair. If there are two or more + candidates, there is a vote. Otherwise, nothing changes. +
    2. +
  2. Participants vote. Participants have 21 days to vote for a single + candidate, but this period ends as soon as all participants have voted. + The individual who receives the most votes, no two from the same + organisation, is elected chair. In case of a tie, RFC2777 is used to + break the tie. An elected Chair may appoint co-Chairs. +
    3. +
+ +

+ Participants dissatisfied with the outcome of an election may ask the + Community Development Lead to intervene. The Community Development Lead, + after evaluating the election, may take any action including no action. +

+ +

+ Amendments to this Charter +

+ +

+ The group can decide to work on a proposed amended charter, editing the + text using the Decision Process described above. + The decision on whether to adopt the amended charter is made by + conducting a 30-day vote on the proposed new charter. The new charter, if + approved, takes effect on either the proposed date in the charter itself, + or 7 days after the result of the election is announced, whichever is + later. A new charter must receive 2/3 of the votes cast in the approval + vote to pass. The group may make simple corrections to the charter such + as deliverable dates by the simpler group decision process rather than + this charter amendment process. The group will use the amendment process + for any substantive changes to the goals, scope, deliverables, decision + process or rules for amending the charter. +

+ + + From e3bc754169919b5672b9fca24ed8ef5d7c654574 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Wed, 28 Mar 2018 17:07:28 -0500 Subject: [PATCH 03/13] add reference to CEPC --- CGCharter.html | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CGCharter.html b/CGCharter.html index df5ff1a..f618d9f 100644 --- a/CGCharter.html +++ b/CGCharter.html @@ -157,6 +157,12 @@

W3C expects to monitor these contribution requests.

+

+ The W3C Code of + Ethics and Professional Conduct applies to participation in + this group. +

+

Work Limited to Charter Scope

From cf189919ad6c11752574a83eabc19e35d26d9874 Mon Sep 17 00:00:00 2001 From: Wayne Carr Date: Sat, 21 May 2016 15:25:41 -0700 Subject: [PATCH 04/13] remove note on cg contrib list @ianbjacobs Removed the paragraph on not sing the cg contrib list and not doing contributions on mail list (when using GitHub). that latter sentence was being dropped by users of the template. it's not necessary so making the template consistent with use. --- CGCharter.html | 8 -------- 1 file changed, 8 deletions(-) diff --git a/CGCharter.html b/CGCharter.html index f618d9f..890b827 100644 --- a/CGCharter.html +++ b/CGCharter.html @@ -212,14 +212,6 @@

"https://github.com/w3c/licenses/blob/master/CG-LICENSE.md">LICENSE files.

-

- Note: this Community Group will not use a contrib mailing list for contributions - since all contributions will be tracked via Github mechanisms - (e.g. pull requests). For the same reason, the Community Group - mailing list must not be used for making or discussing substantive contributions - to Specifications. -

-

Transparency

From ab4223bb436895741322f6b971e1ea7652c0107f Mon Sep 17 00:00:00 2001 From: Wayne C Date: Wed, 15 Jun 2016 15:02:04 -0700 Subject: [PATCH 05/13] [CG Charter] test suite paragraph was for WGs @ianbjacobs @wseltzer The test suite section for the CG Charter template points to a page that is only about WGs. It includes the 2 ways to include test suites in a WG (either as part of the spec or not) and also directly refers to the W3C patent policy. It's not at all relevant to CGs. It would be better just to point to the GitHub LICENSE.md file if in GitHub. I followed links in that material until I found the W3C license used and proposed putting that in the LICENSE.md file for the WebVR CG. That's a separate change I'll suggest in the W3C LICENSE.md file for CGs. --- CGCharter.html | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CGCharter.html b/CGCharter.html index 890b827..fee3c00 100644 --- a/CGCharter.html +++ b/CGCharter.html @@ -116,15 +116,15 @@

Test Suites and Other Software

-

{TBD: State whether test suites or any other software - will be created for any Specifications and list the relevant licenses. - For information about contributions to W3C test suites, please see - Test the Web Forward, - and take note of the W3C's - test suite contribution policy and - licenses - for W3C test suites>. If there are no plans to create a test suite - or other software, please state that.}

+

{TBD: If there are no plans to create a test suite + or other software, please state that and remove the following paragraph. If + Github is not being used, then indicate where the license information is.} +

+

+ The group MAY produce test suites to support the Specifications. Please see the + GitHub LICENSE file for + test suite contribution licensing information. +

Dependencies or Liaisons From 41ce43e3703aaabba0fe13038600e06de793ca93 Mon Sep 17 00:00:00 2001 From: Wayne C Date: Mon, 20 Jun 2016 15:35:49 -0700 Subject: [PATCH 06/13] [CGCharter] had link to WebVR CG LICENSE.md changed it to link to the license section of the charter (since we don't know where they will put their charter in their GitHub repo) --- CGCharter.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/CGCharter.html b/CGCharter.html index fee3c00..f114e97 100644 --- a/CGCharter.html +++ b/CGCharter.html @@ -118,11 +118,12 @@

{TBD: If there are no plans to create a test suite or other software, please state that and remove the following paragraph. If - Github is not being used, then indicate where the license information is.} + Github is not being used, then indicate where the license information is. + If GitHub is being used link to your LICENSE.md file in the next paragraph.}

The group MAY produce test suites to support the Specifications. Please see the - GitHub LICENSE file for + GitHub LICENSE file for test suite contribution licensing information.

@@ -204,7 +205,7 @@

or by adding a comment to an existing issue.

-

+

All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING From 6de42088f8fc86165ef8e2547d4e333b07ee3679 Mon Sep 17 00:00:00 2001 From: Wayne C Date: Wed, 22 Jun 2016 13:54:48 -0700 Subject: [PATCH 07/13] [CGCharter] cleaned with HTML Tidy @ianbjacobs Got this from Google in second screen CG. Install tidy from http://binaries.html-tidy.org Download tidyconfig.txt: https://raw.githubusercontent.com/w3c/presentation-api/gh-pages/build/tidyconfig.txt Run tidy on command line: tidy -config tidyconfig.txt -o output.html input.html --- CGCharter.html | 337 +++++++++++++++++++++++-------------------------- 1 file changed, 157 insertions(+), 180 deletions(-) diff --git a/CGCharter.html b/CGCharter.html index f114e97..4395717 100644 --- a/CGCharter.html +++ b/CGCharter.html @@ -28,134 +28,133 @@ -

{TBD: This is a draft template that Community or Business Groups MAY choose - to use for their Group Charter. You may edit your charter to remove or change - the text provided here. Community Groups SHOULD have charters as a way to build - shared understanding within a group about activities, and to attract new - participants who appreciate a clear description of the group's scope and - deliverables.}

- -

{TBD: The charter sections below include notes (marked with “{TBD”) - on what to include and recommended text. Please remember to remove - the notes in your specific charter.}

- +

+ {TBD: This is a draft template that Community or Business Groups MAY + choose to use for their Group Charter. You may edit your charter to + remove or change the text provided here. Community Groups SHOULD have + charters as a way to build shared understanding within a group about + activities, and to attract new participants who appreciate a clear + description of the group's scope and deliverables.} +

+

+ {TBD: The charter sections below include notes (marked with �{TBD�) on + what to include and recommended text. Please remember to remove the notes + in your specific charter.} +

[DRAFT] {TBD: name} Community Group Charter

- -

{TBD: remove next sentence before submitting for approval} - This Charter is work in progress. To submit feedback, please use - {TBD:GitHub repository URL} Issues where Charter is being developed.

- +

+ {TBD: remove next sentence before submitting for + approval} This Charter is work in progress. To submit feedback, + please use {TBD:GitHub repository URL} Issues + where Charter is being developed. +

    -
  • This Charter: {TBD: URI}
    • -
  • Previous Charter: {TBD: URI}
    • -
  • Start Date: {TBD: date the charter takes effect, estimate if not - known. Update this if the charter is revised and include a link to the - previous version of the charter.}
    • -
  • Last Modifed: {TBD: If the system does not - automatically provide information about - the date of the last modification, it can be useful to include that in - the charter.}
    • +
  • This Charter: {TBD: URI} +
    • +
  • Previous Charter: {TBD: URI} +
    • +
  • Start Date: {TBD: date the charter takes effect, + estimate if not known. Update this if the charter is revised and include + a link to the previous version of the charter.} +
    • +
  • Last Modifed: {TBD: If the system does not + automatically provide information about the date of the last + modification, it can be useful to include that in the charter.} +
-

Goals

- -

{TBD: describe the mission and goals of the Community Group. - This should be a brief description describing the reason the group has been formed.} -

- +

+ {TBD: describe the mission and goals of the + Community Group. This should be a brief description describing the reason + the group has been formed.} +

Scope of Work

-

- {TBD: Describe topics that are in scope. For specifications that the CLA - patent section applies to, it is helpful to describe the scope in a way - that it is clear what types of technologies will be defined in specifications, - as opposed to adoption by reference or underlying technology not defined in the - proposed spec. Key use cases are often helpful in describing scope. If no - specifications will be defined in the group that the CLA patent section applies - to, the charter should clearly state that. A clear scope is particularly important - where patent licensing obligations may apply.} + {TBD: Describe topics that are in scope. For specifications that the CLA + patent section applies to, it is helpful to describe the scope in a way + that it is clear what types of technologies will be defined in + specifications, as opposed to adoption by reference or underlying + technology not defined in the proposed spec. Key use cases are often + helpful in describing scope. If no specifications will be defined in the + group that the CLA patent section applies to, the charter should clearly + state that. A clear scope is particularly important where patent + licensing obligations may apply.} +

+

+ Out of Scope +

+

+ {TBD: Identify topics known in advance to be out of scope}

- -

- Out of Scope -

- -

{TBD: Identify topics known in advance to be out of scope}

-

Deliverables

- -

- Specifications -

- -

- {TBD: Provide a brief description of each specification the group plans - to produce. Where an estimate is possible, it can be useful to provide - an estimated schedule for key deliverables. As described below, - the group may later modify the charter deliverables. if no specifications, - include: "No Specifications will be produced under the current charter."} -

- -

- Non-Normative Reports -

- -

The group may produce other Community Group Reports within - the scope of this charter but that are not Specifications, for instance use cases, - requirements, or white papers.

- -

- Test Suites and Other Software -

- -

{TBD: If there are no plans to create a test suite - or other software, please state that and remove the following paragraph. If - Github is not being used, then indicate where the license information is. - If GitHub is being used link to your LICENSE.md file in the next paragraph.} -

-

- The group MAY produce test suites to support the Specifications. Please see the - GitHub LICENSE file for - test suite contribution licensing information. -

- +

+ Specifications +

+

+ {TBD: Provide a brief description of each specification the group plans + to produce. Where an estimate is possible, it can be useful to provide an + estimated schedule for key deliverables. As described below, the group + may later modify the charter deliverables. if no specifications, include: + "No Specifications will be produced under the current charter."} +

+

+ Non-Normative Reports +

+

+ The group may produce other Community Group Reports within the scope of + this charter but that are not Specifications, for instance use cases, + requirements, or white papers. +

+

+ Test Suites and Other Software +

+

+ {TBD: If there are no plans to create a test suite or other software, + please state that and remove the following paragraph. If Github is not + being used, then indicate where the license information is. If GitHub is + being used link to your LICENSE.md file in the next paragraph.} +

+

+ The group MAY produce test suites to support the Specifications. Please + see the GitHub LICENSE file for test suite contribution licensing + information. +

Dependencies or Liaisons

- -

{TBD: List any significant dependencies on other groups - (inside or outside W3C) or materials. } -

- +

+ {TBD: List any significant dependencies on other groups (inside or + outside W3C) or materials. } +

Community and Business Group Process

- -

The group operates under the + The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.

- -

As with other Community Groups, W3C seeks organizational licensing +

+ As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community - Contributor License Agreement (CLA). When people - request to participate without representing their organization's legal - interests, W3C will in general approve those requests for this group with - the following understanding: W3C will seek and expect an organizational + Contributor License Agreement (CLA). When people request to + participate without representing their organization's legal interests, + W3C will in general approve those requests for this group 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 Deliverable. The - section on Contribution Mechanics describes how - W3C expects to monitor these contribution requests. + make a contribution to a group Deliverable. + The section on Contribution Mechanics describes + how W3C expects to monitor these contribution requests.

@@ -167,129 +166,111 @@

Work Limited to Charter Scope

- -

The group will not publish Specifications on topics other than those - listed under Specifications above. - See below for how to modify the charter. +

+ The group will not publish Specifications on topics other than those + listed under Specifications above. See + below for how to modify the charter.

-

Contribution Mechanics

-

- Substantive Contributions to Specifications can only be made by Community - Group Participants who have agreed to the - W3C Community - Contributor License Agreement (CLA). + Substantive Contributions to Specifications can only be made by Community + Group Participants who have agreed to the W3C Community + Contributor License Agreement (CLA).

-

- Specifications created in the Community Group must use the - - W3C Software and Document License. All other documents produced - by the group should use that License where possible. + W3C Software and Document License. All other documents produced by + the group should use that License where possible.

-

- {TBD: if CG doesn't use GitHub replace the remaining paragraphs in this + {TBD: if CG doesn't use GitHub replace the remaining paragraphs in this section with: "All Contributions are made on the groups public mail list - or public contrib list"} + or public contrib list"}

-

- Community Group participants agree to make all contributions - in the GitHub repo the group is using for the particular document. - This may be in the form of a pull request (preferred), by raising an issue, - or by adding a comment to an existing issue. + Community Group participants agree to make all contributions in the + GitHub repo the group is using for the particular document. This may be + in the form of a pull request (preferred), by raising an issue, or by + adding a comment to an existing issue.

-

All Github repositories attached to the Community Group must contain a - copy of the - CONTRIBUTING + copy of the CONTRIBUTING and LICENSE files. + "https://github.com/w3c/licenses/blob/master/CG-LICENSE.md">LICENSE + files.

-

Transparency

-

- The group will conduct all of its technical work in public. If the group - uses GitHub, all technical work will occur in its GitHub repositories - (and not in mailing list discussions). This is to ensure contributions + The group will conduct all of its technical work in public. If the group + uses GitHub, all technical work will occur in its GitHub repositories + (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool.

-

- Meetings may be restricted to Community Group participants, but a - public summary or minutes must be posted to the group's public mailing - list, or to a GitHub issue if the group uses GitHub. + Meetings may be restricted to Community Group participants, but a public + summary or minutes must be posted to the group's public mailing list, or + to a GitHub issue if the group uses GitHub.

-

Decision Process

- -

This group will seek to make decisions where there is consensus. - Groups are free to decide how to make decisions (e.g. Participants - who have earned Committer status for a history of useful contributions - assess consensus, or the Chair assesses consensus, or where consensus - isn't clear there is a Call for Consensus [CfC] to allow multi-day online - feedback for a proposed course of action). It is expected that participants - can earn Committer status through a history of valuable contributions as is - common in open source projects. After discussion and due consideration of - different opinions, a decision should be publicly recorded (where GitHub is - used as the resolution of an Issue). +

+ This group will seek to make decisions where there is consensus. Groups + are free to decide how to make decisions (e.g. Participants who have + earned Committer status for a history of useful contributions assess + consensus, or the Chair assesses consensus, or where consensus isn't + clear there is a Call for Consensus [CfC] to allow multi-day online + feedback for a proposed course of action). It is expected that + participants can earn Committer status through a history of valuable + contributions as is common in open source projects. After discussion and + due consideration of different opinions, a decision should be publicly + recorded (where GitHub is used as the resolution of an Issue).

-

- If substantial disagreement remains (e.g. the group is divided) - and the group needs to decide an Issue in order to continue to make progress, - the Committers will choose an alternative that had substantial support - (with a vote of Committers if necessary). Individuals who disagree - with the choice are strongly encouraged to take ownership - of their objection by taking ownership of an alternative fork. - This is explicitly allowed (and preferred to blocking progress) - with a goal of letting implementation experience inform which - spec is ultimately chosen by the group to move ahead with. + If substantial disagreement remains (e.g. the group is divided) and the + group needs to decide an Issue in order to continue to make progress, the + Committers will choose an alternative that had substantial support (with + a vote of Committers if necessary). Individuals who disagree with the + choice are strongly encouraged to take ownership of their objection by + taking ownership of an alternative fork. This is explicitly allowed (and + preferred to blocking progress) with a goal of letting implementation + experience inform which spec is ultimately chosen by the group to move + ahead with.

-

- Any decisions reached at any meeting are tentative and should be - recorded in a GitHub Issue for groups that use GitHub and otherwise - on the group's public mail list. Any group participant may object to - a decision reached at an online or in-person meeting within 7 days of - publication of the decision provided that they include clear technical - reasons for their objection. The Chairs will facilitate discussion to try - to resolve the objection according to the decision - process. + Any decisions reached at any meeting are tentative and should be recorded + in a GitHub Issue for groups that use GitHub and otherwise on the group's + public mail list. Any group participant may object to a decision reached + at an online or in-person meeting within 7 days of publication of the + decision provided that they include clear technical reasons for their + objection. The Chairs will facilitate discussion to try to resolve the + objection according to the decision process.

-

- It is the Chairs' responsibility to ensure that the decision process is fair, - respects the consensus of the CG, and does not unreasonably favour or - discriminate against any group participant or their employer. + It is the Chairs' responsibility to ensure that the decision process is + fair, respects the consensus of the CG, and does not unreasonably favour + or discriminate against any group participant or their employer.

- -

Chair Selection

-

Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants, no two from the same organisation, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election - operations (e.g., voting infrastructure and using - RFC 2777). + operations (e.g., voting infrastructure and using RFC 2777).

-
  1. Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all @@ -304,17 +285,14 @@

    break the tie. An elected Chair may appoint co-Chairs.

-

Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.

-

Amendments to this Charter

-

The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. @@ -329,6 +307,5 @@

for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.

- From 334c3cbd693fe84635460d8903dae32ca9470324 Mon Sep 17 00:00:00 2001 From: Malvoz <26493779+Malvoz@users.noreply.github.com> Date: Sun, 20 Jun 2021 17:09:26 +0200 Subject: [PATCH 08/13] Update link to Community and Business Group Process --- CGCharter.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CGCharter.html b/CGCharter.html index 4395717..8245aae 100644 --- a/CGCharter.html +++ b/CGCharter.html @@ -139,7 +139,7 @@

The group operates under the Community and Business + "https://www.w3.org/community/about/process/">Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.

From 6ef7606201b2f9c2fba8a67980fdccb62967620e Mon Sep 17 00:00:00 2001 From: Malvoz <26493779+Malvoz@users.noreply.github.com> Date: Sun, 20 Jun 2021 18:43:05 +0200 Subject: [PATCH 09/13] Update links to W3C CLA --- CGCharter.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CGCharter.html b/CGCharter.html index 8245aae..4bfb4ae 100644 --- a/CGCharter.html +++ b/CGCharter.html @@ -146,7 +146,7 @@

As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community + 'https://www.w3.org/community/about/process/cla/'>W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the @@ -177,7 +177,7 @@

Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community + "https://www.w3.org/community/about/process/cla/">W3C Community Contributor License Agreement (CLA).

From 96f8457a4a881f3d1f9850bd1fd8c32aef8d5135 Mon Sep 17 00:00:00 2001 From: plehegar Date: Thu, 29 Jun 2023 10:49:56 -0400 Subject: [PATCH 10/13] Fixes https://github.com/w3c/charter-drafts/issues/396 --- CGCharter.html | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/CGCharter.html b/CGCharter.html index 4bfb4ae..54bb464 100644 --- a/CGCharter.html +++ b/CGCharter.html @@ -222,6 +222,9 @@

Decision Process

+

+ If the decision policy is documented somewhere, update this section accordingly to link to it. +

This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have @@ -252,7 +255,7 @@

at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the - objection according to the decision process. + objection according to this decision process.

It is the Chairs' responsibility to ensure that the decision process is From d6d500ed57325525af19b1dd8cc03d570179d010 Mon Sep 17 00:00:00 2001 From: bengo <171782+gobengo@users.noreply.github.com> Date: Thu, 26 Sep 2024 14:17:06 -0700 Subject: [PATCH 11/13] fill in charter template with basic SWICG info in concsultation with Dmitri Zagidulin at TPAC 2024 --- CGCharter.html | 66 ++++++++++++++++++++++---------------------------- 1 file changed, 29 insertions(+), 37 deletions(-) diff --git a/CGCharter.html b/CGCharter.html index 54bb464..3537c06 100644 --- a/CGCharter.html +++ b/CGCharter.html @@ -28,26 +28,12 @@ -

- {TBD: This is a draft template that Community or Business Groups MAY - choose to use for their Group Charter. You may edit your charter to - remove or change the text provided here. Community Groups SHOULD have - charters as a way to build shared understanding within a group about - activities, and to attract new participants who appreciate a clear - description of the group's scope and deliverables.} -

-

- {TBD: The charter sections below include notes (marked with �{TBD�) on - what to include and recommended text. Please remember to remove the notes - in your specific charter.} -

- [DRAFT] {TBD: name} Community Group Charter + [DRAFT] Social Web Incubator Community Group Charter

- {TBD: remove next sentence before submitting for - approval} This Charter is work in progress. To submit feedback, - please use {TBD:GitHub repository URL} Issues + This Charter is work in progress. To submit feedback, + please use https://github.com/swicg/potential-charters/issues Issues where Charter is being developed.

    @@ -59,19 +45,24 @@

    estimate if not known. Update this if the charter is revised and include a link to the previous version of the charter.} -
  • Last Modifed: {TBD: If the system does not - automatically provide information about the date of the last - modification, it can be useful to include that in the charter.} +
  • Last Modifed: 2024-09-26

+

+ The Social Web Incubator Community Group (also known as SocialCG, or SWICG) is the successor of the Social Web Working Group, which ran from 2014 to 2017. +

Goals

-

- {TBD: describe the mission and goals of the - Community Group. This should be a brief description describing the reason - the group has been formed.} -

+
    +
  • + Provide space to collaborate and coordinate for implementors who are building on any of the specifications published by the Social Web WG (2014-2017), and related technologies. +
    • +
  • + Incubate new proposals which build on or complement the Social Web WG recommendations. +
    • +
+

Scope of Work

@@ -86,12 +77,13 @@

state that. A clear scope is particularly important where patent licensing obligations may apply.}

-

- Out of Scope -

-

- {TBD: Identify topics known in advance to be out of scope} -

+

+ Out of Scope +

+

+ {TBD: Identify topics known in advance to be out of scope} +

+

Deliverables

@@ -209,15 +201,15 @@

Transparency

- The group will conduct all of its technical work in public. If the group - uses GitHub, all technical work will occur in its GitHub repositories - (and not in mailing list discussions). This is to ensure contributions - can be tracked through a software tool. + The group will conduct all of its technical work in public, e.g. + on the public-swicg@w3.org mailing list, + w3.org SocialCG wiki, + and git repositories cloned in the github.com/swicg/ Organization + .

Meetings may be restricted to Community Group participants, but a public - summary or minutes must be posted to the group's public mailing list, or - to a GitHub issue if the group uses GitHub. + summary or minutes must be posted to the public-swicg@w3.org mailing list.

Decision Process From 38836c6515245c5cb6d4f80ea0b8c33490c4147b Mon Sep 17 00:00:00 2001 From: bengo <171782+gobengo@users.noreply.github.com> Date: Thu, 26 Sep 2024 14:42:22 -0700 Subject: [PATCH 12/13] mv CGCharter.html to path w/ datetime making it clear this is just one proposal --- CGCharter.html => CGCharter-1727386911.html | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename CGCharter.html => CGCharter-1727386911.html (100%) diff --git a/CGCharter.html b/CGCharter-1727386911.html similarity index 100% rename from CGCharter.html rename to CGCharter-1727386911.html From 89ebe64f107f1940bc204c440710757feada153d Mon Sep 17 00:00:00 2001 From: Benjamin Goering <171782+gobengo@users.noreply.github.com> Date: Fri, 4 Oct 2024 10:28:40 -0700 Subject: [PATCH 13/13] Update CGCharter-1727386911.html MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Tantek Çelik --- CGCharter-1727386911.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CGCharter-1727386911.html b/CGCharter-1727386911.html index 3537c06..aaa2f15 100644 --- a/CGCharter-1727386911.html +++ b/CGCharter-1727386911.html @@ -151,7 +151,7 @@

The W3C Code of - Ethics and Professional Conduct applies to participation in + Conduct applies to participation in this group.