3 io.js Working Groups are autonomous projects created by the TC.
5 Working Groups can be formed at any time but must be ratified by the TC.
6 Once formed the work defined in the Working Group charter is the
7 responsibility of the WG rather than the TC.
9 It is important that Working Groups are not formed pre-maturely. Working
10 Groups are not formed to *begin* a set of tasks but instead are formed
11 once that work is already underway and the contributors
12 think it would benefit from being done as an autonomous project.
14 If the work defined in a Working Group charter is completed the Working
15 Group should be dissolved and the responsibility for governance absorbed
18 ## Current Working Groups
22 The website working group's purpose is to build and maintain a public
23 website for the `io.js` project.
25 Its responsibilities are:
26 * Develop and maintain a build and automation system for `iojs.org`.
27 * Ensure the site is regularly updated with changes made to `io.js` like
28 releases and features.
29 * Foster and enable a community of translators.
31 The current members can be found in their
32 [README](https://github.com/iojs/website#current-project-team-members).
36 The streams working group's purpose is to improve the existing Stream
37 implementation, in accordance with the communities needs and feedback.
39 Its responsibilities are:
40 * Produce a living `Stream` standard.
41 * Create a reference implementation as `readable-stream`.
42 * Recommend versions of `readable-stream` to be included in `io.js`
43 * Collaborate with the WHATWG Stream standard to ensure an optimal level
44 of compatibility between the two standards.
69 The build working group's purpose is to create and maintain a
70 distributed automation infrastructure.
72 Its responsibilities are:
73 * Produce Packages for all target platforms.
75 * Run performance testing and comparisons.
77 The current members can be found in their
78 [README](https://github.com/iojs/build#people).
82 A Working Group is established by first defining a charter that can be
83 ratified by the TC. A charter is a *statement of purpose*, a
84 *list of responsibilities* and a *list of initial membership*.
86 A working group needs 5 initial members. These should be individuals
87 already undertaking the work described in the charter.
89 The list of responsibilities should be specific. Once established these
90 responsibilities are no longer governed by the TC and therefor should
91 not be broad or subjective.
93 If the responsibilities described in the charter are currently
94 undertaken by another WG then the charter will additionally have to be
97 You can submit the WG charter for ratification by sending
98 a Pull Request to this document which adds the it to the
99 list of current Working Groups. Once ratified the list of
100 members should be maintained in the Working Group's
103 ## Bootstrap Governance
105 Once the TC ratifies a charter the WG inherits the following
106 documentation for governance, contribution, conduct and an MIT
107 LICENSE. The WG is free to change these documents through their own
108 governance process, hence the term "bootstrap."
110 ### *[insert WG name]* Working Group
112 The io.js *[insert WG name]* is jointly governed by a Working Group (WG)
113 which is responsible for high-level guidance of the project.
115 The WG has final authority over this project including:
117 * Technical direction
118 * Project governance and process (including this policy)
119 * Contribution policy
120 * GitHub repository hosting
122 * Maintaining the list of additional Collaborators
124 For the current list of WG members, see the project
125 [README.md](./README.md#current-project-team-members).
129 The [iojs/website](https://github.com/iojs/website) GitHub repository is
130 maintained by the WG and additional Collaborators who are added by the
131 WG on an ongoing basis.
133 Individuals making significant and valuable contributions are made
134 Collaborators and given commit-access to the project. These
135 individuals are identified by the WG and their addition as
136 Collaborators is discussed during the weekly WG meeting.
138 _Note:_ If you make a significant contribution and are not considered
139 for commit-access log an issue or contact a WG member directly and it
140 will be brought up in the next WG meeting.
142 Modifications of the contents of the iojs/website repository are made on
143 a collaborative basis. Anybody with a GitHub account may propose a
144 modification via pull request and it will be considered by the project
145 Collaborators. All pull requests must be reviewed and accepted by a
146 Collaborator with sufficient expertise who is able to take full
147 responsibility for the change. In the case of pull requests proposed
148 by an existing Collaborator, an additional Collaborator is required
149 for sign-off. Consensus should be sought if additional Collaborators
150 participate and there is disagreement around a particular
151 modification. See _Consensus Seeking Process_ below for further detail
152 on the consensus model used for governance.
154 Collaborators may opt to elevate significant or controversial
155 modifications, or modifications that have not found consensus to the
156 WG for discussion by assigning the ***WG-agenda*** tag to a pull
157 request or issue. The WG should serve as the final arbiter where
160 For the current list of Collaborators, see the project
161 [README.md](./README.md#current-project-team-members).
165 WG seats are not time-limited. There is no fixed size of the WG.
166 However, the expected target is between 6 and 12, to ensure adequate
167 coverage of important areas of expertise, balanced with the ability to
168 make decisions efficiently.
170 There is no specific set of requirements or qualifications for WG
171 membership beyond these rules.
173 The WG may add additional members to the WG by unanimous consensus.
175 A WG member may be removed from the WG by voluntary resignation, or by
176 unanimous consensus of all other WG members.
178 Changes to WG membership should be posted in the agenda, and may be
179 suggested as any other agenda item (see "WG Meetings" below).
181 If an addition or removal is proposed during a meeting, and the full
182 WG is not in attendance to participate, then the addition or removal
183 is added to the agenda for the subsequent meeting. This is to ensure
184 that all members are given the opportunity to participate in all
185 membership decisions. If a WG member is unable to attend a meeting
186 where a planned membership decision is being made, then their consent
189 No more than 1/3 of the WG members may be affiliated with the same
190 employer. If removal or resignation of a WG member, or a change of
191 employment by a WG member, creates a situation where more than 1/3 of
192 the WG membership shares an employer, then the situation must be
193 immediately remedied by the resignation or removal of one or more WG
194 members affiliated with the over-represented employer(s).
198 The WG meets weekly on a Google Hangout On Air. The meeting is run by
199 a designated moderator approved by the WG. Each meeting should be
200 published to YouTube.
202 Items are added to the WG agenda which are considered contentious or
203 are modifications of governance, contribution policy, WG membership,
206 The intention of the agenda is not to approve or review all patches,
207 that should happen continuously on GitHub and be handled by the larger
208 group of Collaborators.
210 Any community member or contributor can ask that something be added to
211 the next meeting's agenda by logging a GitHub Issue. Any Collaborator,
212 WG member or the moderator can add the item to the agenda by adding
213 the ***WG-agenda*** tag to the issue.
215 Prior to each WG meeting the moderator will share the Agenda with
216 members of the WG. WG members can add any items they like to the
217 agenda at the beginning of each meeting. The moderator and the WG
218 cannot veto or remove items.
220 The WG may invite persons or representatives from certain projects to
221 participate in a non-voting capacity.
223 The moderator is responsible for summarizing the discussion of each
224 agenda item and send it as a pull request after the meeting.
226 ### Consensus Seeking Process
229 [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
230 decision making model.
232 When an agenda item has appeared to reach a consensus the moderator
233 will ask "Does anyone object?" as a final call for dissent from the
236 If an agenda item cannot reach a consensus a WG member can call for
237 either a closing vote or a vote to table the issue to the next
238 meeting. The call for a vote must be seconded by a majority of the WG
239 or else the discussion will continue. Simple majority wins.
241 Note that changes to WG membership require unanimous consensus. See
242 "WG Membership" above.
244 ### Developer's Certificate of Origin 1.0
246 By making a contribution to this project, I certify that:
248 * (a) The contribution was created in whole or in part by me and I
249 have the right to submit it under the open source license indicated
251 * (b) The contribution is based upon previous work that, to the best
252 of my knowledge, is covered under an appropriate open source license
253 and I have the right under that license to submit that work with
254 modifications, whether created in whole or in part by me, under the
255 same open source license (unless I am permitted to submit under a
256 different license), as indicated in the file; or
257 * (c) The contribution was provided directly to me by some other
258 person who certified (a), (b) or (c) and I have not modified it.
263 This Code of Conduct is adapted from [Rust's wonderful
264 CoC](https://github.com/rust-lang/rust/wiki/Note-development-policy#conduct).
266 * We are committed to providing a friendly, safe and welcoming
267 environment for all, regardless of gender, sexual orientation,
268 disability, ethnicity, religion, or similar personal characteristic.
269 * Please avoid using overtly sexual nicknames or other nicknames that
270 might detract from a friendly, safe and welcoming environment for
272 * Please be kind and courteous. There's no need to be mean or rude.
273 * Respect that people have differences of opinion and that every
274 design or implementation choice carries a trade-off and numerous
275 costs. There is seldom a right answer.
276 * Please keep unstructured critique to a minimum. If you have solid
277 ideas you want to experiment with, make a fork and see how it works.
278 * We will exclude you from interaction if you insult, demean or harass
279 anyone. That is not welcome behaviour. We interpret the term
280 "harassment" as including the definition in the [Citizen Code of
281 Conduct](http://citizencodeofconduct.org/); if you have any lack of
282 clarity about what might be included in that concept, please read
283 their definition. In particular, we don't tolerate behavior that
284 excludes people in socially marginalized groups.
285 * Private harassment is also unacceptable. No matter who you are, if
286 you feel you have been or are being harassed or made uncomfortable
287 by a community member, please contact one of the channel ops or any
288 of the TC members immediately with a capture (log, photo, email) of
289 the harassment if possible. Whether you're a regular contributor or
290 a newcomer, we care about making this community a safe place for you
291 and we've got your back.
292 * Likewise any spamming, trolling, flaming, baiting or other
293 attention-stealing behaviour is not welcome.
294 * Avoid the use of personal pronouns in code comments or
295 documentation. There is no need to address persons when explaining
296 code (e.g. "When the developer")