Update from upstream cg/cloud-edge-client/group.json

cg/cloud-edge-client/group.json

@@ -0,0 +1,54 @@
+{
+ "id": 162208,
+ "name": "Cloud-Edge-Client Coordination Community Group",
+ "is_closed": false,
+ "description": "<p>1. Goals\r\nThe mission of this group is to explore mechanisms and interfaces between Cloud, Edge, and Client for computing workload offloading and orchestration. The typical use cases include AI acceleration, cloud gaming, and streaming acceleration. The goal is to explore the feasibility of defining a set of new APIs and mechanisms that enable computing workload offloading and orchestration between Cloud, Edge, and Client. It should leverage existing mechanisms as much as possible and should coordinate with related W3C working groups and other SDOs and open-source communities if necessary.</p>\r\n\r\n<p>\r\n2. Scope of Work\r\nThis group aims to discuss proposals for Cloud-Edge-Client coordination, including:\r\n- Use cases and requirements for Cloud-Edge-Client coordination\r\n- Proposals for APIs and mechanisms (including protocols) that enable computing workload offloading and orchestration between Cloud, Edge, and Client\r\n- Secure networking and trust model requirements in the context of edge computing and offload to edge.</p>\r\n\r\n<p>3. Out of Scope\r\nThe following are out of scope:\r\nActual development of standards.</p>\r\n\r\n<p>4. Success Criteria\r\nThe Group will have succeeded if it can achieve the following:</p>\r\n\r\n<p>- Participation from various stakeholder communities, especially from startups and innovators in the space of distributed computing;\r\n- Consensus on a standard solution architecture for workload offloading.</p>\r\n\r\n<p>5. Deliverables\r\nWork items can be documents, such as specifications, technical reports, best practices and guidelines, use cases and requirements, white papers, etc. Work items can also be software, for instance test suites, samples, proof of concept work, etc. In general, all work items in scope of the group are welcome. If there are individuals who will commit to being editors for a document, the group should record agreement to accept it as a work item even if it conflicts with previous work adopted by the community. Newly-accepted work items that extend beyond the scope of this Community Group Charter will lead to a reconsideration of the Charter. The Community Group may vote to revise the Charter in order to include new work, or to determine that the proposed work is unrelated.</p>\r\n\r\n<p>6. Specifications\r\nThe group may produce Specifications that are not on the W3C Standards track. Development of W3C Standards should be done in appropriate Working Groups.</p>\r\n\r\n<p>7. Non-Normative Reports\r\nThe group may produce other Community Group Reports within the scope of this charter that are not Specifications, for instance Techinal Reports, Use Cases, Requirements, Primers, White Papers, etc.</p>\r\n\r\n<p>8. Test Suites and Other Software\r\nThe group MAY produce test suites to support the Specifications. Please see the GitHub LICENSE file for test suite contribution licensing information.</p>\r\n\r\n<p>9. Dependencies or Liaisons\r\nThe group may collaborate with other relevant groups within W3C.</p>\r\n\r\n<p>10. Community and Business Group Process\r\nThe 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.</p>\r\n\r\n<p>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.</p>\r\n\r\n<p>The W3C Code of Ethics and Professional Conduct applies to participation in this group.</p>\r\n\r\n<p>11. Work Limited to Charter Scope\r\nThe group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.</p>\r\n\r\n<p>12. Contribution Mechanics\r\nSubstantive 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.</p>\r\n\r\n<p>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.</p>\r\n\r\n<p>All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.</p>\r\n\r\n<p>13. Transparency\r\nThe 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.</p>\r\n\r\n<p>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.</p>\r\n\r\n<p>14. Decision Process\r\nIf 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 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 this decision process.</p>\r\n\r\n<p>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.</p>\r\n\r\n<p>15. Amendments to this Charter\r\nThe 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.</p>",
+ "shortname": "cloud-edge-client",
+ "spec-publisher": true,
+ "discr": "w3cgroup",
+ "_links": {
+  "self": {
+   "href": "https://api.w3.org/groups/cg/cloud-edge-client"
+  },
+  "homepage": {
+   "href": "https://www.w3.org/community/cloud-edge-client/"
+  },
+  "users": {
+   "href": "https://api.w3.org/groups/cg/cloud-edge-client/users"
+  },
+  "services": {
+   "href": "https://api.w3.org/groups/cg/cloud-edge-client/services"
+  },
+  "chairs": {
+   "href": "https://api.w3.org/groups/cg/cloud-edge-client/chairs"
+  },
+  "join": {
+   "href": "https://www.w3.org/community/cloud-edge-client/join"
+  },
+  "participations": {
+   "href": "https://api.w3.org/groups/cg/cloud-edge-client/participations"
+  }
+ },
+ "type": "community group",
+ "tr-publisher": false,
+ "group-type": "cg",
+ "identifier": "cg/cloud-edge-client",
+ "services": [
+  {
+   "href": "https://api.w3.org/services/43973",
+   "title": "RSS"
+  },
+  {
+   "href": "https://api.w3.org/services/43974",
+   "title": "Chat"
+  },
+  {
+   "href": "https://api.w3.org/services/43975",
+   "title": "Mailing List"
+  },
+  {
+   "href": "https://api.w3.org/services/43976",
+   "title": "Mailing List"
+  }
+ ]
+}