为 Metabase 做贡献

感谢您

首先，感谢您对 Metabase 感兴趣并希望做出贡献！

在本指南中，我们将讨论 Metabase 是如何构建的。这应该让您对我们的流程以及您可能希望参与的方面有一个很好的了解。

一般来说，我们喜欢为每个拉取请求设置一个开放的 issue，以便讨论任何错误或建议改进的性质。每个拉取请求都应该解决一个 issue，并且包含修复程序以及拉取请求的描述和验证 PR 修复了相关 issue 的测试。

对于错误修复，请提交拉取请求以定位 master 分支。我们的团队会不时地将选定的关键错误修复反向移植到 stable/release 分支。

对于重要的功能添加，预计已在附加的 issue 中进行了讨论。任何需要做出重大决定的功能都需要编写明确的设计文档。本文档的目标是明确任何给定功能实现将包含的假设、约束和权衡。重点不是生成文档，而是允许讨论引用特定的建议设计，并允许其他人考虑给定设计的影响。

贡献者许可协议

我们不喜欢被起诉，因此在合并任何拉取请求之前，我们需要每位代码贡献者签署一份 贡献者许可协议。

我们正在尝试构建什么

Metabase 的全部意义在于让非技术用户能够访问其组织的数据。我们正在努力最大限度地提高那些了解其业务、具有定量分析能力但可能只熟悉 Excel 的人可以舒适使用的功能。

牢记 Metabase 项目的这些目标非常重要。许多时候，提案将被标记为“超出范围”或以其他方式降低优先级。这并不意味着提案没有用，或者我们对看到它作为副项目或实验性分支完成不感兴趣。但是，这确实意味着我们不会在近期内将核心团队或贡献者指向它。稍微超出范围的 issue 将保持开放状态，以防出现社区支持（最好是贡献）。

要了解最终目标，请务必阅读 Metabase 之禅。

我们的产品流程

核心团队运行着一个相当完善的产品流程。它正在积极调整，但以下是对撰写本文时其相当忠实的描述。在开始 PR 之前，您应该清楚地了解我们的工作方式。

A) 从社区识别产品需求

我们积极地从我们的社区、用户群以及我们自己对 Metabase 的内部使用中寻找新的功能创意。我们专注于潜在的问题或需求，而不是对特定功能的请求。虽然有时建议的功能会按需构建，但我们经常发现它们涉及对现有功能的更改，甚至可能是解决潜在问题的完全不同的解决方案。这些通常会收集在许多 issue 中，并标记为 提案

B) 将这些需求综合成具体的功能

我们通常会将一组 issue 或建议收集到一个新的顶级功能概念中。通常，我们会创建一个工作文档，其中收集所有关于该功能旨在做什么以及更重要的不做什么的“开放性问题”。我们会与我们的用户聊天，可能会进行深入访谈，并通常尝试严格定义该功能。如果某个功能似乎需要时间来讨论和确定范围，则会将其标记为 提案/正在讨论，以表示它仍在积极讨论中。

C) 设计功能

一旦定义了功能，通常会由产品设计师负责。在这里，他们将制作低保真模型，从我们的用户和社区获得反馈，并进行迭代。

一旦主要的 UX 流程被调整到位，就会有一个高保真视觉设计。

准备好进行设计的功能被标记为 需要设计。一旦某个功能有了相当完整的视觉设计，就应该标记为 需要帮助。

D) 构建功能

一旦某个功能被标记为 需要帮助，它就被认为可以构建了。核心团队成员（或者你，非常乐于助人的人）可以开始着手处理它。

如果您正在构建用户将在 Metabase 中看到的内容，请参考样式指南（位于 https://storybook.metabase.com），了解如何以及何时使用各种 Metabase UI 元素。

一旦一个人或多个人开始处理某个功能，就应该将其标记为 进行中。一旦有分支+一些代码，就会打开一个拉取请求，链接到该功能 + 任何被拉到一起以告知该功能的 issue。

E) 验证和合并

所有涉及重大更改的 PR 都应进行审核。请参阅我们的 代码审查流程。

如果一切顺利，该功能将被编码、验证，然后拉取请求将被合并！大家击掌庆祝。

如果拉取请求中缺少测试、代码风格问题或特定的架构问题，则应在合并之前修复它们。我们在代码和产品质量方面都有非常高的标准，并且重要的是要保持这一点，所以请耐心等待。

帮助方式

起点是熟悉 Metabase 产品，并了解其工作原理。如果您在工作中使用它，那就太好了！如果不是，下载 Metabase 并试用一下。阅读文档并大致了解产品的流程。

以下是一些你可以提供帮助的方式，按照与我们协作和互动的程度递增排序

帮助识别 Metabase 可以解决的需求和问题

如果你想提供帮助，请试用 Metabase。在你的公司使用它，并反馈你喜欢、不喜欢的地方以及遇到的任何问题。尽可能帮助我们理解你的数据模型、所需的指标和常见的使用模式。这些信息直接影响产品的质量。你告诉我们你面临的问题类型越多，我们就越能更好地解决这些问题。

帮助我们分类并支持其他用户

花时间在 discourse.metabase.com 和新的 issue 上，尝试重现报告的 bug。对于那些在使用数据库时遇到问题，而你又掌握相关知识的人，请帮助他们。谁知道呢，也许将来他们会反过来帮助你。

如果你在回复时理解我们的 优先级框架，这将很有帮助。

告诉你的朋友们

让你的朋友们了解 Metabase。在你所在的地区发起一个用户组。 在 Twitter 上发推文提及我们。写博客分享你如何使用 Metabase，以及你学到的东西。

修复 bug

按照我们的定义，“Bug”是指程序没有按照设计或规范执行预期操作的情况。这些通常限定于存在明确定义的正确行为的问题。通常可以放心选择其中一个 bug，修复它，并提交 PR（附带测试！）。这些 PR 通常会被合并，除非它涉及到大量代码。如果我们要求你做一些小的修改或添加更多的测试，请不要介意。我们对代码覆盖率和编码风格有点强迫症。

帮助完善文档

有大量的文档，这意味着保持文档更新很困难。如果你注意到不一致、错误或过时的信息，请帮助我们保持文档的最新状态！

请注意，目前我们不接受文档的翻译。我们支持 应用内翻译，并且只支持覆盖率达到 100% 的语言。但是，1) 应用内文本比我们的文档短几个数量级，2) 其更新速度较慢，并且 3) 有很多人提供帮助。我们可能会在未来考虑支持多种语言的文档，但目前我们需要将资源集中在改进现有文档（并扩展文档以包含我们正在添加的所有新功能）上。

开发新功能

有些功能，例如数据库驱动程序，没有任何面向用户的像素。这些是开始贡献的好地方，因为它们不需要太多的沟通、关于权衡的讨论和一般的流程。

在已经完成设计的情况下，我们总是需要一些帮助。在 pull request 或 issue 中插话，并提供帮助。

总的来说，任何在 Help Wanted 标签下的 issue 都是可以参与的。

#YOLO 提交一个 PR 吧

如果你提出了非常酷的东西，并想与我们分享，只需提交一个 PR。如果它没有经过上述流程，我们可能不会按原样合并它，但如果它很有吸引力，我们非常愿意通过代码审查、设计审查和一般的强迫症式挑剔来帮助你，使其融入我们代码库的其余部分。