Skip to content

NodeSecure Governance (Code of conduct & Contribution guidelines)

License

Notifications You must be signed in to change notification settings

NodeSecure/Governance

Repository files navigation

Governance

The NodeSecure Project wants as much as possible to operate using procedures that are fair, open, inviting, and ultimately good for the community. For that reason, we find it valuable to codify some of the ways that the Project goes about its day-to-day business. We want to make sure that no matter who you are, you have the opportunity to contribute to NodeSecure. This document describes how various types of contributors work within the NodeSecure project.

What is the NodeSecure project?

Find out more on our project discovery README

Roles and Responsibilities

Users

Users are community members who have a need for the project. Anyone can be a User; there are no special requirements. Common User contributions include evangelizing the project (e.g., displaying a link on a website and raising awareness through word-of-mouth), informing developers of strengths and weaknesses from a new user perspective, or providing moral support (a "thank you" goes a long way).

Users who continue to engage with the project and its community will often become more and more involved. Such Users may find themselves becoming Contributors, as described in the next section.

Contributors

Contributors are community members who contribute in concrete ways to the project, most often in the form of code and/or documentation. Anyone can become a Contributor, and contributions can take many forms. There is no expectation of commitment to the project, no specific skill requirements, and no selection process.

Contributors have read-only access to source code and to submit changes via pull requests. Contributor pull requests have their contribution reviewed and merged by a TSC member. TSC members and Committers work with Contributors to review and prepare their code for merging.

As Contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for committer-ship by an existing Committer.

To become a Contributor:

  • you have to have at least one pull request proposed, approved and merged or you have helped respond to a variety of issues that helped close them

Process for Adding Contributors

  1. Notify the contribution by adding it with the allcontributors bot
  2. Add the role "Contributor" to the user on Discord (if present)

Committers

Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committers are given push access to the project's GitHub repos and must abide by the project's Contribution Guidelines.

Committers:

  • Are expected to work on public branches of the source repository and submit pull requests from that branch to the main branch. Pull requests have to be made as a draft if the work is not ready for a merge or an initial review.
  • Debates between committers about whether code should be merged should happen in GitHub pull requests or Discord.
  • Proposals for large changes to the project's code (architectural changes, etc...) should be brought forward as a GitHub issue or as a thread on Discord.
  • In general, any committer can review and merge a PR. Committers should only merge code they are qualified to review, which might entail pinging another committer who has greater ownership over a specific code area.
  • Are expected to delete their public branches when they are no longer necessary.
  • Must submit pull requests for all changes.
  • Have their work reviewed by TSC members before acceptance into the repository.
  • May label and close issues
  • May merge some pull requests

To become a Committer:

  • One must have shown a willingness and ability to participate in the project as a team player. Typically, a potential Committer will need to show that they have an understanding of and alignment with the project, its objectives, and its strategy.
  • Committers are expected to be respectful of every community member and to work collaboratively in the spirit of inclusion.
  • Have submitted a minimum of 10 qualifying pull requests. What's a qualifying pull request? One that carries significant technical weight and requires little effort to accept because it's well-documented and tested.

New Committers can be nominated by any existing Committer. Once they have been nominated, there will be a vote by the TSC members.

It is important to recognize that a committer-ship is a privilege, not a right. That privilege must be earned and once earned, it can be removed by the TSC members by a standard TSC motion. However, under normal circumstances, a committer-ship exists for as long as the Committer wishes to continue engaging with the project.

A Committer who shows an above-average level of contribution to the project, particularly concerning its strategic direction and long-term health, may be nominated to become a TSC member, as described below.

Process for Adding Committers

  1. Add the GitHub user to the "Committers" team
  2. Add the role Committers on Discord

Technical Steering Committee (TSC)

The NodeSecure project is jointly governed by a Technical Steering Committee (TSC) which is responsible for high-level guidance of the project.

The TSC has final authority over this project including:

  • Technical direction
  • Project governance and process (including this policy)
  • Contribution policy
  • GitHub repository hosting

TSC seats are not time-limited. There is no fixed size of the TSC. The TSC should be of such a size as to ensure adequate coverage of important areas of expertise balanced with the ability to make decisions efficiently.

The TSC may add additional members to the TSC by a standard TSC motion. A TSC member may be removed from the TSC by voluntary resignation, or by a standard TSC motion.

TSC members have additional responsibilities over and above those of a Committer. These responsibilities ensure the smooth running of the project. TSC members are expected to review code contributions, approve changes to this document, and manage the copyrights within the project outputs.

TSC members fulfill all requirements of Committers, and also:

  • May merge external pull requests for accepted issues upon reviewing and approving the changes.
  • May merge their pull requests once they have collected the feedback they deem necessary. (No pull request should be merged without at least one Project Committer/TSC member comment stating they've looked at the code.)

To become a TSC member:

  • Work in a helpful and collaborative way with the community.
  • Have given good feedback on others' submissions and displayed an overall understanding of the code quality standards for the project.
  • Commit to being a part of the community for the long term.
  • Have submitted a minimum of 30 qualifying pull requests.

A Committer is invited to become a TSC member by existing TSC members. A nomination will result in discussion and then a decision by the TSC.

Process for Adding TSC Members

  1. Add the GitHub user to the "TSC" team
  2. Set the GitHub user to have the "Owner" role for the NodeSecure organization
  3. Add the role "TSC" to the user on Discord
  4. Add the TSC member to the NPM organization

Communication Channels

The project maintains various channels for providing information, supporting development and enabling communication between team members. Adherence to the project's Code of Conduct is strictly mandatory for all types of communication in these channels.

  • LinkedIn Company Account: for communicating and promoting news around the project or project-related topics.
  • Discord: chat for all NodeSecure users to seek help and support on problems using the project.
  • Contributors and Committers Channels: private channel for members of the Project Committers team to discuss contributions and organize other collaborative efforts.
  • TSC Channels: private channel for members of the TSC team to discuss project governance and security topics.

OpenAlly

Consensus Seeking Process

The TSC follows a Consensus-Seeking 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 TSC member can call for either a closing vote or a vote to table the issue at the next meeting. The call for a vote must be approved by a majority of the TSC or else the discussion will continue. A simple majority wins.

Current Project Team Members

TSC

fraxken
Thomas
API / Node.js lead at MyUnisoft

tony-go
Tony
Senior Systems Engineer at Postman
antoine-coulon
Antoine
Lead Software Engineer at Evryg
Kawacrepe
Vincent
Full-stack Engineer
im-codebreaker
Mehdi
Front-end developer at Antidots

PierreDemailly
Pierre
Node.js developer at MyUnisoft

Committers

nicolas-hallaert
Nicolas
Node.js developer at MyUnisoft

Kouadio Fabrice Nguessan
Fabrice
Back-end developer

Jean Michelet
Jean
Node.js developer

Raising Issues Related to Governance

This governance model necessarily leaves many situations unspecified. If questions arise as to how a given situation should proceed according to the overall goals of the project, the best thing to do is to open a GitHub issue and ping the TSC members.

Note

This work is a derivative of the WebdriverIO governance

This work is licensed under a Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License.

About

NodeSecure Governance (Code of conduct & Contribution guidelines)

Resources

License

Code of conduct

Stars

Watchers

Forks