Skip to content

Latest commit

 

History

History
72 lines (49 loc) · 2.83 KB

CONTRIBUTING.md

File metadata and controls

72 lines (49 loc) · 2.83 KB

Guidelines for contributing to the JSON Schema project

Contributing to JSON Schema Specification

Thanks for taking the time to contribute! 🎉👍

JSON Schema is an evolving language. This repository contains the specification text as well as Pull Requests with suggested improvements and contributions.

Contributions that do not change the interpretation of the spec but instead improve legibility, fix editorial errors, clear up ambiguity and improve examples are encouraged and are often merged by a spec editor with little process.

However, contributions that do meaningfully change the interpretation of the spec must follow the Specification Development Process.

Issues

Issues should identify a problem, enhancement, or use case; and propose some course of action for the draft. For alternate support channels, see the SUPPORT.md.

Pull Requests

We welcome pull requests, both for editorial suggestions and to resolve open issues.

If the pull request would solve a particular issue, reference the issue in the pull request description.

Changes that would affect implementation behavior should typically be opened as an issue first.

Generally, pull requests should be made to the main branch unless it is a patch update and we are in a patch phase. In that case there will be a branch named something like 2020-12-patch that the PR should target instead.

Most PRs, including all PRs that impact implementation behavior, will be left open for a minimum of 14 days. Minor wording fixes may be merged more quickly once approved by a project member.

Milestones

Each milestone is an estimation of the work that will be done for the next draft. Milestones are typically named after the meta-schema draft number, and the open milestone with the lowest draft number is the current active project.

Issues may be removed from a milestoned due to lack of consensus, lack of anyone with the correct expertise to make a PR, or simply because we wish to publish a draft and defer the remaining issues to the next draft.

Numbered milestones other than the lowest-numbered one are used to tentatively organize future work, but may be completely reorganized once work on that draft actually begins.

The draft-future milestone is for issues for which there is an agreement that they should be addressed, but no specific timeline.

Code of Conduct

All official channels including the mailing list, GitHub organization and Slack server, follow our Code of Conduct.

Have Questions?

You can join the #specification channel in our Slack workspace to interact with other community members involved in the Specification development, share new ideas and ask questions.