Governance, Contribution Policy, and Code of Conduct.

I was about to comment on the new threads about core governance when I realized that all of them presume some knowledge of the structure we've adopted and have been using for some time in Node Forward.

Without discussing and being able to link to some kind of ongoing documentation I don't think the conversation threads will be very fruitful so I've gone ahead and written them up in this pull request.

They are adapted from Node Forward's fork where they are sections in the CONTRIBUTING file. Here I've put them in to their own files for clearer separation. All direct references to Node Forward have been removed so that this can be adopted by any project without confusion.

The premise is simple: the project employs a simple governance structure that can be the "final word" on contentious issues and, most importantly, owns the *contribution policy*. The contribution policy is intended to be somewhat fluid and adapt over time to the needs of the project. The current one is geared heavily towards growing the contributor base of the project because that's the biggest problem. You can imagine that after the project grows a large cohort of contributors this policy would change to adapt the challenges of distributing work among a larger contributor base.

This separation between *contributor* and *TC member* is a necessary one. Liberalizing the contribution policy has been an effective tool at growing new contributors in Node Forward and in other projects that have been employing similar policies for some time. Of course, contributors who spend a fair amount of time in the project and want to take on additional responsibilities will find themselves on the TC but the direct correlation of commit rights to being part of a sometimes boring and bureaucratic process of managing the project at a higher level is an unnecessary barrier to growing contributors.
@gramergrater Please see section 4 of the CCoC.  To re-iterate (for, hopefully, the last time), this is the same language used by many open source projects and conferences, and is well understood in context.  Your concern about the definition is noted, and I don't believe there is any more to say on that point.