@@ -7,44 +7,43 @@ There are 2 types of Working Groups:
7
7
* [ Top-Level Working Groups] ( #top-level-working-groups )
8
8
* [ Core Working Groups] ( #core-working-groups )
9
9
10
- ## Top-Level Working Groups
10
+ # Top-Level Working Groups
11
11
<!-- Information here should mostly mirror: https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md -->
12
12
13
- Top-Level Working Groups are created by the
13
+ Top-Level Working Groups are created by the
14
14
[ Technical Steering Committee (TSC)] ( https://github.com/nodejs/TSC#top-level-wgs-and-tlps ) .
15
15
16
- ### Current Top-Level Working Groups
16
+ ## Current Top-Level Working Groups
17
17
* [ Inclusivity] ( #inclusivity )
18
18
19
- #### [ Inclusivity] ( https://github.com/nodejs/inclusivity )
20
- The Inclusivity Working Group seeks to increase inclusivity and diversity for
19
+ ### [ Inclusivity] ( https://github.com/nodejs/inclusivity )
20
+ The Inclusivity Working Group seeks to increase inclusivity and diversity for
21
21
the Node.js project:
22
22
23
- * Increasing inclusivity means making the Node.js project a safe and friendly
23
+ * Increasing inclusivity means making the Node.js project a safe and friendly
24
24
place for people from diverse backgrounds.
25
- * Increasing diversity means actively onboarding people from diverse backgrounds
25
+ * Increasing diversity means actively onboarding people from diverse backgrounds
26
26
to the Node.js project and maintaining their participation.
27
27
28
- Its responsibilites are :
29
- * Foster a welcoming environment that ensures participants are valued and can
28
+ Responsibilities include :
29
+ * Fostering a welcoming environment that ensures participants are valued and can
30
30
feel confident contributing or joining discussions, regardless of any [ aspect of
31
31
their identity] ( https://github.com/nodejs/inclusivity/#list-of-responsibilities ) .
32
- * Proactively seek and propose concrete steps the project can take to increase
32
+ * Proactively seeking and proposing concrete steps the project can take to increase
33
33
inclusivity.
34
- * Serve as a resource for the development and enforcement of workflows that
34
+ * Serving as a resource for the development and enforcement of workflows that
35
35
protect community members and projects from harassment and abuse.
36
- * Acknowledge and celebrate existing diversity accomplishments within the project
36
+ * Acknowledging and celebrating existing diversity accomplishments within the project
37
37
while seeking to build upon them.
38
- * Identify ways to measure diversity and inclusivity within the project and report
38
+ * Identifying ways to measure diversity and inclusivity within the project and report
39
39
them at regular intervals.
40
40
41
41
# Core Working Groups
42
42
<!-- Information here should mostly mirror: https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md -->
43
43
44
- Core Working Groups are created by the
44
+ Core Working Groups are created by the
45
45
[ Core Technical Committee (CTC)] ( https://github.com/nodejs/node/blob/master/GOVERNANCE.md#core-technical-committee ) .
46
46
47
-
48
47
## Current Working Groups
49
48
50
49
* [ Website] ( #website )
@@ -63,90 +62,81 @@ Core Working Groups are created by the
63
62
* [ Documentation] ( #documentation )
64
63
* [ Testing] ( #testing )
65
64
66
-
67
65
### [ Website] ( https://github.com/nodejs/nodejs.org )
68
66
69
- The website working group 's purpose is to build and maintain a public
70
- website for the ` Node.js ` project.
67
+ The Website Working Group 's purpose is to build and maintain a public
68
+ website for the Node.js project.
71
69
72
- Its responsibilities are :
73
- * Develop and maintain a build and automation system for ` nodejs.org ` .
74
- * Ensure the site is regularly updated with changes made to ` Node.js ` like
75
- releases and features.
76
- * Foster and enable a community of translators.
70
+ Responsibilities include :
71
+ * Developing and maintaining a build and automation system for nodejs.org.
72
+ * Ensuring the site is regularly updated with changes made to Node.js, like
73
+ releases and features.
74
+ * Fostering and enabling a community of translators.
77
75
78
76
### [ Streams] ( https://github.com/nodejs/readable-stream )
79
77
80
- The Streams WG is dedicated to the support and improvement of the Streams API
81
- as used in Node.js and the npm ecosystem. We seek to create a composable API that
82
- solves the problem of representing multiple occurrences of an event over time
83
- in a humane, low-overhead fashion. Improvements to the API will be driven by
84
- the needs of the ecosystem; interoperability and backwards compatibility with
85
- other solutions and prior versions are paramount in importance. Our
86
- responsibilities include:
78
+ The Streams Working Group is dedicated to the support and improvement of the
79
+ Streams API as used in Node.js and the npm ecosystem. We seek to create a
80
+ composable API that solves the problem of representing multiple occurrences
81
+ of an event over time in a humane, low-overhead fashion. Improvements to the
82
+ API will be driven by the needs of the ecosystem; interoperability and
83
+ backwards compatibility with other solutions and prior versions are paramount
84
+ in importance.
87
85
86
+ Responsibilities include:
88
87
* Addressing stream issues on the Node.js issue tracker.
89
88
* Authoring and editing stream documentation within the Node.js project.
90
89
* Reviewing changes to stream subclasses within the Node.js project.
91
90
* Redirecting changes to streams from the Node.js project to this project.
92
91
* Assisting in the implementation of stream providers within Node.js.
93
- * Recommending versions of readable-stream to be included in Node.js.
92
+ * Recommending versions of ` readable-stream ` to be included in Node.js.
94
93
* Messaging about the future of streams to give the community advance notice of changes.
95
94
96
-
97
95
### [ Build] ( https://github.com/nodejs/build )
98
96
99
- The build working group's purpose is to create and maintain a
100
- distributed automation infrastructure.
101
-
102
- Its responsibilities are:
103
- * Produce Packages for all target platforms.
104
- * Run tests.
105
- * Run performance testing and comparisons.
106
- * Creates and manages build-containers.
97
+ The Build Working Group's purpose is to create and maintain a distributed
98
+ automation infrastructure.
107
99
100
+ Responsibilities include:
101
+ * Producing packages for all target platforms.
102
+ * Running tests.
103
+ * Running performance testing and comparisons.
104
+ * Creating and managing build-containers.
108
105
109
106
### [ Diagnostics] ( https://github.com/nodejs/diagnostics )
110
107
111
- The diagnostics working group 's purpose is to ensure Node provides a set of
112
- comprehensive, documented, extensible diagnostic protocols, formats, and
113
- APIs to enable tool vendors to provide reliable diagnostic tools for Node .
108
+ The Diagnostics Working Group 's purpose is to surface a set of comprehensive,
109
+ documented, and extensible diagnostic interfaces for use by Node.js tools and
110
+ JavaScript VMs .
114
111
115
- Its responsibilities are:
116
- * Collect, understand, and document existing diagnostic capabilities and
117
- entry-points throughout Node, V8, and other components.
118
- * Collect and document projects and products providing diagnostics for
119
- Node with brief description of their technical architecture and sponsoring
120
- organizations.
121
- * Identify opportunities and gaps, then propose and implement solutions.
122
-
123
- Work is divided into several domains:
124
-
125
- * [ Tracing] ( https://github.com/nodejs/diagnostics/blob/master/tracing )
126
- * [ Profiling] ( https://github.com/nodejs/diagnostics/blob/master/profiling )
127
- * [ Heap and Memory Analysis] ( https://github.com/nodejs/diagnostics/blob/master/heap-memory )
128
- * [ Step Debugging] ( https://github.com/nodejs/diagnostics/blob/master/debugging )
112
+ Responsibilities include:
113
+ * Collaborating with V8 to integrate ` v8_inspector ` into Node.js.
114
+ * Collaborating with V8 to integrate ` trace_event ` into Node.js.
115
+ * Collaborating with Core to refine ` async_wrap ` and ` async_hooks ` .
116
+ * Maintaining and improving OS trace system integration (e.g. ETW, LTTNG, dtrace).
117
+ * Documenting diagnostic capabilities and APIs in Node.js and its components.
118
+ * Exploring opportunities and gaps, discussing feature requests, and addressing
119
+ conflicts in Node.js diagnostics.
120
+ * Fostering an ecosystem of diagnostics tools for Node.js.
129
121
130
122
### i18n
131
123
132
- The i18n working groups handle more than just translations. They
124
+ The i18n Working Groups handle more than just translations. They
133
125
are endpoints for community members to collaborate with each
134
126
other in their language of choice.
135
127
136
128
Each team is organized around a common spoken language. Each
137
129
language community might then produce multiple localizations for
138
130
various project resources.
139
131
140
- Their responsibilities are:
141
- * Translations of any Node.js materials they believe are relevant to their
142
- community.
143
- * Review processes for keeping translations up
144
- to date and of high quality.
145
- * Social media channels in their language.
146
- * Promotion of Node.js speakers for meetups and conferences in their
147
- language.
132
+ Responsibilities include:
133
+ * Translating any Node.js materials they believe are relevant to their
134
+ community.
135
+ * Reviewing processes for keeping translations up to date and of high quality.
136
+ * Managing and monitoring social media channels in their language.
137
+ * Promoting Node.js speakers for meetups and conferences in their language.
148
138
149
- Note that the i18n working groups are distinct from the [ Intl] ( #Intl ) working group .
139
+ Note that the i18n Working Groups are distinct from the [ Intl] ( #Intl ) Working Group .
150
140
151
141
Each language community maintains its own membership.
152
142
@@ -188,33 +178,37 @@ Each language community maintains its own membership.
188
178
### [ Intl] ( https://github.com/nodejs/Intl )
189
179
190
180
The Intl Working Group is dedicated to support and improvement of
191
- Internationalization (i18n) and Localization (l10n) in Node. Its responsibilities are:
181
+ Internationalization (i18n) and Localization (l10n) in Node.
192
182
193
- 1 . Functionality & compliance (standards: ECMA, Unicode…)
194
- 2 . Support for Globalization and Internationalization issues that come up in the tracker
195
- 3 . Guidance and Best Practices
196
- 4 . Refinement of existing ` Intl ` implementation
183
+ Responsibilities include:
184
+ * Ensuring functionality & compliance (standards: ECMA, Unicode…)
185
+ * Supporting Globalization and Internationalization issues that come up
186
+ in the tracker
187
+ * Communicating guidance and best practices
188
+ * Refining the existing ` Intl ` implementation
197
189
198
- The Intl WG is not responsible for translation of content. That is the responsibility of the specific [ i18n] ( #i18n ) group for each language.
190
+ The Intl Working Group is not responsible for translation of content. That is the
191
+ responsibility of the specific [ i18n] ( #i18n ) group for each language.
199
192
200
193
### [ Evangelism] ( https://github.com/nodejs/evangelism )
201
194
202
- The evangelism working group promotes the accomplishments
195
+ The Evangelism Working Group promotes the accomplishments
203
196
of Node.js and lets the community know how they can get involved.
204
197
205
- Their responsibilities are :
206
- * Project messaging.
207
- * Official project social media.
208
- * Promotion of speakers for meetups and conferences.
209
- * Promotion of community events.
198
+ Responsibilities include :
199
+ * Facilitating project messaging.
200
+ * Managing official project social media.
201
+ * Handling the promotion of speakers for meetups and conferences.
202
+ * Handling the promotion of community events.
210
203
* Publishing regular update summaries and other promotional
211
- content.
204
+ content.
212
205
213
206
### [ HTTP] ( https://github.com/nodejs/http )
214
207
215
- The HTTP working group is chartered for the support and improvement of the
216
- HTTP implementation in Node. It's responsibilities are:
208
+ The HTTP Working Group is chartered for the support and improvement of the
209
+ HTTP implementation in Node.js.
217
210
211
+ Responsibilities include:
218
212
* Addressing HTTP issues on the Node.js issue tracker.
219
213
* Authoring and editing HTTP documentation within the Node.js project.
220
214
* Reviewing changes to HTTP functionality within the Node.js project.
@@ -226,30 +220,28 @@ HTTP implementation in Node. It's responsibilities are:
226
220
227
221
### [ Roadmap] ( https://github.com/nodejs/roadmap )
228
222
229
- The roadmap working group is responsible for user community outreach
223
+ The Roadmap Working Group is responsible for user community outreach
230
224
and the translation of their concerns into a plan of action for Node.js.
231
225
232
- The final [ ROADMAP] ( https://github.com/nodejs/node/blob/master/ROADMAP.md ) document is still
226
+ The final [ ROADMAP] ( https://github.com/nodejs/node/blob/master/ROADMAP.md ) document is still
233
227
owned by the TC and requires the same approval for changes as any other project asset.
234
228
235
- Their responsibilities are :
236
- * Attract and summarize user community needs and feedback.
237
- * Find or potentially create tools that allow for broader participation.
238
- * Create Pull Requests for relevant changes to
229
+ Responsibilities include :
230
+ * Attracting and summarizing user community needs and feedback.
231
+ * Finding or potentially creating tools that allow for broader participation.
232
+ * Creating Pull Requests for relevant changes to
239
233
[ ROADMAP.md] ( https://github.com/nodejs/node/blob/master/ROADMAP.md )
240
234
241
-
242
235
### [ Docker] ( https://github.com/nodejs/docker-node )
243
236
244
- The Docker working group 's purpose is to build, maintain, and improve official
245
- Docker images for the ` Node.js ` project.
237
+ The Docker Working Group 's purpose is to build, maintain, and improve official
238
+ Docker images for the Node.js project.
246
239
247
- Their responsibilities are :
248
- * Keep the official Docker images updated in line with new ` Node.js ` releases.
240
+ Responsibilities include :
241
+ * Keeping the official Docker images updated in line with new Node.js releases.
249
242
* Decide and implement image improvements and/or fixes.
250
243
* Maintain and improve the images' documentation.
251
244
252
-
253
245
### [ Addon API] ( https://github.com/nodejs/nan )
254
246
255
247
The Addon API Working Group is responsible for maintaining the NAN project and
@@ -258,8 +250,7 @@ abstraction layer for native add-on authors for Node.js,
258
250
assisting in the writing of code that is compatible with many actively used
259
251
versions of Node.js, V8 and libuv.
260
252
261
- Their responsibilities are:
262
-
253
+ Responsibilities include:
263
254
* Maintaining the [ NAN] ( https://github.com/nodejs/nan ) GitHub repository,
264
255
including code, issues and documentation.
265
256
* Maintaining the [ addon-examples] ( https://github.com/nodejs/node-addon-examples )
@@ -277,48 +268,46 @@ The current members can be found in their
277
268
278
269
### [ Benchmarking] ( https://github.com/nodejs/benchmarking )
279
270
280
- The purpose of the Benchmark working group is to gain consensus
281
- for an agreed set of benchmarks that can be used to:
282
-
283
- + track and evangelize performance gains made between Node releases
284
- + avoid performance regressions between releases
271
+ The purpose of the Benchmark Working Group is to gain consensus
272
+ on an agreed set of benchmarks that can be used to:
285
273
286
- Its responsibilities are:
274
+ * track and evangelize performance gains made between Node.js releases
275
+ * avoid performance regressions between releases
287
276
288
- + Identify 1 or more benchmarks that reflect customer usage.
289
- Likely need more than one to cover typical Node use cases
290
- including low-latency and high concurrency
291
- + Work to get community consensus on the list chosen
292
- + Add regular execution of chosen benchmarks to Node builds
293
- + Track/publicize performance between builds/releases
277
+ Responsibilities include:
278
+ * Identifying 1 or more benchmarks that reflect customer usage.
279
+ Likely will need more than one to cover typical Node.js use cases
280
+ including low-latency and high concurrency
281
+ * Working to get community consensus on the list chosen
282
+ * Adding regular execution of chosen benchmarks to Node.js builds
283
+ * Tracking/publicizing performance between builds/releases
294
284
295
285
### [ Post-mortem] ( https://github.com/nodejs/post-mortem )
296
286
297
- The Post-mortem Diagnostics working group is dedicated to the support
287
+ The Post-mortem Diagnostics Working Group is dedicated to the support
298
288
and improvement of postmortem debugging for Node.js. It seeks to
299
289
elevate the role of postmortem debugging for Node, to assist in the
300
290
development of techniques and tools, and to make techniques and tools
301
291
known and available to Node.js users.
302
292
303
- Its responsibilities are:
304
-
305
- + Defining and adding interfaces/APIs in order to allow dumps
306
- to be generated when needed
307
- + Defining and adding common structures to the dumps generated
308
- in order to support tools that want to introspect those dumps
293
+ Responsibilities include:
294
+ * Defining and adding interfaces/APIs in order to allow dumps
295
+ to be generated when needed.
296
+ * Defining and adding common structures to the dumps generated
297
+ in order to support tools that want to introspect those dumps.
309
298
310
299
### [ Documentation] ( https://github.com/nodejs/docs )
311
300
312
- The Documentation working group exists to support the improvement of Node.js
301
+ The Documentation Working Group exists to support the improvement of Node.js
313
302
documentation, both in the core API documentation, and elsewhere, such as the
314
- Node.js website. Its intent is to work closely with Evangelism, Website, and
315
- Intl working groups to make excellent documentation available and accessible
303
+ Node.js website. Its intent is to work closely with the Evangelism, Website, and
304
+ Intl Working Groups to make excellent documentation available and accessible
316
305
to all.
317
306
318
- Its responsibilities are:
319
-
307
+ Responsibilities include:
320
308
* Defining and maintaining documentation style and content standards.
321
- * Producing documentation in a format acceptable for the Website WG to consume.
309
+ * Producing documentation in a format acceptable for the Website Working Group
310
+ to consume.
322
311
* Ensuring that Node's documentation addresses a wide variety of audiences.
323
312
* Creating and operating a process for documentation review that produces
324
313
quality documentation and avoids impeding the progress of Core work.
@@ -328,8 +317,7 @@ Its responsibilities are:
328
317
The Node.js Testing Working Group's purpose is to extend and improve testing of
329
318
the Node.js source code.
330
319
331
- It's responsibilities are:
332
-
320
+ Responsibilities include:
333
321
* Coordinating an overall strategy for improving testing.
334
322
* Documenting guidelines around tests.
335
323
* Working with the Build Working Group to improve continuous integration.
0 commit comments