请在看完该文档后再进行贡献，不然你的提交有可能会被打回。

Issues

一言以蔽之，遵守 issue templates，尽可能多地填写信息。以及，不要扎堆。

for a bug

1. 这个问题有被提出过吗？如果有，Ta 的情况和你一样吗？重复的问题将会被缩减。
2. 这个问题能被复现吗？如果能，怎么复现？罕见的问题可能会被删除。
3. 有时候，只有你会遇到这个问题，为什么？是不是你配置失误？是不是你系统特性使然？如果是，请提供系统信息。

for a feature

1. 有人提出过这个特性吗？如果有，Ta 的诉求和你一样吗？请不要刷 Cu 之类的话，而是用 reaction 之类的方法表达请求。
2. 你想过这个特性合理吗？是否会消耗过多的服务器资源？如果答案是否定的，请不要在这里提出，或许 Hello Luogu/Luogu Academic 更适合你的建议。
3. 如果可行的话，你能给出一个 demo 或者描述吗？不具体的诉求可能也会被取消。
4. 最好的话，你能给出一个实现并 Pull Request 吗？我们非常欢迎你的贡献。

Pull Requests

请先阅读所有内容，确保你的代码符合我们的要求。除此以外，你需要达成如下要求：

1. 你的实现是否与这个项目合拍？具体的，你是否将这个项目已经造过的轮子再造了一遍，如 jQuery.fn.whenKey？尽可能使用这个项目的轮子来实现你的功能，当然自造实用的轮子也是欢迎的。

2. 你是否留下了调试信息，如 console.log、debugger？请删除它们。代码中的注释仅限于弃用的代码和解释，这些注释只会增加后人理解的成本。

3. 请测试你做的功能：

   • 是否都符合预期？如果一段代码报错了但结果符合期望，请改掉它，不要留下潜在问题给后人添麻烦。

   • 是否实现合理？形如，代码中是否有一秒请求一次私信的操作？不合理的实现，如对用户或服务器资源消耗过大的行为，都不应该出现和被 merge。

4. 你是否对你的模块撰写了对应文档？现在 Git 钩子已经能识别你写的模块有无对应文档，但如果你对某个模块做了更新而没有适当的阐述，请加上它们。

5. PR 是覆水难收的吗？不是。学会使用 GitHub 的特性，如 PR 以后还可以增加 commits。

6. 你不应该修改版本号。版本管理将会在 merge 以后统一进行。

7. 尽量避免 git push -f，这具有潜在风险。

顺便提一嘴，所有的 Contributor 都可以去找 optimize_2 要 badge，只要你的 contribution 没有严重问题，大概率都是要得到的。