Contributing

Revision is open. Anyone may propose a change to the canonical text. The procedures here are an operational summary of the Governance section in FOUNDATIONAL.md; if the two ever conflict, the current tagged version of FOUNDATIONAL.md governs the canonical project.

#Proposing a change

1. Open a pull request against FOUNDATIONAL.md. Explain what you are changing and why. If the proposal comes from something learned in practice at a table, say so without disclosing private material.
2. Keep substantive discussion on the pull request or another linked public record so the reasoning and revision history remain visible.
3. Do not publish hard-truth disclosures, safeguarding reports, personal data, private correspondence, or security credentials in the name of openness.
4. Every adopted substantive change gets an entry in CHANGELOG.md and, when appropriate, a new version tag. Supporting files such as CARD.md, README.md, and READING.md should be updated in the same change when they would otherwise drift out of sync.

#What counts as an active table

For governance only, an active table is a recurring gathering of at least two people that has kept the weekly form in at least eight of the previous twelve weeks and whose participants are willing to attest publicly that the table exists.

No attendance list, belief test, donation, legal identity, or disclosure of hard-truth content is required. A recurring gathering counts once even when some participants attend other tables. Duplicate or sham tables created to gain governance weight may be disregarded under the honesty commitment.

#Bootstrap period

Before four active tables exist, the founder or current repository custodians may merge substantive revisions after:

1. publishing the proposal publicly;
2. leaving it open for at least 30 days of public comment; and
3. publishing a written rationale with the preserved diff when it is merged.

Obvious spelling, formatting, broken-link, source corrections that do not change meaning, credential emergencies, and security fixes may be handled immediately, with the change and reason published afterward.

Bootstrap authority is administrative and temporary. It gives no one authority over belief or over a local table. Once four active tables exist, the bootstrap period ends and cannot be restored merely because participation later falls.

#Revision after the bootstrap period

Anyone may propose a revision publicly.

For an ordinary substantive revision:

1. The proposal remains open for comment for at least 30 days.
2. Each active table may record one position: accept, reject, or no position.
3. At least half of all active tables must participate for quorum.
4. The revision is adopted when two-thirds of the participating tables accept it.

Changes to the structural governance safeguards require approval from three-quarters of all active tables, not merely three-quarters of those responding. These safeguards include:

• no clergy or standing spiritual rank;
• no treasury or private financial benefit from spiritual status;
• no coercive outside agenda;
• open forking;
• an open revision history; and
• the independence of local tables.

The dissolution clause may be strengthened but never weakened, qualified, or removed from the canonical text.

#Custody and access

During the bootstrap period, the founder or current custodians hold the domain and repository organization, with at least one named successor holding enough access to recover them if necessary. The successor is recorded publicly.

Once four active tables exist, owner-level access to the domain, repository organization, and directory infrastructure is held by at least three custodians from different active tables. Where supported, recovery should require more than one custodian. Custodians serve six-month terms, should not serve consecutive terms unless there is no practical alternative, and may be replaced by the tables at any time.

Custodians administer infrastructure and apply decisions made under the governance process. They do not define doctrine, discipline tables, certify spiritual legitimacy, or prevent forks.

#Safeguarding and private material

Repository governance is public; safeguarding is not a public spectacle.

Do not use issues, pull requests, discussions, or governance votes to publish identifying details of alleged abuse, hard-truth disclosures, medical information, private messages, information about children or vulnerable people, or other material whose publication could cause harm. Follow the safeguarding principles in FOUNDATIONAL.md: safety first, appropriate outside authorities or services where required, fact-checking without forced confrontation, and no retaliation for good-faith reporting.

Security incidents and exposed credentials may be handled privately first when necessary to contain harm, with an appropriate public record afterward that does not disclose exploitable details.

#The card

CARD.md should remain short enough to function as the portable form of the practice and should track the corresponding section of FOUNDATIONAL.md exactly in substance.

#Forks

Forks are welcome. CC0 material may be copied, changed, translated, republished, and redistributed. Forks are asked, but not legally required, to preserve the dissolution clause and to state clearly what they changed. A fork that weakens or removes the dissolution clause should not present itself as the canonical continuation of this project.

See LICENSE and NOTICE.md for license scope.