@@ -41,83 +41,80 @@ back in to the CTC.
41
41
42
42
### [ Website] ( https://github.com/nodejs/nodejs.org )
43
43
44
- The website working group 's purpose is to build and maintain a public
45
- website for the ` Node.js ` project.
44
+ The website Working Group 's purpose is to build and maintain a public
45
+ website for the Node.js project.
46
46
47
- Its responsibilities are :
48
- * Develop and maintain a build and automation system for ` nodejs.org ` .
49
- * Ensure the site is regularly updated with changes made to ` Node.js ` like
50
- releases and features.
51
- * Foster and enable a community of translators.
47
+ Responsibilities include :
48
+ * Developing and maintaining a build and automation system for nodejs.org.
49
+ * Ensuring the site is regularly updated with changes made to Node.js, like
50
+ releases and features.
51
+ * Fostering and enabling a community of translators.
52
52
53
53
### [ Streams] ( https://github.com/nodejs/readable-stream )
54
54
55
- The Streams WG is dedicated to the support and improvement of the Streams API
56
- as used in Node.js and the npm ecosystem. We seek to create a composable API that
57
- solves the problem of representing multiple occurrences of an event over time
58
- in a humane, low-overhead fashion. Improvements to the API will be driven by
59
- the needs of the ecosystem; interoperability and backwards compatibility with
60
- other solutions and prior versions are paramount in importance. Our
61
- responsibilities include:
55
+ The Streams Working Group is dedicated to the support and improvement of the
56
+ Streams API as used in Node.js and the npm ecosystem. We seek to create a
57
+ composable API that solves the problem of representing multiple occurrences
58
+ of an event over time in a humane, low-overhead fashion. Improvements to the
59
+ API will be driven by the needs of the ecosystem; interoperability and
60
+ backwards compatibility with other solutions and prior versions are paramount
61
+ in importance.
62
62
63
+ Responsibilities include:
63
64
* Addressing stream issues on the Node.js issue tracker.
64
65
* Authoring and editing stream documentation within the Node.js project.
65
66
* Reviewing changes to stream subclasses within the Node.js project.
66
67
* Redirecting changes to streams from the Node.js project to this project.
67
68
* Assisting in the implementation of stream providers within Node.js.
68
- * Recommending versions of readable-stream to be included in Node.js.
69
- * Messaging about the future of streams to give the community advance notice of changes.
70
-
69
+ * Recommending versions of ` readable-stream ` to be included in Node.js.
70
+ * Messaging about the future of streams to give the community advance notice of
71
+ changes.
71
72
72
73
### [ Build] ( https://github.com/nodejs/build )
73
74
74
- The build working group's purpose is to create and maintain a
75
- distributed automation infrastructure.
76
-
77
- Its responsibilities are:
78
- * Produce Packages for all target platforms.
79
- * Run tests.
80
- * Run performance testing and comparisons.
81
- * Creates and manages build-containers.
75
+ The Build Working Group's purpose is to create and maintain a distributed
76
+ automation infrastructure.
82
77
78
+ Responsibilities include:
79
+ * Producing packages for all target platforms.
80
+ * Running tests.
81
+ * Running performance testing and comparisons.
82
+ * Creating and managing build-containers.
83
83
84
84
### [ Diagnostics] ( https://github.com/nodejs/diagnostics )
85
85
86
- The diagnostics working group's purpose is to surface a set of comprehensive,
87
- documented, and extensible diagnostic interfaces for use by
88
- Node.js tools and JavaScript VMs.
89
-
90
- Its responsibilities are:
91
-
92
- * Collaborate with V8 to integrate ` v8_inspector ` into Node.js.
93
- * Collaborate with V8 to integrate ` trace_event ` into Node.js.
94
- * Collaborate with Core to refine ` async_wrap ` and ` async_hooks ` .
95
- * Maintain and improve OS trace system integration (e.g. ETW, LTTNG, dtrace).
96
- * Document diagnostic capabilities and APIs in Node.js and its components.
97
- * Explore opportunities and gaps, discuss feature requests, and address
86
+ The Diagnostics Working Group's purpose is to surface a set of comprehensive,
87
+ documented, and extensible diagnostic interfaces for use by Node.js tools and
88
+ JavaScript VMs.
89
+
90
+ Responsibilities include:
91
+ * Collaborating with V8 to integrate ` v8_inspector ` into Node.js.
92
+ * Collaborating with V8 to integrate ` trace_event ` into Node.js.
93
+ * Collaborating with Core to refine ` async_wrap ` and ` async_hooks ` .
94
+ * Maintaining and improving OS trace system integration (e.g. ETW, LTTNG, dtrace).
95
+ * Documenting diagnostic capabilities and APIs in Node.js and its components.
96
+ * Exploring opportunities and gaps, discussing feature requests, and addressing
98
97
conflicts in Node.js diagnostics.
99
- * Foster an ecosystem of diagnostics tools for Node.js.
98
+ * Fostering an ecosystem of diagnostics tools for Node.js.
100
99
101
100
### i18n
102
101
103
- The i18n working groups handle more than just translations. They
102
+ The i18n Working Groups handle more than just translations. They
104
103
are endpoints for community members to collaborate with each
105
104
other in their language of choice.
106
105
107
106
Each team is organized around a common spoken language. Each
108
107
language community might then produce multiple localizations for
109
108
various project resources.
110
109
111
- Their responsibilities are:
112
- * Translations of any Node.js materials they believe are relevant to their
113
- community.
114
- * Review processes for keeping translations up
115
- to date and of high quality.
116
- * Social media channels in their language.
117
- * Promotion of Node.js speakers for meetups and conferences in their
118
- language.
110
+ Responsibilities include:
111
+ * Translating any Node.js materials they believe are relevant to their
112
+ community.
113
+ * Reviewing processes for keeping translations up to date and of high quality.
114
+ * Managing and monitoring social media channels in their language.
115
+ * Promoting Node.js speakers for meetups and conferences in their language.
119
116
120
- Note that the i18n working groups are distinct from the [ Intl] ( #Intl ) working group .
117
+ Note that the i18n Working Groups are distinct from the [ Intl] ( #Intl ) Working Group .
121
118
122
119
Each language community maintains its own membership.
123
120
@@ -159,33 +156,37 @@ Each language community maintains its own membership.
159
156
### [ Intl] ( https://github.com/nodejs/Intl )
160
157
161
158
The Intl Working Group is dedicated to support and improvement of
162
- Internationalization (i18n) and Localization (l10n) in Node. Its responsibilities are:
159
+ Internationalization (i18n) and Localization (l10n) in Node.
163
160
164
- 1 . Functionality & compliance (standards: ECMA, Unicode…)
165
- 2 . Support for Globalization and Internationalization issues that come up in the tracker
166
- 3 . Guidance and Best Practices
167
- 4 . Refinement of existing ` Intl ` implementation
161
+ Responsibilities include:
162
+ * Ensuring functionality & compliance (standards: ECMA, Unicode…)
163
+ * Supporting Globalization and Internationalization issues that come up
164
+ in the tracker
165
+ * Communicating guidance and best practices
166
+ * Refining the existing ` Intl ` implementation
168
167
169
- The Intl WG is not responsible for translation of content. That is the responsibility of the specific [ i18n] ( #i18n ) group for each language.
168
+ The Intl Working Group is not responsible for translation of content. That is the
169
+ responsibility of the specific [ i18n] ( #i18n ) group for each language.
170
170
171
171
### [ Evangelism] ( https://github.com/nodejs/evangelism )
172
172
173
- The evangelism working group promotes the accomplishments
173
+ The Evangelism Working Group promotes the accomplishments
174
174
of Node.js and lets the community know how they can get involved.
175
175
176
- Their responsibilities are :
177
- * Project messaging.
178
- * Official project social media.
179
- * Promotion of speakers for meetups and conferences.
180
- * Promotion of community events.
176
+ Responsibilities include :
177
+ * Facilitating project messaging.
178
+ * Managing official project social media.
179
+ * Handling the promotion of speakers for meetups and conferences.
180
+ * Handling the promotion of community events.
181
181
* Publishing regular update summaries and other promotional
182
- content.
182
+ content.
183
183
184
184
### [ HTTP] ( https://github.com/nodejs/http )
185
185
186
- The HTTP working group is chartered for the support and improvement of the
187
- HTTP implementation in Node. Its responsibilities are:
186
+ The HTTP Working Group is chartered for the support and improvement of the
187
+ HTTP implementation in Node.js.
188
188
189
+ Responsibilities include:
189
190
* Addressing HTTP issues on the Node.js issue tracker.
190
191
* Authoring and editing HTTP documentation within the Node.js project.
191
192
* Reviewing changes to HTTP functionality within the Node.js project.
@@ -197,39 +198,36 @@ HTTP implementation in Node. Its responsibilities are:
197
198
198
199
### [ Roadmap] ( https://github.com/nodejs/roadmap )
199
200
200
- The roadmap working group is responsible for user community outreach
201
+ The Roadmap Working Group is responsible for user community outreach
201
202
and the translation of their concerns into a plan of action for Node.js.
202
203
203
204
The final [ ROADMAP] ( ./ROADMAP.md ) document is still owned by the TC and requires
204
205
the same approval for changes as any other project asset.
205
206
206
207
Their responsibilities are:
207
- * Attract and summarize user community needs and feedback.
208
- * Find or potentially create tools that allow for broader participation.
209
- * Create Pull Requests for relevant changes to [ Roadmap.md] ( ./ROADMAP.md )
210
-
208
+ * Attracting and summarizing user community needs and feedback.
209
+ * Finding or potentially creating tools that allow for broader participation.
210
+ * Creating Pull Requests for relevant changes to [ ROADMAP.md] ( ./ROADMAP.md )
211
211
212
212
### [ Docker] ( https://github.com/nodejs/docker-iojs )
213
213
214
- The Docker working group 's purpose is to build, maintain, and improve official
215
- Docker images for the ` Node.js ` project.
214
+ The Docker Working Group 's purpose is to build, maintain, and improve official
215
+ Docker images for the Node.js project.
216
216
217
- Their responsibilities are :
218
- * Keep the official Docker images updated in line with new ` Node.js ` releases.
217
+ Responsibilities include :
218
+ * Keeping the official Docker images updated in line with new Node.js releases.
219
219
* Decide and implement image improvements and/or fixes.
220
220
* Maintain and improve the images' documentation.
221
221
222
-
223
222
### [ Addon API] ( https://github.com/nodejs/nan )
224
223
225
224
The Addon API Working Group is responsible for maintaining the NAN project and
226
225
corresponding _ nan_ package in npm. The NAN project makes available an
227
- abstraction layer for native add-on authors for both Node.js and Node.js,
226
+ abstraction layer for native add-on authors for Node.js,
228
227
assisting in the writing of code that is compatible with many actively used
229
- versions of Node.js, Node.js, V8 and libuv.
230
-
231
- Their responsibilities are:
228
+ versions of Node.js, V8 and libuv.
232
229
230
+ Responsibilities include:
233
231
* Maintaining the [ NAN] ( https://github.com/nodejs/nan ) GitHub repository,
234
232
including code, issues and documentation.
235
233
* Maintaining the [ addon-examples] ( https://github.com/nodejs/node-addon-examples )
@@ -247,48 +245,46 @@ The current members can be found in their
247
245
248
246
### [ Benchmarking] ( https://github.com/nodejs/benchmarking )
249
247
250
- The purpose of the Benchmark working group is to gain consensus
251
- for an agreed set of benchmarks that can be used to:
248
+ The purpose of the Benchmark Working Group is to gain consensus
249
+ on an agreed set of benchmarks that can be used to:
252
250
253
- + track and evangelize performance gains made between Node releases
254
- + avoid performance regressions between releases
251
+ * track and evangelize performance gains made between Node.js releases
252
+ * avoid performance regressions between releases
255
253
256
- Its responsibilities are:
257
-
258
- + Identify 1 or more benchmarks that reflect customer usage.
259
- Likely need more than one to cover typical Node use cases
260
- including low-latency and high concurrency
261
- + Work to get community consensus on the list chosen
262
- + Add regular execution of chosen benchmarks to Node builds
263
- + Track/publicize performance between builds/releases
254
+ Responsibilities include:
255
+ * Identifying 1 or more benchmarks that reflect customer usage.
256
+ Likely will need more than one to cover typical Node.js use cases
257
+ including low-latency and high concurrency
258
+ * Working to get community consensus on the list chosen
259
+ * Adding regular execution of chosen benchmarks to Node.js builds
260
+ * Tracking/publicizing performance between builds/releases
264
261
265
262
### [ Post-mortem] ( https://github.com/nodejs/post-mortem )
266
263
267
- The Post-mortem Diagnostics working group is dedicated to the support
264
+ The Post-mortem Diagnostics Working Group is dedicated to the support
268
265
and improvement of postmortem debugging for Node.js. It seeks to
269
266
elevate the role of postmortem debugging for Node, to assist in the
270
267
development of techniques and tools, and to make techniques and tools
271
268
known and available to Node.js users.
272
269
273
- Its responsibilities are:
274
-
275
- + Defining and adding interfaces/APIs in order to allow dumps
276
- to be generated when needed
277
- + Defining and adding common structures to the dumps generated
278
- in order to support tools that want to introspect those dumps
270
+ Responsibilities include:
271
+ * Defining and adding interfaces/APIs in order to allow dumps
272
+ to be generated when needed.
273
+ * Defining and adding common structures to the dumps generated
274
+ in order to support tools that want to introspect those dumps.
279
275
280
276
### [ Documentation] ( https://github.com/nodejs/docs )
281
277
282
- The Documentation working group exists to support the improvement of Node.js
278
+ The Documentation Working Group exists to support the improvement of Node.js
283
279
documentation, both in the core API documentation, and elsewhere, such as the
284
- Node.js website. Its intent is to work closely with Evangelism, Website, and
285
- Intl working groups to make excellent documentation available and accessible
280
+ Node.js website. Its intent is to work closely with the Evangelism, Website, and
281
+ Intl Working Groups to make excellent documentation available and accessible
286
282
to all.
287
283
288
- Its responsibilities are:
289
-
284
+ Responsibilities include:
290
285
* Defining and maintaining documentation style and content standards.
291
- * Producing documentation in a format acceptable for the Website WG to consume.
286
+ * Producing documentation in a format acceptable for the Website Working Group
287
+ to consume.
292
288
* Ensuring that Node's documentation addresses a wide variety of audiences.
293
289
* Creating and operating a process for documentation review that produces
294
290
quality documentation and avoids impeding the progress of Core work.
@@ -298,8 +294,7 @@ Its responsibilities are:
298
294
The Node.js Testing Working Group's purpose is to extend and improve testing of
299
295
the Node.js source code.
300
296
301
- Its responsibilities are:
302
-
297
+ Responsibilities include:
303
298
* Coordinating an overall strategy for improving testing.
304
299
* Documenting guidelines around tests.
305
300
* Working with the Build Working Group to improve continuous integration.
0 commit comments