成为项目团队负责人 (PTL)¶
您是否被邀请担任 OpenStack 项目的团队负责人 (PTL)？您是否正在考虑竞选 PTL，但不确定工作量？您是否正在与您的管理层讨论竞选 PTL 的好处以及您的潜在候选资格？或者，您正在合作的项目是否没有即将到来的 PTL 选举的候选人？
如果以上任何一项属实，以下文档旨在帮助您了解 Openstack 项目的 PTL 预计需要承担的职责。
本文档旨在作为当前和未来 PTL 的通用指南。它并非涵盖所有内容，也不是所有部分都必需的，它只是您可以参考的指南。每个 OpenStack 项目都不同，发布、计划和委托的方式也不同。
如果您不熟悉下面的一些概念、术语或行动项目，请随时联系您项目的当前 PTL。如果您无法这样做，您可以联系 当前任职的技术委员会 (TC) 的任何成员，以获取有关下一步的进一步指导。
重要提示
重要的是要注意，本文档包含大量内容，可以被认为是一项繁重的工作。我们（社区）建议任何考虑竞选 PTL 的个人都应充分了解职责，并且如果他们无法完成所有任务，则可以舒适地委派任何任务。
定期任务¶
下面概述的定期任务是社区认为作为团队领导的 PTL 应该能够完成的最低期望。
请记住，以下项目是可选的，并且完全取决于您的团队的功能。
核心成员维护¶
这在不同的团队之间会有很大差异，但以下内容提供了一个您可能考虑的通用指南。
考虑新核心成员的标准¶
PTL 可以单独做出成功的任命，但是鼓励听取现有核心团队的意见。这可以通过 IRC 上的私信或通过 openstack-discuss 邮件列表公开进行。
他们的 review 数量（数量和分歧）与现有核心成员相似吗？
这个人会跟进 review 吗？
review 有帮助、有批判性且对作者友好吗？
这个人是否帮助处理 bug？（例如：重现问题）
这个人是否提供 bug 修复？
这个人是否创建和实施新功能？
这个人是否 review 规范？
这个人是否参加每周会议？
这个人是否参与论坛讨论？
这个人是否参加中期/项目团队会议？
这个人是否了解项目方向和优先级？
这个人是否在 IRC 上帮助他人？
添加新核心成员时要执行的操作¶
准备好后，执行以下操作
在邮件列表中宣布新的核心成员
将他们添加到 Launchpad 中的项目驱动程序组。
在 Gerrit 中更新核心团队。
移除新核心成员的标准¶
核心 reviewer review 的数量是否足够？使用数据（例如 stackalytics 或 reviewstats）来确定核心 reviewer 是否在整体 review 数量方面与其他核心成员相同。
核心 reviewer 是否有足够的时间进行 review？工作职责可能已经改变。
核心 reviewer 是否不再了解代码库和新功能？
核心 reviewer 是否仍然提供有用的反馈，即使不经常？
在新的周期开始时¶
任命 跨项目联络人（文档、发布、QA、Oslo 等）。
任命 First Contact SIG 联络人（默认情况下，联络人将是 PTL）。
检查会议时间是否适合大多数活跃贡献者。
如果您保留发布联络人职责，请加入 #openstack-release 并确保关注邮件列表中的 [release] 邮件。
如有必要，压缩数据库迁移。通常不需要这样做，但可以减少升级所需的时间。Keystone 团队的示例 squash 可以参见 此处。
跟踪已删除和弃用的功能，例如使用 deprecated-as-of-<series> 和 removed-as-of-<series> 蓝图。
组织规范页面（如果有）。
如果 TC 批准了社区目标，请检查该目标与项目的相关性，并评估团队的工作项目。
提议添加来自您项目的额外活跃贡献者。要了解谁可以成为额外的活跃贡献者以及如何添加他们，请参阅 TC 文档
在周期内¶
帮助首次贡献者，他们会遇到最大的困难。
注意
作为 PTL，您的工作不是全职指导个人。如果新贡献者遇到重大困难，请将他们指向 First Contact SIG (#openstack-upstream-institute 在 IRC 上)，以便他们获得适当的入职培训。
缺乏 review？联系核心团队并提醒他们。
根据需要发布库，但不要等待太久！有些团队即使更改很小，也会在 4 周后发布。更频繁地发布比更少地发布更好。
会议和活动任务¶
项目更新¶
确定您的项目是否有他们希望与社区分享的新闻，以在即将到来的峰会上以 20 或 40 分钟的项目更新的形式分享。
请留意 OSF 员工发送的项目更新请求调查。调查将直接发送给 PTL，而不是发送给 openstack-discuss ML。
如果您请求了项目更新，请确保在电子邮件中注明的截止日期之前注册您自己（或列为演讲者的其他人），以确保更新插槽。
在论坛之前¶
启动 etherpad 以集思广益潜在的会话主题。例如：http://lists.openstack.org/pipermail/openstack-dev/2017-March/114123.html
根据集思广益的结果，提出会话。为每个会话创建一个 etherpad，准备内容。将这些 etherpad 列在 Wiki 中。
在论坛期间¶
联系潜在的新贡献者，参与项目入职会话。
尽可能参加跨项目会话。
在您主持的讨论会话中
在 etherpad 上做笔记（或委派抄写员）
充当主持人，而不是积极参与（或委派主持人）
讨论结束后，将会话结果的摘要发布到 ML，以便那些无法到场的人受益。
在论坛结束时，确保将所有讨论的摘要发送到 ML，以便那些没有参加活动的人员。
在 PTG 之前¶
确定您的团队是否将在 PTG 上举行团队会议，并与活动组织者沟通。OSF 员工会提前发送电子邮件给 PTL - 请留意。
如果您的团队在 PTG 上聚会，请创建一个 etherpad 以动态构建房间议程，并在活动 wiki 页面上列出它。
创建一个临时时间表，以便对特定主题感兴趣的其他项目的人员知道何时加入讨论。
在 PTG 期间¶
尽可能灵活，根据需要参加跨项目会话。
使事件时间表保持最新，了解您的团队房间中当前讨论的主题。
在 PTG 结束时，确保将所有讨论的摘要发送到 ML，以便那些没有参加活动的人员。
参加活动¶
虽然作为 PTL 参加峰会和 PTG 是首选，但如果您由于个人或职业原因无法做到，那也没关系。社区会支持您，如果无法参加旅行，可以帮助规划团队定向活动和任务。
如果您无法参加，请参阅我们的 如何成功委派 部分。
在周期结束时¶
清理发布说明。
与 发布管理 团队协调交付成果，除非已指定联络人，并确保发布亮点记录在发布文件中。
通过 etherpad 进行回顾。建议的章节包括：哪些方面进展顺利？、哪些方面进展不顺利。
分析每个新功能的 完成 程度。它是否有 DevStack 支持？Horizon 支持？客户端绑定？CLI 支持？文档？是否需要更新安装指南？
确保文档已更新，以反映周期内实施的任何重大更改。
收集反馈¶
从用户和操作员那里收集反馈是逐步改进软件的重要步骤。任何人都可以收集反馈，但有时 PTL 承担着促进开放沟通线路的责任。以下是一些您可以做到这一点的方法。
邮件列表¶
我们的社区有几个邮件列表。大多数使用、操作和开发讨论发生在 openstack-discuss 邮件列表中，使其成为寻求反馈的好地方。使用邮件列表的一个优势是回复已记录，因此以后可以轻松引用它们。您也不必等待特定的时间和地点来使用邮件列表，因此在正式场合不可行或不需要时，可以轻松尝试收集反馈。
用户调查¶
基金会为用户和操作员准备了一项调查。基金会与 PTL 分享结果，然后他们可以将知识传播给其他可能感兴趣的人。
值得检查您的项目是否参与了调查。确保调查问题与您的项目相关并反映团队正在做的事情的当前状态。如果您不确定调查中询问的内容或想更新项目特定的调查问题，请联系基金会的人员。
PTG 会话¶
有时，您可能会在项目团队聚会上找到操作员或用户。您可以设置时间段在您的项目议程中，邀请他们与开发人员分享反馈。如果官方时间段没有进入时间表，走廊讨论是收集快速反馈的好方法。
论坛会话¶
在峰会和论坛上找到更多操作员和用户的情况并不常见。您可以利用这个机会尽可能多地从他们那里收集反馈，如果您参加的话。由于每个人通常都有繁忙的日程安排，因此最好提前计划并宣传这些会话。有几种特定的方法可以在整个星期收集反馈。
首先，提交论坛会话提案以收集您项目的反馈。基金会要求社区提供会话提案，这些提案用于构建论坛的时间表。如果您正在寻找有关特定事物的反馈，请明确说明。通过在正式时间表上安排反馈会话，您让操作员和用户知道您的项目愿意倾听他们的意见。这是与用户面对面交流、交换联系信息和讨论他们可能遇到的问题的绝佳方式。
其次，使用您的项目更新来宣传反馈会话或表明团队对反馈感兴趣。如果您正在寻找有关新功能的指导，请分享一些关于它的信息，并说您想听听人们的想法。您不必将整个项目更新都集中在此方面，但它可能会导致后续或有趣的走廊讨论。
稳定¶
或者，本节中的职责可以委派给个人来管理本地稳定维护。
确保稳定分支的门控没有中断。
与稳定发布团队协调，以确保在回移植关键修复程序或着陆足够的小修复程序时执行发布。
一次性任务¶
在必要时，可以随时执行以下操作。
Bug 冲刺
API 冲刺
技巧和窍门¶
现在，这份文档告诉了您所有可以做的事情，以下是一些社区技巧，可以帮助您改善作为 OpenStack 项目领导者的体验。
如果您能想到任何其他可能有帮助的事情，请不要犹豫，从 OpenDev 克隆 project-team-guide 仓库并提交补充。
确保您的电子邮件过滤器设置为捕获包含 [ptl] 或您的项目名称的主题标题的邮件。
如果您尚未加入，请加入 #openstack-tc IRC 频道，以讨论社区目标或与您的项目相关的任何内容。
即使您有发布联络人，也请加入 #openstack-release 频道。
项目更新邮件：当您开始上手时，这是一个可选的补充。将偶尔的项目团队更新邮件发送到 openstack-discuss 邮件列表，是让兼职贡献者了解项目内发生的变化的好方法。例如，Keystone 团队每周提供更新：http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006799.html
确保 IRC 每周会议的信息和议程是最新的：http://meetings.opendev.org
在每周会议期间留出时间来查看项目中最早未处理的评审。结果的操作应该是以下之一：补丁被合并，被 -1，或者如果无法实时完成评审，则有人被分配跟进。这是减少大量积压和潜在技术债务的好方法。
IRC 会议中的礼貌 ping：每个人都有忙碌的生活，脱离社区。想办法 ping 对参加团队会议感兴趣的团队成员是一个有用的补充。
另一种方法是鼓励团队成员配置他们的 IRC 客户端，以突出显示特定的关键字。例如 #startmeeting <PROJECT> 或 foo-team。
管理优先级评审。这可以通过在 Gerrit 中添加评审优先级列或在 spec 仓库中维护优先级 blueprint 来完成。以下是 Cinder 团队实施评审优先级列的示例：https://review.opendev.org/#/c/620664/
如何成功地委派¶
委派是您作为 OpenStack PTL 的角色的重要组成部分。有很多任务，我们知道跟上所有任务有多么困难。有些项目比其他项目更幸运，周围有更多的人可以委派任务，但并非总是如此——无论项目规模如何。
以下是一些来自社区成员的技巧和窍门，可以帮助您委派任务
通过 IRC 或邮件列表联系团队成员——每个人沟通方式不同。
详细说明您的要求。含糊不清的要求往往会被忽略，因为人们有自己的工作量。但是，如果您需要某人主持团队会议、总结论坛或 PTG，甚至修复一个错误，细节是获得结果的关键。
不要等到最后一分钟才寻求帮助。如果您有一个大型项目在眼前，请在开始时找到人来帮忙——即使这个人是您的备份，以防万一出现问题。
如果您找不到委派人，可以接受放弃某些事情。举行团队会议或完美地计划一切并非至关重要。以下是一些帮助您处理无法委派任务的技巧
不要害怕向其他项目团队、TC 或 UC 寻求帮助。TC 和 UC 旨在尽可能提供指导和支持。
不要当英雄。确保人们知道您遇到了麻烦，并且一些可交付成果可能无法完成。我们关心我们的社区成员，重要的是您感到支持，而不是被压垮。
移交 PTL 职责¶
您正在考虑离开吗？希望鼓励该角色的健康轮换？也许您已经决定您受够了并且精疲力竭。或者也许您正在搬到新的角色或公司，OpenStack 不再是您的工作重点。有人需要或想要离开 PTL 职位有很多原因。虽然社区会因为您辞职而感到难过，但这却是该职位生命周期的一部分，并且经常看到新的人和新的想法进入领导职位，这是一件积极的变化。
移交 PTL 职位并不容易，它不像简单地 ping 一个活跃的贡献者并询问他们是否感兴趣。最重要的是让个人了解本文档中涵盖的内容，因为这可能是他们尚未遇到的事情。
注意
有一些重要的信息需要传递，但您永远无法完全转移知识。没关系！
为了让您和他们更容易完成这个过程，在辞职前提供 PTL 指导。如果您知道您的状况将提前发生变化，为什么不联系整个团队并询问谁感兴趣以及您是否可以在最后几个月指导他们？
如果没有人愿意，请在辞职前联系 OpenStack TC，以便他们了解当前情况并可以介入提供帮助。
