From 5f5a73ee6bd0fbbe37790a0c6805376577ada9d7 Mon Sep 17 00:00:00 2001 From: Tobie Langel Date: Sun, 14 Jul 2024 17:43:59 +0200 Subject: [PATCH 1/4] Merge Working Groups and Collaboration Spaces Closes #1110 --- CPC-CHARTER.md | 4 +- README.md | 22 +-- collaboration-spaces/COLLABORATION_NETWORK.md | 28 +++- .../COLLABORATION_SPACE_PROGRESSION.md | 12 +- governance/GITHUB_ORG_MANAGEMENT_POLICY.md | 2 +- governance/GOVERNANCE.md | 5 +- governance/WORKING_GROUPS.md | 150 ------------------ 7 files changed, 45 insertions(+), 178 deletions(-) delete mode 100644 governance/WORKING_GROUPS.md diff --git a/CPC-CHARTER.md b/CPC-CHARTER.md index 1964929a2..a1b6feac5 100644 --- a/CPC-CHARTER.md +++ b/CPC-CHARTER.md @@ -86,8 +86,8 @@ Voting members have the roles and responsibilities as outlined below. Subject to such policies as may be set by the Board, the CPC is responsible for: - 1. When needed, members of the CPC will be expected to create subcommittees or working groups. - The CPC will delegate responsibilities and empower these groups to make decisions. + 1. When needed, members of the CPC will be expected to create subcommittees or `collaboration spaces`. + The CPC may delegate responsibilities and empower these groups to make decisions. Any of the responsibilities listed below not identified as being responsibilities of the Voting members may be delegated. For the remaining responsibilities, day-to-day work, investigation, and building recommendations may be delegated, however, the final responsibility will remain with the Voting members. 1. Ensuring collaboration is the driving principle within a Project, between OpenJS Foundation Projects, and between OpenJS Foundation Projects and the broader community. diff --git a/README.md b/README.md index b8cd29863..6543f17c8 100644 --- a/README.md +++ b/README.md @@ -84,19 +84,22 @@ The following projects are official OpenJS Foundation projects. If you are inter The following are official OpenJS Collaboration spaces. If you are interested in fostering collaboration with the support of the OpenJS foundation through a collaboration space, please read our [Collaboration Space Progression](./collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md) -| Name | Repository | Description | -| -------------------------------------------- |:----------------------------------:|-----------------------------------------------------------------| -| Ecosystem Report | [Repository][ecosystem-report] | JavaScript ecosystem annual end-users poll and report | -| Open Visualization (OpenVis) | [Repository][openvis] | Visualization libraries based on JavaScript and WebGL | -| Package Metadata Interop | [Repository][pkg-metadata-interop] | Interoperability of package.json across the JS ecosystem | -| Package Vulnerability Management & Reporting | [Repository][pkg-vuln] | Package vulnerability management and reporting | -| Security | [Repository][security] | Documentation and coordination of the Foundation's security effort | +| Name | Repository | Authority Delegation | Description | +| -------------------------------------------- |:----------------------------------:| ---------------------- | ----------------------------------------------------------------| +| Ecosystem Report | [Repository][ecosystem-report] | No | JavaScript ecosystem annual end-users poll and report | +| Open Visualization (OpenVis) | [Repository][openvis] | No | Visualization libraries based on JavaScript and WebGL | +| Package Metadata Interop | [Repository][pkg-metadata-interop] | No | Interoperability of package.json across the JS ecosystem | +| Package Vulnerability Management & Reporting | [Repository][pkg-vuln] | No | Package vulnerability management and reporting | +| Security | [Repository][security] | No | Documentation and coordination of the Foundation's security effort | +| Standards | [Repository][standards] | [Yes][standards-deleg] | Facilitate the engagement of projects and collaborators in standards organizations | [ecosystem-report]: https://github.com/openjs-foundation/ecosystem-report [openvis]: https://github.com/openjs-foundation/openvis-collab-space [pkg-metadata-interop]: https://github.com/openjs-foundation/package-metadata-interoperability-collab-space [pkg-vuln]: https://github.com/openjs-foundation/pkg-vuln-collab-space [security]: https://github.com/openjs-foundation/security-collab-space +[standards]: https://github.com/openjs-foundation/standards +[standards-deleg]: ./collaboration-spaces/COLLABORATION_NETWORK.md#standards-collaboration-space ## CPC Meetings @@ -236,10 +239,9 @@ If an Observer fails to meet these expectations they can be excluded from future * [Policy Proposal Process](PROPOSAL_PROCESS.md) - Process by which the CPC creates new policies and processes. * [GitHub organization Management Policy](./governance/GITHUB_ORG_MANAGEMENT_POLICY.md) - Policy for managing the CPC's GitHub organization. -#### Collaboration Spaces and Working Groups +#### Collaboration Spaces * [Collaboration Network](./collaboration-spaces/COLLABORATION_NETWORK.md) * [Collaboration Space Progression](./collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md) -* [Working Groups](./governance/WORKING_GROUPS.md) #### Community Fund @@ -251,7 +253,7 @@ If an Observer fails to meet these expectations they can be excluded from future ### Policy Change Proposal Process -The OpenJS CPC is chartered to oversee the technical governance of all OpenJS Projects, Collaboration spaces and Working Groups under the OpenJS Foundation. The CPC establishes the default governance, conduct, and licensing policies for all Projects and Collaboration spaces. Projects have broad powers of self-governance. +The OpenJS CPC is chartered to oversee the technical governance of all OpenJS Projects and Collaboration spaces under the OpenJS Foundation. The CPC establishes the default governance, conduct, and licensing policies for all Projects and Collaboration spaces. Projects have broad powers of self-governance. Anyone may submit an idea for a policy or program following the [proposal process](PROPOSAL_PROCESS.md). diff --git a/collaboration-spaces/COLLABORATION_NETWORK.md b/collaboration-spaces/COLLABORATION_NETWORK.md index 793e22f76..184e6e71f 100644 --- a/collaboration-spaces/COLLABORATION_NETWORK.md +++ b/collaboration-spaces/COLLABORATION_NETWORK.md @@ -18,10 +18,26 @@ Support includes but not be limited to: The current Collaboration Networks spaces are listed in the main README.md in the CPC repository. -Collaboration spaces differ from Working Groups in that existing authority is not delegated from the CPC as is the case with a Working Group. -Instead of delegation of authority, the goal of a collaboration space is to support collaboration in a more independent manner. -The work of the space does not necessarily represent the Foundation (just like the views and direction of an individual project do not -necessarily represent the views of the Foundation) but is instead fostered and supported by the Foundation. -In this sense the relationship is more like that of projects to the Foundation versus Working Groups. - The [Collaboration Space Progression](./COLLABORATION_SPACE_PROGRESSION.md) document explains how a proposal for a new Collaboration space may be submitted and how Collaboration spaces move between stages. + +## Authority Delegation + +The Cross Project Council (CPC) main delegate scoped authority to a collaboration space. In such cases, the collaboration space may formally represent the Foundation, for example in a standards organization. + +Collaboration Spaces to which the CPC delegates authority are listed below: + +### Standards Collaboration Space + +The purpose of the Standards Collaboration Space is to act as a facilitator for OpenJS Foundation projects to support their engagement in various Standards Organizations, Working Groups, Technical Committees, and other spaces where internationally recognized standards are collaborated upon. + +Responsibilities include: + +* approve and support OpenJS Foundation project contributors in attending meetings held by standards organizations +* make OpenJS Foundation project contributors aware of developments in relevant standards +* help OpenJS Foundation projects formulate a standards strategy +* support new contributors to standards-making activities +* mentor project contributors who are unfamiliar with standards-making processes +* make recommendations to the Cross Project Council regarding standards organization membership +* managing ongoing relationships with standards ogranizations +* ensuring that OpenJS representatives are aware of the responsibility of being a delegate of the foundation as outlined in [the membership expectations](https://github.com/openjs-foundation/standards/blob/HEAD/MEMBER_EXPECTATIONS.md) +* facilitate when different projects' needs conflict resolution diff --git a/collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md b/collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md index f664c8c50..bda084a18 100644 --- a/collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md +++ b/collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md @@ -3,19 +3,15 @@ This governance policy describes how a new `Collaboration Space` can be established within the OpenJS Foundation, hereinafter referred to as the "Foundation", via the [Collaboration Space Proposal Process](#ii-collaboration-space-proposal-process). It describes the [Stages](#stages) a collaboration space may be admitted under and what the criteria and expectations are for a given stage, as well as the acceptance criteria for a space to move from one stage to another. -`Collaboration Spaces` are different than `Working Groups` in a number of ways: -* `Working Groups` are formally delegated responsibility from the scope of the Cross Project Council so that they can make autonomous decisions with respect to the delegated scope. - The subject of a `Collaboration Space` may be completely outside of the existing scope of the Cross Project Council. -* `Working Groups` are generally made up of an existing OpenJS members project contributors. - `Collaboration Spaces` are intended to expand the group of contributors to the work of the OpenJS Foundation's work by allowing people outside the OpenJS member projects to propose/collaborate on areas of importance to the JavaScript ecosystem. +The Cross Project Council (CPC) may [formally delegate authority](./COLLABORATION_NETWORK.md#authority-delegation) to a `Collaboration Space`, so that the `Collaboration Space` can make autonomous decisions with respect to the delegated scope. + +`Collaboration Spaces` are intended to expand the group of contributors to the work of the OpenJS Foundation's work by allowing people outside the OpenJS member projects to propose/collaborate on areas of importance to the JavaScript ecosystem. `Collaboration Spaces` may graduate between levels as outlined in this document. -In addition, it may make more sense for them to be converted into a `Working group` if formal delegation of responsibility is beneficial or most of the contributions/leadership is being made from those who are active in the CPC. -If there is an existing `Working Group` in a particular area a `Collaboration Space` will only be approved by the CPC with the support and approval from the `Working Group` that the space is complimentary. `Collaboration Space` applications must include the champions who will lead the effort and the credentials of the champion and those initially involved will be a key part of the evaluation process to ensure that the work of the spaces is aligned/respectful of the foundation vision and expectations. -Collaboration space progression - movement from one stage to another - allows spaces to participate at the level that is most appropriate for them given where they are in their lifecycle. Regardless of stage, all Foundation spaces benefit from access to some level of mentorship, support, and foundation resources. +Collaboration space progression - movement from one stage to another - allows spaces to participate at the level that is most appropriate for them given where they are in their lifecycle. Regardless of stage, all Foundation spaces benefit from access to some level of mentorship, support, and foundation resources. ## II. Collaboration Space Proposal Process diff --git a/governance/GITHUB_ORG_MANAGEMENT_POLICY.md b/governance/GITHUB_ORG_MANAGEMENT_POLICY.md index 83faa8481..fd06946b5 100644 --- a/governance/GITHUB_ORG_MANAGEMENT_POLICY.md +++ b/governance/GITHUB_ORG_MANAGEMENT_POLICY.md @@ -23,7 +23,7 @@ The following groups are granted Ownership permissions: ### Members -GitHub users are added as members to the [OpenJS GitHub Organization][] when they are added to any Working Group or team. Organization Owners should add new members to the organization when requested by a Working Group, or team. +GitHub users are added as members to the [OpenJS GitHub Organization][] when they are added to any Collaboration Space. Organization Owners should add new members to the organization when requested by a Collaboration Space or team. ## Repositories diff --git a/governance/GOVERNANCE.md b/governance/GOVERNANCE.md index 8ba77de20..e6d987211 100644 --- a/governance/GOVERNANCE.md +++ b/governance/GOVERNANCE.md @@ -134,7 +134,10 @@ Pull requests that do not change the charter or governance of the CPC can be mer * There are two approvals by CPC members * The PR has been open for at least 72 hours -Pull requests that change governance of the CPC (including approving changes to Working Groups) must meet the following conditions in addition to the ones listed for regular PRs. +The Cross Project Council (CPC) may [formally delegate authority](./COLLABORATION_NETWORK.md#authority-delegation) to a `Collaboration Space`, so that the `Collaboration Space` can make autonomous decisions with respect to the delegated scope. + + +Pull requests that change governance of the CPC (including changes to [auhtority delegation to Collaboration Spaces](./COLLABORATION_NETWORK.md#authority-delegation)) must meet the following conditions in addition to the ones listed for regular PRs. * The PR has been open for at least 14 days OR consensus is reached in a meeting with quorum of voting members. diff --git a/governance/WORKING_GROUPS.md b/governance/WORKING_GROUPS.md deleted file mode 100644 index 650d06ca7..000000000 --- a/governance/WORKING_GROUPS.md +++ /dev/null @@ -1,150 +0,0 @@ -# OpenJS Core Working Groups - -OpenJS Core Working Groups (WG) are autonomous projects created by the [Cross Project Council (CPC)][]. - -Working Groups can be formed at any time, but must be ratified by the CPC. Once formed, the work defined in the Working Group charter is the responsibility of the WG rather than the CPC. - -It is important that Working Groups are not formed prematurely. Working Groups are not formed to *begin* a set of tasks, but are formed once that work is underway and its contributors agree that doing the work as an autonomous project is the most beneficial next step. - -If the work defined in a Working Group's charter is complete, the charter should be revoked. - -A Working Group's charter can be revoked either by the consent of the Working Group's members, or by a CPC vote. Once revoked, any future work that previously fit within the scope of the dechartered working group becomes the responsibility of the CPC. - -## Joining a Working Group - -To find out how to join a working group, please review the GOVERNANCE.md document in the working group's repository. - -## Starting A Core Working Group - -A Working Group is established by first defining a charter that can be ratified by the CPC. A charter is a *statement of purpose*, a *list of responsibilities*, and a *list of initial membership*. - -A Working Group needs 3 initial members. These should be individuals who are already undertaking the work described in the charter. - -The list of responsibilities for the Working Group should be specific. Once established, these responsibilities are no longer governed by the CPC and therefore should not be broad or subjective. The only recourse the CPC has over the working group is to revoke the entire charter, and take on the work previously done by the working group themselves. - -If the responsibilities described in the Working Group's charter are currently undertaken by another WG, then the Working Group's charter will additionally have to be ratified by that WG. - -You can submit the Working Group charter for ratification by sending a Pull Request to this document, which adds it to the list of current Working Groups. Once ratified, the list of members should be maintained in the Working Group's README document. - -## Bootstrap Governance - -Once the CPC ratifies a charter, the Working Group inherits the following documentation for governance, contribution, conduct, and an MIT LICENSE. The Working Group is free to change these documents through their own governance process (hence the term "bootstrap"). - -```markdown -### *[insert WG name]* Working Group - -The OpenJS *[insert WG name]* is jointly governed by a Working Group (WG) that is responsible for high-level guidance of the project. - -The WG has the final authority over this project including: - -* Technical direction -* Project governance and process (including this policy) -* Contribution policy -* GitHub repository hosting -* Conduct guidelines -* Maintaining the list of additional Collaborators - -For the current list of WG members, please see the project [README.md](./README.md#current-project-team-members). - -### Collaborators - -The *[insert WG name]* GitHub repository is maintained by the WG and additional Collaborators who are added by the WG on an ongoing basis. - -Individuals making significant and valuable contributions are made Collaborators, and given commit-access to the project. These individuals are identified by the WG, and their addition as Collaborators is discussed during the weekly WG meeting. - -_Note:_ If you make a significant contribution and are not considered for commit-access, log an issue or contact a WG member directly and it will be brought up in the next WG meeting. - -Modifications of the contents of the *[insert WG repo]* repository are made on a collaborative basis. Anybody with a GitHub account may propose a modification via pull request(s), and it will be considered by the project Collaborators. All pull requests must be reviewed and accepted by a Collaborator with sufficient expertise who is able to take full responsibility for the change. In the case of pull requests proposed by an existing Collaborator, an additional Collaborator is required for sign-off. Consensus should be sought if additional Collaborators participate and there is disagreement around a particular modification. Please see the _Consensus Seeking Process_ below for further detail on the consensus model that is used for governance. - -Collaborators may opt to elevate significant or controversial modifications, or modifications that have not found consensus within the WG for discussion by assigning a ***WG-agenda*** tag to a pull request or issue. The WG should serve as the final arbiter, where required. - -For the current list of Collaborators, see the project [README.md](./README.md#current-project-team-members). - -### Working Group Membership - -Working Group seats are not time-limited, and there is no fixed-size for the Working Group (beyond the requirement of needing 3 inidividuals to establish it). However, a sufficient number of participants should be involved to ensure adequate coverage of important areas of expertise, which is balanced with the ability to make decisions efficiently. - -There is no specific set of requirements or qualifications for WG membership, beyond these rules. - -The WG may add additional members to the WG by unanimous consensus. - -A WG member may be removed from the WG by voluntary resignation, or by the unanimous consensus of all other WG members. - -Changes to WG membership should be posted in the WG's meeting agenda, and may be suggested as any other agenda item (see "WG Meetings" below). - -If a membership addition or removal is proposed during a meeting, and the full WG is not in attendance to participate, then the addition or removal is added to the agenda for the subsequent meeting. This is to ensure that all members are given the opportunity to participate in all membership decisions. If a WG member is unable to attend a meeting where a planned membership decision is being made, then their consent is assumed. - -### Working Group Meetings - -The WG meets regularly on a webinar platform. A designated moderator approved by the WG runs the meeting. Each meeting should be published to the [OpenJS YouTube Channel](https://www.youtube.com/channel/UCjxM1d3fv_mSEBsyp5MTFrg). - -Items are added to the WG agenda that are considered contentious, or are modifications of governance, contribution policy, WG membership, or release processes. - -The intention of the agenda is not to approve or review all patches, that should happen continuously on GitHub and be handled by the larger group of Collaborators. - -Any community member or contributor can ask that something be added to the next meeting's agenda by logging a GitHub Issue. Any Collaborator, WG member, or moderator can add the item to the agenda by adding the ***WG-agenda*** tag to the issue. - -Prior to each WG meeting, the moderator will share the Agenda with members of the WG. WG members can add any items they like to the agenda at the beginning of each meeting. The moderator and the WG cannot veto or remove items. - -The WG may invite persons or representatives from related projects to participate in a non-voting capacity. - -The moderator is responsible for summarizing the discussion of each agenda item, and commits it as a pull request after the meeting. - -### Consensus Seeking Process - -The Working Group follows a [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) decision-making model. - -When an agenda item has appeared to reach a consensus, the moderator will ask "Does anyone object?" as a final call for dissent from the group consensus. - -If an agenda item cannot reach a consensus: a WG member can call for either a closing vote, or a vote to table the issue until the next meeting. The call for a vote must be seconded by a majority of the WG, or else the discussion will continue. A simple majority wins. - -Note that changes to WG membership require unanimous consensus. See the "Working Group Membership" section above for more information. - - -## Developer's Certificate of Origin 1.1 - -*Note*: The DCO is mandatory for all OpenJS Foundation projects. - -By making a contribution to this project, I certify that: - -* (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or - -* (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or - -* (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. - -* (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. - -### Moderation Policy - -The [OpenJS Moderation Policy][] applies to this Working Group. Moderation Policy TBD. - -### Code of Conduct - -The [OpenJS Code of Conduct][] applies to this Working Group. - -[OpenJS Code of Conduct]: https://github.com/openjs-foundation/cross-project-council/blob/HEAD/CODE_OF_CONDUCT.md -[OpenJS Moderation Policy]: https://github.com/openjs-foundation/cross-project-council/blob/HEAD/Moderation-Policy.md -``` - -## Current Working Groups - -* [Standards](#standards) - -### [Standards](https://github.com/openjs-foundation/standards/) - -The purpose of the Standards Working Group is to act as a facilitator for OpenJS Foundation projects to support their engagement in various Standards Organizations, Working Groups, Technical Committees, and other spaces where internationally recognized standards are collaborated upon. - -Responsibilities include: -* approve and support OpenJS Foundation project contributors in attending meetings held by standards organizations -* make OpenJS Foundation project contributors aware of developments in relevant standards -* help OpenJS Foundation projects formulate a standards strategy -* support new contributors to standards-making activities -* mentor project contributors who are unfamiliar with standards-making processes -* make recommendations to the Cross Project Council regarding standards organization membership -* managing ongoing relationships with standards ogranizations -* ensuring that OpenJS representatives are aware of the responsibility of being a delegate of the foundation as outlined in [the membership expectations](https://github.com/openjs-foundation/standards/blob/HEAD/MEMBER_EXPECTATIONS.md) -* facilitate when different projects' needs conflict resolution - -[Cross Project Council (CPC)]: ../CPC-CHARTER.md - From cc341009df7a81e37c515b44402d459aedd57725 Mon Sep 17 00:00:00 2001 From: Tobie Langel Date: Sun, 14 Jul 2024 17:57:10 +0200 Subject: [PATCH 2/4] Update collaboration-spaces/COLLABORATION_NETWORK.md Co-authored-by: Jordan Harband Signed-off-by: Tobie Langel --- collaboration-spaces/COLLABORATION_NETWORK.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/collaboration-spaces/COLLABORATION_NETWORK.md b/collaboration-spaces/COLLABORATION_NETWORK.md index 184e6e71f..dc112d9c4 100644 --- a/collaboration-spaces/COLLABORATION_NETWORK.md +++ b/collaboration-spaces/COLLABORATION_NETWORK.md @@ -22,7 +22,7 @@ The [Collaboration Space Progression](./COLLABORATION_SPACE_PROGRESSION.md) docu ## Authority Delegation -The Cross Project Council (CPC) main delegate scoped authority to a collaboration space. In such cases, the collaboration space may formally represent the Foundation, for example in a standards organization. +The Cross Project Council (CPC) may delegate scoped authority to a collaboration space. In such cases, the collaboration space may formally represent the Foundation, for example in a standards organization. Collaboration Spaces to which the CPC delegates authority are listed below: From 9f86f45133628e51030ad34c4f2fb785a410d7f3 Mon Sep 17 00:00:00 2001 From: Tobie Langel Date: Mon, 15 Jul 2024 21:24:45 +0200 Subject: [PATCH 3/4] Apply suggestions from code review Co-authored-by: Chris de Almeida Signed-off-by: Tobie Langel --- collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md | 2 +- governance/GITHUB_ORG_MANAGEMENT_POLICY.md | 2 +- governance/GOVERNANCE.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md b/collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md index bda084a18..1a426e2b7 100644 --- a/collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md +++ b/collaboration-spaces/COLLABORATION_SPACE_PROGRESSION.md @@ -5,7 +5,7 @@ It describes the [Stages](#stages) a collaboration space may be admitted under a The Cross Project Council (CPC) may [formally delegate authority](./COLLABORATION_NETWORK.md#authority-delegation) to a `Collaboration Space`, so that the `Collaboration Space` can make autonomous decisions with respect to the delegated scope. -`Collaboration Spaces` are intended to expand the group of contributors to the work of the OpenJS Foundation's work by allowing people outside the OpenJS member projects to propose/collaborate on areas of importance to the JavaScript ecosystem. +`Collaboration Spaces` aim to expand the group of contributors to the OpenJS Foundation by enabling individuals outside of OpenJS Foundation projects to propose and collaborate on areas important to the JavaScript ecosystem. `Collaboration Spaces` may graduate between levels as outlined in this document. diff --git a/governance/GITHUB_ORG_MANAGEMENT_POLICY.md b/governance/GITHUB_ORG_MANAGEMENT_POLICY.md index fd06946b5..c6d726615 100644 --- a/governance/GITHUB_ORG_MANAGEMENT_POLICY.md +++ b/governance/GITHUB_ORG_MANAGEMENT_POLICY.md @@ -23,7 +23,7 @@ The following groups are granted Ownership permissions: ### Members -GitHub users are added as members to the [OpenJS GitHub Organization][] when they are added to any Collaboration Space. Organization Owners should add new members to the organization when requested by a Collaboration Space or team. +GitHub users are added as members to the [OpenJS GitHub Organization][] when they are added to any Collaboration Space. Organization Owners should add new members to the organization when requested by a Collaboration Space. ## Repositories diff --git a/governance/GOVERNANCE.md b/governance/GOVERNANCE.md index e6d987211..717202d64 100644 --- a/governance/GOVERNANCE.md +++ b/governance/GOVERNANCE.md @@ -137,7 +137,7 @@ Pull requests that do not change the charter or governance of the CPC can be mer The Cross Project Council (CPC) may [formally delegate authority](./COLLABORATION_NETWORK.md#authority-delegation) to a `Collaboration Space`, so that the `Collaboration Space` can make autonomous decisions with respect to the delegated scope. -Pull requests that change governance of the CPC (including changes to [auhtority delegation to Collaboration Spaces](./COLLABORATION_NETWORK.md#authority-delegation)) must meet the following conditions in addition to the ones listed for regular PRs. +Pull requests that change governance of the CPC (including changes to [authority delegation to Collaboration Spaces](./COLLABORATION_NETWORK.md#authority-delegation)) must meet the following conditions in addition to the ones listed for regular PRs: * The PR has been open for at least 14 days OR consensus is reached in a meeting with quorum of voting members. From 0c2a638c519b3db389f447c5973493a0daeb94d8 Mon Sep 17 00:00:00 2001 From: Tobie Langel Date: Fri, 26 Jul 2024 19:50:50 +0200 Subject: [PATCH 4/4] Apply suggestions from code review Co-authored-by: Mohammed Keyvanzadeh Signed-off-by: Tobie Langel --- collaboration-spaces/COLLABORATION_NETWORK.md | 4 ++-- governance/GOVERNANCE.md | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/collaboration-spaces/COLLABORATION_NETWORK.md b/collaboration-spaces/COLLABORATION_NETWORK.md index dc112d9c4..047163ed5 100644 --- a/collaboration-spaces/COLLABORATION_NETWORK.md +++ b/collaboration-spaces/COLLABORATION_NETWORK.md @@ -38,6 +38,6 @@ Responsibilities include: * support new contributors to standards-making activities * mentor project contributors who are unfamiliar with standards-making processes * make recommendations to the Cross Project Council regarding standards organization membership -* managing ongoing relationships with standards ogranizations +* managing ongoing relationships with standards organizations * ensuring that OpenJS representatives are aware of the responsibility of being a delegate of the foundation as outlined in [the membership expectations](https://github.com/openjs-foundation/standards/blob/HEAD/MEMBER_EXPECTATIONS.md) -* facilitate when different projects' needs conflict resolution +* facilitate when different projects' needs conflict diff --git a/governance/GOVERNANCE.md b/governance/GOVERNANCE.md index 717202d64..53c40231f 100644 --- a/governance/GOVERNANCE.md +++ b/governance/GOVERNANCE.md @@ -136,8 +136,7 @@ Pull requests that do not change the charter or governance of the CPC can be mer The Cross Project Council (CPC) may [formally delegate authority](./COLLABORATION_NETWORK.md#authority-delegation) to a `Collaboration Space`, so that the `Collaboration Space` can make autonomous decisions with respect to the delegated scope. - -Pull requests that change governance of the CPC (including changes to [authority delegation to Collaboration Spaces](./COLLABORATION_NETWORK.md#authority-delegation)) must meet the following conditions in addition to the ones listed for regular PRs: +Pull requests that change CPC governance (including changes to [authority delegation to Collaboration Spaces](./COLLABORATION_NETWORK.md#authority-delegation)) must meet the following conditions in addition to the ones listed for regular PRs: * The PR has been open for at least 14 days OR consensus is reached in a meeting with quorum of voting members.