Paolo

我维护一个 Python 下载管理器。一周前它有 1,500 颗星，却没有外部贡献者。今天已有九人提交了合并的拉取请求。代码本身没有改变——真正改变的是问题追踪器，而我认为我做错的具体事情比做对的更有参考价值。

明确指出需要修改的内容的问题
我最初的“适合新手”问题写的是“添加测试”。没人接单。真正有人接单的问题会明确文件名、函数、验收标准——最重要的是——是否需要我的操作系统。我的项目只能在 Windows 上运行，但几乎所有开放工作都不需要 Windows，每条问题都明确说明这一点后，队列中的大部分任务都解锁了。

将一次大清理拆分成多个片段
我有三个文件中 30 处几乎相同的改动。作为一个问题，它在那里搁置了数周；没人愿意认领 30 件任何事情。我把它拆分成四个带标签的片段，附上行号范围，其中三个在一天内就被认领了。

我这么做时出了两件事错误。我漏算了一个文件七处改动。并且我的行号范围意外地将一个项目排除在所有片段之外，所以没人能认领它。两者都是因为我重新对照源代码计数，而不是信任自己写的问题，才被发现的。

一个置顶的路线图问题
一页列出所有开放项目，按规模和是否需要操作系统排序。这是仓库中访问量最大的内容。

我还置顶了两个已经关闭的问题，悄悄浪费了三个置顶槽中的两个。检查一下你的置顶。

公开纠正自己
我现在已经多次在自己的问题下发布更正，列出错误数据和正确数据。这感觉很糟糕，但有效：我合并的最好的拉取请求来自一个修复了生成该请求的问题中的错误的人，而且他明确指出了这一点。

如果贡献者认为你的问题文本是权威的，他们就会实现你的错误。

阅读 diff，而不是描述
一个拉取请求列出了三项改进。diff 中却没有这些内容，只有一个空测试文件。作者并没有不诚实——他们描述了他们打算做的事情。我现在在合并前会将每个要点与实际更改进行核对，并在 CONTRIBUTING.md 中说明我会这样做。

使用你自己的软件能发现比阅读它更多的内容
我审计了近 5,000 行代码，发现了一个真正的 bug。然后我花了一个小时实际运行这个东西，发现了八个问题，包括一个速度读数显示的速率大约是真实速率的九倍——可以通过将屏幕显示的内容与运行自己的日志文件进行比较来证明。

每一项都变成了一个包含测量值的问题，因此贡献者可以用一个数字而不是感觉来检查他们的修复。当天下午出现的五个人中，有四个人认领了其中一项。

我没有预料到的事情
七月份，我合并了来自同一周创建的账号的十八个单行拉取请求。它们看起来像是真正的贡献。它们是贡献刷子——这些账号在 Stripe、DataDog 和 Microsoft 的仓库中也有类似的单一琐碎 PR。

我出于善意合并了它们，它们现在永久留在了我的历史记录中。如果你维护任何带有 hacktoberfest 标签的东西，十月就是这类事情到来的时候。在那之前写下什么算作贡献，而不是之后。

我会做不同的事情
从路线图页面开始，而不是问题。说明每件事是否需要你的操作系统。在任何人询问之前，将大清理拆分成命名的片段。并且在你根据阅读代码写出任何问题之前，先运行你自己的软件一个小时。

很乐意回答任何相关问题，包括那些没有起作用的部分。