mirror of
https://github.com/nodejs/node.git
synced 2024-11-29 23:16:30 +01:00
132e44b402
Fixes: https://github.com/nodejs/CTC/issues/41 PR-URL: https://github.com/nodejs/node/pull/10604 Fixes: https://github.com/nodejs/CTC#41 Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Michal Zasso <targos@protonmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
282 lines
12 KiB
Markdown
282 lines
12 KiB
Markdown
# 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.
|
||
|