How this project is run

The situation

Let’s Recommon IT is a commons of writing, patterns, and code, run collectively from the start. If it can’t follow its own advice on governing commons, readers have no reason to. Right now one founding member wrote most of the content and holds every account, which is the situation Two Keyholders warns about. This document sets up shared decision-making while the group is small and changes are cheap.

It covers the collective-choice and constitutional levels: how the project’s rules are made and changed, and who makes them. The operational rules, for day-to-day work, are in the contributing guide. Why the project is organized in levels is in This repository is a commons.

Analysis

The project as an IAD action situation (Understanding Institutional Diversity):

IAD part	For this project
Participants	Members, contributors, readers
Positions	Member: shares in decisions and review. Keyholder: a member who holds admin access to an account. Contributor: submits work but doesn’t vote. Reader.
Actions	Contribute a piece or pattern to any cell of the table, review, merge, publish, change templates or structure, add threads, admit members, manage accounts
Information	Decisions and their reasons are recorded publicly in [decision log location], each linked to its proposal and the pull request that carried it out. Drafts are visible to members on GitHub.
Control	Merging to main publishes. Account access (GitHub, domain, hosting) controls everything else.
Outcomes	Published pieces, a growing pattern language, a healthy group
Costs & benefits	Costs: domain, hosting, time. Benefits: the work, the skills, the network.

Rules to decide

Operational rules: day-to-day work

Review, merging, and draft rules are in the contributing guide, where contributors use them. They’re made and changed under the collective-choice rules below.

Collective-choice rules: changing how the work is done

• Lazy consensus: changes to templates, threads, the table’s structure, or the operational rules are proposed in [issues / discussions]. A proposal passes if no member objects within [7] days.
• Objections go to the next members’ meeting, where the group looks for a version everyone can accept. If that fails, [two-thirds] of members decide.
• Meetings: members meet [monthly] by [video / in person]. Notes go in the decision log.

Constitutional rules: who decides, and how this ends

• Membership: a contributor becomes a member by [invitation from an existing member and consensus of members]. Members may step back at any time; their contributions stay under the project license.
• Charter changes require [consensus] of members at a meeting.
• Licensing: content stays CC BY-SA 4.0 and code stays MIT. These can’t be changed to non-free licenses. (CC BY-SA content can’t be relicensed without its authors’ consent anyway.)
• Dissolution: if the project ends, the repository is archived publicly, or handed to another commons-oriented group that agrees to keep the licenses. Domains and accounts are transferred or closed by the keyholders.

Keyholders

Every account the project depends on has at least two keyholders, who both use their access:

Account	Keyholders	Status
GitHub organization recommoning-tech	recommon-it (owner), jordaninskeep (owner)	Org created; repo transferred. Both owner accounts belong to the founding member, which guards against losing one account but not against losing the person. Action needed: a second member as owner.
Domain registrar	[member], [member]	Not yet registered
Hosting	[member], [member]	Not yet chosen
Shared password vault	[member], [member]	Not yet set up

AI assistance (proposed)

This project uses AI tools in drafting, and its own sources are critical of AI (Griziotti). The rule tries to keep people in charge of the writing:

• Contributors (A) must (D) note in the pull request (I) when a draft was substantially written with AI tools (C), or else the PR isn’t merged until they do (O).
• AI-drafted text stays status: draft until a member has rewritten or reviewed it in their own voice.
• Citations produced with AI help must be checked against a publisher or library record before publishing.

Risks and trade-offs

• Founder dominance: “collective from the start” is collective in name only if one person wrote everything and holds every account. Counter it with a second keyholder who is a different person, review by other members, and the first meeting’s review of founder-merged PRs.
• Consensus paralysis: lazy consensus with a deadline, and a fallback vote, keep decisions moving.
• Volunteer burnout: writing is visible; maintenance (fixing links, reviewing, renewing the domain) usually isn’t (Eghbal; Federici). Name the maintenance tasks and rotate them.
• Forks: CC BY-SA and MIT mean anyone can copy the project and go their own way. That’s a feature: exit is always possible, which keeps the group honest.
• Too much process for a small group: start with the operational rules and the keyholders table. Add the rest as the group grows.

Patterns introduced

Any Cell, Any Time

If the unit of contribution is a full set of theory, guide, and governance, only people with a lot of time can contribute, and they end up setting the direction. The action situation above makes “contribute a piece to any cell” an action open to every contributor, and the collective-choice rules decide which threads exist.

Therefore: accept a contribution to any single cell of the table at any time, without waiting for the rest of its row.

Patterns applied

• Every Thread at Every Level: this piece holds the collective-choice and constitutional rules; operational rules live in the guide.
• Every Page Links Out: an information rule. Each decision in the log links to its proposal and its pull request.
• Two Keyholders: the keyholders table, and the open action to add a second person as a GitHub owner.
• Talk Before You Enforce: objections go to a meeting before any vote; the only automatic consequence is reverting an unreviewed merge.
• Patterns Are Tested in Practice: this project is the first test of its own patterns. Problems found here should change the patterns.

Adopting the charter

The rules above are the charter. At the first members’ meeting, fill in the bracketed placeholders, record the date and the members present, and adopt it along with the operational rules. From then on it changes only under the constitutional rules.