通用指南
以下是一些在所有类型贡献中需要注意的事项
- 遵循“fork 和 pull request” 工作流程。
- 在打开 pull request 时填写已签入的 pull request 模板。请注意相关问题并标记相关维护者。
- 在请求审查之前,请确保您的 PR 通过格式化、代码风格检查和测试检查。
- 如果您希望在当前进度上获得评论或反馈,请打开一个 issue 或讨论并标记维护者。
- 请参阅关于测试 和格式化和代码风格检查 的部分,了解如何在本地运行这些检查。
- 向后兼容性是关键。您的更改不得破坏现有功能,除非是在紧急错误和安全修复的情况下。
- 在打开新的 PR 或 issue 之前,请查找是否已经存在重复的 PR 或 issue。
- 保持范围尽可能隔离。一般来说,您的更改一次不应影响多个包。
错误修复
我们鼓励并感谢错误修复。我们要求您
- 详细解释错误,以便维护者能够重现它。
- 如果存在相应的 issue,请链接到它。使用
Fixes
作为前缀,以便在 PR 合并时自动关闭该 issue。
- 如果存在相应的 issue,请链接到它。使用
- 如果可能,避免破坏性更改。
- 包含在没有错误修复的情况下会失败的单元测试。
如果您遇到错误但不知道如何修复它,我们要求您为此打开一个 issue,详细描述您遇到错误的环境。
新功能
我们的目标是为新功能设置较高的门槛。通常,我们不接受来自外部贡献者的新的核心抽象、基础设施更改、依赖项更改或新的代理/链,除非存在现有的 GitHub 讨论或 issue 来证明对它们的迫切需求。
- 新功能必须附带文档、单元测试和(如果适用)集成测试。
- 新的集成必须附带文档、单元测试和(如果适用)集成测试。
- 请参阅此页面,以获取有关贡献新集成的更多详细信息。
- 新功能不应继承或使用已弃用的方法或类。
- 我们将拒绝可能导致安全漏洞或报告的功能。
- 不要添加任何硬依赖项。集成可以添加可选依赖项。