贡献 Metabase

感谢

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

在本指南中，我们将讨论 Metabase 的构建方式。这应该能让您对我们的流程以及您可能想要融入的地方有一个很好的认识。

通常，我们希望为每个拉取请求（pull request）提供一个开放的问题，以便讨论任何错误或拟议改进的性质。每个拉取请求都应解决一个问题，并包含修复以及对拉取请求的描述和验证该 PR 是否修复了所涉及问题的测试。

对于 bug 修复，请将拉取请求提交到 `master` 分支。我们会不时地将选定的关键 bug 修复移植到 stable/release 分支。

对于重大的功能添加，预计将会在附带的问题中进行讨论。任何需要做出重大决策的功能都必须编写明确的设计文档。该文档的目标是明确任何给定功能实现所包含的假设、约束和权衡。其目的不是生成文档，而是允许讨论引用特定的设计提案，并允许他人考虑特定设计的含义。

贡献者许可协议

我们不希望被起诉，因此在合并任何拉取请求之前，我们需要每个贡献代码的人签署一份《贡献者许可协议》。

我们正在努力构建什么

Metabase 的核心在于让非技术用户能够访问其组织的数据。我们正努力最大限度地发挥一个能够舒适地由了解其业务、具备量化思维但可能只熟悉 Excel 的人使用的能力。

牢记 Metabase 项目的这些目标非常重要。许多提案可能会被标记为“超出范围”或被推迟。这并不意味着该提案没有用，或者我们不会对其作为副项目或实验性分支的实现感兴趣。然而，这意味着我们不会在短期内将其指向核心团队或贡献者。略微超出范围的问题将保持开放状态，以备社区支持（并希望做出贡献）。

要了解最终目标，请务必阅读《Metabase 的禅意》。

我们的产品流程

核心团队有一个相当明确的产品流程。它正在积极调整中，但以下描述在撰写本文时是相当准确的。在开始提交 PR 之前，您应该清楚地了解我们的工作方式。

A) 从社区识别产品需求

我们积极从社区、用户群以及我们自己使用 Metabase 的内部情况中寻找新功能创意。我们关注的是根本的问题或需求，而不是对特定功能的请求。虽然有时会按要求构建建议的功能，但我们经常发现它们涉及对现有功能的更改，以及可能对根本问题产生的完全不同的解决方案。这些通常会收集在一些问题中，并标记为 Proposal

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

我们通常会将一组问题或建议收集成一个新的顶层功能概念。通常我们会创建一个工作文档，其中包含有关该功能应做什么以及更重要的是不做什么的所有“待解决问题”。我们会与用户聊天，可能进行深度访谈，并尽力精确定义该功能。如果一个功能似乎需要时间来讨论和范围界定，它将被标记为 Proposal/Being Discussed，以表明它仍在积极讨论中。

C) 设计功能

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

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

已准备好进行设计的特性将被标记为 Design Needed。一旦一个功能有了相当完整视觉设计，它应该被标记为 Help Wanted。

D) 构建功能

一旦一个功能被标记为 Help Wanted，就意味着它可以构建了。核心团队成员（或者您，您这个非常乐于助人的家伙）可以开始处理它。

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

一旦一个或多个开发者开始处理一个功能，它应该被标记为 In Progress。一旦有了分支+一些代码，就会打开一个拉取请求，并链接到该功能+为该功能提供信息的所有问题。

E) 验证和合并

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

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

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

如何提供帮助

起步阶段是熟悉 Metabase 产品，并了解其操作。如果您在工作中使用它，那太好了！如果不是，请下载 Metabase 并玩一玩。阅读文档，总体上感受一下产品的流程。

以下是一些您可以提供帮助的方式，按协调+互动程度递增排列：

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

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

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

花时间在 discourse.metabase.com 和新问题上，并尝试重现报告的 bug。对于那些在数据库方面遇到麻烦但您拥有丰富知识的人，请帮助他们。谁知道呢，也许他们将来也会在某件事上帮助您。

了解我们的优先级框架来回复会很有帮助。

告诉你的朋友

让您的朋友了解 Metabase。在您所在的地区组织一个用户组。在 Twitter 上分享我们。写博客介绍您如何使用 Metabase，并分享您的经验。

修复 bug

根据我们的定义，“Bug”是指程序未按照设计或规范执行的情况。这些通常范围界定在有明确定义正确行为的问题。通常可以安全地处理其中一个问题，修复它，然后提交 PR（附带测试！）。这些 PR 将被合并，除非 PR 触及大量代码，否则不会有太多麻烦。如果我们要求您进行小的修改或添加更多测试，请不要感到冒犯。我们对代码覆盖率和编码风格有点强迫症。

帮助改进文档

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

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

开发功能

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

在已经完成设计的情况下，我们总是需要帮助。在拉取请求或问题中参与进来，并主动提供帮助。

总的来说，Help Wanted 中的任何问题都可以进行。

# YOLO 直接提交 PR

如果您想到了很棒的东西，并想与我们分享，请直接提交 PR。如果您没有经过上述流程，我们可能不会按原样合并它，但如果它很有吸引力，我们非常乐意通过代码审查、设计审查和普遍的强迫症式挑剔来帮助您，使其能够融入我们的代码库。