How It Works

This page describes how the collective operates. The full governance documents are in the private member repository.

Membership

You join because someone already in the collective knows you and proposes your membership. The founder approves every invitation. There is no public application in the ordinary sense; the Join page exists for cases where someone has been told to apply and needs to send their details.

The person who proposed you is accountable for you. You eventually become accountable for the people you propose. The collective is closed: membership and internal records are visible to members only, and that is not expected to change.

The member agreement

Every member signs an agreement when they join. The core of it: contributions belong to the project they were made to, under that project’s licence; no individual member can claim them as personal property. The agreement applies to everyone equally, including the people who started the collective.

The full text lives in the member repository.

Projects

Starting one

A member proposes a new project to the collective. The proposal explains what the project is for and who it serves. After a comment period and the required approvals, the project is accepted and a repository is created.

Running one

The maintainer owns the direction. The maintainer chooses the technology, the architecture, the contributors, and the release schedule. Other members contribute by invitation from the maintainer.

Releasing one

When a project ships, it is published in its own public repository under the licence chosen by the maintainer. The release is permanent: it cannot be retracted, re-licensed under restrictive terms, or pulled back.

Ending one

A project without an active maintainer is reviewed and may be archived. Past releases stay valid forever.

Public process notes that do not belong on the Projects showroom page live on Project Process.

The review process

Each project sets its own day-to-day workflow - code style, branching, CI, what kinds of automated checks make sense for the language and the codebase. What is common to every project is the rule for what reaches a project’s main branch:

Every change merged to a project’s main branch goes through a deep human review by a member other than the author. The review covers what the change actually does, whether it matches the description, whether it introduces dependencies or behaviour the maintainer didn’t expect, and whether it is the kind of change the project should accept at all.

Maintainers may, and usually will, also use automated tools that fit their project - linters, static analysis, tests, secret scanning. Some projects may layer automated AI review on top of human review, especially for security-sensitive code. The collective does not prescribe a single toolchain; what it prescribes is that nothing reaches a project’s main branch without a member of the collective having read it carefully and signed off.

This applies to every project, every merge to main, always - including for the maintainer themselves and for the founder. A maintainer does not review their own merges.

Decisions

Most things are just commits. For bigger things:

All decisions are recorded permanently in the member repository.

What belongs to everyone

Every released project is open source under the licence chosen for it. The member agreement makes that permanent: no individual can retract or re-licence a shipped release.