从零到英雄：OpenStack贡献者的第一周

Posted 2021-04-24 开源云中文社区

每年，数以百计的新贡献者开始使用OpenStack。大多数OpenStack项目都有成熟的代码库和已经从事数年开发的代码贡献者。确保新贡献者的方向正确通常是艰苦而耗时的。

当一个新手问如何做出贡献时，经验丰富的Stacker将直接把他们带到OpenStack Manuals。为什么呢？因为文档贡献过程与代码贡献过程相同，是一个新手开始的好地方。

OpenStack手册项目为OpenStack项目提供关键的入门安装、操作和管理文档。手册是一个好的起点，它提供一个无价的、每个项目如何操作的窗口。它使得贡献者能够熟悉Git和Gerrit工作流程，并且能够自信地审查、响应，以及对补丁和bug做出反应，而不会觉得自己是在破坏代码。

以下是第一周的提示和链接，毫不夸张地说，它们将帮助确保几天之后你可以感觉（并告诉你的老板！）自己是一个OpenStack贡献大师。

（场景：你已被告知要开始使用OpenStack，提高贡献，开始成为项目的核心。如果你不知道这是什么意思，从第0天开始。如果你了解概念，但想知道如何更多的参与，从第1天开始。）

第0天：

OpenStack手册项目为各种OpenStack项目提供文档，以促进OpenStack和开发和维护工具和流程来确保文档的质量和准确性。

OpenStack手册项目的团队结构与任何其他OpenStack项目相同。有一个项目技术主管（PTL）负责确保项目和个别任务的完成，并照顾个人贡献者的要求（如果有的话）。 PTL是这个项目的社区经理。

核心审核团队与PTL合作。核心审核人员可以+2并将内容合并到他们具有核心地位的项目。核心地位授予那些不仅在审查中表现出关心和智慧，而且还完成了足够数量的审查和提交的人。

OpenStack手册团队负责处理这个宝库（https://governance.openstack.org/tc/reference/projects/documentation.html#deliverables）。

没有限制谁才可以提交OpenStack手册的补丁。如果你希望开始，Contributor Guide是所有信息的来源。要开始贡献，使用First Timers部分设置帐户、Git和Gerrit。OpenStack手册项目像处理代码一样处理文档，所以有与开发相同的过程。OpenStack手册项目还建议你加入文档邮件列表（并带上一点自我介绍），然后加入Freenode的＃openstack-doc IRC频道。

第1天：

你已成功设置了Git和Gerrit工作流程，知道执行哪些命令来提交补丁以供审核。

我们建议先处理低难度的bug。这些bug已经被文档团队分类，并被指定为“快速修复”。问题应在bug报告或注释中描述。但是，如果你觉得没有充分了解bug，可以执行以下操作之一：

    首先，加入OpenStack Documentation Bug团队。将bug的状态设置为“未完成”，并要求报告者提供更多信息。
    

   如果bug解决了项目特定文档的问题，请联系该特定项目的文档联络人。

OpenStack手册项目的文档是用RST编写的，因此请确保你有适当的文本编辑器来处理格式和语法。你还可以找到所有文档贡献者应遵循的、通用的写作风格的准则，以确保所有技术出版物的一致性。

至此，你可以根据“First Timers”部分中所描述的工作流程修补bug并应用修复程序，也可以查看其他人的某些修补程序。查看文档修补程序是了解指南中内容的最佳方法之一。

第2天：

审查文档可能会令人困惑 ——人们用请求、bug报告甚至内容规范来回复补丁。

在每个发布周期的开始，项目团队在项目团队聚集（PTG）上完成他们的主要可交付成果。这会立即影响文档 ——上游的更改必须在文档中跟进。这通常是以bug报告的形式出现在文档中。该项目将通过在原始开发补丁的提交消息中标记DocImpact或通过提交一个新的bug并要求更新文档的请求，来向OpenStack手册团队报告bug。

当项目团队制定其关键的可交付成果时，文档团队还有机会决定在指南中需要满足哪些可交付成果。这可能涉及技术债务、存档，甚至可能涉及所有指南必须发生的大规模变化。这项工作通过规范跟踪。

所有要审核的补丁应链接到规范、bug报告，或至少有一个详细的、遵循良好实践指南的提交消息。

在查看补丁时，请确保提交者解释了他们为什么修复这个问题，并确保他们所说的与输出匹配。如果你需要构建文档以正确检查，你可以使用OpenStack手册项目的构建工具，或者可以使用gate作业在浏览器中检查构建。

以下是在审核其他人的补丁时要记住的一些准则：http://docs.openstack.org/contributor-guide/docs-review.html。

第3天：

在第1天，你推出第一个补丁，根据其他人的请求进行迭代。现在，根据指南，你的补丁可以与所需的+2，+1和+ 2a合并。如果你的补丁没有准备好并在第3天合并，不要担心。获得补丁审查并合并往往需要时间。

安全合并后，你需要知道接下来怎么办。如果你想参与一个特定的指南但不知道如何参与，见第4天。

如果你有兴趣参与但真的不知道想做什么，建议你继续修复bug。你可以在OpenStack-manuals的bugs栏目下找到OpenStack手册团队已经确认或分类的所有bug的列表。

不要处理标记为“新建”的、在“状态”列中没有“已确认”或“已分类”的，或已有受理人的任何bug。

第4天：

在邮件列表和“贡献者指南”中会发现有提及专业团队。为了确保每个指南都得到照顾以及针对指南的bug得到处理，文档小组已指定专业团队负责人。你可以在这里（https://docs.openstack.org/contributor-guide/team-structure.html）找到每个专业团队的名单。

要更多地参与某一个指南，请联系列出的相关个人。每个团队经常有需要新贡献者的项目。你不必专门只盯着某一个指南。

第5天：

现在你已经在手册上花了快一周的时间，这里有几个可能的路线：

    继续与文档团队合作，通过修复bug并与专业团队合作，了解OpenStack的安装、使用和管理。

    查找更多文档出口。每个开发项目都有为自己的开发人员量身定制的文档。你可以在docs.openstack.org/develop/PROJECTNAME找到更多信息。

    开始为感兴趣的项目工作！所有你需要做的是克隆相关的库，并开始！

祝你好运！

编译：Jonathan Zhang

来源：http://superuser.openstack.org/articles/new-openstack-contributor/

投稿邮箱：[e-mail]