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（集成測試）。