doc: redirect 'Start a Working Group' to TSC repo

PR-URL: #9655
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>

Author: williamkapke

WORKING_GROUPS.md

@@ -19,6 +19,16 @@ A Working Group's charter can be revoked either by consensus of the Working
 Group's members or by a CTC vote. Once revoked, any future work that arises
 becomes the responsibility of the CTC.
 
+## Joining a WG
+
+To find out how to join a working group, consult the GOVERNANCE.md in
+the working group's repository, or in the working group's repository.
+
+## Starting A Core Working Group
+
+The process to start a Core Working Group is identical to [creating a
+Top Level Working Group](https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md#starting-a-wg).
+
 ## Current Working Groups
 
 * [Website](#website)
@@ -36,10 +46,6 @@ becomes the responsibility of the CTC.
 * [Documentation](#documentation)
 * [Testing](#testing)
 
-#### Process:
-
-* [Starting a Working Group](#starting-a-wg)
-* [Bootstrap Governance](#bootstrap-governance)
 
 ### [Website](https://github.com/nodejs/nodejs.org)
 
@@ -289,211 +295,3 @@ Responsibilities include:
 * Working with the Build Working Group to improve continuous integration.
 * Improving tooling for testing.
 
-## Joining a WG
-
-To find out how to join a working group, consult the GOVERNANCE.md in
-the working group's repository, or simply open an issue there.
-
-## Starting a WG
-
-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 to this document, which adds it to the
-list of current Working Groups. Once ratified the list of
-members should be maintained in the Working Group's
-README.
-
-## Bootstrap Governance
-
-Once the TC ratifies a charter the WG inherits the following
-documentation for governance, contribution, conduct and an MIT
-LICENSE. The WG is free to change these documents through their own
-governance process, hence the term "bootstrap."
-
-### *[insert WG name]* Working Group
-
-The Node.js *[insert WG name]* is jointly governed by a Working Group (WG)
-that is responsible for high-level guidance of the project.
-
-The WG has final authority over this project including:
-
-* 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](./README.md#current-project-team-members).
-
-### 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.
-
-_Note:_ If you make a significant contribution and are not considered
-for commit-access log an issue or contact a WG member directly and it
-will be brought up in the next WG meeting.
-
-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 elevate significant or controversial
-modifications, or modifications that have not found consensus to the
-WG for discussion 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](./README.md#current-project-team-members).
-
-### 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 unanimous consensus.
-
-A WG member may be removed from the WG by voluntary resignation, or by
-unanimous 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
-
-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](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
-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 unanimous consensus.  See
-"WG Membership" above.
-
-<a id="developers-certificate-of-origin"></a>
-## Developer's Certificate of Origin 1.1
-
-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.
-
-* (d) I understand and agree that this project and the contribution
-  are public and that a record of the contribution (including all
-  personal information I submit with it, including my sign-off) is
-  maintained indefinitely and may be redistributed consistent with
-  this project or the open source license(s) involved.
-
-### Moderation Policy
-
-The [Node.js Moderation Policy] applies to this WG.
-
-### 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
-[Node.js Moderation Policy]: https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md