This document describes the individuals in and around the unified collective. It describes the motions used to initiate how individuals are nominated and how they step down. Finally, it describes how accepted motions are enacted through playbooks for inviting, onboarding, awarding, succession, and offboarding.
This document is developed by the unified collective core team.
+--------------------------------------------------------------------------+
| person |
| +------------------------------------------------------+ |
| | member | |
| | +----------------------------------+ | |
| | | maintainer | | |
| +-------------+ | +-------------+ | +-------------+ +-------------+ | | |
| | user | | | contributor | | | merger | | releaser | | | |
| +-------------+ | +-------------+ | +-------------+ +-------------+ | | |
| | +----------------------------------+ | |
| +------------------------------------------------------+ |
+--------------------------------------------------------------------------+
A person, in the scope of collective governance, is any individual that participates in a space where the collective has a presence.
Participation includes dealing in the projects governed by the collective (such as using, distributing, or selling), and activity such as code, comments, commits, edits, emails, issues, posts, pull requests, or tweets.
Spaces includes any online or offline place such as email, GitHub, npm, or Twitter.
Persons are further divided into two groups: users and members. A member is a person that is part of a team, a user is not.
Members are further divided into two groups: contributors and maintainers. A maintainer is an active member whose significant and valuable participation spans the whole scope of the team and improves the longevity of the collective, a contributor is not.
The set of contributors should be large; the ideal would be ten or more, as contributors can be contacted to voice their opinions on matters affecting the community, and could in the future become maintainers.
In some cases, a contributor can be an invited guest maintainer on certain projects governed by an organization team. Guest maintainers have the same rights and responsibilities as normal maintainers (specifically mergers, not releasers), except that their participation focusses on one or a few projects instead of the whole organization. Guest maintainers do not have the voting rights that actual maintainers have and cannot nominate other maintainers. Guest maintainers should be the exception to the rule, and are invited through a motion to grant governance.
The set of maintainers should be medium; the ideal would be more than three and less than ten, to spread the workload and avoid burdening or burning out any person. The set of maintainers of the moderation team should instead be small; the ideal would be two or three.
Maintainers of the moderation and core teams are further limited in that they should not be on both teams at the same time to avoid conflicts of interest.
Organization teams further differentiate between two types of maintainers: mergers and releasers. A releaser is a maintainer with the authority to release projects produced by the team, a merger is not.
The set of releasers should be small; the ideal would be three or less, to limit access and reduce risk.
Releasers are required to have an npm account.
One maintainer of an organization team is elected as the team lead. This role must be fulfilled by a collective core team maintainer.
Some (but not all) examples of participation can be gathered through GitHub search, for example, like so:
- Find commits by a user in an org
- Find issues / PRs opened by a user in an org
- Find issues / PRs with comments by a user in an org
- Find PRs with reviews by a user in an org
You can also search in the entire collective.
Typical participation of a member includes:
- Asking questions
- Reporting problems and requesting new features
- Commenting on issues and pull requests
- Triaging issues
- Requesting motions
Typical participation of an organization team maintainer includes:
- Answering questions and helping novice contributors
- Contributing code, non-code, and documentation changes that improve the scope of the team
- Reviewing and merging pull requests
- Participating in initiatives and discussions
Maintainers are not required to contribute code. It is, however, required that maintainers have actively participated for a consistent and significant amount of time already.
Typical participation of a moderation team maintainer includes:
- Enforcing the code of conduct
- Expelling members and blocking users
Typical participation of a core team maintainer includes:
- Focusing on overarching concerns
- Voting to accept or dismiss motions
- Enacting accepted motions
- Communicating between all teams
Typical participation of a lead includes:
- Setting up a team
- Ensuring initiatives are progressing at a reasonable rate
Motions are used to initiate changes in the roles people have based on their participation.
This section describes who may request a motion (the movant), who may be nominated (the nominee), and who may vote (the voters). In some cases, the movant and nominee are the same individual.
Furthermore, this section describes what happens when the vote dismisses a motion and what playbook is followed when it is accepted.
This section describes motions where both the movant and nominee operate in good-faith. Additional policy is needed to define bad-faith scenarios.
A user (the nominee) is nominated by a member (the movant) to become a contributor on one or more team. Users are free to contact members beforehand to suggest their own nomination.
A motion to nominate a contributor cannot be requested to collective teams. For collective teams, request a motion to nominate a maintainer.
The movant must open an issue on unifiedjs/collective to request the motion.
The movant should be convinced that the nominee is indeed an active contributor,
and is therefore tasked to convince the collective core team to accept the
motion, through proof that participation matches that of a contributor.
Other than proof, the motion must include the full name, email address, GitHub
handle, and npm handle (optional) of the nominee, and the teams the nominee is
nominated for.
Any collective core team maintainer may vote.
When the motion is accepted, the lead of a team (if an organization team) or any maintainer (if a collective team), enacts the motion by following the inviting playbook.
When the motion is dismissed, the nominee is ineligible to be nominated as a contributor to the relevant team(s) for six months.
A person (the nominee) is nominated by a maintainer (the movant) to become a merger (in case of an organization team) or maintainer (in case of a collective team) on a single team. Contributors are free to contact maintainers beforehand to suggest their own nomination.
The movant must open an issue on unifiedjs/collective to request the motion.
The movant should be convinced that the nominee is indeed an active maintainer,
and is therefore tasked with convincing the collective core team to accept the
motion, through proof that participation matches that of a maintainer.
The movant should include, if not already known, the npm handle of the nominee.
Any collective core team maintainer may vote.
When the motion is accepted, the lead of the team (if an organization team) or any maintainer (if a collective team), enacts the motion by following the inviting playbook (in case the person has not been invited before) and the onboarding playbook.
When the motion is dismissed, the nominee is ineligible to be nominated as a maintainer to the team for six months.
Also known as: Motion to nominate a maintainer.
A contributor (the nominee and movant) who previously held the role of a maintainer may self-nominate to become a merger (in case of an organization team) or maintainer (in case of a collective team) on a single team.
The movant must open an issue on unifiedjs/collective to request the motion.
The movant is tasked with convincing the collective core team to accept the
motion.
The movant should include, if not already known, their npm handle.
Any collective core team maintainer may vote.
When the motion is accepted, the lead of the team (if an organization team) or any maintainer (if a collective team), enacts the motion by following the onboarding playbook.
When the motion is dismissed, the nominee is ineligible to be nominated as a maintainer to the team for six months.
Also known as: Motion to nominate a releaser.
In case of an organization team, a merger (the nominee and movant) may self-nominate to become a releaser on a team.
The movant must open an issue on unifiedjs/collective to request the motion.
The movant is tasked with convincing the collective core team to accept the
motion.
The movant must include, if not already known, their npm handle.
Any collective core team maintainer may vote.
When the motion is accepted, the lead of the team enacts the motion by following the awarding playbook.
When the motion is dismissed, the nominee is ineligible to be nominated as a releaser to the team for six months.
Also known as: Motion to elect a lead.
In case of an organization team, yearly, the lead (the movant) must open an issue on the team’s governance repository to notify maintainers that elections are coming up. Maintainers of the team that are interested in volunteering as lead but are not collective core team maintainers, may then move to become core team maintainers.
When one month has passed, the movant must open another issue on the team’s governance repository to request a motion to elect a lead. The movant is tasked with compiling a list of nominees with all maintainers of the team, that are also collective core team maintainers, and are interested in volunteering as lead. The nominees may include the movant.
Any maintainer of the team may vote.
The motion cannot be dismissed.
The motion is accepted immediately if there is only one nominee and otherwise after 14 days. The movant enacts the motion by following the succession playbook for the nominee with the most votes.
Also known as: Motion to be excused from duty.
Any maintainer (the movant and nominee) may request a motion to be excused from duty.
The movant must open an issue on unifiedjs/collective to request the motion.
It is discouraged to request to resign if the nominee is the lead, or the last
maintainer of a team, before finding suitable replacement.
The motion must include the new role the nominee wishes to have, which must
require less participation that their current role (one of: merger, maintainer,
or contributor).
The motion cannot be dismissed.
The motion is accepted. The lead of a team (if an organization team) or any maintainer (if a collective team), enacts the motion by following the offboarding playbook. The offboarding may take up to 45 days (in case of a collective team maintainer) or 7 days (in case of a releaser) if a suitable replacement needs to be found.
The lead of a team (if an organization team) or any maintainer (if a collective team), known as the movant, may request a motion to prune a team. A motion to prune cannot be requested within six months of the previous motion to prune.
The movant must open an issue on the team’s governance repository to request the motion. The motion asks current maintainers for their continued volunteering efforts.
Any maintainer that responds affirmative remains on the team in their current role.
The motion cannot be dismissed.
The motion is accepted after 14 days.
Maintainer that did not respond (the nominees) are treated as if they had
requested a motion to be excused from duty with a role of contributor.
The movant enacts the motion by following the offboarding playbook for the
nominees.
The offboarding may take up to 45 days (in case of a collective team maintainer)
or 7 days (in case of a releaser) if suitable replacements needs to be found.
After offboarding the nominees are immediately eligible to request to become a
maintainer again.
Playbooks describe the steps the enactor and nominee(s) must follow to enact changes initiated through accepted motions.
The inviting playbook is followed when a motion to nominate a contributor, and in some cases a motion to nominate a maintainer or a motion to grant governance, is accepted. The enactor of the playbook is a lead of a team (if an organization team) or any maintainer (if a collective team). The result of inviting is that a user (the nominee) becomes a contributor on one or more teams.
- Nominee ensures 2FA is enabled on GitHub
- Nominee confirms that they have read, understand, and agree to uphold the code of conduct
- Enactor adds the nominee, if not already listed, to
data/humans.yml - Enactor adds the nominee to the respective teams as a
contributorindata/teams.yml - Tooling automatically invites the nominee and sets their permissions on GitHub within 24 hours
The onboarding playbook is followed when a motion to nominate a maintainer is accepted. The enactor of the playbook is the lead of a team (if an organization team) or any maintainer (if a collective team). The result of onboarding is that a contributor (the nominee) becomes a maintainer on a team.
- Enactor adds the npm handle of the nominee, if known and not already listed,
to
data/humans.yml - Enactor changes the role of the nominee in the team from
contributortomerger(if an organization team) ormaintainer(if a collective team) indata/teams.yml - Tooling automatically updates the nominee and changes their permissions on GitHub, and invites the nominee and sets their permissions on npm, within 24 hours
- Enactor and nominee should schedule a call to walk through relevant processes, documents, and expectations
If the nominee is added to a collective team, the following steps additionally apply:
- Enactor adds the nominee to OpenCollective
- @wooorm sets up an email address for the nominee and ensures the relevant collective email addresses are forwarded to it
- Nominee confirms emails can be received
The awarding playbook is followed when a motion to nominate a releaser is accepted. The enactor of the playbook is the lead of a team. The result of awarding is that a merger (the nominee) becomes a releaser on a team.
- Nominee ensures 2FA is enabled on npm
- Enactor adds the npm handle of the nominee, if not already listed, to
data/humans.yml - Enactor changes the role of the nominee in the team from
mergertoreleaserindata/teams.yml - Tooling automatically updates the nominee and changes their permissions on GitHub and npm within 24 hours
- Enactor and nominee should schedule a call to walk through relevant processes, documents, and expectations
The succession playbook is followed when a motion to elect a lead is accepted. The enactor of the playbook is the current lead of the team. The result of succession is that a maintainer (the nominee) becomes the lead of the team.
If the nominee is not the enactor, the following steps are taken:
- Enactor changes the
leadfield indata/teams.ymlto the GitHub handle of the nominee - Tooling automatically updates the enactor and nominee and changes their permissions on GitHub within 24 hours. Enactor may have to manually perform destructive actions as reported by tooling
- Enactor and nominee should schedule a call to walk through relevant processes, documents, and expectations
The offboarding playbook is followed when a motion to be excused from duty, and in some cases a motion to prune, is accepted. The enactor of the playbook is the lead of a team (if an organization team) or any maintainer (if a collective team). If the enactor is also the nominee (because the nominee is the last maintainer of a team), a collective core team maintainer is the enactor. The result of offboarding is that a maintainer (the nominee) becomes a merger, maintainer, or contributor on a team.
Note that if the nominee is being excused from duty as a collective core team maintainer, they are also excused from duty as lead of any organization teams.
- If nominee is being excused from duty as a lead, the collective core team appoints a guest lead. The guest lead is tasked with requesting a motion to elect a lead. This may take up to 45 days
- If the nominee is being excused from duty as a collective moderation team maintainer, and the team is getting too small, the collective core team appoints a guest moderator. The guest moderator and remaining moderators are tasked with finding suitable replacement. This may take up to 45 days
- If the nominee is being excused from duty as a releaser and the set of releasers on the team is getting too small, enactor raises a call for releasers to ask that current mergers request a motion to nominate a releaser. This may take up to 7 days
- Enactor changes the role of the nominee in the respective teams to the
approved role in
data/teams.yml - Tooling automatically updates the nominee and changes their permissions on GitHub and npm within 24 hours. Enactor may have to manually perform destructive actions as reported by tooling
If the nominee is removed from a collective team as a maintainer, the following steps additionally apply:
- Enactor removes the nominee from OpenCollective
- @wooorm removes the nominee’s email address and ensures the relevant collective email addresses are no longer forwarded to them.