贡献指南

对Apollo感到兴奋并希望使其变得更好？我们也很兴奋。请阅读以下内容以了解如何以不同的方式为项目做出贡献。

问题

如果您遇到错误，请通过包含可能存在错误的子项目的仓库在GitHub上提交问题。如果您提出的问题已经有人报告，请添加附加信息或在下方👍点赞以表示您同意。

尽管我们将尽力提供帮助，但请包括以下内容以提高快速修复的可能性

预期结果：出现错误时您试图完成的任务，以及与问题来源相关的尽可能多的代码。
实际结果：对实际发生情况的描述，包括任何相关的错误消息、日志或其他输出的截图或复制粘贴。可查找信息的地方包括浏览器控制台、服务器控制台和网络日志。请避免使用“未工作”或“损坏”等不具体的词语。
重现：我们可以运行的最低程度的问题重现。最好是以我们从GitHub上克隆的示例应用的形式或以其他形式发送的失败的测试。重现应包含尽可能少的代码来演示错误。

创建良好的重现真的有助于贡献者快速调查和解决问题。在许多情况下，创建最小重现过程能够阐明错误的来源在库之外的某个地方，从而为每个人节省时间和精力。

创建重现的良好起点是开发者首页上的“hello world”示例：

在某个时间点，Apollo的大多数功能都是由社区提议的。我们欢迎任何关于如何使我们的项目更适合您的用例的想法。除非有压倒性的需求，否则可能不会立即实施新功能，但请尽可能提供有助于人们讨论您的提议的信息。

用例：您试图用具体术语完成什么任务？通常，可能已经存在一种很好的方法来完成您需要的任务，因此不需要额外的新功能，但没有具体信息就很难知道。
这是否可以作为一个插件？在许多情况下，一个功能可能太专业而不适合包含在图书馆的核心中，最好将其实现为辅助软件包。如果无法扩展库以执行您需要的功能，是否可以添加额外的插件API？重要的是要说明为什么功能应该成为库的核心功能。
有没有解决方案？ 这是一种更方便的做法，还是说存在一些障碍使得解决方案不可行？

功能请求将被标记，我们鼓励使用GitHub问题来讨论新功能和可能的实施设计。在形成共识之前，请避免提交实现建议功能的pull request。这样，你可以避免投入无法合并的工作。

一旦对新功能的需求达成共识，请按照以下“大PR”部分进行操作。

如果有微小改动，请随时提出含有修复或改进的PR。对于这类pull request，没有必要先写设计。

改进文档、示例和其他开源内容可能是为库做出贡献的最简单方式。如果你看到一些可以改进的内容，无论多小，都请提出改进的PR！如果你想提出大改动或重大重写，我们非常愿意听取你的想法，但请在写PR之前先打开一个问题进行讨论。

对于20行代码以下的微小修复更改，请随时提出pull request。我们将尽快合并，并理想情况是在同一天发布新版本。唯一的要求是，一定要添加一个验证你试图修复的bug的测试。

这包括

对于仓库的重大更改，在开始实施之前确定设计是非常重要的。这样可以确保主要改进得到合适的关注。因为大改动可能存在风险，不一定总是可以得到合并，所以在首先同意实施设计/计划后，可以减少可能的浪费努力。

打开一个问题。 就你的bug或功能，按照上述方式打开一个问题。
达成共识。 一些贡献者和社区成员应该达成协议，这个功能或bug很重要，并且有人应该负责实施或修复它。
协商期望的行为。 在问题上，达成关于期望行为的协议。在bug修复的情况下，应该明确bug修复的含义，以及在功能的情况下，明确开发者如何使用新功能。
协商实施计划。 编写一个如何实施此功能或bug修复的计划。需要添加或重写的模块有哪些？这是一个pull request还是多个渐进式改进？谁将负责每个部分？
提交PR。 如果需要多次相关的补丁来实现更改，请一次提交一个。否则，其他补丁可能会在第一次被审查和合并时过时。确保避免“在此过程中”类型的变化——如果某些事情与当前的改进不相关，它应该在一个单独的PR中；这特别包括与无关代码的代码风格更改。
审查。 至少有一位核心贡献者应该在合并之前签署此更改。查看下面的“代码审查”部分，了解代码审查中重要因素。如果你想加快代码的合并，首先尝试审查你自己的代码！
合并和发布！

重要的是，让人觉得Apollo包中的每一块代码都至少被一位熟悉该代码库的核心理念贡献者审查过。以下是一些需要留意的事项

所需的持续集成（CI）检查通过。 如果测试未通过，则无需审查分支请求（PR）直至测试通过。
简洁性。 这是实现预期目标的最简单方法吗？如果文件过多、存在冗余函数或复杂的代码行，建议提出一个更简便的解决方案。特别是，在简单、小型、务实的修复可以解决问题的情况下，避免实现过于通用的解决方案。
测试。 测试确保这项代码在周围其他东西改变时不会破坏吗？当它断开时，添加的测试值能否帮助我们识别哪个库的部分存在问题？是否覆盖了适当的一组边缘情况？如果有的话，查看测试覆盖率报告。新代码中的所有重要代码路径是否至少被执行过一次？
不需要的不必要变更。 PR中不应该包含随机的格式更改，尤其是在代码中不相关的部分。如果需要进行一些重构，在一个单独的PR中完成，最好从错误修复或功能开始，如果可能的话。
代码有适当的注释。 应该注释复杂的逻辑，或者以清晰“自文档”的方式书写。
语言习惯性使用。 在TypeScript中，确保类型定义是具体且正确的。在ES2015中，确保使用import而不是require，使用const代替var等。理想情况下，使用代码规范工具强制执行大部分，但使用常识并遵循周围代码的风格。