贡献者指南¶

如果您正在阅读此内容，您可能对为 Requests 做出贡献感兴趣。非常感谢！开源项目的存亡取决于他们从他人那里获得的支持，而您甚至考虑为 Requests 项目做出贡献，这真是非常慷慨。

本文档列出了为本项目做出贡献的指南和建议。如果您正在考虑做出贡献，请首先阅读本文档并了解如何为本项目做出贡献。如果您有任何疑问，请随时联系主要维护者 Nate Prewitt、Ian Cordasco 或 Seth Michael Larson。

本指南根据您考虑做出的贡献类型分为多个部分，其中一部分涵盖了所有贡献者的通用指南。

保持礼貌¶

保持礼貌，否则请离开。——Kenneth Reitz

Requests 有一个非常重要的规则，适用于所有形式的贡献，包括报告错误或请求功能。这条黄金规则是“保持礼貌，否则请离开”。

欢迎所有贡献，只要对所涉及的每个人都表示尊重。

尽早获得反馈¶

如果您正在做出贡献，不要觉得有必要等到您的贡献完美无缺并完成时才提交。您尽早寻求反馈对所涉及的每个人都有帮助。提交早期未完成的贡献版本以获得反馈，绝不会影响您让该贡献被接受的机会，并且可以避免您将大量精力投入不适合该项目的贡献。

贡献适用性¶

我们的项目维护者对贡献是否适合 Requests 拥有最终决定权。所有贡献都将得到认真考虑，但有时，贡献会被拒绝，因为它们不符合项目的当前目标或需求。

如果您的贡献被拒绝，不要绝望！只要您遵循了这些指南，您就有更大的机会让您的下一个贡献被接受。

代码贡献¶

提交代码的步骤¶

在贡献代码时，您需要遵循此清单

在 GitHub 上分叉存储库。
运行测试以确认它们全部通过您的系统。如果它们没有通过，您需要调查它们失败的原因。如果您无法自行诊断此问题，请按照本文档中的指南将其作为错误报告提出：错误报告。
编写测试以演示您的错误或功能。确保它们失败。
进行更改。
再次运行整个测试套件，确认所有测试都通过包括您刚刚添加的测试。
向主存储库的 main 分支发送一个 GitHub Pull Request。GitHub Pull Request 是此项目中代码协作的预期方法。

以下小节将更详细地介绍上述一些要点。

代码审查¶

除非代码已通过审查，否则不会合并贡献。你应实施任何代码审查反馈，除非你强烈反对。如果你反对代码审查反馈，你应清楚而冷静地阐明你的理由。如果这样做后，反馈仍被认为适用，你必须应用反馈或撤回你的贡献。

代码风格¶

Requests 使用一系列工具来确保代码库在不断发展过程中保持一致的风格。我们使用名为 pre-commit 的工具对这些工具进行编排。它可以在本地安装，并在打开 PR 之前对你的更改进行运行，并且还将在变更合并之前作为 CI 批准流程的一部分运行。

你可以在 Requests 的顶级目录中找到 .pre-commit-config.yaml 中指定的完整格式要求列表。

新贡献者¶

如果你对开源是新手或相对新手，欢迎！Requests 旨在作为开源世界的温和介绍。如果你担心如何最好地做出贡献，请考虑给维护者（如上所列）发送邮件并寻求帮助。

请同时查看获取早期反馈部分。

文档贡献¶

文档改进始终受欢迎！文档文件位于代码库的 docs/ 目录中。它们使用 reStructuredText 编写，并使用 Sphinx 生成完整的文档套件。

在提供文档时，请尽力遵循文档文件的风格。这意味着你的文本文件中的软限制为 79 个字符宽，散文风格半正式，但友好且平易近人。

在展示 Python 代码时，请使用单引号字符串 ('hello' 而不是 "hello")。

错误报告¶

错误报告非常重要！但是，在你提出错误报告之前，请仔细查看 GitHub 问题，包括已解决和未解决的问题，以确认该错误之前未报告过。重复的错误报告会极大地浪费其他贡献者的时间，应尽可能避免。

功能请求¶

Requests 处于永久功能冻结状态，只有 BDFL 才能添加或批准新功能。维护者认为 Requests 目前是一款功能齐全的软件。

维护一个使用广泛的开源项目时最重要的技能之一是学会对建议的更改说不，同时保持开放的耳朵和思想。

如果你认为缺少某个功能，请随时提出功能请求，但请注意，你的功能请求极有可能不会被接受。