Skip to content

Commit

Permalink
Add a governance document.
Browse files Browse the repository at this point in the history
  • Loading branch information
@alexanderson1993
alexanderson1993 committed Sep 27, 2021
1 parent b9d55ee commit df93104
Show file tree
Hide file tree
Showing 2 changed files with 293 additions and 0 deletions.
291 changes: 291 additions & 0 deletions GOVERNANCE.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,291 @@
# Thorium Governance

## Overview and Vision

Thorium Nova is a community driven project. That means contributions, including
concepts, code, art, money, and most importantly time, should come from the
broader community rather than any one person. There should always be the
possibility that even the most involved member can choose to leave the project
without fear that it will become unmaintained.

Community members will also have the opportunity to take leadership roles to
make decisions about the project goals, roadmap, execution and use of funds.

Being an open source project means someone could choose to fork Thorium and
start an entirely new project. In fact, this ability to fork is very important
to the health of open source communities. This is because it ensures that those
involved in project governance strive to make the right decisions for the
community.

## Roles and Responsibilities

### Users

Users are community members who have a need for the project. They are the most
important members of the community and without them the project would have no
purpose. Anyone can be a user; there are no special requirements.

The project asks its users to participate in the project and community as much
as possible. The best place to participate is
[Github Discussions](https://github.com/Thorium-Sim/thorium-nova/discussions)
and [Discord conversations](https://discord.gg/BxwXaUB). User contributions
enable the project team to ensure that they are satisfying the needs of those
users. Common user contributions include (but are not limited to):

- evangelizing about the project (e.g. a link on a website and word-of-mouth
awareness raising)
- informing developers of strengths and weaknesses from a new user perspective
- providing moral support (a "thank you" goes a long way)
- providing financial support (the software is open source, but someone has to
keep the lights on)

Users who continue to engage with the project and its community will often
become more and more involved. Such users may find themselves becoming
contributors, as described in the next section.

### Contributors

Contributors are community members who contribute in concrete ways to the
project. Anyone can become a contributor, and contributions can take many forms,
as detailed in the [contributing document](CONTRIBUTING.md). There is no
expectation of commitment to the project, no specific skill requirements and no
selection process.

In addition to their actions as users, contributors may also find themselves
doing one or more of the following:

- supporting new users (existing users are often the best people to support new
users)
- reporting bugs
- identifying requirements
- providing graphics and web design
- programming
- assisting with project infrastructure
- writing documentation
- fixing bugs
- adding features

Contributors engage with the project through
[Github issues](https://github.com/Thorium-Sim/thorium-nova/issues),
[Github Discussions](https://github.com/Thorium-Sim/thorium-nova/discussions) or
[Discord conversations](https://discord.gg/BxwXaUB). They submit changes to the
project itself via pull requests, which are reviewed according to the
[contributing guidelines](CONTRIBUTING.md).
[Discord](https://discord.gg/BxwXaUB) is the most appropriate place to ask for
help when making that first contribution.

After showing an interest, contributors are given commit access to the project
repo, which allows them to make changes to the codebase. While all code
contributions require a pull request review, andy contributor can review and
merge pull requests into the main branch.

Contributors will also receive a role on Discord, which makes it easier to send
messages specifically targeting them.

Anyone can become a contributor; there are no special requirements, other than
to have shown a willingness and ability to participate in the project as a team
player. Typically, a potential committer will need to show that they have an
understanding of the project, its objectives and its strategy.

A contributor who shows an above-average level of contribution to the project,
particularly with respect to its strategic direction and long-term health, may
be invited to become a member of the Core Team.

### Core Team

The Thorium Core Team is responsible for the vision and project direction for
Thorium. These responsibilities ensure the smooth running of the project. Core
Team members are expected to review code contributions, participate in strategic
planning, approve changes to the governance model, and make decisions regarding
project funds.

Members of the Core Team do not have significant authority over other members of
the community. It makes decisions when community consensus cannot be reached or
in legal matters.

Some Core Team discussions might happen in private. This is to handle sensitive
issues, such as banning community members and legal matters that cannot be
discussed in public. It is never used for project management or planning. To
facilitate this, Core Team members will have a special Discord role assigned to
them. They will also be expected to moderate the Thorium Discord server as
necessary.

Membership of the Core Team is by invitation from the existing Core Team
members. A nomination will result in discussion and then a vote by the existing
Core Team members. Core Team membership votes are subject to consensus approval
of the current Core Team members.

#### Core Team Lead

The Core Team Lead is a single individual, voted for by the Core Team members.
Once someone has been appointed Lead, they remain in that role until they choose
to retire, or the Core Team casts a two-thirds majority vote to remove them.

The Core Team Lead has no additional authority over other members of the Core
Team: the role is one of coordinator and facilitator. The Lead is also expected
to ensure that all governance processes are adhered to, and has the casting vote
when the Core Team fails to reach consensus.

## Support

All participants in the community are encouraged to provide support for new
users within the project infrastructure. This usually happens through
[Github Discussions](https://github.com/Thorium-Sim/thorium-nova/discussions)
and [Discord conversations](https://discord.gg/BxwXaUB). This support is
provided as a way of growing the community. Those seeking support should
recognize that all support activity within the project is voluntary and is
therefore provided as and when time allows.

## Decision Making Process

Decisions about the future of the project are made through discussion with all
members of the community, from the newest user to the most experienced Core Team
member. All non-sensitive project management discussion takes place through
[Github issues](https://github.com/Thorium-Sim/thorium-nova/issues) for most
features and bugs, and
[Github Discussions](https://github.com/Thorium-Sim/thorium-nova/discussions)
for larger features or strategic decisions. Occasionally, sensitive discussion
occurs through private conversation among Core Team members.

In order to ensure that the project is not bogged down by endless discussion and
continual voting, the project operates a policy of lazy consensus. This allows
the majority of decisions to be made without resorting to a formal vote.

### Lazy consensus

Decision making typically involves the following steps:

- Proposal
- Discussion
- Vote (if consensus is not reached through discussion)
- Decision

Any community member can make a proposal for consideration by the community. In
order to initiate a discussion about a new idea, they should
[file an issue](https://github.com/Thorium-Sim/thorium-nova/issues/new/choose)
or
[start a discussion](https://github.com/Thorium-Sim/thorium-nova/discussions/new).
This will prompt a review and, if necessary, a discussion of the idea. The goal
of this review and discussion is to gain approval for the contribution. Since
most people in the project community have a shared vision, there is often little
need for discussion in order to reach consensus.

In general, as long as nobody explicitly opposes a proposal, it is recognized as
having the support of the community. This is called lazy consensus - that is,
those who have not stated their opinion explicitly have implicitly agreed to the
implementation of the proposal.

Lazy consensus is a very important concept within the project. It is this
process that allows a large group of people to efficiently reach consensus, as
someone with no objections to a proposal need not spend time stating their
position. However, anyone can still provide suggestions or additional ideas to a
proposal without making an objection.

For lazy consensus to be effective, it is necessary to allow at least 48 hours
before assuming that there are no objections to the proposal. This requirement
ensures that everyone is given enough time to read, digest, and respond to the
proposal. This time period is chosen so as to be as inclusive as possible of all
participants, regardless of their location and time commitments.

During and after the consensus period, contributors should feel comfortable to
begin work to address a proposal. For example, small features or bug fixes are
likely to be approved and should be addressed as quickly as possible.

## Voting

Not all decisions can be made using lazy consensus. Issues such as those
affecting the strategic direction or legal standing of the project must gain
explicit approval in the form of a vote. Every member of the community is
encouraged to express their opinions in all discussion and all votes. However,
only project contributors and/or Core Team members have binding votes for the
purposes of decision making.

If a formal vote on a proposal is called (signalled by sending a message on the
Discord server with a link to a Github issue or discussion), all contributors
may express an opinion and vote. They do this by replying to the issue or
discussion including their vote:

- **Approve**: also willing to help bring about the proposed action.
- **Allow**: in favor, but not willing or able to help bring about the proposed
action.
- **Disagree**: but will not oppose the action’s going forward.
- **Reject**: opposes the action’s going forward and must propose an alternative
action to address the issue (or a justification for not addressing the issue).

To abstain from the vote, participants simply do not respond to discussion.
However, it can be more helpful to cast a **Allow** or **Disagree** than to
abstain, since this allows the team to gauge the general feeling of the
community if the proposal should be controversial.

Every member of the community, from interested user to the most active
developer, has a vote. The project encourages all members to express their
opinions in all discussion and all votes.

However, for some votes, only contributing members have binding votes for the
purposes of decision making. For others, only Core Team members vote is binding.

It is therefore their responsibility to ensure that the opinions of all
community members are considered. While not all members may have a binding vote,
a well-justified **Reject** from a non-contributor must be considered by the
community, and if appropriate, supported by a binding **Reject**.

A **Reject** can also indicate a veto, depending on the type of vote and who is
using it. Someone without a binding vote cannot veto a proposal, so in their
case a **Reject** would simply indicate an objection.

When a vote receives a **Reject**, it is the responsibility of the community as
a whole to address the objection. Such discussion will continue until the
objection is either rescinded, overruled (in the case of a non-binding veto) or
the proposal itself is altered in order to achieve consensus (possibly by
withdrawing it altogether). In the rare circumstance that consensus cannot be
achieved, the Core Team will decide the forward course of action.

In summary:

- Those who don’t agree with the proposal and think they have a better idea
should vote **Reject** and defend their counter-proposal.
- Those who don’t agree but don’t have a better idea should vote **Disagree**.
- Those who agree but will not actively assist in implementing the proposal
should vote **Allow**.
- Those who agree and will actively assist in implementing the proposal should
vote **Approve**.

### Types Of Approval

Different actions require different types of approval, ranging from lazy
consensus to a majority decision by the Core Team. These are summarized in the
table below. The section after the table describes which type of approval should
be used in common situations.

| **Type** | **Description** | **Duration** |
| :-----------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------: |
| Lazy consensus | An action with lazy consensus is implicitly allowed, unless a binding **Reject** vote is received. Depending on the type of action, a vote will then be called. Note that even though a binding **Reject** is required to prevent the action, all community members are encouraged to cast a **Reject** vote with supporting argument. Contributors are expected to evaluate the argument and, if necessary, support it with a binding **Reject**. | N/A |
| Lazy majority | A lazy majority vote requires more binding **Approve** votes than binding **Reject** votes. | 72 hours |
| Consensus approval | Consensus approval requires three binding **Approve** votes and no binding **Reject** votes. | 72 hours |
| Unanimous consensus | All of the binding votes that are cast are to be **Approve** and there can be no binding vetoes (**Reject**). | 120 hours |
| 2/3 majority | Some strategic actions require a 2/3 majority of Core Team members; in addition, 2/3 of the binding votes cast must be **Approve**. Such actions typically affect the foundation of the project (e.g. adopting a new codebase to replace an existing product). | 120 hours |

### When Is A Vote Required?

Every effort is made to allow the majority of decisions to be taken through lazy
consensus. That is, simply stating one’s intentions is assumed to be enough to
proceed, unless an objection is raised. However, some activities require a more
formal approval process in order to ensure fully transparent decision making.

The table below describes some of the actions that will require a vote. It also
identifies which type of vote should be called.

| **Action** | **Description** | **Approval type** |
| :----------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------: |
| Release plan | Defines the timetable and actions for a release. A release plan cannot be vetoed (hence lazy majority). | Lazy majority |
| Product release | When a release of one of the project’s products is ready, a vote is required to accept the release as an official release of the project. A release cannot be vetoed (hence lazy majority). | Lazy majority |
| New Core Team member | A new Core Team member has been proposed. | Consensus approval of the community |
| Core Team member removal | When removal of Core Team membership is sought. | Unanimous consensus of the community |

## License

_This document is based on the
[Meritocratic Governance Model](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
by Ross Gardler and Gabriel Hanganu. It is licensed under a
[Creative Commons Attribution-ShareAlike 4.0](https://creativecommons.org/licenses/by-sa/4.0/)
International License._
2 changes: 2 additions & 0 deletions client/src/components/QuoteOfTheDay.tsx
View file
Original file line number Diff line number Diff line change
Expand Up @@ -172,6 +172,8 @@ const quotes = [
"Free advice is seldom cheap.",
// Chaucer
"See yonder, lo, the Galaxy which men calleth the Milky Way, for it is white.",
// Dickens
"The Sun himself is weak when he first rises, and gathers strength and courage as the day gets on.",
];

const QuoteOfTheDay = () => {
Expand Down

0 comments on commit df93104

Please sign in to comment.