如何为 ord 做贡献
建议的步骤
- 找到一个你想解决的问题。
- 弄清楚什么是解决这个问题的良好的第一步，这可以是代码，研究和提案的形式，或者是如果它已经过时，或者一开始就不是一个好主意，则建议将其关闭。
- 概述您所建议的第一步，对问题进行评论，并征求反馈。当然你也可以立即投入并开始编写代码或者测试。但是如果问题已经过时、未明确制定、因其他原因受阻或者未准备好实施，这一步可以避免潜在的精力浪费。
- 如果问题需要更改代码或者修复错误，请打开测试 PR 草稿，并征求反馈意见。这将保证每一个人会同步知道需要做一些什么，或者解决这个问题的第一步是什么。同样，调试是必须的，所以首先写出测试草案并确认更新是可以被容易的测试的。
- 随机敲击键盘直到测试通过，然后重构直到代码准备好提交。
- 将 PR 标记为审查就绪。
- 根据需要修改 PR 。
- 最后一步，合并！
集腋成裘
小的改变可以让你迅速的产生影响力，即便你采取了错误的策略，你也不会浪费太多的时间。
一些小问题的思路：
增加新的测试或者测试案例以增加测试的覆盖率
增加或者改进文档
找到一个需要更多研究的问题，进行研究并在评论中进行总结
找到一个过时的问题，并评论使其关闭
找到一个本不该做的问题，并提供建设性的反馈，详细说明您认为会出现这种情况的原因
早合并，勤合并
将大大型的任务分成多个较小的步骤，这些步骤可以单独取的进展。如果有程序错误，您也可以打开一个 PR，添加一个失败的忽略测试。这可以合并，下一步可以修复错误并忽略测试。将你的研究或者测试结果进行报告。将一个大的功能分解为小的子功能并一次一个的逐步实现它们。
弄清楚如何将一个较大的 PR 分解成较小的 PR，每个 PR 都可以合并是一种非常值得练习，这也是编程的一种艺术。 困难的部分是每个 PR 本身必须是一个改进。
我自己努力遵循这个建议，而且当我这样做时，我总是可以做的更好。
小的更改可以快速编写、审查和合并，这比为一个需要永远编写、审查和合并的大型的 PR 工作要有趣得多。小的更改不会花费太多时间，因此如果您需要停止处理一个小的更改，与代表许多小时工作的较大更改相比，您不会浪费太多时间。 快速获得 PR 可以立即改进项目，而不必等待很长时间才能进行更大的改进。 小的更改不太可能累积合并冲突。正如雅典人所说：快者尽其所愿，慢者兼并其所必须。
寻求帮助
如果您遇到困难超过 15 分钟，请寻求帮助，例如 Rust Discord、Stack Exchange，或者在项目问题或讨论中寻求帮助。
实践'假说驱动'的调试
就导致问题的原因提出假设。 弄清楚如何检验该假设。 执行该测试。 如果有效，那太好了，您解决了问题，或者现在您知道如何解决问题了。 如果不是，请重复一个新的假设。
关注错误信息
阅读所有错误消息，不要容忍警告。