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（集成测试）。