2Ix Volunteer Matching And Project Memory System Design

This report treats **2ix.org as a greenfield product specification**, not as an audit of an existing working site. During research on **May 19, 2026**, the 2ix.org homepage could not be reliably fetched by the web too...

Metadata

Field	Value
Source site	aiwikis.org
Source URL	https://aiwikis.org/
Canonical AIWikis URL	https://aiwikis.org/aiwikis/files/raw-system-archives-2ix-agent-file-handoff-retired-source-archive-2026-0-392b5e81/
Source reference	raw/system-archives/2ix/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-19-mvp-improvement/2ix Volunteer Matching and Project Memory System Design.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-19T16:49:53.0480475Z
Content hash	sha256:392b5e8169471815e6a01e9cdb34b5bfcdfec33ff1ff7acb0d3fe20b5963c739
Import status	unchanged
Raw source layer	data/sources/aiwikis/raw-system-archives-2ix-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-19-mvp-impr-392b5e816947.md
Normalized source layer	data/normalized/aiwikis/raw-system-archives-2ix-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-19-mvp-impr-392b5e816947.txt

Current File Content

Structure Preview

• 2ix Volunteer Matching and Project Memory System Design
• Executive summary
• Research basis and design stance
• User roles and opportunity schema
• Matching mechanics and workflows
• Durable project memory, data model, and APIs
• UI and UX flows
• Trust, privacy, moderation, metrics, and deployment

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 50217
• Preview characters: 11992

# 2ix Volunteer Matching and Project Memory System Design

## Executive summary

This report treats **2ix.org as a greenfield product specification**, not as an audit of an existing working site. During research on **May 19, 2026**, the 2ix.org homepage could not be reliably fetched by the web tool and returned timeouts on repeated attempts, so I do not assume any current production behavior beyond the domain name. citeturn1view0turn15view0

The strongest product direction is to build 2ix as **a hybrid volunteer marketplace plus a durable project-memory layer**. It should not be only a listing board, and it should not be only a wiki. Volunteer platforms such as Idealist/VolunteerMatch emphasize searchable opportunities by keyword, skill, cause area, and work format; Catchafire emphasizes **pre-scoped projects with clear outcomes, timelines, and explicit prerequisites**; GitHub and Google Summer of Code show that successful open-source onboarding depends on clear contribution guidelines, beginner-friendly issue labeling, maintainer review, structured work tracking, and fast human response. Those patterns point to a system where every opportunity is structured, every match is explainable, every contribution leaves a durable handoff trail, and every project can link outward to the real systems of record such as code, issues, and docs. citeturn16view3turn16view0turn16view1turn17view0turn18view1turn24view0turn16view10

The most important product decisions are summarized below.

| Design question | Recommended answer for 2ix | Why this is the right default |
|---|---|---|
| What is 2ix? | A **hybrid matching system** for volunteers and organizations, plus a **canonical memory layer** for project work | Volunteer platforms need discovery and matching; open-source work needs durable state, review, and handoff memory |
| How are opportunities created? | As **structured opportunities** with typed metadata, scope, prerequisites, deliverables, acceptance criteria, and links | Clear outcomes and structured intake reduce ambiguity and improve matching quality |
| How should matching work? | **Pull-first, push-assisted, hybrid**: volunteers browse/apply; maintainers can invite; the system recommends both directions | This combines the openness of issue browsing with the efficiency of skills-based invitations |
| How should project memory work? | A **hybrid federated model**: 2ix stores canonical task state, handoff notes, artifacts, and snapshots, while linking to code/issues/docs in external tools | GitHub-style work already lives across repositories, issues, PRs, and discussions; 2ix should unify that without copy-pasting entire ecosystems |
| How should roles work? | Four product roles: **volunteer, organization, project maintainer, reviewer**, with a separate admin/moderator function | This mirrors contributor/mentor/admin separation in successful open-source programs and preserves clear accountability |
| How should trust work? | **Verified organizations, structured reviews, project health checks, moderation tools, audit logs, and reputation that helps but does not lock out newcomers** | Fast, fair moderation and newcomer-friendly contribution paths are central to healthy communities |
| What should the technical shape be? | **REST-first API**, webhook connectors, relational core, event log, object storage, search index, and background workers | This is implementable without betting on a narrow stack and supports later federation and analytics |

A good first release of 2ix should therefore do seven things well: publish structured opportunities, calculate explainable matches, onboard volunteers into live projects, track assignment and review lifecycle, preserve handoff memory, integrate with external tools, and maintain community trust and safety. Those are the load-bearing capabilities for a system intended to serve **both volunteer matching and project continuity**. citeturn16view0turn20view1turn17view0turn17view2turn16view5turn16view9turn17view8

## Research basis and design stance

The external patterns that matter most for 2ix are remarkably consistent. **Idealist** exposes volunteering as a filterable search experience: keyword, skill, interest, radius, location type, cause area, and “done in a day” style constraints. Idealist also presents volunteering as a large multi-organization marketplace rather than a single-org dashboard. citeturn16view3

**Catchafire** adds the most useful operational discipline for 2ix. Its official documentation says projects are **pre-scoped** to create structure, timelines, and clear outcomes; volunteer selection uses algorithms factoring in skills, recent activity, similar completed projects, and ratings; organizations still vet candidates through application review and, when needed, interviews; and effective collaboration begins with a kickoff call, standing check-ins, and shared documents. Catchafire also distinguishes **small advisory calls** from larger fully scoped projects and, in newer flows, supports **two-way matching** where volunteers can originate proposals that organizations browse. These are exactly the right building blocks for a modern volunteer contribution system. citeturn16view0turn16view1turn20view1turn20view2turn20view3turn16view2

**GitHub** and **Open Source Guides** fill in the project-collaboration side. GitHub documents beginner-friendly discovery via `good first issue` and `help wanted`, structured issue forms with validations, `CONTRIBUTING.md`, community health files, code ownership and required reviews, Projects with custom fields and automation, Discussions for community conversations, and linked issues/PRs to show work in progress and automatically close issues on merge. Open Source Guides also stress that contributions are not only code: documentation, design, user support, and organizing are all valid contribution types. In other words, the best open-source systems lower the barrier to entry **and** keep a strong audit trail. citeturn17view0turn17view1turn18view1turn17view6turn17view3turn17view4turn16view5turn23view0turn22view0turn17view2turn18view0

**Google Summer of Code** contributes the best role and onboarding patterns. Its contributor/mentor/org-admin split makes responsibilities legible: contributors communicate progress and blockers, mentors guide and review regularly, and org admins define expectations, acceptance criteria, coverage, escalation paths, and integration into the community. The GSoC “community bonding period” is especially relevant for 2ix: onboarding works better when a contributor is introduced to the project, gets the development environment set up, reads the documentation, refines the plan, and starts on small preliminary tasks before being judged on large deliverables. citeturn24view0turn16view7

Taken together, these sources imply a very clear design stance for 2ix:

**First, 2ix should prefer scoped work over vague calls for help.** Catchafire’s explicit structuring of outcomes and timelines is the right model; free-text asks should be converted into typed opportunities before publication. citeturn16view0

**Second, 2ix should treat project readiness as a prerequisite for volunteer matching.** GitHub’s nonprofit “For Good First Issue” guidance expects active maintenance, a README, contribution guidelines, and beginner-friendly labels. A project without those basics is not yet ready to recruit volunteers effectively. citeturn18view3turn18view4turn18view1

**Third, 2ix should support more than code.** Documentation, design, research, translation, outreach, community moderation, and reviewing should all be first-class opportunity types, because that is how real open-source and civic work happens. citeturn18view0

**Fourth, 2ix should separate “discussion” from “opportunity.”** Early-stage ideas belong in discussion threads; once scope is clear, they should convert into structured work items. That mirrors GitHub Discussions and keeps the opportunity queue clean. citeturn22view0turn17view7

## User roles and opportunity schema

The core role split should be simple, but strict.

| Role | Primary responsibility | Can create | Can approve | Can review | Can moderate | Required account state |
|---|---|---|---|---|---|---|
| Volunteer | Offer time and skills to complete scoped work | Profile, applications, progress updates, artifacts, handoff drafts | No final project approvals | Peer comments only unless separately granted reviewer role | Report abuse only | Profile complete; prerequisites satisfied for each opportunity |
| Organization | Own the mission context, legal context, and project sponsorship | Organization profile, projects, policy defaults, maintainer/reviewer assignments | Project publication, volunteer selection policy, IP settings | Optional | No, unless also admin | Verified organization identity |
| Project Maintainer | Scope work, manage queue, guide volunteers, keep project moving | Opportunities, work items, labels, onboarding checklist, memory records | Applicant selection, assignment start, state transitions, handoff acceptance | Yes, if also reviewer | Limited moderation inside project spaces if granted | Maintainer training complete; MFA required |
| Reviewer | Evaluate deliverables against acceptance criteria and record structured feedback | Review records, approval/rejection notes, scorecards | Deliverable acceptance only | Yes | No, unless also moderator | Verified reviewer status; MFA required |

This role model is a practical translation of the contributor/mentor/admin structure documented by GSoC and the contributor/reviewer/code-owner patterns documented by GitHub. Contributors need clear expectations, maintainers need to guide and triage, reviewers need explicit approval authority, and the sponsoring organization must define policy and escalation. citeturn24view0turn17view3turn17view4

A key implementation rule is that **reviewer is a distinct permission**, even when a maintainer and reviewer are the same person on small projects. Keeping it separate in the data model is what lets 2ix later require independent approval on sensitive opportunities, just as GitHub supports required reviews and code-owner review requests. citeturn17view3turn17view4

The opportunity object should be fully structured. The schema below is the minimum viable shape.

| Field | Type | Required | Exact use |
|---|---|---:|---|
| `id` | UUID | Yes | Stable primary key |
| `organization_id` | UUID | Yes | Sponsoring organization |
| `project_id` | UUID | Yes | Parent project/workstream |
| `title` | string | Yes | One-sentence task name |
| `summary` | string | Yes | Card-level description, 160–280 chars |
| `description_md` | markdown | Yes | Full scope and context |
| `opportunity_type` | enum | Yes | `advisory_call`, `microtask`, `compact_task`, `project`, `team_project` |
| `visibility` | enum | Yes | `public`, `organization_only`, `invite_only`, `private_draft` |
| `status` | enum | Yes | `draft`, `review`, `published`, `paused`, `matched`, `active`, `completed`, `handoff`, `archived`, `canceled` |
| `cause_areas` | array<string> | Yes | Mission taxonomy: e.g. `civic-tech`, `education`, `accessibility` |
| `work_types` | array<string> | Yes | `code`, `docs`, `design`, `research`, `data`, `community`, `translation`, `review` |
| `skills_required` | array<object> | Yes | Each object: `{skill_key, level, weight}` |
| `skills_desired` | array<object> | No | Useful but non-blocking skills |
| `languages` | array<string> | No | Human-language requirements |
| `location_mode` | enum | Yes | `remote`, `hybrid`, `onsite` |
| `time_zone_overlap_hours` | integer | No | Minimum synchronous overlap if needed |
| `estimated_total_hours` | integer | Yes | Expected total effort |
| `estimated_hours_per_week` | integer | Yes | Expected weekly commitment |
| `duration_weeks` | integer | Yes | Expected elapsed duration |

Why This File Exists

This is a memory-system evidence file from aiwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: 2ix Volunteer Matching and Project Memory System Design; Executive summary; Research basis and design stance; User roles and opportunity schema; Matching mechanics and workflows; Durable project memory, data model, and APIs; UI and UX flows; Trust, privacy, moderation, metrics, and deployment. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-287 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "2Ix Volunteer Matching And Project Memory System Design",
    "source_site":  "aiwikis.org",
    "source_url":  "https://aiwikis.org/",
    "canonical_url":  "https://aiwikis.org/aiwikis/files/raw-system-archives-2ix-agent-file-handoff-retired-source-archive-2026-0-392b5e81/",
    "source_reference":  "raw/system-archives/2ix/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-19-mvp-improvement/2ix Volunteer Matching and Project Memory System Design.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:392b5e8169471815e6a01e9cdb34b5bfcdfec33ff1ff7acb0d3fe20b5963c739",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-19T16:49:53.0480475Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-287",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}