This document outlines the governance model for Astro. This includes detailed descriptions of different roles, nomination processes, code review processes, and Code of Conduct enforcement.
All types of contribution are meaningful. This can include code changes, type fixes, Discord activity, and even posting about Astro to your personal blog. No contribution is too small!
Anyone can become an Astro contributor (yes, even you!). Engineering ability is not required. Our goal is to recognize all contributors to the project regardless of skill, experience or background.
We recognize different levels of contribution as four different **Contributor Levels.** Because each level comes with a new set of privileges and responsibilities, you may also see these levels referred to as **Contributor Roles**.
- **Being here** - Everyone's time is valuable, and the fact that you're here and contributing to Astro is amazing! Thank you for being a part of this project with us.
- **Being a positive member of our community** - Go above and beyond our [Code of Conduct](CODE_OF_CONDUCT.md) and commit to healthy communication across pull requests, issue discussions, Discord conversations, and any interactions outside of our community (ex: no Twitter bullies allowed :)
Have you done something (big or small) to contribute to the health, success, or growth of Astro? **Congratulations, you're officially recognized as a contributor to the project!**
If you're interested in reaching the next level and becoming a **Maintainer**, you can explore some of those responsibilities in the [next section](#level-2-l2---maintainer).
You may self-nominate by sending the message `!contribute` in any Discord channel. If you do this, please share a second message with a link or description of your contribution so that people can recognize you for the contribution.
You may also be granted this role automatically if you are active and helpful on Discord.
The Maintainer role is critical to the long-term health of Astro. Maintainers act as the first line of defense when it comes to new issues, pull requests and Discord activity. Maintainers are most likely the first people that a user will interact with on Discord or GitHub.
**Maintainers are not required to write code!** Some Maintainers spend most of their time inside of Discord, maintaining a healthy community there. Others work on technical documentation, support, or design.
**A Maintainer has moderation privileges!** All maintainers are trusted with the ability to help moderate our Discord and GitHub communities for things like spam. There is also a special (optional, opt-in) `@mods` role open to maintainers who are also interested in helping out when a community member reaches out for moderation help.
There is no strict minimum number of contributions needed to reach this level, as long as you can show **sustained** involvement over some amount of time (at least a few months).
The **Core** role is available to community members who have a larger-than-usual impact on the Astro project and community. They are seen as leaders in the project and are listened to by the wider Astro community, often before they have even reached this level. A Core member is recognized for contributing a significant amount of time and energy to the project through issues, pull requests, bug fixes, implementing advanced enhancements/features, and/or actively posting on Discord.
Not every contributor will reach this level, and that's okay! L2 Maintainers still have significant responsibility and privileges within our community.
Because of these limitations, this type of Core membership is useful for anyone who has been brought in to work on or contribute to the Astro project without rising through our normal contributor levels. For example: an Astro designer or developer advocate hired by The Astro Technology Company to assist the community could be nominated for a Core Residency role without having a previously earned contributor level.
A Core Residency nomination must still be approved through the normal Core nomination and voting process. During the nomination, the Project Steward will state that the nomination is for the Core Residency designation. The project Steward is the only one who can officially make this designation during the nomination process.
If a Core Residency member has their membership revoked, the project Steward may choose to impose a waiting period of some number of days, during which the member can not be re-nominated to become a full Core member.
The role of Steward is mainly an administrative one. Stewards control and maintain sensitive project assets, assist in resolving conflicts, and act as tiebreakers in the event of disagreements.
In extremely rare cases, a Steward can act unilaterally when they believe it is in the project'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.
The project Steward is currently: **@FredKSchott**
Besides our contributor levels described above, there are additional roles and teams available that community members are welcome to join. Roles are a great way to organize around different projects and initiatives in our community. For example:
Many of these team roles can be browsed and joined automatically by visiting the `#manage-roles` channel in our Discord. Getting involved with a team is a great way to start contributing to Astro!
### Moderator
**Moderator** is a special role available to Maintainers (L2 and above). While all maintainers are granted permissions to moderate for bad behavior across our community, a Moderator actively takes on this the responsibility. For example, a community member may ping moderators (via the `@mods` role) to resolve spam posts or Code of Conduct violations.
Trivial tasks (like removing spam) can be acted on unilaterally by a Moderator. Other non-trivial tasks (like assisting with or resolving a Code of Conduct violation) should involve the entire Moderator team (and in some cases, the project Steward).
The **TSC** is a special role available to Core members (L3 and above). TSC members are responsible for the growth and maintenance of the Astro codebase.
A TSC member guides the direction of the project and ensures a healthy future for the Astro codebase. TSC members are ultimately responsible for technical decision making when it comes to any changes to the Astro codebase.
A TSC member has significant sway in software design decisions. For this reason, coding experience is critical for this role. TSC membership is one of the only roles that requires a significant contribution history of code to the Astro project on GitHub.
#### Privileges
-`@tsc` role on [Discord](https://astro.build/chat)
- Invitation to the private `#tsc` channel on Discord
- Invitation to the `tsc` team on GitHub.
- Ability to merge all GitHub PRs.
- Ability to vote on RFCs and technical initiatives (see [Voting](#voting) below).
Staff membership does not grant any additional abilities when it comes to voting and project governance. A Staff member is still eligible for other roles in the community and may still vote as defined by their other roles. For example, a Staff member who is also a part of `@core` will be able to vote as any other `@core` member would.
**Alumni** is a special designation for Maintainers (L2 and above) who have stepped away from the project and no longer contribute regularly. See [Retiring a Role](#retiring-a-role-alumni) below for more information.
#### Privileges
-`@alumni` role on [Discord](https://astro.build/chat)
- New name color on Discord: **light blue**.
- Invitation to the private `#alumni` channel on Discord.
## Retiring a Role (Alumni)
Contributor roles are granted for as long as the person wishes to engage with the project. However, over time an active community member may choose to step away from the Astro project to work on other things. Moving on from a project is a natural and well-understood part of any open source community, and we celebrate it!
**Alumni** is a special designation and role for any person who was once an active maintainer (L2 or above) but is now no longer actively involved. By retiring and joining Alumni you trade-in your current set of roles, privileges, and responsibilities for a new, special Alumni role (which comes with its own set of Privileges, as described above).
As a Maintainer (L2 or above) you can retire your role at any time by pinging the project 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 project. Or, if you have gone several months without interacting with the Astro community, the project Steward may actively reach out to you to discuss retiring as a way to make room for new contributors.
As an Alumni member, you are still a part of the Astro community and can continue to be a part of our Discord, GitHub, and anywhere else. You may also request to have your old roles reinstated at any time through the normal nomination & voting process for that role.
Rejoining the project as a contributor (L1 or above) will automatically remove you from the Alumni role.
Certain project decisions (like governance changes and membership nominations) require a vote. Below are the changes that require a vote, and the rules that govern that vote.
The project Steward may initiate a vote for any unlisted project decision. [General Rules](#general-rules) will apply, along with any addition rules provided at the steward's discretion. If this unlisted project decision is expected to be repeated in the future, voting rules should be agreed on and then added to this document.
This process kicks off once a valid nomination has been made. See ["Maintainer - Nomination Process"](#nomination-process) above for more details on nomination.
**Who can vote:** All Maintainers (L2 and above).
1. A vote thread should be created in Discord #maintainers channel (the private channel for all maintainers).
9.**If the vote fails:** the project Steward is responsible for informing the nominee with constructive, actionable feedback. (Note: this is not required if the nomination was made in the `#core` channel, or if the nominee was otherwise not made aware of their nomination).
#### Draft message to send to accepted maintainer, informing them of the decision:
```
Hey ${NAME}!
**I have some exciting news — you've been given the role of L2 Contributor (aka Maintainer/Moderator) in the Astro community!**
Some background: I nominated you for the role in the (private) #maintainers channel, and the consensus was overwhelmingly positive. Some quotes from the nomination thread that sum up the impact you've already had on the project so far:
- ...
- ...
- ...
Thank you for ${1 SENTENCE DESCRIPTION OF CONTRIBUTIONS}. Your impact has definitely been felt and we would be thrilled to have your help building a healthy future for Astro! There is no required time commitment: you can continue to contribute as often or as little as you'd like. This is mainly a chance to recognize your contributions and give you more privileges in Discord and GitHub.
Please let me know if you’re interested in accepting this invitation. If so, we’ll start getting your roles up to date. And if you have any questions, feel free to let me know.
*PS: As a reminder, our Governance document describes the following privileges and responsibilities for the **L2 - Maintainer** role: https://github.com/withastro/astro/blob/main/GOVERNANCE.md*
This process kicks off once a valid nomination has been made. See ["Core Member - Nomination Process"](#nomination-process) above for more details on nomination.
9.**If the vote fails:** the project Steward is responsible for informing the nominee with constructive, actionable feedback. (Note: this is not required if the nomination was made in the #core channel, or if the nominee was otherwise not made aware of their nomination).
I have some exciting news—you’ve been nominated and accepted as a member of the Astro Core team! The Core team held a vote and overwhelmingly agree that you would be a great addition to the team. Congratulations! Thanks for all of your significant contributions to Astro to date and your continued dedication to this project and our community. We would be thrilled to have your help ensuring a healthy future for Astro!
If the pull request submitter is not a Core Member, the PR can be closed by any Maintainer 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 (L3 and above). All Maintainers are encouraged to discuss and voice their opinion in the pull request discussion. Core members should take the opinions of Maintainers into consideration when voting.
1. The pull request discussion thread is used to discuss the governance change.
2. 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.
3. Voting can be done in the pull request via a review of either **Approve (For)** or **Change Requested (Against)**.
4. The vote must receive a simple majority (50%+) to pass.
5.**If the vote passes:** the PR is merged and the changes take effect immediately.
6.**If the vote fails:** the PR is closed and no change occurs.
## Voting: RFC Proposals
Astro features are discussed using a model called [Consensus-seeking decision-making](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making). This model attempts to achieve consensus on all significant changes to Astro, but has a fallback voting procedure in place if consensus appears unattainable.
2. A trivial change can be discussed and approved entirely within the RFC GitHub issue, as long as there are no objections from Core or TSC members. This is not considered a formal vote.
3. A non-trivial, significant change should be discussed within the RFC and approved during an RFC meeting call. In some cases, an RFC may be approved outside of an RFC meeting using Pull Request reviews as a proxy for votes.
4. During an RFC meeting, the person leading the call will attempt to achieve consensus on the RFC proposal.
6.**If consensus is not reached:** The RFC author and TSC members must make all reasonable attempts to resolve issues and reach consensusin GitHub or a follow-up RFC meeting. The process of reaching consensus can take time, and should not be rushed as long as all participants are making a reasonable effort to respond.
7.**If consensus still cannot be reached:** The project Steward may invoke [rough consensus](https://en.wikipedia.org/wiki/Rough_consensus) to resolve an RFC that has not achieved absolute consensus, as described below (borrowed from the [IETF](https://datatracker.ietf.org/doc/html/rfc2418)):
> Working groups make decisions through a "rough consensus" process. Astro consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the TSC shall prevail. (However, "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement). Consensus can be determined by a show of hands, humming, or any other means on which the TSC agrees (by rough consensus, of course). Note that 51% of the TSC does not qualify as "rough consensus" and 99% is better than rough. It is up to the project Steward to determine if rough consensus has been reached.
Inspired by [ESLint](https://eslint.org/docs/6.0.0/maintainer-guide/governance), [Rome](https://github.com/rome/tools/blob/main/GOVERNANCE.md) and [Blitz](https://blitzjs.com/docs/maintainers).
