life-itself / life-itself/reasoncommons

Define and exercise the Research Group handoff into the Second Renaissance model

Open
#36 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
1
Forks
0
Avg merge
4h 59m
Merged PRs (30d)
11

Description

The Research Group's throughput is controlled, carefully deliberated updates to the Second Renaissance commons' model. This needs a visible handoff between distinct commons: research activity and a proposed change are not yet an accepted update in the receiving model.

## Work

- Agree who may propose, review and accept changes in the receiving commons; do not presume research-group membership grants movement-model authority.
- Define a substantive update as a coherent contribution to the model rather than each low-level node or edge edit. Record how corrections, withdrawals and duplicate submissions are counted.
- Preserve the research question, source excerpts, interpretations, objections and deliberation leading to the proposed change.
- Bind the handoff to an identified receiving-model version; handle rejection, revision and a changed target without silent overwrites.
- Record the resulting accepted update and link it back to the research work.
- Start with a manual linked handoff using existing capabilities if native cross-commons transfer is absent. Specify automation only after exercising the semantics.

## Acceptance criteria

One research case can be followed from its question through deliberation to an accepted, revised or rejected receiving-model decision. For an accepted case, both commons link to the exact update and receiving version, and the agreed throughput measure counts it once. Rejected or pending work remains visible but does not count as delivered throughput. A batch of technical edits is not inflated into multiple intellectual advances.

## Expected benefit and check

The group can show what intellectual progress reached the movement's model, why it was accepted and what remains uncertain. Review the case on a later visit. The controlled update is the group's chosen output measure; subsequent evidence can still challenge its quality.

Candidate material is available from the September 4 discussion, subject to appropriate access and fidelity to contributors' words. Related: #18, the broader unfinished forum-to-model protocol. This is a bounded working case of that ambition, not a claim that the entire protocol is complete.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with related issue #18 and the September 4 discussion, then map one research case through proposal, deliberation and the receiving-model decision. Exercise the manual linked handoff using existing capabilities. Done means accepted, revised or rejected work remains traceable, accepted cases link both commons to the exact update and receiving version, and throughput counts each substantive update once.

Written by the indexing model from the issue text.

Assessment

Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.