1 # Node.js Working Groups
3 Node.js Working Groups are autonomous projects created by the
4 [Technical Steering Committee (TSC)](https://github.com/nodejs/node/blob/master/GOVERNANCE.md#technical-committee).
6 Working Groups can be formed at any time but must be ratified by the TSC.
7 Once formed the work defined in the Working Group charter is the
8 responsibility of the WG rather than the TSC.
10 It is important that Working Groups are not formed pre-maturely. Working
11 Groups are not formed to *begin* a set of tasks but instead are formed
12 once that work is already underway and the contributors
13 think it would benefit from being done as an autonomous project.
15 If the work defined in a Working Group charter is completed the Working
16 Group should be dissolved and the responsibility for governance absorbed
19 ## Current Working Groups
26 * [Evangelism](#evangelism)
29 * [Addon API](#addon-api)
30 * [Starting a Working Group](#starting-a-wg)
31 * [Bootstrap Governance](#bootstrap-governance)
33 ### [Website](https://github.com/nodejs/website)
35 The website working group's purpose is to build and maintain a public
36 website for the `Node.js` project.
38 Its responsibilities are:
39 * Develop and maintain a build and automation system for `nodejs.org`.
40 * Ensure the site is regularly updated with changes made to `Node.js` like
41 releases and features.
42 * Foster and enable a community of translators.
44 ### [Streams](https://github.com/nodejs/readable-stream)
46 The Streams WG is dedicated to the support and improvement of the Streams API
47 as used in Node.js and the npm ecosystem. We seek to create a composable API that
48 solves the problem of representing multiple occurrences of an event over time
49 in a humane, low-overhead fashion. Improvements to the API will be driven by
50 the needs of the ecosystem; interoperability and backwards compatibility with
51 other solutions and prior versions are paramount in importance. Our
52 responsibilities include:
54 * Addressing stream issues on the Node.js issue tracker.
55 * Authoring and editing stream documentation within the Node.js project.
56 * Reviewing changes to stream subclasses within the Node.js project.
57 * Redirecting changes to streams from the Node.js project to this project.
58 * Assisting in the implementation of stream providers within Node.js.
59 * Recommending versions of readable-stream to be included in Node.js.
60 * Messaging about the future of streams to give the community advance notice of changes.
63 ### [Build](https://github.com/nodejs/build)
65 The build working group's purpose is to create and maintain a
66 distributed automation infrastructure.
68 Its responsibilities are:
69 * Produce Packages for all target platforms.
71 * Run performance testing and comparisons.
72 * Creates and manages build-containers.
75 ### [Tracing](https://github.com/nodejs/tracing-wg)
77 The tracing working group's purpose is to increase the
78 transparency of software written in Node.js.
80 Its responsibilities are:
81 * Collaboration with V8 to integrate with `trace_event`.
82 * Maintenance and iteration on AsyncWrap.
83 * Maintenance and improvements to system tracing support (DTrace, LTTng, etc.)
84 * Documentation of tracing and debugging techniques.
85 * Fostering a tracing and debugging ecosystem.
89 The i18n working groups handle more than just translations. They
90 are endpoints for community members to collaborate with each
91 other in their language of choice.
93 Each team is organized around a common spoken language. Each
94 language community might then produce multiple localizations for
95 various project resources.
97 Their responsibilities are:
98 * Translations of any Node.js materials they believe are relevant to their
100 * Review processes for keeping translations up
101 to date and of high quality.
102 * Social media channels in their language.
103 * Promotion of Node.js speakers for meetups and conferences in their
106 Each language community maintains its own membership.
108 * [iojs-ar - Arabic (اللغة العربية)](https://github.com/nodejs/iojs-ar)
109 * [iojs-bg - Bulgarian (български език)](https://github.com/nodejs/iojs-bg)
110 * [iojs-bn - Bengali (বাংলা)](https://github.com/nodejs/iojs-bn)
111 * [iojs-cn - Chinese (中文)](https://github.com/nodejs/iojs-cn)
112 * [iojs-cs - Czech (Český Jazyk)](https://github.com/nodejs/iojs-cs)
113 * [iojs-da - Danish (Dansk)](https://github.com/nodejs/iojs-da)
114 * [iojs-de - German (Deutsch)](https://github.com/nodejs/iojs-de)
115 * [iojs-el - Greek (Ελληνικά)](https://github.com/nodejs/iojs-el)
116 * [iojs-es - Spanish (Español)](https://github.com/nodejs/iojs-es)
117 * [iojs-fa - Persian (فارسی)](https://github.com/nodejs/iojs-fa)
118 * [iojs-fi - Finnish (Suomi)](https://github.com/nodejs/iojs-fi)
119 * [iojs-fr - French (Français)](https://github.com/nodejs/iojs-fr)
120 * [iojs-he - Hebrew (עברית)](https://github.com/nodejs/iojs-he)
121 * [iojs-hi - Hindi (फिजी बात)](https://github.com/nodejs/iojs-hi)
122 * [iojs-hu - Hungarian (Magyar)](https://github.com/nodejs/iojs-hu)
123 * [iojs-id - Indonesian (Bahasa Indonesia)](https://github.com/nodejs/iojs-id)
124 * [iojs-it - Italian (Italiano)](https://github.com/nodejs/iojs-it)
125 * [iojs-ja - Japanese (日本語)](https://github.com/nodejs/iojs-ja)
126 * [iojs-ka - Georgian (ქართული)](https://github.com/nodejs/iojs-ka)
127 * [iojs-ko - Korean (조선말)](https://github.com/nodejs/iojs-ko)
128 * [iojs-mk - Macedonian (Mакедонски)](https://github.com/nodejs/iojs-mk)
129 * [iojs-ms - Malay (بهاس ملايو)](https://github.com/nodejs/iojs-ms)
130 * [iojs-nl - Dutch (Nederlands)](https://github.com/nodejs/iojs-nl)
131 * [iojs-no - Norwegian (Norsk)](https://github.com/nodejs/iojs-no)
132 * [iojs-pl - Polish (Język Polski)](https://github.com/nodejs/iojs-pl)
133 * [iojs-pt - Portuguese (Português)](https://github.com/nodejs/iojs-pt)
134 * [iojs-ro - Romanian (Română)](https://github.com/nodejs/iojs-ro)
135 * [iojs-ru - Russian (Русский)](https://github.com/nodejs/iojs-ru)
136 * [iojs-sv - Swedish (Svenska)](https://github.com/nodejs/iojs-sv)
137 * [iojs-ta - Tamil (தமிழ்)](https://github.com/nodejs/iojs-ta)
138 * [iojs-tr - Turkish (Türkçe)](https://github.com/nodejs/iojs-tr)
139 * [iojs-tw - Taiwanese (Hō-ló)](https://github.com/nodejs/iojs-tw)
140 * [iojs-uk - Ukrainian (Українська)](https://github.com/nodejs/iojs-uk)
141 * [iojs-vi - Vietnamese (Tiếng Việtnam)](https://github.com/nodejs/iojs-vi)
144 ### [Evangelism](https://github.com/nodejs/evangelism)
146 The evangelism working group promotes the accomplishments
147 of Node.js and lets the community know how they can get involved.
149 Their responsibilities are:
151 * Official project social media.
152 * Promotion of speakers for meetups and conferences.
153 * Promotion of community events.
154 * Publishing regular update summaries and other promotional
158 ### [Roadmap](https://github.com/nodejs/roadmap)
160 The roadmap working group is responsible for user community outreach
161 and the translation of their concerns into a plan of action for Node.js.
163 The final [ROADMAP](./ROADMAP.md) document is still owned by the TC and requires
164 the same approval for changes as any other project asset.
166 Their responsibilities are:
167 * Attract and summarize user community needs and feedback.
168 * Find or potentially create tools that allow for broader participation.
169 * Create Pull Requests for relevant changes to [Roadmap.md](./ROADMAP.md)
172 ### [Docker](https://github.com/nodejs/docker-iojs)
174 The Docker working group's purpose is to build, maintain, and improve official
175 Docker images for the `Node.js` project.
177 Their responsibilities are:
178 * Keep the official Docker images updated in line with new `Node.js` releases.
179 * Decide and implement image improvements and/or fixes.
180 * Maintain and improve the images' documentation.
183 ### [Addon API](https://github.com/nodejs/nan)
185 The Addon API Working Group is responsible for maintaining the NAN project and
186 corresponding _nan_ package in npm. The NAN project makes available an
187 abstraction layer for native add-on authors for both Node.js and Node.js,
188 assisting in the writing of code that is compatible with many actively used
189 versions of Node.js, Node.js, V8 and libuv.
191 Their responsibilities are:
193 * Maintaining the [NAN](https://github.com/nodejs/nan) GitHub repository,
194 including code, issues and documentation.
195 * Maintaining the [addon-examples](https://github.com/nodejs/node-addon-examples)
196 GitHub repository, including code, issues and documentation.
197 * Maintaining the C++ Addon API within the Node.js project, in subordination to
199 * Maintaining the Addon documentation within the Node.js project, in
200 subordination to the Node.js TSC.
201 * Maintaining the _nan_ package in npm, releasing new versions as appropriate.
202 * Messaging about the future of the Node.js and NAN interface to give the
203 community advance notice of changes.
205 The current members can be found in their
206 [README](https://github.com/nodejs/nan#collaborators).
210 A Working Group is established by first defining a charter that can be
211 ratified by the TC. A charter is a *statement of purpose*, a
212 *list of responsibilities* and a *list of initial membership*.
214 A working group needs 3 initial members. These should be individuals
215 already undertaking the work described in the charter.
217 The list of responsibilities should be specific. Once established, these
218 responsibilities are no longer governed by the TC and therefore should
219 not be broad or subjective. The only recourse the TC has over the working
220 group is to revoke the entire charter and take on the work previously
221 done by the working group themselves.
223 If the responsibilities described in the charter are currently
224 undertaken by another WG then the charter will additionally have to be
227 You can submit the WG charter for ratification by sending
228 a Pull Request to this document, which adds it to the
229 list of current Working Groups. Once ratified the list of
230 members should be maintained in the Working Group's
233 ## Bootstrap Governance
235 Once the TC ratifies a charter the WG inherits the following
236 documentation for governance, contribution, conduct and an MIT
237 LICENSE. The WG is free to change these documents through their own
238 governance process, hence the term "bootstrap."
240 ### *[insert WG name]* Working Group
242 The Node.js *[insert WG name]* is jointly governed by a Working Group (WG)
243 that is responsible for high-level guidance of the project.
245 The WG has final authority over this project including:
247 * Technical direction
248 * Project governance and process (including this policy)
249 * Contribution policy
250 * GitHub repository hosting
252 * Maintaining the list of additional Collaborators
254 For the current list of WG members, see the project
255 [README.md](./README.md#current-project-team-members).
259 The *[insert WG name]* GitHub repository is
260 maintained by the WG and additional Collaborators who are added by the
261 WG on an ongoing basis.
263 Individuals making significant and valuable contributions are made
264 Collaborators and given commit-access to the project. These
265 individuals are identified by the WG and their addition as
266 Collaborators is discussed during the weekly WG meeting.
268 _Note:_ If you make a significant contribution and are not considered
269 for commit-access log an issue or contact a WG member directly and it
270 will be brought up in the next WG meeting.
272 Modifications of the contents of the *[insert WG repo]* repository are made on
273 a collaborative basis. Anybody with a GitHub account may propose a
274 modification via pull request and it will be considered by the project
275 Collaborators. All pull requests must be reviewed and accepted by a
276 Collaborator with sufficient expertise who is able to take full
277 responsibility for the change. In the case of pull requests proposed
278 by an existing Collaborator, an additional Collaborator is required
279 for sign-off. Consensus should be sought if additional Collaborators
280 participate and there is disagreement around a particular
281 modification. See _Consensus Seeking Process_ below for further detail
282 on the consensus model used for governance.
284 Collaborators may opt to elevate significant or controversial
285 modifications, or modifications that have not found consensus to the
286 WG for discussion by assigning the ***WG-agenda*** tag to a pull
287 request or issue. The WG should serve as the final arbiter where
290 For the current list of Collaborators, see the project
291 [README.md](./README.md#current-project-team-members).
295 WG seats are not time-limited. There is no fixed size of the WG.
296 However, the expected target is between 6 and 12, to ensure adequate
297 coverage of important areas of expertise, balanced with the ability to
298 make decisions efficiently.
300 There is no specific set of requirements or qualifications for WG
301 membership beyond these rules.
303 The WG may add additional members to the WG by unanimous consensus.
305 A WG member may be removed from the WG by voluntary resignation, or by
306 unanimous consensus of all other WG members.
308 Changes to WG membership should be posted in the agenda, and may be
309 suggested as any other agenda item (see "WG Meetings" below).
311 If an addition or removal is proposed during a meeting, and the full
312 WG is not in attendance to participate, then the addition or removal
313 is added to the agenda for the subsequent meeting. This is to ensure
314 that all members are given the opportunity to participate in all
315 membership decisions. If a WG member is unable to attend a meeting
316 where a planned membership decision is being made, then their consent
319 No more than 1/3 of the WG members may be affiliated with the same
320 employer. If removal or resignation of a WG member, or a change of
321 employment by a WG member, creates a situation where more than 1/3 of
322 the WG membership shares an employer, then the situation must be
323 immediately remedied by the resignation or removal of one or more WG
324 members affiliated with the over-represented employer(s).
328 The WG meets weekly on a Google Hangout On Air. A designated moderator
329 approved by the WG runs the meeting. Each meeting should be
330 published to YouTube.
332 Items are added to the WG agenda that are considered contentious or
333 are modifications of governance, contribution policy, WG membership,
336 The intention of the agenda is not to approve or review all patches;
337 that should happen continuously on GitHub and be handled by the larger
338 group of Collaborators.
340 Any community member or contributor can ask that something be added to
341 the next meeting's agenda by logging a GitHub Issue. Any Collaborator,
342 WG member or the moderator can add the item to the agenda by adding
343 the ***WG-agenda*** tag to the issue.
345 Prior to each WG meeting the moderator will share the Agenda with
346 members of the WG. WG members can add any items they like to the
347 agenda at the beginning of each meeting. The moderator and the WG
348 cannot veto or remove items.
350 The WG may invite persons or representatives from certain projects to
351 participate in a non-voting capacity.
353 The moderator is responsible for summarizing the discussion of each
354 agenda item and sends it as a pull request after the meeting.
356 ### Consensus Seeking Process
359 [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
360 decision-making model.
362 When an agenda item has appeared to reach a consensus the moderator
363 will ask "Does anyone object?" as a final call for dissent from the
366 If an agenda item cannot reach a consensus a WG member can call for
367 either a closing vote or a vote to table the issue to the next
368 meeting. The call for a vote must be seconded by a majority of the WG
369 or else the discussion will continue. Simple majority wins.
371 Note that changes to WG membership require unanimous consensus. See
372 "WG Membership" above.
374 ### Developer's Certificate of Origin 1.0
376 By making a contribution to this project, I certify that:
378 * (a) The contribution was created in whole or in part by me and I
379 have the right to submit it under the open source license indicated
381 * (b) The contribution is based upon previous work that, to the best
382 of my knowledge, is covered under an appropriate open source license
383 and I have the right under that license to submit that work with
384 modifications, whether created in whole or in part by me, under the
385 same open source license (unless I am permitted to submit under a
386 different license), as indicated in the file; or
387 * (c) The contribution was provided directly to me by some other
388 person who certified (a), (b) or (c) and I have not modified it.
393 This Code of Conduct is adapted from [Rust's wonderful
394 CoC](https://github.com/rust-lang/rust/wiki/Note-development-policy#conduct).
396 * We are committed to providing a friendly, safe and welcoming
397 environment for all, regardless of gender, sexual orientation,
398 disability, ethnicity, religion, or similar personal characteristic.
399 * Please avoid using overtly sexual nicknames or other nicknames that
400 might detract from a friendly, safe and welcoming environment for
402 * Please be kind and courteous. There's no need to be mean or rude.
403 * Respect that people have differences of opinion and that every
404 design or implementation choice carries a trade-off and numerous
405 costs. There is seldom a right answer.
406 * Please keep unstructured critique to a minimum. If you have solid
407 ideas you want to experiment with, make a fork and see how it works.
408 * We will exclude you from interaction if you insult, demean or harass
409 anyone. That is not welcome behaviour. We interpret the term
410 "harassment" as including the definition in the [Citizen Code of
411 Conduct](http://citizencodeofconduct.org/); if you have any lack of
412 clarity about what might be included in that concept, please read
413 their definition. In particular, we don't tolerate behavior that
414 excludes people in socially marginalized groups.
415 * Private harassment is also unacceptable. No matter who you are, if
416 you feel you have been or are being harassed or made uncomfortable
417 by a community member, please contact one of the channel ops or any
418 of the TC members immediately with a capture (log, photo, email) of
419 the harassment if possible. Whether you're a regular contributor or
420 a newcomer, we care about making this community a safe place for you
421 and we've got your back.
422 * Likewise any spamming, trolling, flaming, baiting or other
423 attention-stealing behaviour is not welcome.
424 * Avoid the use of personal pronouns in code comments or
425 documentation. There is no need to address persons when explaining
426 code (e.g. "When the developer")