diff --git a/PROPOSAL_PROCESS.md b/PROPOSAL_PROCESS.md deleted file mode 100644 index 312ddeb20..000000000 --- a/PROPOSAL_PROCESS.md +++ /dev/null @@ -1,35 +0,0 @@ -# Proposal Process - -Anyone may submit an idea for a policy or program following the proposal process outlined below. -To submit an idea, create a folder in the appropriate directory found in `./proposals`, update [proposals/README.md](./README.md), submit a pull-request, and apply the appropriate proposal label. - -For incubating proposals a README.md is sufficient, for later stages please include the appropriate supporting documents as well. - -## Incubating Proposal - -An initial PR is created to incubate/refine a proposal until it is ready to be approved adopted. -Before landing it needs to have an identified 'champion' (this can be anybody) who will be pushing the proposal through to its conclusion. - -They should have a rough description of the program idea or policy, what resources would be needed to execute it, what committee or role is responsible for overseeing it, ideas for metrics, execution, and so forth. -They have clear language about which group or groups the program/policy will serve. -The purpose of this stage is to capture the spirit of an idea the community may want to explore further, and to begin thinking about implementation ideas or process questions that need to be answered. - -The PR should include a new directory in the proposals directory titled for the proposal with a README.md with the outline -for the proposal. - -An incubating proposal can be updated through as many PRs as you’d like, essentially providing snapshots - -## Ready for Approval - -When ready a new PR is created to move an incubating proposal to the ready for approval by the CPC and if necessary the board. -Proposals in this stage are written up in the style of the formal policy or program language. -They include examples of the program idea or policy in action, with clear steps and guidelines. -They include the steps that will need to be taken to initially implement the idea or policy. - -The purpose of this stage is to refine the policy, make sure all stakeholders (potentially including the board) have had a chance to review and request changes, and determine whether further iteration is needed. - -The PR should include: - * moving the new artifacts into place (for example into the top level of the CPC repo). - * moving the directory the proposal into the Approved directory within the proposals directory - -Once the PR lands the proposal is considered complete and in place. diff --git a/README.md b/README.md index b8cd29863..70d1c75e0 100644 --- a/README.md +++ b/README.md @@ -233,7 +233,6 @@ If an Observer fails to meet these expectations they can be excluded from future * [CPC Charter](CPC-CHARTER.md) - The CPC's charter describes the CPC's mission as defined in the Bylaws. * [OpenJS Cross Project Council Governance](./governance/GOVERNANCE.md) - Describes how the CPC operates. * [Expectations of the Community Board of Directors Representatives](./governance/COMMUNITY_BOARD_SEAT_EXPECTATIONS.md) - Description of the role and responsibilities of the Community Board of Directors Representatives. -* [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 @@ -253,9 +252,7 @@ If an Observer fails to meet these expectations they can be excluded from future 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. -Anyone may submit an idea for a policy or program following the [proposal process](PROPOSAL_PROCESS.md). - -The pull request can be labeled cross-project-council-agenda to request that it be put on the agenda for the next CPC meeting. +Anyone may submit an idea for a policy or program by opening an issue in this repository. The issue should be reviewed at the next CPC meeting. The OpenJS Foundation Board of Directors retains certain rights (especially legal considerations). If the CPC endorses a proposal, they will escalate to the OpenJS Foundation Board of Directors when required to do so. diff --git a/artifacts/BOOTSTRAP_README.md b/artifacts/BOOTSTRAP_README.md index 15a8eb59b..675febad8 100644 --- a/artifacts/BOOTSTRAP_README.md +++ b/artifacts/BOOTSTRAP_README.md @@ -42,4 +42,4 @@ The deliverables from this body will be: ## Making proposals -Anyone may submit an idea for a policy or program following the [proposal process](../PROPOSAL_PROCESS.md). +Anyone may submit an idea for a policy or program following the [proposal process](https://github.com/openjs-foundation/cross-project-council/blob/a376c1dabb01fb1f0ac66affa9104876dee76fa9/PROPOSAL_PROCESS.md). diff --git a/meetings/2019/2019-01-07.md b/meetings/2019/2019-01-07.md index 2c3323b36..9727bb782 100644 --- a/meetings/2019/2019-01-07.md +++ b/meetings/2019/2019-01-07.md @@ -30,7 +30,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * * CPC Charter - 5 minute timebox - Refs: - - [Proposal Readme](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/proposals/approved/CPC_CHARTER/README.md) + - [Proposal Readme](https://github.com/nodejs/bootstrap/blob/03ba5897e9c4e01ac2bf6b118a9a5ea2b5b85f61/proposals/mdawson-cpc-charter/README.md) - https://github.com/nodejs/bootstrap/pull/65 - MDawson recaps - reframe the CPC to be more open, easier to enter. Thinks this PR is ready to land based on the comments so far. Needs more @@ -41,7 +41,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * * Project Progression - 5 minute timebox - Refs: - - [Proposal Readme](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/proposals/approved/PROJECT_PROGRESSION/README.md) + - [Proposal Readme](https://github.com/nodejs/bootstrap/blob/03ba5897e9c4e01ac2bf6b118a9a5ea2b5b85f61/proposals/jorydotcom-PROJECT_PROGRESSION/README.md) - Proposal described how a project might be categorized when it comes into the Foundation and what would be required around levels (e.g. top level project), maturity or other factors in @@ -53,7 +53,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * * Expectations - 5 minute timebox - Refs: - - [Expectations.md](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/proposals/approved/EXPECTATIONS/EXPECTATIONS.md) + - [Expectations.md](https://github.com/nodejs/bootstrap/blob/03ba5897e9c4e01ac2bf6b118a9a5ea2b5b85f61/proposals/hackygolucky-EXPECTATIONS/EXPECTATIONS.md) - Myles: Proposes to move the doc to stage 2 - MDawson: What about the node project board seats? @@ -102,7 +102,7 @@ Myles: introduces LittleDan to talk about the foundation’s involvement in stan - What does the CPC look like? [#37](https://github.com/nodejs/bootstrap/issues/37) - Top Level Council(s) Shape and Focus [#52](https://github.com/nodejs/bootstrap/issues/52) - https://github.com/nodejs/bootstrap/projects/1 - - [CPC Charter Proposal](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/proposals/approved/CPC_CHARTER/README.md) + - [CPC Charter Proposal](https://github.com/nodejs/bootstrap/blob/03ba5897e9c4e01ac2bf6b118a9a5ea2b5b85f61/proposals/mdawson-cpc-charter/README.md) - Myles: Recap work done to differentiate CPC and C3 responsibilities in project board. Not clear we need a hard seperation between CPC and C3. This is important for us to figure out diff --git a/meetings/2019/2019-01-14.md b/meetings/2019/2019-01-14.md index a16f802af..2db769f0c 100644 --- a/meetings/2019/2019-01-14.md +++ b/meetings/2019/2019-01-14.md @@ -30,7 +30,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * * CPC Charter - 5 minute timebox - Refs: - - [Proposal Readme](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/proposals/approved/CPC_CHARTER/README.md) + - [Proposal Readme](https://github.com/nodejs/bootstrap/blob/f3a20922551773517d557f3d54a4aedbfba4faac/proposals/mdawson-cpc-charter/README.md) - https://github.com/nodejs/bootstrap/pull/65 Mdawson: Update: 2 prs since last discussion. Board represntation wasn’t in the first pr. The proposal includes 1 board seat for the chair as well as 2 other seats tbd by the CPC. For the first year those proceses would be 1) dedicated to the Node projects and the other being a vote of the members with candidates of non-node projects. The folloing years the CPC could decide. Otehr comments have been addressed. Make it clearer that anyone can show up to participate so we added ‘Observers’. Distinction that regular members make contributions on an ongoing basis. Other comments can be discussed later before we progress too much. @@ -38,14 +38,15 @@ Mdawson: Update: 2 prs since last discussion. Board represntation wasn’t in th * Project Progression - 5 minute timebox - Refs: - - [Proposal Readme](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/proposals/approved/PROJECT_PROGRESSION/README.md) + - [Proposal Readme](https://github.com/nodejs/bootstrap/blob/f3a20922551773517d557f3d54a4aedbfba4faac/proposals/jorydotcom-PROJECT_PROGRESSION/README.md) Jory: Great meeting this morning, Action items to define open governance for top level projects and to fill gap around code of conduct expectations for projects. Good basis of progress from which to move forward. * Expectations - 5 minute timebox - Refs: - - [Expectations.md](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/proposals/approved/EXPECTATIONS/EXPECTATIONS.md) + - [Expectations.md](https://github.com/nodejs/bootstrap/blob/f3a20922551773517d557f3d54a4aedbfba4faac/proposals/hackygolucky-EXP +ECTATIONS/EXPECTATIONS.md) No update since last week, moving on to next item. @@ -87,7 +88,7 @@ Jory: None - proposal: Community Board Representation Stage 1 [#72](https://github.com/nodejs/bootstrap/pull/72) - Top Level Council(s) Shape and Focus [#52](https://github.com/nodejs/bootstrap/issues/52) - https://github.com/nodejs/bootstrap/projects/1 - - [CPC Charter Proposal](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/proposals/approved/CPC_CHARTER/README.md) + - [CPC Charter Proposal](https://github.com/nodejs/bootstrap/blob/f3a20922551773517d557f3d54a4aedbfba4faac/proposals/mdawson-cpc-charter/README.md) All: +1 to closing #38 diff --git a/meetings/2019/2019-01-21.md b/meetings/2019/2019-01-21.md index 1c41ed69b..0fe15a3eb 100644 --- a/meetings/2019/2019-01-21.md +++ b/meetings/2019/2019-01-21.md @@ -57,7 +57,7 @@ All: +1 * Define 'Open Governance' requirements for Top Level Projects [#74](https://github.com/nodejs/bootstrap/issues/74) - 15 minute timebox - Refs: - - [Project Progression Proposal](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/PROJECT_PROGRESSION) + - [Project Progression Proposal](https://github.com/nodejs/bootstrap/tree/4c2bde205b7e01195b24b3ba2320a3ffb1beda56/proposals/stage-1/PROJECT_PROGRESSION) Myles/Jory: Provides overview. @@ -121,7 +121,7 @@ We need a proposal for how this works - MDawson will take the first draft. - refs: - What does the CPC look like? [#37](https://github.com/nodejs/bootstrap/issues/37) - [Responsibilities Project Board](https://github.com/nodejs/bootstrap/projects/1) - - [CPC Charter Proposal](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/proposals/approved/CPC_CHARTER/README.md) + - [CPC Charter Proposal](https://github.com/nodejs/bootstrap/blob/4c2bde205b7e01195b24b3ba2320a3ffb1beda56/proposals/mdawson-cpc-charter/README.md) - proposal: Community Board Representation Stage 1 [#72](https://github.com/nodejs/bootstrap/pull/72) diff --git a/meetings/2019/2019-02-04.md b/meetings/2019/2019-02-04.md index f0e898892..02d9413fd 100644 --- a/meetings/2019/2019-02-04.md +++ b/meetings/2019/2019-02-04.md @@ -49,7 +49,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * ### Proposals (35 minutes) -* [CPC Charter](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/CPC_CHARTER) +* [CPC Charter](https://github.com/nodejs/bootstrap/tree/942f7a9fc06cc68db5932e6b5f9ca9e3934ab544/proposals/stage-1/CPC_CHARTER) - Refs: - remove regular members from CPC charter [#93](https://github.com/nodejs/bootstrap/pull/93) @@ -58,7 +58,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * * Mike: models that are simpler to engage is usually easier to start with * Sarah are motiviate in many different ways. Least friction to get involved is one way. -* [Expectations](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/EXPECTATIONS) +* [Expectations](https://github.com/nodejs/bootstrap/tree/942f7a9fc06cc68db5932e6b5f9ca9e3934ab544/proposals/stage-1/EXPECTATIONS) - Refs: - expectations to stage 2 [#92](https://github.com/nodejs/bootstrap/pull/92) @@ -66,7 +66,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * * Myles proposes that we move to stage 2. No objections in the call to this landing at stage 2. * Aim to land next week, leaving a week for people to chime in. -* [Individual Membership](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/INDIVIDUAL_MEMBERSHIP) +* [Individual Membership](https://github.com/nodejs/bootstrap/tree/942f7a9fc06cc68db5932e6b5f9ca9e3934ab544/proposals/stage-0/individual-membership) - Refs: - individual membership to stage 1 [#91](https://github.com/nodejs/bootstrap/pull/91) - Create Individual Membership representation proposal [#82](https://github.com/nodejs/bootstrap/pull/82) @@ -91,7 +91,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * * Andrew Updegrove we can put in some placeholder or words that show things are a possibility. -* [Project Progression](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/PROJECT_PROGRESSION) +* [Project Progression](https://github.com/nodejs/bootstrap/tree/942f7a9fc06cc68db5932e6b5f9ca9e3934ab544/proposals/stage-1/PROJECT_PROGRESSION) - Refs: - Move to Stage 2 [#88](https://github.com/nodejs/bootstrap/pull/88) - Define 'Open Governance' requirements for Top Level Projects [#74](https://github.com/nodejs/bootstrap/issues/74) diff --git a/meetings/2019/2019-02-11.md b/meetings/2019/2019-02-11.md index 4d4787fe1..d1376ed93 100644 --- a/meetings/2019/2019-02-11.md +++ b/meetings/2019/2019-02-11.md @@ -37,7 +37,7 @@ No objections to landing as stage 1. Further iteration will happen prior to sta ### Proposals (50 minutes) -* [CPC Charter](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/CPC_CHARTER) +* [CPC Charter](https://github.com/nodejs/bootstrap/tree/88fdf8aeecbc30bccb148b09bee0e10f54fd9551/proposals/stage-1/CPC_CHARTER) - 10 minute timebox - Refs: - remove regular members from CPC charter [#93](https://github.com/nodejs/bootstrap/pull/93) @@ -59,7 +59,7 @@ A: If the goal is to create inclusion, we can try this and iterate. If we find Myles to remove objection. -* [Expectations](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/EXPECTATIONS) +* [Expectations](https://github.com/nodejs/bootstrap/tree/88fdf8aeecbc30bccb148b09bee0e10f54fd9551/proposals/stage-1/EXPECTATIONS) - 10 minute timebox - Refs: - expectations to stage 2 [#92](https://github.com/nodejs/bootstrap/pull/92) @@ -70,7 +70,7 @@ We were planning to close this last week, but left it open for one more week. Absent comments, this will be moved forward to stage 2. -* [Individual Membership](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/INDIVIDUAL_MEMBERSHIP) +* [Individual Membership](https://github.com/nodejs/bootstrap/tree/88fdf8aeecbc30bccb148b09bee0e10f54fd9551/proposals/stage-0/individual-membership) - 10 minute timebox - Refs: - individual membership to stage 1 [#91](https://github.com/nodejs/bootstrap/pull/91) @@ -87,7 +87,7 @@ Action: Myles to add language to the proposal specifically identifying that we n Q: Should this be a CPC chartered program or a board chartered program? A: Jory recommends it be a CPC program, as they are in the best position to ensure community transparency and accountability. -* [Project Progression](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/PROJECT_PROGRESSION) +* [Project Progression](https://github.com/nodejs/bootstrap/tree/88fdf8aeecbc30bccb148b09bee0e10f54fd9551/proposals/stage-1/PROJECT_PROGRESSION) - 10 minute timebox - Refs: - Move to Stage 2 [#88](https://github.com/nodejs/bootstrap/pull/88) diff --git a/meetings/2019/2019-02-25.md b/meetings/2019/2019-02-25.md index 785790de0..5d79ac781 100644 --- a/meetings/2019/2019-02-25.md +++ b/meetings/2019/2019-02-25.md @@ -23,7 +23,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. ### Proposal Advancement (15 minutes) -* [CPC Charter](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/CPC_CHARTER) +* [CPC Charter](https://github.com/nodejs/bootstrap/tree/f94c0e919a33bd0323d6190d84f341d21e1a3d6c/proposals/stage-1/CPC_CHARTER) * 5 minute timebox * Refs: * proposal: Move CPC_CHARTER to stage-2. @@ -58,7 +58,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * * Myles: Does anyone object to moving this to stage 2? * None -* [Individual Membership](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/INDIVIDUAL_MEMBERSHIP) +* [Individual Membership](https://github.com/nodejs/bootstrap/tree/f94c0e919a33bd0323d6190d84f341d21e1a3d6c/proposals/stage-0/individual-membership) * 5 minute timebox * Refs: * proposal: individual membership to stage-2 @@ -66,7 +66,7 @@ Extracted from **bootstrap-agenda** labelled issues and pull requests from the * * Myles: Does anyone object to landing number 102? * None -* [Community Board Representation](https://github.com/openjs-foundation/cross-project-council/tree/HEAD/proposals/approved/COMMUNITY_BOARD_REPRESENTATION) +* [Community Board Representation](https://github.com/nodejs/bootstrap/tree/f94c0e919a33bd0323d6190d84f341d21e1a3d6c/proposals/stage-1/COMMUNITY_BOARD_REPRESENTATION) * 5 minute timebox * Refs: * proposal: individual membership to stage-2 diff --git a/meetings/2021/2021-05-11.md b/meetings/2021/2021-05-11.md index 26eb6a814..7ef486b07 100644 --- a/meetings/2021/2021-05-11.md +++ b/meetings/2021/2021-05-11.md @@ -37,7 +37,7 @@ * Create proposal(s) for the Community Fund [#756](https://github.com/openjs-foundation/cross-project-council/issues/756) * Placeholder issue to make sure it gets done. The team has put together a draft proposal. - * Brian walked the group through the proposal: https://github.com/openjs-foundation/cross-project-council/tree/add-community-fund-logistics/proposals/incubating/COMMUNITY_FUND_PROCESS + * Brian walked the group through the proposal: https://github.com/openjs-foundation/cross-project-council/tree/4cf6fb0994b454e6c899a2dcb0c189bfd3f1708f/proposals/incubating/COMMUNITY_FUND_PROCESS * Proposal includes using the LFX Crowdfunding tool * Issues like the Wire fees that apply to non-us accounts, costs to those who can’t afford the travel could be addressed on a case by case basis * Discussion will continue diff --git a/proposals/README.md b/proposals/README.md deleted file mode 100644 index 56844cbfd..000000000 --- a/proposals/README.md +++ /dev/null @@ -1,31 +0,0 @@ -# Proposals - -Anyone may submit an idea for a policy or program following the [proposal process](../PROPOSAL_PROCESS.md). - -## Incubating - -* [Project Exit Criteria](./incubating/PROJECT_EXIT_CRITERIA) -* [Regular Town Halls](./incubating/REGULAR_TOWN_HALLS) -* [Shared Interfaces](./incubating/SHARED_INTERFACES) -* [Standards Outreach](./incubating/STANDARDS_OUTREACH) -* [Charter Review](./incubating/CHARTER_REVIEW) -* [Collab Summit](./incubating/COLLAB_SUMMIT) - -## Approved - -* [Community Board representation](./approved/COMMUNITY_BOARD_REPRESENTATION) -* [CPC Charter](./approved/CPC_CHARTER) -* [Expectations](./approved/EXPECTATIONS) -* [Governance](./approved/GOVERNANCE) -* [Individual Membership program](./approved/INDIVIDUAL_MEMBERSHIP) -* [Project Onboarding](./approved/PROJECT_ONBOARDING) -* [Project Progression](./approved/PROJECT_PROGRESSION) -* [Travel Fund](./approved/TRAVEL_FUND) -* [Code of Conduct approach](./approved/CODE_OF_CONDUCT) -* [Security Reporting](../PROJECT_SECURITY_REPORTING.md) -* [Individual Supporter Program](./approved/SUPPORTER_PROGRAM) -* [Collaboration Network](./approved/COLLABORATION_NETWORK) -* [Security Reporting](./approved/SECURITY_REPORTING) -* [Individual Supporter Program](./approved/SUPPORTER_PROGRAM) -* [Collaboration Network](./approved/COLLABORATION_NETWORK) - diff --git a/proposals/TEMPLATE.md b/proposals/TEMPLATE.md deleted file mode 100644 index 9ce44a871..000000000 --- a/proposals/TEMPLATE.md +++ /dev/null @@ -1,36 +0,0 @@ -# My New Proposal -> incubating - -Below is simply a suggested template for drafting a proposal, it will not fit all potential proposals. - -## Champion - -Who is the stakeholder of this initiative? - -## Description - -A rough description of the program idea or policy - -## Required Resources - -What resources would be needed to execute it? - -## Who would be responsible? - -Which committee would be overseeing or responsible for executing this proposal - -## How would success be measured? - -Please include potential metrics that can be used to measure success of the proposal. - -## Why this proposal is important - -Why should we do this? - -## Unresolved Question - -Current objections or concerns that will be required to reach approved - -## What is necessary to complete this proposal - -Everything required to reach approved diff --git a/proposals/approved/CODE_OF_CONDUCT/README.md b/proposals/approved/CODE_OF_CONDUCT/README.md deleted file mode 100644 index 3b25c2eca..000000000 --- a/proposals/approved/CODE_OF_CONDUCT/README.md +++ /dev/null @@ -1,46 +0,0 @@ -# CPC Charter Proposal -> approved - -## Champion - -Michael Dawson (@mhdawson) - -## Description - -These documents capture a proposed approach for implementing and handling Code of Conducts within the Foundation. - -* `FOUNDATION_CODE_OF_CONDUCT_REQUIREMENTS.md`: a proposed approach for -managing Code of Conducts within the Foundation. -* `HANDLING_CODE_OF_CONDUCT_REPORTS.md`: a proposed framework for handling reports and escalation. - -## Required Resources - -Discussion/approval by bootstrap committee - -## Who would be responsible? - -In current proposals for the groups within a merged -foundation, the responsibility would be a joint -responsibility of the Foundation, Board, CPC, and projects. - -## How would success be measured? - -Success is incorporation of the content within this document -either as the document itself or incorporate into one -of the other Governance documents for the foundation. - -## Why this proposal is important - -We need to agree on the requirements a Code of Conduct -as part of the requirements for projects joining the -foundation. - -## What is neccessary to complete this proposal - -## Further questions - -### Other thoughts to consider later on -* Form: It would be easier on the reportee to have a form template to help them structure their report. The form submission could trigger an email. TODO: copy for a form. -* Repo: openjs/moderation (not provisioned). As commented in PR review, hosting sensitive personal information on GitHub needs due consideration, review, and possibly legal consultation. -* Beacon project -* Code of Conduct Project: A cross-project collaboration between multiple open source tech communities (RxJS, AngularJS, Node.js, Vue.js, etc.) to find consensus on Code of Conducts. Progress is rapid and can add definition to our own process (where possible) within 6 months. Recommend incorporating the findings and avoid duplication of effort. diff --git a/proposals/approved/COLLABORATION_NETWORK/README.md b/proposals/approved/COLLABORATION_NETWORK/README.md deleted file mode 100644 index 5d4d66caf..000000000 --- a/proposals/approved/COLLABORATION_NETWORK/README.md +++ /dev/null @@ -1,82 +0,0 @@ -# JavaScript Outreach Groups -> approved - -## Champion - -Michael Dawson(@mhdawson) - -## Description - - -The formation of the OpenJS Foundation was in support of a number of goals. -The first was to support JavaScript projects, providing a neutral place for people to collaborate and resources needed by those projects (legal, marketing, best practices governance support, infra, etc.). - -Good progress has been made on this front with governance for accepting and onboarding projects having been defined and the first projects working through the process. - -The second goal was to foster greater collaboration in the JavaScript ecosystem. Bringing -projects together in a single Foundation provides an easier path to collaboration between projects. We see this collaboration starting, for example, in the formation of the Standards -working group. However, I feel support for collaboration efforts should be broader than that scope. - -The OpenJS Foundation should act as a neutral place for people to collaborate on areas of -importance to the JavaScript ecosystem. In some cases, this may align with projects and in -other cases be independent of the member projects. Regardless of the alignment with existing -member projects, the OpenJS Foundation should provide support for collaboration in -a particular area. Support could include but not be limited to: -* a repo in the OpenJS org -* marketing support -* mailing lists -* slack channels -* etc. -* representation on the CPC - -In the same way, as we have a process/governance for reviewing projects that wish to join -the Foundation we could have process/governance for applications to start a new -`OpenJS Collaboration Space`. Those submitting the application need not be within -member projects and the application would be reviewed/accepted by the CPC as is the -case with projects. - -My hope is that this approach would help provide more focus/support for collaboration -as an effort independent from member projects. - -Some of the `Collaboration Spaces` that I could envision include: - -* Security -* Test -* Runtimes (Node.js, electron, WASI, etc/.) -* Web Frameworks (Express, Fastify, Hapi, etc.) -* JavaScript Standards (existing Standards team?) -* Package management (npm, yarn) -* Registries, local caches -* Package ecosystem (Package-maintenance team in Node.js ?) - - -One key question is if this would better support collaboration versus just -adopting `Working Group` governance along the lines of what was supported -in the Node.js space. One area that would be different is that responsibility -would not necessarily be delegated from the CPC, as the "Space" might cover -an area with is outside the charter of the CPC, much like responsibility the -work in a specific project is outside the scope of the CPC. - - - -## Required Resources - - -## Who would be responsible? - - -## How would success be measured? - -A number of active and vibrant collaboration spaces. - - -## Why this proposal is important - -See description above - - -## Unresolved Question - - -## What is necessary to complete this proposal - diff --git a/proposals/approved/COMMUNITY_BOARD_REPRESENTATION/README.md b/proposals/approved/COMMUNITY_BOARD_REPRESENTATION/README.md deleted file mode 100644 index 0f580e437..000000000 --- a/proposals/approved/COMMUNITY_BOARD_REPRESENTATION/README.md +++ /dev/null @@ -1,50 +0,0 @@ -# Community Board Representation -> approved - -## Champion - -[Myles Borins](https://github.com/MylesBorins) - -## Description - -### What exists today - -Currently the Node.js foundation has up to 3 community board seats: - -* 1 board seat for TSC -* 1 board seat for Community Committee -* 1 board seat for Individual Membership Program - -There are some limitations on these seats as noted in [Section 4.3](https://github.com/nodejs/board/blob/HEAD/by-laws.md#section-43-nomination-election-and-term-of-office-of-directors), -specifically that: - -4.3 d) There must be 3 platinum directors for the individual membership theo elect a board member - -4.3 e) There must be 2 platinum directors for the TSC or CommComm to elect a board member - -### Proposal for OpenJS Foundation - -There would be up to 3 community board seats: - -* 1 board seat for CPC -* 1 floating board seat to be delegated by CPC - - delegated on an annual basis and approved by Board -* 1 board seat for the individual membership program - -Similar to the current bylaws there would be some limitations that would activate seats: - -* CPC would always have a board seat independent of platinum membership -* There must be 2 platinum directors to activate the floating board seat -* There must be 3 platinum directors and 2k individual members to activate the individual board member seat - -These limitations allow for representation to scale with the growth of the foundation while also ensuring that there -will always be community representation. - -## Who would be responsible? - -This would be owned by both the board and the CPC - -## Why this proposal is important - -Community representation is extremely important to the success of the foundation ensuring the board has insight -into the community and vice versa. diff --git a/proposals/approved/CPC_CHARTER/CPC-CHARTER.md b/proposals/approved/CPC_CHARTER/CPC-CHARTER.md deleted file mode 100644 index 96a826f40..000000000 --- a/proposals/approved/CPC_CHARTER/CPC-CHARTER.md +++ /dev/null @@ -1,319 +0,0 @@ -# Cross Project Council (CPC) Charter - -## Section 1. Guiding Principle. - -The OpenJS Foundation will operate transparently, openly, -collaboratively, and ethically. Project proposals, timelines, and status -must not merely be open, but also easily visible to outsiders. - -## Section 2. Evolution of OpenJS Foundation Governance. - -Most large, complex open source communities have both a business and a -technical governance model. OpenJS Foundation’s technical leadership -is the Cross Project Council (“CPC”). OpenJS Foundation’s business -leadership is the Board of Directors (the “Board”). - -This Cross Project Council Charter reflects a carefully -constructed, balanced role for the CPC and the Board in the governance of -OpenJS Foundation. The charter amendment process is for the -OpenJS Foundation to propose changes using simple majority of the -full OpenJS Foundation, the proposed changes being subject to review -and approval by the Board. The Board may additionally make amendments to -the OpenJS Foundation charter at any time, though the Board will not interfere -with day-to-day discussions, votes or meetings -of the CPC. - -## Section 3. Board’s Role in Setting OpenJS Foundation’s Strategic Direction. - -The Board will set the CPC Policy. The policy will describe the -overarching scope of the OpenJS Foundation initiative, OpenJS Foundation -Foundation’s technical vision and direction and project release -expectations in the form of expected cadence and intent. The Board will -use the CPC as a delegate body for governing technical implementation, -individual project scope and direction while they remain within the scope -and direction of the policies as described in the CPC Policy document and -approved by the Board. - -The Board sets the CPC policy through Foundation mission and vision -statements as well as within the [Foundation bylaws][]. The policy describes -the overarching scope of the OpenJS Foundation initiatives , technical vision, -and direction. The Board uses the CPC as a delegate body for governing -high-level technical policy and procedures while remaining within the scope and -direction of the policies set by the Board. - - -## Section 4. Establishment of the CPC. - -The CPC is an inclusive group with three types of participants: - -* Observers -* Regular members -* Voting members - - -### Observers - -Observers are free to attend meetings and participate in the work of the -CPC as well as the consensus seeking process. - -### Regular members - -Regular members have made a commitment to be involved in an ongoing manner -and take on roles and responsibilities as outlined below. -Regular member is implied when membership type is not -specified. Anyone who has been a member of one of the projects under the -OpenJS Foundation for at least three months may request to -become a regular member by opening a PR to add themselves to the list of -regular members. Regular members remain for as long as they are active -within the work of the CPC. Regular members who have not been active -in GitHub, participated in meetings, or other work of the CPC for 3 months may be -removed from the list of Regular members. In addition, a Regular CPC member -can be removed by voluntary resignation, or by a standard CPC motion. - -### Voting members - -Voting members are selected as follows: - -* Each Impact project may nominate up to two members through a process -of their choosing. Once nominated the member must be ratified by the -CPC Voting members before becoming a Voting member. - -* up to two Voting members may be nominated by the non-Impact projects based -on a process set by the CPC. - -* up to two Voting members may be nominated by the Regular members. Once -nominated these members must be ratified by the CPC Voting members -before becoming a Voting member. - -Voting members are expected to make a time commitment which -allows them to be responsive to CPC business, participate regularly -in meetings and to participate in all voting matters (either by -voting or specifically abstaining). They are -also expected to help to enable work of the regular CPC -members by providing leadership, help with interactions with the -board and Foundation staff and to generally help keep things moving. - -Voting members serve for a term of 1 year and must be re-nominated -and ratified by the Voting CPC members each year. In addition, a Voting CPC member -can be removed by voluntary resignation, by a standard CPC motion, -or in accordance to the participation rules described for Regular -members. - -Changes to CPC membership should be posted in the agenda, and may be suggested -as any other agenda item. - -No more than one-fourth of the Voting CPC members may be affiliated with the -same employer. Removal or resignation of a Voting CPC member, or a change of -employment by a Voting CPC member could cause more than -one-fourth of the Voting CPC membership to be affiliated with the same employer. -Such a situation must be immediately remedied by the resignation or -removal of one or more voting CPC members. - -The public portion of the CPC discussions and meetings will be open to all -observers and members. - -The CPC shall meet regularly using tools that enable participation by the -community. The meeting shall be directed by the CPC Chairperson. -Responsibility for directing individual meetings may be -delegated by the CPC Chairperson to any other CPC member. The CPC chairperson -shall be one of the Voting members, and will be selected by the CPC members -through consensus or if necessary a vote as described in the section titled "Voting". -Minutes or an appropriate recording shall be taken and made available to -the community through accessible public postings. - -Voting members have the roles and responsibilities as outlined below. - -Section 5. Responsibilities and Expectations of the CPC - -Subject to such policies as may be set by the Board, the CPC is responsible for -ensuring: - - 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. 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. - 1. Defining and maintaining neutral consensus for the technical vision for the OpenJS Foundation. - 1. Creating conceptual architecture for how the projects fit together. - 1. Voting members are responsible for approving new projects within the scope - for OpenJS Foundation set by the Governing Board, as outlined in the Project Progression Process. - 1. Voting members are responsible for making final decisions on aligning projects, - removing or archiving projects, as outlined in Project Progression Process. - 1. Voting members are responsible for approving the charter - (and any updates) for projects which are part of the OpenJS Foundation. As part of this - review/approval the voting members will ensure that the updated charter is compatible - with the mission of the OpenJS Foundation and reach consensus with the Board on more - substantial changes before final approval by CPC. - 1. Voting members are responsible for approving funds for budgets delegated - to the project. - 1. Following and be up to date on Board/OpenJS Foundation initiatives and communicate them to the projects. - 1. Defining common practices to be implemented across OpenJS Foundation projects, if any. - 1. Mediating technical conflicts between OpenJS Foundation Projects when attempts to resolve - those conflicts within the Project were unsuccessful. - 1. Managing the process for creating a yearly budget and approving a yearly budget to be - presented to the board. - 1. The CPC serves as the OpenJS Foundation's primary technical - liaison body with external open source projects, consortiums and groups and is - also responsible for ensuring that the OpenJS Foundation has appropriate technical - participation in standards bodies by finding an encouraging members from - individual projects to participate in these bodies. - 1. Managing the Individual membership program. - 1. Managing programs to improve inclusivity and diversity. - 1. Guiding projects into appropriate Foundation paths. - 1. Shared resources, tooling and funding for projects and Commons.js (Events - Collaborator Summit, Travel fund). - 1. Supporting projects in their enforcement of Code of Conduct - violations and escalation. - 1. Developing a framework for community end-user feedback. - 1. Managing programs to offer mentorship to external individuals. - 1. Managing developer outreach programs. - 1. Supporting project advocacy and recognition programs. - 1. Identifying, recruiting and engaging prospective projects. - 1. Voting members are responsible for making a final decision if consensus - cannot be reached among members. - 1. Members of the CPC, or committees consisting of subsets of the CPC - membership will be expected to meet on a regular basis to discuss topics - such as new project acceptance into the mentorship program, project graduation - from the mentorship program, Project issues and conflicts, opportunities - for collaboration between Projects, opportunities for the Foundation in the - greater JavaScript community, etc. - - -## Section 6. Non-Responsibilities of the CPC - -OpenJS Foundation Projects are self-governing entities. All policies and procedures for interacting with, contributing to and making decisions within a Project are defined, implemented, and documented by that Project’s maintainers and community during the mentorship process. Specific technical decisions within a Project will be the responsibility of the Project and establishment and implementation of the decision making process will be done within the guidelines as defined by CPC charter. Those Project decisions and responsibilities include but are not limited to: - -* Setting release dates. -* Release quality standards. -* Technical direction. -* Project governance and process. -* GitHub repository hosting. -* Conduct guidelines. -* Maintaining the list of additional Collaborators. -* Development process and any coding standards. -* Mediating technical conflicts between Collaborators. - - -Notwithstanding the above, the Projects and the entire technical community will follow any processes -as may be specified by the Board relating to the intake and license compliance review of contributions, -including the OpenJS Foundation IP Policy. - -## Section 7. Elections - -Leadership roles in OpenJS Foundation will be peer-elected -representatives of the community. - -For election of persons (such as the CPC Chairperson), a multiple-candidate -method should be used, such as: - -* [Condorcet][] or -* [Single Transferable Vote][] - -Multiple-candidate methods may be reduced to simple election by plurality -when there are only two candidates for one position to be filled. No -election is required if there is only one candidate and no objections to -the candidates election. Elections shall be done within the Projects by -the Collaborators active in the Project. - - -The CPC will elect from amongst voting CPC members a CPC Chairperson to -work on building an agenda for CPC meetings and a CPC Director to represent -the CPC to the Board for a term of one year according to the OpenJS Foundation’s -By-laws. The Chair and Director may be (but are not required to be) -the same person. The CPC shall hold annual elections to select a CPC -Chairperson and Director; there are no limits on the number of terms a -CPC Chairperson or Director may serve. - -## Section 8. Board Representation - -There are 3 Board seats earmarked for representation from the -OpenJS Foundation projects. The first of these board seats is filled by -the CPC Director as outlined in Section 7 on [Elections][] and is -always in place. - -The second board seat requires 2 Platinum board members to activate -and will be filled based on processes defined -by the CPC and approved by the Voting CPC members and then the Board. The -CPC members will review and either re-confirm or update the -processes once per year. - -For the first year after the formation of the OpenJS Foundation, the -processes for filling this seat will be as follows: - -* As a constellation member of the OpenJS Foundation, the Node.js project - will elect one Board representative from either the Technical Steering Committee (TSC) or - Community Committee (CommComm). The representative will be selected according to a process - defined by the TSC and CommComm. - -As described in the [Elections][] section a multiple candidate method -will be used for the voting for the first and second board members. - -The third board seat is earmarked to represent the Individual membership -program. 3 Platinum board members as well as 2000 members registered in the -Individual membership program are required for it to activate. -Candidates for the Individual Membership Director are to be nominated by voting -members of the top-level committees of all projects and the voting CPC members. -Active members of the Individual Membership program would then vote on the -candidate of their choosing via an election system set by the CPC. - -## Section 9. Decision Making - -For internal Project decisions, Collaborators shall operate under Lazy -Consensus. The CPC follows a [Consensus Seeking][] 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 consensus. - -If an agenda item cannot reach a consensus a CPC member can call for either a -closing vote or a vote to table the issue to the next meeting. Votes shall -follow the procedure described in the [Voting][] section of this charter. - -## Section 10. Voting - -The CPC follows a [Consensus Seeking][] 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 consensus. - -If an agenda item cannot reach a consensus a CPC member can call for -either a closing vote or a vote to table the issue to the next meeting. -The call for a vote must be seconded by a majority of the CPC or else the -discussion will continue. - -For all votes, a simple majority of all Voting CPC members for, or against, the issue -wins. A Voting CPC member may choose to participate in any vote through abstention. - -Note that, in addition to requiring a simple majority vote of the CPC Voting -CPC members, all changes to this charter are also subject to approval -from the OpenJS Foundation board. - -## Section 11. Definitions - -**Project**: a technical collaboration effort that is organized through the -project mentorship process and approved by the TAC. - -**Contributors**: contribute code or other artifacts, but do not have the right -to commit to the code base. Contributors work with the Project's Collaborators -to have code committed to the code base. A Contributor may be promoted to a -Collaborator by the Project's Maintainers. Contributors should rarely be -encumbered by the TAC or Board. - -**Collaborator**: a Contributor within a Project that has made significant and -valuable contributions and has been given commit-access to that Project -repository. - -**Maintainer**: a Collaborator within a Project elected to represent the Project -in an official decision making role as defined in the Project's governance -policies. - -[Foundation bylaws]: https://bylaws.openjsf.org -[Voting]: #section-10.-voting -[Elections]: #section-7.-elections -[Consensus Seeking]: http://en.wikipedia.org/wiki/Consensus-seeking_decision-making -[Condorcet]: http://en.wikipedia.org/wiki/Condorcet_method -[Single Transferable Vote]: http://en.wikipedia.org/wiki/Single_transferable_vote - - diff --git a/proposals/approved/CPC_CHARTER/README.md b/proposals/approved/CPC_CHARTER/README.md deleted file mode 100644 index ade5de2a5..000000000 --- a/proposals/approved/CPC_CHARTER/README.md +++ /dev/null @@ -1,39 +0,0 @@ -# CPC Charter Proposal -> Approved - -## Champion - -Michael Dawson (@mhdawson) - -## Description - -This document captures a proposed charter for the CPC -(or equivalent) using the Node.js TSC, JSF TAC and -CNCF TOC charters as a starting points. - -## Required resources - -Discussion/approval by bootstrap committee - -## Who would be responsible? - -In current proposals for the groups within a merged -foundation, the CPC would be responsible for defining -and updating its charter. - -## How would success be measured? - -Success is approval of the document as the Charter for -the CPC or its use as the basis for the document that -captures the charter for the CPC (or equivalent) in the -merged foundation. - -## Why this proposal is important - -We need to better understand the charter for the CPC -to validate the structure being proposed for the merged -foundation. - -## Archive of initial charter - -[./CPC-CHARTER](./CPC-CHARTER.md) diff --git a/proposals/approved/EXPECTATIONS/EXPECTATIONS.md b/proposals/approved/EXPECTATIONS/EXPECTATIONS.md deleted file mode 100644 index 301da76a5..000000000 --- a/proposals/approved/EXPECTATIONS/EXPECTATIONS.md +++ /dev/null @@ -1,153 +0,0 @@ -# Expectations - -With the intent to merge the Node.js Foundation and JS Foundation being announced, those interested in the continued support of Node.js and JS-related projects are working through expectations and structure for what the potential new foundation could look like. - -This document is for the initial phase of work for the Bootstrap team to draft requirements that overlap with scope of the Board in order to provide an outline and structure for the foundation attuned to the needs of the projects and ecosystem stakeholders who have participated. - -This document is organized by two key areas: concerns that must be included in the foundation bylaws, and those that are communicated expectations that aren't required to be in our legal documents to proceed but are vital to managing expectations of project members and ecosystem stakeholders. - -## Bylaws requirements -- Communicated scope for the foundation and board -- Annual reviews of staff, NPS, board, programs, support services to projects for accountability and incremental improvement -- The foundation staff, executive director, and board should follow a leadership style that prioritizes and promotes the well-being of the project and those who prioritize and promote a healthy project and ecosystem. -- Project representation on the Board where the broader and longer-term issues important to the success of the overall JavaScript ecosystem can discussed, championed and supported - - Community Representation should sit on the Board directly. Projects could share this representation. - - Community representation on the Board: 3 seats guaranteed for community representation -- Board must establish Cross Project Council focused on the specific needs of the member projects - - Allow projects to self-organize amongst themselves. Processes are defined and driven by project e.g. CPC is not structured by the Board -- Non-corporate member representation in budget/finance subcommittee -- Creation of the budget and oversight/approval of the spending of that budget against the allocation can be delegated to collaborators in the project. -- Projects values should drive foundation focus and priority -- No "pay to play" in technical participation -- Earmarking allowed with flexibility in budgeting for concerns and needs of individual projects -- Value satisfaction: regular feedback from projects -- Explicit acknowledgement and documention for the ability of projects to leave the foundation -- Foundation should document a clear process for trademark usage to enable community not-for-profit efforts -- Communicated scope for the foundation and board - - Annual reviews of staff, NPS, board, programs, support services to projects for accountability and incremental improvement - - The Foundation staff, executive director, and board should follow a "servant leadership" style. - - Non-corporate member representation in budget / finance subcommittee - - Projects values should drive foundation focus and priority - - Earmarking allowed with flexibility in budgeting for concerns and needs of individual projects - - Value satisfaction: regular feedback from projects -- Executive Director required to work directly with projects to gather strategy and budget needs for upcoming roadmaps including but not limited to: - - Brand management per Project - - Budget Allocation per Project - - Resource Allocation per Project - -## Communicated expectations - -### Expectations of the Foundation -- Protect Intellectual Property (IP) including trademarks - - Enable the project communities to use the trademarks - - Educate members, new and old, about proper use of the projects' IP - -- Provide Legal Advice and Legal Best Practices - - Provide legal resources and representation that support the needs of the project - - Create a well-defined communications path for project legal needs within a 3-6 month timeframe - -- Software / Hardware resource facilitation (for use by the project) - - Examples: - - OKTA Identity Service for Individual Membership - - Headless CMS for website - - Translation and Internationalization Platform - - Have asked for approval to buy mac minis…. - -- Provide Ongoing Supporting Personnel to help manage community and technical efforts - - Examples: - - Community Manager - - Education Manager - -- Provide a pathway for community personnel requests for resources including but not limited to Employee, Contractor, Committed Volunteer, and Outsourced roles - - Examples: - - Designer for a project website - - Site Reliability Engineer (SRE) to monitor uptime and service quality of Build, Website, and Automation Infrastructure - -- Grow Foundation Membership and Expand the Network of folks engaged with the projects (and facilitate contribution from the Members to the projects) - - Provide compelling membership value propositions - - Recruit new members - - Enable members to meet regularly - -- Foundation representatives should regularly attend top-level meetings - - When needed, the Executive Director will work with the top-level committees to ensure their role as a liaison is fulfilled. - -- Engage members of the top-level committees inside of Foundation functions, like the Marketing Committee, Legal Committee, and Events meetings. -- Increase the adoption of projects across individuals and companies by - - Promoting initiatives by the top-level committees - - Financing initiatives (as per some agreed level of priority) that have this objective. This is related to community personnel requests outlined earlier - -### Expectations of the Board - -- Maintain a transparent process in financial management of the foundation -- Responsible execution of fiscal duties to maintain and grow the foundation -- Hire an Executive Director who can execute on the expectations of the projects -- Regularly review the performance of the Executive Director -- Review foundation performance with top-level project leadership quarterly -- Collaborate with representatives of the foundation on a yearly basis for accountability, multi-year strategy planning, and reviewing goal achievement -- Annual board meetup with members from top-level committee membership - -### Expectations of the Executive Director - -- Be an engaged participant of a/the projects' ecosystems while having guidelines around what activity is appropriate while wearing the hat of ED vs. contributor. -- Represent the projects through active participation with project members -- Fundraising to ensure solvency and sufficient budget to accommodate the growing needs of the projects -- Manage diplomacy between member companies and the foundation -- Maintain context of vital work of the project for application in representing the foundation and informed decision-making -- Employee hiring and management of functional roles contributing to the foundation administrative work. Examples: - - Community needs - - Certification - - Project community representation at events -- Bring in resources to contribute to the working groups and initiatives. -- Timely communication of Board activity and decisions to appropriate scope (public, top-level committees, and so on) -- A public face of Node.js Foundation. Activities might include, but would not be limited to, some or all of: - - representing the voice of foundation at conferences through keynotes, panels, and talks - - writing blog posts - - providing regular updates to the project and the community - - Regular communication/interlocks with the project committees. - - regulard Q&A with ecosystem - -### Mission Statement Drafts -Projects joining the foundation should collectively agree on a _single mission statement_ when joining the new Foundation. Below are a number of rough drafts put forward by attendees of the Governance breakout session(s) at our Node.js Collaborator Summit 2018 in Vancouver. - - > By providing structure and support to build and sustain community among open-source projects. - - > Growing and maintaining the global JavaScript system through open, equitable, and inclusive governance. - - > The Foundation is dedicated to the development and sustainability of the JavaScript ecosystem, through fostering the environment for growth of JavaScript related projects. - - > The Foundation envisions a future where JavaScript is a sustainable platform for implementing best in class experiences in production across all types of workloads. The $FOUNDATION is committed to being a catalyst across the industry making our technological communities productive, sustainable, equitable, diverse and inclusive. - -### Vision Statement Drafts -Projects joining the foundation should collectively agree on a _single vision statement_ when joining the new Foundation. Below are a number of recommendations put forward by attendees of the Governance breakout sessions at our Node.js Collaborator Summit 2018 in Vancouver. - - > Vision: To enable widespread adoption and help accelerate development of JavaScript and key ecosystem projects across connected devices, servers and networks, user agents and runtimes. The Foundation supports its hosted projects through open governance models and social structures that encourage community, skills growth, technical contribution, standards engagement, and inclusive participation. - -### Identified Values -The following values were identified in the governance brainstorming exercises during the October 2018 Collaborators Summit in Vancouver. We believe they can operate as guiding principles for Foundation efforts. - -#### Community Focus - - Promote Diversity, Inclusivity and Representation with a global perspective. - - Bring members together on a regular basis with equal accessibility - - Global Leadership - - Be less US / North American centric – engage worldwide - - Value moral values - -#### Project Driven - - Projects make all technical decisions - - Make projects the priority - - Value project input for all decisions - - Ensure health of highly used / critical libraries - - Help champion new efforts - - Provide Recognition - - Ensure ability to leave - -#### Transparent Operation - - Open Governance - - Radical Collaboration - - Value data over opinions - - Guarantee the right to disagree - - Consensus seeking as a model for decision making - -#### Simple Structure - - By-laws general enough not to require evolution - - Simple, project-driven governance evolution diff --git a/proposals/approved/EXPECTATIONS/README.md b/proposals/approved/EXPECTATIONS/README.md deleted file mode 100644 index e292a4a56..000000000 --- a/proposals/approved/EXPECTATIONS/README.md +++ /dev/null @@ -1,28 +0,0 @@ -# Expectations -> approved - -## Champion - -Tracy Hinds (@hackygolucky) - -## Description - -This [EXPECTATIONS.md][] document is an outline of expectations from the projects of the Node.js and JS Foundations to communicate priorities that should be considered and converted into language for the Bylaws of the proposed merged foundation, where the scope of the Boards and projects overlap–in order to provide an outline and structure for the foundation attuned to the needs of the projects and ecosystem stakeholders who have participated. - -## Required Resources - -Approval of the bootstrap team and collaboration with Directors of the Boards on each foundation. - -## Who would be responsible? - -The bootstrap committee to finalize for consideration of the Boards and Legal. - -## Why this proposal is important - -The needs of the projects and ecosystem stakeholders being voiced through the governance of the foundation for which they are represented is vital for the foundation to succeed. - -## What is necessary to approve this proposal - -The Boards and Legal would review this proposal and Legal would then draft the expectations as language that would be folded into the Bylaws to be developed for the proposed foundation. - -[EXPECTATIONS.md]: ./EXPECTATIONS.md diff --git a/proposals/approved/GOVERNANCE/GOVERNANCE.md b/proposals/approved/GOVERNANCE/GOVERNANCE.md deleted file mode 100644 index 71169a9c0..000000000 --- a/proposals/approved/GOVERNANCE/GOVERNANCE.md +++ /dev/null @@ -1,76 +0,0 @@ -# Joint Foundation Bootstrap Team - -For the current list of Team members, see the project -[README.md](./README.md). - -## Members - -The [nodejs/bootstrap](https://github.com/nodejs/bootstrap) GitHub -repository is maintained by the Team and additional Members who are -added on an ongoing basis. - -## Team Membership - -Team Membership is not time-limited. There is no fixed size of the Team. - -There is no specific set of requirements or qualifications for Team Membership beyond these rules. - -The following groups automatically have membership and can request to be added to the github team: - -* Node.js Members: @nodejs/members -* JSF Project Maintainers -* JSF TAC -* Node.js Foundation Board of Directors -* JSF Board of Directors - -## Team Meetings - -The Team meets weekly on Zoom.us. A designated moderator -approved by the Team runs the meeting. Each meeting should be -published to YouTube. - -Items are added to the Team agenda that are considered contentious or -are modifications of governance, contribution policy, Team membership, -or release process. - -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, -Team member or the moderator can add the item to the agenda by adding -the ***bootstrap-agenda*** tag to the issue. - -Prior to each Team meeting the moderator will share the agenda with -members of the Team. Team members can add any items they like to the -agenda at the beginning of each meeting. The moderator and the Team -cannot veto or remove items. - -The moderator is responsible for summarizing the discussion of each -agenda item and sends it as a pull request after the meeting. - -## Consensus Seeking Process - -The Team 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 -consensus. - -If an agenda item cannot reach a consensus, a Team member can call for -the item to be decided by a vote or to table the issue to the next -meeting. In both cases the decision must be seconded by a majority of the Team -or else the discussion will continue. Simple majority wins. Only Active -Members participate in a vote. - -## Merging PRs into this Repository - -This section does not apply to [the Node.js core repository](https://github.com/nodejs/node). -It only applies to [the bootstrap repository](https://github.com/nodejs/bootstrap). - -Pull requests must have no objections and have been open for at least 72 hours -in order to be merged into this repository. A pull request that is unable to -reach consensus cannot be merged into this repository. diff --git a/proposals/approved/GOVERNANCE/README.md b/proposals/approved/GOVERNANCE/README.md deleted file mode 100644 index 35cc9d936..000000000 --- a/proposals/approved/GOVERNANCE/README.md +++ /dev/null @@ -1,29 +0,0 @@ -# Initial Governance Model -> approved - -## Champion - -Myles Borins (@Myles Borins) - -## Description - -This [GOVERNANCE.md][] document is a basic outline of the governance model for the bootstrap team. It outline how membership is defined and how we will collaborate. - -## Required Resources - -Approval of the bootstrap team. - -## Who would be responsible? - -The bootstrap committee - -## Why this proposal is important - -We need basic governance to operate - -## What is necessary to approve this proposal - -As this proposal does not need to be approved by either board and doesn't have any budgetary or legal requriements I believe -that we can move immediately from Stage 2 to Stage 3 at the same time. (Note: based on old proposal process) - -[GOVERNANCE.md]: ./GOVERNANCE.md diff --git a/proposals/approved/INDIVIDUAL_MEMBERSHIP/INDIVIDUAL_MEMBERSHIP.md b/proposals/approved/INDIVIDUAL_MEMBERSHIP/INDIVIDUAL_MEMBERSHIP.md deleted file mode 100644 index e3208b062..000000000 --- a/proposals/approved/INDIVIDUAL_MEMBERSHIP/INDIVIDUAL_MEMBERSHIP.md +++ /dev/null @@ -1,5 +0,0 @@ -# Individual Membership - -## JavaScriptLandia - -JavaScriptLandia serves as the individual membership program for the Foundation. Details on the program, benefits, cost, and required resources can be found in the [JavaScriptLandia program description](/proposals/approved/SUPPORTER_PROGRAM/SUPPORTER_PROGRAM.md). diff --git a/proposals/approved/INDIVIDUAL_MEMBERSHIP/README.md b/proposals/approved/INDIVIDUAL_MEMBERSHIP/README.md deleted file mode 100644 index 16f68a5b9..000000000 --- a/proposals/approved/INDIVIDUAL_MEMBERSHIP/README.md +++ /dev/null @@ -1,43 +0,0 @@ -# Individual Membership Program -> approved - -### Champion -[Tracy Hinds](https://github.com/hackygolucky) - -### Description - -The projects of the OpenJS Foundation, hereinafter referred to as the "Foundation", should strive to feel more engaging and welcoming. The Individual Membership program brings together Foundation projects contributors and users – who are not current contributors – through increased participation, solicited input, and first access to some Foundation provided benefits. This program codifies a relationship with our ecosystem, and provides an opportunity for the Foundation, and member companies, to connect with engaged community members through systematic communication building. - -### Required Resources - -What resources would be needed to execute it? - -- Administrator for elections, tooling, and communications coordination for membership -- Tooling: membership management system and election system - -### Who would be responsible? - -The CPC would own the maintenance and sustainability of the programs with power to delegate, and would be aided by the Executive group with resources of the Foundation to execute. - -### How would success be measured? - -Given the goals outlined in this proposal, - -- NPS score improves by 10% after base is established - - With the introduction of better feedback mechanisms, we should be able to move some detractors to passives, and some passives to promoters. -- Relaunch of program results in at least a 2X growth in active membership roster in first year of program. - -### Why this proposal is important - -With the historical data we have regarding individual membership in Node.js, if Board Directors wish for the Individual Membership to be representative of the larger umbrella projects engaged ecosystem, we know that the number of members prior and the number of members who voted was not statistically significant nor representative. The Individual Membership did not have a clear path, role, or definition and all three are required in order to set the program up for success and provide proper service to these member programs. - -*The goals of the proposed program include:* - -- To give a voice and direction to a larger and different group than core collaborators of projects. To feel bought into the Foundation. -- To have a visible association with the foundation -- They see direct benefit through the swag, resources, etc. - -*How does this program achieve this?* - -- Provides the interested but not yet fully engaged members the path to engagement and voice -- Operationalizes programs that focus on folks who are more engaged and interested in giving and getting feedback outside of the collaborator base on the project and foundation work through guaranteed communications, surveys, better evangelists prepared with exclusive information ahead of the world to provide this value. diff --git a/proposals/approved/PROJECT_ONBOARDING/NEW_PROJECT_APPLICATION.md b/proposals/approved/PROJECT_ONBOARDING/NEW_PROJECT_APPLICATION.md deleted file mode 100644 index 36693d290..000000000 --- a/proposals/approved/PROJECT_ONBOARDING/NEW_PROJECT_APPLICATION.md +++ /dev/null @@ -1,87 +0,0 @@ -# ${Project Name} - -## Project Champion - -Who is the main point of contact during the application process? - -## Description - -A rough description of the project in less than 100 words. - -## Statement of alignment with OpenJS Foundation charter and mission - -Please refer to [the Cross Project Council's Charter](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/CPC-CHARTER.md). -Please keep your answer to less than 250 words. - -## List of all repos that are part of the project - -For each repository, please provide: - -- link to repo, -- license information, -- link to issue tracker, -- link to code of conduct (CoC), -- optionally, the full list of vendored dependencies contained in the source tree, including license information. A full audit - of all vendored dependencies will be required before your project can officially join the foundation, but this can be done - later with foundation support. - -## Governance Structure - -* Is there a leadership team? -* Who are the members of the leadership team? -* How are members of the leadership team nominated? -* How are individuals outside of leadership given commit access? -* Please share links to all existing documentation e.g. GOVERNANCE.md / CONTRIBUTING.md - -## Desired Initial Project Phase - -Please refer to [Section III, Stages - Definitions & Expectations](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/PROJECT_PROGRESSION.md#iii-stages---definitions--expectations) of PROJECT_PROGRESSION.md. - -At Large / Growth / Impact - -## Official Communication Channels - -List current channels e.g.: Slack / IRC / Mailing lists - -## Project Website - -Include link - -## Social Media Accounts - -Links to social media accounts - -## Existing Financial Sponsorship - -Does your project currently receive funds? Who do they come from and what are the funds used for? - -## Infrastructure Needs or Requests - -What needs will your project have from the foundation? Feel free to provide a list. - -## Onboarding Checklist - -This is an informational checklist to help projects onboard into the OpenJS Foundation - tasks we will complete together after your project has been accepted into the incubation process. If you have any questions or need help, the OpenJS Foundation CPC is available to assist. - -- [ ] Adopt the OpenJS Foundation Code of Conduct -- [ ] Update project CoC reporting methods to include OpenJS Foundation escalation path -- [ ] Transfer official domains to OpenJS Foundation -- [ ] Identify and document other core project infrastructure -- [ ] If choosing to use a Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO), make selection and implement appropriate tool -- [ ] Add or Update Governance.md document (required for Impact stage) -- [ ] Confirm required files in place (CODE_OF_CONDUCT.md, LICENSE.md) -- [ ] Project Charter is published on website or github -- [ ] Update legal copyright notice on project website and github -- [ ] Add OpenJS Foundation logo to project website -- [ ] Add Project logo to OpenJS Foundation website; update PROJECTS.md file -- [ ] Transfer logomark to the OpenJS Foundation -- [ ] If project is using crowdfunding platforms, add disclaimer to platforms -- [ ] Identify individuals from the project to join the CPC -- [ ] Document project and foundation contacts for: - * marketing & social media - * infrastructure - * legal/governance help - -## Questions? - -What questions do you have? What questions might arise during your application? diff --git a/proposals/approved/PROJECT_ONBOARDING/README.md b/proposals/approved/PROJECT_ONBOARDING/README.md deleted file mode 100644 index 5fd0c90c0..000000000 --- a/proposals/approved/PROJECT_ONBOARDING/README.md +++ /dev/null @@ -1,54 +0,0 @@ -# Project Onboarding Checklist Proposal -> approved - -## Champion - -Jory Burson (@jorydotcom), Michael Dawson (@mhdawson), & Myles Borins (@MylesBorins) - -## Description - -This proposal codifies the process for new projects applying to join the foundation. It includes a project application template and a checklist to be used to onboard projects as part of being accepted into the OpenJS Foundation. - -## Required Resources - -* General support from the CPC - - Keep track of applying projects - - Ongoing communication with applying projects - - Mentoring projects as they onboard -* General support from the CPC Director - - Updates to Board of Directors of OpenJS Foundation -* Project Management support from OpenJS Foundation. - - Keep track of applying projects - - Ongoing communication with project - -## Who would be responsible? - -This document would belong to the CPC to update and use moving forward. Large changes may require board approval. - -## How would success be measured? - -Initially we should measure this document's success by how well it helps us onboard our current projects into the new Foundation system. We expect that it might also be successfully used to help would-be foundation projects understand what to expect after joining. - -## Why this proposal is important - -We need to share a workflow and understanding of what steps are required to bring in projects to the OpenJS Foundation. This process is an attempt to organize our ideas and our work to make that happen effectively. This process should be explicit and consistent to make applications fair for all projects. - -## Things we plan to iterate on - -* Suggestion: group all the per-repo info we're looking for in one place (such as issue trackers, lists of committers, links to documentation such as Governance.md ) -* Clarification: to vendor dependencies include transitive dependencies as well? Also dev, prod dependencies or both? -* Suggestion: include a tool such as https://www.npmjs.com/package/license-checker for grabbing dependency info -* Suggestion: clarify the purpose of the request for list of committers (for staging purposes) and what measurements are to be used. -* Clarification: what kind of information do we want to gather on a 'whole project' vs. 'per repo' basis bearing in mind there may be some variability across some project repositories. - - -## What is necessary to complete this proposal - -Agreement on the initial checklist items; interim owners/helpers for each of the tasks. - -- [x] [Template for Project Applications](./NEW_PROJECT_APPLICATION.md) -- [x] [Onboarding Check List](./NEW_PROJECT_APPLICATION.md#onboarding-checklist) -- [x] [Update to Project Progression](https://github.com/openjs-foundation/cross-project-council/pull/165) -- [x] Discussion/approval by the Cross Project Council -- [ ] Discussion/approval by the Board -- [x] Adoption by the CPC diff --git a/proposals/approved/PROJECT_PROGRESSION/PROJECT_PROGRESSION.md b/proposals/approved/PROJECT_PROGRESSION/PROJECT_PROGRESSION.md deleted file mode 100644 index 282fe6c72..000000000 --- a/proposals/approved/PROJECT_PROGRESSION/PROJECT_PROGRESSION.md +++ /dev/null @@ -1,157 +0,0 @@ -## I. Overview -This governance policy describes how an open source project can formally join the OpenJS Foundation, hereinafter referred to as the "Foundation", via the [Project Proposal Process](). It describes the [Stages]() a project may be admitted under and what the criteria and expectations are for a given stage, as well as the acceptance criteria for a project to move from one stage to another. It also describes the [Annual Review Process]() through which those changes will be evaluated and made. - -Project progression - movement from one stage to another - allows projects to particpate at the level that is most appropriate for them given where they are in their lifecycle. Regardless of stage, all Foundation projects benefit from a deepened alignment with existing projects, and access to mentorship, support, and foundation resources such as the travel fund. - -For more information about how your project can benefit from Foundation membership and services, please see [TBD Document](). - -This proposal has been modified from the [CNCF process documentation](https://github.com/cncf/toc/tree/HEAD/process). - -## II. Project Proposal Process - -### Introduction -This governance policy sets forth the proposal process for projects to be accepted into the Foundation. The process is the same for both existing projects which seek to move into the Foundation, and new projects to be formed within the Foundation. - -### Project Proposal Requirements -Projects must be proposed via GitHub. Project proposals submitted to the Foundation must provide the following information to the best of their ability: - -* name of project -* project description (what it does, why it is valuable, origin and history) -* statement on alignment with Foundation charter mission -* link to *current* Code of Conduct -* sponsor from CPC, if identified (a sponsor helps mentor projects) -* project license -* source control (GitHub by default) -* issue tracker (GitHub by default) -* external dependencies (including licenses) -* release methodology and mechanics -* names of initial committers, if different from those submitting proposal -* briefly describe the project's leadership team and decision-making process -* preferred maturity level (see stages below) -* list of project's official communication channels (slack, irc, mailing lists) -* link to project's website -* links to social media accounts -* existing financial sponsorship -* infrastructure needs or requests - -### Project Acceptance Process -* Projects are required to present their proposal at a CPC meeting -* The CPC may ask for changes to bring the project into better alignment with the Foundation (adding a governance document to a repository or adopting a more stringent Code of Conduct, for example). - * The project will need to make these changes in order to progress further. -* Projects get accepted via a 2/3 supermajority vote of the CPC. -* The proposal document will be finalized as a project charter. This charter document must be included in the project's main repository. -* The CPC will determine the appropriate initial stage for the project. The project can apply for a different stage via the review process. - -## III. Stages - Definitions & Expectations -Every Foundation project has an associated maturity level. Proposed Foundation projects should state their preferred maturity level. Projects of all maturities have access to Foundation resources. - -All Foundation projects may attend CPC meetings and contribute work regardless of their stage. - -*note: all stage names are tbd pending outcome of [#44](https://github.com/nodejs/bootstrap/issues/44#issuecomment-440026298)* - -### At Large Projects (formerly 'Sandbox') -**Definition** - -At Large projects are projects which the CPC believes are, or have the potential to be, important to the ecosystem of Top-Level Projects or the JS ecosystem as a whole. They may be early-stage projects just getting started, or they may be long-established projects with minimal resource needs. The At Large stage provides a beneficial, neutral home for these projects in order to foster collaborative development and provide a path to deeper alignment with other Foundation projects via the graduation process. - -**Examples** - -1. New projects that are designed to extend one or more Foundation projects with functionality or interoperability libraries. -1. Independent projects that fit the Foundation mission and provide potential for a novel approach to existing functional areas (or are an attempt to meet an unfulfilled need). -1. Projects commissioned or sanctioned by the Foundation. -1. Any project that realistically intends to join the Foundation Incubation or Top Level Stages in the future and wishes to lay the foundations for that transition. - -**Expectations** - -End users should evaluate At Large projects with care, as this stage does not set requirements for community size, governance, or production readiness. At Large projects will receive minimal marketing support from the Foundation. Projects will be reviewed on an annual basis; they may also request a status review by submitting a report to the CPC. - -**Acceptance Criteria** - -To be considered for the At Large Stage, the project must meet the following requirements: -* 2 CPC sponsors to champion the project & provide mentorship as needed -* A presentation to at the meeting of the CPC -* Adherence to the Foundation IP Policy -* Upon acceptance, At Large projects must list their status prominently on website/readme - -### Growth Stage (formerly 'Incubating') -**Definition** - -The Growth Stage is for projects that are interested in reaching the Impact Stage, and have identified a growth plan for doing so. Growth Stage projects will receive mentorship from the CPC and are expected to actively develop their community of contributors, governance, project documentation, and other variables identified in the growth plan that factor in to broad success and adoption. - -In order to support their active development, projects in the Growth stage have a higher level of access to marketing and other resources, which will be agreed upon and reviewed on a yearly basis. A project's progress toward its growth plan goals will be reviewed on a yearly basis, and the CPC may ask the project to move to the At Large stage if progress on the plan drops off or stalls. - -**Examples** - -1. Projects that are on their way or very likely to become Top Level Projects. -1. Projects that have developed new growth targets or other community metrics for success. -1. Projects that are looking to create a lifecycle plan (maintainership succession, contributor programs, version planning, etc.) -1. Projects that need more active support from the Foundation in the form of marketing or CPC mentorship in order to reach their goals. - -**Expectations** - -Projects in the Growth Stage are generally expected to move out of the Growth stage within two years. Depending on their growth plans, projects may cycle through At Large, Growth, or Impact stage as needed. - -**Acceptance Criteria** - -To be considered for Growth Stage, the project must meet the At Large requirements as well as the following: - - * Development of a growth plan, to be done in conjunction with their project mentor(s) at the CPC. - * Document that it is being used successfully in production by at least two independent end users which, in the CPC’s judgement, are of adequate quality and scope. - * Demonstrate a substantial ongoing flow of commits and merged contributions. - * Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan. - * Since these metrics can vary significantly depending on the type, scope and size of a project, the CPC has final judgement over the level of activity that is adequate to meet these criteria. - * Receive a two-thirds supermajority vote of the CPC to move to Growth Stage. - -### Impact Stage (formerly 'Top-Level') -**Definition** - -The Impact Stage is for projects that have reached their growth goals and are now on a sustaining cycle of development, maintainence, and long-term support. Impact Stage projects are used commonly in enterprise production environments and have large, well-established project communities. - -**Examples** - -1. Projects that have publicly documented release cycles and plans for LTS. -1. Projects that have themselves become platforms for other projects. -1. Projects that are able to attract a healthy number of committers on the basis of its production usefulness (not simply 'developer popularity'). -1. Projects that have several, high-profile or well known end-user implementations. - -**Expectations** - -Impact Stage projects are expected to participate actively in CPC proceedings, and as such have a binding vote on CPC matters requiring a formal vote, such as the election of a CPC Director. They receive ongoing financial and marketing support from the Foundation, and are expected to cross promote the foundation along with their activities. - -**Acceptance Criteria** - -To graduate from At Large or Growth status, or for a new project to join as an Impact project, a project must meet the Growth stage criteria plus: - - * Have a defined governing body of at least 5 or more members (owners and core maintainers), of which no more than 1/3 is affiliated with the same employer. In the case there are 5 governing members, 2 may be from the same employer. - * Have a documented and publicly accessible description of the project's governance, decision-making, and release processes. - * Have a healthy number of committers from at least two organizations. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project. - * Adopt the Foundation Code of Conduct. - * Explicitly define a project governance and committer process. This is preferably laid out in a GOVERNANCE.md file and references a CONTRIBUTING.md and OWNERS.md file showing the current and emeritus committers. - * Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website). - * Other metrics as defined by the applying Project during the application process in cooperation with the CPC. - * Receive a supermajority vote from the CPC to move to Impact stage. Projects can move directly from At Large to Impact, if they can demonstrate sufficient maturity and have met all requirements. - - -### Emeritus Stage -**Definition** - -Emeritus projects are projects which the maintainers feel have reached or are nearing end-of-life. Emeritus projects have contributed to the ecosystem, but are not necessarily recommended for modern development as there may be more actively maintained choices. The Foundation appreciates the contributions of these projects and their communities, and the role they have played in moving the ecosystem forward. - -**Examples** - -1. Projects that are "complete" by the maintainers' standards. -1. Projects that do not plan to release major versions in the future. - -**Expectations** - -Projects in this stage are not in active development. Their maintainers may infrequently monitor their repositories, and may only push updates to address security issues, if at all. Emeritus projects should clearly state their status and what any user or contributor should expect in terms of response or support. If there is an alternative project the maintainers recommend, it should be listed as well. The foundation will continue to hold the IP and any trademarks and domains, but the project does not draw on foundation resources. - -**Acceptance Criteria** - -Projects may be granted Emeritus status via a 2/3 vote from the CPC and with approval from project ownership. In cases where there is a lack of project ownership, only a 2/3 vote from the CPC is required. - - -## IV. Annual Review Process - -The CPC shall develop an annual review process to determine whether projects are in the stage that accurately reflects their needs and goals. - diff --git a/proposals/approved/PROJECT_PROGRESSION/README.md b/proposals/approved/PROJECT_PROGRESSION/README.md deleted file mode 100644 index 4d03b711b..000000000 --- a/proposals/approved/PROJECT_PROGRESSION/README.md +++ /dev/null @@ -1,26 +0,0 @@ -# Project Progression Proposal -> Stage 3 - -## Champion - -Jory Burson (@jorydotcom) - -## Description - -The [PROJECT_PROGRESSION.md][] document describes the process and criteria for any project to join the foundation and 'graduate' to a 'Top Level Project.' This proposal incorporates ideas from the CNCF, the JSF, and the [Community Drafting Doc](https://docs.google.com/presentation/d/1qUcvZz4wmQtwcWu9rWjxFNmWw5plD9-4_7mtvQvCegk/edit#slide=id.g45c3106792_4_115). - -Note that this document will utilize the naming conventions that are to be determined in [#44](https://github.com/nodejs/bootstrap/issues/44#issuecomment-440026298). - -## Required Resources - -Approval of the bootstrap team. - -## Who would be responsible? - -In the merged organization, the CPC would be responsible for shepherding this process. In the interim, I believe the Bootstrap team and respective boards. - -## Why this proposal is important - -Existing projects need to know what their "status" will be in the new organization. Potential projects need to know what the criteria and requirements are of Foundation projects. - -[PROJECT_PROGRESSION.md]: ./PROJECT_PROGRESSION.md diff --git a/proposals/approved/SECURITY_REPORTING/README.md b/proposals/approved/SECURITY_REPORTING/README.md deleted file mode 100644 index ff5069822..000000000 --- a/proposals/approved/SECURITY_REPORTING/README.md +++ /dev/null @@ -1,65 +0,0 @@ -# Security Reporting for OpenJS Foundation Projects -> approved - -## Champion - -Marcin Hoppe (@marcin_hoppe) - -## Description - -Currently OpenJS Foundation projects do not have consistently documented standards for responsible reporting and disclosure of security vulnerabilities. This proposal aligns OpenJS Foundation projects with industry best practices in this space. - -See also: -- [Security reporting in OpenJS Foundation projects](https://gist.github.com/MarcinHoppe/b13a870770522c31a8386ada48b2e40f) -- [Guidelines for responsible reporting and disclosure of security vulnerabilities](https://github.com/nodejs/package-maintenance/blob/HEAD/docs/security-guidelines.md) - -## Required Resources - -- Generic security policy template that projects can easily adopt -- Vulnerability handling playbook for project maintainers -- Optionally: vulnerability disclosure platform (VDP) - -## Who would be responsible? - -The responsibility for adoption of security reporting standards would be owned by the projects. The CPC would be responsible for providing guidance and necessary shared resources. - -## How would success be measured? - -- 100% of Impact, Growth, and more than 50% of At-Large projects have: - - Security policy on GitHub - - Vulnerability reporting mechanism (email or VDP) -- 100% of projects graduating from Incubation have a security policy on GitHub - -## Why this proposal is important - -Open source projects that can responsibly accept security reports and respond with a coordinated vulnerability disclosure have a higher chance of being treated as trustworthy by adopters. - -## Unresolved questions - -- Do we leave it to projects to coordinate disclosure? - - Some projects are already prepared, have infrastructure and processes in place. Others don't. -- Do we need to offer additional resources to projects? - - Vulnerability disclosure platform? - - Staff triage team? -- Do we need to have a coordinating body? - - Security working group at the Foundation level? -- How to coordinate with similar industry initiatives? - - Open Source Security Coalition (https://securitylab.github.com/) - - Node.js Ecosystem Security WG (https://github.com/nodejs/security-wg) - -## What is out of scope? - -- This proposal does not cover bug bounties - - The decision whether to offer bounties or not is left to individual projects - -## What is necessary to complete this proposal - -- [x] Input from projects on their commitment to accepting security reports -- [x] Providing projects with generic: - - Minimum requirements for security reporting: [PROJECT_SECURITY_REPORTING](../../../PROJECT_SECURITY_REPORTING.md) - - Security policy template - - Recommendation how to handle security reports -- [x] Updating CPC processes and documentation to include security reporting and disclosure in: - - Project onboarding - - Project progression -- [ ] Agreement on level of support the Foundation can offer to projects diff --git a/proposals/approved/SUPPORTER_PROGRAM/README.md b/proposals/approved/SUPPORTER_PROGRAM/README.md deleted file mode 100644 index 69dc2f912..000000000 --- a/proposals/approved/SUPPORTER_PROGRAM/README.md +++ /dev/null @@ -1,44 +0,0 @@ -# Individual Supporter Representation Proposal -Stage: Approved - -## Directory -* [Spec](SPEC.md) -* [Supporter Program Details](SUPPORTER_PROGRAM.md) - -## Champion - -[Sara Chipps](https://github.com/sarajo) - -## Description - -Supporter program for OpenJS individual supporters. - -## Who would be responsible? - -The CPC would own the maintenance and sustainability of the program with OpenJS Foundation staff support along with iterating on the program and ensuring the supporter needs are heard and accounted for. - -## How would success be measured? - -* Growth of the supporter list -* Quantifiable public advocacy from supporters for the OpenJS Foundation and projects -* An increase in contributors to projects from small to large -* More attendees at weekly CPC meetings, and additional CPC members - -## What is necessary to complete this proposal - -Approval of this proposal from project members of the NF and JSF, the Node.js Board of Directors, and the JSF Board of Directors - -## Open Questions - -* What should the income from the supporter program go towards? -* What should the landing page be like, can we give supporters "passports"? -* Should we auutomatically re-charge supporters at the end of a calendar year? - -## Timeline - -Our goal to roll out this program will be Q4, permitting everything goes smoothly. - - - - - diff --git a/proposals/approved/SUPPORTER_PROGRAM/SPEC.md b/proposals/approved/SUPPORTER_PROGRAM/SPEC.md deleted file mode 100644 index 6d847684c..000000000 --- a/proposals/approved/SUPPORTER_PROGRAM/SPEC.md +++ /dev/null @@ -1,58 +0,0 @@ -# JavaScriptLandia - Phase 1 - Spec -## October 2020 - -### Summary -JavaScriptLandia is a place where all JavaScript developers, whether if you're all about TypeScript, a React evangelist, or you stick to Node.js, gather to declare their support for the JavaScript ecosystem and OpenJS. - -### Phase 1 Components - -**Launch Announcement** - -This will be a blog post on the OpenJS Site -Developed in partnership with the content team at the LF/OpenJSF -We will determine the best date to post with the content team - -Design requirements: -* Image of a country with multiple JS Libraries -* Image will be created by LF/OpenJSF internal team, we also can source iterations of it on Twitter or Github - -**Website Changes** - -A signup page where supporters can become members and pay for their yearly membership. We plan to adopt the auto join functionality from the Linux Foundation. - -An automated workflow to add new supporters to monthly email -* Existing subscribers will not be removed -* They can request removal at any time -* Zapier or IFTT can work if no other solution - -A new platform for the weekly emails, and a designed template. - -A page to reflect current supporters on the website - -A swag store for supporters (turnkey) - -**A Logo and Badge** - -Inspirations and Suggestions: -* An anthropromorphic passport, with JS branding -* A little playful -* Binocs -* Fanny pack -* Tourguide flags -* Map -* Passport person is traveling to see everything, doesn’t have a destination -* Topography instead of countries -* Play on the passport is the digital badge - - -Logo Things to avoid: - -* Transportation mediums -* Anything that suggests nationalism/closed borders -* Anything that suggests a certain nationality or race -* Something too esoteric -* Maps or directions that get you to a certain destination - -### Open Questions - -Should the logo and badge be different? diff --git a/proposals/approved/SUPPORTER_PROGRAM/SUPPORTER_PROGRAM.md b/proposals/approved/SUPPORTER_PROGRAM/SUPPORTER_PROGRAM.md deleted file mode 100644 index 2834a9f6d..000000000 --- a/proposals/approved/SUPPORTER_PROGRAM/SUPPORTER_PROGRAM.md +++ /dev/null @@ -1,51 +0,0 @@ -## The People's Community of JavaScriptlandia - -JavaScriptLandia is a place where all JavaScript developers, whether if you're all about TypeScript, a React evangelist, or you stick to Node.js, gather to declare their support for the JavaScript ecosystem and OpenJS. - -It's an Individual Supporter Program whose goals are to help bring awareness about OpenJS projects to possible contributors. A way for individuals to show support and be a part of the OpenJS Foundation, as well as providing an opportunity for community with the other supporters. - -While one goal of this group is introducing supporter to projects and helping the projects find the support they need via new core commiters; the supporter program will also be an opportunity to welcome an inclusive group of coders from around the world that love the projects that are part of the OpenJS Foundation. This also brings in new perspectives and feedback from the vast community of JavaScript developers. - -We also want to grow awareness of OpenJS, our projects, and how to get involved. - -Additionally, being an Individual supporter should help people understand that their projects can also get support from the foundation, and that the OpenJS Foundation is their foundation. - -A tertiary goal is to establish a pool from which an ambassador program can be started. Recognizing people that advocate and recruit for OpenJS projects. - -## Supporter Benefits - -Citizens of JavaScriptlandia will receive a supporters' weekly newsletter keeping them up to date on the last from OpenJS projects, the CPC, and the board. They will be invited to participate in discussions about governance and new initiatives. - -They will be featured on our global supporter page, and will be given a digital passport that they can put on an avatar, their blog, and/or personal website. Their passport will feature the libaries that they use the most, and the ones that they are the are the biggest fans of. - -There will be a repository for supporters, and they will be able to display their badge proudly on their Github profile. Supporters can incubate projects in that repository (this should have discussion). - -Additionally, they will receive discounts for training, certification, conferences, and potentially exclusive offers from member organizations. - -Lastly, supporters will have access to the supporter store where they can purchase OpenJS supporter swag to show their support for our projects. Revenue from swag will go towards furthering the reach of the foundation. - - -## Supporter Cost - -OpenJS supporters are charged $25/year. Supporter status is renewed 1 year from the date of your initial support. Supporters can cancel at any time and not be charged for the next year. - -Supporters will be required to comply with the Code of Conduct, and may be subject to removal upon violation. - -## Required Resources - -What resources would be needed to execute it? -* Workflow to add new supporters to monthly email - * Existing subscribers will not be removed - * They can request removal at any time - * Optional additional email content, such as “What is the CPC and how can I get involved” can be set up via an email drip campaign for new supporters. -* Design - * JavaScriptlandia logo, passports, avatars, and swag -* Web - * A page to reflect current supporters on the website - * A swag store for supporters (turnkey) - * A sign up page for membership with a payment gateway that allows for subscriptions - * Possibly a page with a passport that you can add stamps to? -* Foundation - * Support for the members of the supporter program (questions, emails, updates) - * Ensuring that the supporter program is continually promoted and growing - * Help with running periodic satisfaction surveys (NPS or related) diff --git a/proposals/approved/TRAVEL_FUND/README.md b/proposals/approved/TRAVEL_FUND/README.md deleted file mode 100644 index 2a26d7c47..000000000 --- a/proposals/approved/TRAVEL_FUND/README.md +++ /dev/null @@ -1,70 +0,0 @@ -# OpenJS Travel Fund -> approved - -Tracked by https://github.com/openjs-foundation/cross-project-council/issues/172 - -## Champion - -Jonah Stiennon (@jonahss) - -## Description - -The Node.js organizations that existed prior to the formation of the OpenJS foundation oversaw a monetary fund for the purpose of member and affiliate travel to, and lodging at, events related to the foundation's mission. This proposal proposes moving the management responsibilities of this fund to the Cross Project Council (CPC), and making the funds available to all members of this broader organization. Since all projects have voting representation on the CPC, the beneficiaries of the fund will jointly manage it, and the previous owners of the fund will still vote on its use. - -We shall review the process in this proposal, but the intent is to leave the mechanics of the fund unchanged, simply moving from the purview of the Node.js project into the domain of the OpenJS Foundation, overseen by the CPC. This operation can be viewed as a refactor which moves the travel fund up one level in the organizational tree. - -The current fund is used mostly for attending collaborator summits, and we do not expect this to change. - -## Difference from the current process - -The existing process requires approval from two members of the [Node.js TSC](https://github.com/nodejs/TSC) and two members of the [Node.js Community Committee](https://github.com/nodejs/community-committee). -The new process will require approval from four members of the CPC. - -The role of fund "treasurer" will be removed, as it has been found to be redundant and is not currently filled (see https://github.com/openjs-foundation/cross-project-council/pull/268#issuecomment-513888283). - -The suggestion to submit a "trip report" after travel has been removed. No trip reports have been submitted in the past year. - -## Who qualifies for using the Travel Fund? - -As the document currently states: -> * Candidates must be an active participant of one of the projects of the OpenJS Foundation. -> * Those requesting funds must indicate that they do not have funding available from another source, such as an employer or -> the event itself that might cover costs for presenters. - -This means, any project in the Foundation, no matter the level. -For each project, any active participant is welcome to apply for funds. This would mean any contributor or someone active in the community. Their participation should be self-evident (github activity, etc), and if in doubt their project representative can be asked to confirm. - -## Practical Specifics - -> **Note:** This section has been updated to include the updated links, pointing to where they live in the OpenJS Foundation organization rather than the dead links in the Node.js organization. See the previous commit to the following lines file if you'd like to see the original, broken links. - -- Modify these files to account for OpenJS Foundation rather than Node.js organizations - - https://github.com/openjs-foundation/community-fund/blob/main/programs/travel-fund/README.md - - https://github.com/openjs-foundation/community-fund/blob/main/programs/travel-fund/travel-visas.md - -- Remove mentions from nodejs/admin README, add links to CPC README - -## Required Resources - -@brianwarner reports that everything can stay the same for the tools and accounts involved. - - add email: visainfo@openjsf.org and travelapprovals@openjsf.org -Some data on past fund usage, and data from the OpenJS projects on predicted fund usage. - -## How would success be measured? - -Success will be achieved if Node.js and non-Node.js members use the travel fund to attend a Foundation-related event, and nobody notices the difference. - -## Why this proposal is important - -The Node.js project has demonstrated the value of providing a travel fund which allows project members to get together at collaborator summits and to represent/advocate for the project at other events. It is important to expand the travel fund (both resource and usage) so that other projects can benefit as well. - -## Unresolved Questions - - - -## What is necessary to complete this proposal - -- Approval and buy-in from Node.js TSC and CommComm. -- OpenJS board approval -- Definition and wording of the travel fund mechanics, mostly moving files and updating references. -- Update 2019.md to include expenses made during this proposal process in nodejs/admin/travelfunds/2019.md diff --git a/proposals/incubating/ANNUAL_ECOSYSTEM_REPORT/README.md b/proposals/incubating/ANNUAL_ECOSYSTEM_REPORT/README.md deleted file mode 100644 index 1b18f5e88..000000000 --- a/proposals/incubating/ANNUAL_ECOSYSTEM_REPORT/README.md +++ /dev/null @@ -1,58 +0,0 @@ -# **OpenJS Foundation Annual Ecosystem Report** -> incubating - -## **Champion** - -[Adrian Estrada](https://github.com/edsadr) - -## **Description** - -This proposal contemplates the creation of **an annual open poll** capturing relevant data and opinions from the JavaScript ecosystem end-users **and a final report** including collected data and adding a comprehensive statement with pertinent information from the OpenJS Foundation and its member projects. - -This comprehensive report should present a detailed look into the OpenJS Foundation's entire portfolio, shedding light on each open-source JavaScript member project's progress, plans, and potential. It also delves into feedback gathered from the open poll, ensuring the voices of JavaScript ecosystem end-users are heard. Readers can expect insights on milestones achieved, future roadmaps, recommended best practices, specific project requests to end-users, and recommendations from the OpenJS Foundation. - -This effort will aim at nurturing the healthy evolution of the open-source JavaScript ecosystem and web technologies and establish a channel to get end-users feedback and more involvement with the OpenJS Foundation. - -## **Required Resources** - -* Project Management support from the OpenJS Foundation -* Budget for the design and distribution of the end-user poll -* Design and distribution support from the OpenJS Foundation marketing staff - -## **Who would be responsible?** - -* The CPC would overview the process -* A new working group should be created, and its responsibilities will be: - * Work on designing the end-user poll - * Create the format for all member projects to report their details - * Work with the member projects to get the report done - * In case of not getting the report from a project, the working group will create a report based on the information available -* The OpenJS Foundation marketing staff would design and distribute the end-user poll and the final unified report. - -## **How would success be measured?** - -* Number of end-users that participate in the poll -* Distribution stats of the final report -* An increase in contributors to projects from small to large - -## **Why this proposal is important** - -* Currently, the connection with the end-users from the OpenJS Foundation needs to be stronger. This proposal will help better understand the end-user's needs and how the OpenJS Foundation can help fulfill them. -* It will help to get end-users feedback and more involvement with the OpenJS Foundation, which will help to nurture the healthy evolution of the open-source JavaScript ecosystem and web technologies. -* It will help get a panoramic view of the OpenJS Foundation's portfolio, detailing all project members' progress, plans, and prospects. -* It will build trust and confidence in the OpenJS Foundation and its project members. -* It will provide a channel to give recommendations to end-users from the OpenJS Foundation and its member projects. - -## **Unresolved Question** - -* What should be the protocol to reach the open-source project members to get the report done? -* What should the deadline be for the open-source project members to complete the report? -* What should be the timeline for the report? -* What should be the timeline for the end-user poll? -* What should be the timeline for the final report? - -## **What is necessary to complete this proposal** - -* Approval and general support from the CPC -* Approval and support from the Board of Directors of OpenJS Foundation -* Creation of a new working group diff --git a/proposals/incubating/CHARTER_REVIEW/README.md b/proposals/incubating/CHARTER_REVIEW/README.md deleted file mode 100644 index c92950065..000000000 --- a/proposals/incubating/CHARTER_REVIEW/README.md +++ /dev/null @@ -1,41 +0,0 @@ -# Charter Review and Update Process -> incubating - -## Champion - -Jory Burson (@jorydotcom) - -## Description - -Clarifies process through which projects, new and old, get reviews from the CPC related to their project charters. Project charter documents are required for all OpenJS Foundation projects. - -An exception may be made for projects that came into the OpenJS Foundation as Emeritus Projects. - -## Required Resources - -* PROJECT_CHARTER_TEMPLATE.md (landed) -* CPC Participation & review - -## Who would be responsible? - -The CPC is responsible for reviewing and approving project charters. - -Should legal review of a charter be requested, the CPC Board Representative is responsible for handling that request. - -## How would success be measured? - -* speed and thoroughness of charter review - we have ~30 project charters to assess in the coming months related to onboarding -* ease of review - the process should be relatively frictionless where there are no concerns - - -## Why this proposal is important - -We need a clear process to execute the number of charters we will have to review in a short amount of time, and the charters we have reviewed or updated so far have taken longer than is strictly necessary. - -## Unresolved Question - - -## What is necessary to complete this proposal - -* Approval from the CPC - diff --git a/proposals/incubating/CHARTER_REVIEW/charter_review.md b/proposals/incubating/CHARTER_REVIEW/charter_review.md deleted file mode 100644 index a2704f257..000000000 --- a/proposals/incubating/CHARTER_REVIEW/charter_review.md +++ /dev/null @@ -1,47 +0,0 @@ -# Charter Submission, Review & Approval Process - -This section describes how to submit charter documents for review, and how the CPC conducts project charter reviews for new projects, or for projects that may make changes to their charters from time to time. - -Project charter documents live in project repositories - not in the CPC repository. - -## Submitting a project charter document -All project charters should follow the format of the PROJECT_CHARTER_TEMPLATE.md document located in this repository. - -### Submitting a new charter (for onboarding projects) - -Once your project team has drafted its charter following the template above and is satisfied that it accurately reflects the project: - -* Open a pull request to add the charter on the appropriate repo in your project repository - for example, this is often an 'admin', 'meta', or 'documentation' repository. It should be in the same repository that the project uses for its Code of Conduct and Governance documents. -* File an issue in the Project Onboarding repository - Titled *New {$Project Name} Charter Document* and include a link to this pull request. -* Tag '@openjs-foundation/cpc' on the issue - this notifies all CPC members that a document is ready for their review. -* Add the 'cross-project-council-agenda' label to the issue - this will ensure the issue is taken up at the next CPC meeting. -* If the project would like to request legal review, note that in the issue as well (this is optional at the request of the project or the CPC). - -### Submitting an update to an existing charter - -If your project has decided that its existing charter document needs to be updated, complete the following steps: - -* Open a pull request to update your previously approved charter. Make sure changes remain in the format of the PROJECT_CHARTER_TEMPLATE.md. -* File an issue in the Cross-Project-Council repository - Titled *Update {$Project Name} Charter Document* and include a link to this pull request. -* Tag '@openjs-foundation/cpc' on the issue - this notifies all CPC members that a document is ready for their review. -* Add the 'cross-project-council-agenda' label to the issue - this will ensure the issue is taken up at the next CPC meeting. -* If the project would like to request legal review, note that in the issue as well (this is optional at the request of the project or the CPC). - -## Reviewing a charter - -Project Charters are the responsibility of the CPC. When reviewing a charter, the CPC shall evaluate: - -1. The completeness of the document - all sections marked required in the PROJECT_CHARTER_TEMPLATE.md are filled out. Optional sections that have not been filled out are marked as intentionally omitted. -1. The comprehensibility of the document - a person familiar with the field but unfamiliar with the project should be able to read the charter and have a sound understanding of where it fits in the ecosystem. -1. The accuracy of the document - the document should reflect the reality of the project. It should avoid hyperbolic language (e.g. "world's best developer experience"). -1. The lifespan of the document - the CPC should take note of what factors may cause the charter document to change. If data that may change frequently appears in the charter - such as a list of names - the CPC may ask to remove it. - -If the project handles Personally Identifiable Information (PII), deals with a new intersection between technology and law, or would simply feel more comfortable, they or the CPC Board Representative may request review from Foundation legal counsel. This is an optional step. - -CPC members should add themselves as reviewers to the associated charter issue. Comments or suggested edits to the charter document should be captured on the Pull Request. - -## Approving a charter - -Project Charters should be reviewed and approved within two weeks of submission. An exception may be made if the charter is submitted during a holiday period (such as the end of the year) or in the event either the project or CPC has requested legal review. - -Charters are approved when they meet the requirements outlined in the 'Approving Charters' section of [GOVERNANCE.md](https://github.com/openjs-foundation/cross-project-council/blob/HEAD/governance/GOVERNANCE.md#approving-project-charters). diff --git a/proposals/incubating/COLLAB_SUMMIT/README.md b/proposals/incubating/COLLAB_SUMMIT/README.md deleted file mode 100644 index 4442f8ddc..000000000 --- a/proposals/incubating/COLLAB_SUMMIT/README.md +++ /dev/null @@ -1,55 +0,0 @@ -# OpenJS Collaborator Summit -> incubating - -## Champion - -Matteo Collina (@mcollina) - -## Description - -Organize an OpenJS Collaborator Summit twice a year in two -geographically distinct location (e.g. one in Europe and one in North -America) -following the lead of the [Node.js Collaborator Summit](https://github.com/nodejs/summit). - -The goal of the Collaborator Summit is to foster collaboration within -and across projects in the Foundation. - -## Required Resources - -* Budget for venue -* Budget for travel fund - -## Who would be responsible? - -The CPC delegates the organization of the Summit to a team/working group -that includes representation from all interested projects and OpenJS staff. -The team/working group will oversee the budget for the venue and the -travel fund. - -## How would success be measured? - -* numbers of attendees at the Summit. The one in Berlin/Europe 2019 has 70 people -attending. -* number of projects participating in the summit. -* number of decisions made / problems solved. - -## Why this proposal is important - -Meeting fellow collaborators in person is important for the success of -Open Source projects. - -## Unresolved Question - -* The Node.js TSC and CommComm jointly approve the Node.js travel fund - requests in https://github.com/nodejs/admin. The majority of this - budget is currently spent for attending the summit. - How will it be managed going forward? It was managed by Node.js, but - the Collaborator Summit will now be larger than just Node.js. Will - Node.js maintain their travel fund and a new travel fund will be set up - for the Foundation as a whole? Will many projects get travel budgets? - -## What is necessary to complete this proposal - -* Approval from the CPC -* Approval from the Board on the allocated budgets for 2020 diff --git a/proposals/incubating/PROJECT_EXIT_CRITERIA/README.md b/proposals/incubating/PROJECT_EXIT_CRITERIA/README.md deleted file mode 100644 index 1d8e3df63..000000000 --- a/proposals/incubating/PROJECT_EXIT_CRITERIA/README.md +++ /dev/null @@ -1,42 +0,0 @@ -# Project Exit Criteria -> incubating - -## Champion - -[Sendil Kumar N](https://github.com/sendilkumarn) - -## Description - -This proposal codifies the process for projects should do before exiting the foundation. It includes a checklist to be used by the projects and the foundation when the project is exiting the OpenJS Foundation. - -## Who would be responsible? - -The Project, The Foundation - -## Why this proposal is important? - -A project can leave the foundation because of the following reason: - -* Project decided to leave the foundation - -> There are many other reasons. We will focus on the above reason to codify the basic criteria then expand the reasons. - -It is important to codify this process that will ensure transparent and efficient way of removing a project from the foundation and informing everybody about this. - -## What is necessary to complete this proposal? - -* Board buy in and approval to leave the foundation -* Receive a two-thirds supermajority vote of the CPC to remove the project. - -The project should: -* transfer its assets to another non-profit [a (c)6 or (c)3 in the US]. -* remove all the references to foundation. -* return all the infra, assets provided by the foundation. - -The foundation should: -* remove the project references. -* revoke access to any assets provided by the foundation. - -Other questions: -* What should we do if the project is in any investigation (like Code of Conduct breach)? -* How we should educate the users about this removal? diff --git a/proposals/incubating/REGULAR_TOWN_HALLS/README.md b/proposals/incubating/REGULAR_TOWN_HALLS/README.md deleted file mode 100644 index 3b6886f37..000000000 --- a/proposals/incubating/REGULAR_TOWN_HALLS/README.md +++ /dev/null @@ -1,55 +0,0 @@ -# Regular Town Halls -> incubating - -## Champion - -[Myles Borins](https://github.com/MylesBorins) - -## Description - -A monthly / quarterly open Q/A between the Board of Directors of OpenJS Foundation -and the projects / community. - -## Required Resources - -* zoom account -* moderator -* marketing to signal boost -* board members to attend -* way to stream live - - youtube - -## Who would be responsible? - -The Executive Director and Director of the CPC - -## How would success be measured? - -* Board engagement -* Project engagement -* Live stream viewers - -## Why this proposal is important - -Keeping a regular cadence of community and project outreach will be important -to ensure that projects and community members feel that they are empowered to -have a voice within the foundation. - -## What is necessary to complete this proposal - -* Board buy in that they would participate -* General agreement on who should moderate -* An understanding of scope of participants of live stream - - Just Board? - - Board and CPC? - - Board and CPC and C3? - - Board and any project member? - - Open to the public? -* Scope for questions - - only from projects - - anyone can ask -* Agreement on cadence - - monthly? - - quarterly? -* How do we document that we are doing this? - - this will be a blocker to stage 1 (Based on old proposal process) diff --git a/proposals/incubating/SHARED_INTERFACES/README.md b/proposals/incubating/SHARED_INTERFACES/README.md deleted file mode 100644 index 94e86e2e2..000000000 --- a/proposals/incubating/SHARED_INTERFACES/README.md +++ /dev/null @@ -1,42 +0,0 @@ -# JavaScript Shared Interfaces documentation effort -> incubating - -## Champion - -Daniel Ehrenberg (@littledan) - -## Description - -["JavaScript Shared interfaces"](https://github.com/littledan/js-shared-interfaces/) is a documentation effort to explain how cross-environment ("isomorphic") JavaScript code can be written. My hope is that this can help convergence between different platforms over time. - -## Required Resources - -We will need a lot of help writing, expanding the current content in the following directions: -- Adding documentation about more JavaScript environments -- Deepening the coverage, including deviations in semantics between environments - -## Who would be responsible? - -I'm not sure; I'd like to not be the only person responsible for this. That's why I'd like to work with the Foundation. - -## How would success be measured? - -Ideally, all of the following would start to happen over time; we can talk to readers to find out whether these goals are being met. -- Programmers find this to be a useful resource for developing code that works across environments. -- Specification authors find this to be a useful resource to understand how their work affects multiple environments. -- JavaScript embeddings/environment maintainers find this to a be a useful guide for what interfaces to implement, based on what other environments share. - -## Why this proposal is important - -JavaScript is getting used in a bunch of different ways, and it's a tax on the ecosystem to have the differences be undocumented. A lot of the most popular modules on npm exist largely to paper over these differences, and the cost of this will grow over time as the number of environments and their capabilities grows. - -## Unresolved Question - -- How can this be maintained over time? It will be a continual effort. -- How should this be exposed to developers in the most friendly way? - -## What is necessary to complete this proposal - -- The js-shared-interfaces repo should be transferred to some kind of Foundation-related organization. -- There should be a reasonable first draft published, where we are comfortable with the contents and coverage of the scope. -- We should have a solid plan for maintaining the documentation over time and making sure it doesn't go out of date. diff --git a/proposals/incubating/STANDARDS_OUTREACH/README.md b/proposals/incubating/STANDARDS_OUTREACH/README.md deleted file mode 100644 index a240948aa..000000000 --- a/proposals/incubating/STANDARDS_OUTREACH/README.md +++ /dev/null @@ -1,47 +0,0 @@ -# JavaScript Outreach Groups -> incubating - -## Champion - -Daniel Ehrenberg (@littledan) - -## Description - -[JS Outreach Groups](https://github.com/littledan/js-outreach-groups) -is an effort to have regular calls with various segments of the -JavaScript community, to consult with them on emerging standards. -We're starting with TC39 topics, but I imagine it could be useful for -other standards as well. - -## Required Resources - -Resources the Foundation could provide to help: -- A neutral home to base this outreach from, which participants can trust. It's awkward to have this as a personal repository. -- Access to attend standards committee meetings for people who are heavily involved in the efforts ("invited expert" can get awkward). - -Work involved in this effort includes: -- Identifying constituencies who would have relevant feedback in standards bodies which isn't reaching those standards bodies; calling them up, convincing them to discuss -- Running the meetings, setting agendas, taking notes, publishing the notes -- Going to standards bodies and reporting the feedback of these groups, so that it's taken into account - -## Who would be responsible? - -I'm not sure; I'd like to not be the only person responsible for this. That's why I'd like to work with the Foundation. - -## How would success be measured? - -These are squishy metrics, but: -- Standards make better and faster decisions based on feedback from ecosystem stakeholders. -- Key ecosystem stakeholders are better informed about the developments in standards. - -## Why this proposal is important - -JavaScript and Web standards will be better if they can take feedback from developers into account! - -## Unresolved Question - -Will we be able to have the impact we want it to? - -## What is necessary to complete this proposal - -The MVP here would be to just be able to say that this is a Foundation effort, and publish the notes in a place that's inside of a Foundation-related organization. Meetings are already happening.