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.
I find this peculiar because I thought the goal from the outset was fostering "a friendly, safe and welcoming environment". Diversity isn't something you *create*, it's something that happens naturally in precisely such an environment as previously outlined. In other words, is diversity a means to an end or an end in itself? There may be contexts in which diversity is indeed a goal in and of itself, but we're talking software projects. Yes, I understand there have been issues in the past and I'm not in any way downplaying any of them. On the contrary, when looking at the underpinnings a bigger concern unfolds.

It is my understanding that discrimination is about creating hierarchies based on prejudice, a false sense of dominance that's not rational or neutral towards entities identifiable by a given trait. With this in mind, it becomes almost trivial to see where it occurs.

In writing "socially marginalized groups" to mean "women", you perpetuate the beliefs that women are "socially marginalized". Whether or not diversity is the goal, this doesn't help to end the status quo at all. It takes anyone who currently feels marginalised and enforces the dominance of the majority all whilst saying "don't do that". Why do these people feel that way? It may have to do with how documents like this mention it, somewhat covertly as to not be too insensitive, but anyone with half a brain can still distil what it really says.