# 五、贡献

### 建议的步骤

1. 找到您想解决的问题
2. 弄清楚什么是解决问题的良好第一步。 这可以是代码、研究、提案的形式，或者如果它已经过时或一开始就不是一个好主意，则建议将其关闭。 
3. 对问题进行评论，概述您建议的第一步，并征求反馈。 当然，您可以立即投入并开始编写代码或测试，但这可以避免潜在的浪费精力，如果问题已过时、未明确指定、因其他原因受阻或未准备好实施。 
4. 如果问题需要更改代码或修复错误，请打开带有测试的 PR 草案，并征求反馈。 这可以确保每个人都在同一页面上了解需要做什么，或者解决问题的第一步应该是什么。 
5. 此外，由于需要测试，因此首先编写测试可以很容易地确认更改是否可以轻松测试。 随机敲击键盘直到测试通过，然后重构直到代码准备好提交。 
6. 将 PR 标记为准备好审查。 
7. 根据需要修改 PR。 
8. 最后，合并！

### 从小做起

小的改变会让你迅速产生影响，如果你采取了错误的策略，你也不会浪费太多时间。

小问题的思路：

```
 添加新的测试或测试用例以增加测试覆盖率
 添加或改进文档
 找到一个需要更多研究的问题，进行研究并在评论中进行总结
 找到一个过时的问题并评论它可以关闭
 找到一个不应该做的问题，并提供严格的反馈，详细说明您认为会出现这种情况的原因
```

尽早并经常合并！

### 尽早并经常合并

将大型任务分解为多个较小的步骤，这些步骤可以单独取得进展。 如果有错误，您可以打开一个 PR，添加一个失败的忽略测试。 这可以合并，下一步可以修复错误并忽略测试。 进行研究或测试，并报告您的结果。 将功能分解为小的子功能，一次一个地实现它们。

弄清楚如何将一个较大的 PR 分解成较小的 PR，每个 PR 都可以合并是一种非常值得练习的艺术形式。 困难的部分是每个 PR 本身必须是一个改进。

我自己努力遵循这个建议，而且当我这样做时，我总是过得更好。

小的更改可以快速编写、审查和合并，这比为一个需要永远编写、审查和合并的巨大 PR 工作要有趣得多。 小的更改不会花费太多时间，因此如果您需要停止处理一个小的更改，与代表许多小时工作的较大更改相比，您不会浪费太多时间。 快速获得 PR 可以立即改进项目，而不必等待很长时间才能进行更大的改进。 小的更改不太可能累积合并冲突。 正如雅典人所说：快者尽其所愿，慢者兼并其所必须。 

### 得到帮助

如果您遇到困难超过 15 分钟，请寻求帮助，例如 Rust Discord、Stack Exchange，或者在项目问题或讨论中寻求帮助。 

### 练习假设驱动的调试

就导致问题的原因提出假设。 弄清楚如何检验该假设。 执行该测试。 如果有效，那太好了，您解决了问题，或者现在您知道如何解决问题了。 如果不是，请重复一个新的假设。 

### 注意错误信息

阅读所有错误消息，不要容忍警告。