Skip to content

GOVERNANCE.md

Latest commit

 

History

History
77 lines (51 loc) · 5.06 KB

GOVERNANCE.md

File metadata and controls

77 lines (51 loc) · 5.06 KB

StencilJS Governance

The StencilJS Project aims to operate using procedures that are fair, open, inviting, and ultimately beneficial for the community. We believe in codifying the ways that the Project conducts its day-to-day business. Our goal is to ensure that anyone has the opportunity to contribute to StencilJS, while maintaining a balance that prevents any single corporation from exerting undue influence on the community or holding the Project hostage. Similarly, we want to ensure that corporations benefiting from StencilJS are incentivized to give back. This document describes how various types of contributors work within the StencilJS project.

Roles and Responsibilities

Within the StencilJS project we define 3 different roles with their respective 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 submit changes via pull requests. Contributor pull requests have their contribution reviewed and merged by a Technical Steering Committee (TSC) member. TSC members and Committers work with Contributors to review their code and prepare it for merging.

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. Add the GitHub user to the "Project Contributors" team

Project 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
  • Must submit proposals for significant architectural changes as GitHub issues labeled as "Proposal"
  • 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
  • Have submitted a minimum of 15 qualifying pull requests
  • Be respectful of every community member and work collaboratively in the spirit of inclusion

Technical Steering Committee (TSC)

The StencilJS 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, contribution policy, and GitHub repository hosting.

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 own pull requests once they have collected the feedback they deem necessary
  • May support Committers and Contributors to contribute to the project

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 understanding of the code quality standards
  • Commit to being a part of the community for the long term
  • Have submitted a minimum of 30 qualifying pull requests

Communication Channels

The project maintains various channels for providing information, supporting development and enabling communication between team members:

Consensus Seeking Process

The TSC follows a Consensus-Seeking decision-making model. When an agenda item appears to reach a consensus, the moderator will ask "Does anyone object?" as a final call for dissent. If consensus cannot be reached, a TSC member can call for either a closing vote or a vote to table the issue. Amendment of Policies

These policies can be amended with a two-thirds majority vote among the TSC members to adapt to the changing needs and structure of our project.