The Node.js Community Committee initiatives are governed by its Collaborators, including the Community Commitee (CommComm) which is responsible for high-level guidance of the initiatives.
An individual begins contributing as a "Contributor". A contributor is any individual participating in working groups or initiatives of the Community Committee by:
- commenting on an issue or pull request, OR
- creating an issue or pull request
Contributors have no special access to the repositories under the Community Committee.
To begin contributing to working groups and initiatives, start participating!
Attend the meetings of the working group or initiative, investigate issues tagged
as good first issue, open issues and pull requests, or provide insight via GitHub.
Individuals can open an issue asking to be an invited Guest to CommComm meetings. You can find a great example of such an issue here!
CommComm Collaborators are active contributors with write access to the repo(s) relevant to their initiative or working group.
Active Contributors in the CommComm repositories can be nominated by another Collaborator to become a Collaborator. On approval by existing Collaborators through the consensus process, the nominated Contributor becomes a Collaborator.
Typical activities of a Collaborator include:
- Helping users and novice contributors
- Contributing code, non-code, and documentation changes that improve the project
- Reviewing and commenting on issues and pull requests
- Participating in working groups or initiatives
- Merging pull requests
The CommComm periodically reviews the Collaborator list to identify inactive Collaborators. Past Collaborators are typically given Emeritus status. Emeriti may request that the CommComm restore them to active status.
Active Collaborators of a CommComm initiative or working group can self-nominate or be nominated by a CommComm Member to become a Member of CommComm. On approval by the consensus process, the Collaborator becomes a Member.
Collaborators voted in as Members are given write access to all repositories of the Community Committee, the admin repos, and the moderation repo.
CommComm Members are administrative and help to remove barriers for initiatives and working groups under CommComm’s scope. CommComm Members are involved primarily with decisions that have wider reaching effects than within a single initiative or individual working group. CommComm Members are responsible for making decisions when consensus cannot be reached among Collaborators.
Working groups and initiatives should check-in with CommComm. As the CommComm Members serve as a point of reference for initiatives and working groups, this check-in helps to keep all stakeholders across the Node.js project up-to-date. This improves the initiatives' and working groups' accountability and success.
The CommComm meets regularly in a voice conference call. The meeting is run by a designated meeting chair approved by the CommComm. Each meeting is streamed on YouTube.
Items are added to the CommComm agenda which are considered contentious or are modifications of governance, contribution policy, CommComm membership, or release process.
The intention of the agenda is not to approve or review all patches. That should happen continuously on GitHub and be handled by the larger group of Collaborators.
Any community member or contributor can ask that something be reviewed
by the CommComm by logging a GitHub issue. Any Collaborator, CommComm member, or the
meeting chair can bring the issue to the CommComm's attention by applying the
cc-review label. If consensus-seeking among CommComm members fails for a
particular issue, it may be added to the CommComm meeting agenda by adding the
cc-agenda label.
The CC will elect from amongst voting CC members a CC Chairperson to work on building an agenda for CC meetings and a CC Director to represent the CC to the Board for a term of one year according to the Node.js Foundation’s By-laws. The Chair and Director may be (but are not required to be) the same person. The CC shall hold annual elections to select a CC Chairperson and Director; there are no limits on the number of terms a CC Chairperson or Director may serve.
The CommComm may invite additional persons to participate in a non-voting capacity.
The meeting chair is responsible for ensuring that minutes are taken and that a pull request with the minutes is submitted after the meeting.
Due to the challenges of scheduling a global meeting with participants in several timezones, the CommComm will seek to resolve as many agenda items as possible outside of meetings using the Community-Committee issue tracker. The process in the issue tracker is:
- A CommComm member opens an issue explaining the proposal/issue and @-mentions @nodejs/community-committee.
- After 72 hours, if there are two or more
LGTMs from other CommComm members and no explicit opposition from other CommComm members, then the proposal is approved. - If there are any CommComm members objecting, then a conversation ensues until either the proposal is dropped or the objecting members are persuaded. If there is an extended impasse, a motion for a vote may be made.
Active Contributors of a CommComm initiative or working group can be nominated by another Collaborator to become a Collaborator of that initiative or working group. Contributors making significant, ongoing, and valuable contributions are also identified by the CommComm and their addition as Collaborators is discussed during the weekly CommComm meeting. On approval by the consensus process, the Contributor becomes a Collaborator and is given commit-access to the repo(s) relevant to their initiative.
Modifications to the contents of the git repositor(y/ies) under
the responsibility of the Collaborators 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 effort.
Collaborators may request Emeritus status when they find themselves inactive. The CommComm also periodically reviews the Collaborator list to identify inactive Collaborators. Past Collaborators are typically given Emeritus status. Emeriti may request that the CommComm restore them to active status.
All collaborators added as CommComm members should be on-boarded in a timely manner and be given write access to the repository.
The CommComm follows a Consensus Seeking decision making model as described by the CommComm Charter.