From 0b8d59b3b80d08a8d77e9b95f95a4f16848a55f1 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 7 Feb 2023 09:37:59 +0000 Subject: [PATCH 01/83] Initial commit of charter template Copy from OpenJS Foundation CPC repo --- CHARTER.md | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 CHARTER.md diff --git a/CHARTER.md b/CHARTER.md new file mode 100644 index 00000000..4969015b --- /dev/null +++ b/CHARTER.md @@ -0,0 +1,112 @@ +# ${PROJECT} Charter + +_note: the purpose of a project charter is to provide a brief introduction_ +_to the project from a technical, community, or business perspective. The_ +_document also connects a project's community leadership and governance with the_ +_OpenJS Foundation's governance._ + + +## Section 0: Guiding Principles (optional) + +_directions: provide a concise, high-level statement about_ +_the project's long-term principles, values, or mission._ + +ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-1-guiding-principle) + +## Section 1: Scope + +_directions: Include a 3-4 sentence summary of what the project does,_ +_and/or what problems it solves. Imagine trying to explain your work_ +_to a colleague who is familiar with related technical concepts but unfamiliar_ +_with the project. You may also want to describe the project's value to community_ +_and/or business stakeholders._ + +ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#scope) + +### 1.1: In-scope (optional) + +_directions: list or bullet out problem spaces, use cases, repositories_ +_or other projects which are included with the work but may not be readily_ +_apparent. This may help differentiate the project from other solutions in the_ +_space. If you are not using this section, please indicate your intent with the_ +_phrase, 'Section Intentionally Left Blank'._ + +ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#in-scope) + +### 1.2: Out-of-Scope (optional) + +_directions: list or bullet out areas that may be seen to be related but are_ +_not included in the scope of this project. This may help clarify the kind of_ +_features, contributions, issues or problems the project is looking for._ +_If you are not using this section, please indicate your intent with the_ +_phrase, 'Section Intentionally Left Blank'._ + +ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#out-of-scope) + +## Section 2: Relationship with OpenJS Foundation CPC. + +_directions: describe how the project intersects with the Cross Project_ +_Council._ + +ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-2-evolution-of-openjs-foundation-governance) + +### 2.1 Other Formal Project Relationships (optional) + +_directions: describe any additional affiliations or groups that liaise with_ +_the project in a formal way (such as a W3C Community Group, for example)._ +_If you are not using this section, please indicate your intent with the_ +_phrase, 'Section Intentionally Left Blank'._ + +## Section 3: ${PROJECT TSC} Governing Body + +_directions: describe the structure of the group responsible for managing_ +_the project and its respective organization and repositories. If there are_ +_specific rules for membership or participation in the group, list them here or_ +_by reference to a governance.md document._ + +ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-3-establishment-of-the-tsc) + +## Section 4: Roles & Responsibilities + +_directions: describe the roles and responsibilities of the ${PROJECT} Governing Body._ + +ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#roles-and-organization-management) +ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-4-responsibilities-of-the-tsc) + +### Section 4.1 Project Operations & Management (optional) + +_directions: use this section to describe any other specific tasks the_ +_${PROJECT} Governing Body may be responsible for regarding process or project_ +_operations and management. If you are not using this section, please indicate_ +_your intent with the phrase, 'Section Intentionally Left Blank'._ + +ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#roles-and-organization-management) +ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-5-nodejs-project-operations) + +### Section 4.2: Decision-making, Voting, and/or Elections (optional) + +_directions: describe any provisions the project makes for decision-making_ +_or include the information by reference your governance.md document._ +_If you are not using this section, please indicate your intent with the_ +_phrase, 'Section Intentionally Left Blank'._ + +ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-6-elections) + +### Section 4.3: Other Project Roles (optional) + +_directions: describe other roles within the project, such as chairperson,_ +_tech lead, collaborator, contributor, maintainer, etc. and any responsibilities or_ +_rights such role confers. You can also include this information by_ +_reference to your governance.md document._ +_If you are not using this section, please indicate your intent with the_ +_phrase, 'Section Intentionally Left Blank'._ + +ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-8-project-roles) + +## Section 5: Definitions (optional) + +_directions: include any definitions that may help clarify terms or ideas found_ +_in this charter document. If you are not using this section, please indicate_ +_your intent with the phrase, 'Section Intentionally Left Blank'._ + +ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-9-definitions) From 4666a220708c1e1da0213a7c69b4bd61459f8050 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 7 Feb 2023 09:39:17 +0000 Subject: [PATCH 02/83] Add comments to heading for people who might edit the file, and a link to discussion while the document is being drafted --- CHARTER.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 4969015b..db103f62 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -1,10 +1,7 @@ -# ${PROJECT} Charter - -_note: the purpose of a project charter is to provide a brief introduction_ -_to the project from a technical, community, or business perspective. The_ -_document also connects a project's community leadership and governance with the_ -_OpenJS Foundation's governance._ +# JSON Schema Org Charter + + ## Section 0: Guiding Principles (optional) From 3cc72d2b48bb2b14609512fdb8a54a38409bf504 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 7 Feb 2023 09:41:27 +0000 Subject: [PATCH 03/83] Add content for Guiding Principles --- CHARTER.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index db103f62..41c615df 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -3,12 +3,12 @@ -## Section 0: Guiding Principles (optional) +## Section 0: Guiding Principles + -_directions: provide a concise, high-level statement about_ -_the project's long-term principles, values, or mission._ +The JSON Schema project is part of the OpenJS Foundation which operates transparently, openly, collaboratively, and ethically. We strive to be open and transparent as much as is possible, and wish to enable anyone to interact and engage with any area of our work. -ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-1-guiding-principle) +Having no structure in place usually leads to one that is informal and undocumeted, making it difficult to meet our own expectations of how we wish to operate. As such, we define the following charter which includes aspects of the governance model to which we subscribe and by which we operate. ## Section 1: Scope From b7de5e1a476fbe15798c54e8179d60304ba3f811 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 7 Feb 2023 09:42:28 +0000 Subject: [PATCH 04/83] Add content for Scope section --- CHARTER.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 41c615df..63d26157 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -11,14 +11,10 @@ The JSON Schema project is part of the OpenJS Foundation which operates transpar Having no structure in place usually leads to one that is informal and undocumeted, making it difficult to meet our own expectations of how we wish to operate. As such, we define the following charter which includes aspects of the governance model to which we subscribe and by which we operate. ## Section 1: Scope + -_directions: Include a 3-4 sentence summary of what the project does,_ -_and/or what problems it solves. Imagine trying to explain your work_ -_to a colleague who is familiar with related technical concepts but unfamiliar_ -_with the project. You may also want to describe the project's value to community_ -_and/or business stakeholders._ - -ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#scope) +JSON Schema aims to enable the confident and reliable use of the JSON data format. It does this primarily by providing specification documents which define a declarative language that allows you to annotate and validate JSON documents. +While JSON Schema's primary target is constraint based data validation, it continues to be used across the whole stack, in different stages of a given project, and for purposes beyond which it was designed for. We aim to enable these additional and emergent use cases. ### 1.1: In-scope (optional) From a4bf147855b6f76f30dbf094b52da7c48cdcbb05 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 7 Feb 2023 09:49:39 +0000 Subject: [PATCH 05/83] Modified version of Scope --- CHARTER.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 63d26157..87ab2251 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -13,8 +13,8 @@ Having no structure in place usually leads to one that is informal and undocumet ## Section 1: Scope -JSON Schema aims to enable the confident and reliable use of the JSON data format. It does this primarily by providing specification documents which define a declarative language that allows you to annotate and validate JSON documents. -While JSON Schema's primary target is constraint based data validation, it continues to be used across the whole stack, in different stages of a given project, and for purposes beyond which it was designed for. We aim to enable these additional and emergent use cases. +JSON Schema aims to enable the confident and reliable use of the JSON data format. It does this primarily by providing specification documents which define a declarative language that allows annotation and validation of JSON documents. +While JSON Schema's primary target is constraint-based data validation, it continues to be used across the whole stack, in different stages of a given project, and for purposes beyond its original design. We aim to enable these additional and emergent use cases. ### 1.1: In-scope (optional) From 327b09e43387dc8fd34b9ee945ba808bb918469f Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 7 Feb 2023 10:58:59 +0000 Subject: [PATCH 06/83] Add sections 1.1 and 1.2 re scope In-scope does not yet have any suggestions. Out-of-scope only has a suggestion to be left blank. --- CHARTER.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 87ab2251..14e35fc2 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -18,6 +18,8 @@ While JSON Schema's primary target is constraint-based data validation, it conti ### 1.1: In-scope (optional) +https://github.com/json-schema-org/community/discussions/286#discussioncomment-4391253 + _directions: list or bullet out problem spaces, use cases, repositories_ _or other projects which are included with the work but may not be readily_ _apparent. This may help differentiate the project from other solutions in the_ @@ -27,14 +29,9 @@ _phrase, 'Section Intentionally Left Blank'._ ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#in-scope) ### 1.2: Out-of-Scope (optional) + -_directions: list or bullet out areas that may be seen to be related but are_ -_not included in the scope of this project. This may help clarify the kind of_ -_features, contributions, issues or problems the project is looking for._ -_If you are not using this section, please indicate your intent with the_ -_phrase, 'Section Intentionally Left Blank'._ - -ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#out-of-scope) +Section Intentionally Left Blank ## Section 2: Relationship with OpenJS Foundation CPC. From cdc7cf5844387e648abeff3ac96dfa6a0904b798 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 7 Feb 2023 11:02:50 +0000 Subject: [PATCH 07/83] Add Relationship with OpenJS Foundation CPC section --- CHARTER.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 14e35fc2..e154487c 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -34,11 +34,9 @@ ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/ Section Intentionally Left Blank ## Section 2: Relationship with OpenJS Foundation CPC. + -_directions: describe how the project intersects with the Cross Project_ -_Council._ - -ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-2-evolution-of-openjs-foundation-governance) +Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). ### 2.1 Other Formal Project Relationships (optional) From d60d3887f458e295407fa8f7043d7eff7e6f98ea Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 7 Feb 2023 11:15:37 +0000 Subject: [PATCH 08/83] Add Other Formal Project Relationships section Left blank --- CHARTER.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index e154487c..cba8eb7e 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -39,11 +39,9 @@ Section Intentionally Left Blank Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). ### 2.1 Other Formal Project Relationships (optional) + -_directions: describe any additional affiliations or groups that liaise with_ -_the project in a formal way (such as a W3C Community Group, for example)._ -_If you are not using this section, please indicate your intent with the_ -_phrase, 'Section Intentionally Left Blank'._ +Section Intentionally Left Blank ## Section 3: ${PROJECT TSC} Governing Body From ece5e53040a5f56112d8123eefa49e762cfd3fff Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 7 Feb 2023 11:18:09 +0000 Subject: [PATCH 09/83] Add Governing Body (TSC) section --- CHARTER.md | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index cba8eb7e..ae0af908 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -43,14 +43,30 @@ Most large, complex open source communities have both a business and a technical Section Intentionally Left Blank -## Section 3: ${PROJECT TSC} Governing Body +## Section 3: JSON Schema Org Governing Body (TSC) + -_directions: describe the structure of the group responsible for managing_ -_the project and its respective organization and repositories. If there are_ -_specific rules for membership or participation in the group, list them here or_ -_by reference to a governance.md document._ +The TSC is initially established from the observed major contributors who are currently active and in good standing. -ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-3-establishment-of-the-tsc) +There is no maximum TSC membership size. The TSC must have a minimum of four members. + +Changes to TSC membership should be posted in the agenda, and may be suggested as any other agenda item. + +TSC memberships are not time-limited. + +While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (Especially when an employer has employed individuals already active in the community to work exclusivly on the open source project). While at this time there is no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. + +TSC members are expected to regularly participate in TSC activities. + +The TSC will meet regularly using virtual conferencing tools. The meeting will be directed by the TSC Chairperson(s). Responsibility for directing individual meetings may be delegated by a TSC Chairperson to any other TSC member. Minutes or an appropriate recording will be taken and made available to the community through accessible public postings. + +The TSC may, at its discretion, invite any number of non-voting observers to participate in the public portion of TSC discussions and meetings. + +A TSC member may be removed by vote from the TSC if, during a 3-month period, all of the following are true: + +- They attend fewer than 25% of the regularly scheduled meetings +- They do not participate in any TSC votes +- They do not provide any form of excuse or no excuse is known for their absence ## Section 4: Roles & Responsibilities From 2d38695e616a8653cf67c35157c6030c5bd8704e Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 9 Feb 2023 15:55:05 +0000 Subject: [PATCH 10/83] Add Roles and Responsibilities section --- CHARTER.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index ae0af908..069be5ec 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -69,11 +69,18 @@ A TSC member may be removed by vote from the TSC if, during a 3-month period, al - They do not provide any form of excuse or no excuse is known for their absence ## Section 4: Roles & Responsibilities + -_directions: describe the roles and responsibilities of the ${PROJECT} Governing Body._ +The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. -ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#roles-and-organization-management) -ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-4-responsibilities-of-the-tsc) +The TSC has final authority over this project including: + +- Technical direction +- Project governance and process (including this policy) +- Contribution policy +- GitHub repository hosting and administration +- Establishment of and delegation to working groups or teams +- Mediating technical conflicts ### Section 4.1 Project Operations & Management (optional) From 29ed1a523e64d67566c9d5d3746e305afad1cc48 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 9 Feb 2023 17:53:21 +0000 Subject: [PATCH 11/83] Add Project Operations and Management section --- CHARTER.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 069be5ec..9ae0c30d 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -83,14 +83,9 @@ The TSC has final authority over this project including: - Mediating technical conflicts ### Section 4.1 Project Operations & Management (optional) + -_directions: use this section to describe any other specific tasks the_ -_${PROJECT} Governing Body may be responsible for regarding process or project_ -_operations and management. If you are not using this section, please indicate_ -_your intent with the phrase, 'Section Intentionally Left Blank'._ - -ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#roles-and-organization-management) -ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-5-nodejs-project-operations) +The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. ### Section 4.2: Decision-making, Voting, and/or Elections (optional) From c9a6006d95dc05a4004a0ae3a64760b41b42b5e1 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 10 Feb 2023 14:11:25 +0000 Subject: [PATCH 12/83] Add Decision-making and Voting section --- CHARTER.md | 51 +++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 45 insertions(+), 6 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 9ae0c30d..7f595ae3 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -87,14 +87,53 @@ The TSC has final authority over this project including: The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. -### Section 4.2: Decision-making, Voting, and/or Elections (optional) +### Section 4.2: Decision-making and Voting + +Note: See comments found in raw view... + -_directions: describe any provisions the project makes for decision-making_ -_or include the information by reference your governance.md document._ -_If you are not using this section, please indicate your intent with the_ -_phrase, 'Section Intentionally Left Blank'._ +The TSC follows a formal consensus seeking decision making model. + +When a TSC member looks for a decision to be made, they must start by assessing if they feel it warrants potentially being a non-public discussion and decision. The TSC member must reach out to the TSC chairs to request a non-public discussion and decision. A discussion and decision will be non-public at the discression of the TSC chairs. It is expected that decision discussions and voting will only be non-public in rare circumstances. + +A decision discussion may be raised by creating an Issue in the community repo. +--? OK with this being in the community repo or should we have a new TSC repo?-- +The Issue should include introductory information about the decision that needs to be made. It should follow the provided template, and must have the label tsc-decision. + +The TSC member who raised the call for a decision should indicate if they request the short consensus process. If they do, a vote is called to see if the other members agree. If the vote is unanimous, the short concensus model is started, otherwise, the standard consensus process is started. + +The short consensus process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the agenda item has at least one clear resolution to present. The agenda item owner should present the possible solution they are advocating for, and ask for a test for agreement. If consensus is not clearly reached, the short consensus process is ended and the standard consensus process is started. + +The standard consensus process is desgined for all non-trivial decisions. +The standard consensus process should progress through the following seven stages. + +1. Introduction and clarify the issue +2. Open the discussion - Share needs and perspecitves on the issue +3. Explore ideas in a broad discussion +4. Form a proposal +5. Amend the proposal +6. Test for agreement +7. Determine resolution + +All decisions that go through the standard consensus process must also have an associated GitHub Issue, which allows those unable to attend meetings to participate. +The Issue may spread into a GitHub Discussion for considering and discussing multiple proposals, allowing for threadded replies. The Discussion and Issue must be clearly linked. +The opening comment of the Issue should be kept up to date as to the status of a decision. + +Any call for public TSC votes will be made by creating an Issue in the community repo with the tsc-vote label assigned. The Issue should use the provided template. +--? Should public votes go in the community repo or a new TSC repo?-- + +Once an Issue gains the label tsc-vote, all members of the TSC will be notified via a specific Slack channel (and by any additional method the TSC deems helpful). The votes will be collected by way of using GitHub Reactions on a specific comment, which must not be the first comment. The first comment must link to the voting comment in the same Issue. +Voting will by default close after 7 days. Any member of the TSC may request a 7 day extension for any reason, moving the closing date back by 7 days. Any member of the TSC may request additioanl extensions, approved at the discretion of any TSC chair. + +If a TSC member wants to call for a vote that they wish to be non-public, they must do so by contacting the TSC Chairs directly. +At the discression of the TSC Chairs, a vote may made non-public, and will then be handled by creating a Discussion in the orgs TSC Team page (?-- Or should this be an Issue in a private repo? That might be preferable as they can then be closed--). The topic and nature of non-public votes may remain non-public, including the results.(It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) + +Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (Previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." -ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-6-elections) +(The short consensus process does not require a Decision Record, but the decision should be minuted.) ### Section 4.3: Other Project Roles (optional) From d0d58ba94a411f3e130d494edda0008a6bc8a0d3 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 10 Feb 2023 15:01:20 +0000 Subject: [PATCH 13/83] Add Definitions section --- CHARTER.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 7f595ae3..9ba62425 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -147,9 +147,9 @@ _phrase, 'Section Intentionally Left Blank'._ ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-8-project-roles) ## Section 5: Definitions (optional) + -_directions: include any definitions that may help clarify terms or ideas found_ -_in this charter document. If you are not using this section, please indicate_ -_your intent with the phrase, 'Section Intentionally Left Blank'._ +The JSON Schema project: The project which is housed by the OpenJS Foundation which operates as The JSON Schema Org. + +The JSON Schema Org: The people, policies, processes, activities, and artifacts, found within the GitHub json-schema-org. -ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-9-definitions) From 0c0f97cb418101ead3d0fa60885d594ca8c55538 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 10 Feb 2023 15:33:04 +0000 Subject: [PATCH 14/83] Add footer with links to resources --- CHARTER.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/CHARTER.md b/CHARTER.md index 9ba62425..c4c700dc 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -153,3 +153,10 @@ The JSON Schema project: The project which is housed by the OpenJS Foundation wh The JSON Schema Org: The people, policies, processes, activities, and artifacts, found within the GitHub json-schema-org. +--- + +This work is a derivative of the [WebdriverIO Project Governance Model](https://github.com/webdriverio/webdriverio/blob/main/GOVERNANCE.md). + +Inspired by https://seedsforchange.org.uk/consensus + +This work is licensed under a [Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License](https://creativecommons.org/licenses/by-sa/2.0/uk/). \ No newline at end of file From 557c0a2f52b2437e0563d10638320c055ea116e7 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 20 Feb 2023 10:32:11 +0000 Subject: [PATCH 15/83] Fix typos --- CHARTER.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index c4c700dc..0bb073a9 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -8,7 +8,7 @@ The JSON Schema project is part of the OpenJS Foundation which operates transparently, openly, collaboratively, and ethically. We strive to be open and transparent as much as is possible, and wish to enable anyone to interact and engage with any area of our work. -Having no structure in place usually leads to one that is informal and undocumeted, making it difficult to meet our own expectations of how we wish to operate. As such, we define the following charter which includes aspects of the governance model to which we subscribe and by which we operate. +Having no structure in place usually leads to one that is informal and undocumented, making it difficult to meet our own expectations of how we wish to operate. As such, we define the following charter which includes aspects of the governance model to which we subscribe and by which we operate. ## Section 1: Scope @@ -54,7 +54,7 @@ Changes to TSC membership should be posted in the agenda, and may be suggested a TSC memberships are not time-limited. -While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (Especially when an employer has employed individuals already active in the community to work exclusivly on the open source project). While at this time there is no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. +While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (Especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there is no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. TSC members are expected to regularly participate in TSC activities. @@ -97,21 +97,21 @@ Note: See comments found in raw view... The TSC follows a formal consensus seeking decision making model. -When a TSC member looks for a decision to be made, they must start by assessing if they feel it warrants potentially being a non-public discussion and decision. The TSC member must reach out to the TSC chairs to request a non-public discussion and decision. A discussion and decision will be non-public at the discression of the TSC chairs. It is expected that decision discussions and voting will only be non-public in rare circumstances. +When a TSC member looks for a decision to be made, they must start by assessing if they feel it warrants potentially being a non-public discussion and decision. The TSC member must reach out to the TSC chairs to request a non-public discussion and decision. A discussion and decision will be non-public at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be non-public in rare circumstances. A decision discussion may be raised by creating an Issue in the community repo. --? OK with this being in the community repo or should we have a new TSC repo?-- The Issue should include introductory information about the decision that needs to be made. It should follow the provided template, and must have the label tsc-decision. -The TSC member who raised the call for a decision should indicate if they request the short consensus process. If they do, a vote is called to see if the other members agree. If the vote is unanimous, the short concensus model is started, otherwise, the standard consensus process is started. +The TSC member who raised the call for a decision should indicate if they request the short consensus process. If they do, a vote is called to see if the other members agree. If the vote is unanimous, the short consensus model is started, otherwise, the standard consensus process is started. The short consensus process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the agenda item has at least one clear resolution to present. The agenda item owner should present the possible solution they are advocating for, and ask for a test for agreement. If consensus is not clearly reached, the short consensus process is ended and the standard consensus process is started. -The standard consensus process is desgined for all non-trivial decisions. +The standard consensus process is designed for all non-trivial decisions. The standard consensus process should progress through the following seven stages. 1. Introduction and clarify the issue -2. Open the discussion - Share needs and perspecitves on the issue +2. Open the discussion - Share needs and perspectives on the issue 3. Explore ideas in a broad discussion 4. Form a proposal 5. Amend the proposal @@ -119,17 +119,17 @@ The standard consensus process should progress through the following seven stage 7. Determine resolution All decisions that go through the standard consensus process must also have an associated GitHub Issue, which allows those unable to attend meetings to participate. -The Issue may spread into a GitHub Discussion for considering and discussing multiple proposals, allowing for threadded replies. The Discussion and Issue must be clearly linked. +The Issue may spread into a GitHub Discussion for considering and discussing multiple proposals, allowing for threaded replies. The Discussion and Issue must be clearly linked. The opening comment of the Issue should be kept up to date as to the status of a decision. Any call for public TSC votes will be made by creating an Issue in the community repo with the tsc-vote label assigned. The Issue should use the provided template. --? Should public votes go in the community repo or a new TSC repo?-- Once an Issue gains the label tsc-vote, all members of the TSC will be notified via a specific Slack channel (and by any additional method the TSC deems helpful). The votes will be collected by way of using GitHub Reactions on a specific comment, which must not be the first comment. The first comment must link to the voting comment in the same Issue. -Voting will by default close after 7 days. Any member of the TSC may request a 7 day extension for any reason, moving the closing date back by 7 days. Any member of the TSC may request additioanl extensions, approved at the discretion of any TSC chair. +Voting will by default close after 7 days. Any member of the TSC may request a 7 day extension for any reason, moving the closing date back by 7 days. Any member of the TSC may request additional extensions, approved at the discretion of any TSC chair. If a TSC member wants to call for a vote that they wish to be non-public, they must do so by contacting the TSC Chairs directly. -At the discression of the TSC Chairs, a vote may made non-public, and will then be handled by creating a Discussion in the orgs TSC Team page (?-- Or should this be an Issue in a private repo? That might be preferable as they can then be closed--). The topic and nature of non-public votes may remain non-public, including the results.(It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) +At the discretion of the TSC Chairs, a vote may made non-public, and will then be handled by creating a Discussion in the orgs TSC Team page (?-- Or should this be an Issue in a private repo? That might be preferable as they can then be closed--). The topic and nature of non-public votes may remain non-public, including the results.(It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (Previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." From 5abe1bd6af7562847183a68d11828d1bbf4e7a30 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 21 Feb 2023 11:52:34 +0000 Subject: [PATCH 16/83] Add note about how testing for agreement is not the same as voting. Add that quorum is required for a vote by default. --- CHARTER.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CHARTER.md b/CHARTER.md index 0bb073a9..fe8209bf 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -122,12 +122,17 @@ All decisions that go through the standard consensus process must also have an a The Issue may spread into a GitHub Discussion for considering and discussing multiple proposals, allowing for threaded replies. The Discussion and Issue must be clearly linked. The opening comment of the Issue should be kept up to date as to the status of a decision. +The "Test for agreement" step is not voting, and is in stead asking for "signals", which enable the consensus process to continue. +Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. + Any call for public TSC votes will be made by creating an Issue in the community repo with the tsc-vote label assigned. The Issue should use the provided template. --? Should public votes go in the community repo or a new TSC repo?-- Once an Issue gains the label tsc-vote, all members of the TSC will be notified via a specific Slack channel (and by any additional method the TSC deems helpful). The votes will be collected by way of using GitHub Reactions on a specific comment, which must not be the first comment. The first comment must link to the voting comment in the same Issue. Voting will by default close after 7 days. Any member of the TSC may request a 7 day extension for any reason, moving the closing date back by 7 days. Any member of the TSC may request additional extensions, approved at the discretion of any TSC chair. +For a vote to carry, a quorum of 75% is required by default. + If a TSC member wants to call for a vote that they wish to be non-public, they must do so by contacting the TSC Chairs directly. At the discretion of the TSC Chairs, a vote may made non-public, and will then be handled by creating a Discussion in the orgs TSC Team page (?-- Or should this be an Issue in a private repo? That might be preferable as they can then be closed--). The topic and nature of non-public votes may remain non-public, including the results.(It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) @@ -158,5 +163,6 @@ The JSON Schema Org: The people, policies, processes, activities, and artifacts, This work is a derivative of the [WebdriverIO Project Governance Model](https://github.com/webdriverio/webdriverio/blob/main/GOVERNANCE.md). Inspired by https://seedsforchange.org.uk/consensus +Informed by https://www.ic.org/busting-the-myth-that-consensus-with-unanimity-is-good-for-communities/ This work is licensed under a [Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License](https://creativecommons.org/licenses/by-sa/2.0/uk/). \ No newline at end of file From 9ba125a8ad454e7909c3c86139b12fdf4776a5c0 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 23 Feb 2023 11:30:12 +0000 Subject: [PATCH 17/83] Refine consensus model --- CHARTER.md | 50 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 35 insertions(+), 15 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index fe8209bf..05e5e1f4 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -90,22 +90,28 @@ The TSC and entire technical community will follow any processes as may be speci ### Section 4.2: Decision-making and Voting Note: See comments found in raw view... - The TSC follows a formal consensus seeking decision making model. +In some situations, a vote may be preferable, however a vote will not be used to make the vast majority of decisions. +In the unlikely case where it seems that consensus cannot be reached after multiple attempts, the decision process may be moved to resolve via a vote. This is not expected to happen, but defined as a backup. -When a TSC member looks for a decision to be made, they must start by assessing if they feel it warrants potentially being a non-public discussion and decision. The TSC member must reach out to the TSC chairs to request a non-public discussion and decision. A discussion and decision will be non-public at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be non-public in rare circumstances. +#### Decision-making via consensus -A decision discussion may be raised by creating an Issue in the community repo. ---? OK with this being in the community repo or should we have a new TSC repo?-- -The Issue should include introductory information about the decision that needs to be made. It should follow the provided template, and must have the label tsc-decision. +When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a non-public discussion and decision. The TSC member must reach out to the TSC chairs to request a non-public discussion and decision. A discussion and decision will be non-public at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be non-public in rare circumstances. -The TSC member who raised the call for a decision should indicate if they request the short consensus process. If they do, a vote is called to see if the other members agree. If the vote is unanimous, the short consensus model is started, otherwise, the standard consensus process is started. +A decision discussion may be started by creating a Discussion in the Community repository. +--? Should we have a new repo and limit the Discussions to that repo? TSC? ?-- +The Discussion should include introductory information about the decision that needs to be made. It should follow the provided template, and must have the label `tsc-decision`. -The short consensus process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the agenda item has at least one clear resolution to present. The agenda item owner should present the possible solution they are advocating for, and ask for a test for agreement. If consensus is not clearly reached, the short consensus process is ended and the standard consensus process is started. +##### Quick consensus process + +In the event a TSC member feels the need for a decision to be expedited, they may create the decision discussion, indicating that they wish to use the quick process rather than the standard consensus process. + +A vote is called to see if other members agree. The vote takes place on the opening comment. This vote is different from the decision-making voting process, and only requires 3 (additional) votes in favour and none against to carry. If the vote carries, the quick process is started, otherwise the standard consensus process is started. + +The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for, and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. + +##### Standard consensus process The standard consensus process is designed for all non-trivial decisions. The standard consensus process should progress through the following seven stages. @@ -118,13 +124,27 @@ The standard consensus process should progress through the following seven stage 6. Test for agreement 7. Determine resolution -All decisions that go through the standard consensus process must also have an associated GitHub Issue, which allows those unable to attend meetings to participate. -The Issue may spread into a GitHub Discussion for considering and discussing multiple proposals, allowing for threaded replies. The Discussion and Issue must be clearly linked. -The opening comment of the Issue should be kept up to date as to the status of a decision. +(These stages are those defined by the [Seeds For Change's Consensus Decision Making document](https://seedsforchange.org.uk/consensus). Please use that document as a rough guide for specific steps while we test and firm up our specific requirements, and document them in our [Governance document](./GOVERNANCE.md)) + + +All decisions that go through the standard consensus process must also have an associated GitHub Discussion, which allows those unable to attend meetings to participate. +The opening comment of the Discussion should be kept up to date as to the status of a decision. + +Transition between stages may be requested by anyone, but must be called by the facilitator (either a TSC chair or TSC member delegated the facilitator role for a given decision discussion). The stage will be indicated in the opening comment of the discussion and using the appropriate label. -The "Test for agreement" step is not voting, and is in stead asking for "signals", which enable the consensus process to continue. +Most of the discussion should happen within the same Discussion. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in the same Discussion, and any other relevant locations. + +Moving to the 'Form a proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. + +The "Test for Agreement" step is not voting, and is in stead asking for "signals", which enable the consensus process to continue. Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. +If someone calls for a Test of Agreement, the facilitator for the Discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Discussion (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using reactions on the comment. + +The "Determine resolution" step should result in the creation of an [Any Decision Record](./docs/adr/README.md). + +#### Decision-making via vote + Any call for public TSC votes will be made by creating an Issue in the community repo with the tsc-vote label assigned. The Issue should use the provided template. --? Should public votes go in the community repo or a new TSC repo?-- @@ -162,7 +182,7 @@ The JSON Schema Org: The people, policies, processes, activities, and artifacts, This work is a derivative of the [WebdriverIO Project Governance Model](https://github.com/webdriverio/webdriverio/blob/main/GOVERNANCE.md). -Inspired by https://seedsforchange.org.uk/consensus +Inspired by https://seedsforchange.org.uk/consensus, https://seedsforchange.org.uk/quickconsensus Informed by https://www.ic.org/busting-the-myth-that-consensus-with-unanimity-is-good-for-communities/ This work is licensed under a [Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License](https://creativecommons.org/licenses/by-sa/2.0/uk/). \ No newline at end of file From 9301be9039bc3c8618b494a956af86287195bea7 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 23 Feb 2023 14:33:54 +0000 Subject: [PATCH 18/83] Tidy up and break out section for ADRs --- CHARTER.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 05e5e1f4..109389a3 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -134,31 +134,35 @@ Transition between stages may be requested by anyone, but must be called by the Most of the discussion should happen within the same Discussion. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in the same Discussion, and any other relevant locations. -Moving to the 'Form a proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. +Moving to the 'Form a Proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. The "Test for Agreement" step is not voting, and is in stead asking for "signals", which enable the consensus process to continue. Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. -If someone calls for a Test of Agreement, the facilitator for the Discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Discussion (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using reactions on the comment. +If someone calls for a Test of Agreement, the facilitator for the Discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Discussion (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. -The "Determine resolution" step should result in the creation of an [Any Decision Record](./docs/adr/README.md). +The "Determine resolution" step should result in the creation of an [Any Decision Record](./docs/adr/README.md). More details in following sections. #### Decision-making via vote -Any call for public TSC votes will be made by creating an Issue in the community repo with the tsc-vote label assigned. The Issue should use the provided template. +Any call for public TSC votes will be made by creating an Issue in the community repo with the `tsc-vote` label assigned. The Issue should use the provided template. --? Should public votes go in the community repo or a new TSC repo?-- -Once an Issue gains the label tsc-vote, all members of the TSC will be notified via a specific Slack channel (and by any additional method the TSC deems helpful). The votes will be collected by way of using GitHub Reactions on a specific comment, which must not be the first comment. The first comment must link to the voting comment in the same Issue. +Once an Issue gains the label `tsc-vote`, all members of the TSC will be notified via a specific Slack channel (and by any additional method the TSC deems helpful). The votes will be collected by way of using GitHub Reactions on a specific comment, which must not be the first comment. The first comment must link to the voting comment in the same Issue. Voting will by default close after 7 days. Any member of the TSC may request a 7 day extension for any reason, moving the closing date back by 7 days. Any member of the TSC may request additional extensions, approved at the discretion of any TSC chair. For a vote to carry, a quorum of 75% is required by default. If a TSC member wants to call for a vote that they wish to be non-public, they must do so by contacting the TSC Chairs directly. -At the discretion of the TSC Chairs, a vote may made non-public, and will then be handled by creating a Discussion in the orgs TSC Team page (?-- Or should this be an Issue in a private repo? That might be preferable as they can then be closed--). The topic and nature of non-public votes may remain non-public, including the results.(It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) +At the discretion of the TSC Chairs, a vote may be made non-public, and will then be handled by creating a Discussion in the orgs TSC Team page (?-- Or should this be an Issue in a private repo? That might be preferable as they can then be closed--). The topic and nature of non-public votes may remain non-public, including the results.(It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) + +#### Documenting decisions Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (Previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." -(The short consensus process does not require a Decision Record, but the decision should be minuted.) +(The quick consensus process does not require a Decision Record, but the decision should be minuted.) + +Non-public decisions should be documented (as an ADR or otherwise) in the private `private-tsc` repo. ### Section 4.3: Other Project Roles (optional) From e3ecb1e6172bab569e402a22b538d77132ab91be Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 3 Mar 2023 11:59:38 +0000 Subject: [PATCH 19/83] Add definition of TSC --- CHARTER.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHARTER.md b/CHARTER.md index 109389a3..96f31d75 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -182,6 +182,8 @@ The JSON Schema project: The project which is housed by the OpenJS Foundation wh The JSON Schema Org: The people, policies, processes, activities, and artifacts, found within the GitHub json-schema-org. +TSC: The Technical Steering Committee, delegated technical leadership for the JSON Schema project by the OpenJS Foundation. + --- This work is a derivative of the [WebdriverIO Project Governance Model](https://github.com/webdriverio/webdriverio/blob/main/GOVERNANCE.md). From f6ac84cb9c33eb2a0d5935dc4d0bb9c8fb84a219 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 3 Mar 2023 12:00:49 +0000 Subject: [PATCH 20/83] Recognize other project roles to be defined --- CHARTER.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 96f31d75..1196231c 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -166,14 +166,16 @@ Non-public decisions should be documented (as an ADR or otherwise) in the privat ### Section 4.3: Other Project Roles (optional) -_directions: describe other roles within the project, such as chairperson,_ -_tech lead, collaborator, contributor, maintainer, etc. and any responsibilities or_ -_rights such role confers. You can also include this information by_ -_reference to your governance.md document._ -_If you are not using this section, please indicate your intent with the_ -_phrase, 'Section Intentionally Left Blank'._ +The JSON Schema project recognises the need for both technical and non-technical roles. While the OpenJS Foundation takes on business responsibilities as the legal entity hosting the project, there are other non-technical responsibilities. + +The TSC will look to create other roles as appropriate, and may update this document in accordance with the requirements for doing so, to formally recognise the additional roles. -ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-8-project-roles) +The following responsibilities are recognised as those requiring roles to be defined by the TSC: +- Community and Industry connections +- Brand awareness, recognition, and health +- Strategic allocation of funds and budgeting for investment in JSON Schema and its ecosystem +- Education and training +- Financial allocation approval, tracking, and auditing ## Section 5: Definitions (optional) From a2af3ba179c0fed015ff28e6b859803916362941 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 8 Mar 2023 12:08:56 +0000 Subject: [PATCH 21/83] Add detail about signal based voting at the Test for Agreement stage of the consensus process --- CHARTER.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 1196231c..8db27455 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -139,7 +139,24 @@ Moving to the 'Form a Proposal" stage should be approached when the group might The "Test for Agreement" step is not voting, and is in stead asking for "signals", which enable the consensus process to continue. Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. -If someone calls for a Test of Agreement, the facilitator for the Discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Discussion (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. +If someone calls for a Test for Agreement, the facilitator for the Discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Discussion (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the projects core principals or something that would harm the project. + +The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. + +If someone feels a "Block" is being used for unfair reasons, such as targeting individuals or to gain some personal advantage, or any such reason that might be in breach of our Code of Conduct, they should immediately report it to the Code of Conduct committee. The Code of Conduct committee should report this to the TSC Chairs as soon as possible, and the decision is halted while the committee investigates the report. + +The Code of Conduct committee will report their findings and any remediation action to the TSC Chairs. +Reports must remain anonymous, as per the Code of Conduct. + +The other signals that may be made when a Test For Agreement is called include "Reservations" and "Stand Aside". Both are signals which convey consent to let the proposal pass, however they may be conditional. + +Signalling "Reservations" means an agreement on the overall direction, however there is some desire to revise or amend the proposal somewhat. It is expected that the individuals signalling "Reservations" want to engage in reworking the proposal. The facilitator will check with each individual regarding the strength of the reservation, and later facilitate or direct discussion as required to amend and represent the proposal. If the individual/s do not wish to participate in reworking the proposal, their reservations should be logged as part of the decision record as unresolved. + +If "Reservations" is signalled three consecutive times by the same individual/s, anyone may call for no further attempts to remediate the reservations, and the proposal will pass. + +Signalling "Stand Aside" convey consent, but an unwillingness for whatever reason to be further involved. It could be for example that the individual does not have time to participate, or that they have limited opinions on the specific decision. The individual may provide a reason for standing aside. If the individual believes the reason can be remedied by the group, the group should seek to remedy the reason where possible, with help from the facilitator. + +The TSC will make every reasonable effort to reach unanimity based consensus. If unanimity seems unlikely after several failed attempts to revise the proposal and Test for Agreement, if the proposal is clear, the decision may be moved to a vote, at the discretion of the TSC Chairs. This is a last resort. The "Determine resolution" step should result in the creation of an [Any Decision Record](./docs/adr/README.md). More details in following sections. From 3fc951e4e9fe3b8b41af6e49278b88a09893d391 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 8 Mar 2023 12:14:04 +0000 Subject: [PATCH 22/83] Spacing --- CHARTER.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 8db27455..8b5d9dfb 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -139,7 +139,9 @@ Moving to the 'Form a Proposal" stage should be approached when the group might The "Test for Agreement" step is not voting, and is in stead asking for "signals", which enable the consensus process to continue. Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. -If someone calls for a Test for Agreement, the facilitator for the Discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Discussion (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the projects core principals or something that would harm the project. +If someone calls for a Test for Agreement, the facilitator for the Discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Discussion (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. + +The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the projects core principals or something that would harm the project. The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. From df8930aa076139359a97d1980fe42c0259144990 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 14 Mar 2023 10:26:34 +0000 Subject: [PATCH 23/83] Amend decision making process in charter --- CHARTER.md | 44 +++++++++++++++++++++++++++++++------------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 8b5d9dfb..e4c3a005 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -99,21 +99,38 @@ In the unlikely case where it seems that consensus cannot be reached after multi When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a non-public discussion and decision. The TSC member must reach out to the TSC chairs to request a non-public discussion and decision. A discussion and decision will be non-public at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be non-public in rare circumstances. -A decision discussion may be started by creating a Discussion in the Community repository. ---? Should we have a new repo and limit the Discussions to that repo? TSC? ?-- -The Discussion should include introductory information about the decision that needs to be made. It should follow the provided template, and must have the label `tsc-decision`. +Both the Quick and Standard consensus process require the creation of an Issue in the TSC GitHub repository. +The Issue must: +- Include brief introductory information about the decision that needs to be made +- Be labelled with 'tsc-decision' +- Use the provided template, unless there is a good reason not to do so ##### Quick consensus process -In the event a TSC member feels the need for a decision to be expedited, they may create the decision discussion, indicating that they wish to use the quick process rather than the standard consensus process. +In the event a TSC member feels the need for a decision to be expedited, they may create the decision discussion, indicating that they wish to use the quick process rather than the standard consensus process. This should be done by creating a new Issue in the TSC repository. +In addition to the requirements above, the Issue must be labelled 'expedited'. + +While an associated Discussion is not required, if one is used, it must be clearly linked in both directions, and be labelled with 'tsc-decision'. A vote is called to see if other members agree. The vote takes place on the opening comment. This vote is different from the decision-making voting process, and only requires 3 (additional) votes in favour and none against to carry. If the vote carries, the quick process is started, otherwise the standard consensus process is started. -The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for, and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. +The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for (in a follow up comment on the Issue. Not in the opening comment.), and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. (Label 'expedited' should be removed and 'stage-1' added.) ##### Standard consensus process The standard consensus process is designed for all non-trivial decisions. + +A decision discussion may be started by creating an Issue and Discussion in the TSC repository. + +In addition to the requirements above, the Issue must: +- Be labelled with 'stage-1' +- Link to the associated initial Discussion + +The Discussion must: +- Link to the associated Issue +- Include detailed introductory information about the decision that needs to be made +- Be labelled with 'tsc-decision' + The standard consensus process should progress through the following seven stages. 1. Introduction and clarify the issue @@ -127,19 +144,19 @@ The standard consensus process should progress through the following seven stage (These stages are those defined by the [Seeds For Change's Consensus Decision Making document](https://seedsforchange.org.uk/consensus). Please use that document as a rough guide for specific steps while we test and firm up our specific requirements, and document them in our [Governance document](./GOVERNANCE.md)) -All decisions that go through the standard consensus process must also have an associated GitHub Discussion, which allows those unable to attend meetings to participate. -The opening comment of the Discussion should be kept up to date as to the status of a decision. +All decisions that go through the standard consensus process must have an associated GitHub Issue, which allows those unable to attend meetings to participate. +The opening comment of the Issue should be kept up to date as to the status of the decision. -Transition between stages may be requested by anyone, but must be called by the facilitator (either a TSC chair or TSC member delegated the facilitator role for a given decision discussion). The stage will be indicated in the opening comment of the discussion and using the appropriate label. +Transition between stages may be requested by anyone, but must be called by the facilitator (either a TSC chair or TSC member delegated the facilitator role for a given decision discussion). The stage will be indicated in the opening comment of the Issue and using the appropriate label. -Most of the discussion should happen within the same Discussion. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in the same Discussion, and any other relevant locations. +Most of the discussion should happen within the associated Discussion. The Issue should mostly be used to updated and report progress the consensus process. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in associated Discussion, and any other relevant locations. Moving to the 'Form a Proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. The "Test for Agreement" step is not voting, and is in stead asking for "signals", which enable the consensus process to continue. Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. -If someone calls for a Test for Agreement, the facilitator for the Discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Discussion (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. +If someone calls for a Test for Agreement, the facilitator for the decision discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Issue (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the projects core principals or something that would harm the project. @@ -164,8 +181,7 @@ The "Determine resolution" step should result in the creation of an [Any Decisio #### Decision-making via vote -Any call for public TSC votes will be made by creating an Issue in the community repo with the `tsc-vote` label assigned. The Issue should use the provided template. ---? Should public votes go in the community repo or a new TSC repo?-- +Any call for public TSC votes will be made by creating an Issue in the TSC repository with the `tsc-vote` label assigned. The Issue should use the provided template. Once an Issue gains the label `tsc-vote`, all members of the TSC will be notified via a specific Slack channel (and by any additional method the TSC deems helpful). The votes will be collected by way of using GitHub Reactions on a specific comment, which must not be the first comment. The first comment must link to the voting comment in the same Issue. Voting will by default close after 7 days. Any member of the TSC may request a 7 day extension for any reason, moving the closing date back by 7 days. Any member of the TSC may request additional extensions, approved at the discretion of any TSC chair. @@ -173,7 +189,9 @@ Voting will by default close after 7 days. Any member of the TSC may request a 7 For a vote to carry, a quorum of 75% is required by default. If a TSC member wants to call for a vote that they wish to be non-public, they must do so by contacting the TSC Chairs directly. -At the discretion of the TSC Chairs, a vote may be made non-public, and will then be handled by creating a Discussion in the orgs TSC Team page (?-- Or should this be an Issue in a private repo? That might be preferable as they can then be closed--). The topic and nature of non-public votes may remain non-public, including the results.(It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) +At the discretion of the TSC Chairs, a vote may be made non-public, and will then be handled by creating an Issue in the 'TSC-private' repository. + +The topic and nature of non-public votes may remain non-public, including the results.(It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) #### Documenting decisions From cfa2ae979f6b65b517b477bcceee7ea13590b090 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 14 Mar 2023 10:28:25 +0000 Subject: [PATCH 24/83] Fix inconsistent name for repos --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index e4c3a005..85c2e565 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -199,7 +199,7 @@ Either initially, or at any point during the process, any TSC member may suggest (The quick consensus process does not require a Decision Record, but the decision should be minuted.) -Non-public decisions should be documented (as an ADR or otherwise) in the private `private-tsc` repo. +Non-public decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. ### Section 4.3: Other Project Roles (optional) From a6bc2a8dc10140ad9f8503c4928875943da1426d Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 14 Mar 2023 11:01:56 +0000 Subject: [PATCH 25/83] Add details for project scope in the charter --- CHARTER.md | 43 +++++++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 10 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 85c2e565..48b525d9 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -17,16 +17,39 @@ JSON Schema aims to enable the confident and reliable use of the JSON data forma While JSON Schema's primary target is constraint-based data validation, it continues to be used across the whole stack, in different stages of a given project, and for purposes beyond its original design. We aim to enable these additional and emergent use cases. ### 1.1: In-scope (optional) - -https://github.com/json-schema-org/community/discussions/286#discussioncomment-4391253 - -_directions: list or bullet out problem spaces, use cases, repositories_ -_or other projects which are included with the work but may not be readily_ -_apparent. This may help differentiate the project from other solutions in the_ -_space. If you are not using this section, please indicate your intent with the_ -_phrase, 'Section Intentionally Left Blank'._ - -ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#in-scope) + + +The scope of the JSON Schema project is split into two sections: primary and secondary concerns. +Primary concerns are areas we wish to give focus to, while secondary concerns are more likely to require the creation of a Special Interest Group. + +Primary Concerns +- Publication of the JSON Schema standard + - Validation of JSON data + - Semantic annotation of JSON data + - Extensibility +- Critical tooling + - Creation of new + - Ingestion of existing + - Long term support + - (Including linting) +- Documentation +- Test suite +- Community + - Enabling schema authors + - Enabling implementers + - Engaging with industry + - Communicating value + - Ensuring the sustainability of the project + +Secondary Concerns +- Hypermedia +- Generating JSON Schema +- Using JSON Schema to generate + - Code (including types or classes) + - UI (including forms) + - Databases +- Relational validation +- Vocabularies registry ### 1.2: Out-of-Scope (optional) From d30322dc8735198eda6490dd5a5eab2a20483f41 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 16 Mar 2023 10:06:16 +0000 Subject: [PATCH 26/83] Add line about non-technical conflicts to the charter --- CHARTER.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHARTER.md b/CHARTER.md index 48b525d9..4f18b48b 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -104,6 +104,7 @@ The TSC has final authority over this project including: - GitHub repository hosting and administration - Establishment of and delegation to working groups or teams - Mediating technical conflicts +- Mediating non-technical conflicts (until a formal Code of Conduct Committee is established) ### Section 4.1 Project Operations & Management (optional) From fea116329d9cbc52788c986502cb83a5ba1dc8f5 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 20 Mar 2023 21:26:42 +0000 Subject: [PATCH 27/83] Update CHARTER.md Use full "Any Decision Record" naming for ADR Co-authored-by: Greg Dennis --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 4f18b48b..4b9d2cf7 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -221,7 +221,7 @@ The topic and nature of non-public votes may remain non-public, including the re Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (Previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." -(The quick consensus process does not require a Decision Record, but the decision should be minuted.) +(The quick consensus process does not require an Any Decision Record, but the decision should be minuted.) Non-public decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. From 14d7ca2749ec294163508ba47e968c2ab89b4a96 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 24 Mar 2023 13:56:23 +0000 Subject: [PATCH 28/83] Fix using upper case inside bracket --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 4b9d2cf7..fb4aedb4 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -219,7 +219,7 @@ The topic and nature of non-public votes may remain non-public, including the re #### Documenting decisions -Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (Previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." +Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." (The quick consensus process does not require an Any Decision Record, but the decision should be minuted.) From 90896a9ab0f708eea697d93288b6fe6e1f068a5b Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 28 Mar 2023 14:02:08 +0100 Subject: [PATCH 29/83] Remove specific mention of linting tooling. No one suggests linting isn't critical. --- CHARTER.md | 1 - 1 file changed, 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index fb4aedb4..7a20749b 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -31,7 +31,6 @@ Primary Concerns - Creation of new - Ingestion of existing - Long term support - - (Including linting) - Documentation - Test suite - Community From dc3785a43eff239f72fe9dcc32ecf2d225aeaf6d Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 30 Mar 2023 11:48:10 +0100 Subject: [PATCH 30/83] Add time limits to some stages of consensus process --- CHARTER.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CHARTER.md b/CHARTER.md index 7a20749b..b7276c72 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -105,6 +105,8 @@ The TSC has final authority over this project including: - Mediating technical conflicts - Mediating non-technical conflicts (until a formal Code of Conduct Committee is established) +In joining the TSC, members commit to communicate on a regular basis and respond to issues raised by the TSC in a timely manner. If they are no longer able or willing to make such a commitment, they should discuss this with the TSC or a TSC Chair. + ### Section 4.1 Project Operations & Management (optional) @@ -128,6 +130,8 @@ The Issue must: - Be labelled with 'tsc-decision' - Use the provided template, unless there is a good reason not to do so +At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signalling or voting. The TSC member must detail when they expect to return. + ##### Quick consensus process In the event a TSC member feels the need for a decision to be expedited, they may create the decision discussion, indicating that they wish to use the quick process rather than the standard consensus process. This should be done by creating a new Issue in the TSC repository. @@ -172,6 +176,8 @@ The opening comment of the Issue should be kept up to date as to the status of t Transition between stages may be requested by anyone, but must be called by the facilitator (either a TSC chair or TSC member delegated the facilitator role for a given decision discussion). The stage will be indicated in the opening comment of the Issue and using the appropriate label. +Stages 1 and 6 are required to be open for at least 7 days or until every TSC member has confirmed they wish to progress to the next stage (Progression will still be "called", as above). This includes signals of abstaining given automatically via a notification of period of leave from TSC activity. For stage 2, any TSC member may request a 7 day extension to allow for further consideration. Should there be no reasonable objection (determined by a TSC Chair), the minimum time will be extended by 7 days. A TSC member may request multiple extensions, however lack of justification may result in the TSC member being asked to consider abstaining in stead. There are no other explicit time limits placed on the other stages of the process. + Most of the discussion should happen within the associated Discussion. The Issue should mostly be used to updated and report progress the consensus process. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in associated Discussion, and any other relevant locations. Moving to the 'Form a Proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. From c35d42325fed58d2fb0585adc634ca7a861d5f9d Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 6 Apr 2023 15:23:54 +0100 Subject: [PATCH 31/83] Provide blocker fallback This is a similar approach to the N Street consensus model --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index b7276c72..e3d83512 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -189,7 +189,7 @@ If someone calls for a Test for Agreement, the facilitator for the decision disc The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the projects core principals or something that would harm the project. -The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. +The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. If the blocker/s are unable or unwilling to participate in attempts to find a solution, after multiple attempts, the original proposal is moved to a vote, as defined in this document, but additionally requiring a 75% super majority to pass. This will be at the discression of the TSC Chairs. If someone feels a "Block" is being used for unfair reasons, such as targeting individuals or to gain some personal advantage, or any such reason that might be in breach of our Code of Conduct, they should immediately report it to the Code of Conduct committee. The Code of Conduct committee should report this to the TSC Chairs as soon as possible, and the decision is halted while the committee investigates the report. From c1f0fa43c6f556aea256e647c376abb70a68bb8a Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 11 Apr 2023 16:22:50 +0100 Subject: [PATCH 32/83] Add details to ADR for consensus based TSC --- ...023-03-30-establish-consensus-based-tsc.md | 123 ++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 docs/adr/2023-03-30-establish-consensus-based-tsc.md diff --git a/docs/adr/2023-03-30-establish-consensus-based-tsc.md b/docs/adr/2023-03-30-establish-consensus-based-tsc.md new file mode 100644 index 00000000..81b9faab --- /dev/null +++ b/docs/adr/2023-03-30-establish-consensus-based-tsc.md @@ -0,0 +1,123 @@ +# Project has formal governance through consensus based Technical Steering Committee + +* Status: proposed +* Deciders: @relequestual, @awwright, @gregsdennis, @Julian, @jdesrosiers, @karenetheridge +* Date: 2023-03-30 + +Story: In order to fully onboard with the OpenJS Foundation, and in order to have proper governance, we should have a charter: https://github.com/json-schema-org/community/issues/274 + +## Context and Problem Statement + +It's essential that both the maintainers and community can see a clear and coherent statement about the JSON Schema project and its intentions. Currently it is not clear, and may be hard to determine. + +Lack of clear and document governance makes it very difficult in some situations to move some issues forward. The current "process" is mostly undocumented and ad-hoc, with loose collective will. +As the number of people who can work on this full or part time grows, the organizational needs will evolve, requiring governance for long term sustainability. +Having a clear and documented governance model will allow us to make clear progress with an unambiguous process defined. + +When we joined the OpenJS Foundation, we committed to creating a charter. They provide a template for use, which several projects have used. We should use it as our basis, but we may also want to consider additional elements or sections. + +## Decision Drivers + +- JSON Schema committed to forming a governance model as part of a charter when we joined the OpenJS Foundation +- It has sometimes been difficult to reach decisions on tricky topics, with no clear way to resolve divisive issues +- Undocumented process can lead to an imbalance of power which is undesirable +- Defining a process can help make sure everyone has space to be heard +- Defining expectations up front can help everyone know what the next steps are and avoid decision stagnation +- Gives internal and external confidence of long term viability + +## Considered Options + +- Voting +- Unanimous Consensus +- General/rough consensus +- Lazy consensus / Do-ocracy +- Benevolent Dictator (for life) + +## Decision Outcome + +We settled on Consensus and Voting, with a preference for consensus. Ideally we would like to have unanimous consensus, however reflecting on how requiring that might [not always be a good thing](https://www.ic.org/busting-the-myth-that-consensus-with-unanimity-is-good-for-communities/), we landed on a variation of what's known as the N Street Consensus Method. This wasn't originally one of the consensus models proposed, but was discovered during the process and found in favour over general or nondescript "consensus". + +In consensus based decision making, any individual can signal "block", which works like a veto when voting. It is a signal that the consensus process has failed, or the conditions for forming consensus are not as good as they could be. Given any member may signal a "block", this may give individual members disproportional power, and blocks may be used inappropriately, such as for personal reasons. + +Ideally, major or critical reservations should have been worked out as part of the consensus building process. However, it is possible that a presented solution may have had something untenable added in error. We also define using aspects of the N Street based consensus method for resolving blocks, requiring that a blocker commit to trying to find a new or amended solution. There is a fallback of voting should resolving a block not be possible. + +It's recognised that some decision making may not be suitable for using the consensus approach, or voting may be preferable, and voting is provided as a rare fall-back solution. + +### Positive Consequences + +- Everyone has the opportunity to be heard and understood +- Shares power between all members fairly +- More likely to find a solution that is acceptable to all involved in resolving a given issue +- Make sure that decisions aren't made against the will of anyone involved +- Members are likely to assist or help in enacting the resolution +- Builds a stronger sense of trust +- Voting as a fall-back helps avoid eternal blocking + +### Negative Consequences + +- Consensus can be slower than voting +- Still provides some additional powers to the facilitating Chair/s +- May make some types of decisions harder +- Potential for "Groupthink" +- Requires continual active engagement +- May make bad decisions +- Blocking can be abused against individuals + +## Pros and Cons of the Options + +### Voting + +Voting with a majority rule. + +- Good, because it enables decisions to be made clearly and quickly +- Good, because it gives everyone equal power +- Bad, because it may not allow individuals to be fully heard +- Bad, because decisions can be divisive + +### Unanimous Consensus + +Consensus where everyone must be in agreement + +- Good, because everyone consents to the solution +- Bad, because it can create a fear of proposing ideas + +See https://www.ic.org/busting-the-myth-that-consensus-with-unanimity-is-good-for-communities/ + +### General/rough consensus + +As used by the IETF + +- Good, because it allows progress without requiring all to agree +- Good, because it can be faster than other consensus based methods +- Good, because the chairperson can make judgement calls +- Good, because it allows anonymity, encouraging people to vocalise concerns without fear of retribution or judgement +- Bad, because it's hard to do not in-person / requires regular in-person meetings to be effective +- Bad, because it can be subjective +- Bad, because it puts a lot of power in the chairperson + +### Lazy consensus / Do-ocracy + +- Good, because it allows progress without requiring everyone to be involved +- Good, because it enables faster progress +- Good, because it can foster a sense of trust and community +- Good, because it empowers do-ers +- Bad, because it is possible for people to miss things +- Bad, because it assumes silence is consent, which can result in people less likely to want to raise concerns +- Bad, because it creates a power imbalance where people who have more time or who are more influential can push decisions through + +### Benevolent Dictator (for life) + +- Good, because it enables very fast progress +- Good, because it can help to have a clear and consistent vision +- Good, because there's clear accountability, which might encourage a BDFL to act in the best interests of the project +- Bad, because it prevents diverse opinions or ideas +- Bad, because concentrated power can be abused +- Bad, because it discourages participation from the community + +## Links + +Useful resources in helping make this decision + +- https://seedsforchange.org.uk/consensus +- https://www.ic.org/busting-the-myth-that-consensus-with-unanimity-is-good-for-communities +- https://copim.pubpub.org/towards-better-practices-for-the-community-governance-of-open-infrastructures \ No newline at end of file From 42e1c54b35c721024d591c20e4f844aed925f28f Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Apr 2023 15:32:24 +0100 Subject: [PATCH 33/83] Remove comments not intended for final document --- CHARTER.md | 23 ----------------------- 1 file changed, 23 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index e3d83512..40a9be4b 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -4,21 +4,15 @@ ## Section 0: Guiding Principles - - The JSON Schema project is part of the OpenJS Foundation which operates transparently, openly, collaboratively, and ethically. We strive to be open and transparent as much as is possible, and wish to enable anyone to interact and engage with any area of our work. Having no structure in place usually leads to one that is informal and undocumented, making it difficult to meet our own expectations of how we wish to operate. As such, we define the following charter which includes aspects of the governance model to which we subscribe and by which we operate. ## Section 1: Scope - - JSON Schema aims to enable the confident and reliable use of the JSON data format. It does this primarily by providing specification documents which define a declarative language that allows annotation and validation of JSON documents. While JSON Schema's primary target is constraint-based data validation, it continues to be used across the whole stack, in different stages of a given project, and for purposes beyond its original design. We aim to enable these additional and emergent use cases. ### 1.1: In-scope (optional) - - The scope of the JSON Schema project is split into two sections: primary and secondary concerns. Primary concerns are areas we wish to give focus to, while secondary concerns are more likely to require the creation of a Special Interest Group. @@ -51,23 +45,15 @@ Secondary Concerns - Vocabularies registry ### 1.2: Out-of-Scope (optional) - - Section Intentionally Left Blank ## Section 2: Relationship with OpenJS Foundation CPC. - - Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). ### 2.1 Other Formal Project Relationships (optional) - - Section Intentionally Left Blank ## Section 3: JSON Schema Org Governing Body (TSC) - - The TSC is initially established from the observed major contributors who are currently active and in good standing. There is no maximum TSC membership size. The TSC must have a minimum of four members. @@ -91,8 +77,6 @@ A TSC member may be removed by vote from the TSC if, during a 3-month period, al - They do not provide any form of excuse or no excuse is known for their absence ## Section 4: Roles & Responsibilities - - The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. The TSC has final authority over this project including: @@ -108,14 +92,9 @@ The TSC has final authority over this project including: In joining the TSC, members commit to communicate on a regular basis and respond to issues raised by the TSC in a timely manner. If they are no longer able or willing to make such a commitment, they should discuss this with the TSC or a TSC Chair. ### Section 4.1 Project Operations & Management (optional) - - The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. ### Section 4.2: Decision-making and Voting - -Note: See comments found in raw view... - The TSC follows a formal consensus seeking decision making model. In some situations, a vote may be preferable, however a vote will not be used to make the vast majority of decisions. In the unlikely case where it seems that consensus cannot be reached after multiple attempts, the decision process may be moved to resolve via a vote. This is not expected to happen, but defined as a backup. @@ -244,8 +223,6 @@ The following responsibilities are recognised as those requiring roles to be def - Financial allocation approval, tracking, and auditing ## Section 5: Definitions (optional) - - The JSON Schema project: The project which is housed by the OpenJS Foundation which operates as The JSON Schema Org. The JSON Schema Org: The people, policies, processes, activities, and artifacts, found within the GitHub json-schema-org. From 1b31445eacf13381a3124fe1658a9384dfa0daf3 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Apr 2023 15:41:05 +0100 Subject: [PATCH 34/83] Fix typo --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 40a9be4b..d20afca1 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -168,7 +168,7 @@ If someone calls for a Test for Agreement, the facilitator for the decision disc The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the projects core principals or something that would harm the project. -The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. If the blocker/s are unable or unwilling to participate in attempts to find a solution, after multiple attempts, the original proposal is moved to a vote, as defined in this document, but additionally requiring a 75% super majority to pass. This will be at the discression of the TSC Chairs. +The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. If the blocker/s are unable or unwilling to participate in attempts to find a solution, after multiple attempts, the original proposal is moved to a vote, as defined in this document, but additionally requiring a 75% super majority to pass. This will be at the discretion of the TSC Chairs. If someone feels a "Block" is being used for unfair reasons, such as targeting individuals or to gain some personal advantage, or any such reason that might be in breach of our Code of Conduct, they should immediately report it to the Code of Conduct committee. The Code of Conduct committee should report this to the TSC Chairs as soon as possible, and the decision is halted while the committee investigates the report. From 9634a600d89b8daa9b9c1bc00469dace9de7443f Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Apr 2023 15:41:59 +0100 Subject: [PATCH 35/83] Remove additional comment and mention governance document is to be created --- CHARTER.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index d20afca1..77a0c7cf 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -1,7 +1,5 @@ # JSON Schema Org Charter - - - + ## Section 0: Guiding Principles The JSON Schema project is part of the OpenJS Foundation which operates transparently, openly, collaboratively, and ethically. We strive to be open and transparent as much as is possible, and wish to enable anyone to interact and engage with any area of our work. @@ -147,8 +145,7 @@ The standard consensus process should progress through the following seven stage 6. Test for agreement 7. Determine resolution -(These stages are those defined by the [Seeds For Change's Consensus Decision Making document](https://seedsforchange.org.uk/consensus). Please use that document as a rough guide for specific steps while we test and firm up our specific requirements, and document them in our [Governance document](./GOVERNANCE.md)) - +(These stages are those defined by the [Seeds For Change's Consensus Decision Making document](https://seedsforchange.org.uk/consensus). Please use that document as a rough guide for specific steps while we test and firm up our specific requirements, and document them in our yet to be created [Governance document](./GOVERNANCE.md)) All decisions that go through the standard consensus process must have an associated GitHub Issue, which allows those unable to attend meetings to participate. The opening comment of the Issue should be kept up to date as to the status of the decision. From 8f1df0f09ec49f81a91ac8b303c75151262e9738 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Apr 2023 15:43:03 +0100 Subject: [PATCH 36/83] Remove (optional) from headings in charter --- CHARTER.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 77a0c7cf..d472fe0d 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -10,7 +10,7 @@ Having no structure in place usually leads to one that is informal and undocumen JSON Schema aims to enable the confident and reliable use of the JSON data format. It does this primarily by providing specification documents which define a declarative language that allows annotation and validation of JSON documents. While JSON Schema's primary target is constraint-based data validation, it continues to be used across the whole stack, in different stages of a given project, and for purposes beyond its original design. We aim to enable these additional and emergent use cases. -### 1.1: In-scope (optional) +### 1.1: In-scope The scope of the JSON Schema project is split into two sections: primary and secondary concerns. Primary concerns are areas we wish to give focus to, while secondary concerns are more likely to require the creation of a Special Interest Group. @@ -42,13 +42,13 @@ Secondary Concerns - Relational validation - Vocabularies registry -### 1.2: Out-of-Scope (optional) +### 1.2: Out-of-Scope Section Intentionally Left Blank ## Section 2: Relationship with OpenJS Foundation CPC. Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). -### 2.1 Other Formal Project Relationships (optional) +### 2.1 Other Formal Project Relationships Section Intentionally Left Blank ## Section 3: JSON Schema Org Governing Body (TSC) @@ -89,7 +89,7 @@ The TSC has final authority over this project including: In joining the TSC, members commit to communicate on a regular basis and respond to issues raised by the TSC in a timely manner. If they are no longer able or willing to make such a commitment, they should discuss this with the TSC or a TSC Chair. -### Section 4.1 Project Operations & Management (optional) +### Section 4.1 Project Operations & Management The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. ### Section 4.2: Decision-making and Voting @@ -206,7 +206,7 @@ Either initially, or at any point during the process, any TSC member may suggest Non-public decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. -### Section 4.3: Other Project Roles (optional) +### Section 4.3: Other Project Roles The JSON Schema project recognises the need for both technical and non-technical roles. While the OpenJS Foundation takes on business responsibilities as the legal entity hosting the project, there are other non-technical responsibilities. @@ -219,7 +219,7 @@ The following responsibilities are recognised as those requiring roles to be def - Education and training - Financial allocation approval, tracking, and auditing -## Section 5: Definitions (optional) +## Section 5: Definitions The JSON Schema project: The project which is housed by the OpenJS Foundation which operates as The JSON Schema Org. The JSON Schema Org: The people, policies, processes, activities, and artifacts, found within the GitHub json-schema-org. From f5dd0f58b4cf8e6b9b146b353f2dd43292202139 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Apr 2023 16:23:24 +0100 Subject: [PATCH 37/83] Add initial TSC members list --- CHARTER.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHARTER.md b/CHARTER.md index d472fe0d..3458dc7b 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -74,6 +74,8 @@ A TSC member may be removed by vote from the TSC if, during a 3-month period, al - They do not participate in any TSC votes - They do not provide any form of excuse or no excuse is known for their absence +The initial TSC members are @relequestual, @awwright, @gregsdennis, @Julian, @jdesrosiers, @karenetheridge, with @relequestual being the initial chair. + ## Section 4: Roles & Responsibilities The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. From d083f46e8e279fb3ee29e3e8ee56b79c7964181e Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Apr 2023 16:25:20 +0100 Subject: [PATCH 38/83] Fix grammar Co-authored-by: Jason Desrosiers --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 3458dc7b..d701eefa 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -60,7 +60,7 @@ Changes to TSC membership should be posted in the agenda, and may be suggested a TSC memberships are not time-limited. -While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (Especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there is no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. +While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (Especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there are no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. TSC members are expected to regularly participate in TSC activities. From 6653e46e038db05dcf9741a54119fda2cde41dc2 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Apr 2023 16:25:49 +0100 Subject: [PATCH 39/83] Fix typo in charter Co-authored-by: Jason Desrosiers --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index d701eefa..7727228c 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -154,7 +154,7 @@ The opening comment of the Issue should be kept up to date as to the status of t Transition between stages may be requested by anyone, but must be called by the facilitator (either a TSC chair or TSC member delegated the facilitator role for a given decision discussion). The stage will be indicated in the opening comment of the Issue and using the appropriate label. -Stages 1 and 6 are required to be open for at least 7 days or until every TSC member has confirmed they wish to progress to the next stage (Progression will still be "called", as above). This includes signals of abstaining given automatically via a notification of period of leave from TSC activity. For stage 2, any TSC member may request a 7 day extension to allow for further consideration. Should there be no reasonable objection (determined by a TSC Chair), the minimum time will be extended by 7 days. A TSC member may request multiple extensions, however lack of justification may result in the TSC member being asked to consider abstaining in stead. There are no other explicit time limits placed on the other stages of the process. +Stages 1 and 6 are required to be open for at least 7 days or until every TSC member has confirmed they wish to progress to the next stage (Progression will still be "called", as above). This includes signals of abstaining given automatically via a notification of period of leave from TSC activity. For stage 2, any TSC member may request a 7 day extension to allow for further consideration. Should there be no reasonable objection (determined by a TSC Chair), the minimum time will be extended by 7 days. A TSC member may request multiple extensions, however lack of justification may result in the TSC member being asked to consider abstaining instead. There are no other explicit time limits placed on the other stages of the process. Most of the discussion should happen within the associated Discussion. The Issue should mostly be used to updated and report progress the consensus process. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in associated Discussion, and any other relevant locations. From c84610a27a6ed1ac026cd786523d0440ef0cba46 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Apr 2023 16:27:42 +0100 Subject: [PATCH 40/83] Apply grammar and typo fixes to charter from PR review Co-authored-by: Jason Desrosiers --- CHARTER.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 7727228c..aaf75353 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -156,14 +156,14 @@ Transition between stages may be requested by anyone, but must be called by the Stages 1 and 6 are required to be open for at least 7 days or until every TSC member has confirmed they wish to progress to the next stage (Progression will still be "called", as above). This includes signals of abstaining given automatically via a notification of period of leave from TSC activity. For stage 2, any TSC member may request a 7 day extension to allow for further consideration. Should there be no reasonable objection (determined by a TSC Chair), the minimum time will be extended by 7 days. A TSC member may request multiple extensions, however lack of justification may result in the TSC member being asked to consider abstaining instead. There are no other explicit time limits placed on the other stages of the process. -Most of the discussion should happen within the associated Discussion. The Issue should mostly be used to updated and report progress the consensus process. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in associated Discussion, and any other relevant locations. +Most of the discussion should happen within the associated Discussion. The Issue should mostly be used to update and report the progress of the consensus process. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in associated Discussion, and any other relevant locations. -Moving to the 'Form a Proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. +Moving to the "Form a Proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. -The "Test for Agreement" step is not voting, and is in stead asking for "signals", which enable the consensus process to continue. +The "Test for Agreement" step is not voting, and is instead asking for "signals", which enable the consensus process to continue. Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. -If someone calls for a Test for Agreement, the facilitator for the decision discussion will review current proposal and may call to Test for Agreement. The facilitator will post a comment on the Issue (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. +If someone calls for a Test for Agreement, the facilitator for the decision discussion will review the current proposal and may call to Test for Agreement. The facilitator will post a comment on the Issue (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the projects core principals or something that would harm the project. @@ -198,7 +198,7 @@ For a vote to carry, a quorum of 75% is required by default. If a TSC member wants to call for a vote that they wish to be non-public, they must do so by contacting the TSC Chairs directly. At the discretion of the TSC Chairs, a vote may be made non-public, and will then be handled by creating an Issue in the 'TSC-private' repository. -The topic and nature of non-public votes may remain non-public, including the results.(It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) +The topic and nature of non-public votes may remain non-public, including the results. (It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) #### Documenting decisions @@ -210,9 +210,9 @@ Non-public decisions should be documented (as an ADR or otherwise) in the privat ### Section 4.3: Other Project Roles -The JSON Schema project recognises the need for both technical and non-technical roles. While the OpenJS Foundation takes on business responsibilities as the legal entity hosting the project, there are other non-technical responsibilities. +The JSON Schema project recognizes the need for both technical and non-technical roles. While the OpenJS Foundation takes on business responsibilities as the legal entity hosting the project, there are other non-technical responsibilities. -The TSC will look to create other roles as appropriate, and may update this document in accordance with the requirements for doing so, to formally recognise the additional roles. +The TSC will look to create other roles as appropriate, and may update this document in accordance with the requirements for doing so, to formally recognize the additional roles. The following responsibilities are recognised as those requiring roles to be defined by the TSC: - Community and Industry connections From a4943cdd44f709f461fe673191961fbcabe67fb8 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 17 Apr 2023 11:56:51 +0100 Subject: [PATCH 41/83] Remove specific TSC member requirement about meetings --- CHARTER.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index aaf75353..bd223477 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -70,8 +70,7 @@ The TSC may, at its discretion, invite any number of non-voting observers to par A TSC member may be removed by vote from the TSC if, during a 3-month period, all of the following are true: -- They attend fewer than 25% of the regularly scheduled meetings -- They do not participate in any TSC votes +- They do not participate in any TSC related discussions or votes - They do not provide any form of excuse or no excuse is known for their absence The initial TSC members are @relequestual, @awwright, @gregsdennis, @Julian, @jdesrosiers, @karenetheridge, with @relequestual being the initial chair. From 94d1801d4d133bba5d7396b6b463f3687e802ca9 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 17 Apr 2023 16:44:08 +0100 Subject: [PATCH 42/83] Fix double typo with thanks to @mwadams --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index bd223477..f877b877 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -164,7 +164,7 @@ Voting should be considered a last resort if the consensus process has failed fo If someone calls for a Test for Agreement, the facilitator for the decision discussion will review the current proposal and may call to Test for Agreement. The facilitator will post a comment on the Issue (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. -The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the projects core principals or something that would harm the project. +The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the project's core principles or something that would harm the project. The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. If the blocker/s are unable or unwilling to participate in attempts to find a solution, after multiple attempts, the original proposal is moved to a vote, as defined in this document, but additionally requiring a 75% super majority to pass. This will be at the discretion of the TSC Chairs. From c9ab2dd354434de638517ffe320a3d787ed45359 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 18 Apr 2023 09:02:27 +0100 Subject: [PATCH 43/83] List names and links for the TSC members Co-authored-by: Greg Dennis --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index f877b877..f3c2f521 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -73,7 +73,7 @@ A TSC member may be removed by vote from the TSC if, during a 3-month period, al - They do not participate in any TSC related discussions or votes - They do not provide any form of excuse or no excuse is known for their absence -The initial TSC members are @relequestual, @awwright, @gregsdennis, @Julian, @jdesrosiers, @karenetheridge, with @relequestual being the initial chair. +The initial TSC members are [Ben Hutton](https://github.com/relequestual), [Austin Wright](https://github.com/awwright), [Greg Dennis](https://github.com/gregsdennis), [Julian Berman](https://github.com/Julian), [Jason Desrosiers](https://github.com/jdesrosiers), and [Karen Etheridge](https://github.com/karenetheridge), with Ben Hutton being the initial chair. ## Section 4: Roles & Responsibilities The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. From b5f0e856fb65eef4d9f7ba98a162001688ae967c Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 18 Apr 2023 09:04:31 +0100 Subject: [PATCH 44/83] Fix typo and quotes in charter Co-authored-by: Greg Dennis --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index f3c2f521..ff8e42ab 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -105,7 +105,7 @@ When a TSC member looks for an issue to be discussed and a decision to be made, Both the Quick and Standard consensus process require the creation of an Issue in the TSC GitHub repository. The Issue must: - Include brief introductory information about the decision that needs to be made -- Be labelled with 'tsc-decision' +- Be labeled with `tsc-decision` - Use the provided template, unless there is a good reason not to do so At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signalling or voting. The TSC member must detail when they expect to return. From b2efdce79a721708c8631a35ff5f80127c7ce552 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 18 Apr 2023 09:06:24 +0100 Subject: [PATCH 45/83] Fix typos and quotes in charter Apply suggestions from review Co-authored-by: Greg Dennis --- CHARTER.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index ff8e42ab..cccc8125 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -108,18 +108,18 @@ The Issue must: - Be labeled with `tsc-decision` - Use the provided template, unless there is a good reason not to do so -At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signalling or voting. The TSC member must detail when they expect to return. +At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signaling or voting. The TSC member must detail when they expect to return. ##### Quick consensus process In the event a TSC member feels the need for a decision to be expedited, they may create the decision discussion, indicating that they wish to use the quick process rather than the standard consensus process. This should be done by creating a new Issue in the TSC repository. -In addition to the requirements above, the Issue must be labelled 'expedited'. +In addition to the requirements above, the Issue must be labeled `expedited`. -While an associated Discussion is not required, if one is used, it must be clearly linked in both directions, and be labelled with 'tsc-decision'. +While an associated Discussion is not required, if one is used, it must be clearly linked in both directions, and be labeled with `tsc-decision`. A vote is called to see if other members agree. The vote takes place on the opening comment. This vote is different from the decision-making voting process, and only requires 3 (additional) votes in favour and none against to carry. If the vote carries, the quick process is started, otherwise the standard consensus process is started. -The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for (in a follow up comment on the Issue. Not in the opening comment.), and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. (Label 'expedited' should be removed and 'stage-1' added.) +The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for (in a follow up comment on the Issue. Not in the opening comment.), and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. (Label `expedited` should be removed and `stage-1` added.) ##### Standard consensus process @@ -128,13 +128,13 @@ The standard consensus process is designed for all non-trivial decisions. A decision discussion may be started by creating an Issue and Discussion in the TSC repository. In addition to the requirements above, the Issue must: -- Be labelled with 'stage-1' +- Be labeled with `stage-1` - Link to the associated initial Discussion The Discussion must: - Link to the associated Issue - Include detailed introductory information about the decision that needs to be made -- Be labelled with 'tsc-decision' +- Be labeled with `tsc-decision` The standard consensus process should progress through the following seven stages. @@ -175,7 +175,7 @@ Reports must remain anonymous, as per the Code of Conduct. The other signals that may be made when a Test For Agreement is called include "Reservations" and "Stand Aside". Both are signals which convey consent to let the proposal pass, however they may be conditional. -Signalling "Reservations" means an agreement on the overall direction, however there is some desire to revise or amend the proposal somewhat. It is expected that the individuals signalling "Reservations" want to engage in reworking the proposal. The facilitator will check with each individual regarding the strength of the reservation, and later facilitate or direct discussion as required to amend and represent the proposal. If the individual/s do not wish to participate in reworking the proposal, their reservations should be logged as part of the decision record as unresolved. +Signaling "Reservations" means an agreement on the overall direction, however there is some desire to revise or amend the proposal somewhat. It is expected that the individuals signalling "Reservations" want to engage in reworking the proposal. The facilitator will check with each individual regarding the strength of the reservation, and later facilitate or direct discussion as required to amend and represent the proposal. If the individual/s do not wish to participate in reworking the proposal, their reservations should be logged as part of the decision record as unresolved. If "Reservations" is signalled three consecutive times by the same individual/s, anyone may call for no further attempts to remediate the reservations, and the proposal will pass. @@ -195,7 +195,7 @@ Voting will by default close after 7 days. Any member of the TSC may request a 7 For a vote to carry, a quorum of 75% is required by default. If a TSC member wants to call for a vote that they wish to be non-public, they must do so by contacting the TSC Chairs directly. -At the discretion of the TSC Chairs, a vote may be made non-public, and will then be handled by creating an Issue in the 'TSC-private' repository. +At the discretion of the TSC Chairs, a vote may be made non-public, and will then be handled by creating an Issue in the `TSC-private` repository. The topic and nature of non-public votes may remain non-public, including the results. (It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) @@ -221,6 +221,7 @@ The following responsibilities are recognised as those requiring roles to be def - Financial allocation approval, tracking, and auditing ## Section 5: Definitions + The JSON Schema project: The project which is housed by the OpenJS Foundation which operates as The JSON Schema Org. The JSON Schema Org: The people, policies, processes, activities, and artifacts, found within the GitHub json-schema-org. From d2f853c575eff980bb750bdcbb45818a83228ce4 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 18 Apr 2023 09:40:40 +0100 Subject: [PATCH 46/83] Fix grammar in charter Co-authored-by: Greg Dennis --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index cccc8125..26dd0dcc 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -60,7 +60,7 @@ Changes to TSC membership should be posted in the agenda, and may be suggested a TSC memberships are not time-limited. -While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (Especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there are no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. +While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there are no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. TSC members are expected to regularly participate in TSC activities. From 035ab9b529c607b2349601cfcdf0cc7cf9deccb1 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 18 Apr 2023 10:04:59 +0100 Subject: [PATCH 47/83] Remove 'section' from titles --- CHARTER.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 26dd0dcc..28bfe2dc 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -1,12 +1,12 @@ # JSON Schema Org Charter -## Section 0: Guiding Principles +## 0: Guiding Principles The JSON Schema project is part of the OpenJS Foundation which operates transparently, openly, collaboratively, and ethically. We strive to be open and transparent as much as is possible, and wish to enable anyone to interact and engage with any area of our work. Having no structure in place usually leads to one that is informal and undocumented, making it difficult to meet our own expectations of how we wish to operate. As such, we define the following charter which includes aspects of the governance model to which we subscribe and by which we operate. -## Section 1: Scope +## 1: Scope JSON Schema aims to enable the confident and reliable use of the JSON data format. It does this primarily by providing specification documents which define a declarative language that allows annotation and validation of JSON documents. While JSON Schema's primary target is constraint-based data validation, it continues to be used across the whole stack, in different stages of a given project, and for purposes beyond its original design. We aim to enable these additional and emergent use cases. @@ -45,13 +45,13 @@ Secondary Concerns ### 1.2: Out-of-Scope Section Intentionally Left Blank -## Section 2: Relationship with OpenJS Foundation CPC. +## 2: Relationship with OpenJS Foundation CPC. Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). ### 2.1 Other Formal Project Relationships Section Intentionally Left Blank -## Section 3: JSON Schema Org Governing Body (TSC) +## 3: JSON Schema Org Governing Body (TSC) The TSC is initially established from the observed major contributors who are currently active and in good standing. There is no maximum TSC membership size. The TSC must have a minimum of four members. @@ -75,7 +75,7 @@ A TSC member may be removed by vote from the TSC if, during a 3-month period, al The initial TSC members are [Ben Hutton](https://github.com/relequestual), [Austin Wright](https://github.com/awwright), [Greg Dennis](https://github.com/gregsdennis), [Julian Berman](https://github.com/Julian), [Jason Desrosiers](https://github.com/jdesrosiers), and [Karen Etheridge](https://github.com/karenetheridge), with Ben Hutton being the initial chair. -## Section 4: Roles & Responsibilities +## 4: Roles & Responsibilities The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. The TSC has final authority over this project including: @@ -90,10 +90,10 @@ The TSC has final authority over this project including: In joining the TSC, members commit to communicate on a regular basis and respond to issues raised by the TSC in a timely manner. If they are no longer able or willing to make such a commitment, they should discuss this with the TSC or a TSC Chair. -### Section 4.1 Project Operations & Management +### 4.1 Project Operations & Management The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. -### Section 4.2: Decision-making and Voting +### 4.2: Decision-making and Voting The TSC follows a formal consensus seeking decision making model. In some situations, a vote may be preferable, however a vote will not be used to make the vast majority of decisions. In the unlikely case where it seems that consensus cannot be reached after multiple attempts, the decision process may be moved to resolve via a vote. This is not expected to happen, but defined as a backup. @@ -207,7 +207,7 @@ Either initially, or at any point during the process, any TSC member may suggest Non-public decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. -### Section 4.3: Other Project Roles +### 4.3: Other Project Roles The JSON Schema project recognizes the need for both technical and non-technical roles. While the OpenJS Foundation takes on business responsibilities as the legal entity hosting the project, there are other non-technical responsibilities. @@ -220,7 +220,7 @@ The following responsibilities are recognised as those requiring roles to be def - Education and training - Financial allocation approval, tracking, and auditing -## Section 5: Definitions +## 5: Definitions The JSON Schema project: The project which is housed by the OpenJS Foundation which operates as The JSON Schema Org. From dc3e6857f9ff00bf7acf07fdd1704f3bb0cae116 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 18 Apr 2023 10:18:34 +0100 Subject: [PATCH 48/83] Fix language specific spellings in charter --- CHARTER.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 28bfe2dc..e5c5a80c 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -175,11 +175,11 @@ Reports must remain anonymous, as per the Code of Conduct. The other signals that may be made when a Test For Agreement is called include "Reservations" and "Stand Aside". Both are signals which convey consent to let the proposal pass, however they may be conditional. -Signaling "Reservations" means an agreement on the overall direction, however there is some desire to revise or amend the proposal somewhat. It is expected that the individuals signalling "Reservations" want to engage in reworking the proposal. The facilitator will check with each individual regarding the strength of the reservation, and later facilitate or direct discussion as required to amend and represent the proposal. If the individual/s do not wish to participate in reworking the proposal, their reservations should be logged as part of the decision record as unresolved. +Signaling "Reservations" means an agreement on the overall direction, however there is some desire to revise or amend the proposal somewhat. It is expected that the individuals signaling "Reservations" want to engage in reworking the proposal. The facilitator will check with each individual regarding the strength of the reservation, and later facilitate or direct discussion as required to amend and represent the proposal. If the individual/s do not wish to participate in reworking the proposal, their reservations should be logged as part of the decision record as unresolved. If "Reservations" is signalled three consecutive times by the same individual/s, anyone may call for no further attempts to remediate the reservations, and the proposal will pass. -Signalling "Stand Aside" convey consent, but an unwillingness for whatever reason to be further involved. It could be for example that the individual does not have time to participate, or that they have limited opinions on the specific decision. The individual may provide a reason for standing aside. If the individual believes the reason can be remedied by the group, the group should seek to remedy the reason where possible, with help from the facilitator. +Signaling "Stand Aside" convey consent, but an unwillingness for whatever reason to be further involved. It could be for example that the individual does not have time to participate, or that they have limited opinions on the specific decision. The individual may provide a reason for standing aside. If the individual believes the reason can be remedied by the group, the group should seek to remedy the reason where possible, with help from the facilitator. The TSC will make every reasonable effort to reach unanimity based consensus. If unanimity seems unlikely after several failed attempts to revise the proposal and Test for Agreement, if the proposal is clear, the decision may be moved to a vote, at the discretion of the TSC Chairs. This is a last resort. @@ -213,7 +213,7 @@ The JSON Schema project recognizes the need for both technical and non-technical The TSC will look to create other roles as appropriate, and may update this document in accordance with the requirements for doing so, to formally recognize the additional roles. -The following responsibilities are recognised as those requiring roles to be defined by the TSC: +The following responsibilities are recognized as those requiring roles to be defined by the TSC: - Community and Industry connections - Brand awareness, recognition, and health - Strategic allocation of funds and budgeting for investment in JSON Schema and its ecosystem From 631db8cc8a61a14e48e7f4fcb0e7569155006d99 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 18 Apr 2023 10:32:03 +0100 Subject: [PATCH 49/83] Specifically mention specifications we use and that use us as out of scope in the charter --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index e5c5a80c..876100fb 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -43,7 +43,7 @@ Secondary Concerns - Vocabularies registry ### 1.2: Out-of-Scope -Section Intentionally Left Blank +While the JSON Schema project has no control over the specifications it uses (such as JSON and IRI), nor specifications that use JSON Schema (such as OpenAPI and AsyncAPI), the JSON Schema project has, and continues to, provide expert opinion, advice, and support, as time allows. We recognize the importance and value of the ecosystem surrounding JSON Schema, and we encourage those developing standards and tooling to reach out at any time. ## 2: Relationship with OpenJS Foundation CPC. Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). From 8eb98838ac3fecd35e6c3fbc6ffb30a7bd92ccd9 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 24 Apr 2023 14:12:28 +0100 Subject: [PATCH 50/83] Do not reference 'JSON Schema Org' Just JSON Schema is fine, and we don't need to differenciate between the project and the org. https://github.com/json-schema-org/community/pull/325\#discussion_r1174052120 --- CHARTER.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 876100fb..e5c68355 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -1,4 +1,4 @@ -# JSON Schema Org Charter +# JSON Schema Charter ## 0: Guiding Principles @@ -51,7 +51,7 @@ Most large, complex open source communities have both a business and a technical ### 2.1 Other Formal Project Relationships Section Intentionally Left Blank -## 3: JSON Schema Org Governing Body (TSC) +## 3: JSON Schema Governing Body (TSC) The TSC is initially established from the observed major contributors who are currently active and in good standing. There is no maximum TSC membership size. The TSC must have a minimum of four members. @@ -222,10 +222,6 @@ The following responsibilities are recognized as those requiring roles to be def ## 5: Definitions -The JSON Schema project: The project which is housed by the OpenJS Foundation which operates as The JSON Schema Org. - -The JSON Schema Org: The people, policies, processes, activities, and artifacts, found within the GitHub json-schema-org. - TSC: The Technical Steering Committee, delegated technical leadership for the JSON Schema project by the OpenJS Foundation. --- From 341ecefac65d5fd667bf00ee5d29b7416dd4da08 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 25 Apr 2023 14:07:08 +0100 Subject: [PATCH 51/83] Do not define what the OpenJS Foundation does, per feedback from the foundation --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index e5c68355..4619fe48 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -2,7 +2,7 @@ ## 0: Guiding Principles -The JSON Schema project is part of the OpenJS Foundation which operates transparently, openly, collaboratively, and ethically. We strive to be open and transparent as much as is possible, and wish to enable anyone to interact and engage with any area of our work. +The JSON Schema project is part of the OpenJS Foundation. The JSON Schema project strives to be open and transparent as much as is possible, and wish to enable anyone to interact and engage with any area of our work. Having no structure in place usually leads to one that is informal and undocumented, making it difficult to meet our own expectations of how we wish to operate. As such, we define the following charter which includes aspects of the governance model to which we subscribe and by which we operate. From f4e35ff6079fdbe33e274032e5978069731761fc Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 25 Apr 2023 14:15:49 +0100 Subject: [PATCH 52/83] Remove mention of fund and budgeting, as the charter is about the foundation passing technical leadership, and funds are business related --- CHARTER.md | 1 - 1 file changed, 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 4619fe48..58ebc810 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -216,7 +216,6 @@ The TSC will look to create other roles as appropriate, and may update this docu The following responsibilities are recognized as those requiring roles to be defined by the TSC: - Community and Industry connections - Brand awareness, recognition, and health -- Strategic allocation of funds and budgeting for investment in JSON Schema and its ecosystem - Education and training - Financial allocation approval, tracking, and auditing From e94c0cb050770fe06294bf894a964f2c884efb5f Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 25 Apr 2023 14:16:29 +0100 Subject: [PATCH 53/83] Remove mention of finances as per last commit --- CHARTER.md | 1 - 1 file changed, 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 58ebc810..07dbe515 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -217,7 +217,6 @@ The following responsibilities are recognized as those requiring roles to be def - Community and Industry connections - Brand awareness, recognition, and health - Education and training -- Financial allocation approval, tracking, and auditing ## 5: Definitions From 9e1ad26bfe30cabd0bd387f07250627acf09d74c Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 25 Apr 2023 14:19:14 +0100 Subject: [PATCH 54/83] Remove mention of special interest groups in favour of noting the community would need to drive the work --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 07dbe515..8aef94ad 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -12,7 +12,7 @@ While JSON Schema's primary target is constraint-based data validation, it conti ### 1.1: In-scope The scope of the JSON Schema project is split into two sections: primary and secondary concerns. -Primary concerns are areas we wish to give focus to, while secondary concerns are more likely to require the creation of a Special Interest Group. +Primary concerns are areas we wish to give focus to, while secondary concerns are more likely to require the desire of the community to drive the work. Primary Concerns - Publication of the JSON Schema standard From 52bedb32e516f6973b3119ab228ae80c9817e073 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 26 Apr 2023 11:30:57 +0100 Subject: [PATCH 55/83] Loosen TSC meeting expectations Co-authored-by: Matteo Collina --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 8aef94ad..e07a2c0a 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -64,7 +64,7 @@ While the project is not looking to obtain "Impact" project status within the Op TSC members are expected to regularly participate in TSC activities. -The TSC will meet regularly using virtual conferencing tools. The meeting will be directed by the TSC Chairperson(s). Responsibility for directing individual meetings may be delegated by a TSC Chairperson to any other TSC member. Minutes or an appropriate recording will be taken and made available to the community through accessible public postings. +When the TSC meets using virtual conferencing tools, the meeting will be directed by the TSC Chairperson(s). Responsibility for directing individual meetings may be delegated by a TSC Chairperson to any other TSC member. Minutes or an appropriate recording will be taken and made available to the community through accessible public postings. The TSC may, at its discretion, invite any number of non-voting observers to participate in the public portion of TSC discussions and meetings. From 4a2ad4a688fb6719cd328b05b9cebe5fcb374b5b Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 25 Apr 2023 14:32:00 +0100 Subject: [PATCH 56/83] Intro section better reflects the JSON Schema projects relationship with the OpenJS Foundation CPC and Board. --- CHARTER.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index e07a2c0a..f5ab1436 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -4,7 +4,9 @@ ## 0: Guiding Principles The JSON Schema project is part of the OpenJS Foundation. The JSON Schema project strives to be open and transparent as much as is possible, and wish to enable anyone to interact and engage with any area of our work. -Having no structure in place usually leads to one that is informal and undocumented, making it difficult to meet our own expectations of how we wish to operate. As such, we define the following charter which includes aspects of the governance model to which we subscribe and by which we operate. +Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). OpenJS Foundation's business leadership is the Board of Directors (the "Board"). + +Having no structure in place usually leads to one that is informal and undocumented, making it difficult to meet our own expectations of how the TSC wish to operate. As such, the JSON Schema project define the following charter which includes aspects of the governance model to which the TSC subscribe and by which the TSC operate. ## 1: Scope JSON Schema aims to enable the confident and reliable use of the JSON data format. It does this primarily by providing specification documents which define a declarative language that allows annotation and validation of JSON documents. @@ -43,7 +45,7 @@ Secondary Concerns - Vocabularies registry ### 1.2: Out-of-Scope -While the JSON Schema project has no control over the specifications it uses (such as JSON and IRI), nor specifications that use JSON Schema (such as OpenAPI and AsyncAPI), the JSON Schema project has, and continues to, provide expert opinion, advice, and support, as time allows. We recognize the importance and value of the ecosystem surrounding JSON Schema, and we encourage those developing standards and tooling to reach out at any time. +While the JSON Schema project has no control over the specifications it uses (such as JSON and IRI), nor specifications that use JSON Schema (such as OpenAPI and AsyncAPI), the JSON Schema project has, and continues to, provide expert opinion, advice, and support, as time allows. JSON Schema recognizes the importance and value of the ecosystem surrounding JSON Schema, and JSON Schema encourage those developing standards and tooling to reach out at any time. ## 2: Relationship with OpenJS Foundation CPC. Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). From 397a8d111e7f799a3d29046bf38b0463dbf69094 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 3 May 2023 21:21:50 +0100 Subject: [PATCH 57/83] Don't use 'we' and use proper pronouns --- CHARTER.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index f5ab1436..ca013c09 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -10,11 +10,11 @@ Having no structure in place usually leads to one that is informal and undocumen ## 1: Scope JSON Schema aims to enable the confident and reliable use of the JSON data format. It does this primarily by providing specification documents which define a declarative language that allows annotation and validation of JSON documents. -While JSON Schema's primary target is constraint-based data validation, it continues to be used across the whole stack, in different stages of a given project, and for purposes beyond its original design. We aim to enable these additional and emergent use cases. +While JSON Schema's primary target is constraint-based data validation, it continues to be used across the whole stack, in different stages of a given project, and for purposes beyond its original design. The JSON Schema project aims to enable these additional and emergent use cases. ### 1.1: In-scope The scope of the JSON Schema project is split into two sections: primary and secondary concerns. -Primary concerns are areas we wish to give focus to, while secondary concerns are more likely to require the desire of the community to drive the work. +Primary concerns are areas the JSON Schema project wish to give focus to, while secondary concerns are more likely to require the desire of the community to drive the work. Primary Concerns - Publication of the JSON Schema standard @@ -148,7 +148,7 @@ The standard consensus process should progress through the following seven stage 6. Test for agreement 7. Determine resolution -(These stages are those defined by the [Seeds For Change's Consensus Decision Making document](https://seedsforchange.org.uk/consensus). Please use that document as a rough guide for specific steps while we test and firm up our specific requirements, and document them in our yet to be created [Governance document](./GOVERNANCE.md)) +(These stages are those defined by the [Seeds For Change's Consensus Decision Making document](https://seedsforchange.org.uk/consensus). Please use that document as a rough guide for specific steps while the JSON Schema project tests and firms up our specific requirements, and document them in our yet to be created [Governance document](./GOVERNANCE.md)) All decisions that go through the standard consensus process must have an associated GitHub Issue, which allows those unable to attend meetings to participate. The opening comment of the Issue should be kept up to date as to the status of the decision. From d79198e6d61fe215f73103bbceafa348c9c58ff1 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 3 May 2023 22:13:10 +0100 Subject: [PATCH 58/83] Move the list of initial TSC members outside of the charter document --- CHARTER.md | 2 -- TSC.md | 3 +++ 2 files changed, 3 insertions(+), 2 deletions(-) create mode 100644 TSC.md diff --git a/CHARTER.md b/CHARTER.md index ca013c09..8727ede5 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -75,8 +75,6 @@ A TSC member may be removed by vote from the TSC if, during a 3-month period, al - They do not participate in any TSC related discussions or votes - They do not provide any form of excuse or no excuse is known for their absence -The initial TSC members are [Ben Hutton](https://github.com/relequestual), [Austin Wright](https://github.com/awwright), [Greg Dennis](https://github.com/gregsdennis), [Julian Berman](https://github.com/Julian), [Jason Desrosiers](https://github.com/jdesrosiers), and [Karen Etheridge](https://github.com/karenetheridge), with Ben Hutton being the initial chair. - ## 4: Roles & Responsibilities The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. diff --git a/TSC.md b/TSC.md new file mode 100644 index 00000000..13165f70 --- /dev/null +++ b/TSC.md @@ -0,0 +1,3 @@ +This file lists the members of the JSON Schema Technical Steering Committee (TSC). + +The initial TSC members are [Ben Hutton](https://github.com/relequestual), [Austin Wright](https://github.com/awwright), [Greg Dennis](https://github.com/gregsdennis), [Julian Berman](https://github.com/Julian), [Jason Desrosiers](https://github.com/jdesrosiers), and [Karen Etheridge](https://github.com/karenetheridge), with Ben Hutton being the initial chair. \ No newline at end of file From 59deddb83ea82d732995fbbe7f3edbb31766be85 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 3 May 2023 22:35:18 +0100 Subject: [PATCH 59/83] Use 'private' as opposed to 'non-public' --- CHARTER.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 8727ede5..69343eb4 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -100,7 +100,7 @@ In the unlikely case where it seems that consensus cannot be reached after multi #### Decision-making via consensus -When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a non-public discussion and decision. The TSC member must reach out to the TSC chairs to request a non-public discussion and decision. A discussion and decision will be non-public at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be non-public in rare circumstances. +When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a private discussion and decision. The TSC member must reach out to the TSC chairs to request a private discussion and decision. A discussion and decision will be private at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be private in rare circumstances. Both the Quick and Standard consensus process require the creation of an Issue in the TSC GitHub repository. The Issue must: @@ -194,10 +194,10 @@ Voting will by default close after 7 days. Any member of the TSC may request a 7 For a vote to carry, a quorum of 75% is required by default. -If a TSC member wants to call for a vote that they wish to be non-public, they must do so by contacting the TSC Chairs directly. -At the discretion of the TSC Chairs, a vote may be made non-public, and will then be handled by creating an Issue in the `TSC-private` repository. +If a TSC member wants to call for a vote that they wish to be private, they must do so by contacting the TSC Chairs directly. +At the discretion of the TSC Chairs, a vote may be made private, and will then be handled by creating an Issue in the `TSC-private` repository. -The topic and nature of non-public votes may remain non-public, including the results. (It is expected that vast majority of votes will be public. Non-public voting should only be used in exceptional circumstances.) +The topic and nature of private votes may remain private, including the results. (It is expected that vast majority of votes will be public. Private voting should only be used in exceptional circumstances.) #### Documenting decisions @@ -205,7 +205,7 @@ Either initially, or at any point during the process, any TSC member may suggest (The quick consensus process does not require an Any Decision Record, but the decision should be minuted.) -Non-public decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. +Private decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. ### 4.3: Other Project Roles From f1974e2a845cf6831b373034bd00782b02fb162d Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 15 Jun 2023 15:29:20 +0100 Subject: [PATCH 60/83] Remove the explicit mention of ingesting tooling into the project --- CHARTER.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 69343eb4..588d0b90 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -22,9 +22,6 @@ Primary Concerns - Semantic annotation of JSON data - Extensibility - Critical tooling - - Creation of new - - Ingestion of existing - - Long term support - Documentation - Test suite - Community From c872a5fce6cf979304549aba22a4a1b9d4203064 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 16 Jun 2023 16:41:28 +0100 Subject: [PATCH 61/83] Note what kinds of discussions and votes can and should be made private --- CHARTER.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CHARTER.md b/CHARTER.md index 588d0b90..21cae887 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -99,6 +99,8 @@ In the unlikely case where it seems that consensus cannot be reached after multi When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a private discussion and decision. The TSC member must reach out to the TSC chairs to request a private discussion and decision. A discussion and decision will be private at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be private in rare circumstances. +The kinds of discussions which should be private include security reports or discussions with an entity where it might not be desireable to be made public knowledge to either party. This could include details of case studies or partnerships which are not yet concluded or published, where either party may need a final approval for publication or wishes for coordinated or scheduled public publication. + Both the Quick and Standard consensus process require the creation of an Issue in the TSC GitHub repository. The Issue must: - Include brief introductory information about the decision that needs to be made @@ -196,6 +198,8 @@ At the discretion of the TSC Chairs, a vote may be made private, and will then b The topic and nature of private votes may remain private, including the results. (It is expected that vast majority of votes will be public. Private voting should only be used in exceptional circumstances.) +The kinds of votes which should be private include things related to security reports or discussions with an entity where it might not be desireable to be made public knowledge to either party. This could include details of case studies or partnerships which are not yet concluded or published, where either party may need a final approval for publication or wishes for coordinated or scheduled public publication. + #### Documenting decisions Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." From a9741176e0c878d0d78f1fcd7e91107e353c9c7a Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 16 Jun 2023 16:43:12 +0100 Subject: [PATCH 62/83] Move the paragraph about TSC period of leave to membership section --- CHARTER.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 21cae887..d57fc216 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -65,6 +65,8 @@ TSC members are expected to regularly participate in TSC activities. When the TSC meets using virtual conferencing tools, the meeting will be directed by the TSC Chairperson(s). Responsibility for directing individual meetings may be delegated by a TSC Chairperson to any other TSC member. Minutes or an appropriate recording will be taken and made available to the community through accessible public postings. +At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signaling or voting. The TSC member must detail when they expect to return. + The TSC may, at its discretion, invite any number of non-voting observers to participate in the public portion of TSC discussions and meetings. A TSC member may be removed by vote from the TSC if, during a 3-month period, all of the following are true: @@ -107,8 +109,6 @@ The Issue must: - Be labeled with `tsc-decision` - Use the provided template, unless there is a good reason not to do so -At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signaling or voting. The TSC member must detail when they expect to return. - ##### Quick consensus process In the event a TSC member feels the need for a decision to be expedited, they may create the decision discussion, indicating that they wish to use the quick process rather than the standard consensus process. This should be done by creating a new Issue in the TSC repository. From 86ff12e8219fdd0f1d3066cfd5705bd4acd6cc10 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 23 Jun 2023 11:55:37 +0100 Subject: [PATCH 63/83] Create governance document and move governance and process related content out of the charter and into the governance document. View this diff locally using --color-moved to see content is moved but unedited --- CHARTER.md | 151 ++------------------------------------------ GOVERNANCE.md | 171 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 175 insertions(+), 147 deletions(-) create mode 100644 GOVERNANCE.md diff --git a/CHARTER.md b/CHARTER.md index d57fc216..57558d5a 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -51,43 +51,12 @@ Most large, complex open source communities have both a business and a technical Section Intentionally Left Blank ## 3: JSON Schema Governing Body (TSC) -The TSC is initially established from the observed major contributors who are currently active and in good standing. -There is no maximum TSC membership size. The TSC must have a minimum of four members. - -Changes to TSC membership should be posted in the agenda, and may be suggested as any other agenda item. - -TSC memberships are not time-limited. - -While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there are no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. - -TSC members are expected to regularly participate in TSC activities. - -When the TSC meets using virtual conferencing tools, the meeting will be directed by the TSC Chairperson(s). Responsibility for directing individual meetings may be delegated by a TSC Chairperson to any other TSC member. Minutes or an appropriate recording will be taken and made available to the community through accessible public postings. - -At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signaling or voting. The TSC member must detail when they expect to return. - -The TSC may, at its discretion, invite any number of non-voting observers to participate in the public portion of TSC discussions and meetings. - -A TSC member may be removed by vote from the TSC if, during a 3-month period, all of the following are true: - -- They do not participate in any TSC related discussions or votes -- They do not provide any form of excuse or no excuse is known for their absence +See GOVERNANCE.md ## 4: Roles & Responsibilities -The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. - -The TSC has final authority over this project including: - -- Technical direction -- Project governance and process (including this policy) -- Contribution policy -- GitHub repository hosting and administration -- Establishment of and delegation to working groups or teams -- Mediating technical conflicts -- Mediating non-technical conflicts (until a formal Code of Conduct Committee is established) -In joining the TSC, members commit to communicate on a regular basis and respond to issues raised by the TSC in a timely manner. If they are no longer able or willing to make such a commitment, they should discuss this with the TSC or a TSC Chair. +See GOVERNANCE.md ### 4.1 Project Operations & Management The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. @@ -97,116 +66,9 @@ The TSC follows a formal consensus seeking decision making model. In some situations, a vote may be preferable, however a vote will not be used to make the vast majority of decisions. In the unlikely case where it seems that consensus cannot be reached after multiple attempts, the decision process may be moved to resolve via a vote. This is not expected to happen, but defined as a backup. -#### Decision-making via consensus - -When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a private discussion and decision. The TSC member must reach out to the TSC chairs to request a private discussion and decision. A discussion and decision will be private at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be private in rare circumstances. - -The kinds of discussions which should be private include security reports or discussions with an entity where it might not be desireable to be made public knowledge to either party. This could include details of case studies or partnerships which are not yet concluded or published, where either party may need a final approval for publication or wishes for coordinated or scheduled public publication. - -Both the Quick and Standard consensus process require the creation of an Issue in the TSC GitHub repository. -The Issue must: -- Include brief introductory information about the decision that needs to be made -- Be labeled with `tsc-decision` -- Use the provided template, unless there is a good reason not to do so - -##### Quick consensus process - -In the event a TSC member feels the need for a decision to be expedited, they may create the decision discussion, indicating that they wish to use the quick process rather than the standard consensus process. This should be done by creating a new Issue in the TSC repository. -In addition to the requirements above, the Issue must be labeled `expedited`. - -While an associated Discussion is not required, if one is used, it must be clearly linked in both directions, and be labeled with `tsc-decision`. - -A vote is called to see if other members agree. The vote takes place on the opening comment. This vote is different from the decision-making voting process, and only requires 3 (additional) votes in favour and none against to carry. If the vote carries, the quick process is started, otherwise the standard consensus process is started. - -The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for (in a follow up comment on the Issue. Not in the opening comment.), and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. (Label `expedited` should be removed and `stage-1` added.) - -##### Standard consensus process - -The standard consensus process is designed for all non-trivial decisions. - -A decision discussion may be started by creating an Issue and Discussion in the TSC repository. - -In addition to the requirements above, the Issue must: -- Be labeled with `stage-1` -- Link to the associated initial Discussion - -The Discussion must: -- Link to the associated Issue -- Include detailed introductory information about the decision that needs to be made -- Be labeled with `tsc-decision` - -The standard consensus process should progress through the following seven stages. - -1. Introduction and clarify the issue -2. Open the discussion - Share needs and perspectives on the issue -3. Explore ideas in a broad discussion -4. Form a proposal -5. Amend the proposal -6. Test for agreement -7. Determine resolution - -(These stages are those defined by the [Seeds For Change's Consensus Decision Making document](https://seedsforchange.org.uk/consensus). Please use that document as a rough guide for specific steps while the JSON Schema project tests and firms up our specific requirements, and document them in our yet to be created [Governance document](./GOVERNANCE.md)) - -All decisions that go through the standard consensus process must have an associated GitHub Issue, which allows those unable to attend meetings to participate. -The opening comment of the Issue should be kept up to date as to the status of the decision. +#### Decision-making via consensus and voting, and documenting decisions -Transition between stages may be requested by anyone, but must be called by the facilitator (either a TSC chair or TSC member delegated the facilitator role for a given decision discussion). The stage will be indicated in the opening comment of the Issue and using the appropriate label. - -Stages 1 and 6 are required to be open for at least 7 days or until every TSC member has confirmed they wish to progress to the next stage (Progression will still be "called", as above). This includes signals of abstaining given automatically via a notification of period of leave from TSC activity. For stage 2, any TSC member may request a 7 day extension to allow for further consideration. Should there be no reasonable objection (determined by a TSC Chair), the minimum time will be extended by 7 days. A TSC member may request multiple extensions, however lack of justification may result in the TSC member being asked to consider abstaining instead. There are no other explicit time limits placed on the other stages of the process. - -Most of the discussion should happen within the associated Discussion. The Issue should mostly be used to update and report the progress of the consensus process. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in associated Discussion, and any other relevant locations. - -Moving to the "Form a Proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. - -The "Test for Agreement" step is not voting, and is instead asking for "signals", which enable the consensus process to continue. -Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. - -If someone calls for a Test for Agreement, the facilitator for the decision discussion will review the current proposal and may call to Test for Agreement. The facilitator will post a comment on the Issue (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. - -The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the project's core principles or something that would harm the project. - -The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. If the blocker/s are unable or unwilling to participate in attempts to find a solution, after multiple attempts, the original proposal is moved to a vote, as defined in this document, but additionally requiring a 75% super majority to pass. This will be at the discretion of the TSC Chairs. - -If someone feels a "Block" is being used for unfair reasons, such as targeting individuals or to gain some personal advantage, or any such reason that might be in breach of our Code of Conduct, they should immediately report it to the Code of Conduct committee. The Code of Conduct committee should report this to the TSC Chairs as soon as possible, and the decision is halted while the committee investigates the report. - -The Code of Conduct committee will report their findings and any remediation action to the TSC Chairs. -Reports must remain anonymous, as per the Code of Conduct. - -The other signals that may be made when a Test For Agreement is called include "Reservations" and "Stand Aside". Both are signals which convey consent to let the proposal pass, however they may be conditional. - -Signaling "Reservations" means an agreement on the overall direction, however there is some desire to revise or amend the proposal somewhat. It is expected that the individuals signaling "Reservations" want to engage in reworking the proposal. The facilitator will check with each individual regarding the strength of the reservation, and later facilitate or direct discussion as required to amend and represent the proposal. If the individual/s do not wish to participate in reworking the proposal, their reservations should be logged as part of the decision record as unresolved. - -If "Reservations" is signalled three consecutive times by the same individual/s, anyone may call for no further attempts to remediate the reservations, and the proposal will pass. - -Signaling "Stand Aside" convey consent, but an unwillingness for whatever reason to be further involved. It could be for example that the individual does not have time to participate, or that they have limited opinions on the specific decision. The individual may provide a reason for standing aside. If the individual believes the reason can be remedied by the group, the group should seek to remedy the reason where possible, with help from the facilitator. - -The TSC will make every reasonable effort to reach unanimity based consensus. If unanimity seems unlikely after several failed attempts to revise the proposal and Test for Agreement, if the proposal is clear, the decision may be moved to a vote, at the discretion of the TSC Chairs. This is a last resort. - -The "Determine resolution" step should result in the creation of an [Any Decision Record](./docs/adr/README.md). More details in following sections. - -#### Decision-making via vote - -Any call for public TSC votes will be made by creating an Issue in the TSC repository with the `tsc-vote` label assigned. The Issue should use the provided template. - -Once an Issue gains the label `tsc-vote`, all members of the TSC will be notified via a specific Slack channel (and by any additional method the TSC deems helpful). The votes will be collected by way of using GitHub Reactions on a specific comment, which must not be the first comment. The first comment must link to the voting comment in the same Issue. -Voting will by default close after 7 days. Any member of the TSC may request a 7 day extension for any reason, moving the closing date back by 7 days. Any member of the TSC may request additional extensions, approved at the discretion of any TSC chair. - -For a vote to carry, a quorum of 75% is required by default. - -If a TSC member wants to call for a vote that they wish to be private, they must do so by contacting the TSC Chairs directly. -At the discretion of the TSC Chairs, a vote may be made private, and will then be handled by creating an Issue in the `TSC-private` repository. - -The topic and nature of private votes may remain private, including the results. (It is expected that vast majority of votes will be public. Private voting should only be used in exceptional circumstances.) - -The kinds of votes which should be private include things related to security reports or discussions with an entity where it might not be desireable to be made public knowledge to either party. This could include details of case studies or partnerships which are not yet concluded or published, where either party may need a final approval for publication or wishes for coordinated or scheduled public publication. - -#### Documenting decisions - -Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." - -(The quick consensus process does not require an Any Decision Record, but the decision should be minuted.) - -Private decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. +See GOVERNANCE.md ### 4.3: Other Project Roles @@ -225,9 +87,4 @@ TSC: The Technical Steering Committee, delegated technical leadership for the JS --- -This work is a derivative of the [WebdriverIO Project Governance Model](https://github.com/webdriverio/webdriverio/blob/main/GOVERNANCE.md). - -Inspired by https://seedsforchange.org.uk/consensus, https://seedsforchange.org.uk/quickconsensus -Informed by https://www.ic.org/busting-the-myth-that-consensus-with-unanimity-is-good-for-communities/ - This work is licensed under a [Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License](https://creativecommons.org/licenses/by-sa/2.0/uk/). \ No newline at end of file diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 00000000..b2bf53ec --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,171 @@ +🚨 This document is not ratified 🚨 +In the process of creating a charter, many "process" and governance related things were included in the draft of the charter. Feedback was that the charter should not include such content, and that it should be moved to a separate file. This is that file. +The initial commit includes content already approved by the group, however some additional content will be added at a later point, and this comment removed. +For context, see https://github.com/json-schema-org/community/pull/325 + +--- + +# Governance + + +## JSON Schema Governing Body (TSC) +The JSON Schema Technical Steering Committee (TSC) is initially established from the observed major contributors who are currently active and in good standing. + +There is no maximum TSC membership size. The TSC must have a minimum of four members. + +Changes to TSC membership should be posted in the agenda, and may be suggested as any other agenda item. + +TSC memberships are not time-limited. + +While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there are no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. + +TSC members are expected to regularly participate in TSC activities. + +When the TSC meets using virtual conferencing tools, the meeting will be directed by the TSC Chairperson(s). Responsibility for directing individual meetings may be delegated by a TSC Chairperson to any other TSC member. Minutes or an appropriate recording will be taken and made available to the community through accessible public postings. + +At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signaling or voting. The TSC member must detail when they expect to return. + +The TSC may, at its discretion, invite any number of non-voting observers to participate in the public portion of TSC discussions and meetings. + +A TSC member may be removed by vote from the TSC if, during a 3-month period, all of the following are true: + +- They do not participate in any TSC related discussions or votes +- They do not provide any form of excuse or no excuse is known for their absence + +## Roles & Responsibilities +The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. + +The TSC has final authority over this project including: + +- Technical direction +- Project governance and process (including this policy) +- Contribution policy +- GitHub repository hosting and administration +- Establishment of and delegation to working groups or teams +- Mediating technical conflicts +- Mediating non-technical conflicts (until a formal Code of Conduct Committee is established) + +In joining the TSC, members commit to communicate on a regular basis and respond to issues raised by the TSC in a timely manner. If they are no longer able or willing to make such a commitment, they should discuss this with the TSC or a TSC Chair. + +## Decision Making + +### Decision-making via consensus + +When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a private discussion and decision. The TSC member must reach out to the TSC chairs to request a private discussion and decision. A discussion and decision will be private at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be private in rare circumstances. + +The kinds of discussions which should be private include security reports or discussions with an entity where it might not be desireable to be made public knowledge to either party. This could include details of case studies or partnerships which are not yet concluded or published, where either party may need a final approval for publication or wishes for coordinated or scheduled public publication. + +Both the Quick and Standard consensus process require the creation of an Issue in the TSC GitHub repository. +The Issue must: +- Include brief introductory information about the decision that needs to be made +- Be labeled with `tsc-decision` +- Use the provided template, unless there is a good reason not to do so + +#### Quick consensus process + +In the event a TSC member feels the need for a decision to be expedited, they may create the decision discussion, indicating that they wish to use the quick process rather than the standard consensus process. This should be done by creating a new Issue in the TSC repository. +In addition to the requirements above, the Issue must be labeled `expedited`. + +While an associated Discussion is not required, if one is used, it must be clearly linked in both directions, and be labeled with `tsc-decision`. + +A vote is called to see if other members agree. The vote takes place on the opening comment. This vote is different from the decision-making voting process, and only requires 3 (additional) votes in favour and none against to carry. If the vote carries, the quick process is started, otherwise the standard consensus process is started. + +The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for (in a follow up comment on the Issue. Not in the opening comment.), and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. (Label `expedited` should be removed and `stage-1` added.) + +#### Standard consensus process + +The standard consensus process is designed for all non-trivial decisions. + +A decision discussion may be started by creating an Issue and Discussion in the TSC repository. + +In addition to the requirements above, the Issue must: +- Be labeled with `stage-1` +- Link to the associated initial Discussion + +The Discussion must: +- Link to the associated Issue +- Include detailed introductory information about the decision that needs to be made +- Be labeled with `tsc-decision` + +The standard consensus process should progress through the following seven stages. + +1. Introduction and clarify the issue +2. Open the discussion - Share needs and perspectives on the issue +3. Explore ideas in a broad discussion +4. Form a proposal +5. Amend the proposal +6. Test for agreement +7. Determine resolution + +(These stages are those defined by the [Seeds For Change's Consensus Decision Making document](https://seedsforchange.org.uk/consensus). Please use that document as a rough guide for specific steps while the JSON Schema project tests and firms up our specific requirements, and document them in our yet to be created [Governance document](./GOVERNANCE.md)) + +All decisions that go through the standard consensus process must have an associated GitHub Issue, which allows those unable to attend meetings to participate. +The opening comment of the Issue should be kept up to date as to the status of the decision. + +Transition between stages may be requested by anyone, but must be called by the facilitator (either a TSC chair or TSC member delegated the facilitator role for a given decision discussion). The stage will be indicated in the opening comment of the Issue and using the appropriate label. + +Stages 1 and 6 are required to be open for at least 7 days or until every TSC member has confirmed they wish to progress to the next stage (Progression will still be "called", as above). This includes signals of abstaining given automatically via a notification of period of leave from TSC activity. For stage 2, any TSC member may request a 7 day extension to allow for further consideration. Should there be no reasonable objection (determined by a TSC Chair), the minimum time will be extended by 7 days. A TSC member may request multiple extensions, however lack of justification may result in the TSC member being asked to consider abstaining instead. There are no other explicit time limits placed on the other stages of the process. + +Most of the discussion should happen within the associated Discussion. The Issue should mostly be used to update and report the progress of the consensus process. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in associated Discussion, and any other relevant locations. + +Moving to the "Form a Proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. + +The "Test for Agreement" step is not voting, and is instead asking for "signals", which enable the consensus process to continue. +Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. + +If someone calls for a Test for Agreement, the facilitator for the decision discussion will review the current proposal and may call to Test for Agreement. The facilitator will post a comment on the Issue (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. + +The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the project's core principles or something that would harm the project. + +The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. If the blocker/s are unable or unwilling to participate in attempts to find a solution, after multiple attempts, the original proposal is moved to a vote, as defined in this document, but additionally requiring a 75% super majority to pass. This will be at the discretion of the TSC Chairs. + +If someone feels a "Block" is being used for unfair reasons, such as targeting individuals or to gain some personal advantage, or any such reason that might be in breach of our Code of Conduct, they should immediately report it to the Code of Conduct committee. The Code of Conduct committee should report this to the TSC Chairs as soon as possible, and the decision is halted while the committee investigates the report. + +The Code of Conduct committee will report their findings and any remediation action to the TSC Chairs. +Reports must remain anonymous, as per the Code of Conduct. + +The other signals that may be made when a Test For Agreement is called include "Reservations" and "Stand Aside". Both are signals which convey consent to let the proposal pass, however they may be conditional. + +Signaling "Reservations" means an agreement on the overall direction, however there is some desire to revise or amend the proposal somewhat. It is expected that the individuals signaling "Reservations" want to engage in reworking the proposal. The facilitator will check with each individual regarding the strength of the reservation, and later facilitate or direct discussion as required to amend and represent the proposal. If the individual/s do not wish to participate in reworking the proposal, their reservations should be logged as part of the decision record as unresolved. + +If "Reservations" is signalled three consecutive times by the same individual/s, anyone may call for no further attempts to remediate the reservations, and the proposal will pass. + +Signaling "Stand Aside" convey consent, but an unwillingness for whatever reason to be further involved. It could be for example that the individual does not have time to participate, or that they have limited opinions on the specific decision. The individual may provide a reason for standing aside. If the individual believes the reason can be remedied by the group, the group should seek to remedy the reason where possible, with help from the facilitator. + +The TSC will make every reasonable effort to reach unanimity based consensus. If unanimity seems unlikely after several failed attempts to revise the proposal and Test for Agreement, if the proposal is clear, the decision may be moved to a vote, at the discretion of the TSC Chairs. This is a last resort. + +The "Determine resolution" step should result in the creation of an [Any Decision Record](./docs/adr/README.md). More details in following sections. + +### Decision-making via vote + +Any call for public TSC votes will be made by creating an Issue in the TSC repository with the `tsc-vote` label assigned. The Issue should use the provided template. + +Once an Issue gains the label `tsc-vote`, all members of the TSC will be notified via a specific Slack channel (and by any additional method the TSC deems helpful). The votes will be collected by way of using GitHub Reactions on a specific comment, which must not be the first comment. The first comment must link to the voting comment in the same Issue. +Voting will by default close after 7 days. Any member of the TSC may request a 7 day extension for any reason, moving the closing date back by 7 days. Any member of the TSC may request additional extensions, approved at the discretion of any TSC chair. + +For a vote to carry, a quorum of 75% is required by default. + +If a TSC member wants to call for a vote that they wish to be private, they must do so by contacting the TSC Chairs directly. +At the discretion of the TSC Chairs, a vote may be made private, and will then be handled by creating an Issue in the `TSC-private` repository. + +The topic and nature of private votes may remain private, including the results. (It is expected that vast majority of votes will be public. Private voting should only be used in exceptional circumstances.) + +The kinds of votes which should be private include things related to security reports or discussions with an entity where it might not be desireable to be made public knowledge to either party. This could include details of case studies or partnerships which are not yet concluded or published, where either party may need a final approval for publication or wishes for coordinated or scheduled public publication. + +### Documenting decisions + +Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." + +(The quick consensus process does not require an Any Decision Record, but the decision should be minuted.) + +Private decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. + + +--- + +This work is a derivative of the [WebdriverIO Project Governance Model](https://github.com/webdriverio/webdriverio/blob/main/GOVERNANCE.md). + +Inspired by https://seedsforchange.org.uk/consensus, https://seedsforchange.org.uk/quickconsensus +Informed by https://www.ic.org/busting-the-myth-that-consensus-with-unanimity-is-good-for-communities/ + +This work is licensed under a [Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License](https://creativecommons.org/licenses/by-sa/2.0/uk/). \ No newline at end of file From 55aa9b3b7070d3f7d62b49a5d94da0fc7b8c36f6 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 23 Jun 2023 15:37:17 +0100 Subject: [PATCH 64/83] Refined definition of TSC in context --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 57558d5a..81b88812 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -83,7 +83,7 @@ The following responsibilities are recognized as those requiring roles to be def ## 5: Definitions -TSC: The Technical Steering Committee, delegated technical leadership for the JSON Schema project by the OpenJS Foundation. +TSC: The JSON Schema Technical Steering Committee, delegated technical leadership for the JSON Schema project by the OpenJS Foundation. --- From 75542a8009bf17152480ec333f416831d846929b Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 26 Jun 2023 09:19:46 +0100 Subject: [PATCH 65/83] Move content about voting and additional project roles from charter to governance document --- CHARTER.md | 16 ---------------- GOVERNANCE.md | 16 ++++++++++++++++ 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 81b88812..d7c1d947 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -61,26 +61,10 @@ See GOVERNANCE.md ### 4.1 Project Operations & Management The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. -### 4.2: Decision-making and Voting -The TSC follows a formal consensus seeking decision making model. -In some situations, a vote may be preferable, however a vote will not be used to make the vast majority of decisions. -In the unlikely case where it seems that consensus cannot be reached after multiple attempts, the decision process may be moved to resolve via a vote. This is not expected to happen, but defined as a backup. - #### Decision-making via consensus and voting, and documenting decisions See GOVERNANCE.md -### 4.3: Other Project Roles - -The JSON Schema project recognizes the need for both technical and non-technical roles. While the OpenJS Foundation takes on business responsibilities as the legal entity hosting the project, there are other non-technical responsibilities. - -The TSC will look to create other roles as appropriate, and may update this document in accordance with the requirements for doing so, to formally recognize the additional roles. - -The following responsibilities are recognized as those requiring roles to be defined by the TSC: -- Community and Industry connections -- Brand awareness, recognition, and health -- Education and training - ## 5: Definitions TSC: The JSON Schema Technical Steering Committee, delegated technical leadership for the JSON Schema project by the OpenJS Foundation. diff --git a/GOVERNANCE.md b/GOVERNANCE.md index b2bf53ec..7ba05621 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -49,6 +49,11 @@ In joining the TSC, members commit to communicate on a regular basis and respond ## Decision Making +### Decision-making and Voting +The TSC follows a formal consensus seeking decision making model. +In some situations, a vote may be preferable, however a vote will not be used to make the vast majority of decisions. +In the unlikely case where it seems that consensus cannot be reached after multiple attempts, the decision process may be moved to resolve via a vote. This is not expected to happen, but defined as a backup. + ### Decision-making via consensus When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a private discussion and decision. The TSC member must reach out to the TSC chairs to request a private discussion and decision. A discussion and decision will be private at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be private in rare circumstances. @@ -161,6 +166,17 @@ Either initially, or at any point during the process, any TSC member may suggest Private decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. +## Other Project Roles + +The JSON Schema project recognizes the need for both technical and non-technical roles. While the OpenJS Foundation takes on business responsibilities as the legal entity hosting the project, there are other non-technical responsibilities. + +The TSC will look to create other roles as appropriate, and may update this document in accordance with the requirements for doing so, to formally recognize the additional roles. + +The following responsibilities are recognized as those requiring roles to be defined by the TSC: +- Community and Industry connections +- Brand awareness, recognition, and health +- Education and training + --- This work is a derivative of the [WebdriverIO Project Governance Model](https://github.com/webdriverio/webdriverio/blob/main/GOVERNANCE.md). From aea0b80d98991b81d7c34c2875899cd05bf9f270 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 26 Jun 2023 11:32:50 +0100 Subject: [PATCH 66/83] Add interoperability to list of in scope concerns --- CHARTER.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHARTER.md b/CHARTER.md index d7c1d947..d1f7b125 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -20,6 +20,7 @@ Primary Concerns - Publication of the JSON Schema standard - Validation of JSON data - Semantic annotation of JSON data + - Interoperability - Extensibility - Critical tooling - Documentation From fbe8b54623e127e698454ad947253aa501e00414 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 27 Jun 2023 11:04:40 +0100 Subject: [PATCH 67/83] Change 'JSON data' to 'JSON-compatible data' in charter --- CHARTER.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index d1f7b125..5cb1acf6 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -18,8 +18,8 @@ Primary concerns are areas the JSON Schema project wish to give focus to, while Primary Concerns - Publication of the JSON Schema standard - - Validation of JSON data - - Semantic annotation of JSON data + - Validation of JSON-compatible data + - Semantic annotation of JSON-compatible data - Interoperability - Extensibility - Critical tooling From 63cf6735a0c60ec354e58c0d0fbc5b144c08b012 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 10 Jul 2023 14:42:20 +0100 Subject: [PATCH 68/83] Use more inclusive phrasing Co-authored-by: Tobie Langel --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 5cb1acf6..d83099f9 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -14,7 +14,7 @@ While JSON Schema's primary target is constraint-based data validation, it conti ### 1.1: In-scope The scope of the JSON Schema project is split into two sections: primary and secondary concerns. -Primary concerns are areas the JSON Schema project wish to give focus to, while secondary concerns are more likely to require the desire of the community to drive the work. +Primary concerns are areas the JSON Schema project wish to give focus to. Secondary concerns, while remaining in scope, aren't areas of focus, and would require dedicated championing by community members to come to fruition. Primary Concerns - Publication of the JSON Schema standard From a996e13c945f473e4b378e6cb201be1163352fac Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 10 Jul 2023 14:58:21 +0100 Subject: [PATCH 69/83] Remove content which is mostly a duplication of section 2 --- CHARTER.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index d83099f9..9cc0a4f9 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -4,8 +4,6 @@ ## 0: Guiding Principles The JSON Schema project is part of the OpenJS Foundation. The JSON Schema project strives to be open and transparent as much as is possible, and wish to enable anyone to interact and engage with any area of our work. -Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). OpenJS Foundation's business leadership is the Board of Directors (the "Board"). - Having no structure in place usually leads to one that is informal and undocumented, making it difficult to meet our own expectations of how the TSC wish to operate. As such, the JSON Schema project define the following charter which includes aspects of the governance model to which the TSC subscribe and by which the TSC operate. ## 1: Scope From 2a92249e991918d09bcc733ffb542d002d343efb Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 11 Jul 2023 13:54:38 +0100 Subject: [PATCH 70/83] Simplify out of scope sction. Add engaging with upstream and downstream specs and projects --- CHARTER.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 9cc0a4f9..b9bd86f3 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -27,6 +27,7 @@ Primary Concerns - Enabling schema authors - Enabling implementers - Engaging with industry + - Engaging with upstream and downstream standards and projects - Communicating value - Ensuring the sustainability of the project @@ -41,7 +42,7 @@ Secondary Concerns - Vocabularies registry ### 1.2: Out-of-Scope -While the JSON Schema project has no control over the specifications it uses (such as JSON and IRI), nor specifications that use JSON Schema (such as OpenAPI and AsyncAPI), the JSON Schema project has, and continues to, provide expert opinion, advice, and support, as time allows. JSON Schema recognizes the importance and value of the ecosystem surrounding JSON Schema, and JSON Schema encourage those developing standards and tooling to reach out at any time. +Standards that the JSON Schema project uses (such as JSON and IRI), nor standards and projects that use JSON Schema (such as OpenAPI and AsyncAPI), are not things which the JSON Schema project has any control over. ## 2: Relationship with OpenJS Foundation CPC. Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). From 58d942b7a658e6b5d8debe40b81b0511806ff4cd Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Jul 2023 12:32:30 +0100 Subject: [PATCH 71/83] Move TSC policy elements to charter from governance document --- CHARTER.md | 9 ++++++++- GOVERNANCE.md | 10 +++------- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index b9bd86f3..b5d5d22c 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -51,8 +51,15 @@ Most large, complex open source communities have both a business and a technical Section Intentionally Left Blank ## 3: JSON Schema Governing Body (TSC) +The JSON Schema Technical Steering Committee (TSC) is initially established from the observed major contributors who are currently active and in good standing. -See GOVERNANCE.md +The TSC must have a minimum of four members. There is no maximum TSC membership size. + +TSC memberships are not time-limited. + +The TSC follows the decision-making process defined in this charter unless otherwise documented. + +The TSC aims to work asynchronously. TSC meetings are pre-announced, public, and recorded. Minutes are taken and the recordings made available. If there is a reasonable reason (such as security or privacy), any portion of a meeting, its minutes, and recording, may be kept private. ## 4: Roles & Responsibilities diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 7ba05621..5709499a 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -9,13 +9,7 @@ For context, see https://github.com/json-schema-org/community/pull/325 ## JSON Schema Governing Body (TSC) -The JSON Schema Technical Steering Committee (TSC) is initially established from the observed major contributors who are currently active and in good standing. - -There is no maximum TSC membership size. The TSC must have a minimum of four members. - -Changes to TSC membership should be posted in the agenda, and may be suggested as any other agenda item. - -TSC memberships are not time-limited. +--- content migrated to Charter.md While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there are no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. @@ -32,6 +26,8 @@ A TSC member may be removed by vote from the TSC if, during a 3-month period, al - They do not participate in any TSC related discussions or votes - They do not provide any form of excuse or no excuse is known for their absence +There may be other grounds for removal from the TSC, such as seriously violating the Code of Conduct. + ## Roles & Responsibilities The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. From 8b2ed6628a68642e12f427e0ce797a6b418143c5 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 13 Jul 2023 12:32:53 +0100 Subject: [PATCH 72/83] Add that TSC meetings should have an agenda --- GOVERNANCE.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 5709499a..f5ae13a8 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -9,7 +9,6 @@ For context, see https://github.com/json-schema-org/community/pull/325 ## JSON Schema Governing Body (TSC) ---- content migrated to Charter.md While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there are no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. @@ -17,6 +16,8 @@ TSC members are expected to regularly participate in TSC activities. When the TSC meets using virtual conferencing tools, the meeting will be directed by the TSC Chairperson(s). Responsibility for directing individual meetings may be delegated by a TSC Chairperson to any other TSC member. Minutes or an appropriate recording will be taken and made available to the community through accessible public postings. +TSC meetings should have a clearly defined agenda. + At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signaling or voting. The TSC member must detail when they expect to return. The TSC may, at its discretion, invite any number of non-voting observers to participate in the public portion of TSC discussions and meetings. From be3800687ed7db4e1cf84ce107058d7bf0fe7f0b Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 25 Jul 2023 11:23:38 +0100 Subject: [PATCH 73/83] Move roles and responsibilities section back to charter document with small modification. With thanks for guidance from Julian --- CHARTER.md | 16 +++++++++++++++- GOVERNANCE.md | 15 --------------- 2 files changed, 15 insertions(+), 16 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index b5d5d22c..55dbdcb2 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -63,7 +63,21 @@ The TSC aims to work asynchronously. TSC meetings are pre-announced, public, and ## 4: Roles & Responsibilities -See GOVERNANCE.md +The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. + +The TSC has final authority over this project including: + +- Technical direction +- Project governance and process (including this policy) +- Contribution policy +- GitHub repository hosting and administration +- Establishment of and delegation to working groups or teams +- Mediating technical conflicts + +It is also responsible for establishing a Code of Conduct Committee suitable for mediating non-technical conflicts. +In any period where such a committee is not yet formed, the TSC must assume temporary responsibility of mediating such conflicts in addition to responsibilities enumerated above. + +In joining the TSC, members commit to communicate on a regular basis and respond to issues raised by the TSC in a timely manner. If they are no longer able or willing to make such a commitment, they should discuss this with the TSC or a TSC Chair. ### 4.1 Project Operations & Management The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. diff --git a/GOVERNANCE.md b/GOVERNANCE.md index f5ae13a8..36545aa9 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -29,21 +29,6 @@ A TSC member may be removed by vote from the TSC if, during a 3-month period, al There may be other grounds for removal from the TSC, such as seriously violating the Code of Conduct. -## Roles & Responsibilities -The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. - -The TSC has final authority over this project including: - -- Technical direction -- Project governance and process (including this policy) -- Contribution policy -- GitHub repository hosting and administration -- Establishment of and delegation to working groups or teams -- Mediating technical conflicts -- Mediating non-technical conflicts (until a formal Code of Conduct Committee is established) - -In joining the TSC, members commit to communicate on a regular basis and respond to issues raised by the TSC in a timely manner. If they are no longer able or willing to make such a commitment, they should discuss this with the TSC or a TSC Chair. - ## Decision Making ### Decision-making and Voting From 4c92fc6ccb68f20ced913500d57dd650595dc9fe Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 25 Jul 2023 12:02:10 +0100 Subject: [PATCH 74/83] Migrate some content regarding process out of the governance document back into charter document. Specifically around decision making and voting. With thanks to Julian for assisting in this revision. --- CHARTER.md | 17 +++++++++++++++-- GOVERNANCE.md | 11 ++--------- 2 files changed, 17 insertions(+), 11 deletions(-) diff --git a/CHARTER.md b/CHARTER.md index 55dbdcb2..28acac41 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -82,9 +82,22 @@ In joining the TSC, members commit to communicate on a regular basis and respond ### 4.1 Project Operations & Management The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. -#### Decision-making via consensus and voting, and documenting decisions +#### Decision-making -See GOVERNANCE.md +The TSC follows a consensus-seeking decision making model in which joint decisions are agreed upon by all members whenever possible. +In some situations, a vote may be preferable, however a formal vote is expected to be an infrequent occurrence invoked only when consensus cannot be reached after multiple attempts to reach TSC consensus. +TSC discussions and decisions are to be assumed public by default, unless otherwise decided upon on a case-by-case basis by the TSC. +Precise criteria for which decisions are to be left private are left to the TSC's discretion and assumed to include security-related reports or discussions with a third-party who wishes their interactions to remain private, such as when they concern yet unpublished case studies or partnerships which are not yet ready for announcement. + +The TSC is expected to agree upon and maintain specific process and procedure which facilitate labelling or communicating which decisions have been formally decided upon by the TSC. +This process should include a mechanism for identifying ongoing TSC discussions and decision-making. +When concluded, decisions should include reasoning and/or justification of the TSC, as well as indication of the consensus of the committee, or lack thereof in the case of a voted decision as indicated above. +Private decisions should also be documented in a private location accessible to parties expected to have access to them. + +## Code of Conduct Findings & Violations + +Code of Conduct incidents must be reported to the TSC by the Code of Conduct committee. +Reports must remain anonymous, as per the Code of Conduct, but should be documented in a manner similar to private TSC decisions as mentioned. ## 5: Definitions diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 36545aa9..50eb31ba 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -31,17 +31,8 @@ There may be other grounds for removal from the TSC, such as seriously violating ## Decision Making -### Decision-making and Voting -The TSC follows a formal consensus seeking decision making model. -In some situations, a vote may be preferable, however a vote will not be used to make the vast majority of decisions. -In the unlikely case where it seems that consensus cannot be reached after multiple attempts, the decision process may be moved to resolve via a vote. This is not expected to happen, but defined as a backup. - ### Decision-making via consensus -When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a private discussion and decision. The TSC member must reach out to the TSC chairs to request a private discussion and decision. A discussion and decision will be private at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be private in rare circumstances. - -The kinds of discussions which should be private include security reports or discussions with an entity where it might not be desireable to be made public knowledge to either party. This could include details of case studies or partnerships which are not yet concluded or published, where either party may need a final approval for publication or wishes for coordinated or scheduled public publication. - Both the Quick and Standard consensus process require the creation of an Issue in the TSC GitHub repository. The Issue must: - Include brief introductory information about the decision that needs to be made @@ -55,6 +46,8 @@ In addition to the requirements above, the Issue must be labeled `expedited`. While an associated Discussion is not required, if one is used, it must be clearly linked in both directions, and be labeled with `tsc-decision`. +#### Quick consensus process + A vote is called to see if other members agree. The vote takes place on the opening comment. This vote is different from the decision-making voting process, and only requires 3 (additional) votes in favour and none against to carry. If the vote carries, the quick process is started, otherwise the standard consensus process is started. The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for (in a follow up comment on the Issue. Not in the opening comment.), and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. (Label `expedited` should be removed and `stage-1` added.) From 507246bc7b470c68560d8ee1185798f05bed701b Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 25 Jul 2023 13:26:25 +0100 Subject: [PATCH 75/83] Remove governance document for the Charter PR --- GOVERNANCE.md | 162 -------------------------------------------------- 1 file changed, 162 deletions(-) delete mode 100644 GOVERNANCE.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md deleted file mode 100644 index 50eb31ba..00000000 --- a/GOVERNANCE.md +++ /dev/null @@ -1,162 +0,0 @@ -🚨 This document is not ratified 🚨 -In the process of creating a charter, many "process" and governance related things were included in the draft of the charter. Feedback was that the charter should not include such content, and that it should be moved to a separate file. This is that file. -The initial commit includes content already approved by the group, however some additional content will be added at a later point, and this comment removed. -For context, see https://github.com/json-schema-org/community/pull/325 - ---- - -# Governance - - -## JSON Schema Governing Body (TSC) - -While the project is not looking to obtain "Impact" project status within the OpenJS Foundation, there is no requirement set out to limit the number of TSC members by employer. It is in some cases considered difficult or even unhelpful for the project to limit the number or percentage of TSC members by employer (especially when an employer has employed individuals already active in the community to work exclusively on the open source project). While at this time there are no limits on TSC membership by employer, the TSC will strive to keep to at least less than 50%, ideally 33% (One third, one in three). The TSC will re-evaluate this specific clause at least every six months, and aim to revise it within one year to meet the "no more than 1/3 employer member affiliation" mandate. - -TSC members are expected to regularly participate in TSC activities. - -When the TSC meets using virtual conferencing tools, the meeting will be directed by the TSC Chairperson(s). Responsibility for directing individual meetings may be delegated by a TSC Chairperson to any other TSC member. Minutes or an appropriate recording will be taken and made available to the community through accessible public postings. - -TSC meetings should have a clearly defined agenda. - -At any point, any TSC member may notify the TSC that they are taking a period of leave and should be considered to abstain from any signaling or voting. The TSC member must detail when they expect to return. - -The TSC may, at its discretion, invite any number of non-voting observers to participate in the public portion of TSC discussions and meetings. - -A TSC member may be removed by vote from the TSC if, during a 3-month period, all of the following are true: - -- They do not participate in any TSC related discussions or votes -- They do not provide any form of excuse or no excuse is known for their absence - -There may be other grounds for removal from the TSC, such as seriously violating the Code of Conduct. - -## Decision Making - -### Decision-making via consensus - -Both the Quick and Standard consensus process require the creation of an Issue in the TSC GitHub repository. -The Issue must: -- Include brief introductory information about the decision that needs to be made -- Be labeled with `tsc-decision` -- Use the provided template, unless there is a good reason not to do so - -#### Quick consensus process - -In the event a TSC member feels the need for a decision to be expedited, they may create the decision discussion, indicating that they wish to use the quick process rather than the standard consensus process. This should be done by creating a new Issue in the TSC repository. -In addition to the requirements above, the Issue must be labeled `expedited`. - -While an associated Discussion is not required, if one is used, it must be clearly linked in both directions, and be labeled with `tsc-decision`. - -#### Quick consensus process - -A vote is called to see if other members agree. The vote takes place on the opening comment. This vote is different from the decision-making voting process, and only requires 3 (additional) votes in favour and none against to carry. If the vote carries, the quick process is started, otherwise the standard consensus process is started. - -The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for (in a follow up comment on the Issue. Not in the opening comment.), and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. (Label `expedited` should be removed and `stage-1` added.) - -#### Standard consensus process - -The standard consensus process is designed for all non-trivial decisions. - -A decision discussion may be started by creating an Issue and Discussion in the TSC repository. - -In addition to the requirements above, the Issue must: -- Be labeled with `stage-1` -- Link to the associated initial Discussion - -The Discussion must: -- Link to the associated Issue -- Include detailed introductory information about the decision that needs to be made -- Be labeled with `tsc-decision` - -The standard consensus process should progress through the following seven stages. - -1. Introduction and clarify the issue -2. Open the discussion - Share needs and perspectives on the issue -3. Explore ideas in a broad discussion -4. Form a proposal -5. Amend the proposal -6. Test for agreement -7. Determine resolution - -(These stages are those defined by the [Seeds For Change's Consensus Decision Making document](https://seedsforchange.org.uk/consensus). Please use that document as a rough guide for specific steps while the JSON Schema project tests and firms up our specific requirements, and document them in our yet to be created [Governance document](./GOVERNANCE.md)) - -All decisions that go through the standard consensus process must have an associated GitHub Issue, which allows those unable to attend meetings to participate. -The opening comment of the Issue should be kept up to date as to the status of the decision. - -Transition between stages may be requested by anyone, but must be called by the facilitator (either a TSC chair or TSC member delegated the facilitator role for a given decision discussion). The stage will be indicated in the opening comment of the Issue and using the appropriate label. - -Stages 1 and 6 are required to be open for at least 7 days or until every TSC member has confirmed they wish to progress to the next stage (Progression will still be "called", as above). This includes signals of abstaining given automatically via a notification of period of leave from TSC activity. For stage 2, any TSC member may request a 7 day extension to allow for further consideration. Should there be no reasonable objection (determined by a TSC Chair), the minimum time will be extended by 7 days. A TSC member may request multiple extensions, however lack of justification may result in the TSC member being asked to consider abstaining instead. There are no other explicit time limits placed on the other stages of the process. - -Most of the discussion should happen within the associated Discussion. The Issue should mostly be used to update and report the progress of the consensus process. Groups looking to form a proposal or amend a proposal (stages 4 and 5) may make use of other additional Discussions or Issues, but these must be clearly linked. The opening comment should be updated to include links to relevant specific threads and comments in associated Discussion, and any other relevant locations. - -Moving to the "Form a Proposal" stage should be approached when the group might feel able to combine ideas to form a single proposal. Multiple possible solutions should be discussed in the previous stage. - -The "Test for Agreement" step is not voting, and is instead asking for "signals", which enable the consensus process to continue. -Voting should be considered a last resort if the consensus process has failed for a particular issue, to enable the project to move forward. - -If someone calls for a Test for Agreement, the facilitator for the decision discussion will review the current proposal and may call to Test for Agreement. The facilitator will post a comment on the Issue (using the provided template), linking to the current version of the proposal, and update the opening comment with a link to the new comment. TSC members will then be asked to signal their agreement using GitHub Reactions on the comment. - -The signals include "Block". Any use of the "Block" signal will require a new or amended proposal to be worked on. A "Block" should be used to indicate a strong objection, such as something against the project's core principles or something that would harm the project. - -The blocker/s should be prepared to commit to trying to find a solution, but not necessarily form and present a solution by themselves. The TSC will look to facilitate a number of workshops to help understand the blocking objections, and form a new or amended proposal as a result. If the blocker/s are unable or unwilling to participate in attempts to find a solution, after multiple attempts, the original proposal is moved to a vote, as defined in this document, but additionally requiring a 75% super majority to pass. This will be at the discretion of the TSC Chairs. - -If someone feels a "Block" is being used for unfair reasons, such as targeting individuals or to gain some personal advantage, or any such reason that might be in breach of our Code of Conduct, they should immediately report it to the Code of Conduct committee. The Code of Conduct committee should report this to the TSC Chairs as soon as possible, and the decision is halted while the committee investigates the report. - -The Code of Conduct committee will report their findings and any remediation action to the TSC Chairs. -Reports must remain anonymous, as per the Code of Conduct. - -The other signals that may be made when a Test For Agreement is called include "Reservations" and "Stand Aside". Both are signals which convey consent to let the proposal pass, however they may be conditional. - -Signaling "Reservations" means an agreement on the overall direction, however there is some desire to revise or amend the proposal somewhat. It is expected that the individuals signaling "Reservations" want to engage in reworking the proposal. The facilitator will check with each individual regarding the strength of the reservation, and later facilitate or direct discussion as required to amend and represent the proposal. If the individual/s do not wish to participate in reworking the proposal, their reservations should be logged as part of the decision record as unresolved. - -If "Reservations" is signalled three consecutive times by the same individual/s, anyone may call for no further attempts to remediate the reservations, and the proposal will pass. - -Signaling "Stand Aside" convey consent, but an unwillingness for whatever reason to be further involved. It could be for example that the individual does not have time to participate, or that they have limited opinions on the specific decision. The individual may provide a reason for standing aside. If the individual believes the reason can be remedied by the group, the group should seek to remedy the reason where possible, with help from the facilitator. - -The TSC will make every reasonable effort to reach unanimity based consensus. If unanimity seems unlikely after several failed attempts to revise the proposal and Test for Agreement, if the proposal is clear, the decision may be moved to a vote, at the discretion of the TSC Chairs. This is a last resort. - -The "Determine resolution" step should result in the creation of an [Any Decision Record](./docs/adr/README.md). More details in following sections. - -### Decision-making via vote - -Any call for public TSC votes will be made by creating an Issue in the TSC repository with the `tsc-vote` label assigned. The Issue should use the provided template. - -Once an Issue gains the label `tsc-vote`, all members of the TSC will be notified via a specific Slack channel (and by any additional method the TSC deems helpful). The votes will be collected by way of using GitHub Reactions on a specific comment, which must not be the first comment. The first comment must link to the voting comment in the same Issue. -Voting will by default close after 7 days. Any member of the TSC may request a 7 day extension for any reason, moving the closing date back by 7 days. Any member of the TSC may request additional extensions, approved at the discretion of any TSC chair. - -For a vote to carry, a quorum of 75% is required by default. - -If a TSC member wants to call for a vote that they wish to be private, they must do so by contacting the TSC Chairs directly. -At the discretion of the TSC Chairs, a vote may be made private, and will then be handled by creating an Issue in the `TSC-private` repository. - -The topic and nature of private votes may remain private, including the results. (It is expected that vast majority of votes will be public. Private voting should only be used in exceptional circumstances.) - -The kinds of votes which should be private include things related to security reports or discussions with an entity where it might not be desireable to be made public knowledge to either party. This could include details of case studies or partnerships which are not yet concluded or published, where either party may need a final approval for publication or wishes for coordinated or scheduled public publication. - -### Documenting decisions - -Either initially, or at any point during the process, any TSC member may suggest the issue being discussed is "significant or noteworthy." If there are no objections, the resolution actions for the issue must include the creation of an Any Decision Record (previously named Architectural Decision Record). The Any Decision Record (ADR) should include as much information as is thought to be useful, following the provided template. The Pull Request for the ADR must be approved by all those who were involved in the decision making process, which must also be documented in the ADR as the "deciders." - -(The quick consensus process does not require an Any Decision Record, but the decision should be minuted.) - -Private decisions should be documented (as an ADR or otherwise) in the private `TSC-private` repository. - - -## Other Project Roles - -The JSON Schema project recognizes the need for both technical and non-technical roles. While the OpenJS Foundation takes on business responsibilities as the legal entity hosting the project, there are other non-technical responsibilities. - -The TSC will look to create other roles as appropriate, and may update this document in accordance with the requirements for doing so, to formally recognize the additional roles. - -The following responsibilities are recognized as those requiring roles to be defined by the TSC: -- Community and Industry connections -- Brand awareness, recognition, and health -- Education and training - ---- - -This work is a derivative of the [WebdriverIO Project Governance Model](https://github.com/webdriverio/webdriverio/blob/main/GOVERNANCE.md). - -Inspired by https://seedsforchange.org.uk/consensus, https://seedsforchange.org.uk/quickconsensus -Informed by https://www.ic.org/busting-the-myth-that-consensus-with-unanimity-is-good-for-communities/ - -This work is licensed under a [Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License](https://creativecommons.org/licenses/by-sa/2.0/uk/). \ No newline at end of file From 26f9265601af912f1342aaaf0b87351431fc0639 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 2 Aug 2023 15:43:59 +0100 Subject: [PATCH 76/83] Improve phrasing for out of scope Co-authored-by: Tobie Langel --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 28acac41..8f8295a3 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -42,7 +42,7 @@ Secondary Concerns - Vocabularies registry ### 1.2: Out-of-Scope -Standards that the JSON Schema project uses (such as JSON and IRI), nor standards and projects that use JSON Schema (such as OpenAPI and AsyncAPI), are not things which the JSON Schema project has any control over. +Neither standards that the JSON Schema project uses (such as JSON and IRI) nor standards or projects that use JSON Schema (such as OpenAPI or AsyncAPI) are in scope, nor does the JSON Schema project has any control over them. ## 2: Relationship with OpenJS Foundation CPC. Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). From 31d5f6e0adc3e03bc12d5ccdc026faa375bce867 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 2 Aug 2023 15:44:46 +0100 Subject: [PATCH 77/83] Tighten phrasing Co-authored-by: Tobie Langel --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 8f8295a3..85f15da2 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -63,7 +63,7 @@ The TSC aims to work asynchronously. TSC meetings are pre-announced, public, and ## 4: Roles & Responsibilities -The JSON Schema project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. +The JSON Schema project is governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project. The TSC has final authority over this project including: From 47a0d79e9729cd25035933b4d7e807bbd819e7b8 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 2 Aug 2023 15:45:43 +0100 Subject: [PATCH 78/83] Note that updates to the charter must be approved by the OpenJS Foundation CPC Co-authored-by: Tobie Langel --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 85f15da2..4777aa20 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -68,7 +68,7 @@ The JSON Schema project is governed by a Technical Steering Committee (TSC) whic The TSC has final authority over this project including: - Technical direction -- Project governance and process (including this policy) +- Project governance and process (including this policy, though changes to this policy must be approved by the CPC) - Contribution policy - GitHub repository hosting and administration - Establishment of and delegation to working groups or teams From 37eccb2c3f47f41b0d38d54bb77039ae018ca735 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 2 Aug 2023 15:54:02 +0100 Subject: [PATCH 79/83] Include the CPC Co-authored-by: Tobie Langel --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 4777aa20..744c6c20 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -80,7 +80,7 @@ In any period where such a committee is not yet formed, the TSC must assume temp In joining the TSC, members commit to communicate on a regular basis and respond to issues raised by the TSC in a timely manner. If they are no longer able or willing to make such a commitment, they should discuss this with the TSC or a TSC Chair. ### 4.1 Project Operations & Management -The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. +The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board or the CPC relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy. #### Decision-making From bea5924a152b1a71b5e884c3cdd6b8e9cb334abc Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 2 Aug 2023 15:58:00 +0100 Subject: [PATCH 80/83] Strive to be open, always! Co-authored-by: Tobie Langel --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 744c6c20..724b5b26 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -92,7 +92,7 @@ Precise criteria for which decisions are to be left private are left to the TSC' The TSC is expected to agree upon and maintain specific process and procedure which facilitate labelling or communicating which decisions have been formally decided upon by the TSC. This process should include a mechanism for identifying ongoing TSC discussions and decision-making. When concluded, decisions should include reasoning and/or justification of the TSC, as well as indication of the consensus of the committee, or lack thereof in the case of a voted decision as indicated above. -Private decisions should also be documented in a private location accessible to parties expected to have access to them. +Private decisions should also be documented in a private location accessible to parties expected to have access to them. In the spirit of transparency, the TSC will strive to make anonymized or redacted versions of these decisions publicly available. ## Code of Conduct Findings & Violations From 91d513397b1ac5ddcd119d9c9aeb7a324a3ab8b0 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 3 Aug 2023 10:42:53 +0100 Subject: [PATCH 81/83] Remove initial included license and add CC-BY 4.0 Initial license was from the Webhint.io governance document, but governance aspects have since been moved to another document, leaving us free to choose the license for the charter. --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 724b5b26..6372fa7f 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -105,4 +105,4 @@ TSC: The JSON Schema Technical Steering Committee, delegated technical leadershi --- -This work is licensed under a [Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License](https://creativecommons.org/licenses/by-sa/2.0/uk/). \ No newline at end of file +CC-BY 4.0 (c) The JSON Schema Project contributors \ No newline at end of file From cdce30bfad8feab37a2fdce7850b10a5be19ffb9 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 3 Aug 2023 10:45:16 +0100 Subject: [PATCH 82/83] Fix posession Co-authored-by: Jordan Harband --- CHARTER.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHARTER.md b/CHARTER.md index 6372fa7f..968506e8 100644 --- a/CHARTER.md +++ b/CHARTER.md @@ -42,7 +42,7 @@ Secondary Concerns - Vocabularies registry ### 1.2: Out-of-Scope -Neither standards that the JSON Schema project uses (such as JSON and IRI) nor standards or projects that use JSON Schema (such as OpenAPI or AsyncAPI) are in scope, nor does the JSON Schema project has any control over them. +Neither standards that the JSON Schema project uses (such as JSON and IRI) nor standards or projects that use JSON Schema (such as OpenAPI or AsyncAPI) are in scope, nor does the JSON Schema project have any control over them. ## 2: Relationship with OpenJS Foundation CPC. Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of the JSON Schema project, it is delegated to the JSON Schema Technical Steering Committee ("TSC"). From 06240f9be929f74023e6e382c94ddcb46e0954fe Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 9 Aug 2023 10:31:26 +0100 Subject: [PATCH 83/83] Fix grammar Co-authored-by: Jason Desrosiers --- docs/adr/2023-03-30-establish-consensus-based-tsc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/adr/2023-03-30-establish-consensus-based-tsc.md b/docs/adr/2023-03-30-establish-consensus-based-tsc.md index 81b9faab..dca8e3d3 100644 --- a/docs/adr/2023-03-30-establish-consensus-based-tsc.md +++ b/docs/adr/2023-03-30-establish-consensus-based-tsc.md @@ -10,7 +10,7 @@ Story: In order to fully onboard with the OpenJS Foundation, and in order to hav It's essential that both the maintainers and community can see a clear and coherent statement about the JSON Schema project and its intentions. Currently it is not clear, and may be hard to determine. -Lack of clear and document governance makes it very difficult in some situations to move some issues forward. The current "process" is mostly undocumented and ad-hoc, with loose collective will. +Lack of clear and documented governance makes it very difficult in some situations to move some issues forward. The current "process" is mostly undocumented and ad-hoc, with loose collective will. As the number of people who can work on this full or part time grows, the organizational needs will evolve, requiring governance for long term sustainability. Having a clear and documented governance model will allow us to make clear progress with an unambiguous process defined.