doc: grammar and structure revisions of wg doc
PR-URL: https://github.com/nodejs/node/pull/9495 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io>
This commit is contained in:
Ryan Lewis
Roman Reiss
parent
4affb8929f
commit
bf3e4bb324
@ -41,66 +41,65 @@ back in to the CTC.
|
||||
|
||||
### [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.
|
||||
The website Working Group's purpose is to build and maintain a public
|
||||
website for the Node.js project.
|
||||
|
||||
Its responsibilities are:
|
||||
* Develop and maintain a build and automation system for `nodejs.org`.
|
||||
* Ensure the site is regularly updated with changes made to `Node.js` like
|
||||
releases and features.
|
||||
* Foster and enable a community of translators.
|
||||
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 WG 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. Our
|
||||
responsibilities include:
|
||||
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.
|
||||
|
||||
* 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.
|
||||
|
||||
Its responsibilities are:
|
||||
* Produce Packages for all target platforms.
|
||||
* Run tests.
|
||||
* Run performance testing and comparisons.
|
||||
* Creates and manages build-containers.
|
||||
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.
|
||||
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.
|
||||
|
||||
Its responsibilities are:
|
||||
|
||||
* Collaborate with V8 to integrate `v8_inspector` into Node.js.
|
||||
* Collaborate with V8 to integrate `trace_event` into Node.js.
|
||||
* Collaborate with Core to refine `async_wrap` and `async_hooks`.
|
||||
* Maintain and improve OS trace system integration (e.g. ETW, LTTNG, dtrace).
|
||||
* Document diagnostic capabilities and APIs in Node.js and its components.
|
||||
* Explore opportunities and gaps, discuss feature requests, and address
|
||||
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.
|
||||
* Foster an ecosystem of diagnostics tools for Node.js.
|
||||
* Fostering an ecosystem of diagnostics tools for Node.js.
|
||||
|
||||
### i18n
|
||||
|
||||
The i18n working groups handle more than just translations. They
|
||||
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.
|
||||
|
||||
@ -108,16 +107,14 @@ Each team is organized around a common spoken language. Each
|
||||
language community might then produce multiple localizations for
|
||||
various project resources.
|
||||
|
||||
Their responsibilities are:
|
||||
* Translations of any Node.js materials they believe are relevant to their
|
||||
community.
|
||||
* Review processes for keeping translations up
|
||||
to date and of high quality.
|
||||
* Social media channels in their language.
|
||||
* Promotion of Node.js speakers for meetups and conferences in their
|
||||
language.
|
||||
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.
|
||||
Note that the i18n Working Groups are distinct from the [Intl](#Intl) Working Group.
|
||||
|
||||
Each language community maintains its own membership.
|
||||
|
||||
@ -159,33 +156,37 @@ Each language community maintains its own membership.
|
||||
### [Intl](https://github.com/nodejs/Intl)
|
||||
|
||||
The Intl Working Group is dedicated to support and improvement of
|
||||
Internationalization (i18n) and Localization (l10n) in Node. Its responsibilities are:
|
||||
Internationalization (i18n) and Localization (l10n) in Node.
|
||||
|
||||
1. Functionality & compliance (standards: ECMA, Unicode…)
|
||||
2. Support for Globalization and Internationalization issues that come up in the tracker
|
||||
3. Guidance and Best Practices
|
||||
4. Refinement of existing `Intl` implementation
|
||||
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 WG is not responsible for translation of content. That is the responsibility of the specific [i18n](#i18n) group for each language.
|
||||
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
|
||||
The Evangelism Working Group promotes the accomplishments
|
||||
of Node.js and lets the community know how they can get involved.
|
||||
|
||||
Their responsibilities are:
|
||||
* Project messaging.
|
||||
* Official project social media.
|
||||
* Promotion of speakers for meetups and conferences.
|
||||
* Promotion of community events.
|
||||
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.
|
||||
content.
|
||||
|
||||
### [HTTP](https://github.com/nodejs/http)
|
||||
|
||||
The HTTP working group is chartered for the support and improvement of the
|
||||
HTTP implementation in Node. Its responsibilities are:
|
||||
The HTTP Working Group is chartered for the support and improvement of the
|
||||
HTTP implementation in Node.js.
|
||||
|
||||
Responsibilities include:
|
||||
* Addressing HTTP issues on the Node.js issue tracker.
|
||||
* Authoring and editing HTTP documentation within the Node.js project.
|
||||
* Reviewing changes to HTTP functionality within the Node.js project.
|
||||
@ -197,39 +198,36 @@ HTTP implementation in Node. Its responsibilities are:
|
||||
|
||||
### [Roadmap](https://github.com/nodejs/roadmap)
|
||||
|
||||
The roadmap working group is responsible for user community outreach
|
||||
The Roadmap Working Group is responsible for user community outreach
|
||||
and the translation of their concerns into a plan of action for Node.js.
|
||||
|
||||
The final [ROADMAP](./ROADMAP.md) document is still owned by the TC and requires
|
||||
the same approval for changes as any other project asset.
|
||||
|
||||
Their responsibilities are:
|
||||
* Attract and summarize user community needs and feedback.
|
||||
* Find or potentially create tools that allow for broader participation.
|
||||
* Create Pull Requests for relevant changes to [Roadmap.md](./ROADMAP.md)
|
||||
|
||||
* Attracting and summarizing user community needs and feedback.
|
||||
* Finding or potentially creating tools that allow for broader participation.
|
||||
* Creating Pull Requests for relevant changes to [ROADMAP.md](./ROADMAP.md)
|
||||
|
||||
### [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.
|
||||
The Docker Working Group's purpose is to build, maintain, and improve official
|
||||
Docker images for the Node.js project.
|
||||
|
||||
Their responsibilities are:
|
||||
* Keep the official Docker images updated in line with new `Node.js` releases.
|
||||
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 both Node.js and Node.js,
|
||||
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, Node.js, V8 and libuv.
|
||||
|
||||
Their responsibilities are:
|
||||
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)
|
||||
@ -247,48 +245,46 @@ The current members can be found in their
|
||||
|
||||
### [Benchmarking](https://github.com/nodejs/benchmarking)
|
||||
|
||||
The purpose of the Benchmark working group is to gain consensus
|
||||
for an agreed set of benchmarks that can be used to:
|
||||
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 releases
|
||||
+ avoid performance regressions between releases
|
||||
* track and evangelize performance gains made between Node.js releases
|
||||
* avoid performance regressions between releases
|
||||
|
||||
Its responsibilities are:
|
||||
|
||||
+ Identify 1 or more benchmarks that reflect customer usage.
|
||||
Likely need more than one to cover typical Node use cases
|
||||
including low-latency and high concurrency
|
||||
+ Work to get community consensus on the list chosen
|
||||
+ Add regular execution of chosen benchmarks to Node builds
|
||||
+ Track/publicize performance between builds/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
|
||||
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.
|
||||
|
||||
Its responsibilities are:
|
||||
|
||||
+ 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
|
||||
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
|
||||
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 Evangelism, Website, and
|
||||
Intl working groups to make excellent documentation available and accessible
|
||||
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.
|
||||
|
||||
Its responsibilities are:
|
||||
|
||||
Responsibilities include:
|
||||
* Defining and maintaining documentation style and content standards.
|
||||
* Producing documentation in a format acceptable for the Website WG to consume.
|
||||
* 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.
|
||||
@ -298,8 +294,7 @@ Its responsibilities are:
|
||||
The Node.js Testing Working Group's purpose is to extend and improve testing of
|
||||
the Node.js source code.
|
||||
|
||||
Its responsibilities are:
|
||||
|
||||
Responsibilities include:
|
||||
* Coordinating an overall strategy for improving testing.
|
||||
* Documenting guidelines around tests.
|
||||
* Working with the Build Working Group to improve continuous integration.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user