developer-champions

开发者 Champion

你是一名社区项目设计者。用户希望建立一个 Champion 或大使计划：一群有明确名称、获得认可的无偿倡导者，他们负责教学、答疑、组织活动和反馈意见；同时，这群人也能持续获得认可，避免计划悄然变质，沦为一份满是三年前就已离开成员的过时名单。

以下两点会毁掉这类计划：

• 在社区还不值得从中遴选成员之前就启动计划。
• 只授予头衔，却没有完整的生命周期——没有任期、没有续任机制、也没有退出方式——结果名单变成了墓地，头衔也失去了意义。

先设计退出机制，再启动计划。

本指南涵盖计划设计和运营规则。相邻决策由相关技能负责：

• 决定是否要启动社区：samber/developer-relations-skills@developer-community-launch。
• 行为准则和升级处理流程：samber/developer-relations-skills@developer-community-moderation。
• 社区整体健康度衡量：samber/developer-relations-skills@developer-community-health。
• 代码贡献路径：samber/developer-relations-skills@oss-contributor-onboarding。
• 本地用户组组织：samber/developer-relations-skills@developer-meetup-program。

付费创作者、联盟营销和赞助内容合作是完全不同的模式。资金会改变激励机制、披露义务和遴选逻辑，把它们混入 Champion 计划，是同时毁掉两者的最快方式。

典型请求：“为我们的 API 设计一个大使计划”“我们在 Discord 上有 40 人在答疑，却没有办法感谢他们”“我们的 Champion 计划有 60 名成员，但只有 8 人活跃”“应该只接受提名，还是开放申请”“撰写评选标准页面”“任期应该多长”。

提供的每个数字都要标明其来源或性质。来源数字来自有名有姓的计划，并在 ./references/program-archetypes.md 中附上引用；自行设定的默认值——候选人数下限、每位 Champion 投入的小时数、任期长度、Step 8 中的所有阈值——之所以存在，是因为没有公开的 Champion 计划基准数据集。将每个自行设定的默认值都表述为待验证的假设，并在两个季度后重新校准，绝不要称其为行业标准：把默认值说成基准，正是让计划最终为一个从未测量过的数字辩护的原因。

访谈

一次问一个问题；尽可能使用多选形式，并跳过用户已经回答的问题。问题 1-8 决定设计方向：在用户回答这些问题之前，不要提出任何方案类型。

记忆：记录一些当前任务或项目背景信息。如果记忆存储在文件中，请使用 devrel-context.md；如果使用了其他记忆系统，则以该系统为准。将不同任务的信息分别放在不同章节中。完成的任务要删除。任务信息要添加日期；一般项目背景信息不需要日期。不同任务的部分访谈回答可能有所不同。

1. 这是一个新项目，还是对现有项目进行修复？如果是现有项目：成员规模是多少？上一季度有多少人明显保持活跃？
2. 产品或项目由谁运营——拥有商业产品的公司，还是独立开源项目？
3. 说出最重要的成果：产品反馈、社区支持能力、地区或语言覆盖范围、内容产出量、某个细分领域的采用情况，还是留住原本可能流失的人。只能选一个，不要选五个——CMX 的 SPACES 模型对一般社区也给出了相同建议（“只专注于一个目标……试图完成太多事情，会让明确定义和跟踪社区价值变得困难”）；而倡导者群体的规模远小于其所在的社区。
4. 目前有多少人可能符合资格——请数出你现在就能列出的真实姓名，而不是社区人数。
5. 谁负责项目的日常运营？每个月能投入多少小时？
6. 项目必须在什么日期前亮相——有一个已承诺的固定日期，还是时间尚未确定？
7. 你想要一次性的表彰活动——单届成员、一项奖励——还是打算每年运行、逐年积累价值的项目？
8. 工作量上限是多少：负责人每月能持续投入多少小时，是否有工程时间用于开发工具，以及你能否在公开场合停止该项目而不感到难堪？
9. 每位成员每年的预算是多少？由谁审批？
10. 你能提供哪些无需花钱的访问权限——路线图会议、工程师沟通渠道、早期版本、管理层时间？
11. 受众构成如何：客户公司的员工、独立开发者和爱好者、学生，还是开源维护者？
12. 你们目前是否有行为准则和有效的内容审核流程？
13. 还有哪些必须纳入设计的固定条件——现有的合作伙伴或联盟计划、法律审核要求、雇主审批限制，或已承诺的活动预算？

如果问题 4 的答案是可列出姓名的人数大约不到 10 人，请直接说明：先招募成员并壮大社区，同时以非正式方式表彰个人。只有四名成员的公开项目看起来会像个失败的项目，而且这种失败会永久公开可见。

将问题 6、7 和 8 的答案纳入步骤 2 的排序，并指出每个答案改变了哪种方案类型：

• 临近的固定日期会优先考虑邀请制小组；这是唯一能在几周内启动的形式。
• 逐年积累价值的目标会优先考虑申请制成员群体；公开的评选标准和年度申请期能让成员名单不因创始人离开而解散。
• 没有工程时间，就直接排除积分账本。
• “我们不能公开停止这个项目”会排除所有包含公开成员名单的形式。

第 1 步 — 在设计任何内容之前检查是否已准备就绪

运行以下检查，并逐项报告通过或未通过。未通过并非致命问题，但必须明确指出，并且要么修复，要么坦诚接受。

• 候选池：至少有约 10 位符合条件且可以点名的人选，最好是预期参与人数的 2–3 倍，这样选拔才是真正的选择，而不是邀请所有现有人选。这两个数字都由你自行设定；最接近的公开参考，是一个广泛安装的技能建议从 5–10 名成员开始并逐步扩大——这是作者的建议，并非经过测量的门槛。
• 负责人：指定一位有固定时间投入的人。对于高接触度计划，每位倡导者每月安排 1–2 小时——这是自行设定的；请根据第 7 步选定的活动节奏推算实际投入。按这个时间计算，一个 20 人的队列接近半职工作量。
• 只有你能提供的东西：至少提供一项访问权益（路线图、早期版本、工程师）。如果全部权益只有周边商品，这个计划就没有运转动力。
• 反馈承接能力：产品团队中必须有人真正接收并回应倡导者提出的问题。反馈义务若无人倾听，只会让倡导者觉得自己的意见石沉大海。
• 行为准则基线：必须已经有行为准则和管理流程。倡导者头衔会让人默认其拥有权威；授予头衔却没有执行流程，就会让不良行为者成为官方成员。

同时写明终止标准：每季度的活动率或续期率达到什么水平时，意味着计划应该缩减或停止。启动前做出决定，是唯一能诚实做出这项决定的时机。

第 2 步 — 选择招募模式

以下是四种模式，按单位投入所能带来的价值排序。介绍排名靠前的两到三种模式及其权衡，并给出建议，然后让用户选择。

• 投入：负责人的固定工时、每轮的审核工作量、需要有人构建并维护的工具，以及该模式公开后可逆的程度。
• 价值：入选队列的质量，以及向所有未入选者解释选拔结果的说服力。

CNCF、HashiCorp、MongoDB、Elastic、Twilio 和 GitHub Stars 的案例来源见 ./references/program-archetypes.md。

• 效率：邀请制小圈子 > 奖励制 > 申请制队列 > 积分台账
• 价值：申请制队列 > 积分台账 > 奖励制 > 邀请制小圈子
• 投入：积分台账 > 申请制队列 > 奖励制 == 邀请制小圈子
• 合规成本：积分台账 > 申请制队列 > 奖励制 == 邀请制小圈子
• 仅限邀请的小圈子 - 私下邀请，5–20 人，不公开成员名单。它在效率方面领先，因为几乎不需要持续投入，几周内就能组建一个有效的群体，而且这是唯一一种可以不发布公告就解散的形式。投入：几乎为零——一份共享文档，以及与每位成员各谈一次。最适合首次尝试，以及活跃社区成员少于约 500 人时；约 500 人这条线由自己设定，刻意早于有关社区扩大的资料中所述的大使计划在成员达到 1,000 人以上时启动的阶段，因为私下邀请所需的社区规模低于公开成员名单。等社区规模大到私下邀请显得随意时，这种形式就会失效。
• 奖励／表彰 - 仅接受提名，评审不公开，设定固定日期的成员批次。它为成员带来可用于自身职业发展的声望，而项目方给予这份声望无需付出任何成本。投入：每份提名约一小时，每个评审周期内会集中出现，周期之间几乎为零。当所有提名者都来自同一个团队，导致成员名单反映该团队的人际网络时，这种形式就会失效。
• 申请制成员批次 - 公布评选标准，每年开放一次申请。四种形式中价值最高：公布评选标准，才能让落选者坦然接受；开放申请窗口则能发现员工无人注意到的候选人。投入：每个申请窗口前后都需要一个季度的管理工作——标准页面、申请表、评分，以及给每位落选者的具体回复——每年重复一次；公布的评选标准也意味着下个周期必须以同样方式执行。
• 积分台账 - 根据已跟踪的贡献自动表彰，成员数量不设上限。它带来的覆盖面是其他形式都无法企及的：员工从未接触到的贡献类型和地区，这正是 Elastic 的数据所描述的情况。投入：持续性的工作——门户网站、每个周期重新审视各地区的权重，以及公开的积分台账。四种形式中最难撤回，因为成员会根据承诺的兑换规则累积积分；停止运行就意味着必须兑现积分余额。
• 说明为何这两种方式在投入上并列：奖项和邀请制小圈子每个周期都只需做一次小范围决策，周期之间无需投入任何精力——两者都不公布标准、不设置申请表，也无需维护任何系统。不过，奖项的效率排名仍然较低，因为公开名单和有明确日期的群组无法悄然取消。
• 说明为何这两种方式在合规上并列：两者只承担第 6 步中全项目层面的义务，不会额外增加任何要求。
• 将合规一栏理解为需要接受的审查，以及为此付出的可逆性：
  • 积分账本会公开成员的活动记录，并授予可兑换的价值，因此在上线前需要考虑礼品限额、成员的税务风险和数据审查。
  • 申请制群组公布的标准是一项公开承诺，你可能需要对此负责。
  • 另外两种方式（邀请制小圈子、奖项）不会增加第 6 步以外的任何要求。
• 默认选择邀请制小圈子；如果私下挑选开始显得武断，就升级一种形式——这正是参考内容描述的逐步升级路径。
• 这种排序牺牲了什么：申请制群组能培养最坚定的拥护者，但行政工作也最多，因此按比率排序时总会选中私人邀请制。出现以下情况时，应将申请制群组提上来：
  • 用户希望打造能持续增值的资产。
  • 社区规模已经超过私下挑选还能说得过去的程度。
  • 被拒申请者公开抱怨会造成实际问题。
• 如果没有工程时间用于追踪，就应删除积分账本，而不是将它排在最后——Elastic 发现基于 GitHub 的追踪方式无法满足需求，不得不构建门户；而电子表格上的账本恰恰会在其最薄弱的方面失效。明确说明删除了哪种模式及原因，不要把它留在候选名单上。
• 将此排序视为默认方案，而非铁律：它会因具体情况和项目负责人而变化。结合你已知的信息重新排序——以下每种情况都会让一种形式在默认排序基础上上升一位：
  • 已有贡献追踪系统。
  • 社区团队已经在为其他事项审核申请。
  • 创始人亲自认识每位候选人。

当需求超过你能支持的群组规模时，可设置两个层级：一个开放、门槛低、任何人都能加入的引流层级，以及一个从中招募的小型精选核心群组。这样既能解决稀缺与包容之间的争论，也能让申请制群组在效率排序中上升——引流层级会积累活动记录，从而降低筛选成本。

第 3 步 - 公开撰写遴选标准

在撰写标准之前，先确定哪些人有资格成为候选人。使用 Orbit 模型的四个成员等级作为分类依据：探索者、参与者、贡献者、倡导者；从贡献者和倡导者中招募拥护者，将参与者视为后备梯队，并排除探索者。该模型的引力公式（热爱 × 覆盖面）也揭示了下文反向信号中的陷阱：平台福利日后可以带来覆盖面，但参与深度无法凭空赋予。

在首次招募前公布标准，并采用满足两项或以上的模式：列出四到六项符合条件的活动，要求候选人满足其中任意两项，就像 CNCF 的五项标准那样。单一强制标准会把计划筛选成只适合一种性格类型的人——通常是会议演讲者；而未公开的评分标准则会让每次拒绝都无法自圆其说。

根据产品调整以下标准，并确保每项都可衡量：

1. 对项目或生态系统有直接贡献，并明确最低要求。
2. 持续 12 个月以上的社区领导工作——组织活动、担任版主、运营用户组。
3. 公开教学：演讲、工作坊、直播。
4. 指导新人，无论是在社区内还是通过有组织的计划。
5. 创作内容，明确不得设置付费墙，以确保这项标准关注的是社区受益。
6. 支持工作：回答他人的问题——这是此技能最看重的信号，因为这类劳动没有报酬。

同样明确说明反向信号：

• 有影响力，但对产品缺乏深入了解。
• 直到申请开放那周才开始参与。
• 居高临下地对待初学者。
• 将头衔视为报酬。

以书面形式说明利益冲突规则，涵盖受雇于竞争对手的情况，以及业务发展会依赖该头衔的咨询公司——此类情况若逐案判断，无论结果如何都会被视为偏袒。

每轮招募都会有落选候选人继续留在社区。请回复具体的不足之处，以及下个申请窗口开放前应做哪些努力。遴选评分标准、申请表字段、拒绝和续期消息示例 中提供了相关内容。

步骤 4 - 将义务设为行为要求，将福利设为可获得的权益

义务。 要求成员遵守行为规范，而不是要求产出：

• 遵守行为准则。
• 积极帮助新成员。
• 提供诚实的反馈，包括批评意见。
• 遵守禁发期。

明确说明反馈义务：对大多数产品而言，产品反馈比传播覆盖面更有价值。绝不设定内容配额：这会把认可变成工作，而无偿工作既是社区问题，也是法律问题（见步骤 6）。

明确写出 Champion 不得做什么：

• 代表公司发言。
• 承诺路线图上的事项。
• 充当无偿的一线支持人员。
• 处理客户升级问题。

福利，按成员每周期从福利中获得的价值与该福利所需内部投入的比例排序。此排序是本技能的判断；有来源支持的依据是，HashiCorp 和 MongoDB 公布的福利清单都将访问权益放在前面——简报、路线图评审和高管交流，而非周边商品。

• 效率：访问权益 > 平台资源 > 技能培养 > 资金支持 > 身份象征物
• 投入：资金支持 > 技能培养 > 平台资源 > 访问权益 > 身份象征物

1. 访问权益 - 路线图评审、版本发布简报、与工程师交流的私密频道、与高管交流，以及在决策落定前参与咨询。这五类福利中最难复制，也是唯一一项只需开展一次就能同时惠及整个群体的福利。
2. 平台资源 - 预留演讲名额、在你的渠道中进行推广、共同撰稿、参与发布材料。这能让社区工作转化为成员的职业资本。需要逐一分配给成员，因此投入高于访问权益。
3. 技能培养 - 在演讲、写作和视频制作方面提供辅导。成员离开后仍能保留这些技能；这需要教练持续投入时间，但不需要审批。
4. 资金支持 - 差旅和门票、活动或内容预算、认证和培训券、额度。这五类福利中投入最高：需要列入预算、为每位成员单独签字审批，并且每次都要检查礼品限额和税务问题（步骤 6）。
5. 身份象征物 - 周边商品、徽章、名录收录、年度峰会。

• 此排序会牺牲什么：资金支持。这个比例把资金支持排在成本更低的福利之后，尽管在你没有设立团队的市场，真正能维系 Champion 的是差旅和门票。对于个人采纳者和区域群体，应提升其优先级（见“按受众划分的变体”）。
• 身份象征物排在最后，尽管成本几乎为零——低成本和高效率是两种不同的排序；在上述四个层级尚未建立之前，周边商品毫无价值。
• 此处不列合规成本：步骤 6 会对整套福利统一进行检查；礼品限额、税务和披露要求取决于成员的雇主和所在司法辖区，而非某个福利层级。

拒绝提供：

• 强制配额。
• 一概适用的保密协议。
• 佣金或联盟分成：这看起来像多层次营销，会损害成员在其受众中的信誉。
• 通用折扣码。
• 有名无实的头衔。

佣金这一项预计会引发反对：通用营销指南通常会把收入分成列为品牌大使计划的福利之一，但这些指南面向的是消费品牌大使，联盟分成在这种场景中很常见。现有的一份面向开发者受众的资料则认为，佣金是最弱的推荐机制，效果不如额度和互惠推荐。

应说明建议面向的是哪类受众，而不是声称整个领域都认同。如果用户确实想开展付费合作，应将其作为独立计划运营，并使用单独的合同，绝不要附加在认可头衔上。

步骤 5 - 修正任期，然后设计续任与退出机制

• 在第一天就为任期设定结束日期。 可自行设定的经验法则：厂商计划为 12 个月，基金会规模的计划为 24 个月——CNCF 的定期队列约为两年，HashiCorp 每年重建一次成员名单。没有明确日期的任期，唯一的退出方式就是移除成员，但没人会执行，所以名单上会不断累积不活跃的名字。
• 仅在任期结束前重新评估，并依据已公布的标准。根据过去的声誉来评判，正是导致成员名单过时的原因。
• 提前通知——提前一个季度很宽裕，提前一个月是底线——并告知你将据以评判的活动记录，这样续任就不会令人意外。
• 提供暂停选项，适用于育儿假、患病、换工作或倦怠等情况。把人生变故当成未能履职，会让人们选择隐瞒。
• 写明不活跃条款（连续 N 个月没有可见活动或联系 → 不符合续任资格，或转为校友），并为行为违规设定立即移除的途径，由审核流程决定，而非仅由计划负责人决定。
• 将校友设为正式身份，而不是删除。保留注明日期且真实准确的头衔（“Champion，2024-2026”），让校友留在低频交流频道，并赋予他们相应职责：提名成员、指导下一届成员、审核申请。成员被你聘用是一项成功——应将其转为校友，而不是抹去记录。
• **如果计划结束，**提前一个完整任期发布公告，兑现已承诺的福利，保留名单页面，并说明原因。删除页面会抹去成员列在简历上的成果。

步骤 6 - 完成合规检查

发布前，请逐项回答以下问题。涉及特定司法管辖区的事项，应以当地现行规定为准；涉及义务或资金时，还应咨询法律顾问。前三项决定候选人能否加入——应在申请时询问，而不是录取之后：

• 雇主批准：询问成员是否需要雇主批准才能担任厂商头衔，以及其雇主是否与你竞争。
• 礼品限额：公共部门、医疗保健和金融行业的员工通常不得接受超过一定价值门槛的礼品——丰厚的福利可能会在不知不觉间让候选人失去资格。允许任何成员在不受处罚的情况下拒绝任何福利。
• 年龄、税务和物流：公开发布的计划通常要求参与者年满 18 岁；高价值福利可能需要由成员缴税；跨境寄送周边产品会产生由计划承担的海关费用。
• 背书披露：免费产品、周边产品、门票、抢先体验和额度都会构成实质性关联，因此 Champion 发布的公开内容必须披露这类关联（在美国，依据 FTC《背书指南》，16 CFR Part 255；英国和欧盟也有类似规定）。提供应使用的措辞并明确披露要求——绝不要让每位成员自行猜测。
• 无偿工作：计划越接近分配任务、设定截止日期和指标，就越像雇佣关系，也会带来用工身份认定方面的风险。自愿参与、不设指标且可随时终止，既是更好的设计，也是更安全的做法。
• 保密协议范围：仅针对你早期实际分享的内容。笼统的保密协议会压制该计划旨在促成的公开倡导。

第 7 步 - 定义运作节奏

项目是一项持续承诺，而非一次性启动。确定节奏，并明确每个环节的负责人：

• 每月或每六周举行一次小组通话（可自愿参加）。
• 每季度举行一次路线图或发布前简报。
• 每季度向倡导者发送一份反馈摘要，回告 他们的意见带来了哪些改变。
• 每年设立一个申请窗口。
• 每季度安排一次公开表彰。

形成反馈闭环——这是最常被跳过、也是倡导者最在意的环节。“你们提出了意见，以下是我们已交付的内容、拒绝的建议及原因”，对留住成员的作用胜过任何福利。

让追踪方式与规模相称：仅限受邀者参与的小圈子用共享文档即可，只有积分账本面向全球开放时才需要真正的门户。Elastic 发现基于 forge 的追踪方式难以满足发展需求，不得不自行构建门户——应将其视为积分账本模式的成本，而非意外。无论追踪什么，都要让成员看得见；Elastic 表示透明的原因是治理，而非游戏化：“我们希望促进社区成员之间的交流，而不是让社区团队充当把关人”（Elastic 的 Ully Sampaio）。

然后，将第 1 至 7 步的所有决定写入章程，并使用 ./references/charter-template.md 中的 12 个问题模板，发布与成员相关的部分。未写明的规则，下一任项目负责人就不会执行；没有书面宗旨的项目，也永远不会得到修正或终止。如果你的环境支持持久记忆，也将章程中的决定存入其中，这样后续会话就能沿用模式、期限和标准，而不必再次向用户询问。

步骤 8 - 设定标准并衡量群体表现

每季度报告一次计分卡。表中的所有阈值均由你自行设定：优秀大使计划会对外保密其内部标准。

以下两个公开的结果数据都只是薄弱证据：

• Elastic：2019–2022 年参与者增加了 13%，贡献增加了 38%（一手信息，来自负责该计划的团队，没有基线对比）。
• Notion：据称有 300 多名大使，约四分之一的新用户通过社区推荐而来（二手信息，来自 Founding Marketing 第 12 章，Notion 从未确认过——这是极大规模下的北极星指标，并非目标）。

在启动前明确设定这些数字，因为没有标准的计划永远不会被叫停。然后根据计划最初两个季度的表现进行校准。

指标	衡量方式	起始标准
章程完整度	已回答的 12 个章程问题	在任何公开启动前达到 12/12
季度活跃占比	本季度至少有 1 次可见活动的大使	≥ 60%
续任接受率	接受再任一届的符合条件的大使	≥ 70%
对大使的响应速度	回答大使的问题或请求所需时间的中位数	≤ 5 个工作日
已落实的反馈	每季度可追溯至大使意见的产品决策数量	≥ 1
候选储备	已确定但尚未获准加入的合格候选人数	≥ 群体规模 × 0.5

先迭代，不要急着招募：如果活跃占比低于标准，先调整福利、义务或群体规模，再增加成员——扩大不活跃名单只会让数据更差。如果续任接受率下降，就对离任者进行离任访谈；原因几乎总是他们失去了访问权限，或是反馈石沉大海。

如实看待归因。大使的影响体现在减少的支持问题、你未委托制作的内容，以及你没有参与的场景中的采用情况——这些都无法被清晰地归因。

跟踪趋势，并询问新用户是如何了解到你的；不要建立数据无法支撑的收入归因模型。整个社区范围内的指标采集应归入 samber/developer-relations-skills@developer-community-health。

交付内容

按以下顺序产出两份成果，并在进入下一部分前与用户确认每一部分。

1. 章程 - 按 ./references/charter-template.md 模板中的顺序给出 12 个问题的答案，每个问题用一段简短文字回答。每个数字都标明是有来源依据还是自行设定。这是交付物；其他内容均由此衍生。
2. 公开页面：
   • 目的。
   • 标准和负面信号。
   • 义务及禁止事项清单。
   • 福利。
   • 任期日期、续任和不活跃规则。
   • 校友身份。
   • 披露要求。
   • 申请或提名方式。

章程中的其他内容均保留为内部信息。

按需添加，而非默认提供：

• 申请表和评分标准（来自 ./references/selection-rubric.md）。
• 生命周期消息草稿。
• 填入双方商定阈值的首份季度计分卡，其中包含步骤 8 的各行内容。

不要只交付福利清单，而不附上任期、退出机制或标准——这正是此技能旨在防止的问题；其带注释版本是 ./references/charter-template.md 中的反面示例。没有明确负责人或预算工时的章程不符合步骤 1 的要求；要直言指出这一点，而不是费心润色一份无人能执行的文档。

按受众划分的变体

• B2B / 企业产品：倡导者通常是客户公司里的员工，因此雇主审批、礼品限额和保密要求在这里影响最大。能提升他们内部地位的福利（认证、会议差旅、演讲机会、具名推荐）比面向消费者的奖励更有效。注意区分：这里指的是公开的社区倡导者，而不是销售周期中客户内部的决策推动者。
• 个人采用型产品（爱好者、学生、独立开发者）：群体更大，也更具流动性；预算来自个人，因此差旅资助或额度很有分量。要预期更高的流失率，缩短任期，并重视地区和语言覆盖——在你没有员工驻扎的市场，倡导者是你能拥有的杠杆效应最高的成员。
• 没有厂商预算的开源项目：核心回报是地位和责任，而不是周边商品。认可应逐步带来评审权和维护者身份——设计倡导者层级时，应让它与贡献者晋升阶梯衔接，而不是并列设置；同时保留该阶梯已定义的荣誉退任机制。参见 samber/developer-relations-skills@oss-contributor-onboarding 和 samber/developer-relations-skills@oss-governance。

失败模式

症状	原因	修复
名单不断扩大，活跃度却没有提升	没有任期、没有续任机制、没有不活跃规则	在下一个周期引入有明确期限的任期，并将不活跃成员转为校友
倡导者在第三个月后就不再回应	福利一开始就发完了周边商品，承诺的访问权限也从未兑现	改为定期提供访问机会；公布根据他们的反馈做了哪些改变
该计划看起来像营销部门的延伸	配额、简报、经批准的话术	取消配额，允许公开批评，并在章程中明确说明
被拒者公开投诉	标准未公开或执行不一致	公布两项或以上标准，并针对具体不足作出回复
倡导者代表公司发言，却说错了内容	从未写明行为边界	增加禁止事项清单；公开纠正，且不归咎于个人
招募到大客户的决策者，却从不露面	评估的是影响力，而非参与度	提高支持和指导信号的权重，使其高于粉丝数
某个地区或语言占据主导	标准是根据单一贡献文化制定的	按地区调整标准权重，正如 Elastic 在积分表中所做的那样
计划负责人精疲力竭	按照高投入模式设计，但群组规模超出可投入时间的承载能力	缩小群组规模，或改用投入较低的类型

参考资料

• ./references/program-archetypes.md：六个已发布计划的类型对比和引用基准数据。
• ./references/charter-template.md：12 个问题的章程模板、填写示例，以及一个失败版本的反面示例。
• ./references/selection-rubric.md：评分标准、申请表，以及拒绝、续期和退出消息示例。
• samber/developer-relations-skills@developer-community-launch：用于上游社区启动决策。
• samber/developer-relations-skills@developer-community-moderation：用于升级处理和行为规范执行。
• samber/developer-relations-skills@developer-community-health：用于衡量整个社区的参与度。
• samber/developer-relations-skills@oss-contributor-onboarding：用于开源项目中的代码贡献途径。
• samber/developer-relations-skills@developer-meetup-program：用于组织本地用户组。
• samber/developer-relations-skills@developer-feedback-loop：用于将倡导者的产品反馈传递给决策者。