2Ix Volunteer Matching And Project Memory System Design - Source Excerpt 02 - Matching mechanics and workflows

Back to 2Ix Volunteer Matching And Project Memory System Design

Summary

This source excerpt begins near Matching mechanics and workflows 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

| 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 |
| `start_window_open` | datetime | Yes | Earliest start |
| `start_window_close` | datetime | No | Latest acceptable start |
| `target_due_at` | datetime | No | Preferred finish date |
| `team_size` | integer | Yes | Default 1; larger for team projects |
| `beginner_friendly` | boolean | Yes | Equivalent to `good first issue` intent |
| `prerequisites` | array<object> | Yes | `{type, text, hard_filter}` e.g. background knowledge, access, training, legal |
| `access_requirements` | array<string> | No | GitHub org, Slack, docs, VPN, etc. |
| `deliverables` | array<object> | Yes | Named outputs with format and owner |
| `acceptance_criteria` | array<string> | Yes | Definition of done |
| `review_mode` | enum | Yes | `none`, `maintainer_approval`, `reviewer_approval`, `dual_approval` |
| `maintainer_id` | UUID | Yes | Primary maintainer |
| `reviewer_ids` | array<UUID> | No | Assigned reviewers |
| `starter_context_md` | markdown | Yes | What the volunteer needs before applying |
| `external_links` | array<object> | Yes | Repo/issues/docs/discussions/design links |
| `artifact_expectations` | array<string> | No | Files or links expected at completion |
| `ip_mode` | enum | Yes | `project_license`, `work_for_hire`, `cc_by`, `custom` |
| `response_sla_hours` | integer | Yes | Maintainer response expectation |
| `check_in_cadence_days` | integer | Yes | Expected update interval |
| `matching_preferences` | object | No | Preferred experience level, async vs sync, cause alignment, etc. |
| `risk_level` | enum | Yes | `low`, `moderate`, `high` |
| `safety_flags` | array<string> | No | Sensitive data, minors, legal review, security-sensitive |

This schema is directly motivated by Idealist’s searchable filters, Catchafire’s pre-scoped projects with prerequisites, samples, and outcomes, and GitHub’s structured issue forms and custom project metadata. The most important product decision here is **not** the field list itself, but that these are typed fields rather than prose fragments. citeturn16view3turn20view1turn20view3turn16view4turn17view1turn23view1

The scope taxonomy should stay intentionally small.

| Scope | Default use case | Effort band | Interview default |
|---|---|---:|---|
| Advisory call | Brainstorming, triage, consultation | 1–2 hours | Not required |
| Microtask | Small doc fix, tagging, issue triage, asset cleanup | 1–8 hours | Not required |
| Compact task | A bounded deliverable such as a setup guide, page redesign, bug fix | 1–2 weeks | Optional |
| Project | Multi-step deliverable with asynchronous work | 2–6 weeks | Usually required |
| Team project | Work needing several volunteers or mixed skills | Variable | Required |

That distinction follows Catchafire’s official split between 1-hour calls and larger scoped projects, while preserving GitHub-style “good first issue” work as the natural entry point for newcomers. citeturn20view3turn17view0turn18view2

Tagging should also be normalized. Every opportunity should support machine-readable tags in five families: **skill**, **work type**, **mission/cause**, **logistics**, and **difficulty/governance**. Example tags: `frontend-react`, `docs-writing`, `translation`, `civic-tech`, `education`, `remote`, `async-friendly`, `us-timezones`, `good-first-task`, `urgent`, `security-sensitive`, `review-needed`. This allows both faceted search and explainable recommendations. Idealist’s visible filters and GitHub’s label-driven discovery show why this matters. citeturn16view3turn17view0turn4search2

## Matching mechanics and workflows

The right matching model for 2ix is **hybrid**, but with a clear bias: **pull-first, push-assisted**. In practice, volunteers should be able to browse and apply freely, while maintainers can invite likely fits and the system can suggest candidates on both sides. This combines the openness of GitHub issue discovery with the efficiency of skills-based matchmaking, and it matches Catchafire’s official combination of open marketplace behavior, organization-side volunteer requests, and newer two-way matching. citeturn16view1turn16view2turn17view0turn18view4

| Matching design | Strengths | Weaknesses | Best use | Recommendation |
|---|---|---|---|---|
| Push-only | Fast staffing for urgent roles; orgs control funnel | Feels closed; weak for newcomers; less serendipity | Sensitive or high-risk tasks | Support, but only as an override mode |
| Pull-only | Open and transparent; great for self-directed contributors | Maintainers must sift through more noise; weak for passive but relevant candidates | Open-source style contribution discovery | Make this the default browsing model |
| Hybrid | Highest total liquidity; supports both browsing and invitations; preserves openness while improving fill rate | More complex ranking and notification policy | Skills-based volunteer work and open-source contribution systems | **Recommended default for 2ix** |

The actual matching engine should run in **two stages**.