贡献 Metabase

感谢

首先，感谢您对 Metabase 的兴趣以及您想要贡献的热情！

在本指南中，我们将讨论 Metabase 是如何构建的。这应该能让您很好地了解我们的流程以及您可能适合的领域。

通常，我们希望每个拉取请求（pull request）都有一个开放的议题（issue）作为讨论任何错误或建议改进的场所。每个拉取请求应解决一个单一问题，并包含修复本身、拉取请求的描述以及验证该拉取请求是否修复了所述问题的测试。

对于错误修复，请将拉取请求提交到 master 分支。我们团队会不时将选定的关键错误修复回溯（backport）到稳定/发布分支。

对于重要的功能添加，预计将在相关议题中进行讨论。任何需要做出重大决定的功能都需要撰写明确的设计文档。这份文档的目标是明确指出任何给定功能实现所包含的假设、约束和权衡。其目的不是为了生成文档，而是为了让讨论能够引用特定的提议设计，并允许其他人考虑给定设计的影响。

贡献者许可协议

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

我们正在努力构建什么

Metabase 的核心是让非技术用户能够访问他们组织的数据。我们正在努力最大化那些懂业务、有量化思维但可能只熟悉 Excel 的人能轻松使用的功能。

牢记 Metabase 项目的这些目标很重要。很多时候，提议会被标记为“超出范围”或被降级。这并不意味着该提议没有用，也不意味着我们不会有兴趣将其作为副项目或实验性分支来完成。然而，这意味着我们近期不会将核心团队或贡献者引导到它。略微超出范围的议题将保持开放，以防获得社区支持（最好是贡献）。

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

我们的产品流程

核心团队遵循一套定义明确的产品流程。它正在积极调整中，但以下是撰写本文时对其的忠实描述。在提交拉取请求（PR）之前，您应该清楚我们如何工作。

A) 从社区识别产品需求

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

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

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

C) 设计功能

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

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

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

D) 构建功能

一旦功能被标记为寻求帮助，它就被认为可以开始构建了。核心团队成员（或您，这位乐于助人的伙伴）可以开始着手开发。

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

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

E) 验证和合并

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

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

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

贡献方式

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

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

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

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

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

花时间在 discourse.metabase.com 和新议题上，尝试重现报告的错误。对于在数据库方面遇到困难且您拥有丰富知识的人，请帮助他们。谁知道呢，也许他们将来也会帮助您。

如果您在回复时了解我们的优先级框架，将会有所帮助。

告诉您的朋友

让您的朋友了解 Metabase。在您所在地区成立一个用户组。在 Twitter 上提及我们。撰写博客，分享您如何使用 Metabase 以及您学到的知识。

修复错误

根据我们的定义，“错误”是指程序未能按照设计或规范执行预期操作的情况。这些通常限定于具有明确定义的正确行为的议题。通常可以安全地选择其中一个，进行修复，并提交一个拉取请求（附带测试！）。除非拉取请求涉及大量代码，否则它们将顺利合并。如果我们要求您进行小幅修改或添加更多测试，请不要介意。我们对代码覆盖率和编码风格有点强迫症。

帮助撰写文档

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

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

开发功能

某些功能（例如数据库驱动程序）不涉及任何用户可见的界面。这些是贡献的绝佳起点，因为它们不需要太多的沟通、关于权衡的讨论和一般流程。

在设计已经完成的情况下，我们随时都需要帮助。请在拉取请求或议题中积极参与并提供帮助。

一般来说，寻求帮助 中的任何议题都可以自由认领。

#人生苦短立即提交PR

如果您想出了非常酷的东西并想与我们分享，尽管提交拉取请求。如果它没有经过上述流程，我们可能不会按原样合并它，但如果它很有吸引力，我们非常乐意通过代码审查、设计审查和一般性的细节挑剔来帮助您，使其符合我们其余的代码库。