Quonauts 9

                          _                            __
 ___ _ _ ___ ___ ___  _ _| |_ ___    ___ _ ___ ___    /  \
| _ | | | _ |   | _ || | |  _|_ -|  |   | |   | -_|   \__|
|_  |__ |___|_|_|____|___|___|___|  |_|_|_|_|_|___|   ___/

Meta rules

This section details how the rules are to be applied to the game.


The definitions for terms listed here take precedence over their normal English meanings, however any terms defined in a specific section of the rules override these in the section in which they are defined and its subsections. A section may also define terms for use in the whole document.

Whenever the word “if” is used in the rules, it is to be interpreted as “if and only if”.


This document is not guaranteed to always be up-to-date as the game rules are modified, however it is the duty of all players to keep this document accurate as game rules are modified. Where this document disagrees with the game rules, players must follow the game rules as they are, rather than their description in this document.


In the case of a contradiction between clauses, the following criteria are to be considered in turn until a clear determination can be made as to which clause takes precedence:

Disallowed by default

Unless explicitly stated in the rules, all game actions are forbidden.

Forbidden actions

Any game action that is forbidden (or a “rule violation”) is considered void and does not modify the game state; the action and its consequences are to be reverted.


Unless otherwise specified, all times and dates are specified with respect to UTC.


Certain game functions may be performed automatically by automated “bots”; the behavior of such bots is not governed by the rules, and any function that bots may perform should be feasible, even if inconvenient, to do manually.

Style conventions

This section and its subsections describe grammatical and stylistic conventions used throughout this ruleset.

Any player may edit the rules to conform to these style conventions. Edits made this way must otherwise be minimal; i.e. they may not change wording or meaning. Note that the meaning of other, linked rule sections must not be changed by such an edit.


Headers and tags


Within a given list, all elements should have the same style, chosen from the following:


From GitHub’s “Mastering Markdown” document, the following may be used:

Additionally, square brackets [] containing a tag will be converted into links to another rule section; e.g. [%rule-tag]. Discord mentions (@username, @role, and #channel) may be used, however they are not readable in GitHub-flavored markdown.


Each subsection of this rule section corresponds to a game channel; as the subsections are created, removed, renamed, or reordered, game channels must be created/removed/renamed/reordered accordingly.


Players may talk freely in the #general channel.


Proposals can be made by posting them to the #proposals game channel.

The first proposal is numbered #1 and each subsequent proposal’s number is increased by 1. Deleted proposals retain their number.

A proposal is either open or closed. When it is first submitted a proposal is open. A closed proposal is either passed or failed. When a player closes a proposal, they must either pass it or fail it. A deleted proposal is closed, but does not pass or fail.

Proposal content

A proposal must describe one or more actions that make changes to the game rules or otherwise alter the game state.

A proposal must not reference information outside of the game state, or propose a rule that does so.

If a proposal describes a modification to the rules, it must unambiguously specify the rule section(s) to be modified and how they will be modified.

If a proposal describes the creation of a new rule section, it must specify its title, its location in relation to an existing one, and its content.

Conflict resolution

If multiple proposals describe the modification or addition of sections, paragraphs, or sentences to the same part of the rules, conflicts should be resolved based on the age of the proposal, such that the newer proposal’s effect overrides the older one’s. For example, if proposal #10 adds a new section “A” to the bottom of the rules, and proposal #11 adds a new section “B” to the bottom of the rules, and both proposals pass, then regardless of which proposal passed first, section “B” will appear below section “A” in the rules.

Dependency resolution

A proposal may state that it depends on other proposals, meaning that proposal will fail if any proposal it depends on passes.

A proposal may also state it is incompatible with other proposals, in which case that proposal will fail if any proposal it is incompatible with passes.

Voting on proposals

Each player may cast one vote on each open proposal.

Players may vote in favour of (vote “for”) a proposal by reacting to the proposal with :thumbsup:, vote against by reacting with :thumbsdown:, or abstain from voting by reacting with :person_shrugging:.

A player may change their vote on an open proposal at any time.

Closing proposals

Any player may close an open proposal if one or more of the following conditions is met:

Passing and failing proposals

When a proposal is closed, it passes if it has more votes in favour than against; otherwise, it fails.

The player that authored a proposal may fail it at any time.

After a proposal passes, the game state and game rules change are modified according to it. The player who passed it must carry out the effects of its passing to the best of their ability.

The rules may only change as the result of a proposal passing.

Deleting proposals

The author of an open proposal may delete it at any time.

Editing proposals

A player may freely edit a proposal they have submitted if that proposal is open for voting and has no votes cast by players other than its author.

The author of a proposal or the player passing a proposal may choose to add or remove whitespace and fix typos or grammar mistakes, as long as the meaning of the proposal and any dependent proposals remains unchanged. Clarifications or additional details should always be added by a new proposal.


The #rules channel contains this rules document.


A poll is a means of gathering the opinions of players on an issue. Players may conduct a poll by providing any necessary detail and posting a question in the #polls game channel.

Players may vote in favour of (vote “for”) a poll by reacting to the poll with :thumbsup:, vote against a poll by reacting with :thumbsdown:, or abstain from voting by reacting with :person_shrugging:.

The player that posted a poll may edit it freely, as long as such edits do not change the meaning/intent of any existing reactions to the poll.