Let's write a Charter!

[Relequestual]

Progress tracked with draft PR: #325

---

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.

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. I've done some research to look for common elements found in project charters and what people have published about writing charters.

I propose we have an open discussion to enable us to start forming a charter.

• For each section in the charter template, vote up or down (thumbs up/down) if you think it should be included or not, and comment to suggest what you would like to see in it
• For any additional section proposals, create a new thread, and ask that it be added to the list here
• For each additional section proposed, vote up or down (thumbs up/down) if you think it should be included or not, and comment to suggest what you would like to see in it

This feels like the most open approach to take, however I'm more than happy to discuss any alterations or totally alternative approaches.

Here's the list of the headings found in the OpenJS Foundation Project Charter Template.

In the template, each section has a link to examples. For further examples, check out the real charters linked in the mentioned and linked charter research page above.

• Section 0: Guiding Principles (optional)
• Section 1: Scope
  • 1.1: In-scope (optional)
  • 1.2: Out-of-Scope (optional)
• Section 2: Relationship with OpenJS Foundation CPC
  • 2.1 Other Formal Project Relationships (optional)
• Section 3: ${PROJECT TSC} Governing Body
• Section 4: Roles & Responsibilities
  • Section 4.1 Project Operations & Management (optional)
  • Section 4.2: Decision-making, Voting, and/or Elections (optional)
  • Section 4.3: Other Project Roles (optional)
• Section 5: Definitions (optional)

The "directions" in each posting is an exact copy from the OpenJS Foundation template.
It's my understanding that the charter will need to be reviewed and ratified through the OpenJS Foundation, as an FYI.

[Relequestual]

Section 0: Guiding Principles (optional)

directions: provide a concise, high-level statement about the project's long-term principles, values, or mission.

[Relequestual]

Example points to the node.js charter. A few other OpenJS Foundations have a charter. They all read...

The [Node.js] project is part of the OpenJS Foundation which operates transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.

We could simply copy this format as is.

[Relequestual]

Suggestion:

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.

[Relequestual]

Suggesting as an addition:

Having no structure in place usually leads to an informal and undocumeted structure, 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.

[gregsdennis]

Having no structure in place usually leads to an informal and undocumeted structure...

This is a bit redundant. Maybe

Having no structure in place usually leads to one that is informal and undocumeted...

[Relequestual]

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.

[Relequestual]

Suggestion:

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.

[gregsdennis]

nits

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.

[Relequestual]

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'.

[benjagm]

Community

• Enabling schema authors
• Enabling implementers
• Eliciting feedback from industry
• Communicating value

I'd suggest add a new point to focus on project sustainability:

• Ensuring the sustainability of the project

[jviotti]

Isn't linting part of critical tooling?

[benjagm]

• Eliciting feedback from industry

I'd suggest changing the wording to clearly state that is not only about feedback is also about actively engage with organizations and entities with an interest in JSON Schema.

[Relequestual]

@jdesrosiers @jviotti I agree that linting is critical tooling, so I'll remove it from being called out explicitly. I wanted to make sure others agreed that linting matters. Critical tooling could be seen as just things which help implementations as opposed to authoring, but I'm glad you both agree it extends beyond that.

[Relequestual]

I have made changes and pushed to the draft PR: #325 awaiting feedback.

[Relequestual]

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'.

[jdesrosiers]

I don't think it's necessary to have both an in-scope and out-of-scope section. I suggest just doing the in-scope section. Anything not mentioned in that section is out of scope.

[gregsdennis]

Do we have anything that we explicitly will not consider for being in scope? It might be useful to list those here.

[Relequestual]

Section 2: Relationship with OpenJS Foundation CPC.

directions: describe how the project intersects with the Cross Project Council.

[Relequestual]

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"). OpenJS Foundation's business leadership is the Board of Directors (the "Board").

This is the standard text that most OpenJS Foundation projects use.
Note: I'm asking the OpenJS Foundation what the practical implications of the last sentence is.
Note: This does not include funds raised through Open Collective. See the "OpenJS Foundation Trademarks and Crowdfunding" section in the OpenJS Foundation's trandmark policy.

[Relequestual]

Digging into this further, the sentence at the end of that paragraph originates from the merging of foundations where the node.js project has this in their charter.
It was suggested that we could simply remove it, although that still doesn't for me answer the question of "Well, who DOES then have business leadership responsibilities?"

I'm half tempted to say, we could figure that out later down the line, but that doesn't sit right with me on this.

The previously mentioned trademark policy effectivly means that no OpenJS Foundation project "has it's own money", and any raising or collecting of money is purley by the individuals doing it, and therefore at their discression, with no juristiction under the OpenJS Foundation. I'm gount to try and clarify this position unofficially, and officially.

ESLint for example, does have the required disclaimer on their Open Collective...

This Collective is run by and for the benefit of the independent contributors to the ESLint open source software project. This Collective is not endorsed or administered by OpenJS Foundation, Inc. (the “OpenJS Foundation”), the OpenJS Foundation does not receive and has no control over any funds contributed, the OpenJS Foundation does not direct or otherwise supervise the actions of any contributor to the ESLint project, and all donations made will be expended for the private benefit of or otherwise to reimburse individuals that do not have an employer/employee, contractor, or other agency relationship with the OpenJS Foundation. The ESLint marks used herein are used under license from the OpenJS Foundation for the benefit of the open source software community.

I wonder how many people or orgs who are donating realise that? I don't think it's a major problem, but it is somewhat unexpected.

I'm going to ask for some examples of actions a project TSC would not be allowed or expected to take, which should be defurred to the "Business Leadership of the OpenJS Foundation".

[Relequestual]

I enquired about this. It's mostly in relation to things one might do if JSON Schema was a legal entity. For example, we cannot enter into contracts as JSON Schema, such as to provide services for donation or funding.

I'm fine (and so are they) for us to leave out that sentence until such times as we want or need to reference "the board" specifically in our charter or other policy documents.

[gregsdennis]

Do we have a TSC? Would that just be the (loosely defined) core members?

Edit: See further down

[Relequestual]

Formally, no. Informally, effectivly almost the same thing? Yeah. Loosely defined, as you say.

[Relequestual]

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'.

[Relequestual]

Section Intentionally Left Blank

I don't think we have any formal relationships with any other groups right now.

[gregsdennis]

OpenAPI?

[Relequestual]

It's not a formal relationship though. We are not accountable or provide any specific privlidges or rights to them.

[Relequestual]

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.

[jdesrosiers]

We've never done voting before other than as a non-formal measure of support for something. We should discuss exactly how that would work if we want to include voting in our process.

[Relequestual]

We've never done voting before other than as a non-formal measure of support for something. We should discuss exactly how that would work if we want to include voting in our process.

Yes, 100%. I've actually decided to move this part of that section to another better fitting section which explains explicitly how this would work. Section 4.2. I should be posting my proposal for it today or tomorrow at the latest.

[Relequestual]

Suggested revision:
(The part about voting was moved to 4.2, given voting is in the title)

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.

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.

No more than one-third of the TSC members may be affiliated with the same employer. If removal or resignation of a TSC member, or a change of employment by a TSC member, creates a situation where more than one-third of the TSC membership shares an employer, then the situation must be immediately remedied by the resignation or removal of one or more TSC members affiliated with the over-represented employer(s).
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

[gregsdennis]

It feels weird reading through the doc and having Section 3 use "TSC" when it's not defined until Section 4.

[Relequestual]

It feels weird reading through the doc and having Section 3 use "TSC" when it's not defined until Section 4.

It is defined in Section 2.
However, I will also add it to the Definitions section for good measure.

[Relequestual]

Section 4: Roles & Responsibilities

directions: describe the roles and responsibilities of the ${PROJECT} Governing Body.

[Relequestual]

I propose the following, with inspiration from webdriver and node.js TSC governance documents:

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

[gregsdennis]

What about mediating non-technical (e.g. interpersonal) conflicts?

[Relequestual]

That's a good question. I think @benjagm is looking to investigate that here: https://github.com/orgs/json-schema-org/discussions/319

[benjagm]

This has been discussed in past's week OCWM. I did some research among projects member of the OpenJS Foundation and other OSS large communities and I included my findings and a proposal in that discussion (#319)

[Relequestual]

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'.

[Relequestual]

Looking at other charters, including the node.js TSC, I think the following might be the only part required...

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.

This is in specific relation to DCO or CLA use, which is a requirement of the OpenJS Foundation, and the IP Policy.

[Relequestual]

Having not received any feedback on this tiny section, I'll assume this is OK, and rely on the final overall review for people to raise any questions at that point, and for now call it "done".

[Relequestual]

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'.

[Relequestual]

Updated section 4.2 content:
(Also visible on this specific commit in the tracking PR)

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.

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.

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.

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.

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. 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)

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.

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 GitHub Reactions on the comment.

The "Determine resolution" step should result in the creation of an Any Decision Record. 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.
--? 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 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 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.

[gregsdennis]

I tend to agree with @jdesrosiers. This needs some sort of definition of what "consensus" means. This would in turn define the threshold for moving to a vote.

Secondarily, if we use a non-unanimous consensus, does that make voting moot since we'd have to calculate the consensus... by voting?

[Relequestual]

@gregsdennis I hear you on this. I'm going to make it clearer.

...if we use a non-unanimous consensus, does that make voting moot since we'd have to calculate the consensus... by voting?

Not quite. With the test for agreement step, if there isn't consensus, we go back the form or amend proposal steps, while a vote determines if the "motion" carries or not.

Also, there are different affirmations. When testing for agreement, the "signals" include "block", "stand-aside", "reservations", and "agreement". While with voting, has "in favour", "against", and "abstain".

While we won't REQUIRE unanimous consensus, we should strive for it, and will have multiple attempts to do so. I hope that in the vast majority of cases, we will be able to readch unanimous consensus.

The idea of not requiring unanimos consensus in all cases is to balance power, by preventing one individual from hoding more power than the remaining group.

I will clearly define what a "block" signal means, and the requireiemnts that come with making that signal, in addition to the other signals.

[Relequestual]

I've updated section 4.2 in this draft PR: #325

Let me know if this addresses some of your concerns.

[Relequestual]

I've further updated section 4.2 in the PR. The requirements for Issues and Discussions are now mroe clearly defined.

[Relequestual]

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'.

[benjagm]

Some notes:

Technical Advisory Council? Chair/s? - Already defined enough in other sections? Collaborator/contributor/maintainer? Community Champions?

Consider responsibilites, rights, permissions, requirements, appointment, stepping down/removal...

• IMHO, At this stage, the role descriptions should be ok. We can create a separate document with the responsibilities and election process for Chair/TSC and later continue with the Technical Advisory Board, which I think will be key to re-engage implementation maintainers.
• Is implementer something to describe alongside Collaborator/contributor/maintainer? We are using the term quite a lot.

[Julian]

I'll mention here so it's not lost something that I mentioned in passing somewhere in Slack -- I think most of us probably think we also need a non-technical steering group at some point.

I don't know whether it's necessary to block the former on the latter -- in some sense it's extra work to agree on the latter, but on the other hand I think it's important not to make either "org" not seem more important than the other, nor seem "primary", since both technical health as well as "organizational/financial/brand" health are important.

I used treasurer as a specific example, but really it's any/all/probably more of:

• Ensuring the health of JSON Schema as a "brand"
• Strategic allocation of funds / "budgeting" for investment in JSON Schema improvements on some regular budget cadence
• Approving specific fund allocation, ensuring that such allocations are approved, tracked, logged, meet any taxation requirements etc.

Here are 2 (quickly chosen) examples of such a structure:

• Django
• OAI -- see "Business Governance Board"

I don't think we need a full blown, giant, bureaucratic organization on day 1, but having two or three members of such a group, or even having a person tasked with forming such a group (and having us all approve that person doing so) might be a good step to take before we fully move forward.

(As I say, the above is only partly formed thoughts!)

[Relequestual]

Related: #286 (reply in thread)

The OpenJS Foundation delegates the technical leadership through the charter.
It doesn't say explicitly that the OpenJS Foundation holds business decisions, but it is implied, and I did ask for clarification (and it was confirmed) that business decisions mostly rest with OpenJS Foudnation.

I say mostly, because as JSON Schema we have funds, but they are not legally part of the project... OpenJS Foundation deliberatly distances themselves for legal reasons, requiring a disclaimer that the funds raised are not under its control or supervision, and are for the "private benefit of or otherwise to reimurse individuals [not paid by OpenJSF]".

I THINK I'm in favour of a non-technical board of some kind, but such would have to be worked out with the OpenJS Foundation.

@benjagm can you add a task to your long term list to research what other OpenJS Foundation projects do? Specifically, do they have any recognised non-technical group to make non-technical decisions?

[Relequestual]

@Julian I have pushed the following to the draft branch. Let me know what you think.

Section 4.3: Other Project Roles (optional)

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.

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

[Julian]

Thumbs up from me, looks great.

[Relequestual]

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'.

[Relequestual]

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.

[Relequestual]

Added the following...

TSC: The Technical Steering Committee, delegated technical leadership for the JSON Schema project by the OpenJS Foundation.