VictoriaMetrics：AI 政策與貢獻指南

本文是 VictoriaMetrics 的貢獻指南，詳細介紹瞭如何參與社群、提交 Issue 和 Pull Request，並明確了 AI 工具的使用政策。

首先，貢獻者可以透過多種方式參與：加入 VictoriaMetrics 社群 Slack 幫助其他成員，在 GitHub 上提交 Issue、功能請求和問題，改進 VictoriaMetrics 文件，並藉助會議演講、部落格文章、社交媒體或與同事分享經驗來推廣專案。

關於 Issue，建立前務必使用 GitHub 搜尋檢查是否有重複。新 Issue 應使用英文撰寫，簡要描述問題及其所在環境，最好附上具體用例，以便維護者判斷是否存在變通方案或替代解決方法。維護者會使用標籤對 Issue 進行分類，包括元件標籤（如 vmalert、vmagent）、型別標籤（bug、enhancement、question）、enterprise、need more info、completed 和 vmui 等。若 Issue 資訊不足，維護者會新增 need more info 標籤並等待使用者補充。

Pull Request 需要遵循嚴格的清單：必須符合專案發展目標；不要基於 master 分支建立 PR；所有提交必須簽名；標題應使用元件字首（例如 app/vmalert: fix…）；描述需清晰說明變更內容、原因和目的，並附上相關 Issue 連結；非平凡改動必須提供測試；儘量避免超出範圍的無關修改；必要時更新文件（新功能需新增 {{% available_from "#" %}} 短程式碼）；在變更日誌中記錄改動；不要手動修改 /vendor 目錄，應先向上游倉庫提交 PR，再更新下游版本。

在 AI 政策方面，專案允許自由使用任何 AI 工具，無需披露使用方法。但貢獻者必須對提交的更改全權負責，應努力理解程式碼庫和 PR 中的每一項改動，並在提交前清理 AI 生成的低質量內容。禁止使用 AI 自動回覆維護者。所有貢獻都會根據質量進行審查，看起來像未經審查的 AI 輸出且包含低質量或破壞性更改的 PR 或 Issue 可能會被直接關閉。

合併 PR 的人員需確保清單已滿足、至少一名審查者批准且所有 CI 檢查透過，並在合併後 cherry-pick 到相關分支（如適用，包括 LTS 釋出線）。同時，應更新相關 Issue 並新增 completed 標籤，但需等到釋出後再關閉，若被自動關閉則重新開啟。

專案遵循 KISS（保持簡單）原則，傾向於簡單程式碼和架構，避免複雜抽象、魔法程式碼和花哨演算法。最佳化只有在效能剖析顯示顯著改進時才被接受，且須在 Go 基準測試和生產負載上進行。專案還避免大型外部依賴，儘量減少分散式系統中的可變部件，並拒絕可能損害叢集可用性、一致性、效能或可除錯性的自動化決策。因此，VictoriaMetrics 叢集版本刻意不包含脆弱的上流協議（如 Thanos 中的失敗嘗試）、難懂的 Paxos 協議、複雜複製方案、自動資料重排、自動叢集調整、自動發現新節點以及自動領導者選舉等功能。

提交 PR 前，建議依次執行 make check-all（靜態檢查）、make test-full（單元測試）和 make apptest（整合測試）。