VictoriaMetrics：AIポリシーとコントリビューションガイド

この記事は、VictoriaMetricsへのコントリビューションガイドです。コミュニティへの参加方法、Issueの報告、Pull Requestの作成方法、そしてAIツールの利用ポリシーについて説明しています。

コントリビュータは、VictoriaMetricsコミュニティのSlackに参加して他のメンバーを支援したり、GitHubでIssueや機能リクエスト、質問を報告したり、ドキュメントを改善したり、カンファレンス講演、ブログ記事、ソーシャルメディア、同僚との経験共有などを通じてプロジェクトを広めることができます。

Issueを作成する際は、重複を避けるためにGitHub検索を使用してください。新しいIssueは英語で書き、問題とその環境を簡潔に説明し、可能であれば具体的なユースケースを含めると、回避策や代替ソリューションが見つかる可能性があります。メンテナーは、コンポーネントラベル（vmalert、vmagentなど）、タイプラベル（bug、enhancement、question）、enterprise、need more info、completed、vmuiなどのラベルを使用してIssueを分類します。情報が不足している場合は、need more infoラベルが追加され、ユーザーからのフィードバックを待ちます。

Pull Requestを作成する際は、多くの要件があります。プロジェクトの開発目標に準拠し、masterブランチを使わず、すべてのコミットに署名する必要があります。タイトルにはコンポーネントのプレフィックス（例: app/vmalert: fix…）を付け、説明には変更内容、理由、目的を明確に記載し、関連Issueへのリンクを含めます。非自明な変更にはテストが必須で、ドキュメントの更新やチェンジログへの記載も必要です。また、/vendorフォルダのコードを手動で変更せず、上流リポジトリへのPRを先に提出し、その後にバージョン更新のPRを開く必要があります。

AIポリシーとして、コード、ドキュメント、Issueなどあらゆる作業でAIツールを自由に使用でき、開示も不要です。ただし、提出する変更には責任を持ち、コードベースとPR内のすべての変更を理解するよう努め、AIが生成した低品質な出力（AIスロップ）は送信前にクリーンアップしてください。AIを使ってメンテナーへの返信を自動化することは禁止されています。レビューされていないAI出力と見なされる低品質なPRやIssueは、詳細なレビューなしにクローズされる可能性があります。

PRをマージする担当者は、チェックリストが満たされているか、少なくとも1人のレビュアーの承認があるか、CIがすべて成功しているかを確認し、可能ならローカルでテストします。マージ後は、関連するすべてのブランチ（LTSリリースラインを含む）にチェリーピックし、関連Issueに変更内容とリリース時期を記載します。リリースが行われるまでチケットを閉じず、自動的に閉じられた場合は再度オープンします。

プロジェクトはKISS原則に従っています。シンプルなコードとアーキテクチャを好み、複雑な抽象化、マジックコード、高度なアルゴリズムを避けます。最適化は、プロファイリングでパフォーマンスやスケーラビリティが大幅に向上し、RAM使用量が削減される場合にのみ適用します。大きな外部依存を避け、分散システム内の可動部品を最小限にし、クラスタの可用性、一貫性、パフォーマンス、デバッグ容易性を損なう可能性のある自動判断を避けます。そのため、クラスターバージョンには、脆弱なゴシッププロトコル、実装が難しいPaxosプロトコル、複雑なレプリケーション方式、ストレージノード間の自動データ再シャッフリング、自動クラスタリサイズ、自動ノード発見と追加、自動リーダー選出などの機能は意図的に含まれていません。

PRを送る前に、make check-all（静的チェック）、make test-full（単体テスト）、make apptest（統合テスト）を実行することをお勧めします。