⚖️ Project Governance

👉 This file is included by default with all Bash-Bits repositories by virtue of its inclusion in the .github repository, which defines defaults for all other repositories under an organization.

Bash-Bits Governance Policy v-1.0.0

This document outlines the governance model for all Bash-Bits projects. This includes descriptions of different roles, nomination processes, code review processes, and Code of Conduct enforcement.

👉 ALL community members must abide by the Code of Conduct

👉 Please review the Community Support Document BEFORE posting

👉 Want to get involved in this project? Review the Contributor's Guide

👉 ALL contributors must be familiar with the project Security Policy

📖 TOC

Getting Involved
Governance Playbook
- Voting
- Moderation

💪 Getting Involved

ALL types of contribution are meaningful! Anyone can become a contributor to a Bash-Bits project (yes, even you!) Your contribution could be in the way of providing bugfixes, providing regular Discord activity, or even by posting about the project in your personal blog. No contribution is too small!

We aim to recognize ALL contributors to our projects, and use the All-Contributors bot to help capture and record contributions. See the Bash-Bits Contributor's Guide for more information.

📂 Contributor Levels

Generally, RedEyed Projects recognise four different levels of contributor, and each comes with a different set of privileges and responsibilities. You may also see these levels occasionally referred to as "Contributor Roles".

Contributor levels are available to ALL contributors, regardless of the type of contribution being made.

The two most important things we look for in a contributor are:

Presence: We recognise that everyone's time is valuable, and we very much appreciate that you're choosing to donate your valuable time to one (or more) of our projects. As mentioned previously, we aim to recognise ALL contributions, and consistent contributions will be rewarded with the granting of additional privileges.
Positive Community Involvement: The influence you bring to our communities matters a great deal. We want our project communities to be inclusive and welcoming for all, and your efforts to help us achieve these goals will not go unnoticed.

Once a level or role has been granted, it will remain with the member who earned it until they leave the project or graduate to a higher level. Only will the worst violations of our Code of Conduct cause a role or level to be revoked, and this is handled on a case-by-case basis.

Contributors can leave a project whenever they wish - however, in roles with the greatest levels of responsibility, we would appreciate that such exits are managed wherever possible.

🥉 Level 3 - Contributor

Everyone who makes a recognized contribution will be granted this role.

Privileges:

Discord Server Role: @contributor
Access to contributor-only content
Invitations to contributor-only events

Responsibilties:

This role does not come with any additional responsibilities or time commitments.

🥈 Level 2 - Maintainer

The role of Maintainer is granted to those who wish to join the team for a longer term and play an active part in the growth of a project.

Contributors who make repeated, regular contributions may be nominated for this role without the obligation of having to accept. (We advise those who wish to be nominated for this role to choose a speciality (or two) and make regular contributions to a project in those areas - your efforts WILL NOT go unnoticed.)

Maintainers are NOT required to write code! Some Maintainers will spend all of their time on the Discord Server helping to maintain a healthy project community. Others work on documentation, marketing, support, and many other areas.

The role of Maintainer is critical to the long-term health of a project. Maintainers are the first line of defense when it comes to the triage of new issues, the review and resolution of pull requests, and the provision of support and advice on our Discord Server. Maintainers are generally the "face" of a project, and are the people that visitors interact with the most on Discord or GitHub.

A Maintainer has moderation privileges! All Maintainers are entrusted with permissions to enable them to moderate our Discord Server and GitHub Repositories. 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.

Privileges:

All privileges of the @contributor role, plus ...
Invitation to the @maintainer role on Discord
Invitation to @mods role on Discord (optional, opt-in)
Access to maintainers-only content
Invitations to maintainers-only events
Moderation permissions at GitHub and on Discord
Permission to push directly to repos (no more private forks)
Permission to review GitHub PRs
Permission to merge selected GitHub PRs
Right to vote on selected project initiatives
Possibility of receiving financial stipend for funded projects (💲)

Responsibilities:

Expected to maintain good standing in the community
Expected to uphold & enforce Code of Conduct
Expected to be active on Discord
Expected to triage new issues at GitHub
Expected to review PRs at GitHub

Nomination:

To be nominated, a nominee is expected to already be performing some or all of the responsibilities of a Maintainer
Any existing Maintainer may nominate a Contributor for the role
Once nominated, a vote will be cast by existing Maintainers
Nominees receiving a clear majority of "YES" votes will be offered the role

🥇 Level 1 - Project Staff

Project Staff are community members who play a critical role in the long-term growth, direction, output of a project and its community. They are the project leaders and are looked up to by the rest of the project community - often before they have been granted this role in the project community. A Project Staff member is recognized for contributing a significant amount of time and energy to a project. In cases where a project is funded through sponsorship or otherwise, Project Staff Members will be in receipt of a financial stipend in recognition of their value to the project.

Privileges:

All the privileges of the @maintainer role, plus ...
Invitation to the @core role on Discord
Invitation to the @staff role on Discord (optional, opt-in)
Access to staff-only content
Invitations to staff-only events
Additional permissions at Github and on Discord
Right to cast multiple votes on most initiatives
Receives financial stipend for funded projects (💲)

Responsibilities:

All the responsibilities of the @maintainer role, plus
Expected to take ownership over specific part(s) of the project
Expected to contribute to the long-term health and success of Bash-Bits
Expected to be a role-model and leader for other maintainers and community members

Nomination:

To be nominated, a nominee is expected to already be performing some or all of the responsibilities of a Project Staff member
Any existing Project Staff member may nominate a Maintainer for the role
Once nominated, a vote will be cast by existing Project Staff Members
Nominees receiving a clear majority of "YES" votes will be offered the role

Special Role - Consulting Staff Member

A Consulting Staff Member is a special role which is limited in the following ways:

No voting rights
No ability to nominate
May be revoked at any time by the Project Head

Consulting Staff Members are usually brought in to work on or contribute to a specific part of a Bash-Bits project, often as a paid contractor.

A Consulting Staff Member may become a Project Staff Member through the usual nomination and voting procedures.

👑 Project Head / Technocrat

The Project Head or Technocrat role is usually only held by a single person in any project, but may be granted to multiple people on larger projects or under special circumstances.

This role is usually an administrative one. The Project Head or Technocrat is the Project Manager, and is responsible for the overall direction, growth and long-term success of a Bash-Bits project.

The Project Head or Technocrat controls and maintains any sensitive project assets, assists in resolving conflicts, and acts as the tiebreaker in the event of deadlocked initiatives.

In some cases, the Project Head or Technocrat can act unilaterally when they believe it is in the best interests of the project, providing they can show that the issue at hand cannot be resolved through normal governance procedures. The Project Head or Technocrat must publicly state their reason for unilateral action BEFORE taking it, and they must address any concerns or comments from project members on the matter.

When a project is first commenced, before it attracts any community members, the Project Head or Technocrat is the sole contributor and driving force of the project. At this stage it is their responsibility to build the project to a stage where a community can be built around it.

Privileges:

Holds either @project-head or @technocrat role on Discord
Super-User permissions at GitHub and on Discord
Defines overall project direction and goals
Receives a financial stipend from funded projects
Access to RedEyed Technologies Infrastructure

Responsibilities:

Determines global policies
May initiate votes
May veto votes and resolve voting deadlocks
Final word on moderation issues
Manages project sponsorship and funding
Manages project expenditure

Nomination:

Project Heads may not be self-nominated except under special circumstances
Only Project Staff Members are eligible
New Project Heads are added based upon a unanimous vote by existing Project Head(s)
In the event that a Project Head is unreachable, the decision will be deferred or decided by the Executive Office

⚖️ Executive Office

In all instances, executive power rests with Ragdata - the proprietor of RedEyed Technologies - and his direct assigns. However, he will guarantee that community members are empowered to exercise control over projects to the extent appropriate to the community's equity in those projects.

⭐ Additional Roles

In addition to the Contributor roles described above, there are additional roles and teams that community members and contributors are welcome to join. These roles are generally used to organize members around different requirements and initiatives across the Bash-Bits Community:

💫 Project Teams

For example, the following project teams are usually founded within projects as they grow to sufficient size:

@docs-team are responsible for producing technical documentation for a project
@i18n-team are responsible for translating a project into multiple languages
@support-squad are responsible for providing technical support for a project
@comms-team are responsible for a project's marketing efforts - such as maintaining websites, blogs, and designing email campaigns

As projects evolve and these teams form within them, you'll be able to join them by posting an application in the appropriate team forum on Discord. Getting involved with a team is a great way to start contributing to a Bash-Bits project!

🏅 Moderators

Moderator is a special role available to all Maintainers (L2) and above on an optional, opt-in basis via @mods. While all Maintainers are granted permissions to moderate for bad behaviour across our community, a Moderator actively takes on this responsibility. (For example, a community member may ping moderators (via the @mods role) to remove spam posts or handle Code of Conduct violations.)

Trivial tasks (like removing spam) can be acted upon unilaterally by a Moderator. Other, non-trivial tasks (like assisting with or resolving a Code of Conduct violation) should involve several members of the Moderator team (and, in some cases, the Project Head or Technocrat).

Privileges:

@mods role on Discord
Invitation to the private #moderators channel on Discord
Invitation to the mods team on GitHub

Nomination:

Any Maintainer (L2+) can self-nominate by messaging the Project Head or Technocrat on Discord.

🚧 Technical Steering Committee (TSC)

The TSC is a special role available to Project Staff Members (L1+). TSC members are responsible for the growth and maintenance of Bash-Bits projects.

TSC members are the guardians over the codebases of Bash-Bits projects. It is their duty to ensure code quality, enforce coding standards, correctness, and security.

A TSC member guides the direction of a project, and ensures the health of a project's codebase into the future. TSC members are ultimately responsible for technical decision making when it comes to any changes or additions to a project's codebase.

TSC members have significant sway in software design decisions. For this reason, coding experience is essential for this role. TSC membership is one of the few roles which requires a significant contribution history of code to a Bash-Bits project on GitHub.

Privileges:

@tsc role on Discord
Invitation to the private #tsc channel on Discord
Invitation to the tsc team on GitHub
Permission to merge ALL GitHub PRs for a project
Ability to vote on RFCs and technical initiatives

Responsibilities:

Expected to participate in RFC discussions & technical meetings
Expected to assist with design and implementation of non-trivial GitHub PRs
Expected to review and merge larger, non-trivial PRs
Expected to maintain and improve overall codebase architecture
Expected to track and ensure progress of all open PRs
Expected to mentor and guide other community contributors

Nomination:

To be nominated, a nominee is expected to already be performing most of the duties of a member of the TSC
May be nominated by any Project Staff member (L1+)
Once nominated, there will be a vote by existing TSC members
Nominees receiving a clear majority of "YES" votes will be offered the role

🚩 RedEyed Staff

The RedEyed Staff role is a special designation for employees of RedEyed Technologies

RedEyed Staff membership does not grant any additional privileges when it comes to voting or project governance. A staff member is still eligible for other roles within the community and may vote as determined by those roles. For example, a RedEyed Staff member who also has the @core role will be able to vote as any other Core Staff member would.

Privileges:

@staff role on Discord
Invitation to selected private channels on Discord
Invitation to staff team at GitHub (where appropriate)

💖 Alumni

Alumni is a special designation for Maintainers who have stepped away from a project and no longer contribute regularly. See Retiring a Role below for more information.

Privileges:

@alumni role on Discord
Invitation to the private #alumni channel on Discord

💥 Retiring a Role

Contributor roles are granted for as long as a person wishes to engage with a project. However, over time an active community member may choose to step away from a 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+) but is now no longer actively involved with a project. By retiring and joining the 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+), you can retire your role at any time by getting in touch with the Project Head or Technocrat 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 Bash-Bits community, a Project Head or the Technocrat 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 valued part of the Bash-Bits community and are welcome to continue to be a part of our discussions on Discord, GitHub, or anywhere else. You may also request to have your old roles reinstated at any time through the normal nomination and voting process for that role.

Rejoining a project as a contributor (L3+) will automatically remove you from the Alumni role.

📑 Governance Playbook

🙋 Voting

Certain decisions around a project (such as governance policy changes and membership nominations) require a vote. Below are described the situations which require a vote, and the rules which govern each vote.

The Project Head or Technocrat may initiate a vote for any unlisted project decision. General Rules apply where no specific rules are provided at the Project Head's or Technocrat's discretion. If this unlisted project decision is expected to be repeated in the future, voting rules should be agreed upon and then added to this policy document.

📑 General Voting Rules

Members may abstain from any vote
Members who do not cast a vote within 72 hours of the vote being called automatically abstain
Project Heads or the Technocrat may reduce the 72 hour window for urgent decisions
Project Heads or the Technocrat reserve the right to veto approval with a publicly disclosed reason

📑 Voting :: Role Nomination

This process is initiated once as valid nomination has been made.

WHO CAN VOTE: All current members holding the role in question

A vote thread should be created in the appropriate Discord channel
The vote thread can be created by any member holding the role in question or a higher-level role
Once the vote thread is created, existing members holding the role in question should discuss the nomination in private
The normal 72-hour voting and discussion window begins with the creation of the discussion thread
Votes can be cast in the discussion thread (visible to other voters) OR in private message to the Project Head or Technocrat
Once the vote is complete, the voting and discussion threads are deleted
The vote must receive a CLEAR MAJORITY (70%+) to pass
IF THE VOTE PASSES: the nominee will be offered the role in question and all privileges will be made available to them
IF THE VOTE FAILS: the Project Head or Technocrat is responsible for informing the nominee along with constructive, actionable feedback. (Note: this is not required if the nominee was not made aware of their nomination)

📑 Voting :: Governance Policy Change

A vote is initiated once a Pull Request to the GOVERNANCE.md file is submitted by a Core Staff Member.

If the PR submitter is NOT a Core Staff Member, the PR can be closed by any Maintainer without a vote. However, any Core Staff Member may request a vote on the PR, in which case a vote is initiated.

WHO CAN VOTE: Core Staff Members (L1+)

Maintainers are encouraged to discuss the matter and voice their opinion in the PR discussion thread.

Core Staff Members should take the opinions of Maintainers into consideration when voting.

The PR discussion thread is used to discuss the Governance Policy change.
The normal 72-hour voting and discussion window begins either with the creation of the PR, or the removal of WIP: from the PR title if the PR was created as a draft
Votes can be cast in the PR 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.

📑 Voting :: RFC Proposals

Bash-Bits project features are discussed using a model called consensus seeking decision making. This model attempts to achieve consensus on all significant changes to Bash-Bits projects, but has a fallback voting procedure in place if consensus appears unattainable.

WHO CAN VOTE: All TSC Members

Anyone can submit an RFC to suggest changes to a Bash-Bits project
A trivial change may be discussed and approved entirely within the RFC GitHub Issue, provided there are no objections from Core Staff or TSC members. This is not considered a formal vote.
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.
During an RFC meeting, the person leading the call will attempt to achieve consensus on the RFC proposal.
If consensus is reached: the RFC is approved
If consensus is not reached the RFC author and TSC members must make all reasonable attempts to resolve any issues and reach consensus in 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.
If consensus STILL cannot be reached: the Project Head or Technocrat may invoke rough consensus to resolve an RFC that has not achieved absolute consensus, as described below (borrowed from IETF)

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.

🚨 Moderation

Outlined below is the process for Code of Conduct violation reviews:

💬 Reporting

Anyone may report a Code of Conduct violation. Violations can be reported in the following ways:

In private, via email to one or more Project Heads or the Technocrat
In private, via direct messaging to a Project Head or the Technocrat on Discord
In public, via a GitHub comment (mentioning @mods or @staff)
In public, via the project channel on the Discord Server (mentioning @mods or @staff)

❓ Who Gets Involved?

Each report will be assigned to reviewers. Initially, these will all be Project Heads and / or the Technocrat

In the event of any conflict of interest - ie Project Heads who are personally connected to the situation, they must immediately recuse themselves.

At the request of the reporter and if deemed appropriate by the reviewers, another neutral third-party may be involved in the review and decision process.

⚖️ Review

If a report doesn't contain enough information, the reviewers will strive to obtain all relevant information before acting.

The reviewers will then review the incident and determine, to the best of their ability:

What happened
Whether this event constitutes a violation of the Code of Conduct
Who, if anyone, was involved in the violation
Whether this is an ongoing situation

The reviewers should aim to have a resolution agreed upon very rapidly; if not agreed upon within 7 days, they will inform the parties involved of the date they plan to have resolution agreed upon.

✅ Resolution

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 the GitHub Org and Discord Server
revocation of contributor role and status

Inspired by Astro