如何参与 Masakari（更多参与方式）

所以你想更多地参与 Masakari 吗？或者你是 Masakari 的新手，想知道从哪里开始？

我们正在努力构建简单的方式，帮助你获取帮助和想法，了解更多关于 Masakari 的信息以及 Masakari 社区的工作方式。

我该如何开始？

这方面有很多全局文档

这里有更多通用信息，非 Masakari 特定的信息

我应该做什么？

所以你正在开始你的 Masakari 之旅，从哪里开始比较好？

如果你想在修改任何内容之前了解 Masakari 的工作方式（一个好主意！），我们建议查看带有 -1 和 -2 的评论，并了解它们为什么被否决。一旦你有了理解，就开始审查补丁。 询问你不理解的事情是可以的。 即使你看到一些潜在的问题，也可以给出 +0 的评价。

一旦你准备好编写代码，可以查看一些已经标记为低垂的果实的工作

如何将我的功能加入？

将你的功能加入的最佳方式……好吧，这取决于情况。

首先专注于解决你的问题和/或用例，不要执着于你所拥有的代码能够合并。 事情可能需要在你讨论你的需求与 Masakari 当前的使用方式相匹配后进行重大修改。 好消息是，这个过程应该会让你拥有一个更灵活的功能，而不会让你陷入你当前的思维方式。

获得代码合并的关键部分是帮助审查其他人的代码。 对他人代码的优秀审查将有助于释放更多的核心审查人员的时间来查看你自己的补丁。 此外，你将在他们审查你的代码时了解审查人员的思路。

另外，弄清楚是否有任何正在进行的工作在阻止你的功能，并帮助加快这些工作的速度。 规范审查过程应该有助于这项工作。

有关我们流程的更多详细信息，请参阅：Masakari 团队流程。

对一个优秀的贡献者有什么期望？

TODO - 需要更多这方面的信息

与 Masakari 社区合作的技巧

以下是一些关于参与 Masakari 社区的技巧

  • IRC

    • 我们经常在 #openstack-masakari 中交流

    • 请在其中向我们提问，我们会尽力帮助你

    • 不确定是否要提问？ 欢迎收听其他人的问题

    • 我们建议你设置一个 IRC bouncer：https://wiki.openstack.org/wiki/IRC

  • Email

    • 在邮件列表中使用 [masakari] 标签

    • 筛选 [masakari] 和 [all] 可以帮助控制列表

  • 保持开放

    • 例如，不要私下审查你的团队的代码，请在 gerrit 中公开进行

    • 例如，准备好公开讨论你遇到的问题，而不是“理论”问题

    • 这样你就可以开始获得更广泛社区的信任

  • 遇到问题了？ 请提问！

    • 请尽早提出任何问题并提问

    • 我们希望在你感到沮丧或恼怒之前帮助你

    • 不确定该问谁？ 就在 IRC 中提问。

  • 先谈论问题，再谈论解决方案

    • 不要考虑“合并你的补丁”，而是考虑“解决你的问题”

    • 对话会更有效率

  • 重要的不是决定，而是决定背后的原因

    • 不喜欢社区的发展方向？

    • 请询问我们为什么会朝着那个方向发展，并参与辩论

    • 如果你不这样做，我们就无法从你提供的意见中学习

  • 没有人能决定，陷入僵局，谁能帮助我？

    • 这很少见，但会发生

    • ……但如果你不问，他们很难帮助你

流程

你可能会觉得你面临着流程的壁垒。 我们是一个庞大的社区，为了确保正确的沟通发生，我们确实使用最少的流程。

如果你发现有些东西没有道理，请

  • 提问以了解它发生的原因

  • 如果你知道更好的方法，请畅所欲言

  • 一种“更好的方法”可能是删除流程，如果它不再有帮助

要了解更多关于 Masakari 流程的信息，请阅读 Masakari 团队流程。

为什么要进行任何流程？

为什么要创建一个 bug 或 blueprint 来跟踪你的代码审查？ 这可能看起来像多余的流程，但通常有一个很好的理由。

我们有很多代码需要审查，并且我们有工具来尝试优先处理真正重要的代码审查。 如果你的代码真的很重要，但我们的工具没有识别出来，你可能只是迷失在一个巨大的队列的底部。

如果你有一个 bug 修复，你已经做了大量的工作来识别问题，并测试你的修复，并提交它。 通过添加一个 bug 报告，你让其他遇到相同问题的人更容易找到你的工作，可能为你节省了你经历的数小时的痛苦。 幸运的是，这让所有这些人有时间修复不同的 bug，所有这些 bug 可能会影响你，如果你没有给他们时间去修复的话。

蓝图也是如此。 你已经找到了如何解决你的痒痒的方法，让我们告诉其他人关于你添加的这个很棒的新功能，以便他们可以使用它。 此外，它阻止了有类似想法的人经历所有创建功能的痛苦，只有为了发现你已经准备好并合并到最新版本中。

希望这让你了解了我们为什么对我们所做的事情应用了一点点流程。 话虽如此，我们需要忘记旧习惯才能前进，可能还有更好的方法，我们愿意尝试它们。 请帮助成为解决方案的一部分。

如果我不是 masakari-core，为什么要进行代码审查？

代码审查是开发者社区的生命线。

关于如何进行良好的审查以及任何人都可以成为审查者，这里有一个很好的讨论：https://docs.openstack.org/infra/manual/developers.html#peer-review

在草案流程指南中，我讨论了如何进行审查可以帮助你的代码更快地合并：Masakari 团队流程。

让我们看看为什么参与代码审查真的对你有所帮助的一些原因

  • 进行更多的审查，并了解其他审查者注意到了什么，将帮助你更好地了解合并到主分支的代码的期望

  • 有更多的非核心人员进行出色的审查，可以减少核心审查人员需要做的审查工作，以便我们能够合并更多的代码

  • 同理心是幸福社区的关键之一。 如果你习惯于进行代码审查，你将更好地理解你在审查你的代码时收到的评论。 当你进行更多的代码审查，并看到其他人注意到了什么时，你将更好地了解人们在对你的代码应用 +2 时在寻找什么。

什么类型的代码审查评论最有用？ 这里有一些最好的

  • 根本缺陷是最大的发现。 补丁会破坏所有现有用户或现有功能吗？

  • 行为的一致性非常重要。 这段代码是否与 Masakari 中其他地方发生类似事情的方式不同？

  • 代码是否易于维护、经过充分测试且易于阅读？ 代码的阅读次数比编写次数多一个数量级，因此针对代码的读者进行优化，而不是编写者。

让我们看看人们在开始进行代码审查时遇到的一些问题

  • 我的 +1 没有任何意义，我为什么要费心？

    • 所以你的 +1 确实有帮助。 一些非常有用的 -1 投票导致 +1 投票有助于将代码置于位置

  • 何时使用 -1 与 0 与 +1

  • 我已经内部审查了这段代码，没有必要在外部添加 +1 了？

    • 请与你的公司谈谈，所有代码审查都在公开进行，这是一种更好的参与方式。 展示代码如何演变为上游，比尝试在上传进行公开审查之前“完善”代码要好得多。 如果你喜欢，可以使用草稿模式并将内容标记为 WIP，但请在 upstream 进行审查。

  • 我从哪里开始？ 我应该审查什么？

如何进行出色的代码审查？

https://docs.openstack.org/infra/manual/developers.html#peer-review

有关更多技巧，请参阅：如果我不是 masakari-core，为什么要进行代码审查？

我如何成为 masakari-core？

你不必成为 masakari-core 才能成为 Masakari 社区的宝贵成员。 你有很多方法可以提供帮助。 每一项有助于其他人使他们的补丁更接近合并的优质审查都有助于每个人更快地合并他们的代码。

成为 masakari-core 的第一步是学习如何成为 Masakari 社区的积极成员，包括学习如何进行出色的代码审查。

如果你觉得你有时间承诺所有 masakari-core 会员期望，请联系 Masakari PTL，他将能够为你找到 masakari-core 的现有成员来帮助指导你。 如果一切顺利，并且你看起来像一个合适的候选人，你的导师将联系 masakari-core 团队的其余成员，要求他们开始查看你的审查，以便他们能够投票支持你，如果你被提名加入 masakari-core。

我们鼓励尽可能在 #openstack-masakari 上进行所有指导，以便每个人都可以从你的讨论中学习和受益。

上述指导适用于所有想要学习如何更好地进行代码审查的人，即使你从不希望承诺成为 masakari-core。 如果你已经有导师，那很好，这个过程仅供那些仍在尝试寻找导师的人使用。 被录取到指导计划不会保证你最终会成为 masakari-core 的成员，它旨在帮助你提高，并帮助你进行可能导致成为 masakari-core 成员的参与和对话。

注意

你可以尝试在 IRC 消息中使用 masakari-ptl 和/或 masakari-core 以获得所需人员的回复。

注意

有关 Masakari 治理的基本信息，包括当前的 PTL（项目团队负责人），请访问 Masakari 的治理页面。

要查看 Masakari 核心审查员（又名核心）的当前列表，请参阅 Gerrit 上的 masakari-core 组。