The JSON Schema Charter

CHARTER.md

@@ -0,0 +1,108 @@
+# JSON Schema Charter
+<!-- This document is managed in the json-schema-org/community GitHub repository. Please do NOT modify this file in another repository as changes may be overridden. -->
+
+## 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 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.
+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 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
+  - Validation of JSON-compatible data
+  - Semantic annotation of JSON-compatible data
+  - Interoperability
+  - Extensibility
+- Critical tooling
+- Documentation
+- Test suite
+- Community
+  - Enabling schema authors
+  - Enabling implementers
+  - Engaging with industry
+  - Engaging with upstream and downstream standards and projects
+  - 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
+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").
+
+### 2.1 Other Formal Project Relationships
+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.
+
+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
+
+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:
+
+- Technical direction
+- 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
+- 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 or the CPC relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy.
+
+#### Decision-making
+
+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. 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
+
+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
+
+TSC: The JSON Schema Technical Steering Committee, delegated technical leadership for the JSON Schema project by the OpenJS Foundation.
+
+---
+
+CC-BY 4.0 (c) The JSON Schema Project contributors

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.

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 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.
+
+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 <!-- optional -->
+
+- 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 <!-- optional -->
+
+- 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 <!-- optional -->
+
+- 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 <!-- optional -->
+
+### 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 <!-- optional -->
+
+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