From 3af7f30a7cceb1e418e5cd26c65a8ec5cc589d09 Mon Sep 17 00:00:00 2001 From: Mikeal Rogers Date: Sat, 24 Jan 2015 17:11:06 -0500 Subject: [PATCH] Initial documentation for working groups. --- WORKING_GROUPS.md | 296 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 296 insertions(+) create mode 100644 WORKING_GROUPS.md diff --git a/WORKING_GROUPS.md b/WORKING_GROUPS.md new file mode 100644 index 0000000..667588f --- /dev/null +++ b/WORKING_GROUPS.md @@ -0,0 +1,296 @@ +# io.js Working Groups + +io.js Working Groups are autonomous projects created by the TC. + +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. + +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. + +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 + +### Website + +The website working group's purpose is to build and maintain a public +website for the `io.js` project. + +Its responsibilities are: +* Develop and maintain a build and automation system for `iojs.org`. +* Ensure the site is regularly updated with changes made to `io.js` like +releases and features. +* Foster and enable a community of translators. + +The current members can be found in their +[README](https://github.com/iojs/website#current-project-team-members). + +### Streams + +The streams working group's purpose is to improve the existing Stream +implementation, in accordance with the communities needs and feedback. + +Its responsibilities are: +* Produce a living `Stream` standard. +* Create a reference implementation as `readable-stream`. +* Recommend versions of `readable-stream` to be included in `io.js` +* Collaborate with the WHATWG Stream standard to ensure an optimal level +of compatibility between the two standards. + +Initial members are: +* @chrisdickinson +* @isaacs +* @rvagg +* @TooTallNate +* @Raynos +* @calvinmetcalf +* @substack +* @sonewman +* @mafintosh +* @timgestson +* @deoxxa +* @maxogden +* @feross +* @mafintosh +* @calvinmetcalf +* @sonewman +* @domenic +* @timgestson + + +### Build + +The build working group's purpose is to create and maintain a +distributed automation infrastructure. + +Its responsibilities are: +* Produce Packages for all target platforms. +* Run tests. +* Run performance testing and comparisons. + +The current members can be found in their +[README](https://github.com/iojs/build#people). + +## Starting a WG + +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*. + +A working group needs 5 initial members. These should be individuals +already undertaking the work described in the charter. + +The list of responsibilities should be specific. Once established these +responsibilities are no longer governed by the TC and therefor should +not be broad or subjective. + +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 the 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 io.js *[insert WG name]* is jointly governed by a Working Group (WG) +which 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](./README.md#current-project-team-members). + +### Collaborators + +The [iojs/website](https://github.com/iojs/website) GitHub repository is +maintained by the WG and additional Collaborators who are added by the +WG on an ongoing basis. + +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. + +_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. + +Modifications of the contents of the iojs/website 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. + +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. + +For the current list of Collaborators, see the project +[README.md](./README.md#current-project-team-members). + +### WG Membership + +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. + +There is no specific set of requirements or qualifications for WG +membership beyond these rules. + +The WG may add additional members to the WG by unanimous consensus. + +A WG member may be removed from the WG by voluntary resignation, or by +unanimous consensus of all other WG members. + +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. The meeting is run by +a designated moderator approved by the WG. Each meeting should be +published to YouTube. + +Items are added to the WG agenda which 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 send 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 behaviour. 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 behaviour 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") -- 2.7.4