Humanbased 将需要数据的人与能够采集、标注或核查数据的人连接起来。Developer（开发者）定义工作和质量要求，Contributor（贡献者）运用自己的知识完成工作，再由各自的记录跟踪验收、交付与收入。
Developer 是业务身份，不要求每个人都编写程序。任务负责人、课程作者、组织协作者和数据使用者都可能使用 Developer 端。
把活动理解为共同工作的项目
如果你熟悉 GitHub，可以把活动Developer 组织的一组数据工作及其相关设置理解为一个协作项目：它把说明、参与者、工作和结果放在一起。这个比喻帮助解释协作；具体权限、参与条件和验收仍按 Humanbased 的规则执行。
你不需要了解 GitHub 才能参与。先分清三个对象：
| 对象 | 它表示什么 | 你要核对什么 |
|---|---|---|
| 活动 | 围绕同一数据需求组织的工作与规则 | 要做什么、谁能参与、怎样验收 |
| Task | 这次实际领取或进入的具体工作 | 输入材料、操作要求和当前领取状态 |
| Submission | 交出工作后形成的记录 | 保存了什么、审核到哪一步 |
完整关系见核心概念。
从需求到结果
以一项虚构的图片分类工作，说明两端怎样围绕统一标准协作：
- 说明需要什么。 Developer 准备图片、分类标准与边界情况，明确预期答案。
- 准备工作方式。 配置人工步骤、回答字段、参与要求和质量检查，让完成工作的人与审核的人使用同一套标准。
- 完成工作。 符合条件的 Contributor 领取 TaskContributor 实际领取或进入的一项具体工作，按说明提交类别与所需材料。
- 查看审核结果。 根据活动配置的检查和验收方式处理 Submission一次提交形成的结果记录，参与者查看记录与反馈。
- 核对数据与收入。 Developer 检查交付及访问权限；Contributor 在 Earnings 查看实际收入。
每一步都有自己的记录。任务被接受、数据可以读取和奖励已经付款，需要分别确认。
用数据结果改进下一次工作
Developer 取回有权使用的数据后，按原来的需求检查准确性与覆盖范围。例如，图片已按任务标准验收，却发现“包装反光”缺少清楚的分类规则。下一轮可以修改说明、例子、表单或验收标准，再单独测试和发布。验收通过说明这次配置的检查已经完成，不证明模型效果自然提高；已有数据满足需求时，先按访问授权和实际记录继续使用。
选择你的起点
- 希望参与工作： 参与第一项工作，从选择活动到确认提交记录。
- 需要组织新的数据工作： 从数据需求开始，了解组织、任务配置与发布。
- 只需要已有数据： 获取已有数据，先确认内容、来源与访问条件，无需为了取数先创建活动。
- 需要程序接入： API 参考，核对凭证、订阅、请求与返回内容。
课程、资格与声誉按 Contributor 已记录的工作得出的 0–100 分，决定等级和奖励系数帮助解释准备情况和参与条件。只处理目标工作要求的项目，在相应页面核对具体结果。声誉反映已记录的工作表现；要求的课程结果和身份验证需要分别完成。验收、交付和付款各有自己的状态与记录。