doc: move WORKING_GROUPS.md into CTC repository

WORKING_GROUPS.md

@@ -0,0 +1,281 @@
+# Node.js Core Working Groups
+
+Node.js Core Working Groups are autonomous projects created by the
+[Core Technical Committee (CTC)](https://github.com/nodejs/node/blob/master/GOVERNANCE.md#core-technical-committee).
+
+Working Groups can be formed at any time but must be ratified by the CTC.
+Once formed the work defined in the Working Group charter is the
+responsibility of the WG rather than the CTC.
+
+It is important that Working Groups are not formed pre-maturely. Working
+Groups are not formed to *begin* a set of tasks but instead are formed
+once that work is already underway and the contributors
+think it would benefit from being done as an autonomous project.
+
+If the work defined in a Working Group's charter is complete, the charter
+should be revoked.
+
+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)
+* [Streams](#streams)
+* [Build](#build)
+* [Diagnostics](#diagnostics)
+* [i18n](#i18n)
+* [Evangelism](#evangelism)
+* [Docker](#docker)
+* [Addon API](#addon-api)
+* [Benchmarking](#benchmarking)
+* [Post-mortem](#post-mortem)
+* [Intl](#intl)
+* [Documentation](#documentation)
+* [Testing](#testing)
+
+
+### [Website](https://github.com/nodejs/nodejs.org)
+
+The website Working Group's purpose is to build and maintain a public
+website for the Node.js project.
+
+Responsibilities include:
+* Developing and maintaining a build and automation system for nodejs.org.
+* Ensuring the site is regularly updated with changes made to Node.js, like
+  releases and features.
+* Fostering and enabling a community of translators.
+
+### [Streams](https://github.com/nodejs/readable-stream)
+
+The Streams Working Group is dedicated to the support and improvement of the
+Streams API as used in Node.js and the npm ecosystem. We seek to create a
+composable API that solves the problem of representing multiple occurrences
+of an event over time in a humane, low-overhead fashion. Improvements to the
+API will be driven by the needs of the ecosystem; interoperability and
+backwards compatibility with other solutions and prior versions are paramount
+in importance.
+
+Responsibilities include:
+* Addressing stream issues on the Node.js issue tracker.
+* Authoring and editing stream documentation within the Node.js project.
+* Reviewing changes to stream subclasses within the Node.js project.
+* Redirecting changes to streams from the Node.js project to this project.
+* Assisting in the implementation of stream providers within Node.js.
+* Recommending versions of `readable-stream` to be included in Node.js.
+* Messaging about the future of streams to give the community advance notice of
+  changes.
+
+### [Build](https://github.com/nodejs/build)
+
+The Build Working Group's purpose is to create and maintain a distributed
+automation infrastructure.
+
+Responsibilities include:
+* Producing packages for all target platforms.
+* Running tests.
+* Running performance testing and comparisons.
+* Creating and managing build-containers.
+
+### [Diagnostics](https://github.com/nodejs/diagnostics)
+
+The Diagnostics Working Group's purpose is to surface a set of comprehensive,
+documented, and extensible diagnostic interfaces for use by Node.js tools and
+JavaScript VMs.
+
+Responsibilities include:
+* Collaborating with V8 to integrate `v8_inspector` into Node.js.
+* Collaborating with V8 to integrate `trace_event` into Node.js.
+* Collaborating with Core to refine `async_wrap` and `async_hooks`.
+* Maintaining and improving OS trace system integration (e.g. ETW, LTTNG, dtrace).
+* Documenting diagnostic capabilities and APIs in Node.js and its components.
+* Exploring opportunities and gaps, discussing feature requests, and addressing
+  conflicts in Node.js diagnostics.
+* Fostering an ecosystem of diagnostics tools for Node.js.
+
+### i18n
+
+The i18n Working Groups handle more than just translations. They
+are endpoints for community members to collaborate with each
+other in their language of choice.
+
+Each team is organized around a common spoken language. Each
+language community might then produce multiple localizations for
+various project resources.
+
+Responsibilities include:
+* Translating any Node.js materials they believe are relevant to their
+  community.
+* Reviewing processes for keeping translations up to date and of high quality.
+* Managing and monitoring social media channels in their language.
+* Promoting Node.js speakers for meetups and conferences in their language.
+
+Note that the i18n Working Groups are distinct from the [Intl](#Intl) Working Group.
+
+Each language community maintains its own membership.
+
+* [nodejs-ar - Arabic (اللغة العربية)](https://github.com/nodejs/nodejs-ar)
+* [nodejs-bg - Bulgarian (български език)](https://github.com/nodejs/nodejs-bg)
+* [nodejs-bn - Bengali (বাংলা)](https://github.com/nodejs/nodejs-bn)
+* [nodejs-zh-CN - Chinese (中文)](https://github.com/nodejs/nodejs-zh-CN)
+* [nodejs-cs - Czech (Český Jazyk)](https://github.com/nodejs/nodejs-cs)
+* [nodejs-da - Danish (Dansk)](https://github.com/nodejs/nodejs-da)
+* [nodejs-de - German (Deutsch)](https://github.com/nodejs/nodejs-de)
+* [nodejs-el - Greek (Ελληνικά)](https://github.com/nodejs/nodejs-el)
+* [nodejs-es - Spanish (Español)](https://github.com/nodejs/nodejs-es)
+* [nodejs-fa - Persian (فارسی)](https://github.com/nodejs/nodejs-fa)
+* [nodejs-fi - Finnish (Suomi)](https://github.com/nodejs/nodejs-fi)
+* [nodejs-fr - French (Français)](https://github.com/nodejs/nodejs-fr)
+* [nodejs-he - Hebrew (עברית)](https://github.com/nodejs/nodejs-he)
+* [nodejs-hi - Hindi (फिजी बात)](https://github.com/nodejs/nodejs-hi)
+* [nodejs-hu - Hungarian (Magyar)](https://github.com/nodejs/nodejs-hu)
+* [nodejs-id - Indonesian (Bahasa Indonesia)](https://github.com/nodejs/nodejs-id)
+* [nodejs-it - Italian (Italiano)](https://github.com/nodejs/nodejs-it)
+* [nodejs-ja - Japanese (日本語)](https://github.com/nodejs/nodejs-ja)
+* [nodejs-ka - Georgian (ქართული)](https://github.com/nodejs/nodejs-ka)
+* [nodejs-ko - Korean (조선말)](https://github.com/nodejs/nodejs-ko)
+* [nodejs-mk - Macedonian (Mакедонски)](https://github.com/nodejs/nodejs-mk)
+* [nodejs-ms - Malay (بهاس ملايو)](https://github.com/nodejs/nodejs-ms)
+* [nodejs-nl - Dutch (Nederlands)](https://github.com/nodejs/nodejs-nl)
+* [nodejs-no - Norwegian (Norsk)](https://github.com/nodejs/nodejs-no)
+* [nodejs-pl - Polish (Język Polski)](https://github.com/nodejs/nodejs-pl)
+* [nodejs-pt - Portuguese (Português)](https://github.com/nodejs/nodejs-pt)
+* [nodejs-ro - Romanian (Română)](https://github.com/nodejs/nodejs-ro)
+* [nodejs-ru - Russian (Русский)](https://github.com/nodejs/nodejs-ru)
+* [nodejs-sv - Swedish (Svenska)](https://github.com/nodejs/nodejs-sv)
+* [nodejs-ta - Tamil (தமிழ்)](https://github.com/nodejs/nodejs-ta)
+* [nodejs-tr - Turkish (Türkçe)](https://github.com/nodejs/nodejs-tr)
+* [nodejs-zh-TW - Taiwanese (Hō-ló)](https://github.com/nodejs/nodejs-zh-TW)
+* [nodejs-uk - Ukrainian (Українська)](https://github.com/nodejs/nodejs-uk)
+* [nodejs-vi - Vietnamese (Tiếng Việtnam)](https://github.com/nodejs/nodejs-vi)
+
+### [Intl](https://github.com/nodejs/Intl)
+
+The Intl Working Group is dedicated to support and improvement of
+Internationalization (i18n) and Localization (l10n) in Node.
+
+Responsibilities include:
+* Ensuring functionality & compliance (standards: ECMA, Unicode…)
+* Supporting Globalization and Internationalization issues that come up
+  in the tracker
+* Communicating guidance and best practices
+* Refining the existing `Intl` implementation
+
+The Intl Working Group is not responsible for translation of content. That is the
+responsibility of the specific [i18n](#i18n) group for each language.
+
+### [Evangelism](https://github.com/nodejs/evangelism)
+
+The Evangelism Working Group promotes the accomplishments
+of Node.js and lets the community know how they can get involved.
+
+Responsibilities include:
+* Facilitating project messaging.
+* Managing official project social media.
+* Handling the promotion of speakers for meetups and conferences.
+* Handling the promotion of community events.
+* Publishing regular update summaries and other promotional
+  content.
+
+### [Docker](https://github.com/nodejs/docker-iojs)
+
+The Docker Working Group's purpose is to build, maintain, and improve official
+Docker images for the Node.js project.
+
+Responsibilities include:
+* Keeping the official Docker images updated in line with new Node.js releases.
+* Decide and implement image improvements and/or fixes.
+* Maintain and improve the images' documentation.
+
+### [Addon API](https://github.com/nodejs/nan)
+
+The Addon API Working Group is responsible for maintaining the NAN project and
+corresponding _nan_ package in npm. The NAN project makes available an
+abstraction layer for native add-on authors for Node.js,
+assisting in the writing of code that is compatible with many actively used
+versions of Node.js, V8 and libuv.
+
+Responsibilities include:
+* Maintaining the [NAN](https://github.com/nodejs/nan) GitHub repository,
+  including code, issues and documentation.
+* Maintaining the [addon-examples](https://github.com/nodejs/node-addon-examples)
+  GitHub repository, including code, issues and documentation.
+* Maintaining the C++ Addon API within the Node.js project, in subordination to
+  the Node.js CTC.
+* Maintaining the Addon documentation within the Node.js project, in
+  subordination to the Node.js CTC.
+* Maintaining the _nan_ package in npm, releasing new versions as appropriate.
+* Messaging about the future of the Node.js and NAN interface to give the
+  community advance notice of changes.
+
+The current members can be found in their
+[README](https://github.com/nodejs/nan#collaborators).
+
+### [Benchmarking](https://github.com/nodejs/benchmarking)
+
+The purpose of the Benchmark Working Group is to gain consensus
+on an agreed set of benchmarks that can be used to:
+
+* track and evangelize performance gains made between Node.js releases
+* avoid performance regressions between releases
+
+Responsibilities include:
+* Identifying 1 or more benchmarks that reflect customer usage.
+  Likely will need more than one to cover typical Node.js use cases
+  including low-latency and high concurrency
+* Working to get community consensus on the list chosen
+* Adding regular execution of chosen benchmarks to Node.js builds
+* Tracking/publicizing performance between builds/releases
+
+### [Post-mortem](https://github.com/nodejs/post-mortem)
+
+The Post-mortem Diagnostics Working Group is dedicated to the support
+and improvement of postmortem debugging for Node.js. It seeks to
+elevate the role of postmortem debugging for Node, to assist in the
+development of techniques and tools, and to make techniques and tools
+known and available to Node.js users.
+
+Responsibilities include:
+* Defining and adding interfaces/APIs in order to allow dumps
+  to be generated when needed.
+* Defining and adding common structures to the dumps generated
+  in order to support tools that want to introspect those dumps.
+
+### [Documentation](https://github.com/nodejs/docs)
+
+The Documentation Working Group exists to support the improvement of Node.js
+documentation, both in the core API documentation, and elsewhere, such as the
+Node.js website. Its intent is to work closely with the Evangelism, Website, and
+Intl Working Groups to make excellent documentation available and accessible
+to all.
+
+Responsibilities include:
+* Defining and maintaining documentation style and content standards.
+* Producing documentation in a format acceptable for the Website Working Group
+  to consume.
+* Ensuring that Node's documentation addresses a wide variety of audiences.
+* Creating and operating a process for documentation review that produces
+  quality documentation and avoids impeding the progress of Core work.
+
+### [Testing](https://github.com/nodejs/testing)
+
+The Node.js Testing Working Group's purpose is to extend and improve testing of
+the Node.js source code.
+
+Responsibilities include:
+* Coordinating an overall strategy for improving testing.
+* Documenting guidelines around tests.
+* Working with the Build Working Group to improve continuous integration.
+* Improving tooling for testing.
+