Update CONTRIBUTING.md for current practices

* Explain current issue, milestone, and PR process
* Explain how I-Ds may be published without a new meta-schema
* Explain how meta-schemas may be updated in place
* We do not keep the "master" branch publication-ready, aside
  from how it should always build and therefore could techncially
  be submitted.  But the paragraph made it sound like "master"
  should make sense as a publishable draft which is definitely
  not always the case.

Author: handrews

CONTRIBUTING.md

@@ -2,11 +2,17 @@
 
 ## Issues
 
-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/).
+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/) or the [jsonschema tag on stackoverflow](https://stackoverflow.com/tags/jsonschema).
 
-Issues waiting for user feedback will be tagged "Feedback". Up to two weeks will be given for feedback to be provided.
+## Milestones
 
-If there seems to be consensus around an issue, the issue will be taken up (and tagged with a milestone) or closed.
+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.
 
 ## Pull requests
 
@@ -18,13 +24,21 @@ Changes that would affect implementation behavior should typically be opened as
 
 Pull requests should be made to master.
 
-## Writing guidelines
+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.
+
+## Internet-Drafts and meta-schemas
+
+An Internet-Draft (I-D) publication replaces previous documents in their entirety.
+
+I-D updates that are purely editorial bug fixes (with no implementation-impacting changes) will continue to use the same meta-schemas as the version that they fix.
+
+I-D updates that impact behavior, whether as a bug fix or a new, changed, or removed feature, will have new meta-schemas published along with them.
 
-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.
+The meta-schema URI is used to differentiate between different vocabularies (currently only Validation and Hyper-Schema).
 
-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.
+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.
 
-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.
+As an informative document, bugs in the meta-schema may be fixed in place to align them with the normative specification.  Examples of in-place fixes include adding an accidentally omitted keyword or fixing an incorrect type.  By definition, no correct schema should fail validation against the meta-schema after a bug fix, although previously validating incorrect schemas may start to (correctly) fail validation.
 
 ## Conduct