The Community Committee will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to the entire ecosystem.
Most large, complex open source communities have both a business and a technical governance model. Technical leadership for projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council. Community leadership is not explicitly owned or delegated. In the Node.js project, community leadership has been delegated to the Community Committee. The OpenJS Foundation's business leadership is instantiated in a Board of Directors (the “Board”). Community activities, such as events, fall outside of the realm of code and documentation that the Node.js project's TSC oversees. The champions of these organizations have very different skillsets, talents, and concerns. The community organizations of Node.js have long been important to the growth and vitality of the project and will be recognized as the Community Committee ("CommComm").
This Community Committee Charter reflects a formal role and the relevance of the voice of community for the Node.js project to the CPC and within the OpenJS Foundation. The charter amendment process is for the CommComm to propose changes using simple majority of the full CommComm, the proposed changes being subject to review and approval the CPC. The Board may additionally make amendments to the CommComm charter at any time, though the Board will not interfere with day-to-day discussions, votes or meetings of the CommComm.
Membership is for 6 months. The group will ask on a regular basis if the expiring members would like to stay on. A member just needs to reply to renew. There is no fixed size of the CommComm. However, the expected target for Advisors, as defined in Section 9, is between 9 and 12, to ensure adequate coverage of important areas of community expertise, balanced with the ability to make decisions efficiently.
There is no specific set of requirements or qualifications for CommComm membership beyond these rules. The CommComm may add additional members to the CommComm by a standard CommComm motion and vote. A CommComm member may be removed from the CommComm by voluntary resignation, or by a standard CommComm motion.
Changes to CommComm membership should be posted in the agenda, and may be suggested as any other agenda item.
No more than one-fourth of the CommComm members may be affiliated with the same employer or leadership of a community/ecosystem organization. If removal or resignation of a CommComm member, or a change of employment by a CommComm member, creates a situation where more than one-fourth of the CommComm membership shares an employer, then the situation must be immediately remedied by the resignation or removal of one or more CommComm members affiliated with the over-represented employer(s).
The CommComm members shall consist of active members of Community Projects.
The CommComm may, at its discretion, invite any number of non-voting Guests to participate in the public portion of CommComm discussions and meetings.
The CommComm shall meet regularly using tools that enable participation by the community (through any appropriate means selected by the CommComm). Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings.
CommComm members are expected to regularly participate in CommComm activities.
In the case where an individual CommComm member -- within any three month period -- attends fewer than 25% of the regularly scheduled meetings, does not participate in CommComm discussions, and does not participate in CommComm votes, the member shall be automatically removed from the CommComm. The member may be invited to continue attending CommComm meetings as a Guest.
Subject to such policies as may be set by the Board, the CommComm is responsible for all cultural development and outreach within the Node.js Project, including:
- Outreach to community organizations
- Documentation of community organizations
- Cultural direction of Node.js Project
- Overseeing education initiatives for the Node.js Project
- Project governance and process (including this policy)
- Recommendations for building and developing community projects that align with needs of Node.js
- Mediating cultural conflicts between the Node.js project and/or community projects
- Facilitation with external open source projects, select consortiums and other outside groups
The CommComm will establish and maintain a process of support for Node.js community projects. The process will establish guidelines for how culture and values of the community can be supported.
The CommComm is responsible for vetting organizations that will be supported through means such as monetary sponsorship, promotion, resource provisioning, etc. for example requirements such as the organization in question having and executing a Code of Conduct or not conflicting with Node.js project’s goals and priorities.
The CommComm and entire technical community will follow any processes as may be specified by the Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation's IP Policy.
Leadership roles in the CommComm will be peer elected representatives of the community organizations.
For election of persons (CommComm Chairperson, Advisors, etc.) a multiple-candidate method should be used, e.g.:
- Condorcet: http://en.wikipedia.org/wiki/Condorcet_method or
- Single Transferable Vote: http://en.wikipedia.org/wiki/Single_transferable_vote
Multiple-candidate methods may be reduced to simple election by plurality when there are only two candidates for one position to be filled. No election is required if there is only one candidate and no objections to the candidate's election. Nominations for organizations that should be represented on the Community Committee will take place in the GitHub repository. A representative for these organizations shall be selected within the organizations by those active in it.
The CommComm will elect from amongst voting CommComm members:
- a CommComm Chairperson, responsible for preparing agendas and coordinating CommComm meetings
- an OpenJS Foundation Cross Project Council (CPC) voting member to represent the CommComm in the OpenJS Foundation
The CommComm shall hold annual elections to select a CommComm Chairperson and an OpenJS Foundation CPC voting member to represent the CommComm; there are no limits on the number of terms a CommComm Chairperson or OpenJS Foundation CPC voting member to represent the CommComm may serve. The same person may not hold both positions at the same time. Each person shall serve a one year term, and may serve for more than one term.
For internal project decisions, Collaborators shall operate under Lazy Consensus. The CommComm shall establish appropriate guidelines for implementing Lazy Consensus (e.g. expected notification and review time periods) within the development process.
The CommComm 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 CommComm 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 CommComm or else the discussion will continue. Simple majority wins.
The Node.js git repositories for the Community Committee and its initiatives are maintained by the CommComm and additional Collaborators who are added by the CommComm on an ongoing basis.
Individuals making significant and valuable contributions, “Contributor(s)”, are made Collaborators and given commit-access to the project. These individuals are identified by the CommComm and their addition as Collaborators is discussed during the weekly CommComm meeting. Modifications of the contents of the git repository are made on a collaborative basis as defined in the development process.
Collaborators may opt to elevate significant or controversial modifications, or modifications that have not found consensus to the CommComm for discussion by assigning the cc-agenda tag to a pull request or issue. The CommComm should serve as the final arbiter where required. The CommComm will maintain and publish a list of current Collaborators by Project, as well as a development process guide for Collaborators and Contributors looking to participate in the development effort.
- Contributors: contribute code or other artifacts, but do not have the right to commit to the code base. Contributors work with the Project’s Collaborators to have code committed to the code base. A Contributor may be promoted to a Collaborator by the projects’ Maintainer or the CommComm. Contributors should rarely be encumbered by the CommComm and never by the Board.
- Project: a collaboration effort, e.g. a subsystem, that is organized through the project creation process and approved by the CommComm.
- Community Project: projects within the Node.js Foundation or in the ecosystem that contribute to the health of the Node.js project.
- Advisor: a Collaborator within a Community Project elected to represent the Community Project on the CommComm.
- Member: a Collaborator with voting rights who has met the requirements of participation to be considered for acceptance, and subsequently voted in by the CommComm voting process.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in all Community Committee documents are to be interpreted as described in RFC 2119.
For the current list of CommComm members, see the project README.md.