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.
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 and Discord conversations. 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 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. 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, Github Discussions or Discord conversations. They submit changes to the project itself via pull requests, which are reviewed according to the contributing guidelines. Discord 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.
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.
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.
All participants in the community are encouraged to provide support for new users within the project infrastructure. This usually happens through Github Discussions and Discord conversations. 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.
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 for most features and bugs, and Github 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.
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 or start a discussion. 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.
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.
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 |
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 |
This document is based on the Meritocratic Governance Model by Ross Gardler and Gabriel Hanganu. It is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.