| ### Streams Working Group |
| |
| The Node.js Streams 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](./README.md#current-project-team-members). |
| |
| ### Collaborators |
| |
| The readable-stream 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 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 readable-stream 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#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 occasionally 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 a majority consensus. See |
| "WG Membership" above. |