Pull request 审查指南
对 Beats 所做的每一个更改都必须保持高标准，虽然 pull request 的质量责任最终在于作者，但 Beats 团队成员作为审查者有责任在审查过程中进行验证。 如果本文档不清楚或不合适，请以常识和共识为准。
每个人对风格都有自己的看法。 为了避免在这问题上花费时间，我们几乎完全依赖于 go fmt 和 hound 来规范风格。 如果这些工具都没有报错，那么代码几乎肯定是没问题的。 可能会有一些例外情况，但应该非常罕见。 只有在最不寻常的情况下才可忽略这些工具的判断。
随着软件项目的增长，其测试用例的复杂性也会增加，从而导致某些测试变得*不稳定*。 处理不稳定的测试是每个人的责任。 如果您发现 pull request 构建失败的原因与推送的代码无关，请按照以下步骤操作
- 使用带有“不稳定测试”标签的“不稳定测试”github 问题模板创建一个问题。
- 创建一个 PR 来禁用或修复不稳定的测试。
- 合并该 PR 并从其变基，然后再继续执行原始 PR 的正常 PR 流程。