2Ix Volunteer Matching And Project Memory System Design - Source Excerpt 03 - Durable project memory, data model, and APIs

Back to 2Ix Volunteer Matching And Project Memory System Design

Summary

This source excerpt begins near Durable project memory, data model, and APIs and preserves the surrounding evidence from 2IA.org/agent-file-handoff/Archive/2026-05-19-2ix-volunteer-platform-research/2ix Volunteer Matching and Project Memory System Design.md.

**Source path:** 2IA.org/agent-file-handoff/Archive/2026-05-19-2ix-volunteer-platform-research/2ix Volunteer Matching and Project Memory System Design.md

**Stage one: eligibility filtering.** This is hard yes/no gating. The volunteer must pass visibility rules, prerequisite rules, risk rules, required language/location rules, and any repository or safety access requirements. If a project is marked `security-sensitive` or `high`, the platform can require interview, MFA, past proven work, or manual approval. Catchafire’s application review flow and prerequisites screen are the right precedent here. citeturn20view1turn20view3

**Stage two: weighted ranking.** The ranking score should be transparent and stored alongside the recommendation.

' ' ' text
score_base =
  0.40 * skill_fit
+ 0.20 * availability_fit
+ 0.15 * contribution_similarity
+ 0.10 * explicit_preference_fit
+ 0.10 * reliability_score
+ 0.05 * recent_activity_score

adjustments =
+ newcomer_boost
- risk_penalty
- response_penalty
' ' ' 

Use the following exact mechanics:

| Signal | Exact implementation |
|---|---|
| `skill_fit` | Weighted match of required and desired skills. Required skills count more than desired. Skill levels should be ordinal: `familiar`, `working`, `strong`, `expert`. |
| `availability_fit` | Compare `estimated_hours_per_week`, `duration_weeks`, start window, and timezone-overlap requirement against volunteer availability. |
| `contribution_similarity` | Use prior completed work, attached portfolio links, repository history, or review history to estimate similarity to scope and deliverables. |
| `explicit_preference_fit` | Compare volunteer preferences on cause areas, work types, remote/on-site, sync/async, and languages to opportunity metadata. |
| `reliability_score` | Bayesian average of completion rate, reviewer ratings, check-in compliance, and no-show history. Start every new user at neutral, not low. |
| `recent_activity_score` | Reward current engagement lightly so dormant profiles do not dominate. |
| `newcomer_boost` | Add a small positive adjustment only on opportunities marked `beginner_friendly`, provided hard prerequisites are met. |
| `risk_penalty` | Penalize unresolved moderation flags, repeated unresponsiveness, or safety noncompliance. |
| `response_penalty` | Penalize maintainers or volunteers who regularly ignore applications or invitations, to improve marketplace hygiene. |

Two fairness rules should be hard-coded. **First, reputation must never be the main gate for beginner-friendly work**; otherwise the platform becomes a closed loop where incumbents get all the opportunities. GitHub’s `good first issue` pattern and CHAOSS’s newcomer-experience framing both argue for deliberate newcomer access. **Second, maintainers must be shown a match explanation, not a black-box score**, so they can override recommendations responsibly. citeturn17view0turn17view8

A good first-response policy is also essential. CHAOSS explicitly treats time to first response as a key signal of community health and newcomer retention, and Catchafire recommends organizations respond within two business days. For 2ix, I would make the product target **median first human response under 24 hours, P90 under 48 hours**, excluding bot responses from the metric. citeturn16view10turn20view1

The matching and onboarding flow should look like this:

' ' ' mermaid
sequenceDiagram
    participant V as Volunteer
    participant T as 2ix
    participant M as Maintainer
    participant R as Reviewer
    participant X as External Tools

    V->>T: Create profile, skills, availability, preferences
    T->>T: Check profile completeness and eligibility
    T->>V: Recommended opportunities with match reasons
    V->>T: Apply to opportunity
    T->>M: Notify application + ranked fit explanation
    M->>T: Review prerequisites, work samples, answers
    alt Interview required
        M->>V: Invite to interview
        V->>M: Attend interview / clarify scope
    else Low-risk scoped work
        M->>T: Start project directly
    end
    M->>T: Accept volunteer
    T->>X: Create/associate issue, task, discussion links
    T->>V: Onboarding checklist + kickoff agenda
    V->>M: Kickoff meeting
    T->>T: Create baseline task snapshot and check-in schedule
    V->>T: Progress updates + artifacts
    R->>T: Review deliverable
    T->>V: Approval, revisions, or handoff request
' ' ' 

The onboarding content itself should be structured, not improvised. The GSoC bonding model is a strong template: read the README and contribution guide, join the communication channel, gain repository/tool access, set up the environment, understand the work plan, and start with small preliminary tasks. GitHub’s community health files and contribution guidelines reinforce this. Therefore every new 2ix assignment should automatically generate an onboarding checklist with six required items: **project overview read, code of conduct acknowledged, access granted, environment/setup completed, kickoff held, first progress update submitted**. citeturn16view7turn18view1turn17view6

## Durable project memory, data model, and APIs

The central product insight is that **matching without memory creates volunteer churn**, and **memory without structured work creates stale documentation**. So 2ix should implement durable project memory as a **hybrid canonical ledger**: the platform stores canonical states, handoff notes, review records, artifact manifests, and snapshots of linked work, while still treating repositories, issue trackers, docs, and design tools as authoritative external evidence. GitHub Projects, linked issues/PRs, and discussions all point in this direction: real work spans multiple repositories and tools, but still benefits from a single cross-project planning surface with custom fields and automation. citeturn16view5turn17view2turn22view0turn23view0turn23view1

| Memory design | Benefits | Failure mode | Recommendation |
|---|---|---|---|
| Centralized copy-all memory | Simple reading experience inside 2ix; easy search | Diverges from source systems; high sync and privacy burden | Avoid as the default |
| Federated link-only memory | Lowest duplication; respects existing tools | Loses continuity when links rot or context moves; weak search | Better than copy-all, but incomplete |
| Hybrid canonical ledger plus linked artifacts | Keeps task continuity, review history, and handoff durability while preserving external systems of record | Slightly more modeling effort | **Recommended** |

The core model should distinguish five concepts:

| Entity | Meaning | Why it exists |
|---|---|---|
| `project` | Long-lived mission/workstream | Parent container for many opportunities and assignments |
| `opportunity` | Recruitable unit of work | What people browse, apply to, or are invited into |
| `assignment` | Binding between volunteer and opportunity | Tracks who is doing what and under what terms |
| `work_item` | Canonical tracked contribution unit | Holds status, versions, links, and state transitions |
| `handoff_packet` | Required continuity document | Prevents knowledge loss when work changes hands |

To make memory durable, `work_item` should use **versioned state plus append-only events**.

| Table | Minimum columns |
|---|---|
| `work_items` | `id`, `project_id`, `opportunity_id`, `current_state`, `current_version`, `current_assignee_id`, `maintainer_id`, `reviewer_id`, `risk_level`, `last_snapshot_at` |
| `work_item_versions` | `work_item_id`, `version_no`, `state`, `summary_md`, `blockers_md`, `next_steps_md`, `acceptance_state`, `created_by`, `created_at` |
| `work_item_events` | `id`, `work_item_id`, `event_type`, `payload_json`, `actor_id`, `created_at` |
| `handoff_packets` | `id`, `work_item_id`, `from_user_id`, `to_user_id`, `state_version`, `status`, `urgency`, `confidence`, `created_at`, `accepted_at` |
| `handoff_packet_versions` | `handoff_packet_id`, `version_no`, `context_md`, `what_changed_md`, `open_questions_md`, `blockers_md`, `recommended_next_actions_md`, `artifact_manifest_json` |
| `external_links` | `id`, `work_item_id`, `provider`, `kind`, `url`, `external_id`, `snapshot_title`, `snapshot_status`, `last_synced_at`, `content_hash` |
| `artifacts` | `id`, `work_item_id`, `kind`, `storage_key`, `mime_type`, `sha256`, `visibility`, `uploaded_by`, `created_at` |
| `reviews` | `id`, `assignment_id`, `reviewer_id`, `decision`, `criteria_scores_json`, `feedback_md`, `created_at` |
| `reputation_ledger` | `id`, `user_id`, `source_type`, `source_id`, `delta_json`, `created_at` |
| `moderation_cases` | `id`, `subject_user_id`, `reporter_id`, `context_type`, `status`, `decision`, `created_at`, `closed_at` |
| `audit_logs` | `id`, `actor_id`, `entity_type`, `entity_id`, `action`, `before_json`, `after_json`, `created_at` |