The Node.js Docker project 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.
The nodejs/docker-node 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 as a pull request to this project's README.md.
Note: If you make a significant contribution and are not considered for commit-access log an issue or contact a WG member directly.
Modifications of the contents of the nodejs/docker-node 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 label 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.
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, or remove, members to and from the WG. A WG member may choose to be removed from the WG by voluntary resignation.
Changes to WG membership should be posted in the nodejs/docker-node repository as an issue or pull request with the WG-agenda label followed by the consensus seeking process described below.
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).
This working group does not meet. All discussions and decisions happen in the nodejs/docker-node repository in issues and pull requests. Items that requires a decision by the WG can be flagged with the WG-agenda label.
When an issue is tagged with WG-agenda, the WG may invite persons or representatives from certain projects to participate in the discussion in a non-voting capacity.
The WG follows a Consensus Seeking decision-making model.
All proposed changes to the project must be made in the form of a pull request to the repository (directly committing to a production branch of the repository is not permitted). The consensus seeking process will then follow via discussion by the WG members on that pull request. Changes deemed trivial by WG members may be merged instantly by any WG member, without waiting for consensus, so long as they leave a note explaining the reason for the merge.
When an agenda item has appeared to reach a consensus any WG member may 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 a closing vote. The call for a vote must be seconded by a majority of the WG or else the discussion will continue. Simple majority wins.
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.
-
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
The Node.js Code of Conduct, which applies to this project, can be found at https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md.