为Metabase做贡献

感谢

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

在本指南中，我们将讨论Metabase是如何构建的。这应该会给你一个很好的过程感和你可能在哪方面适合。

一般来说，我们喜欢为每个拉取请求保留一个开放的问题，作为讨论任何错误或建议改进的性质的地方。每个拉取请求应解决一个问题，并包含修复以及描述拉取请求和验证PR是否解决相关问题的测试。

对于错误修复，请将拉取请求提交到针对master分支。偶尔，我们的团队会将选定的关键错误修复回滚到稳定/发布分支。

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

贡献者许可协议

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

我们试图构建什么

Metabase的一切都是让非技术用户能够访问他们组织的数据库。我们试图最大化那些理解他们的业务、具有量化倾向，但可能只熟悉Excel的人能够舒适使用的功能。

请记住Metabase项目这些目标的重要性。很多时候，提案会被标记为“超出范围”或被降级。这并不意味着提案没有用，或者我们不感兴趣将其作为侧项目或实验分支来实现。然而，这意味着在短期内我们不会将核心团队或贡献者指向它。对于稍微超出范围的议题，将保持开放状态，以防社区支持（理想情况下还有贡献）。

为了了解最终目标，请务必阅读Metabase禅意。

我们的产品流程

核心团队运行着一个相当明确的产品流程。它正在积极调整，但以下内容是在撰写本文时的一个相当忠实描述。在提交PR之前，你应该对我们如何工作有一个清晰的认识。

A) 从社区识别产品需求

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

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

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

C) 设计功能

一旦功能被定义，通常由产品设计师承担。在这里，他们将制作低保真度原型，获取用户的反馈和社区的反馈，并进行迭代。

一旦主要的用户体验流程已经确定，将会有高保真度的视觉设计。

准备设计的功能将被标记为需要设计。一旦功能有一个相对完整的外观设计，应该被标记为需要帮助。

D) 构建功能

一旦功能被标记为需要帮助，就认为它已准备好构建。核心团队成员（或你这位极有帮助的人）可以开始工作。

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

一旦一个人或更多人开始处理一个功能，它应该被标记为进行中。一旦有一个分支和一些代码，将打开一个pull request，将其链接到功能以及任何相关的议题。

E) 验证和合并

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

如果一切顺利，功能将被编码、验证，然后合并PR！大家加油鼓劲。

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

如何帮助

起点是熟悉Metabase产品，并了解其用法。如果你在工作中使用它，那太好了！如果没有，下载Metabase并尝试使用它。阅读文档，并总体上了解产品的流程。

以下是一些你可以帮助的方式，按与我们协调和互动程度递增的顺序

帮助确定Metabase可以解决的问题和需求

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

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

在discourse.metabase.com和新问题上花费时间，并尝试重现报告的bug。对于你在数据库方面有丰富知识的人，帮助他们解决问题。谁知道呢，他们将来可能也会帮助你。

当回复时，如果你理解我们的优先级框架，那将是有帮助的。

告诉你的朋友

让你的朋友了解Metabase。在你所在地区建立一个用户组。转发关于我们的信息。写一篇关于你如何使用Metabase的文章，并分享你所学到的。

修复bug

根据我们的定义，“bug”是指程序根据设计或规格没有按预期执行的情况。这些通常涉及有明确定义的正确行为的议题。通常，安全地抓取其中一个，修复它，并提交PR（带测试！）是没有太多问题的，除非PR涉及大量代码。如果我们要求你进行小的修改或添加更多测试，请不要生气。我们在代码覆盖率和编码风格上有点强迫症。

帮助编写文档

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

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

在开发功能

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

在设计已经完成的情况下，我们总能得到一些帮助。在pull request或issue上留言，并主动提出帮助。

一般来说，任何需要帮助的问题都是合适的。

YOLO，只提交PR

如果你想出了些真正酷的东西，并想与我们分享，只需提交PR。如果它没有经过上述流程，我们可能不会直接合并，但如果它很有吸引力，我们非常愿意通过代码审查、设计审查以及一般的挑剔来帮助你，以确保它适合我们的代码库。