foss测试

您在自由和开源软件项目中扮演关键角色吗？ 您是否想让下一个人更轻松地穿上鞋子，同时让自己有休息的自由并避免倦怠？

当然可以！ 但是，您如何开始？

在执行任何操作之前，请记住这是一个免费或开源项目。 与FOSS中的所有内容一样，您的继任计划应与他人合作进行。 最小惊讶原则也适用：不要孤立地制定计划，然后将其推广到整个社区。 共同努力并公开进行工作，因此当文化或治理发生变化时，任何人都不会措手不及。

识别和分析关键角色

作为项目负责人，第一步是确定社区中的关键角色。 虽然可以帮助询问每个社区成员他们扮演什么角色，但重要的是要意识到大多数人都扮演着多个角色 。 确保考虑每个社区成员在项目中扮演的每个角色。

一旦确定了角色并确定了对您的项目至关重要的角色，下一步就是列出每个关键角色的所有职责。 在这里说实话。 列出您认为每个角色都有的职责和责任，然后请执行该角色的人员列出该角色实际承担的职责。 您几乎可以肯定会发现第二个列表比第一个列表长。

重构大角色

在此过程中，您是否发现任何包含大量职责的角色？ 大型角色就像代码中的大型方法：它们是问题的征兆，需要对其进行重构以使其易于维护。 FOSS项目继任计划中最简单，最有效的步骤之一就是将每个大型角色分成两个或多个较小的角色，并将其分发给其他社区成员。 通过这一步骤，您已大大改善了项目的总线系数 。 更好的是，您使每个新的较小的角色中的每个角色都更易于访问，并且对新社区成员没有太大的威胁。 如果不是很大的负担，人们更有可能自愿担任某个角色。

限制角色任期

使角色更具吸引力的另一种方法是限制其任期。 社区成员将更愿意扮演不限成员名额的角色。 他们可以看看自己的生活和工作计划，然后问自己：“在接下来的18个月中，我可以担任这个职位吗？” （或您设置的任何期限限制）。

设置期限限制也可以帮助当前正在担任该角色的人员。 他们知道什么时候可以搁置这些职责并继续从事其他工作，这可以减轻工作倦怠。 此外，设置任期限制会创建一个已担当此角色并有资格在需要时介入的人员库，这也可以减轻倦怠感。

知识传输

一旦确定并定义了项目中的关键角色，剩下的大部分就是知识转移。 即使是小型项目，也涉及很多活动部分和知识，每个人都应该可以看到，共享，使用并做出贡献。 您应该收集什么样的知识？ 答案会因项目，需求和角色而异，但以下是实施继任计划所需的一些最常见（且通常被忽略）的信息类型：

• 角色及其职责 ：您已经花费了大量时间来确定，分析和潜在地重构角色及其职责。 确保此信息不会丢失。
• 政策和程序 ：这些职责都不是凭空发生的。 在满足特定条件（策略）时，必须以特定方式（过程）执行每个职责。 为每个角色的每一项职责清点这些细节。
• 资源 ：哪些帐户与该项目相关联，或者需要哪些帐户才能运行？ 谁可以为您提供聚会空间，赞助或实物服务？ 这些信息对于项目运营至关重要，但是当负责任的社区成员继续前进时，这些信息很容易丢失。
• 凭据 ：理想情况下，项目所需的每个外部服务sre@project.org使用登录名，该登录名将转到为特定角色指定的电子邮件地址（ sre@project.org ），而不是个人地址。 每个角色的地址都应在通讯组列表中包括多个人，以确保不会错过重要消息（例如停机或虚假的“忘记密码”请求）。 每个服务的凭据都应保存在安全的密钥库中，并且访问权限应限制在可能的最少人数。
• 项目历史记录 ：所有社区成员都将从学习项目历史记录中受益。 收集项目历史信息可以例如阐明过去做出决策的原因，并揭示社区中未表达的要求和价值。 项目历史还可以帮助新社区成员了解“内在的笑话”，行话和其他文化因素。
• 过渡计划 ：如果项目负责人没有考虑过如何将角色从一个人过渡到另一个人，那么继任计划就没有太大用处。 您将如何找到并准备接任关键角色的人员？ 由于该项目已经进行了很多思考和知识转移，因此针对每个角色的过渡计划可能更容易组合在一起。

为项目中的所有角色进行完整的知识转移可能是一项艰巨的任务，但是付出的努力是值得的。 为了避免被如此艰巨的任务淹没，请一次处理一个角色，在完成下一个任务之前先完成每个任务。 以这种方式限制范围使进步和成功的可能性更大。

文件，文件，文件！

继任计划需要时间。 社区将做出很多决定并收集大量信息，因此请确保没有任何损失。 记录所有内容 （不仅仅是在电子邮件线程中）非常重要。 在涉及知识的地方，文档规模很大，而人员却没有。 甚至包括您认为显而易见的事情-对于经验丰富的社区成员而言，显而易见的事情对于新手而言可能不那么明显，所以请不要跳过任何步骤或信息。

将这些决策，流程，策略和其他信息收集到一个地方，即使它只是主项目存储库中的降价文件的集合。 该文档的“如何”和“何处”可以在以后进行整理。 最好先捕获关键信息，然后再花时间骑自行车扔掉文档系统。

收集完所有这些信息后，您应该了解到任何人都不太可能阅读它。 我知道，这似乎不公平，但这只是通常情况下的工作方式。 原因？ 太多的文档和很少的时间。 要解决此问题，请在每个项目的顶部添加摘要或摘要。 通常，这是一个人所需的全部内容，如果没有，则需要深入了解完整的文档。 认识并适应大多数人使用文档的方式会增加他们使用您文档的可能性。

最重要的是，不要跳过文档编制过程。 没有文件，接班人计划是不可能的。

新领导人

如果您还不想扮演关键角色，但愿意的话，您可以在继任计划的过程中做出贡献，同时将自己的方式当做这些角色之一。

对于初学者，积极寻找学习和贡献的机会。 暗中扮演关键角色的人。 您将学习如何完成角色，并可以记录下来以帮助进行继任计划过程。 您还将有机会查看它是否是您进一步追求的目标。

寻求指导是使自己更接近在项目中扮演关键角色的好方法。 即使您还没有听说过可以进行辅导，也可以问一下。 已经担任这些职位的人通常很乐意指导他人，但常常太忙而无法考虑提供指导。 问是对他们的有益提醒，他们应该帮助他们训练需要休息的人。

在执行自己的任务时，请积极寻求反馈。 这不仅会提高您的技能，而且表明您有兴趣为社区做得更好。 当您的项目需要人们担任关键角色时，这一承诺将得到回报。

最后，当您与经验丰富的社区成员进行交流时，请注意有关该项目的历史及其运作方式的轶事。 这段历史非常重要，特别是对于新贡献者或担任关键角色的人们。 它为新的贡献者提供了必要的背景信息，以了解什么东西有用或不起作用以及原因。 当您听到这些故事时，请记录下来，以便将其传递给您之后的人。

继任计划实例

虽然很少有FOSS项目积极考虑继任计划，但有些项目在减少总线因素和防止维护人员倦怠方面做得很好。

锻炼不仅是获得流利的编程语言的绝佳工具。 这也是一个开源项目 ，它尽力帮助贡献者获得他们的第一个补丁 。 在2016年，该项目对每种语言的运行状况进行了审查， 发现其中许多语言受到了严重维护 。 仅仅没有足够的人能讲每种语言，因此维护人员精疲力尽。 运动界认识到这种做法带来的风险，并努力为尽可能多的语言领域寻找新的维护者。 结果，该项目能够从濒死中复活，并开发出一种结构来邀请人们成为维护者。

Vox Pupuli项目的目的是作为Puppet模块社区的一种继任计划。 当维护者不再希望或无法使用其模块时，可以将其遗赠给Vox Pupuli社区。 这个由30位合作者组成的社区共同承担着维护其接受到项目中的所有模块的责任。 大量的协作者确保了没有一个人负担维护的负担，同时还为项目中的每个模块提供了长久而富有成果的生命。

这些只是一些FOSS项目如何处理继任计划的两个示例。 在下面的评论中分享您的故事。

翻译自: https://opensource.com/article/18/4/succession-planning-how-develop-foss-leaders-future

foss测试