为 PEFT 做出贡献
译者：片刻小哥哥
项目地址：https://huggingface.apachecn.org/docs/peft/developer_guides/contributing
原始地址：https://huggingface.co/docs/peft/developer_guides/contributing
我们很高兴接受对 PEFT 的贡献。如果您打算做出贡献，请阅读本文档以使过程尽可能顺利。
安装
安装说明可以找到 此处 。如果您想向 PEFT 提供代码贡献，您应该选择“源”安装方法。
如果您不熟悉创建拉取请求，请按照 [这些说明来自 GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/producing-changes-to-your-work-with-pull-requests/creating-a -拉请求） 。
运行测试和代码质量检查
无论贡献类型如何（除非仅涉及文档），您都应该在创建 PR 之前运行测试和代码质量检查，以确保您的贡献不会破坏任何内容并遵循项目标准。
我们提供了一个 Makefile 来促进这些步骤。运行以下代码进行单元测试：
make test
运行以下命令之一来检查或检查并修复代码质量和样式：
make quality # just check
make style # check and fix
运行所有测试可能需要几分钟的时间。因此，在开发过程中，仅运行特定于您的更改的测试可能会很有用：
pytest tests/ -k <name-of-test>
这应该更快地完成并允许更快的迭代。但是，在创建 PR 之前，请仍然运行整个测试套件，因为某些更改可能会无意中破坏乍一看不相关的测试。
如果您的更改特定于硬件设置（例如，它需要 CUDA），请查看
测试/test_gpu_examples.py
和
测试/test_common_gpu.py
– 也许在那里添加一个测试是有意义的。
当您处理 PR 时，底层代码库可能会由于合并其他更改而发生更改。如果发生这种情况 - 特别是当存在合并冲突时 - 请更新您的分支以获取最新的更改。这可以是合并或变基，无论您喜欢什么。一旦 PR 准备好，我们将对其进行压缩和合并。
公关说明
打开 PR 时，请对您所提供的更改进行详细描述。如果涉及其他问题或 PR，请参考。提供良好的描述不仅可以帮助审阅者更好更快地审阅您的代码，还可以在以后将其用作提交消息（作为基础），这有助于项目的长期维护。
如果您的代码进行了一些重要的更改，那么向代码添加注释来解释这些更改也是一个好主意。例如，如果由于最明显的方法不起作用而必须多次迭代实现，那么这就很好地表明需要代码注释。
提供错误修复
请描述导致该错误的情况。如果存在问题，请链接到该问题（例如“Resolves #12345”）。
理想情况下，当提供错误修复时，应该附带针对该错误的测试。当前代码的测试应该失败，错误修复后测试应该通过。向测试添加引用问题或 PR 的评论。如果没有这样的测试，就很难防止未来的回归。
添加新的微调方法
新的参数有效的微调方法一直在开发。如果您想向 PEFT 添加一种新的、有前景的方法，请按照以下步骤操作。
要求
- 请添加方法来源（通常是论文）的链接。
- 应提供一些证据表明人们普遍对使用该方法感兴趣。我们不会添加新发布但没有证据表明有需求的新方法。
- 理想情况下，我们不仅希望添加新方法的实现，还希望添加示例（笔记本、脚本）、文档和广泛的测试套件，以证明该方法适用于各种任务。然而，这可能非常令人畏惧。因此，仅提供实现和至少一个工作示例也是可以接受的。可以在后续 PR 中添加文档和测试。
脚步
在开始实施新方法之前，请在 GitHub 上提出一个问题并提出您的建议。这样，维护人员就可以给您一些早期反馈。
实现该方法时，寻找现有的实现作为指导是有意义的。此外，当您构建代码时，请从其他 PEFT 方法中获取灵感。例如，如果你的方法与 LoRA 类似，那么以类似的方式构建你的代码，甚至在有意义的地方重复使用一些函数或类是有意义的（但不要过度，一些代码重复是可以的）。
一旦你的东西看起来有效，请立即创建 PR 草案，即使它尚未处于可合并状态。维护人员将很乐意为您提供反馈和指导。
添加其他功能
最好先在 GitHub 上提出一个问题，并提出添加新功能的建议。这样，您可以在花费太多时间来实现之前与维护人员讨论添加该功能是否有意义。
新功能通常应附有测试和文档或示例。如果没有后者，用户将很难发现你很酷的新功能。
对代码的更改应该以向后兼容的方式实现。例如，合并功能后，现有代码应继续以相同的方式工作。
