lint contributing

Author: gregsdennis

CONTRIBUTING.md

@@ -2,45 +2,71 @@
 
 ## Contributing to JSON Schema Specification
 
-Thanks for taking the time to contribute! 🎉👍
+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.
+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.
+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 which is ⚠️currently under discussion and development⚠️. 
+However, contributions that *do* meaningfully change the interpretation of the
+spec must follow the [Specification Development Process](./PROCESS.md).
 
 ## 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](https://github.com/json-schema-org/.github/blob/main/SUPPORT.md).
+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](https://github.com/json-schema-org/.github/blob/main/SUPPORT.md).
 
 ## Pull Requests
 
-We welcome pull requests, both for editorial suggestions and to resolve open issues.
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+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](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md).
+All official channels including the mailing list, GitHub organization and Slack
+server, follow our
+[Code of Conduct](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md).
 
 ## Have Questions?
 
-You can join the `#specification` channel in our [Slack workspace](https://json-schema.org/slack) to interact with other community members involved in the Specification development, share new ideas and ask questions.
+You can join the `#specification` channel in our
+[Slack workspace](https://json-schema.org/slack) to interact with other
+community members involved in the Specification development, share new ideas and
+ask questions.