有人愿意贡献代码，是开源项目令人高兴的时刻。贡献者多起来以后，谁来决定下一步，却会成为另一项工作。
2023 年 7 月 20 日刊出的采访中，Lichess 创始人 Thibault Duplessis 回顾了项目如何从浏览器实时通信实验逐渐吸引使用者与志愿者。有人短暂参与，有人留下多年。这个在线国际象棋服务后来成为法国的一家非营利组织，捐款用于维持和改进服务。[1][2]
同场采访里，负责运营的 Theo Wait 谈到疫情期间的扩展。他认为，技术设施应对增长相对顺利，组织能力的扩展更困难；随着参与者增加，完全依靠共识作决定变得笨重。当时他们正在调整治理方式，包括重写内部章程等工作。[1]
“正在调整”是这段材料的重要时间边界。采访没有证明所有问题已经解决，本文也不能替他们补上一个完善治理的结局。
一个项目最初只有几个人时，大家在聊天中交流，就可能知道谁正做什么。后来出现不同语言、技能和参与频率的贡献者，原来的默契不再自然存在。有人愿意提方案，却不知道由谁接住；有人承担长期维护，也不确定自己能否结束一场持续很久的讨论。
我的理解是，更多参与机会需要配套更清楚的决定方式。允许每个人提出意见，并没有自动回答什么时候可以开始做、谁负责后果，以及以后怎样修改这次决定。
可以用一个假设项目来拆开看。几位志愿者维护一款免费词汇练习工具，同一周收到三项提议：改正一个说明里的错字、改变默认练习顺序、修改贡献者署名的安排。下面的做法是本文建议，并非 Lichess 当年的内部流程。
如果三项提议都等待每个人同意，连错字也可能排在漫长讨论后面。如果三项都由一个人顺手合并，又会把影响他人使用方式或参与权益的决定处理得过轻。决定的范围，应当跟着影响范围变化。
错字可以交给负责文档的人核对并修正，留下记录，让其他人能够复查。默认练习顺序影响实际使用，需要维护者解释希望解决什么问题，听取相关反馈，并安排可以恢复的尝试。署名安排涉及贡献者本人的期待，则需要先让受影响的人了解具体变化，按项目既有规则充分讨论，不能用“代码已经合并”代替这一步。
这里没有要求所有项目都采用同一套层级。更实用的，是在每个重要提议上留下几项简短信息：这次改变影响谁，由谁负责推进，需要听谁的意见，根据什么作出决定，什么情况下重新讨论。
例如，对练习顺序的提议，可以先写清想解决的现象，再记录为什么选择这项尝试，以及出现什么问题时恢复原来的方式。即使后来证明判断有误，下一位接手者也能知道当时在解决哪个问题，而不必从聊天记录里猜测动机。
“没有回复”也要谨慎解释。志愿者可能忙于工作、没有看到通知，或者尚未弄明白影响。可以在讨论开始时写明反馈窗口和必要参与者，并安排负责人提醒；对明确需要受影响者参与的事项，时间到了仍未得到回复，应记录缺口，按规则延后或缩小范围。沉默不能被随意记成支持。
负责推进的人同样需要可交接的安排。若临时无法继续，谁能接过资料，当前卡在哪里，哪些意见仍未处理，应当让后来者看得见。否则项目可能一边依靠开放协作，一边把实际进度锁在某位志愿者的空闲时间里。
这些协调工作会消耗真实精力。Lichess 目前公开的成本表包含社区协调、审核、运营与治理相关工作；表格没有标明统一更新日期，我在 2026 年 11 月 6 日读取它，只把它作为工作类型的补充，不把其中金额套回 2023 年。[3]
对小项目而言，值得先做的一件事，是挑出当前停滞的一个提议，写出谁推进、谁需要参与、下一步何时发生。如果连这几行都写不清，继续招募更多人，可能只是让更多善意排在同一个等待队列里。
资料与日期：
- [1] Sagar Shah 采访、Sneha Tiwari 整理，《The vision of Lichess and its founder Thibault Duplessis》，2023 年 7 月 20 日：创始人与运营负责人访谈。
- [2] Lichess，About，页面未标发布日期，2026 年 11 月 6 日读取。
- [3] Lichess，公开成本表入口，跳转至公开表格，未见统一更新日期，2026 年 11 月 6 日读取。
采访全文与官方资料均已核对。没有采用媒体开头的排名判断、受访者对竞争者的推测，也没有声称项目没有付费人员。词汇工具和决定记录均为本文独立假设。
