Skip to content

Latest commit

 

History

History
184 lines (142 loc) · 7.84 KB

GOVERNANCE.md

File metadata and controls

184 lines (142 loc) · 7.84 KB
Raw

Docker Working Group

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.

Collaborators

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 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, 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).

WG Meetings

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.

Consensus Seeking Process

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.

Developer's Certificate of Origin 1.1

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.

Code of Conduct

This Code of Conduct is adapted from Rust's wonderful CoC.

  • 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; 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")