体验为开源做出贡献的快乐。难以用言语形容我在收到合并通知（如下图）时的喜悦，当然这要归功于现在我上的工程学校 AltSchool Africa。在此之前，我曾多次接触过开源的概念，了解了它在技术领域的重要性，甚至参加过开源会议（比如 OSCAFest）。我曾多次跃跃欲试，但当打开 GitHub 来想创建些东西时，冒名顶替综合症就会冒出来。时间来到 2022 年 8 月 8 日星期一，当观看了 Bolaji 为开源做贡献的视频之后，我重新振奋起来。不过，想要把我学到的东西付诸实践，我注意到需要下面几个步骤：步骤：我要下定决心，做好为一个开源项目做出贡献的心理建设。我要根据我的技能水平进行筛选，我从一个站点（Good First Issues）寻找我开始的第一个项目。我不停地往下翻看，直到找到了一个符合心意的项目。我要确定自己掌握完成项目所需的 Git 和 GitHub 知识。LCTT 译注：“Good First Issues” 这个网站主要是针对那些想为开源软件做贡献，但不知道从哪里开始或如何开始的开发者。通过为开发者提供过滤器，该网站使他们能够根据自己熟悉的编程语言来浏览和选择问题和存储库。此外，他们还可以选择他们想要解决的问题的类型。项目经过长时间查找，我终于找到了一个名为 确保没有缺失的 alt 属性 的项目。我所要做的，就是为网站上的图片提供描述性的 alt 值。图片的 alt 值有助于提高网站的辅助功能，这样屏幕阅读器就可以向视障人士提供图像的详细描述了。这很简单，对吧？是的，但假如我没有下定决心想要作出贡献，我就不会找到这项目，在我心中开源仍将是个神话。我心潮澎湃，直到发现这个项目是来自 MDN 的。等等， MDN Mozzila 开发者网络 ？干和 Mozilla 的开发者一样的事儿？他们会合并我这么小儿科的贡献吗？冒名顶替综合症 又开始了。在检查这个议题时，我看到有人已经在提交贡献了，于是我鼓起勇气开始翻阅项目的内容。阅读和理解这个项目颇花费了我一些时间，而另一个要克服的，就是清楚处理这个议题我要怎么做。这个项目就像你想的那么简单。于是，我挑选了两幅图片着手尝试。我给它们的 alt 属性赋值，提交我的更改，然后发出拉取请求。从提交请求到收到批准邮件的这段时间，我充满了自我怀疑。我要不要关闭拉取请求？这可是 MDN 啊。好吧，这甚至都不算编程…… 如果请求没有被合并怎么办？我恐怕再也不会想为开源做出贡献了。不过，所有的疑虑都在我看到审阅者发来的这些邮件时烟消云散：我喜出望外，这激发了我去检查更多图片的热情，也给了我发请求解决其他议题所需的勇气。总结我希望你能从这篇文章中感受到以下几点：开源是面向所有人的。你在刚刚访问的那个网站上看到拼写错误了吗？你帮助订正了拼写错误，这就是为开源做出了贡献。没有任何技能是微不足道的。如你所见，我所做出的贡献，只需要对 HTML 最基本的了解。能阻止你做出贡献的只有你自己。要想让雪球滚起来，需要做的就只是提交第一个贡献。我衷心希望你能从我的经历中获得什么，并且今天就付诸实践。这也就是我想贡献的另一个领域，那么，我们下一篇文章见，也祝你开源愉快！这篇文章最初发布于 我的第一个拉取请求被合并，并经许可转载。via: https://opensource.com/article/22/9/first-pull-request-merged作者：Oluwaseun 选题：lkxed 译者：onionstalgia 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
事实上，有无穷无尽的方法来为开源做贡献，其中一个简单的方法就是回答我们的投票问题。你是如何参与开源贡献的呢？我们组织了一个投票，结果如下：提交错误报告 - 67 票（35%）解答用户的问题 - 39 票（20%）写作（指南、故事、文档等） - 73 票（38%）其他 - 12 票（6%）我的第一次开源贡献可以追溯到 20 世纪 80 年代中期，当时我们的机构第一次连上了 UseNet，在那里我们发现了贡献代码，以及在其开发和支持过程中和别人分享的机会。在今天，我们有无尽的贡献开源的机会。无论是贡献代码，还是制作一个视频教程，都是贡献的一种途径。不过，我将直接跳过整个贡献代码的部分。诚然，我们中有许多写代码但不认为自己是开发者的人，他们也可以 贡献代码。但是，我更想提醒大家，还存在很多 非代码形式可以贡献开源。接下来，我会谈到其中的三种。提交错误报告有一种重要而具体的贡献形式，它可以被描述为“不要畏惧 提交一个像样的错误报告”以及 与此相关的所有后果。有时，要 提交一个像样的错误报告 是很有挑战性的。比如说：某些错误可能很难记录或描述。当计算机启动时，屏幕上可能会出现又长又复杂的信息，其中包含各种不能理解的代码。或者屏幕上可能显示有一些“异常行为”，但是却没有提供具体的错误信息。某些错误可能很难重现。它可能只发生在某些特定的硬件/软件配置上，或者它可能很少被触发，或者错误的产生场景不明确。某些错误可能与一个非常特殊的开发环境配置有关，但是这个配置庞杂混乱，无法分享，需要先耗费大量精力创建一个精简后的例子才行。当向发行版报告一个错误时，维护者可能会建议将该错误提交给上游，这有时会需要付出大量的工作，因为发行版所提供的版本不是上游社区感兴趣的主要版本。（当发行版提供的版本落后于官方支持的发布和开发版本时，就会有这种情况发生）。尽管如此，我还是鼓励那些潜在的错误报告者（包括我）继续努力，并尝试让错误得到完整的记录和确认。但如何开始呢？你可以使用你最喜欢的搜索工具寻找类似的错误报告，看看它们是如何描述的，它们被归档在哪里，等等。你也可以留意你使用的发行版（例如，Fedora、openSUSE、Ubuntu）或软件包（LibreOffice、Mozilla）的错误报告页面，它们定义了正式的报告机制，你可以按步骤为他们报告相关错误。解答用户的问题我潜伏在各种邮件列表和 论坛 里，偶尔也会冒个泡，例如 Ubuntu 质量控制团队 和 论坛、LinuxQuestions.org，以及 ALSA 用户的邮件列表 等。在这里，我的贡献可能与错误报告的关系不大，更多的是记录复杂的用例。不过，看到有人热心帮助他人，解决他人在某个问题上的遇到的麻烦，对每个人来说，这都是无疑一种很棒的体验。从事开源相关的写作最后，另一个我非常喜欢贡献的领域是 撰写 关于使用开源软件的文章。无论是使用指南，还是对某一特定问题的不同解决方案进行比较评估，或者只是笼统地探索一个感兴趣的领域（就我而言，是使用开源音乐播放软件来享受音乐）。一个类似的选择是制作一个教学视频。你很容易就可以做到边演示一些复杂的桌面操作（比如用 GIMP 创建一个绚丽的标志），边 录制桌面。而那些精通两种或多种语言的人，也可以考虑将现有的使用指南或视频翻译成另一种语言。（LCTT 译注：读了这篇文章，你是不是想要马上投身于开源贡献呢？那么请考虑加入“Linux 中国翻译组（LCTT）”吧！我们有能帮助你快速上手翻译的 维基，有热心友爱的 QQ 群，你甚至还能够在我们的官网上获得属于自己的译者专页……心动了吗？那就立刻行动起来吧！阅读 维基 以了解如何加入我们。）via: https://opensource.com/article/19/4/contribute-without-code作者：Chris Hermansen 选题：lkxed 译者：lkxed 校对：校对者ID本文由 LCTT 原创编译，Linux中国 荣誉推出
成为为开源做贡献的技术写手的四个建议
你的开源贡献将会向潜在雇主表明，你会主动寻求学习、成长和挑战自我的机会。不管你是一个对技术写作有所涉足的技术爱好者，还是一个想要转职为职业技术写手的成熟技术专家，你都可以构建你的技术写作作品集，并将你的开源贡献作为作品集的一部分。为开源项目写作是一件有趣、灵活且低风险的事情。按照自己的时间安排来为你感兴趣的项目做贡献，你将会为社区是多么热情或你对社区产生影响的速度而感到惊喜。你的开源贡献将会向潜在雇主表明，你会主动寻求学习、成长和挑战自我的机会。和任何事情一样，你需要从某个地方开始。为开源项目做贡献可以让你在展示你的才华的同时学到新技巧、新技术。另外，为开源项目写作能让你接触到新的社区、跨越时区与新鲜面孔合作，并建立你的社交网络。当你挖掘到新的开源机会后，你的简历将更抢眼，让你在其他候选人中脱颖而出。以下是为开源做出贡献的四个建议，这可以让你走向技术写作的职业生涯。学习行业工具作为开始，我建议先熟悉 Git，并建立 GitLab 和 GitHub 帐号，然后寻找一个趁手的文本编辑器。我个人喜欢使用开源工具 Atom。关于 Git，它能从网络上获取到丰富的免费学习资源，包括一些优秀的互动教程。你不需要成为一个 Git 高手才能深入开源世界。我建议先学习一些基本操作，然后让你的技能随着你的贡献逐渐成长。找到一个项目为开源做贡献最难的部分大概是找到一个项目来做贡献。你可以查看 Up For Grabs 并找一些感兴趣的项目。First Timers Only 有更多的起步资源。别犹豫，联系项目维护者来了解更多有关于项目的东西，并了解他们在何处需要帮助。请坚持下去。找到一个适合你的项目可能会花费一些时间。告别“冒充者综合症”一个常见的误区是你必须是一个程序员才能为开源项目做贡献。作为一个没有工程或计算机科学领域有关证书的、自学成材的贡献者，我能保证事实并非如此。文档往往开发项目中最价值但最被忽视的部分。这些项目经常缺少人手和资源来建立完善的、高质量的文档。这给你展现了一个绝佳机会来参与提交拉取请求或归档该项目的议题。你可以做到的！（LCTT 译注： 冒充者综合症 Impostor Syndrome ，又称自我能力否定倾向，指个体按照客观标准评价为已经获得了成功或取得成就，但是其本人却认为这是不可能的，他们没有能力取得成功，感觉是在欺骗他人，并且害怕被他人发现此欺骗行为的一种现象。）从小处开始查看你感兴趣的项目的仓库，找到可能存在的贡献指南并遵循。然后，寻找更新 README 文档或提交修改错别字的机会。没有什么贡献是微不足道的。项目维护者可能会为这些帮助感到高兴，而你也将会因把你提交的第一个的拉取请求收录进你的技术写作作品集而感到愉悦。via: https://opensource.com/article/21/11/technical-writing-open-source作者：Ashley Hardin 选题：lujun9972 译者：yingmanwumen 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
一位新的开源贡献者告诉你如何加入到开源项目中。先前，我把我的第一次开源贡献的拖延归咎于冒牌综合症。但还有一个我无法忽视的因素：我做出决定太艰难了。在成千上百万的开源项目中选择时，选择一个要做贡献的项目是难以抉择的。如此重负，以至于我常常不得不关掉我的笔记本去思考：“或许我改天再做吧”。错误之二是让我对做出决定的恐惧妨碍了我做出第一次贡献。在理想世界里，也许开始我的开源之旅时，心中就已经有了一个真正关心和想去做的具体项目，但我有的只是总得为开源项目做出贡献的模糊目标。对于那些处于同一处境的人来说，这儿有一些帮助我挑选出合适的项目（或者至少是一个好的项目）来做贡献的策略。经常使用的工具一开始，我不认为有必要将自己局限于已经熟悉的工具或项目。有一些项目我之前从未使用过，但由于它们的社区很活跃，或者它们解决的问题很有趣，因此看起来很有吸引力。但是，考虑我投入到这个项目中的时间有限，我决定继续投入到我了解的工具上去。要了解工具需求，你需要熟悉它的工作方式。如果你想为自己不熟悉的项目做贡献，则需要完成一个额外的步骤来了解代码的功能和目标。这个额外的工作量可能是有趣且值得的，但也会使你的工作时间加倍。因为我的目标主要是贡献，投入到我了解的工具上是缩小范围的很好方式。回馈一个你认为有用的项目也是有意义的。活跃而友好的社区在选择项目的时候，我希望在那里有人会审查我写的代码才会觉得有信心。当然，我也希望审核我代码的人是个和善的人。毕竟，把你的作品放在那里接受公众监督是很可怕的。虽然我对建设性的反馈持开放态度，但开发者社区中的一些有毒角落是我希望避免的。为了评估我将要加入的社区，我查看了我正在考虑加入的仓库的 议题 issue 部分。我要查看核心团队中是否有人定期回复。更重要的是，我试着确保没有人在评论中互相诋毁（这在议题讨论中是很常见的）。我还留意了那些有行为准则的项目，概述了什么是适当的和不适当的在线互动行为。明确的贡献准则因为这是我第一次为开源项目做出贡献，在此过程中我有很多问题。一些项目社区在流程的文档记录方面做的很好，可以用来指导挑选其中的议题并发起拉取请求。 Gatsby 是这种做法的典范，尽管那时我没有选择它们，因为在此之前我从未使用过该产品。这种清晰的文档帮助我们缓解了一些不知如何去做的不安全感。它也给了我希望：项目对新的贡献者是开放的，并且会花时间来查看我的工作。除了贡献准则外，我还查看了议题部分，看看这个项目是否使用了“ 第一个好议题 good first issue ”标志。这是该项目对初学者开放的另一个迹象（并可以帮助你学会要做什么）。总结如果你还没有计划好选择一个项目，那么选择合适的领域进行你的第一个开源贡献更加可行。列出一系列标准可以帮助自己缩减选择范围，并为自己的第一个拉取请求找到一个好的项目。via: https://opensource.com/article/19/11/my-first-open-source-contribution-mistake-decisions作者：Galen Corey 选题：lujun9972 译者：chenmu-kk 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。什么是《代码英雄》 代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。本文是《代码英雄》系列播客第二季（3）：准备提交的音频脚本。导语：想进入开源领域但不知道从哪里开始？你是一个贡献者，想知道为什么只有一些 拉取请求 Pull Request 被接受？或者，你是一个感觉有点不知所措的维护者？这一集将探讨投身于一个开源项目的意义。我们将跟随我们的英雄们，跟着他们在开源贡献者的角色中不断进步：从寻找项目并为其做出贡献，到建立和维护繁荣的社区。Shannon Crabill 在 2017 年的 Hacktoberfest 上分享了她是如何开始从事开源工作的，而 Corinne Warnshuis 则介绍了将来自各种背景的人纳入到创造优秀软件的过程中是多么重要。为开源做出贡献的方式有很多。让我们一起来了解一下。00:00:03 - Nolan Lawson：在我刚开始做软件开发的时候，我基本上只做些让自己开心的小项目，像小应用程序、命令行小工具之类的。00:00:12 - Lindsey Tulloch：我只是真的不知道作出贡献那么容易。而且你不需要解决 P = MP 那样的难题，你的投入依然可以是很有价值的。00:00:21 - Kanika Muraka：本地社区使我有了足够的信心去做出贡献。00:00:28 - Saron Yitbarek：当我还完全是个编程新手的时候，我和我的朋友 Dan 一起发起了我的第一个开源 拉取请求 Pull Request （PR），这也是我的第一次开源贡献。00:00:42：我听过很多为开源做贡献的故事，说它有多么神奇，有多么可怕。我很清楚，并非所有社区都和善，也不是所有维护者都很友好。00:00:57：那个项目本身对新手来说相当不错。我们只是添加了一个 JavaScript 库，让人们可以在线预览网站。这是一个很好的适用范围很广、自成体系的项目。而且如果这玩意儿不起作用，我基本上确信它不会毁掉整个网站。00:01:18：然而，我对这个 PR 非常紧张。我和 Dan 阅读了这个库的文档，埋头于写我们的代码。我仍记得当我们最终完成的时候，只是互相看着彼此，好像在说：“就这样吗？”我们发起了 PR。它被审查，然后合并，我想我至今还是对这一切感到惊讶，我还是不知道这些机制是怎么运行的。00:01:43：这并不是什么只有他们才能做到的，也不是什么神秘或神奇的事情。我意识到我确实也可以对开源作出贡献。这是我们在这一集中想要传递的一点知识 —— 为开源做出贡献并不神奇，它也不一定可怕。我们将带你一起走过这个过程。00:02:05 - Lindsey Tulloch：这是一个突破性的认识，这些项目实际上是完全开放的，我也可以做出贡献。00:02:15 - Saron Yitbarek：在这一场的开场白中，你会听到像你一样的代码英雄在加入开源行列时，经历着同样的恐惧。他们分别是 Nolan Lawson、 Lindsey Tulloch、 Kanika Muraka，这些是今天来做客的代码英雄。00:02:34：你正在收听的是红帽公司的原创播客节目《代码英雄》。我是主持人 Saron Yitbarek。00:02:47：这是一个关于两个代码英雄的故事，他们只是想在广阔的开源世界中，做出更好的东西。他们其中一个人是贡献者，另一个人是维护者。他们都不是真实存在的人物，而是两个虚构人物，用来代表所有的贡献者和维护者，他们和我们分享了他们的故事。希望你也可以在他们的历程中看到一些你自己的影子。00:03:16：首先来见一见我们的朋友 —— 贡献者。她是个新手，就像曾经的我们那样。她不确定基本的工作流是什么，但是她看到了一个需求，并且认为她可以添加一个功能来提供帮助。我们这个虚构的贡献者很想提交代码，但是该怎么做呢？00:03:44 - Corinne Warnshuis：你一直在成长，学习新技能。而且你不一定必须在孩提时代拆过电脑，才有资格在成年后学写代码。00:03:52 - Saron Yitbarek：这位是 Corinne Warnshuis，一个名叫“Girl Develop It” 的很棒的组织的执行董事。该组织的目的是帮助那些可能不太敢提问的，或在聚会中觉得自己不太受欢迎的女性。00:04:07：Girl Develop It 意识到做出贡献的难度并不是对所有人而言都是一样的 —— 这是社会造成的问题。作为社区，我们的一部分职责，就是要让世界多一点同情心，以及包容健康多元文化。00:04:22 - Corinne Warnshuis：在我们看来，加入开源的壁垒有很多，但我们喜欢称它们为“没有充分的理由”，有三个这样的壁垒将女性专门排斥在技术之外，它们是：刻板印象、可及性和环境。00:04:40 - Saron Yitbarek：值得记住的是，促进多元化不仅具有良好的道德意义，同时也有商业意义。00:04:48 - Corinne Warnshuis：作为一个行业，技术可能拥有着最大潜力，能给当今世界带来最大的变化。你确确实实希望，来自各行各业的人们都为塑造世界的工具、服务和其他事物做出贡献。我认为来自各种背景的人们一起开发软件，并为开源项目做出贡献真的非常重要。00:05:13 - Saron Yitbarek：事实是，我们并非一开始就拥有同样的优势和经验。下一代的伟大开发者可能看上去并不像硅谷的程序员。00:05:23 - Corinne Warnshuis：面对面指导对人们而言，历来是非常昂贵而又难以获取到的。再者，我认为从 2014 年至今，情况有所改善。我认为除了 Girl Develop It 之外的组织（比如 Outreachy 和 CodeNewbie ），正通过提供安全的网络或空间，来提出问题并获得更多的舒适感来做到这一点。00:05:49：为这些想法和问题提供一个安全而友好的测试平台，是一个不错的起点。00:06:02 - Saron Yitbarek：说到新手，回到我们正在追踪的那个贡献者。倘若你不是来自主流背景时，那么第一次提交可能会压力非常大。感觉就好像你必须得证明你自己。不过一旦我们将加入的壁垒降得足够低，我们在准备做出贡献时，实际需要考虑的是什么呢？00:06:23 - Vincent Batts：对某些项目感到兴奋这事很酷，但你想要解决的用例是什么呢？00:06:31 - Saron Yitbarek：Vincent Batts 在红帽主要从事容器架构方面的工作。他鼓励新的贡献者尝试并有针对性地开展工作。找到你和项目一起有意义的那个利基。00:06:45 - Vincent Batts：我认为一个可让人持续贡献的项目通常来自于互惠关系。它满足了你的一个需求，而且在这个过程中你又发现了满足它的需求的方式。即使它是一个由人构成的社区，它也已经成为了一种共生体系。00:07:01 - Saron Yitbarek：比方说：00:07:02 - Vincent Batts：因为朋友的推荐，我最终弄了一台 Slackware Linux 机器。它非常适合我想做的事情，我帮着将其打包到了主流 Slackware Linux 社区，并最终成为了这个项目的贡献者和维护者。这并不是因为我想成为 Slackware Linux 社区的贡献者，而是因为这是最适合我的一个项目，它的用例正好是我一直致力于解决的事情。00:07:33：我想很多人都会遇到这种情况，他们因自己量身定制的用例而编写一个数据库软件。他们发现用 Golang 编写很合适，因此他们写了这样一个高性能的数据库，所以他们能够对 Golang 做出修复或优化方面的贡献，以帮助他们的数据库运行得更快。00:07:54 - Saron Yitbarek：你可以找到你自己的小众领域，并开始自然发展。关键在于，从某处开始去做。你不必等待有了学位或绝对的自信才开始。00:08:08 - Vincent Batts：如果你需要直接编写代码或文档的经历，或是成为一个后端数据库、Web 服务器的系统管理员，那么好消息是，大部分社区都是基于志愿者构成的。你可以参与诸如 Debian、Fedora 或其他一些类似的项目，这些社区都建立起了文档页面。那些项目必须在某处的 Web 服务器上运行，一些人，甚至是一个没有薪酬的、正在积累经验的社区成员，负责去检查 Web 服务器是否停机或出了什么问题。00:08:43 - Saron Yitbarek：Vincent 强调了开源的平等主义本质。无论你来自哪里，只要你愿意，都可以真正开始做出贡献。如果你想的话，你可以为自己扬名立万。00:08:57 - Vincent Batts：一旦它被合并，你的名字就会附在某个项目上。你可以公开表示你在某个地方做出了改进，这是相当有意义的事情。00:09:11：我曾与那些不是从事日常技术工作的电视修理工和教师共事过，他们很有代表性。他们也在社区上做出了很多贡献。另一方面，我也曾和一些开发者合作过，他们有的能有 30 年开发经验，但他们从来没有像那样公开贡献过代码。00:09:40 - Saron Yitbarek：对了，我们的贡献者怎么样了？嗯，她找到了她的定位。她克服了她的恐惧，并最终发起了她的第一个 PR。现在她可以休息一下，并战战兢兢地等待维护者作出回复。00:09:56 - Vincent Batts：向上游做贡献有点像第一次上台做才艺表演。你会感到紧张，走上舞台后手心冒汗。你做了一件事，然后它好像就变成了你的成就。你将被彻底改变，跟过去不再一样。00:10:17 - Saron Yitbarek：彻底改变？或许吧。事实上，维护者有四种可能的回应：沉默 —— 这很有趣，也可能是完全拒绝，或是直接接受，或是柔和的中间立场 —— 要求修改。00:10:37：提交 PR 的几天后，我们虚构的贡献者终于收到了来自维护者的回复。跪迎结果吧，是要求修改。作为一个新手，她将这视为一场小型灾难。她还不知道要求修改是个实际上是成功的一步。她甚至还对维护者的简略语气感到一点气愤，听上去就像维护者没空搭理她一样。00:11:03：这里存在着一堵墙，新的贡献者不知道墙的另一边正在发生什么。00:11:12：我们来认识一位维护者。他正在维护的项目并不是他的全职工作。这是一个周末项目，他时常熬到深夜，给工单排优先级，并且提醒人们发起 PR 时更新文档，然后你就明白了。他相当忙碌，有时甚至出现了一些维护倦怠。00:11:38：一位现实生活中的维护者，Nolan Lawson 写了一篇很棒的有关倦怠的文章，最近引起了很多关注。00:11:51 - Nolan Lawson：老实说，我认为那篇博文有一部分实在寻求帮助。这是我表达我自己偶然发现了这个开源的项目，起初我觉得它确实很有趣，但现在却感觉没那么有趣了。我不确定该如何恢复兴致。00:12:05 - Saron Yitbarek：Nolan 有一份日常工作，但和大多数维护者一样，他在开源项目中投入了大量的休息时间，因为这家伙真的很在意这个项目。讽刺的是，他的部分痛苦来自于，他清楚贡献者也同样很在意这个项目。00:12:23 - Nolan Lawson：真正使我精疲力竭的实际上只是如潮水般涌来的好心人。你真的想帮他们，真的真的很想。他们所做的只是问一个问题，他们所做的就是 —— 他们在你项目中发现了阻碍他们的 bug，或者他们所做的只是 —— 他们真的费心去下载代码并弄清楚它是如何构建的，并提供 bug 修复。他们只是希望你审查他们贡献的代码。00:12:43 - Saron Yitbarek：像 Nolan 这样的维护者正不断地审查 PR 库，弄清每个提交将如何发挥作用。他们促使贡献者尽可能做到最好，遵守内部限制，为了能让项目达到更高的水准，用最有意义的方式做出贡献。00:13:06：我的观点是，那些维护者有可能不是一个新贡献者所担心的混蛋。他们正努力地想去做到一切。他们甚至会花时间标注一些东西保留给新手（很多维护者都这样），以便新手有机会施展自己。00:13:27：但到最后，PR 和提交总是非常的多。我们要如何确保这种情况不会发生呢？我们该如何为维护者创造合理的环境呢？00:13:41：一种解决方案是 —— 像 Fedora 这样拥有强大社区的开源项目。Fedora 项目负责人 Mattew Miller 解释了项目吸引维护者和贡献者的地方。00:13:55 - Matthew Miller：Fedora 项目中许多不光是开发，还有开发过程中所相关的一切。总体来说，IT、 CS（计算机科学）事实上都是如此。开源可能并没有足够的这类围绕开源的支持性的角色。00:14:11 - Saron Yitbarek：那种支持实际上看起来是怎样的呢？00:14:14 - Matthew Miller：我们拿来举例的带薪角色之一是 Fedora 项目经理，他帮着让计划按部就班进行，并且监管着人们来保证文书工作完成。让人有酬劳地来做这份工作事实上可以帮着减少官僚主义，因为他们可以把时间花在使项目成为人看懂的事情，而不只是一堆杂乱的文件。00:14:34 - Matthew Miller：我认为，像这样的企业参与某些角色，可以赋予你无法用志愿者保证的稳定性。00:14:43 - Saron Yitbarek：这有点让我想起了自由职业者使用的共享工作空间。那里有一个共享的接待区、共享的 WiFi 和共享的咖啡。有一个人在管理它，然后你就可以自由地做你自己的事情。00:14:55：Matthew 告诉了我们另一个 Fedora 采取的策略。他们让你想在项目中途停下来休息一下时，可以很自然，而不是感觉一切都崩溃了。00:15:04 - Matthew Miller：我们研究的一个问题是确保领袖角色的漂亮退场，所谓的职位并不一定是终身的委任。你可以重新申请担任角色，并且不会在一年任期后结束后，看起来像被踢出去似的。如果六个月后你想离开，你可以优雅地这样做，而不必觉得这会让人失望。我们已在努力确保人们可以没有障碍地退出。00:15:27 - Saron Yitbarek：Matthew 认为，找到支持该开源社区的方法，而又不至于重蹈覆辙才是关键。00:15:35 - Matthew Miller：社区几乎就像一个家庭，而不是工作场所之类的东西。在这里做出贡献很有意义，因为你不仅只在为自己或是某些薪酬或终端产品工作。而且由于共事的是你的朋友，你们一起工作能做出比单人作品更伟大的东西。00:15:56 - Saron Yitbarek：无论是 Fedora 还是其他社区，它们都造就了一个开源贡献得以持续的世界，这个世界还值得努力让它继续变好。00:16:10：同时，让我们回到办公桌旁，我们关注的那个贡献者刚完成了维护者要求的修改。她还没意识到，但她即将拥有第一个被接受的 PR。00:16:24：当我们谈论诸如倦怠之类的长期工作的问题时，很容易忽视那些早期问题。每天都有很多新的贡献者加入进来。这实际上就是为什么我们需要构建可持续的社区，为所有这些开源魔术提供场地。00:16:49：最终，我们的贡献者和维护者共同努力，推动事情向前发展。故事的最后一句话 —— 记住所有的交流都依赖于 GitHub 和 GitLab 之类的开发平台，这些平台使得我们可以聚集到一起。00:17:09：我想深入探讨一下这些社区是如何使我们的工作成为可能的。我和 Shannon Crabill 谈过这个问题。Shannon 白天是个电子邮件开发者，但到了晚上，她正在学习前端开发。她也是一个对社区价值有第一手了解的人。00:17:28：去年她参加了一个长达一个月的名为 Hacktoberfest 的开源活动，该活动旨在让更多的人为开源做出贡献。当时， Shannon 完全是一个开源新手。00:17:44 - Shannon Crabill：回想起十月那时候，我感觉我没有太多工作要做，而且可能还有更多的新手，没找到需要做的东西。如果我提出一些相对容易的待办事项，他们就可以找到用于尝试和学习的突破口，并且开始习惯使用 Git 和 GitHub。00:18:04：我认为最困难的部分，在于习惯工作流程并付诸实践。如何推送存储库？如何分享项目？如何处理 PR 和相关的东西？我帮助人们对开源做出了贡献，这事令人惊讶，感觉也确实很棒。00:18:21 - Saron Yitbarek：真的很恐怖吗？我觉得如果你是个新手 —— 尽管你拥有存储库，也要走出自己的小世界，把自己放在社区里。现在，维护者所在的社区里出现了正在作出贡献的人，你必须和他们交谈，审查他们的代码并发表意见。这听上去是有点吓人。00:18:42 - Shannon Crabill：我认为最初的反应是，“哦，我的天哪，这太酷了”，还有，“天哪，我让自己陷入了什么境地？”我意识到我只合并过自己的代码，合并过自己的 PR 并将其推送到自己的站点上，以及其他所有只关于自己的事情，我从没处理过别人的东西。我认为我之前尚未完成过真正意味上的合并 PR，所以我不得不把这弄清楚。总的来说，将复杂的东西简单地合并起来，仍然是我要努力熟练解决的问题。00:19:09：这是旋风一样的感觉，“这很酷，但我不知道该怎么做。”每个人都很友好，并且我也努力保持非常友好和真诚，即使只是，“嘿，我有点不知所措。我看到了每个人提交的 PR。虽然今晚我不会找他们，但我明天会的。”人们对这种情况似乎反应良好。00:19:26 - Saron Yitbarek：是的。当你维护一个项目时（尤其是作为一个新的开发者时），我一直想知道的是，是不是这意味着你必须是整个存储库贡献者中最聪明的人？你实际上在评估、评判并审查其他人的代码。你是否遇到过，自己懂的东西不如提交 PR 的人那么多的情况？你是如何处理的？00:19:55 - Shannon Crabill：好问题。我认为，“噢，我需要成为有史以来最聪明最好的开发者”，这样的想法会成为障碍。我觉得自己很幸运，当我进入这个领域的时候，我没有这样想，所以我能像这样说，“让我们先开始，并且期待未来会发生什么吧。”00:20:12：你无需成为一个有 20 年经验的高级开发人员。你只需要有一个好点子，知道如何使用相应软件，然后愿意去学习自己不知道的东西。00:20:22：肯定有一两个 PR 为我的项目添加了一些很酷的功能，说实话，如果它们崩溃了，我真不知道该如何修复。我可能会看着代码然后想道，“是的，它崩溃了。”我不知道该怎么做才能从头构建它们。00:20:34：我认为这就是它酷的地方。如果只有我一个人在做贡献，我可能就做了一些基本的工作，但没法像其他拥有丰富经验的人所作出的贡献一样，将项目变得那么酷。00:20:45 - Saron Yitbarek：作为一个维护者，在使项目更易于访问，更加友好，更加易于贡献的过程中，你学到了些什么呢？00:20:55 - Shannon Crabill：哦，确实有件我认为很有帮助，并且我希望我一开始就做的事，那就是尽可能的建立模板，以及文档、文档、文档。00:21:07：我的确在我的 README 文件里加了很多东西，并且我认为在项目开始时有一个 README 文件确实是很重要的一步。这件事情意味着你对其他人大声说，“嘿，请查看我们的贡献指南。”我认为我制作了一个 PR 模板、一个议题模板，“单击这里查看当前议题”，这样人们才不会多次提交同样的内容。00:21:31：我认为让项目尽可能简单，或尽可能对用户友好，这是你作为维护者需要迈出的一大步。00:21:38 - Saron Yitbarek：绝对是这样，我经常看到 README 文件，经常听说他们有多么多么重要。我觉得在 README 文件里还可以做很多事情。归根结底，它就像是一个空白文档，告诉别人去阅读它。你应该在文档里写什么呢？你该如何构建它，来使得它真正与希望做出贡献的人产生关联呢？00:22:00 - Shannon Crabill：我在我的 README 文件里放了很多 gif。00:22:03 - Saron Yitbarek：很好。00:22:05 - Shannon Crabill：我有 gif，也有链接。00:22:07 - Saron Yitbarek：我一开始就知道 Shannon 已经认识到了合作关系的重要性。她早就知道，如果有人被邀请来协作，这项目就会变得耀眼，大家也会因此度过美好的时光。00:22:20 - Shannon Crabill：有人用开源项目作出很棒的事情，我也认为这很有趣，而且有个有意思的项目，“嘿，我制作了这些很酷的蝙蝠，每次你单击页面的时候，它们都会随机生成。”00:22:33 - Saron Yitbarek：我也喜欢人们做不同的事情。如果你真的很喜欢艺术性的东西，你可以做蝙蝠生成功能。如果你想让项目变得整洁，你也可以做。如果你想说，“我会坚持贡献文档，我将花时间为其他的贡献者们打造更干净，更舒适的环境”，那你也可以选择做这个。00:22:56 - Shannon Crabill：是的。我已经说得很清楚了，无论你想贡献的是什么，都没有问题。如果你发现了一个拼写错误并且想要纠正它，很好。如果你发现某个链接损坏并且想要修复它，也很好。如果你只是想帮着注释这份代码，使得它更易于阅读和理解，那也将很有帮助。00:23:12 - Saron Yitbarek：我认为，你在社区中获得了积极的反馈真的很棒，因为我听说过很多并不是这样美好的故事。人们在网络上并不十分友好，也不太热情善良，尤其是对我们这一些，可能会问出比他们想象中更简单问题的新手。00:23:33：你认为，是什么使得你的社区，比起其他社区更加友好呢？00:23:41 - Shannon Crabill：只是因为在我们社区，贡献是一件很随意的事。如果你想做出贡献，你可以，这很酷。如果你不想，那也很酷。我理解有人认为开源是一件令人恐惧的大事，你需要具备所有这些经验，并且了解所有这些复杂的语言，或是前后端以及其他的一切，才能够做出贡献。00:24:03 - Saron Yitbarek：绝对是这样。做 Hacktoberfest，它是怎样改变了你现在对开源的想法？00:24:11 - Shannon Crabill：它肯定对我造成了积极的影响。就像我说的，我有过很棒的经历，而且我希望每一个以某种方式参与我项目的人也能有很好的经历。这毫无疑问促使我想去尝试更多类似的事情，即使它们没有进一步的发展。现在这看起来这些项目更加平易近人了。00:24:32 - Saron Yitbarek：真是个好消息。00:24:34：这儿有个信息，来自数百家公司的数千人，以及一些根本没在公司工作的人，为 Linux 内核做出过贡献。这意味着基本上运行着互联网的 Linux 是由一群日常英雄在维护的。如果你渴望为开源作出第一次贡献，或许你会想了解有关 Fedora 社区的更多信息，我们有大量的资料正等着来帮助你。请查阅 redhat.com/commandlineheroes 以获得更多信息。00:25:20 - Saron Yitbarek：快速提醒一下，这一季我们将构建我们自己的开源《代码英雄》游戏。欢迎你以对你来说合适的方式来做出贡献。快来了解如何成为其中一员吧。我们希望你可以通过 redhat.com/commandlineheroes 和我们一起开发这款游戏。00:25:42 - Saron Yitbarek：下一集，我们将讨论残酷的达尔文式错误以及开源开发中失败的美丽之处 —— 它如何困扰我们，指导我们，并使我们变得更好。00:25:57 - Saron Yitbarek：《代码英雄》是红帽的原创播客。你可以在 Apple Podcast、 Google Podcast 或是其他你喜欢的途径免费收听。我是 Saron Yitbarek，坚持编程，下期再见。什么是 LCTT SIG 和 LCTT LCRH SIGLCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。欢迎加入 LCRH SIG 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。via: https://www.redhat.com/en/command-line-heroes/season-2/ready-to-commit作者：Red Hat 选题：bestony 译者：JonnieWayy 校对：acyanbird, wxy本文由 LCRH 原创编译，Linux中国 荣誉推出
学习如何做出你的首个 Linux 内核贡献，以及在开始之前你应该知道什么。Linux 内核是最大且变动最快的开源项目之一，它由大约 53,600 个文件和近 2,000 万行代码组成。在全世界范围内超过 15,600 位程序员为它贡献代码，Linux 内核项目的维护者使用了如下的协作模型。本文中，为了便于在 Linux 内核中提交你的第一个贡献，我将为你提供一个必需的快速检查列表，以告诉你在提交补丁时，应该去查看和了解的内容。对于你贡献的第一个补丁的提交流程方面的更多内容，请阅读 KernelNewbies 的第一个内核补丁教程。为内核作贡献第 1 步：准备你的系统。本文开始之前，假设你的系统已经具备了如下的工具：文本编辑器Email 客户端版本控制系统（例如：git）第 2 步：下载 Linux 内核代码仓库。git clone -b staging-testing git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git复制你的当前配置：cp /boot/config-`uname -r`* .config第 3 步：构建/安装你的内核。make -jX sudo make modules_install install第 4 步：创建一个分支并切换到该分支。git checkout -b first-patch第 5 步：更新你的内核并指向到最新的代码。git fetch origin git rebase origin/staging-testing第 6 步：在最新的代码库上产生一个变更。使用 make 命令重新编译，确保你的变更没有错误。第 7 步：提交你的变更并创建一个补丁。git add <file> git commit -s -v git format-patch -o /tmp/ HEAD^主题是由冒号分隔的文件名组成，跟着是使用祈使语态来描述补丁做了什么。空行之后是强制的 signed off 标记，最后是你的补丁的 diff 信息。下面是另外一个简单补丁的示例：接下来，从命令行使用邮件（在本例子中使用的是 Mutt）发送这个补丁：mutt -H /tmp/0001-<whatever your filename is>使用 get\_maintainer.pl 脚本，去了解你的补丁应该发送给哪位维护者的列表。提交你的第一个补丁之前，你应该知道的事情Greg Kroah-Hartman 的 staging tree 是提交你的 第一个补丁 的最好的地方，因为他更容易接受新贡献者的补丁。在你熟悉了补丁发送流程以后，你就可以去发送复杂度更高的子系统专用的补丁。你也可以从纠正代码中的编码风格开始。想学习更多关于这方面的内容，请阅读 Linux 内核编码风格文档。checkpatch.pl 脚本可以帮你检测编码风格方面的错误。例如，运行如下的命令：perl scripts/checkpatch.pl -f drivers/staging/android/* | less你可以去补全开发者留下的 TODO 注释中未完成的内容：find drivers/staging -name TODOCoccinelle 是一个模式匹配的有用工具。阅读 归档的内核邮件。为找到灵感，你可以去遍历 linux.git 日志去查看以前的作者的提交内容。注意：不要与你的补丁的审核者在邮件顶部交流！下面就是一个这样的例子：错误的方式：Chris, Yes let’s schedule the meeting tomorrow, on the second floor. > On Fri, Apr 26, 2013 at 9:25 AM, Chris wrote: > Hey John, I had some questions: > 1. Do you want to schedule the meeting tomorrow? > 2. On which floor in the office? > 3. What time is suitable to you?（注意那最后一个问题，在回复中无意中落下了。）正确的方式：Chris, See my answers below... > On Fri, Apr 26, 2013 at 9:25 AM, Chris wrote: > Hey John, I had some questions: > 1. Do you want to schedule the meeting tomorrow? Yes tomorrow is fine. > 2. On which floor in the office? Let's keep it on the second floor. > 3. What time is suitable to you? 09:00 am would be alright.（所有问题全部回复，并且这种方式还保存了阅读的时间。）Eudyptula challenge 是学习内核基础知识的非常好的方式。想学习更多内容，阅读 KernelNewbies 的第一个内核补丁教程。之后如果你还有任何问题，可以在 kernelnewbies 邮件列表 或者 #kernelnewbies IRC channel 中提问。via: https://opensource.com/article/18/8/first-linux-kernel-patch作者：Sayli Karnik 选题：lujun9972 译者：qhwdw 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
在开源项目中做出你的第一个贡献
这是许多事情的第一步有一个普遍的误解，那就是对开源做出贡献是一件很难的事。你可能会想，“有时我甚至不能理解我自己的代码；那我怎么可能理解别人的？”放轻松。直到去年，我都以为是这样。阅读和理解他人的代码，然后在他们的基础上写上你自己的代码，这是一件令人气馁的任务；但如果有合适的资源，这不像你想象的那么糟。第一步要做的是选择一个项目。这个决定是可能是一个菜鸟转变成一个老练的开源贡献者的关键一步。许多对开源感兴趣的业余程序员都被建议从 Git 入手，但这并不是最好的开始方式。Git 是由许多有着多年软件开发经验的超级极客维护的。它是寻找可以做贡献的开源项目的好地方，但对新手并不友好。大多数对 Git 做出贡献的开发者都有足够的经验，他们不需要参考各类资源或文档。在这篇文章里，我将提供一个对新手友好的特性的列表，并且给出一些建议，希望可以使你更轻松地对开源做出贡献。理解产品在开始贡献之前，你需要理解项目是怎么工作的。为了理解这一点，你需要自己来尝试。如果你发现这个产品很有趣并且有用，它就值得你来做贡献。初学者常常选择参与贡献那些他们没有使用过的软件。他们会失望，并且最终放弃贡献。如果你没有用过这个软件，你不会理解它是怎么工作的。如果你不理解它是怎么工作的，你怎么能解决 bug 或添加新特性呢？要记住：尝试它，才能改变它。确认产品的状况这个项目有多活跃？如果你向一个暂停维护的项目提交一个 拉取请求 pull request ，你的请求可能永远不会被讨论或合并。找找那些活跃的项目，这样你的代码可以得到即时的反馈，你的贡献也就不会被浪费。这里介绍了怎么确认一个项目是否还是活跃的：贡献者数量： 一个增加的贡献者数量表明开发者社区乐于接受新的贡献者。 提交 commit 频率： 查看最近的提交时间。如果是一周之内，甚至是一两个月内，这个项目应该是定期维护的。维护者数量： 维护者的数量越多，你越可能得到指导。聊天室或 IRC 活跃度： 一个繁忙的聊天室意味着你的问题可以更快得到回复。新手资源Coala 是一个开源项目的例子。它有自己的教程和文档，让你可以使用它（每一个类和方法）的 API。这个网站还设计了一个有吸引力的界面，让你有阅读的兴趣。文档： 不管哪种水平的开发者都需要可靠的、被很好地维护的文档，来理解项目的细节。找找在 GitHub（或者放在其它位置）或者类似于 Read the Docs 之类的独立站点上提供了完善文档的项目，这样可以帮助你深入了解代码。教程： 教程会给新手解释如何在项目里添加特性 （然而，你不是在每个项目中都能找到它）。例如，Coala 提供了 小熊编写指南 （进行代码分析的 代码格式化 linting 工具的 Python 包装器）。分类的 讨论点 issue ： 对刚刚想明白如何选择第一个项目的初学者来说，选择一个讨论点是一个更加困难的任务。标签被设为“难度/低”、“难度/新手”、“利于初学者”，以及“ 触手可及 low-hanging fruit ”都表明是对新手友好的。其他因素维护者对新的贡献者的态度： 从我的经验来看，大部分开源贡献者都很乐于帮助他们项目里的新手。然而，当你问问题时，你也有可能遇到一些不太友好的人（甚至可能有点粗鲁）。不要因为这些人失去信心。他们只是因为在比他们经验更丰富的人那儿得不到发泄的机会而已。还有很多其他人愿意提供帮助。审阅过程/机制： 你的拉取请求将经历几遍你的同伴和有经验的开发者的查看和更改——这就是你学习软件开发最主要的方式。一个具有严格审阅过程的项目使您在编写生产级代码的过程中成长。一个稳健的 持续集成 continuous integration 管道： 开源项目会向新手们介绍持续集成和部署服务。一个稳健的 CI 管道将帮助你学习阅读和理解 CI 日志。它也将带给你处理失败的测试用例和代码覆盖率问题的经验。参加编程项目（例如 Google Summer Of Code）： 参加组织证明了你乐于对一个项目的长期发展做贡献。他们也会给新手提供一个机会来获得现实世界中的开发经验，从而获得报酬。大多数参加这些项目的组织都欢迎新人加入。7 对新手友好的组织coala (Python)oppia (Python, Django)DuckDuckGo (Perl, JavaScript)OpenGenus (JavaScript)Kinto (Python, JavaScript)FOSSASIA (Python, JavaScript)Kubernetes (Go)关于作者Palash Nigam - 我是一个印度计算机科学专业本科生，十分乐于参与开源软件的开发，我在 GitHub 上花费了大部分的时间。我现在的兴趣包括 web 后端开发，区块链，和 All things python。via: https://opensource.com/article/18/4/get-started-open-source-project作者：Palash Nigam 译者：lonaparte 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
IBM 工程师 Phil Estes 分享了他的 Linux 爱好如何使他成为了一位开源领袖、贡献者和维护者。从很早很早以前起，我就一直使用开源软件。那个时候，没有所谓的社交媒体。没有火狐，没有谷歌浏览器（甚至连谷歌也没有），没有亚马逊，甚至几乎没有互联网。事实上，那个时候最热门的是最新的 Linux 2.0 内核。当时的技术挑战是什么？嗯，是 Linux 发行版本中旧的 a.out 格式被 ELF 格式代替，导致升级一些 Linux 的安装可能有些棘手。我如何将我自己对这个初出茅庐的年轻操作系统的兴趣转变为开源事业是一个有趣的故事。Linux 为乐趣为生，而非利益1994 年我大学毕业时，计算机实验室是 UNIX 系统的小型网络；如果你幸运的话，它们会连接到这个叫做互联网的新东西上。我知道这难以置信！（那时，）“Web”（就是所知道的那个）大多是手写的 HTML，cgi-bin 目录是启用动态 Web 交互的一个新平台。我们许多人对这些新技术感到兴奋，我们还自学了 shell 脚本、Perl、HTML，以及所有我们在父母的 Windows 3.1 PC 上从没有见过的简短的 UNIX 命令。毕业后，我加入 IBM，工作在一个不能访问 UNIX 系统的 PC 操作系统上，不久，我的大学切断了我通往工程实验室的远程通道。我该如何继续通过 Pine 使用 vi 和 ls 读我的电子邮件的呢？我一直听说开源 Linux，但我还没有时间去研究它。1996 年，我在德克萨斯大学奥斯丁分校开始读硕士学位。我知道这将涉及编程和写论文，不知道还有什么，但我不想使用专有的编辑器，编译器或者文字处理器。我想要的是我的 UNIX 体验!所以我拿了一个旧电脑，找到了一个 Linux 发行版本 Slackware 3.0，在我的 IBM 办公室下载了一张又一张的软盘。可以说我在第一次安装 Linux 后就没有回过头了。在最初的那些日子里，我学习了很多关于 Makefile 和 make 系统、构建软件、补丁还有源码控制的知识。虽然我开始使用 Linux 只是为了兴趣和个人知识，但它最终改变了我的职业生涯。虽然我是一个愉快的 Linux 用户，但我认为开源开发仍然是其他人的工作；我觉得在线邮件列表都是神秘的 UNIX 极客的。我很感激像 Linux HOWTO 这样的项目，它们在我尝试添加软件包、升级 Linux 版本，或者安装新硬件和新 PC 的设备驱动程序撞得鼻青脸肿时帮助了我。但是要处理源代码并进行修改或提交到上游……那是别人的事，不是我。Linux 如何成为我的工作1999 年，我终于有理由把我对 Linux 的个人兴趣与我在 IBM 的日常工作结合起来了。我接了一个研究项目，将 IBM 的 Java 虚拟机（JVM）移植到 Linux 上。为了确保我们在法律上是安全的，IBM 购买了一个塑封的盒装的 Red Hat Linux 6.1 副本来完成这项工作。在 IBM 东京研究实验室工作时，为了编写我们的 JVM 即时编译器（JIT），参考了 AIX JVM 源代码和 Windows 及 OS/2 的 JVM 源代码，我们在几周内就有了一个可以工作在 Linux 上的 JVM，击败了 SUN 公司官方宣告花了几个月才把 Java 移植到 Linux。既然我在 Linux 平台上做得了开发，我就更喜欢它了。到 2000 年，IBM 使用 Linux 的频率迅速增加。由于 Dan Frye 的远见和坚持，IBM 在 Linux 上下了“一亿美元的赌注”，在 1999 年创建了 Linux 技术中心（LTC）。在 LTC 里面有内核开发者、开源贡献者、IBM 硬件设备的驱动程序编写者，以及各种各样的针对 Linux 的开源工作。比起留在与 LTC 联系不大的部门，我更想要成为这个令人兴奋的 IBM 新天地的一份子。从 2003 年到 2013 年我深度参与了 IBM 的 Linux 战略和 Linux 发行版（在 IBM 内部）的使用，最终组成了一个团队成为大约 60 个产品的信息交换所，Linux 的使用涉及了 IBM 每个部门。我参与了收购，期望每个设备、管理系统和虚拟机或者基于物理设备的中间件都能运行 Linux。我开始熟悉 Linux 发行版的构建，包括打包、选择上游来源、开发发行版维护的补丁集、做定制，并通过我们的发行版合作伙伴提供支持。由于我们的下游供应商，我很少提交补丁到上游，但我通过配合 Ulrich Drepper （将一个小补丁提交到 glibc）和改变时区数据库的工作贡献了自己的力量（Arthur David Olson 在 NIH 的 FTP 站点维护它的时候接受了这个改变）。但我仍然没有把开源项目的正式贡献者的工作来当做我的工作的一部分。是该改变这种情况的时候了。在 2013 年末，我加入了 IBM 在开源社区的云组织，并正在寻找一个上游社区参与进来。我会在 Cloud Foundry 工作，还是会加入 IBM 为 OpenStack 贡献的大组中呢？都不是，因为在 2014 年 Docker 席卷了全球，IBM 要我们几个参与到这个热门的新技术。我在接下来的几个月里，经历了许多的第一次：使用 GitHub，比起只是 git clone 学习了关于 Git 的更多知识，做过 Pull Request 的审查，用 Go 语言写代码，等等。在接下来的一年中，我在 Docker 引擎项目上成为一个维护者，为 Dockr 创造下一版的镜像规范（支持多个架构），并在一个关于容器技术的会议上出席和讲话。如今的我一晃几年过去，我已经成为了包括 CNCF 的 containerd 项目在内的开源项目的维护者。我还创建了项目（如 manifest-tool 和 bucketbench）。我也通过 OCI 参与了开源治理，我现在是技术监督委员会的成员；而在Moby 项目，我是技术指导委员会的成员。我乐于在世界各地的会议、沙龙、IBM 内部发表关于开源的演讲。开源现在是我在 IBM 职业生涯的一部分。我与工程师、开发人员和行业领袖的联系可能比我在 IBM 内认识的人的联系还要多。虽然开源与专有开发团队和供应商合作伙伴有许多相同的挑战，但据我的经验，开源与全球各地的人们的关系和联系远远超过困难。随着不同的意见、观点和经验的不断优化，可以对软件和涉及的在其中的人产生一种不断学习和改进的文化。这个旅程 —— 从我第一次使用 Linux 到今天成为一个领袖、贡献者，和现在云原生开源世界的维护者 —— 我获得了极大的收获。我期待着与全球各地的人们长久的进行开源协作和互动。via: https://opensource.com/article/18/2/my-open-source-story-phil-estes作者：Phil Estes 译者：ranchong 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
8 种在你没有时间的时候为开源做贡献的方式
在忙碌的生活中抽出时间回馈给你关心的项目。人们不给开源做贡献（或不能做更多贡献）的最常见的原因之一是缺乏时间。人艰不拆，有这么多的优先的事情争夺你有限的注意力。那么，如何才能在忙碌的生活中为你关心的开源项目抽出时间呢？为了充分披露，我需要提醒你，我延误了把这篇文章给编辑的时间，因为我抽不出时间写它，所以是否接受我的建议，请自行承担风险。找出你所关心的贡献的第一步是弄清楚你正在做些什么。你有一个你自己的为之努力的项目吗？有没有一个你想要帮助的具体项目？或者你只是想做某个事情？弄清楚你正在做的事情将帮助你决定你的生活中的优先事项。找出其他的方法贡献编写新功能可能需要数小时的设计、编码和测试。这对于那种只有几分钟时间就得离开，然后再从原来的地方重新开始的情况下并不容易。如果你没有办法进行长于 30 分钟的无中断工作，当你试着完成一个大的任务时，你或许会感到沮丧。但还有或许可以满足你的需求的其它贡献方式，可以让你利用起来空闲的时间。其中一些可以通过智能手机快速完成，这意味着人们可以避免在通勤上浪费时间，并将其用于开源贡献。以下是可以在小块时间中完成的一些事情列表：Bug 分类： 所有的 bug 报告都有必要的信息来诊断和解决它们么？它们是否妥善提交（给出正确的范围，正确的严重程度等）了么？邮件列表支持： 用户或其他贡献者在邮件列表中提出了问题？也许你可以帮忙。文档修补： 文档经常（但不总是）可以比代码用更小块的时间来处理。也许有几个地方你可以补充一下，或者也许是时候浏览一下文档并确保它们仍然准确了。营销： 在社交媒体上谈论你的项目或者社区。写一篇快速入门博文。在新闻聚合里投票和评论。与你的老板交谈你可能会认为在上班时间里你不能在开源项目上工作，但是你有问过么？ 特别是如果这个项目以某种方式与你的日常工作相关，那你或许可以和你的老板谈谈，让你可在工作时做出贡献。请注意，这可能存在一些知识产权问题（例如，谁拥有你在工作时间内提供的代码的权利），因此首先做一下研究并以书面形式获得授权。设置最后期限我所学到的最佳时间管理建议可以归纳为两个规则：如果要完成，它必须有一个截止日期可以更改最后期限这篇文章有一个最后期限。它没有特别的时间敏感性，但最后期限意味着我定义了什么时候想完成它，并给编辑一个什么时候可以提交的感觉。是的，如上所述，我错过了最后期限。但你知道发生了什么事么？我设定了一个新的期限（二手才最棒！）。如果有些事是时间敏感的，在你需要返工一两次时，设置最后期限也可以给你一些空间。将它放到你的日程上如果你使用日历安排你的生活，那用它安排一些时间来开展你的开源项目，可能是完成此项工作的唯一方法。你计划多少时间取决于你自己，但即使你每周只用一小时作为开源时间，这仍会给你每周一小时的开源时间。这有一个秘密：有时候，如果你需要时间去做别的事情，或者什么都不想做，那么可以自己取消它。开拓未使用的时间你在通勤中感到无聊吗？你晚上睡觉困难么？也许你可以利用这个时间来贡献。现在我认为“每周完全投入工作 169 个小时”的生活方式是一件非常可怕的事情。也就是说，有些夜晚你不能入睡。也许你已经意识到了可以做贡献，而不是躺在床上看看你的 Twitter 上的朋友在世界的另一边做了什么（如我做的）。但是不要养成放弃睡眠的习惯。停止有时，贡献最好的方式是一点不贡献。你是一个忙碌的人，不管你是多么的棒，你不能避开你的生理和心理的需要，它们会找上你。花点时间来休息，这也许可以提高你的生产力，使你的工作更快，突然间你就有时间去做那些你一直想做的开源贡献了。说“不”我不擅长这个，所以我做的并不好。但是没有人能做到任何想做的事情。有时候，你可以做的最好的事情是停止贡献，就像以前一样，或者没有贡献（参见上文）。几年前，我领导了 Fedora 文档团队。团队的传统是，在每次发布结束时, 领导会主动提出下台。我已经做了一两次，没有人想要替代我，所以我继续保持着这个角色。但是在我的第二或第三次发布之后，我明确表示，我不会继续担任团队领导了。我还是很喜欢这份工作，但我有一份全职的工作，而且在研究生读到一半时，我的妻子怀了我们的第一个孩子。我没有办法做到始终如一的努力，所以我退出领导了。我继续做出贡献，但是在要求较低的能力的位置中。如果你正在努力抽出时间来满足你的义务（自我强加的或者不是），那么也许现在是重新考虑你的角色了。这对于你自己创建的或者已经大量投资的项目来说很困难，但有时你不得不这么做——为了你自己好以及项目本身。其他还有什么？你如何找到时间作出贡献？ 让我们在评论中知道。（题图： opensource.com）作者简介：Ben Cotton - Ben Cotton 是一个培训过的气象学家和一个职业的高效计算机工程师。 Ben 在 Cycle Computing 做技术传教士。他是 Fedora 用户和贡献者，合作创办当地的一个开源集会，是一名开源倡议者和软件自由机构的支持者。他的推特 (@FunnelFiasco)via: https://opensource.com/article/17/6/find-time-contribute作者：Ben Cotton 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
千里之行，始于足下 （ The journey of a thousand miles begins with one step ） —— 老子参与开源工作有很多好处，可以帮助你优化和加速技术生涯，包括但不仅限于提高现实中的技术经验和拓展你的专业人脉。有很多你能做贡献的开源项目，无论是小型、中型、大型，还是不知名或知名的项目。在这篇文章里我们将专注于如何为网上最大、最有名的开源项目之一 ，Mozilla ，做出贡献。为什么要向 Mozilla 做贡献？现实经验Mozilla 是网络上最大的开源项目之一，其也托管了许多其他的开源项目。所以，当你为像 Mozilla 这样的大型开源项目做贡献时，你能真正接触到技术领域中的事物是如何工作的，能增长关于技术术语和复杂系统功能的知识。最重要的是，你能理解如何将代码从本地系统移动到实际的代码仓库里。你将会学习在管理大型项目时，贡献者们使用的许多工具和技术，如 Github 、Docker、Bugzilla 等。社区联系社区是任何开源项目的核心。向 Mozilla 做贡献将你与 Mozilla 的员工和顾问、资深 Mozilla 贡献者（又称 Mozillians）以及你当地的 Mozilla 社区相互联系在一起。社区里有着同样关注并致力于改善开源项目的志趣相投的人们。你也能有个机会来建立在 Mozilla 社区里的专属身份，激励其他 Mozillians 同伴。如果你想的话，最后你也能指导其他人。活动和酷物件没有点充满乐趣的活动和小礼品的社区是不完整的。Mozilla 也不例外。向 Mozilla 做贡献能给你机会参加 Mozilla 的内部活动。一旦你成为熟练的 Mozilla 贡献者，你将能主持你当地的 Mozilla 活动（Mozilla 或许会予以资金支持）。当然，会另外提供些小礼品 —— 贴纸，T恤，马克杯等。根据 CC BY-SA 4.0 协议分享，印度 2016 Mozilla 聚会， Moin Shaikh 提供。如何向 Mozilla 做贡献不管您是编程人员、网页设计师、品质控制测试者、翻译，或者是介于之间的任何职业，都有许多不同的方式向 Mozilla 做贡献。让我们看看以下两个主要方面：技术贡献和非技术贡献。根据 CC BY-SA 3.0 协议分享， Mozilla.org 供图。技术贡献技术贡献是给那些喜欢编程，想要用他们的代码来弄出点动静的人。有不同的用特定编程语言的项目可供施展能力。如果喜欢 C++ ，你能向火狐的核心层和其他 Mozilla 产品做贡献。如果喜欢 JavaScript、HTML 和 CSS ，你能向火狐的前端做贡献。如果你懂得 Java ，你能向火狐移动端、火狐安卓版和 MozStumbler （LCTT 译注：MozStumbler 是 Mozilla 开源的无线网络扫描程序）做贡献。如果你懂得 Python ，你能给网络服务，包括 火狐同步 （ Firefox Sync ） 或者 火狐账户 （ Firefox Accounts ） 做贡献。如果你懂得 Shell、Make、Perl 或者 Python ，你能给 Mozilla 的编译系统和发布引擎和自动化做贡献。如果你懂得 C 语言，你能给 NSS、Opus 和 Daala 做贡献。如果你懂得 Rust 语言，你能给 RustC、Servo（一个为并行、安全而设计的网页浏览器引擎）或者 Quantum （一个将大量 Servo 转化为 Gecko 的项目）做贡献。如果你懂得 Go 语言，你能给 Heka 做贡献，这是一个数据处理工具。要获取更多信息，可以访问 Mozilla 开发者网络 Mozilla Developer Network （MDN）的开始部分来了解不同的贡献领域。除了语言和代码，积极测试火狐浏览器的各个部分、火狐安卓浏览器和 Mozilla 的很多网络组件，例如火狐附加组件等，这样也能贡献你的品质保证（QA）和测试能力。非技术贡献你也可以给 Mozilla 提供非技术贡献，专注于以下领域：品质保证（QA）测试，文档翻译，用户体验/用户界面（UX/UI）设计， Web 识别 （ web literacy ） ， 开源宣讲 （ open source advocacy ） ，给 Mozilla 的火狐用户、雷鸟用户提供支持等。品质保证（QA）测试： Mozilla 的 QA 团队遍及全世界，有着庞大且活跃的社区，他们深入参与到了火狐及 Mozilla 的其他项目中。QA 贡献者早期介入到各种产品，探索新的特性，记录漏洞，将已知漏洞分类，编写并执行测试用例，进行自动化测试，并从可用性角度提供有价值的反馈。想开始或者了解更多 Mozilla QA 社区资源，请访问 Mozilla QA 社区 网页。用户体验设计： 如果你是个有创意的设计者或是个喜爱折腾色彩和图形的极客，Mozilla 在其社区里有很多位置提供给你，在那里你能设计好用易理解的、美妙的 Mozilla 项目。去看看 Mozilla GitHub page 上的 开放设计仓库 Open Design repository 页面。用户支持（论坛和社交支持）： 这是成千上万像你我这样的火狐、雷鸟用户访问和发帖询问关于火狐、雷鸟问题的地方。这也是他们从像我们这样的 Mozilla 贡献者获取回答的地方。这不需要编程才华，不需要设计技能，不需要测试能力，作为火狐用户支持贡献者，你只需要有点儿火狐的知识即可上手。点击 SUMO 的“参与其中”的链接来加入用户支持。从做支持开始或许是你着手开始你的 Mozilla 旅程中最简单的部分。（注：三年前，我从社区支持论坛开始我的 Mozilla 旅程）编写知识库和帮助文章： 如果你喜欢写作和传授知识，知识库对你来说是个好地方。 Mozilla 总是在寻找能给火狐和其它产品用英文撰写、编辑、校对文章的志愿者。每周有成千上万的用户浏览这些知识库文章，通过分享你的智慧和编写帮助文章，你也能产生强大的影响力。访问 Mozilla 知识库 页面来参与其中。本地化，又称 “L10N”： （LCTT 译注：L10N 是 localization 的缩写形式，意即在 l 和 n 之间有 10 个字母） Mozilla 的产品，例如火狐，被全世界数百万讲着不同语言的人们所使用着。人们需要这些产品以他们的语言显示。语言本地化是个非常需要志愿者的领域。需要你的翻译和本地化能力的项目包括：Mozilla 产品，例如火狐Mozilla 网页和服务Mozilla 市场活动SUMO 产品支持文档MDN 开发者文档你可以访问 Mozilla 本地化页面来参与其中。教授和 Web 识别 （ web literacy ） 能力： Mozilla 基本使命目标之一是使所有人都可访问网络。为了实现这个目标使命，Mozilla 通过提供 web 识别工具和技术来致力于教育和帮助 Web 用户。这是可以用你的教授技能来帮助他人的地方。如果你是一位喜欢分享知识、给民众展示关于互联网相关东西的热情的老师，来看一下 Mozilla 发起的 Web 教育活动。将互联网和 web 识别教给你当地社区、学校孩子、你的朋友和其他有关的人。宣讲： 如果你对 Mozilla 的使命充满热情，你能通过倡导 Mozilla 的使命来传播使命内容。当倡导 Mozilla 的使命时，你能做出如下来贡献：捍卫公共规则，为开放的互联网和用户隐私做斗争。跟网站管理者在兼容性方面合作，提高网站的互操作性。帮助网络作者提升在开放网络方面的文章写作。成为 火狐朋友 （ Firefox Friends ） ，展示你作为 Mozilla 和火狐贡献者的自豪。想要开始帮助宣传 Mozilla 使命，看一下 Mozilla 宣讲 页面。如果你还有疑惑，我来帮你开始！我知道，作为一个新来的贡献者，这篇文章或许给你太多的信息。如果你需要更深入的方向、更多的资源资料，你可以在下面的评论中问我，或者在 Twitter 里私信我，我很乐意帮助你开始向 Mozilla 做出第一次的贡献（或者更多！）作者简介：Moin Shaikh 是一个开源科技极客，职业是网页分析，有着 7 年多的 IT 工作经验。主要贡献领域：火狐网络 QA ，火狐技术支持，本地化和社区指导。除了开源贡献，还学习并身体力行于用户体验、物料设计和电子商务分析。via: https://opensource.com/article/17/1/how-get-started-contributing-mozilla作者：Moin Shaikh 译者：ypingcn 校对：jasminepeng本文由 LCTT 原创编译，Linux中国 荣誉推出