您是否在一个自由开源软件项目中担任关键角色？您是否希望让继任者更容易接替您的工作，同时让自己能够自由休息并避免倦怠？
当然您会！但如何开始呢？
在您做任何事情之前，请记住这是一个自由或开源项目。与 FOSS 中的所有事物一样，您的继任计划应与他人协作进行。《最小惊讶原则》也适用：不要孤立地制定您的计划，然后突然向整个社区公布。共同公开地工作，这样当文化或治理发生变化时，就不会有人措手不及。
识别和分析关键角色
作为项目负责人，您的第一步是识别社区中的关键角色。虽然询问每位社区成员他们扮演的角色会有所帮助，但重要的是要意识到大多数人扮演多个角色。请确保您考虑每位社区成员在项目中扮演的每个角色。
一旦您确定了角色并确定了哪些角色对您的项目至关重要，下一步就是列出每个关键角色的所有职责和责任。在这里要非常诚实。列出您认为每个角色拥有的职责和责任，然后询问执行该角色的人员列出该角色实际拥有的职责。您几乎肯定会发现第二个列表比第一个列表更长。
重构大型角色
在此过程中，您是否发现任何角色包含大量职责和责任？大型角色就像代码中的大型方法一样：它们是问题的征兆，需要重构以使其更易于维护。FOSS 项目继任计划中最简单有效的步骤之一是将每个大型角色拆分为两个或多个较小的角色，并将这些角色分配给其他社区成员。仅需一步，您就大大提高了项目的巴士系数。更好的是，您使每个新的、较小的角色对新的社区成员来说更容易接受且不那么令人生畏。如果角色不是巨大的负担，人们更愿意自愿承担角色。
限制角色任期
使角色更具吸引力的另一种方法是限制其任期。社区成员更愿意承担非开放式的角色。他们可以查看自己的生活和工作计划，并问自己：“我可以在接下来的十八个月（或您设置的任何期限）内承担这个角色吗？”
设置任期限制也有助于那些目前正在执行角色的人。他们知道何时可以放下这些职责并转而从事其他工作，这有助于减轻倦怠。此外，设置任期限制创建了一个已执行该角色并有资格在需要时介入的人员库，这也可以减轻倦怠。
知识转移
一旦您确定并定义了项目中的关键角色，剩下的主要就是知识转移。即使是小型项目也涉及许多活动的部件和知识，这些知识需要放在每个人都可以看到、共享、使用和贡献的地方。您应该收集哪种知识？答案会因项目、需求和角色而异，但以下是一些实施继任计划所需的最常见（且常被忽视）的信息类型：
- 角色及其职责：您花了很多时间识别、分析以及可能重构角色及其职责。确保这些信息不会丢失。
- 政策和程序：这些职责都不是在真空中发生的。每个职责都必须在特定条件满足时（政策）以特定方式（程序）执行。记录每个角色的每个职责的这些细节。
- 资源：哪些帐户与项目关联，或者项目运行所必需的帐户？谁在聚会场所、赞助或实物服务方面为您提供帮助？此类信息对于项目运营至关重要，但当负责的社区成员离开时很容易丢失。
- 凭证：理想情况下，项目所需的每个外部服务都将使用登录名，该登录名指向为特定角色指定的电子邮件地址（
sre@project.org），而不是个人地址。每个角色的地址应包括分发列表中的多人，以确保不会错过重要消息（例如停机时间或虚假的“忘记密码”请求）。每个服务的凭证都应保存在安全的密钥库中，访问权限应限制在尽可能少的人数。 - 项目历史：所有社区成员都将从学习项目历史中受益匪浅。收集项目历史信息可以阐明过去做出决定的原因，例如，并揭示社区中其他未表达的需求和价值观。项目历史还可以帮助新的社区成员理解“内部笑话”、行话和其他文化因素。
- 过渡计划：如果项目负责人没有考虑过如何将角色从一个人过渡到另一个人，那么继任计划就没什么用处。您将如何找到并培养人员来接替关键角色？由于项目已经进行了大量的思考和知识转移，因此每个角色的过渡计划可能更容易制定。
为项目中所有角色完成完整的知识转移可能是一项艰巨的任务，但这种努力是值得的。为了避免被如此艰巨的任务压倒，请一次处理一个角色，在继续下一个角色之前完成每个角色。以这种方式限制范围使进展和成功都更有可能。
记录，记录，记录！
继任计划需要时间。社区将做出许多决定并收集大量信息，因此请确保没有任何信息丢失。重要的是记录一切（不仅仅是在电子邮件线程中）。就知识而言，文档具有可扩展性，而人则不具备。甚至包括您认为显而易见的事情——对于经验丰富的社区成员来说显而易见的事情对于新手来说可能并非如此，因此不要跳过步骤或信息。
将这些决定、流程、政策和其他信息片段收集到一个地方，即使它只是主项目存储库中的 markdown 文件集合。文档的“如何”和“在哪里”可以稍后解决。最好先捕获关键信息，然后再花时间在文档系统上进行琐碎的争论。
一旦您收集了所有这些信息，您应该明白不太可能有人会阅读它。我知道，这似乎不公平，但这通常就是事情的运作方式。原因是什么？文档太多，时间太少。为了解决这个问题，在每个项目的顶部添加摘要或概要。通常，这才是人们所需要的全部，如果不是，完整的文档就在那里供深入研究。认识到并适应大多数人使用文档的方式会增加他们使用您的文档的可能性。
最重要的是，不要跳过文档记录过程。没有文档，继任计划是不可能的。
新的领导者
如果您尚未担任关键角色但希望担任，您可以在以学徒身份进入其中一个角色的同时为继任计划过程做出贡献。
首先，积极寻找学习和贡献的机会。在关键角色中跟随他人学习。您将学习如何完成角色，并且可以记录下来以帮助继任计划过程。您还将有机会了解这是否是您有兴趣进一步追求的角色。
请求指导是让自己更接近承担项目中关键角色的好方法。即使您没有听说过有指导可用，询问一下也完全可以。已经担任这些角色的人通常很乐意指导他人，但往往太忙而没有考虑提供指导。询问是对他们的一个有益提醒，即他们应该帮助培训人们在他们需要休息时接替他们的角色。
在您执行自己的任务时，积极寻求反馈。这不仅会提高您的技能，而且表明您有兴趣为社区做得更好。当您的项目需要人们担任关键角色时，这种承诺将获得回报。
最后，当您与更有经验的社区成员交流时，请注意关于项目历史及其运作方式的轶事。这段历史非常重要，特别是对于新的贡献者或担任关键角色的人。它为新的贡献者提供了必要的背景信息，以了解哪些事情有效或无效以及原因。当您听到这些故事时，请记录下来，以便可以将它们传递给后来者。
继任计划示例
虽然很少有 FOSS 项目积极考虑继任计划，但有些项目在努力降低其巴士系数和防止维护者倦怠方面做得非常出色。
Exercism 不仅仅是一个用于提高编程语言流利度的出色工具。它也是一个开源项目，竭尽全力帮助贡献者完成他们的第一个补丁。2016 年，该项目审查了每个语言轨道的健康状况，发现许多轨道的维护状况令人担忧。根本没有足够的人来覆盖每种语言，因此维护者感到倦怠。Exercism 社区认识到这造成的风险，并努力为尽可能多的语言轨道寻找新的维护者。结果，该项目能够使几个濒临死亡的轨道恢复生机，并开发了一种邀请人们成为维护者的结构。
Vox Pupuli 项目的目的是作为 Puppet 模块 社区的一种继任计划。当维护者不再希望或无法在其模块上工作时，他们可以将其遗赠给 Vox Pupuli 社区。这个由 30 位合作者组成的社区共同承担维护其接受到项目中的所有模块的责任。大量的合作者确保没有人单独承担维护负担，同时也为项目中的每个模块提供长期而富有成效的生命周期。
这只是 FOSS 项目如何应对继任计划的两个示例。在下面的评论中分享您的故事。
1 条评论