从项目想法到可验证交付
五个步骤，从一开始就结构化。
1. 发起人界定项目
从一个 GitHub 仓库开始。把工作拆分为任务卡，配上清晰的完成标准和 EWU 时间预算。每个任务都明确「完成」意味着什么——不靠感觉，而是针对特定仓库的具体交付物。准备好后即可发布。
2. 协作者发现并申请
开放任务会出现在任务市场上。协作者查看交付合约、了解范围，并申请与自身技能匹配的任务。在投入之前，他们就能看清任务的预期要求。
3. 分配席位
发起人评审申请并分配席位。每位协作者都清楚自己负责什么、何时到期。一旦被接受，他们会收到一份执行包：要 fork 的仓库、分支命名规范，以及 PR 要求。
4. 通过 GitHub 交付工作
协作者 fork 主仓库，创建分支、开发，然后开启一个 PR。他们提交完成报告，把 PR 与任务关联起来。平台通过 GitHub webhook 自动追踪提交活动、PR 状态与合并状态，无需手动更新状态。
5. 评审与验证生成记录
发起人对照标准评审 PR，可以通过、退回一次要求修改，或拒绝。每一个结果都会成为可验证记录——既写入发起人的项目，也计入协作者的档案。整个评审决定可追溯，并与具体提交绑定。
为什么不直接用 GitHub？
对于已经在一起协作的团队，GitHub 非常出色。它管理代码、PR 和评审。但它并不管理上游那一层：
- -谁申请了哪个任务
- -谁获得了席位
- -交付标准是什么
- -评审何时到期
- -什么算作可验证的贡献记录
GitHub 是证据层，Twig Loop 围绕它组织协作。二者解决的是同一问题的不同层面。
想试一试？
发布你的第一个项目，或浏览开放任务。每一份贡献都有 GitHub 证据支撑。