This document outlines the governance model for the e18e community. This includes detailed descriptions of different roles, nomination processes, code review processes, and Code of Conduct enforcement.
👉 All community members must follow the Code of Conduct (CoC).
Consequences for CoC violations are detailed in Moderation.
👉 Want to trigger a vote or perform some other action?
Scroll down to Playbook.
Importantly, e18e is a community and spans across many projects, initiatives and collaborations. This governance model is more flexible than many others for this reason, and is designed to be adaptable to the needs of the community as it grows and changes over time.
We recognize a set of roles that members can earn through their work in the community. Each role comes with a new set of privileges and responsibilities, and is meant to recognize the time and energy that a member has given.
Community roles are available to all members of the e18e community, regardless of coding skill or experience.
Two important things that we look for in a candidate are:
- Being here - Everyone's time is valuable, and the fact that you're here and contributing is amazing! Thank you for being a part of this community.
- Being a positive member of our community - Go above and beyond our Code of Conduct and commit to healthy communication across pull requests, issue discussions, Discord conversations, and any interactions outside of our community.
Members can voluntarily leave their role in the community at any time. See Retiring a Role below for more information.
In extreme cases -- such as a Code of Conduct violation -- a role may be revoked by a Steward at their discretion. This applies across the community as a whole, not to a specific project.
Each new Community role unlocks new privileges and responsibilities both on Discord and on GitHub. Below is a summary of each role.
The Maintainer role is available to members who have shown a sustained commitment to the community and its projects.
Given the e18e community manages a wide range of projects and initiatives, this isn't necessarily a "code maintainer" role. A maintainer can also be someone who has contributed a lot to the community in other ways, such as triaging issues, helping out on Discord, writing documentation, or any other contribution that has a significant impact on the community.
Some maintainers maintain projects, while others may just contribute widely across the community.
- To be nominated, a nominee is expected to already be supporting the community in some of the ways described above.
- You can be nominated by any existing Maintainer or above
- Once nominated, the nomination passes if consensus is reached among existing Maintainers and above. See Nominations for details.
The Core role is available to community members who have a larger-than-usual impact on the community. They are seen as leaders and are listened to by the wider community, often before they have even taken on this role.
Core members are those who have significant positive impact on the community and are involved in the long-term health of it. They are usually involved in leadership of one or more community initiatives and, in most cases, build a specialism for one area over time.
- To be nominated, a nominee is expected to already be performing some of the responsibilities of a Core member.
- You can be nominated by any existing Core member, Advisor, or above
- Once nominated, the nomination passes if consensus is reached among existing Core members, Advisors, and above. See Nominations for details.
The Advisor role is available to community members who have just as large an impact as core members, but are not necessarily leading any initiatives or projects.
An advisor is often someone who is not as involved day-to-day as a core member, but is fundamental to the community's health and direction.
With the core team, advisors are deeply involved in direction of the community, external relationships, and other high-level initiatives. They are often involved in discussions around the future of the community and its projects.
- To be nominated, a nominee is expected to already be performing some of the responsibilities of an Advisor.
- You can be nominated by any existing Core member, Advisor, or above
- Once nominated, the nomination passes if consensus is reached among existing Core members, Advisors, and above. See Nominations for details.
The Steward is an additional role bestowed to 1 (or more) members of the community.
The role of Steward is mainly an administrative one. Stewards control and maintain sensitive community assets, assist in resolving conflicts, and act as tiebreakers in the event of disagreements.
In some cases, a Steward can act unilaterally when they believe it is in the community's best interest and can prove that the issue cannot be resolved through normal governance procedure. The steward must publicly state their reason for unilateral action before taking it.
- Stewards cannot be self-nominated.
- Only Core members and Advisors are eligible.
- New Stewards will be added based on a unanimous vote by the existing Steward(s).
- In the event that someone is unreachable then the decision will be deferred.
Alumni is a special designation for members who have retired from their role. See Retiring a Role below for more information.
Community roles are granted for as long as the person wishes to engage with the community. However, over time an active community member may choose to step away from the community entirely to work on other things, or may simply want to take a step back and be a regular member again.
Alumni is a special designation and role for any person who was once active in a role but has since retired from it. By retiring and joining Alumni you trade-in your current set of roles, privileges, and responsibilities for a new, special Alumni role.
You can retire your role at any time by pinging a Steward and requesting Alumni status. You can initiate this action yourself if you know ahead-of-time that you need to step away from the role.
Except for Stewards, members who are inactive for longer than six months may be proactively retired by a Steward, who will designate them as alumni and notify them of the change.
Rejoining a community role after retiring will automatically remove you from the Alumni role and need to follow the normal nomination process for the role you are trying to rejoin.
Certain community decisions (like governance changes) require a vote. Below are the changes that require a vote, and the rules that govern that vote. Role nominations are handled separately via consensus - see Nominations.
A Steward may initiate a vote for any unlisted decision. General Rules will apply, along with any addition rules provided at the steward's discretion. If this unlisted decision is expected to be repeated in the future, voting rules should be agreed on and then added to this document.
- Members may abstain from any vote.
- Members who do not vote within 3 days will automatically abstain.
- Stewards may reduce the 3 day automatic abstain for urgent decisions.
- Stewards reserve the right to veto approval with a publicly disclosed reason.
- A vote requires at least 3 non-abstaining votes to be valid (or all eligible voters if there are fewer than 3). If there are not enough votes, the vote will be invalid and the decision will be deferred until a valid vote can be held.
This process kicks off once a valid nomination has been made. (Stewards are nominated separately - see the Steward section.)
The group the person is being nominated for is responsible for deciding on the nomination. Anyone in a role above that group in responsibility can also participate.
General hierarchy is as follows (in order of top responsibility to base responsibility):
- Steward
- Core / Advisor
- Maintainer
- A discussion thread should be created in Discord in the appropriate private channel of the group responsible for the decision.
- A thread can be created by any member eligible to participate in the decision for the target role.
- Once a thread is created, existing members can discuss the nomination in private.
- The nomination passes if consensus is reached among the eligible members. What constitutes consensus is intentionally unspecified and is left to the judgement of those involved, with a Steward acting as a tiebreaker if needed.
- If consensus is reached: the nominee will be given the suggested role and all privileges will be made available to them.
- If consensus is not reached: a Steward is responsible for informing the nominee with constructive, actionable feedback. (Note: this is not required if the nomination was made in private, i.e. the nominee was unaware).
A vote is initiated once a pull request to the GOVERNANCE.md file is submitted by a Core Member or Advisor.
If the pull request submitter is not a Core Member or Advisor, the PR can be closed by anyone with GitHub permission to do so without a vote. However, any Core Member may request a vote on that PR, in which case a vote is initiated.
Who can vote: Core members, Advisors, and above. All Maintainers are encouraged to discuss and voice their opinion in the pull request discussion. Core members and Advisors should take the opinions of Maintainers into consideration when voting.
- The pull request discussion thread is used to discuss the governance change.
- The normal 3 day voting & discussion window begins with either the PR creation or the removal of
WIP:from the PR title if the PR was created as a draft. - Voting can be done in the pull request via a review of either Approve (For) or Change Requested (Against).
- The vote must receive a simple majority (50%+) to pass.
- If the vote passes: the PR is merged and the changes take effect immediately.
- If the vote fails: the PR is closed and no change occurs.
Outlined below is the process for Code of Conduct violation reviews.
Anyone may report a violation. Violations can be reported in the following ways:
- In private, via email to one or more stewards.
- In private, via direct message to a steward on Discord
- In public, via a GitHub comment (mentioning a person with one of the community roles).
- In public, via the Discord server
To help find how to reach an appropriate person, please see the membership list.
Each report will be assigned reviewers. These will initially be all stewards.
In the event of any conflict of interest - ie. stewards who are personally connected to a situation, they must immediately recuse themselves.
At request of the reporter and if deemed appropriate by the reviewers, another neutral third-party may be involved in the review and decision process.
If a report doesn’t contain enough information, the reviewers will strive to obtain all relevant data before acting.
The reviewers will then review the incident and determine, to the best of their ability:
- What happened.
- Whether this event constitutes a Code of Conduct violation.
- Who, if anyone, was involved in the violation.
- Whether this is an ongoing situation.
The reviewers should aim to have a resolution agreed very rapidly; if not agreed within a week, they will inform the parties of the planned date.
Responses will be determined by the reviewers on the basis of the information gathered and of the potential consequences. It may include:
- taking no further action
- issuing a reprimand (private or public)
- asking for an apology (private or public)
- permanent ban from any affected GitHub orgs and the Discord server
- revoked community role
Inspired by the Astro governance document.