Skip to content

Commit 2f1e7d5

Browse files
authored
Merge pull request #362 from handrews/contrib
Start a contributing guide from the wiki contents.
2 parents beecae5 + 175df04 commit 2f1e7d5

File tree

1 file changed

+31
-0
lines changed

1 file changed

+31
-0
lines changed

CONTRIBUTING.md

+31
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
# Guidelines for contributing to the JSON Schema project
2+
3+
## Issues
4+
5+
Issues should identify an problem, enhancement, or use case; and propose some course of action for the draft. For alternate support channels, [see the json-schema.org website](http://json-schema.org/).
6+
7+
Issues waiting for user feedback will be tagged "Feedback". Up to two weeks will be given for feedback to be provided.
8+
9+
If there seems to be consensus around an issue, the issue will be taken up (and tagged with a milestone) or closed.
10+
11+
## Pull requests
12+
13+
We welcome pull requests, both for editorial suggestions and to resolve open issues.
14+
15+
If the pull request would solve a particular issue, reference the issue in the pull request description.
16+
17+
Changes that would affect implementation behavior should typically be opened as an issue first.
18+
19+
Pull requests should be made to master.
20+
21+
## Writing guidelines
22+
23+
An Internet-Draft publication replaces previous documents in their entirety. Behavorial changes to the document should be reverse-compatible with existing written schemas, or allow for implementations to implement old and removed behavior.
24+
25+
The meta-schema URI is used to differentiate between different vocabularies (Validation and Hyper-schema). The authority on JSON Schema behavior is the respective specification document, not the JSON meta-schema; the JSON version of the meta-schema is maintained in an informative capacity only. However, the meta-schema URI referred to in the document should desginate a fixed JSON document, and updates to this document should be publised at a new URI. Updates should be made to the meta-schema and published at a time when it becomes desirable for new behaviors and features to be described in this fashion.
26+
27+
The "master" branch should always be Internet-Draft ready. The document editor is responsible for ensuring that the writing meets best practices for an I-D. An I-D will be published from "master" branch when wider review is desired, at the editor's discretion.
28+
29+
## Conduct
30+
31+
All official channels including the mailing list, GitHub organization, and Freenode channel, follow the IETF Guidelines for Conduct as specified in [RFC7154](https://tools.ietf.org/html/rfc7154).

0 commit comments

Comments
 (0)