对一个你并不拥有的项目所做的贡献，只要条目准确写出你到底做了什么，就能在简历上读作可信的工作：某个具体被合并的拉取请求、你追查并修复的一个缺陷、一次影响了他人改动方向的代码评审，或是你在项目中担任的维护者角色，而不只是把仓库名字放在一个链接旁边。开源工作与你自己从零搭建的项目有一个重要区别：你的名字与其他贡献者的名字一起出现在提交历史里，项目在你出现之前就有自己的维护者，在你的改动合并之后也仍在继续运行，因此条目必须准确说明你的具体那一部分，而不是让读者以为你拥有整个项目。
为什么开源条目需要与自有项目不同的写法
对于一个由你自己搭建并完全掌控的项目，在软件工程师简历上展示个人项目一文讲的是描述它做什么、你用什么技术搭建它，以及因为你搭建了它而带来了什么变化。开源贡献首先问的是一个不同的问题，不是这个项目做什么，因为如果项目本身知名，读者通常几秒钟就能查到，而是你具体在一个早已存在、早有自己方向的项目内部做了什么。一句含糊的话放在一个知名项目名字旁边，却没有说明你真正的参与内容，读起来可能像是想借用那个项目的声誉，而不是描述真实的工作，这恰恰与这一条目本该达到的效果相反。
值得具体写明的贡献类型
一个被合并的拉取请求是最清晰的贡献单位，写明它改变了什么比只写它存在更重要：一个具体缺陷的修复、一个新功能、一次性能改进，或是一段缺失的文档。代码评审对一个活跃项目而言是真实且有价值的工作，当你做得足够多、足以有意义时，值得与你自己合并的改动分开单列，尤其是在评审质量本身就是维护者衡量贡献者地位的一部分的项目上。维护者或分流角色，也就是你拥有提交权限、评审他人的拉取请求，或为某个项目管理问题列表，值得单独写一行，而不是笼统地归到"贡献者"里，因为这说明了单一一个被合并的修复无法说明的事：其他维护者持续信任你的判断。同一个项目在数月内的反复贡献，也值得作为一种模式来描述，而不是只列出最亮眼的那一次合并改动，因为一种持续的活动模式读起来比一次性的行为更能体现长期投入。
示例说明：一条开源贡献条目
示例说明，从含糊到具体。含糊：「贡献者，开源项目（github.com/example/project）。」具体：「贡献者，一款用于本地开发环境的开源命令行工具。修复了一个导致该工具在处理大型配置文件时卡死的缺陷，并在六个月内评审了同一仓库中其他贡献者的多个拉取请求。」具体版本在一句话里说明了项目的用途，写清了被合并的改动实际修复了什么，并把评审工作与修复分开表述，而不是暗示整行都在描述同一次贡献。
诚实地肯定共同劳动，而不夸大
一个活跃开源项目中被合并的每一次改动，通常在落地之前都经过了别人的评审，如果简历条目暗示你是某个功能的唯一作者，而实际上是几位维护者共同塑造的，那么一旦有人查看提交历史就会显得夸大其词，而对于公开仓库来说，这只需要几秒钟。写明你具体的贡献，一次修复、一个功能、一个你经常评审的领域，而不是把整个项目的功能都描述得像是你独自完成的，能让这条内容既诚实，而且在多数情况下，也比一个笼统的说法更具体、更可信。如果你的多项贡献集中在项目的某一个领域，比如构建工具或测试套件，写明那个领域通常比逐条列出几个小的拉取请求更能给读者提供信息。
与你完全拥有的项目有何不同
一个你从零开始搭建的个人项目，值得写一句描述其用途和成果的话，因为它做什么、怎么做，每一个决定都是你自己做出的。一条开源贡献则值得写一句描述你在他人决定之中所承担的具体部分，因为项目的整体方向、架构和范围通常在你加入之前就已经定下。两者都是真实的、值得写进简历的技术工作，但把两者混为一谈，用描述自有项目的方式去描述开源贡献，往往要么夸大了你在共同项目中的角色，要么低估了你实际完成的具体工作。
应该放在简历的什么位置
一次有分量的开源贡献，或是随时间维持的维护者角色，通常适合在项目部分单独占一行，与个人项目并列，因为两者都描述的是有偿工作之外的技术投入。分布在不同项目上的若干较小贡献，往往更适合归在一个标题下，比如"开源贡献"，简要说明每个项目，而不是让四行单薄、彼此相似的内容占用与一条描述充分的条目同样的视觉分量。开发者模板在工作经历旁设有项目区域，无论这条贡献是源自一份工作还是完全独立存在，都适合放在这里。
把它添加到你的简历
一条被具体描述、诚实署名的开源贡献，是读者通常可以直接核实的、关于技术判断力的真实证据。从一个为工程工作设计的模板开始，把你的贡献添加到编辑器中，随着新的贡献不断出现，你可以持续打磨措辞。