為 Metabase 貢獻

感謝您

首先，感謝您對 Metabase 的興趣，以及想為其貢獻的心意！

在本指南中，我們將討論 Metabase 的建置方式。這應該能讓您對我們的流程以及您可能想在哪裡參與有良好的概念。

一般來說，我們希望每個提取請求都有一個開放的問題，作為討論任何錯誤或建議改進之處的場所。每個提取請求都應解決單一問題，並包含修復程式以及提取請求的描述和驗證 PR 修復問題的測試。

對於錯誤修復，請提交以 master 分支為目標的提取請求。我們的團隊會不時將選定的重要錯誤修復反向移植到 stable/release 分支。

對於重要的功能新增，預期會在附加的問題中進行討論。任何需要做出重大決策的功能都需要撰寫明確的設計文件。此文件的目標是明確說明任何給定功能實作將包含的假設、限制和權衡。重點不是產生文件，而是讓討論參考特定的建議設計，並讓其他人考慮給定設計的意涵。

貢獻者授權合約

我們不喜歡被告，因此在合併任何提取請求之前，我們需要每位程式碼貢獻者簽署貢獻者授權合約。

我們嘗試建置的內容

Metabase 的一切都是為了讓非技術使用者能夠存取其組織的資料。我們正在努力將可以被舒適地使用之能力最大化，使用者需要了解其業務、具有量化傾向，但可能只熟悉 Excel。

請務必牢記 Metabase 專案的這些目標。許多時候，提案會被標記為「超出範圍」或以其他方式降低優先順序。這並不表示提案沒有用，或者我們不會有興趣看到它作為副專案或實驗性分支來完成。但是，這確實表示我們不會在近期內將核心團隊或貢獻者指向它。稍微超出範圍的問題將保持開放，以防社群支援（最好是貢獻）。

為了了解最終目標，請務必閱讀Metabase 之禪。

我們的產品流程

核心團隊運行著定義相當完善的產品流程。它正在積極調整，但以下是對撰寫時的忠實描述。您應該在加入 PR 之前清楚了解我們的工作方式。

A) 從社群識別產品需求

我們積極從我們的社群、使用者群和我們自己內部使用 Metabase 中尋找新功能構想。我們專注於潛在的問題或需求，而不是特定功能的請求。雖然有時建議的功能會按要求建置，但我們經常發現它們涉及對現有功能的變更，以及可能完全不同的潛在問題解決方案。這些通常會收集在許多問題中，並標記為提案

B) 將這些需求綜合為具體功能

我們通常會將一組問題或建議收集到一個新的頂線功能概念中。通常我們會建立一個工作文件，收集關於該功能旨在做什麼的所有「未解決問題」，更重要的是不做什麼。我們會與使用者聊天、進行深入訪談，並盡力嚴格定義該功能。如果某個功能似乎需要時間來討論和確定範圍，則會標記為提案/正在討論中，以表示它仍在積極討論中。

C) 設計功能

一旦定義了功能，通常會由產品設計師負責。在這裡，他們將產生低傳真原型、從使用者和社群取得回饋，並反覆運算。

一旦主要 UX 流程已調整到位，就會有高傳真視覺設計。

準備好設計的功能會標記為需要設計。一旦某個功能具有相當完整的視覺設計，就應標記為徵求協助。

D) 建置功能

一旦某個功能標記為徵求協助，即視為已準備好建置。核心團隊成員（或您，非常樂於助人的人）可以開始著手進行。

如果您正在建置使用者將在 Metabase 中看到的內容，請參閱樣式指南（位於 https://storybook.metabase.com），以了解如何以及何時使用各種 Metabase UI 元素。

一旦一或多人開始著手處理某項功能，就應標記為進行中。一旦有分支 + 一些程式碼，就會開啟提取請求，連結到該功能 + 任何整合在一起以告知該功能的問題。

E) 驗證與合併

所有涉及重大變更的 PR 都應經過審查。請參閱我們的程式碼審查流程。

如果一切順利，該功能將被編碼、驗證，然後提取請求將被合併！大家擊掌慶祝。

如果提取請求中缺少測試、程式碼樣式問題或特定的架構問題，則應在合併前修復它們。我們在程式碼和產品品質方面都有非常高的標準，並且重要的是，這必須在未來繼續維持下去，因此請在這裡對我們保持耐心。

協助方式

起點是熟悉 Metabase 產品，並了解其運作方式。如果您在工作中使用它，那就太好了！如果沒有，下載 Metabase 並試用。閱讀文件並大致了解產品的流程。

以下是一些您可以協助的方式，依與我們協調 + 互動程度遞增排序

協助識別 Metabase 可以解決的需求和問題

如果您想提供協助，請試用 Metabase。在您的公司中使用它，並回報您喜歡、不喜歡的任何事物以及您遇到的任何問題。盡可能協助我們了解您的資料模型、所需指標和常見使用模式。此資訊直接影響產品的品質。您告訴我們您面臨的問題類型越多，我們就越能更好地解決這些問題。

協助我們分類並支援其他使用者

花時間在 discourse.metabase.com 和新問題上，並嘗試重現回報的錯誤。對於在資料庫方面遇到問題且您擁有豐富知識的人員，請協助他們。誰知道呢，也許他們最終會在未來協助您解決某些問題。

如果您了解我們的優先順序框架，在回覆時會很有幫助。

告訴您的朋友

讓您的朋友知道 Metabase。在您所在的地區成立使用者群組。在 Twitter 上發推文關於我們。撰寫部落格文章關於您如何使用 Metabase，並分享您學到的知識。

修復錯誤

根據我們的定義，「錯誤」是指程式未按照設計或規格預期執行的情況。這些通常限定於存在明確定義的正確行為的問題。抓取其中一個、修復它並提交 PR（附帶測試！）通常是安全的。除非 PR 觸及大量程式碼，否則這些將在沒有太多爭議的情況下合併。如果我們要求您進行少量修改或新增更多測試，請不要感到冒犯。我們對程式碼涵蓋率和編碼樣式有點強迫症。

文件協助

文件很多，這表示保持文件最新很困難。如果您發現不一致、錯誤或過時的資訊，請協助我們保持文件最新！

請注意，我們目前無法接受文件翻譯。我們支援應用程式內翻譯，並且僅支援涵蓋率達 100% 的語言。但是，1) 應用程式內文字比我們的文件短幾個數量級，2) 它們變更的速度較慢，以及 3) 我們有很多人提供協助。我們可能會考慮在未來支援多種語言的文件，但目前我們需要將資源集中在改進現有文件（並擴展它以包含我們新增的所有新功能）上。

處理功能

某些功能（例如資料庫驅動程式）沒有任何使用者面向的像素。這些是開始貢獻的好地方，因為它們不需要太多溝通、關於權衡的討論和一般流程。

在已經完成設計的情況下，我們始終可以使用一些協助。在提取請求或問題中插話並表示願意提供協助。

一般來說，徵求協助中的任何問題都是公平的。

#YOLO 只是提交 PR

如果您想出真正酷的東西，並想與我們分享，只需提交 PR 即可。如果它尚未通過上述流程，我們可能不會按原樣合併它，但如果它很引人注目，我們非常願意通過程式碼審查、設計審查和一般的強迫症挑剔來協助您，使其適合我們其餘的程式碼庫。