doc: add WG "bootstrap kit"

Separate out the templates for bootstrapping a WG process

BasePolicies/CODE_OF_CONDUCT.md

@@ -0,0 +1,27 @@
+## Working Group Code of Conduct Template
+
+Every Working Group must have a Code of Conduct. By default,
+all repositories under the Node.js GitHub Organization fall under
+the [Node.js Code of Conduct][], but Working Groups can choose to
+define their own alternative policy. If the Working Group does choose
+it's own Code of Conduct, it must be documented in a `CODE_OF_CONDUCT.md`
+file located in the root of any repository under their stewardship.
+
+Note that the Code of Conduct adopted by a Working Group will be evaluated
+by the TSC prior to ratifying the WG's proposed charter. If that Code of
+Conduct is considered to be weaker than, or diverges too significantly from,
+the [Node.js Code of Conduct][], the TSC may defer accepting the charter until
+corrections are made.
+
+Likewise, if the WG's Code of Conduct changes after the WG has already been
+chartered and the TSC determines that the updated Code of Conduct is weaker
+than, or diverges too significantly from, the [Node.js Code of Conduct][], the
+TSC (or any Collaborator) may request that further corrections be made by
+opening an issue or a PR in the WG's repository. Should the WG choose not to
+adopt the recommended changes, the TSC may choose to revoke the WGs charter.
+
+### Template: *[insert WG name]* Code of Conduct
+
+The [Node.js Code of Conduct][] applies to this WG.
+
+[Node.js Code of Conduct]: https://github.com/nodejs/node/blob/master/CODE_OF_CONDUCT.md

BasePolicies/Charter.md

@@ -0,0 +1,28 @@
+## Working Group Charter Template
+
+Every Working Group requires a charter that describes the scope of
+the WGs responsibilities. Once written, a new Pull Request that adds
+the charter to either the [CTC][] or [TSC][] WORKING_GROUPS.md document
+must be opened. The WG is considered to be officially chartered once the
+PR adding the proposed charter is landed and merged into the relevant
+WORKING_GROUPS.md document
+
+### Template: *[insert WG name]* Working Group
+
+The Node.js *[insert WG name]* Working Group is jointly governed by the members
+of that Working Group (WG).
+
+The WG responsibilities include:
+
+* Technical direction
+* Project governance and process (including this policy)
+* Contribution policy
+* GitHub repository hosting
+* Conduct guidelines
+* Maintaining the list of additional Collaborators
+
+For the current list of WG members, see the project [README.md][].
+
+[CTC]: https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md
+[TSC]: https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md
+[README.md]: ./README.md#current-project-team-members

BasePolicies/Governance.md

@@ -0,0 +1,149 @@
+## Working Group Governance Template
+
+Every Working Group must have a documented governance model that describes the
+basic operation of the Working Group. This must be documented in the repository
+and referenced by the `README.md`.
+
+## Template: *[insert WG name]* Working Group Governance
+
+### Collaborators
+
+The *[insert WG name]* GitHub repository is
+maintained by the WG and additional Collaborators who are added by the
+WG on an ongoing basis.
+
+Individuals making significant and valuable contributions are made
+Collaborators and given commit-access to the project. These
+individuals are identified by the WG and their addition as
+Collaborators is discussed during the weekly WG meeting.
+
+Individuals who have made significant contributions and who wish to be
+considered for commit-access may create an issue or contact a WG member
+directly. It is not necessary to wait for a WG member to nominate the
+individual.
+
+Modifications of the contents of the *[insert WG repo]* repository are made on
+a collaborative basis. Anybody with a GitHub account may propose a
+modification via pull request and it will be considered by the project
+Collaborators. All pull requests must be reviewed and accepted by a
+Collaborator with sufficient expertise who is able to take full
+responsibility for the change. In the case of pull requests proposed
+by an existing Collaborator, an additional Collaborator is required
+for sign-off. Consensus should be sought if additional Collaborators
+participate and there is disagreement around a particular
+modification. See _Consensus Seeking Process_ below for further detail
+on the consensus model used for governance.
+
+Collaborators may opt to esacalate discussion about significant or
+controversial modifications to the WG as a whole by assigning the
+***WG-agenda*** tag to a pull request or issue. The WG should serve as the
+final arbiter where required.
+
+For the current list of Collaborators, see the project [README.md][].
+
+### WG Membership
+
+WG seats are not time-limited.  There is no fixed size of the WG.
+However, the expected target is between 6 and 12, to ensure adequate
+coverage of important areas of expertise, balanced with the ability to
+make decisions efficiently.
+
+There is no specific set of requirements or qualifications for WG
+membership beyond these rules.
+
+The WG may add additional members to the WG by consensus. If there are
+any objections to adding any individual member, an attempt should be
+made to resolve those objections following the WG's Consensus Seeking
+Process.
+
+A WG member may be removed from the WG by voluntary resignation, or by
+consensus of all other WG members.
+
+Changes to WG membership should be posted in the agenda, and may be
+suggested as any other agenda item (see "WG Meetings" below).
+
+If an addition or removal is proposed during a meeting, and the full
+WG is not in attendance to participate, then the addition or removal
+is added to the agenda for the subsequent meeting.  This is to ensure
+that all members are given the opportunity to participate in all
+membership decisions.  If a WG member is unable to attend a meeting
+where a planned membership decision is being made, then their consent
+is assumed.
+
+No more than 1/3 of the WG members may be affiliated with the same
+employer.  If removal or resignation of a WG member, or a change of
+employment by a WG member, creates a situation where more than 1/3 of
+the WG membership shares an employer, then the situation must be
+immediately remedied by the resignation or removal of one or more WG
+members affiliated with the over-represented employer(s).
+
+### WG Meetings
+
+*Note: Working Groups are not required to hold regular meetings. Should
+a WG decide that it does not wish to hold meetings, this section may be
+removed from the Governance document.*
+
+The WG meets weekly on a Google Hangout On Air. A designated moderator
+approved by the WG runs the meeting. Each meeting should be
+published to YouTube.
+
+Items are added to the WG agenda that are considered contentious or
+are modifications of governance, contribution policy, WG membership,
+or release process.
+
+The intention of the agenda is not to approve or review all patches;
+that should happen continuously on GitHub and be handled by the larger
+group of Collaborators.
+
+Any community member or contributor can ask that something be added to
+the next meeting's agenda by logging a GitHub Issue. Any Collaborator,
+WG member or the moderator can add the item to the agenda by adding
+the ***WG-agenda*** tag to the issue.
+
+Prior to each WG meeting the moderator will share the Agenda with
+members of the WG. WG members can add any items they like to the
+agenda at the beginning of each meeting. The moderator and the WG
+cannot veto or remove items.
+
+The WG may invite persons or representatives from certain projects to
+participate in a non-voting capacity.
+
+The moderator is responsible for summarizing the discussion of each
+agenda item and sends it as a pull request after the meeting.
+
+### Consensus Seeking Process
+
+The WG follows a [Consensus Seeking][] decision-making model.
+
+When an agenda item has appeared to reach a consensus the moderator
+will ask "Does anyone object?" as a final call for dissent from the
+consensus.
+
+If an agenda item cannot reach a consensus a WG member can call for
+either a closing vote or a vote to table the issue to the next
+meeting. The call for a vote must be seconded by a majority of the WG
+or else the discussion will continue. Simple majority wins.
+
+Note that changes to WG membership require consensus. If there are any
+objections to adding or removing individual members, an effort must be
+made to resolve those objections. If consensus cannot be reached, a
+vote may be called following the process above.
+
+### Developer's Certificate of Origin 1.0
+
+By making a contribution to this project, I certify that:
+
+* (a) The contribution was created in whole or in part by me and I
+  have the right to submit it under the open source license indicated
+  in the file; or
+* (b) The contribution is based upon previous work that, to the best
+  of my knowledge, is covered under an appropriate open source license
+  and I have the right under that license to submit that work with
+  modifications, whether created in whole or in part by me, under the
+  same open source license (unless I am permitted to submit under a
+  different license), as indicated in the file; or
+* (c) The contribution was provided directly to me by some other
+  person who certified (a), (b) or (c) and I have not modified it.
+
+[Consensus Seeking]: http://en.wikipedia.org/wiki/Consensus-seeking_decision-making
+[README.md]: ./README.md#current-project-team-members

BasePolicies/ModerationPolicy.md

@@ -0,0 +1,27 @@
+## Working Group Moderation Policy Template
+
+Every Working Group must have a Moderation Policy. By default,
+all repositories under the Node.js GitHub Organization fall under
+the [Node.js Moderation Policy][], but Working Groups can choose to
+define their own alternative policy. If the Working Group does choose
+it's own Moderation Policy, it must be documented in a `ModerationPolicy.md`
+file located in the root of any repository under their stewardship.
+
+Note that the Moderation Policy adopted by a Working Group will be evaluated
+by the TSC prior to ratifying the WG's proposed charter. If that Code of
+Conduct is considered to be weaker than, or diverges too significantly from,
+the [Node.js Moderation Policy][], the TSC may defer accepting the charter until
+corrections are made.
+
+Likewise, if the WG's Moderation Policy changes after the WG has already been
+chartered and the TSC determines that the updated Moderation Policy is weaker
+than, or diverges too significantly from, the [Node.js Moderation Policy][], the
+TSC (or any Collaborator) may request that further corrections be made by
+opening an issue or a PR in the WG's repository. Should the WG choose not to
+adopt the recommended changes, the TSC may choose to revoke the WGs charter.
+
+### Template: *[insert WG name]* Moderation Policy
+
+The [Node.js Moderation Policy] applies to this WG.
+
+[Node.js Moderation Policy]: https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md

BasePolicies/README.md

@@ -0,0 +1,42 @@
+## Establishing a new Working Group
+
+A Working Group is established by first defining a charter that can be
+ratified by the TC. A charter is a *statement of purpose*, a
+*list of responsibilities* and a *list of initial membership*.
+
+A working group needs 3 initial members. These should be individuals
+already undertaking the work described in the charter.
+
+The list of responsibilities should be specific. Once established, these
+responsibilities are no longer governed by the TC and therefore should
+not be broad or subjective. The only recourse the TC has over the working
+group is to revoke the entire charter and take on the work previously
+done by the working group themselves.
+
+If the responsibilities described in the charter are currently
+undertaken by another WG then the charter will additionally have to be
+ratified by that WG.
+
+You can submit the WG charter for ratification by sending
+a Pull Request that adds the charter to the WORKING_GROUPS.md document,
+which adds it to the list of current Working Groups. The WG is considered
+to be chartered once that PR lands. Once ratified the list of members should be
+maintained in the Working Group's README.
+
+### Base Policies for new Working Groups
+
+Once the TC ratifies a charter, the WG inherits the policies established by the
+TC for governance, contribution, conduct and an MIT LICENSE. WGs are free to
+change these documents through their own governance process but should retain
+at least the spirit of the original versions. The template documents provided
+in this directory are provided to help bootstrap that process:
+
+* [Charter Template][]
+* [Governance Template][]
+* [Code of Conduct Template][]
+* [Moderation Policy Template][]
+
+[Charter Template]: Charter.md
+[Governance Template]: Governance.md
+[Code of Conduct Template]: CODE_OF_CONDUCT.md
+[Moderation Policy Template]: ModerationPolicy.md