draft

vim ./src/drafts/draft-npm-cli-governance.md

npm CLI Project Governance

STATUS: Draft

This document defines the organizational structure and processes for the npm CLI project. It establishes roles that collaborators can take as they learn about and commit to the project.

History and Motivation

npm began as a solo personal project of Isaac Z. Schlueter in 2009. In 2014, the use of the npm registry and CLI had grown to a point where it was no longer sustainable to run as a side project on donated infrastructure.

In order to provide support for the growing npm userbase, npm, Inc. was founded in 2014, with the mission of establishing a stable business backing that would keep the npm registry solvent. At that time, the npm CLI also moved from a personal project to one owned by npm, Inc.

From 2014 through 2019, the CLI team at npm, Inc. has made significant improvements to the project, and refined many of its practices. However, there was never a clear way to become a dedicated contributor to the npm CLI and a part of the CLI development team, other than employment by npm, Inc. This has had some unfortunate effects.

First, it's discouraged continued contributions from interested parties, and dissuaded them from putting in the time necessary to learn the ropes of a large codebase with a long legacy.

Second, it has put the entire load of any significant development or project decisions squarely on the shoulders of the npm, Inc. CLI team. As an early-stage startup tasked with also keeping the npm registry up and running, this team was never more than a few people.

Lastly, it is important to us to keep in mind that labor has value, and having community members provide significant amounts of work to a project without compensation raises unpleasant ethical concerns.

Thus, a goal of this structure is to enable companies other than npm, Inc. to have their paid employees work on the project. Without open governance, it is difficult for private for-profit companies to justify contribution to a project dominated by another party, where they get little in return.

Goals

Rationale and Alternatives

This proposal tries to be a "minimum viable community" for the npm CLI project that can be fully functional from day 1 and allows steady growth of Teams.

After taking into account various forms of open source governance for projects of various scales, it was determined that something like what this RFC proposes would be the best balance of honesty and openness.

Initial Membership

At the time of this writing, the only members are Kat Marchán and Isaac Z. Schlueter, both npm, Inc. employees. In order to be considered a successful open governed project, however, we expect ratification of this governance proposal, and a committement of personnel resources, from at least 2 other companies. (This is a general guideline only; of course if we see massive adoption from individual community members, that would also be a form of success.)

For now, this remains an ad hoc joint effort, and the project is still technically owned buy npm, Inc. Whether (and for how long) this remains the case, and when/if the project lands in a foundation, is still to be determined.

Decision Making Process

By default, Teams on the npm CLI project make decisions following a rough consensus model. In short, this means that unanimous consent of all members is not required to move forward. However, any objections to a proposal must be considered and addressed by the members of the team, and deemed to be acceptable. Before finalizing the decision, the team asks if there are any new objections which have not yet been addressed. If not, then rough consensus has been reached, and the decision moves forward.

The number of "votes" does not matter. Objections need not come from any privileged members. All valid objections must be addressed (though not necessarily resolved) before consensus can be reached, regardless of their origin.

Teams are accountable to the Steering Committee, and otherwise may update their processes as they see fit. For example, if a Team decides via rough consensus to use a voting or BDFL model, that is fine, as long as their objectives continue to be met.

Compatibility (Backward, Forward, and Sideways)

In general, the npm CLI maintains an extremely high degree of compatibility wherever possible, balanced against the need to make forward progress on features and capabilities, to best serve our community while fracturing it as little as possible.

Fundamental design principles in ranked order of priority:

While there may be valid reasons to contradict these principles in some situations, it must not be done lightly, and affordances must be provided to help the user resolve the problems that occur.

Additionally, the currently active CLI release must support at least the oldest LTS version of Node.js. Dropping support for a Node.js version requires a semver-major CLI version update.

Breaking changes to CLI behavior, data structures, command semantics, and so on, may be done in a semver-major version update, but must be called out in the changelog, and should detect and adjust whenever possible.

Collaborators and Ranking

"Collaborator" is the general term for anyone who has contributed to the npm CLI project, in aspect, whether or not they have officially been recognized. Anyone who officially becomes a member of a Team, in accordance with that Team's processes, becomes a Member.

There are two types of Member on any team: Full Members and Guest Members.

Full Member

These Members are considered committed, established, and can represent their Teams in an official capacity in the project.

Full Members are expected to contribute more than 4 hours per week to the npm CLI project in relevant tasks related ot their Team's objectives. Full Members can attend wider-project meetings and take active part in their Teams' decision-making processes.

A single individual may be a Full Member of no more than 4 teams at any one time. There is no limit on the number of Guest memberships a single individual may have.

Guest Member

Guest Members are considered valuable collaborators who make noteworthy contributions to the team and the project as a whole, but are not generally committed in the way a Full Member would be.

Guest Members can only observe in decision-making processes for various Teams, they have no special privileges granted within the organization, and they cannot participate in Roadmap Proposal discussions.

Memberships and Multiple Roles

Membership status operates on two levels: if a collaborator holds Full Member status on any team, they are treated as Full Members in any cross-organization situation. However, within a team, they are only considered Full Members if they put at least 4 hours per week into that specific team.

Thus, collaborators can be Guest Members of as many teams as will accept them, but only Full Members of no more than 4 teams. Any other teams will be treated as Guest Memberships in the case of additional Roles, and Full Memberships that the collaborator picks must be declared beforehand.

Teams should not expect or request significant, over-4-hours worth of labor from these "Full Time" members if they are a Guest Member of that Role.

If a member's time demands change over time such that they can no longer dedicate 4 hours per week to the needs of a given team, they are expected to withdraw from their Full Member status. Any team can decide to switch a Full Member to a Guest Member, or add someone as a Full Member, at any time.

Teams

Each team is tasked with a specific area of authority over which they have final decision-making power, barring a possible veto from the Steering Committee (see below).

Teams can be created, merged, or disbanded by the Steering Committee as the needs of the project change over time.

Each team is in charge of determining how new members can be added to the team and the exact roles of Guest vs Full members.

Steering Committee

This team is composed of one representative from each of the other teams, and is responsible for the following areas:

The Steering Committee does not have authority on any matters that are within the scope of another team, and will create new teams when new scopes become apparent in the future.

In cases where a project decision affects multiple teams, and the teams cannot reach resolution on their own, the Steering Committee has veto power. The Steering Committee does not have veto power over matters that only affect a single team.

Liaison Team

This team is responsible for coordinating with external parties with vested interest in the npm CLI project. Liaisons facilitate communication, coordination, and planning between the npm CLI teams and external groups involved with other aspects of the npm ecosystem. By having Liaisons, the npm CLI project can more efficiently work on things that might require simultaneous work on multiple projects/products.

At the discretion of the liaison committee, new liaisons may be added in the future. Initially, this includes liaisons for the following groups:

Community Team

Responsible for various aspects of the community side of the npm CLI Project. This is largely centered around npm.community and its various areas and roles.

In charge of the overall structure and functioning of the npm CLI's community programs, including the community website, the CoC, and addressing incidents.

Coordinates with the Support Committee to ensure that policies and standards are maintained.

Support Team

Responsible for CLI community #support and #bugs triage, answering what they can. Escalate support issues to other Teams as needed (or to contributing companies' support when relevant).

This Team keeps track of bugs in general and helps the rest of the project get a sense of what needs attention and how well the project is doing at addressing bugs themselves.

Regularly present to the Steering Committee, Documentation Team, and Development Team, and weigh in on RFCs from the point of view of bug and issue management.

Development Team

This team is responsible for technical development of the core CLI project.

Documentation Team

Release Team

Implementation

This RFC can be implemented immediately from Day 1, with some miscellaneous tasks to dot the Ts and cross the Is:

  1. Proposed teams are created and staffed by current npm, Inc. employees.
  2. Badges and Groups are created in npm.community for each Team described here, and appropriate permissions granted to each Group.
  3. Interested parties take on roles, as available.
  4. An announcement is planned and crafted with npm, Inc. and the initial member companies.
  5. Some existing, regular contributors to the npm CLI are offered Team Memberships.
  6. Everyone celebrates!

drafts