diff --git a/locale/en/about/working-groups.md b/locale/en/about/working-groups.md index 098405cbf776d..821949e9909e8 100644 --- a/locale/en/about/working-groups.md +++ b/locale/en/about/working-groups.md @@ -3,22 +3,47 @@ layout: about.hbs title: Working Groups --- # Working Groups +There are 2 types of Working Groups: +* [Top-Level Working Groups](#top-level-working-groups) +* [Core Working Groups](#core-working-groups) - Working Groups are autonomous projects created by the -[Technical Committee (TC)](https://github.com/nodejs/node/blob/master/GOVERNANCE.md#technical-committee). +## Top-Level Working Groups + -Working Groups can be formed at any time but must be ratified by the TC. -Once formed the work defined in the Working Group charter is the -responsibility of the WG rather than the TC. +Top-Level Working Groups are created by the +[Technical Steering Committee (TSC)](https://github.com/nodejs/TSC#top-level-wgs-and-tlps). -It is important that Working Groups are not formed pre-maturely. Working -Groups are not formed to *begin* a set of tasks but instead are formed -once that work is already underway and the contributors -think it would benefit from being done as an autonomous project. +### Current Top-Level Working Groups +* [Inclusivity](#inclusivity) + +#### [Inclusivity](https://github.com/nodejs/inclusivity) +The Inclusivity Working Group seeks to increase inclusivity and diversity for +the Node.js project: + +* Increasing inclusivity means making the Node.js project a safe and friendly +place for people from diverse backgrounds. +* Increasing diversity means actively onboarding people from diverse backgrounds +to the Node.js project and maintaining their participation. + +Its responsibilites are: +* Foster a welcoming environment that ensures participants are valued and can +feel confident contributing or joining discussions, regardless of any [aspect of +their identity](https://github.com/nodejs/inclusivity/#list-of-responsibilities). +* Proactively seek and propose concrete steps the project can take to increase +inclusivity. +* Serve as a resource for the development and enforcement of workflows that +protect community members and projects from harassment and abuse. +* Acknowledge and celebrate existing diversity accomplishments within the project +while seeking to build upon them. +* Identify ways to measure diversity and inclusivity within the project and report +them at regular intervals. + +# Core Working Groups + + +Core Working Groups are created by the +[Core Technical Committee (CTC)](https://github.com/nodejs/node/blob/master/GOVERNANCE.md#core-technical-committee). -If the work defined in a Working Group charter is completed the Working -Group should be dissolved and the responsibility for governance absorbed -back in to the TC. ## Current Working Groups @@ -31,36 +56,41 @@ back in to the TC. * [Roadmap](#roadmap) * [Docker](#docker) * [Addon API](#addon-api) -* [Starting a Working Group](#starting-a-wg) -* [Bootstrap Governance](#bootstrap-governance) +* [Benchmarking](#benchmarking) +* [Post-mortem](#post-mortem) +* [Intl](#intl) +* [HTTP](#http) +* [Documentation](#documentation) +* [Testing](#testing) + ### [Website](https://github.com/nodejs/nodejs.org) -The website working group's purpose is to build and maintain the public -website. +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. -* Ensure the site is regularly updated with changes like +* 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. ### [Streams](https://github.com/nodejs/readable-stream) The Streams WG is dedicated to the support and improvement of the Streams API -as used in and the npm ecosystem. We seek to create a composable API that +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: -* Addressing stream issues on the issue tracker. -* Authoring and editing stream documentation within the project. -* Reviewing changes to stream subclasses within the project. -* Redirecting changes to streams from the project to this project. -* Assisting in the implementation of stream providers. -* Recommending versions of readable-stream to be included. +* 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. @@ -99,13 +129,16 @@ language community might then produce multiple localizations for various project resources. Their responsibilities are: -* Translations of any materials they believe are relevant to their +* 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. +* Review processes for keeping translations up +to date and of high quality. * Social media channels in their language. -* Promotion of speakers for meetups and conferences in their +* Promotion of Node.js speakers for meetups and conferences in their language. +Note that the i18n working groups are distinct from the [Intl](#Intl) working group. + Each language community maintains its own membership. * [nodejs-ar - Arabic (اللغة العربية)](https://github.com/nodejs/nodejs-ar) @@ -127,7 +160,7 @@ Each language community maintains its own membership. * [nodejs-it - Italian (Italiano)](https://github.com/nodejs/nodejs-it) * [nodejs-ja - Japanese (日本語)](https://github.com/nodejs/nodejs-ja) * [nodejs-ka - Georgian (ქართული)](https://github.com/nodejs/nodejs-ka) -* [nodejs-ko - Korean (한국어)](https://github.com/nodejs/nodejs-ko) +* [nodejs-ko - Korean (조선말)](https://github.com/nodejs/nodejs-ko) * [nodejs-mk - Macedonian (Mакедонски)](https://github.com/nodejs/nodejs-mk) * [nodejs-ms - Malay (بهاس ملايو)](https://github.com/nodejs/nodejs-ms) * [nodejs-nl - Dutch (Nederlands)](https://github.com/nodejs/nodejs-nl) @@ -143,6 +176,17 @@ Each language community maintains its own membership. * [nodejs-uk - Ukrainian (Українська)](https://github.com/nodejs/nodejs-uk) * [nodejs-vi - Vietnamese (Tiếng Việtnam)](https://github.com/nodejs/nodejs-vi) +### [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: + +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 + +The Intl WG 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) @@ -157,27 +201,41 @@ Their responsibilities are: * Publishing regular update summaries and other promotional content. +### [HTTP](https://github.com/nodejs/http) + +The HTTP working group is chartered for the support and improvement of the +HTTP implementation in Node. It's responsibilities are: + +* 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. +* Working with the ecosystem of HTTP related module developers to evolve the + HTTP implementation and APIs in core. +* Advising the CTC on all HTTP related issues and discussions. +* Messaging about the future of HTTP to give the community advance notice of + changes. ### [Roadmap](https://github.com/nodejs/roadmap) The roadmap working group is responsible for user community outreach -and the translation of their concerns into a plan of action. +and the translation of their concerns into a plan of action for Node.js. -The final [ROADMAP](https://github.com/nodejs/node/blob/master/ROADMAP.md) document is still owned by the TC and requires the same approval for changes as any other project asset. +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](https://github.com/nodejs/node/blob/master/ROADMAP.md) +* Create Pull Requests for relevant changes to [Roadmap.md](./ROADMAP.md) -### [Docker](https://github.com/nodejs/docker-node) +### [Docker](https://github.com/nodejs/docker-iojs) The Docker working group's purpose is to build, maintain, and improve official -Docker images. +Docker images for the `Node.js` project. Their responsibilities are: -* Keep the official Docker images updated in line with new releases. +* Keep 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. @@ -186,233 +244,83 @@ Their responsibilities are: 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, assisting in the writing of code that is compatible with many actively used versions of Node.js, V8 and libuv. +abstraction layer for native add-on authors for both Node.js and 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: * Maintaining the [NAN](https://github.com/nodejs/nan) GitHub repository, - including code, issues and documentation. + including code, issues and documentation. * Maintaining the [addon-examples](https://github.com/nodejs/node-addon-examples) - GitHub repository, including code, issues and documentation. -* Maintaining the C++ addon API within the project, in subordination to - the TC. -* Maintaining the addon documentation within the project, in - subordination to the TC. + GitHub repository, including code, issues and documentation. +* Maintaining the C++ Addon API within the Node.js project, in subordination to + the Node.js CTC. +* Maintaining the Addon documentation within the Node.js project, in + subordination to the Node.js CTC. * Maintaining the _nan_ package in npm, releasing new versions as appropriate. -* Messaging about the future of the and NAN interface to give the - community advance notice of changes. +* Messaging about the future of the Node.js and NAN interface to give the + community advance notice of changes. The current members can be found in their [README](https://github.com/nodejs/nan#collaborators). -## Starting a WG +### [Benchmarking](https://github.com/nodejs/benchmarking) -A Working Group is established by first defining a charter that can be -ratified by the TC. A charter is a *statement of purpose*, a -*list of responsibilities* and a *list of initial membership*. +The purpose of the Benchmark working group is to gain consensus +for an agreed set of benchmarks that can be used to: -A working group needs 3 initial members. These should be individuals -already undertaking the work described in the charter. ++ track and evangelize performance gains made between Node releases ++ avoid performance regressions between releases -The list of responsibilities should be specific. Once established, these -responsibilities are no longer governed by the TC and therefore should -not be broad or subjective. The only recourse the TC has over the working -group is to revoke the entire charter and take on the work previously -done by the working group themselves. - -If the responsibilities described in the charter are currently -undertaken by another WG then the charter will additionally have to be -ratified by that WG. - -You can submit the WG charter for ratification by sending -a Pull Request to this document, which adds it to the -list of current Working Groups. Once ratified the list of -members should be maintained in the Working Group's -README. - -## Bootstrap Governance - -Once the TC ratifies a charter the WG inherits the following -documentation for governance, contribution, conduct and an MIT -LICENSE. The WG is free to change these documents through their own -governance process, hence the term "bootstrap." - -### *[insert WG name]* Working Group - -The *[insert WG name]* is jointly governed by a Working Group (WG) -that is responsible for high-level guidance of the project. - -The WG has final authority over this project including: - -* Technical direction -* Project governance and process (including this policy) -* Contribution policy -* GitHub repository hosting -* Conduct guidelines -* Maintaining the list of additional Collaborators - -For the current list of WG members, see the project -[README.md](https://github.com/nodejs/node/blob/master/README.md#current-project-team-members). +Its responsibilities are: -### Collaborators ++ 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 -The *[insert WG name]* GitHub repository is maintained by the WG and additional Collaborators who are added by the WG on an ongoing basis. +### [Post-mortem](https://github.com/nodejs/post-mortem) -Individuals making significant and valuable contributions are made Collaborators and given commit-access to the project. These individuals are identified by the WG and their addition as Collaborators is discussed during the weekly WG meeting. +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. -_Note:_ If you make a significant contribution and are not considered -for commit-access log an issue or contact a WG member directly and it -will be brought up in the next WG meeting. +Its responsibilities are: -Modifications of the contents of the *[insert WG repo]* repository are made on -a collaborative basis. Anybody with a GitHub account may propose a modification via pull request and it will be considered by the project -Collaborators. All pull requests must be reviewed and accepted by a -Collaborator with sufficient expertise who is able to take full -responsibility for the change. In the case of pull requests proposed -by an existing Collaborator, an additional Collaborator is required -for sign-off. Consensus should be sought if additional Collaborators -participate and there is disagreement around a particular -modification. See _Consensus Seeking Process_ below for further detail -on the consensus model used for governance. ++ 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 -Collaborators may opt to elevate significant or controversial -modifications, or modifications that have not found consensus to the -WG for discussion by assigning the ***WG-agenda*** tag to a pull -request or issue. The WG should serve as the final arbiter where -required. +### [Documentation](https://github.com/nodejs/docs) -For the current list of Collaborators, see the project -[README.md](https://github.com/nodejs/node/blob/master/README.md#current-project-team-members). +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 +to all. -### WG Membership +Its responsibilities are: -WG seats are not time-limited. There is no fixed size of the WG. -However, the expected target is between 6 and 12, to ensure adequate -coverage of important areas of expertise, balanced with the ability to -make decisions efficiently. +* Defining and maintaining documentation style and content standards. +* Producing documentation in a format acceptable for the Website WG 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. -There is no specific set of requirements or qualifications for WG -membership beyond these rules. +### [Testing](https://github.com/nodejs/testing) -The WG may add additional members to the WG by unanimous consensus. +The Node.js Testing Working Group's purpose is to extend and improve testing of +the Node.js source code. -A WG member may be removed from the WG by voluntary resignation, or by -unanimous consensus of all other WG members. +It's responsibilities are: -Changes to WG membership should be posted in the agenda, and may be -suggested as any other agenda item (see "WG Meetings" below). - -If an addition or removal is proposed during a meeting, and the full -WG is not in attendance to participate, then the addition or removal -is added to the agenda for the subsequent meeting. This is to ensure -that all members are given the opportunity to participate in all -membership decisions. If a WG member is unable to attend a meeting -where a planned membership decision is being made, then their consent -is assumed. - -No more than 1/3 of the WG members may be affiliated with the same -employer. If removal or resignation of a WG member, or a change of -employment by a WG member, creates a situation where more than 1/3 of -the WG membership shares an employer, then the situation must be -immediately remedied by the resignation or removal of one or more WG -members affiliated with the over-represented employer(s). - -### WG Meetings - -The WG meets weekly on a Google Hangout On Air. A designated moderator -approved by the WG runs the meeting. Each meeting should be published to YouTube. - -Items are added to the WG agenda that are considered contentious or -are modifications of governance, contribution policy, WG membership, -or release process. - -The intention of the agenda is not to approve or review all patches; -that should happen continuously on GitHub and be handled by the larger -group of Collaborators. - -Any community member or contributor can ask that something be added to -the next meeting's agenda by logging a GitHub Issue. Any Collaborator, -WG member or the moderator can add the item to the agenda by adding -the ***WG-agenda*** tag to the issue. - -Prior to each WG meeting the moderator will share the Agenda with -members of the WG. WG members can add any items they like to the -agenda at the beginning of each meeting. The moderator and the WG -cannot veto or remove items. - -The WG may invite persons or representatives from certain projects to -participate in a non-voting capacity. - -The moderator is responsible for summarizing the discussion of each -agenda item and sends it as a pull request after the meeting. - -### Consensus Seeking Process - -The WG follows a -[Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) decision-making model. - -When an agenda item has appeared to reach a consensus the moderator -will ask "Does anyone object?" as a final call for dissent from the -consensus. - -If an agenda item cannot reach a consensus a WG member can call for -either a closing vote or a vote to table the issue to the next -meeting. The call for a vote must be seconded by a majority of the WG -or else the discussion will continue. Simple majority wins. - -Note that changes to WG membership require unanimous consensus. See -"WG Membership" above. - -### Developer's Certificate of Origin 1.0 - -By making a contribution to this project, I certify that: - -* (a) The contribution was created in whole or in part by me and I - have the right to submit it under the open source license indicated - in the file; or -* (b) The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source license - and I have the right under that license to submit that work with - modifications, whether created in whole or in part by me, under the - same open source license (unless I am permitted to submit under a - different license), as indicated in the file; or -* (c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified it. - - -### Code of Conduct - -This Code of Conduct is adapted from [Rust's wonderful -CoC](https://github.com/rust-lang/rust/wiki/Note-development-policy#conduct). - -* We are committed to providing a friendly, safe and welcoming - environment for all, regardless of gender, sexual orientation, - disability, ethnicity, religion, or similar personal characteristic. -* Please avoid using overtly sexual nicknames or other nicknames that - might detract from a friendly, safe and welcoming environment for - all. -* Please be kind and courteous. There's no need to be mean or rude. -* Respect that people have differences of opinion and that every - design or implementation choice carries a trade-off and numerous - costs. There is seldom a right answer. -* Please keep unstructured critique to a minimum. If you have solid - ideas you want to experiment with, make a fork and see how it works. -* We will exclude you from interaction if you insult, demean or harass - anyone. That is not welcome behavior. We interpret the term - "harassment" as including the definition in the [Citizen Code of - Conduct](http://citizencodeofconduct.org/); if you have any lack of - clarity about what might be included in that concept, please read - their definition. In particular, we don't tolerate behavior that - excludes people in socially marginalized groups. -* Private harassment is also unacceptable. No matter who you are, if - you feel you have been or are being harassed or made uncomfortable - by a community member, please contact one of the channel ops or any - of the TC members immediately with a capture (log, photo, email) of - the harassment if possible. Whether you're a regular contributor or - a newcomer, we care about making this community a safe place for you - and we've got your back. -* Likewise any spamming, trolling, flaming, baiting or other - attention-stealing behavior is not welcome. -* Avoid the use of personal pronouns in code comments or - documentation. There is no need to address persons when explaining - code (e.g. "When the developer") +* Coordinating an overall strategy for improving testing. +* Documenting guidelines around tests. +* Working with the Build Working Group to improve continuous integration. +* Improving tooling for testing.