provide an org level CONTRIBUTING guide

[travi]

we've recently added quite a bit of automation and process rigidity to support that automation to some of the projects that support the primary tasks of the org (mostly around the new site, but this may grow into other areas as well).

while most of this should work technically with little more than nvm install / nvm use and npm it, there are some surprises that will likely catch an outside contributor off guard. we should outline any machine setup that is either necessary or helpful in a common place that can be linked to from all of the various projects. each project may also have their own .github/CONTRIBUTING.md with any repo specific details, but those should link to the common doc for common info.

• https://github.com/blog/1184-contributing-guidelines
• https://help.github.com/articles/setting-guidelines-for-repository-contributors/
• https://mozillascience.github.io/working-open-workshop/contributing/

Examples to consider:

• https://gist.github.com/PurpleBooth/b24679402957c63ec426
• https://github.com/hoodiehq/hoodie/blob/master/CONTRIBUTING.md
• https://github.com/hapijs/.github/blob/master/CONTRIBUTING.md
• https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md

[micleners]

It would be helpful for contributors to include additional information around git cz expectations:

• commit message types (fix, bug, feat, chore, etc.) and what they are associated with
• the resulting semver change if a PR gets merged with a specific type
• expectations around commit messages

Some of this information is available here: https://www.conventionalcommits.org/en/v1.0.0/

[travi]

here's a great example laying out how following the commit convention triggers various releases: https://github.com/probot/probot/blob/master/CONTRIBUTING.md#merging-the-pull-request--releasing-a-new-version