Interactive
BreadWorld
Governance

The BreadWorld governing documents

The charter and community rules of BreadWorld.

Published 6 Oct 2026

Data snapshot · 17 Oct 2026, 01:33 UTC

The BreadWorld governance charter

Not in force Ratification draft 1.0-rc.1 Published 6 Oct 2026 Tag charter-v1.0-rc.1

A reading copy of the ratification draft; unreleased changes never appear here. If anything differs, the release on GitHub is authoritative.

Preamble #

This charter establishes shared governance between the administrators and the citizens of BreadWorld.

Its purpose is to ensure that important changes are made transparently and that no group may impose changes to this charter or the community rules without others having the opportunity to object.

The voting procedures in this charter apply to non-minor changes to governing documents and to the appointment and removal of administrators.

1 Definitions #

1.1 Administrator #

An administrator is a non-bot person who holds one of the administrative roles or permissions listed in Appendix A.

1.2 Citizen #

(1)A citizen is a non-bot person who is a member of at least one official platform of BreadWorld listed in Appendix A.

(2)A person who is a member of multiple official platforms remains one citizen.

1.3 Active citizen #

An active citizen is a citizen who has sent at least one message on an official platform during the 45 days before a vote begins.

1.4 Supermajority #

(1)A supermajority means that at least 65% of the valid votes cast either for or against a proposal or veto are in favor of it.

(2)Abstentions count toward participation but are not included when calculating a supermajority.

1.5 Official platform #

An official platform is a platform listed in Appendix A.

1.6 Bridge failure #

(1)A bridge is any software or service used to relay messages between official platforms.

(2)A bridge failure exists when an official platform has not been connected to Discord by a functioning bridge, directly or through another official platform, for more than 24 hours.

(3)A bridge failure ends when every official platform is again connected to Discord by a functioning bridge, directly or through another official platform.

1.7 Connected and disconnected platforms #

During a bridge failure:

(a)
the connected platforms are Discord and every official platform still connected to Discord by a functioning bridge, directly or through another official platform; and
(b)
the disconnected platforms are all other official platforms.

1.8 Announcement channel #

An announcement channel is a channel or room listed or described in Appendix A.

1.9 Governing document #

A governing document is:

(a)
this charter; or
(b)
the community rules.

1.10 Proposal #

A proposal is a suggested non-minor change to a governing document, or the appointment or removal of an administrator under Section 5.4.

1.11 Minor change #

A minor change is a correction or clarification that does not meaningfully change the purpose, effect, rights, obligations or interpretation of a governing document.

2 Proposing Changes #

2.1 Proposals by administrators #

(1)Any administrator may submit a proposal on behalf of the administrators. The proposal must include:

(a)
the complete wording of the proposed change or, for an appointment or removal, the person concerned; and
(b)
an explanation of its purpose.

(2)When an administrator submits a proposal:

(a)
the proposal must be published in the announcement channels;
(b)
administrators must begin a citizen veto vote on the proposal within seven days after it is published; and
(c)
the proposal may not take effect until the citizen veto vote closes.

(3)If the citizen veto vote does not begin within seven days, the proposal lapses.

(4)The proposal is rejected if the citizen veto vote:

(a)
meets the participation requirements in Section 3.6; and
(b)
receives a supermajority in favor of vetoing the proposal.

(5)Otherwise, the proposal is adopted when the citizen veto vote closes.

2.2 Proposals by citizens #

(1)Any citizen may submit a proposal by posting it publicly on an official platform. The proposal must include:

(a)
the complete wording of the proposed change or, for an appointment or removal, the person concerned; and
(b)
an explanation of its purpose.

(2)Before being placed to a vote, the proposal must receive public support from at least five citizens, including the person who submitted it. Support must be stated publicly on an official platform. If the wording of the proposal changes, support given to an earlier wording no longer counts.

(3)Once a proposal receives the required public support, administrators must begin the citizen vote within seven days.

(4)The proposal is approved by citizens if:

(a)
the vote meets the participation requirements in Section 3.6; and
(b)
the proposal receives a supermajority.

(5)After citizen approval, administrators must begin an administrator veto vote within seven days. If that vote does not begin within seven days, the proposal is adopted.

(6)The proposal is rejected if the administrator veto vote:

(a)
meets the participation requirement in Section 3.7; and
(b)
receives a supermajority in favor of vetoing the proposal.

(7)Otherwise, the proposal is adopted when the administrator veto vote closes.

2.3 Resubmission #

(1)A rejected or lapsed proposal may be submitted again later.

(2)It must complete the full proposal and voting process again.

2.4 Taking effect #

(1)An adopted proposal takes effect when it is adopted.

(2)Within seven days after a proposal is adopted, administrators must:

(a)
announce the adoption in the announcement channels; and
(b)
if the proposal changes a governing document, publish the new version under Section 6.

3 Voting #

3.1 Administration of votes #

(1)Official votes are organized and recorded by the administrators.

(2)The administrators must not alter a proposal, misrepresent a result, or refuse to publish a result.

3.2 Notice #

(1)Every official vote must be announced in the announcement channels on all official platforms.

(2)The announcement must include:

(a)
the complete proposal or veto question;
(b)
a short explanation; and
(c)
the closing time, stated in Coordinated Universal Time (UTC).

3.3 Duration #

A vote must remain open for at least 72 hours and no longer than 168 hours, except as provided in Section 3.11.

3.4 Wording and ballot options #

(1)The wording of a proposal may not be changed after voting begins.

(2)Every vote must allow each voter to vote in favor, vote against, or abstain.

3.5 Eligibility #

(1)Only citizens who are not administrators may vote in a citizen vote. Administrators are not counted when calculating the participation requirements for a citizen vote.

(2)Only administrators may vote in an administrator vote.

(3)Eligibility to vote, and the numbers used to calculate participation requirements, are fixed when a vote begins. A person who becomes a citizen or an administrator after a vote begins may not vote in it, and a change in the administrators after a vote begins does not affect that vote.

3.6 Citizen participation #

(1)A citizen vote is valid only if:

(a)
at least 50% of active citizens participate; and
(b)
at least the lesser of 10 citizens or 50% of all citizens participate.

(2)If either requirement is not met, the vote does not succeed.

3.7 Administrator participation #

An administrator vote is valid only if at least 65% of the administrators eligible to vote in it participate.

3.8 One person, one vote #

(1)A person may vote only once in each vote for which they are eligible, using one account on one official platform.

(2)If a person votes more than once in the same vote, all of their votes in that vote, including their first, are invalid.

3.9 Results #

(1)After a vote closes, the administrators must publish:

(a)
the number of eligible voters;
(b)
for a citizen vote, the number of active citizens;
(c)
the number of participants;
(d)
the number of votes in favor;
(e)
the number of votes against;
(f)
the number of abstentions;
(g)
whether the participation requirements were met;
(h)
whether a bridge failure was in effect and, if so, which platforms were connected; and
(i)
whether the proposal or veto succeeded.

(2)Individual votes do not need to be publicly identified unless the voting method was announced as public before voting began.

3.10 Finality of vetoes #

A veto cannot be vetoed.

3.11 Bridge failures #

While a bridge failure exists:

(a)
no official vote may begin, except as permitted by Section 3.12;
(b)
every official vote that was open when the bridge failure began remains open until at least 72 hours after the bridge failure ends, or until votes may begin again under Section 3.12, whichever is earlier, even if this exceeds the maximum duration in Section 3.3; and
(c)
the time during which no vote may begin does not count toward any deadline in this charter for beginning a vote.

3.12 Extended bridge failures #

(1)If a bridge failure lasts longer than seven days, official announcements and votes may be held only on the connected platforms until the bridge failure ends.

(2)Within seven days after this section begins to apply, administrators must post a single standing notice in the announcement channel of each disconnected platform. The notice must:

(a)
state that a bridge failure is in effect;
(b)
state that official announcements and votes are being held on the connected platforms until the bridge failure ends; and
(c)
include a working, non-expiring invitation to the Discord server.

(3)The standing notice must remain pinned or otherwise prominently visible until that platform is reconnected. No further announcements need to be posted on a disconnected platform while it remains disconnected.

(4)Votes may begin again 72 hours after the standing notice has been posted on every disconnected platform.

(5)While this section applies:

(a)
announcements on the connected platforms satisfy the notice requirements of Section 3.2;
(b)
the participation requirements in Section 3.6 are calculated using only citizens who are members of at least one connected platform; and
(c)
every vote must list the connected platforms in its announcement and results.

(6)A vote held under this section is invalid if a standing notice was not in place on every disconnected platform for its entire duration.

3.13 Review after restoration #

(1)When a disconnected platform is reconnected, administrators must remove its standing notice. When a bridge failure ends, administrators must announce this on all official platforms.

(2)If at least five citizens request it within 168 hours of that announcement, every administrator proposal adopted through a citizen veto vote held under Section 3.12 during that bridge failure must be reopened to a new citizen veto vote under Section 2.1.

(3)A reopened proposal remains in effect while the new citizen veto vote is held. If administrators do not begin the new vote within seven days after the request, or if the veto succeeds, the proposal is reversed and stops having effect.

4 Minor Changes and Emergency Changes #

4.1 Minor changes #

(1)Administrators may make minor changes without holding a vote.

(2)Every minor change must be:

(a)
announced in the announcement channels;
(b)
recorded in the revision history; and
(c)
accompanied by a short explanation of why it was considered minor.

(3)A minor change takes effect when it is announced, subject to Section 4.2.

4.2 Challenges to minor changes #

(1)If at least five citizens publicly challenge the classification of a change as minor on an official platform within 168 hours after it is announced, the change stops having effect, and administrators must remove it from the governing document within seven days.

(2)The change may then take effect only after completing the normal proposal process.

4.3 Emergency action #

Administrators may take immediate action when reasonably necessary to:

(a)
respond to raids, spam, compromised accounts, or security incidents;
(b)
protect the community or its members from immediate harm;
(c)
comply with applicable law; or
(d)
comply with the rules or technical requirements of an official platform.

4.4 Limits on emergency authority #

(1)Emergency authority does not allow administrators to permanently change a governing document without following the normal proposal process.

(2)Any temporary change to a governing document made under emergency authority must be announced in the announcement channels, with its reasons, as soon as reasonably possible.

(3)A temporary emergency change expires seven days after it is made unless:

(a)
the administrators renew it once, for up to seven further days, by announcing the reasons for renewal before it expires; or
(b)
it is adopted through the normal proposal process.

(4)Within seven days after the emergency ends, administrators must publish a review explaining why the change was needed and whether a permanent change will be proposed.

5 Rights and Responsibilities #

5.1 Rights of citizens #

Every citizen has the right to:

(a)
receive notice of proposals;
(b)
participate in citizen votes for which they are eligible, including citizen veto votes on proposals made by administrators;
(c)
propose changes under Section 2.2;
(d)
view the procedure, duration, thresholds, and results of every official vote;
(e)
have their vote counted equally;
(f)
criticize proposals and administrative decisions without retaliation; and
(g)
access the current version and revision history of each governing document.

5.2 Responsibilities of administrators #

Administrators are responsible for:

(a)
maintaining the official governing documents;
(b)
organizing votes required by this charter;
(c)
publishing accurate voting results;
(d)
enforcing adopted rules consistently; and
(e)
preserving voting and revision records.

5.3 No retaliation #

(1)No person may be punished for:

(a)
voting in a particular way;
(b)
proposing or supporting a proposal;
(c)
challenging the classification of a minor change; or
(d)
criticizing the community’s governance, proposals, or administrative decisions.

(2)This protection does not prevent moderation for conduct that violates the community rules.

5.4 Appointment and removal of administrators #

(1)The administrators holding office when this charter takes effect remain administrators.

(2)A person may be appointed as an administrator only through a proposal under Section 2.1 or Section 2.2. The person may not receive an administrative role or permission until the proposal is adopted.

(3)An administrator may resign at any time. Otherwise, an administrator may be removed only through a proposal under Section 2.1 or Section 2.2.

(4)When reasonably necessary under Section 4.3, such as when an account is compromised, administrators may temporarily suspend another administrator’s roles or permissions. The suspension must be announced in the announcement channels as soon as reasonably possible. It expires after seven days unless renewed once for stated reasons or made permanent through a proposal.

6 Publication and Official Versions #

6.1 Official source #

(1)The official source of this charter is https://github.com/ibreadorg/BreadWorld-governing-documents.

(2)The authoritative version is the charter source and PDF file included in the most recent GitHub release of this charter published under Section 6.2. A release of another governing document, or a GitHub pre-release, is not a release of this charter. If the rendered PDF conflicts with the source, the source controls.

(3)A change that has taken effect under Section 2.4 or Section 4.1 but has not yet been released applies as announced until it is released.

6.2 Published versions #

Each version that takes effect must be published as a GitHub release and must have:

(a)
a version number;
(b)
the date it took effect;
(c)
a published PDF; and
(d)
an entry in the revision history.

6.3 Drafts #

Draft files, pre-releases, ordinary commits, branches, pull requests, and unapproved proposals are not in force.

6.4 Precedence #

If the community rules conflict with this charter, this charter prevails.

Appendix A Official Platforms and Administrative Roles #

Discord

Server ID: 942993115130781718
Administrator role ID: 1354434862035243211
Announcement channel ID: 943333424796692500

Fluxer

Community ID: 1510933980231241728
Administrator role ID: 1510957638005821440
Announcement channel ID: 1512417926525751296

Matrix

Official space: #breadmoji:mozilla.org
Administrators: Members with power level 100 in the official space
Announcement room: Breadmoji announcements

Appendix B Revision History #

Version	Date	Commit	Summary
1.0-rc.1	2026-10-06	`5afb68cc`	Initial charter, for ratification

Licenses and attributions #

The charter text and rendered document may be distributed under the Creative Commons Attribution-ShareAlike 4.0 International License.

Software, build scripts, and reusable formatting code in the official repository may be distributed under the MIT License.

The cover artwork is Google Emoji Kitchen artwork. This asset is third-party material and is not licensed under the repository’s Creative Commons Attribution-ShareAlike 4.0 or MIT licenses. BreadWorld is not affiliated with or endorsed by Google. See the repository’s THIRD_PARTY_NOTICES.md for the attribution and the complete license texts included with release EPUBs and source archives.

The BreadWorld community rules

Not in force Ratification draft 1.0-rc.1 Published 6 Oct 2026 Tag rules-v1.0-rc.1

A reading copy of the ratification draft; unreleased changes never appear here. If anything differs, the release on GitHub is authoritative.

Purpose #

These rules help keep BreadWorld welcoming, respectful, and safe across its official platforms.

The additional rules in Section 2 apply to the legit-news channels identified in Appendix A.

1 Server Guidelines #

1.1
Respect all members.
A happy community is a respectful community. Hate speech, insults, bullying, harassment, and any other harmful material are not permitted.
1.2
Remain civil when discussing heated topics.
It’s a debate, not a fight.
1.3
Avoid sending spoilers outside of spoiler tags or threads.
This includes, but is not limited to: movies, books, and games. Especially if this is not something that would already be known by most fans, or is newly released.
1.4
Keep content on topic.
For example, memes are not allowed in general chat if they are not fitting for the conversation.
1.5
Spam is forbidden outside of the dedicated spam channel.
We know people need to be silly sometimes, and that’s why the channel exists: to keep disruption outside of the main chats.
1.6
No self-promotion unless it is related to the conversation.
Except in a dedicated self-promotion channel. This includes unsolicited DMs.
1.7
No asking for fundraisers or donations.
We cannot verify the legitimacy of such things.
1.8
No pornography or other content that is highly disturbing.
For example: extreme or realistic gore.

2 Additional Rules for legit-news #

Since legit-news is a channel that gets published to a public RSS feed, there are a few extra rules.

2.1
No AI-generated content.
Text, images, video, or audio generated with AI tools are not allowed, as legit-news encourages human creativity.
2.2
All posts must use markdown headers.
This is to reduce the amount of low-effort posts, and to make it easier for readers to skim the content.
2.3
No content that breaks Thai laws.
Bread, who hosts the RSS feed, is based there and would like to not get arrested.
2.4
No copyright infringement.
Do not post copyrighted material in a way that does not constitute fair use.
2.5
Do not chat/discuss outside of threads.
Replying to a message to add information is allowed. However, any discussion should be done in threads.

Tone indicators are discouraged in #legit-news.

Please don’t let low-effort posts outnumber your higher-effort ones.

Appendix A legit-news Channel Identifiers #

For the purposes of these rules, legit-news means the following channel or room on each platform.