Governance
This page is a summary of how the collective works. The full governance document, the member agreement, and decision records live in the private member repository.
The basics
Ardeshir is a volunteer collective of Iranian monarchists and friends of the Iranian nation. The collective has no board, no external funder, and no formal legal entity. Decisions happen through documented processes, recorded permanently in the member repository.
A founding steward holds final supervisory authority over the collective. The role exists to prevent sabotage, infiltration, capture, and external pressure - risks that are not theoretical, given who we are and who we work against. The steward operates within the same rules as every other member; every use of supervisory authority is logged where members can see it. The steward’s identity is not published and will not be - that is a structural protection for the entire collective, not personal anonymity.
Membership
Invite-only. Someone already in the collective proposes you. The founder approves the invitation. You sign the member agreement.
The invite chain is a permanent record visible to every member. It is not public, but it is authoritative within the collective: every member can trace every other member’s path in.
Projects
A member proposes a new project. After the comment period and required approvals, the project is accepted and a repository is created.
Each project has a maintainer who owns the direction, chooses the technology and the contributors, and sets the release schedule. Other members contribute by invitation from the maintainer.
When a project ships, it is published under its chosen open source licence in its own public repository.
Review
The collective’s rule on review is simple and applies to every project:
Nothing reaches a project’s main branch without a deep human review by a member of the collective other than the author.
Each project sets the rest of its workflow as the maintainer sees fit - code style, branching, CI, linters, tests, automated analysis. Some projects may add automated AI review for security-sensitive code. What is common to all projects is the human-review-on-merge rule, and it applies to maintainers and to the founder as well as to every other contributor.
Decisions
| What | Process |
|---|---|
| Normal change | Human review and merge |
| New project or new member | Comment period and required approvals |
| Policy or process change | Stricter process documented in the member repository |
| Emergency security action | Steward acts, logs within 24h, notifies members |
All significant decisions are recorded permanently in the member repository, with dates and approvers.
What cannot change
These rules are fixed. They can be amended only by a process so demanding that, in practice, it amounts to founding a new collective:
- Every merge to a project’s main branch is reviewed by a member of the collective other than the author.
- Released projects must remain published under their chosen open source licence; a release cannot be retracted or re-licensed under restrictive terms.
- The invite chain and decision log must be maintained and visible to every member.
- The orientation stated in the collective’s identity document is entrenched and cannot be quietly changed.
Ownership
Contributions belong to the project they were made to, under that project’s licence. No individual member can claim them as personal property. Every member signs an agreement to this effect when they join.
Released code is permanent. Once a project ships under an open source licence, no one - not the maintainer, not the steward, not a future court of opinion - can take it back from the people it was given to.