贡献 Metabase

感谢

首先，感谢您对 Metabase 的兴趣并愿意贡献！

在本指南中，我们将讨论 Metabase 是如何构建的。这将让您很好地了解我们的流程以及您可能希望如何融入其中。

一般来说，我们喜欢为每个拉取请求（pull request）创建一个开放的 issue，作为讨论任何 bug 或提议改进性质的地方。每个拉取请求应解决一个问题，并包含修复以及对拉取请求的描述和验证 PR 修复相关问题的测试。

对于错误修复，请将拉取请求提交到 master 分支。我们团队会不定期将选定的关键错误修复反向移植到稳定/发布分支。

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

贡献者许可协议

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

我们正在努力构建什么

Metabase 的核心目标是让非技术用户能够访问其组织的数据。我们力求最大限度地提高一个理解其业务、有量化倾向但可能只习惯使用 Excel 的人可以轻松使用的功能数量。

牢记 Metabase 项目的这些目标很重要。很多时候，提案会被标记为“超出范围”或被降级。这并不意味着该提案没有用，或者我们不感兴趣将其作为副项目或实验性分支来完成。但是，这确实意味着我们短期内不会将核心团队或贡献者引导到它。稍微超出范围的 issue 将保持开放，以防获得社区支持（理想情况下是贡献）。

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

我们的产品流程

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

A) 从社区中识别产品需求

我们积极从我们的社区、用户群以及我们内部使用 Metabase 的过程中寻找新的功能想法。我们专注于潜在的“问题”或“需求”，而不是针对特定功能的要求。虽然有时会根据要求构建建议的功能，但我们经常发现它们涉及对现有功能的更改，甚至可能是对底层问题的完全不同的解决方案。这些通常会收集在多个 issue 中，并标记为 提案。

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

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

C) 设计功能

功能定义后，通常会由产品设计师接手。他们将制作低保真模型，从用户和社区获取反馈，并进行迭代。

一旦主要的 UX 流程确定，就会有高保真视觉设计。

准备好进行设计的功能会打上 需要设计 标签。一旦某个功能拥有相对完整的视觉设计，就应该打上 需要帮助 标签。

D) 构建功能

一旦某个功能被打上 需要帮助 标签，就认为它已准备好构建。核心团队成员（或您，乐于助人的您）就可以开始着手处理它。

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

一旦有一个或多个人开始着手开发某个功能，就应该将其标记为 进行中。一旦有分支和一些代码，就会打开一个拉取请求，并将其链接到该功能以及为该功能提供信息的任何问题。

E) 验证与合并

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

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

如果拉取请求中存在缺少测试、代码风格问题或特定的架构问题，应在合并前修复。我们对代码和产品质量有非常高的要求，并且保持这一点向前发展很重要，所以请在这里耐心一点。

帮助方式

起点是熟悉 Metabase 产品，并了解其使用方法。如果您正在工作中使用它，那太棒了！如果没有，请下载 Metabase 并试用。阅读文档，并大致了解产品流程。

以下是一些您可以提供帮助的方式，按与我们协调和互动程度递增的顺序排列：

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

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

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

花时间浏览 discourse.metabase.com 和新 issue，并尝试重现报告的 bug。对于在数据库方面遇到困难且您有丰富知识的用户，请帮助他们。谁知道呢，也许他们将来会帮助您解决一些问题。

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

告诉您的朋友们

让您的朋友们知道 Metabase。在您的地区成立一个用户组。在 Twitter 上发布关于我们。撰写博客，介绍您如何使用 Metabase，并分享您的所学。

修复 bug

根据我们的定义，“Bug”是指程序行为与设计或规范预期不符的情况。这些通常针对行为明确的 issue。通常可以安全地选择其中一个，修复它，然后提交 PR（带测试！）。除非 PR 涉及大量代码，否则这些 PR 会顺利合并。如果我们要求您进行小的修改或添加更多测试，请不要感到被冒犯。我们对代码覆盖率和编码风格有点强迫症。

帮助文档

文档很多，这意味着保持其最新状态很难。如果您发现不一致、错误或过时的信息，请帮助我们保持其最新！

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

从事功能开发

某些功能，例如数据库驱动程序，没有任何面向用户的可见元素。这些是非常好的贡献起点，因为它们通常不需要太多的沟通、关于权衡的讨论和整体流程。

在设计已完成的情况下，我们总是需要一些帮助。在拉取请求或 issue 中发表意见并主动提供帮助。

一般来说，需要帮助 中的任何问题都是可以解决的。

#YOLO 直接提交 PR

如果你想出了一个很酷的东西，并想与我们分享，直接提交 PR 即可。如果它没有经过上述过程，我们可能不会按原样合并它，但如果它引人注目，我们非常乐意通过代码审查、设计审查以及普遍的强迫症式挑剔来帮助你，使其融入到我们的其余代码库中。