Lix Governance

Lix has three overlapping circles of responsibility: The core team is the primary governance body of the Lix project. The community team is the secondary governance body of the Lix project. The committers are the set of all people who have "+2" permissions on the Lix code base and thus can approve changesMoved to be merged.https://lix.systems/governance/

Primary focus How decisions are made Core team technical stewardship, project strategy, and conflict resolution consensus first; fallback to the governance mechanisms detailed below Community team culture, moderation, mediation (lazy) consensus Committers day-to-day code, docs, and CI changes review-based consensus; loose consensus rules unless escalated

The teams should mostly enable, not gatekeep. Decision making should default to community consensus wherever possible.

2. Core team

The core team:

Steers the overall direction and long-term goals of the project (vision) Makes decisions when community consensus can’t be reached Grants access to sensitive infrastructure and admin permissions Maintains project-wide policies, including this governance document Represents Lix in cross-project/community spaces

2.1 Joining the Core team

New members can be added via a core team vote. To be considered:

The person must have made sustained contributions (code, infra, docs, community, etc.) At least one current member should vouch for them They must agree to uphold the responsibilities of the team

2.2 Staying in the Core team

Core team members are expected to stay active. “Active” means contributing in some meaningful way at least once every 3 months:

Reviewing or driving technical work Participating in governance discussions or votes Maintaining infra, releases, docs, or community spaces Representing Lix publicly

After 3 months of inactivity, a member is marked inactive. They:

Stay listed as historical members Can return to active status by resuming regular contributions

After 6 months of inactivity, a member may be removed by vote.

2.3 Voting

Each core team member gets one vote Proposals pass with a 2/3-th majority of active members (unless otherwise specified) Votes happen via Matrix or another agreed-on platform

Governance-level decisions that require a vote include:

Major technical decisions for which the usual consensus-gathering mechanisms have failed Granting commit, infra or admin permissions Adding/removing core team members Changes to this document

3 Community team

The community team:

Is responsible for moderation and community management Proactively tries to mediate conflicts before they blow up Maintains the public presence of the project, on the home page and on social media Represents Lix in cross-project/community spaces, and takes care of outreach and public relations on social media

3.1 Joining the Community team

New members can be added via a community team vote. Full consensus of the community team is required. To be considered:

The person must be qualified to do the work of a typical online community moderator The person should be active and well connected in the community Unlike for the core team, regular code contributions are not expected

4. Committers

The committers:

Are entrusted with autonomy in areas where there's not enough help Coordinate current needs in their area of expertise with the core team Review CLs under their area of expertise Bring up difficulties in maintaining their area of expertise that arise, for example for lack of contributors, excessive churns, etc. Help triaging incoming issues Can help with responding to security incidents in Lix

Note that contributors may be declared as "code owners" of certain files or folders within the code base. Code owners are added to the reviewer rooster for those files, and have permission to merge changes affecting files they own. For the purpose of this document, only people with full merge rights on the entire code base are called "committers".

5. Interactions between the teams

Core team ⇄ community team

The core team and community team stay in close contact at all times, and work together on all issues where their responsibilities overlap. The core team consults the community team on decisions that materially affect contributor experience.

Core team ⇄ committers

Committers consult the core team on large-scale changes in the Lix project which may require strategic guidance and long-term vision. Every core team member is a committer. Committers can propose governance changes and may be nominated to the core team. When a technical dispute among committers cannot be resolved through usual review, it is escalated to the core team for binding resolution.

Committers ⇄ community team

Committers are encouraged to mentor newcomers. Committers can raise social issues they face to the Community team to get help.

Why this matters

Clarity — newcomers know whom to ask for what. Checks & balances — no single circle monopolizes influence. Pathways — active committers who gain trust and context have a clear route into governance.

The default rule: work happens in public, by the people closest to the code. Governance teams intervene only when consensus fails or strategic questions arise.

6. Technical conflict resolution

Occasionally, even experienced contributors disagree---especially when it comes to direction, tradeoffs, or prioritization.

Upon request of any contributor, the core team will help resolving technical disputes as follows:

First, seeking consensus in a public channel (e.g. Matrix or issue discussion). If unresolved, escalating to a time-boxed internal discussion (7 days max). If still unresolved, any core team member may call for a vote. The result of the vote (2/3-th majority required) becomes binding.

In particularly tricky cases, the team may choose to consult external experts or contributors most familiar with the code in question.

6.1 Fast-track decisions

For time-sensitive decisions:

Any core team member can propose a fast-track item A 48-hour discussion window opens If 2 other core team members approve and no objections are raised, the proposal passes

If there are objections, the issue moves to a full vote.

7. Transparency

Non-sensitive governance discussions happen in a public read-only channel Sensitive topics (security, conduct, etc.) can happen in private, but outcomes should be summarized publicly when appropriate

7.1 Town Halls

The core team holds quarterly town halls, open to the community.

Announced at least 7 days in advance Minutes are shared publicly afterward Anyone can attend and discuss; only core members vote

Final notes

This is version 1.1. It’s deliberately lightweight, and we expect to revise it as Lix grows. The goal isn’t perfection. Feedback welcome!

Changes to this document require:

a 2/3-th core team vote a minimum 7-day community comment period before voting