Establish three distinct commons and record their goals, throughput and authority

David has proposed three separate commons: Second Renaissance (the white papers and movement's work), Second Renaissance Research Group (deliberated updates to the movement model), and Reason Commons (development of the app, initially David and Rufus). Establishing these boundaries inside the application gives subsequent development a goal and prevents the three kinds of progress being conflated.

Work

• Find and reuse the existing Second Renaissance commons where appropriate; do not create a duplicate or overwrite its accepted model.
• Establish the Research Group and Reason Commons commons with their respective purpose, membership and decision authority.
• In Second Renaissance, record that throughput remains unsettled and capture the strong contender from its actual source for deliberation. Do not invent or ratify its wording.
• In the Research Group, operationalize throughput as controlled, deliberated updates to the Second Renaissance model: define the unit, substantive-change criteria, counting period and acceptance event. Drafts, proposals and cosmetic edits do not count as delivered updates.
• David and Rufus agree on the Reason Commons goal and provisional throughput definition inside its own commons. Neither issue closure nor code volume is presumed to be throughput.
• Connect the Reason Commons commons specifically to life-itself/reasoncommons, subject to confirming the existing connection and avoiding duplicate mappings. This is a repository connection, not ownership of a whole GitHub account.

Acceptance criteria

Each commons has a stable URL, a distinct purpose and an explicit throughput status (candidate or agreed). Agreed measures specify what is counted, over what period, and the observation source. Membership and authority are recorded. The app-development commons points to this repository, with the observed synchronization behavior documented.

Expected benefit and check

David and Rufus can identify which commons owns a contribution, decision and result without reconstructing the distinction from chat. Check this using one concrete example per commons before selecting the first development intervention.

This is setup and facilitated product use; any missing application capability should be recorded as a specific blocker, not treated as permission to ratify a definition automatically.

Start by inspecting the existing Second Renaissance commons and confirming its connection to life-itself/reasoncommons before creating anything. Establish the Research Group and Reason Commons with their purposes, membership, authority and throughput status, recording any missing application capability as a blocker. Done means each commons has a stable URL, explicit measures and one concrete example identifying its ownership.