# 五、贡献

### 建议的步骤

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

### 从小做起

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

小问题的思路：

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

尽早并经常合并！

### 尽早并经常合并

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

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

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

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

### 得到帮助

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

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

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

### 注意错误信息

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.ordinalscn.org/xu-shu-li-lun-shou-ce/wu-gong-xian.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.