【译】开源维护者选择项目 maintainer，最看重的其实不是编码技能

原文：https://twitter.com/youyuxi/status/1463735120922230791?s=21

译者: 「前端灵一」

正文

开源维护者如何选择“投资”哪些贡献者（例如投入时间、精力、指导等）？

How do open source maintainers pick which contributors to “invest” in (time, effort, mentorship, etc)?

我不知道其他人对于这件事的看法。但对我来说，我最看重的不是编码技能。我在开源贡献者中寻找的主要判断依据是良好的判断力。这个概念可能听起来很模糊……🧵

How do open source maintainers pick which contributors to “invest” in (time, effort, mentorship, etc)? I don’t know about others but for me the main thing isn’t coding skill. The main thing I’m looking for in a contributor is good judgement. This concept may sound fuzzy… 🧵

首先，什么标准不是好的判断呢？例如来自哪里、你如何展现自己、你的年龄、甚至你拥有多少年的专业经验，这些条件都和好判断无关。

First, what good judgement is NOT. It has nothing to do with where you’re from, how you present yourself, how old you are, or even how many years of professional experience you have.

好的判断条件和 影响力 或 知名度 没有关系。有些人虽然有 5 个粉丝，但他们比拥有大量粉丝的知名人物更值得让我相信。

Good judgement also has nothing to do with the “clout” or being known. There are people with 5 followers whose judgment I would trust more than well-known characters with latge audiences.

那么我认为的，所谓的 良好的判断力 到底是什么意思？我无法给出准确的定义，但我会描述与这样的人一起工作的感觉。

So what do I mean by “good judgment”? I can’t give a precise definition but I’ll describe what working with a person like this feels like.

在我看来，阅读他们的Pull Request描述是一种享受。他们在Pull Request上写清楚了足够详细的提交细节。但细节并不是在解释代码的逻辑，而是在解释他们在做什么、如何做、最重要的是为什么这样做。他们还会提到自己的思考过程，例如为什么用这种方法去实现、替代方案被拒绝、他们如何进行的代码测试。

Reading their PR descriptions is a treat. They use the right amount of detail — not paraphrasing the code but enough to explain what they’re doing, how, and most importantly, why. They mention their thought process — why this approach, alternatives rejected, how they tested.

他们会注重一个开源项目更长远的未来。例如如果代码发生了崩溃，他们不只是在崩溃的代码上添加 != null 检查。他们纠结于为什么这个地方是空的、它是否应该是空的？假设逻辑不正确的地方、以及修复的好方法。

They look at a bigger picture. For example, if there is a crash, they don’t just add != null check on the line that crashes. They look at why that thing is null, whether it’s supposed to ever be null or not, where the assumptions were violated, and what’s a good place to fix.

他们不会将代码看做是静态的，不会想“这只是给计算机运行的内容”。他们会把代码当成活生生的给人阅读的逻辑，并去试图弄清楚（编写它的人的）过去的意图，跟踪这段代码变化的历史（例如哪次修改引入了错误）。并为下一个代码贡献者留下标记提醒

They don’t look at code as a static “here’s what the computer runs” level. They see a living body of work. They try to figure out the past intentions (of the people who wrote it), track the history of changes (where was a mistake introduced?), leave breadcrumbs for next readers.

他们端到端地查看结果。如果他们修复了一个bug，他们不会将“测试用例通过”作为唯一的通过指标。他们会将其放入重现该bug的项目中，并验证该bug是否已消失。（这是一个秘密：如果你不这样做，仓库的维护者会说谢谢并会为你做。）

They look at the result end-to-end. If they fix a bug, they don’t rely on “tests pass” as the only signal. They put it in a project that reproduces the bug, and verify that the bug is gone. (Here’s a secret: if you don’t do this, the maintainer says thanks but does it for you.)

他们会保持提交的质量。他们会投入等量的工作来验证他们的修改是否正确，并且在更改本身中按预期工作。很明显他们很关心提交的质量。他们为自己的工作充当无情的 QA，不去回避额外花费几个小时进行有意义的测试。

They maintain quality. They put in equal amount of work in verifying their change is right and works as intended as into the change itself. It’s noticeable they CARE. They act as a merciless QA for their own work — not shying away from spending hours on meaningful testing.

当我看到贡献者说："我在三个浏览器中测试了三个分辨率，并经历了场景 X、Y 和 Z"（或同样做了对项目有意义的事情）时，我的心充满了喜悦。这个人自己自觉无论如何他都必须这样做，而且他们已经表现出了先做这件事的礼貌。这里我要对他们说一句谢谢。

When I see “I tested on three resolutions in three browsers and went through scenarios X, Y and Z” (or equivalent that makes sense for the project) my heart fills with joy. This person knows I’ll have to do this anyway and they’ve shown the courtesy of doing it first. Thanks.

但是，这并不意味着他们不会搞砸事情（我们作为作者，也是一样会出错误）。但是他们足够勤奋，以至于有些错误都是自己得来的。把 "一些东西漏掉了" 和 "字面上不用心检查变化是否会起作用" 这两个是有区别的。要做你自己的 QA，我会信任你。

This doesn’t mean they can’t screw up. All of us can! But they take enough diligence that the mistakes feel earned. There’s a difference between something slipping through and literally not bothering to chrck whether the change does the thing. Be your own QA and I’ll trust you.

这听起来可能有些忘恩负义，但在许多情况下，开源项目的维护者会去帮助你在一个受欢迎的项目中提交一个commit，以得良好的贡献经验。一般情况下，开源项目的维护者自己本身可以快速地完成一样的提交，但他们希望这个事情是你来做，并协助你去花几天的时间来回修改。

This might sound ungrateful, but in many cases the maintainer helping you — to land a commit in a popular project, to have a good contributing experience, etc. Often, they can do an equivalent change fast but they want it to be yours and spend days on back-and-forth.

他们对上下文非常敏感。除了遵循“贡献指南”之外，他们还尽力推断出可能无法直接看到的事物。例如：假设、项目愿望、质量标准、技术债务、令人不愉快的提交流程、故意的偷工减料、风格、共鸣等（这里指项目的目标愿望，协作方式，构建流程，技术债务等等）

They are very perceptibe to the context. Beyond following the guidelines, they try their best to infer the things that may not be directly visible — assumptions, project aspirations, quality bar, tech debt areas, frustrating workflows, intentionally cut corners, style, vibes.

他们将最终结果视为一个整体产品。他们会在在项目的目标、其他人的问题、和其他解决方案的背景下看待自己的提交变化，他们会表现得好像要对整个项目负责（be owner）。即使他们只是修改改变了一小部分。

They see the end result as a holistic product. They look at their change in the context of the goals of the project, other people’s issues, other solutions. They act as if they are responsible for the whole thing—even if at the moment they only change a small part.

责任是核心。大多数贡献虽然很棒，但需要仓库维护者为他们的提交内容付出更多的责任。例如测试他的更改，弄清楚此代码以前如何工作，研究浏览器的差异等等。但有些贡献者会主动承担这部分责任。

Responsibility is central to this. Most contributions—while great—need maintainers to add more responsibility to their plates. Test this change, figure out how this code worked before, research browser differences, etc. But there are some contributors who take responsibility.

他们会寻找机会并提出有意义的改变。例如范围内的、务实的、通常是增量的变化。他们的变化感觉更像是“雕刻出”应该已经存在的东西，而不是附加一些额外的内容。它们会让 $PROJECT 感觉更像 $PROJECT-y。

They look for opportunities and propose meaningful changes. Changes that are scoped, pragmatic, usually incremental. Their changes “feel” more like “carving out” what should be “already there” rather than attaching something extra. They make the $PROJECT feel more $PROJECT-y.

他们的工作中没有自我。很明显，他们不只是提交它来建立自己的简历（指水提交）。他们的首要任务是为项目找到正确的变更（并弄清楚它到底是什么！），而不是坚持自己的确切想法。他们可能会发送一些简单的提交，但不会提交无意义的修改。

There is no ego in their work. It’s clear they’re not just sending it to build up a resume. Their priority is to land the right change for the project (and figure out what it is!) rather than to land their exact idea. They might send simple changes but not spammy ones.

到目前为止，我一直专注于仓库的核心代码（尽管这同样适用于文档）。但是在项目的主要结构内容之外（例如测试用例，文档等等），它们通常也很活跃。事实上，我经常看到这些人从一些外部的贡献开始，例如帮助人们解决问题，测试其他人提交的 PR，为错误报告的 Issue 制作重现的testcase

So far I’ve focused on the code (although the same applies to documentation too). However, they are usually active beyond that. In fact, I usually see these people start outside code: helping people in issues, testing other PRs, making reproducing cases for bug reports.

这是有道理的，因为对于已完善的开源项目，许多有价值的活动是来自于非核心贡献的。想要获得 PR 并没有错，但是当一个人有更多社区/产品驱动的心态，并且从仓库维护者的盘子里拿走一些日常工作（帮助大家回答Issue问题，处理杂事等等）时，这一点就很明显了。

This makes sense because for established projects, many valuable activities are external to code. There’s nothing wrong with wanting to score a PR, but it’s noticeable when a person has a more community/product-driven mindset, and takes some routine work off maintainers’ plate.

他们会表现出一种有趣的平衡：即为他们感兴趣的部分培养目标，同时保持真正的好奇心并保护项目的整体现有愿景。

They show an interesting balance of cultivating a vision for the parts they’re interested in while staying genuinely curious and protective of the project’s oberall existing vision.

这些意识怎么学？我不清楚。我见过刚从训练营毕业的人在这方面表现出色，我也见过有 10 年以上经验的人不擅长。你如果对项目有同理心，在这方面是有帮助的。如果您能想象自己成为维护者，那么你很快就会做好成为维护者的准备。

How does one learn this? I don’t know. I’ve seen people fresh out of bootcamp who excel at this and I’ve also seen people with 10+ years of experience who don’t. Empathy helps. If you can imagine what it’s like to be in maintainer’s shoes, you’ll soon be ready to be a maintainer.

我最近看到一些人在做这类的工作：

•@sebsilbermann 在 React 仓库和周围的其他仓库都非常有帮助（他并没有加入我们的组织）•@SylwiaVargas 提供了新的 React Docs 示例内容•@harishkumar_s_s 帮助了新的 React Docs 网站。

A few people I’ve seen do this type of work recently: @sebsilbermann has been spectacularly helpful on the React repo and everywhere around (we don’t deserve him), @SylwiaVargas with new React Docs example content, @harishkumar_s_s helping with the new React Docs website.

我必须澄清一下，简单的驱动式 PR 没有做这些事情的任何必要（包括我自己也提交了许多）。我的内容是关于如何脱颖而出，这些是我在被邀请参与不同项目的人身上观察到的品质。

I should clarify that there’s nothing wrong about simple drive-by PRs that do none of those things. (I send quite a few of those myself!) My thread is about how to stand out — these are the qualities I’ve observed in people who get invited to co-maintain in different projects.

但归根结底，它也是开源的。读到这里你可能会想：wtf，所有这些工作都是免费的？不过这还算公平。我并不希望任何开发人员想要去做这一切，有些人可能想要但也没有时间做这么多额外的工作。

At the end of the day, it’s open source. Reading this might make you think: “wtf, all this work and for free?” That’s fair. I wouldn’t expect any developer to want to do all of this. Some might want to but not have the time to do so much extra work either.

尽管如此，对于平均的评判标准已经足够低，通过稍微多加努力就可以在其中脱颖而出。此外，也许不要从大型项目的 PR 开始贡献 —— 通常它们的维护人员根本没有时间。较小的项目通常有更多可操作的问题需要解决，审查时间也更快。

Still, the average bar is low enough that by putting in slightly more effort you can already stand out. Also, maybe don’t start with PRs to huge projects — often maintainers don’t have time at all. Smaller projects often have more actionable things to fix and faster review times.

此外，这并不是说作为维护者，你应该只帮助那些已经在这方面做得很好的人。我也很开心在时间允许的情况下帮助那些正在努力提高技能的人。我所描述的更多是关于提交者如何长期获得对项目的信任。

Also, this isn’t to say that as a maintainer you should only help people who are already great at this. It’s a pleasure to help someone who is struggling to grow their skillset — when time allows. What I described is more about how people earn trust on projects in longterm.

我确实一直想强调，这一切都与工作的数量无关（如果有的话，较大的 PR 很少达到那个质量标准），这是关于在提交中值得注意的事项。即使他可能是个小事情（提交）

I do want to emphasize though that none of this is about the volume of the work. (If anything, larger PRs are very rarely hitting that quality bar!) It’s about thoughtfulness and care noticeable in the approach. Even for small things.