WORKING_GROUPS.md

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