---
author: Redhat
category: 代码英雄
comments_data: []
count:
  commentnum: 0
  favtimes: 0
  likes: 0
  sharetimes: 0
  viewnum: 3677
date: '2020-09-10 23:22:32'
editorchoice: false
excerpt: 想进入开源领域但不知道从哪里开始？你是一个贡献者，想知道为什么只有一些拉取请求被接受？或者，你是一个感觉有点不知所措的维护者？
fromurl: https://www.redhat.com/en/command-line-heroes/season-2/ready-to-commit
id: 12603
islctt: true
largepic: /images/p/202009/10/232142oamobtcu2qqquq9r.jpg
permalink: /article-12603-1.html
pic: /images/p/202009/10/232142oamobtcu2qqquq9r.jpg.thumb.jpg
related:
- displayorder: 0
  raid: 12595
reviewer: acyanbird, wxy
selector: bestony
summary: 想进入开源领域但不知道从哪里开始？你是一个贡献者，想知道为什么只有一些拉取请求被接受？或者，你是一个感觉有点不知所措的维护者？
tags:
- 代码英雄
- 开源
- 贡献
thumb: false
title: 《代码英雄》第二季（3）：准备提交
titlepic: true
translator: JonnieWayy
updated: '2020-09-10 23:22:32'
---


> 
> 代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。
> 
> 
> 



> 
> **什么是《代码英雄》**
> 
> 
> <ruby> 代码英雄 <rt>  Command Line Heroes </rt></ruby>是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。
> 
> 
> 


![](/images/p/202009/10/232142oamobtcu2qqquq9r.jpg)


本文是《[代码英雄](https://www.redhat.com/en/command-line-heroes)》系列播客[第二季（3）：准备提交](https://www.redhat.com/en/command-line-heroes/season-2/ready-to-commit)的[音频](https://dts.podtrac.com/redirect.mp3/audio.simplecast.com/ae4cf641.mp3)脚本。




> 
> 导语：想进入开源领域但不知道从哪里开始？你是一个贡献者，想知道为什么只有一些<ruby> 拉取请求 <rt>  Pull Request </rt></ruby>被接受？或者，你是一个感觉有点不知所措的维护者？
> 
> 
> 



> 
> 这一集将探讨投身于一个开源项目的意义。我们将跟随我们的英雄们，跟着他们在开源贡献者的角色中不断进步：从寻找项目并为其做出贡献，到建立和维护繁荣的社区。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 一起发起了我的第一个开源<ruby> 拉取请求 <rt>  Pull Request </rt></ruby>（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](http://redhat.com/commandlineheroes) 以获得更多信息。


**00:25:20 - Saron Yitbarek**：


快速提醒一下，这一季我们将构建我们自己的开源《代码英雄》游戏。欢迎你以对你来说合适的方式来做出贡献。快来了解如何成为其中一员吧。我们希望你可以通过 [redhat.com/commandlineheroes](http://redhat.com/commandlineheroes) 和我们一起开发这款游戏。


**00:25:42 - Saron Yitbarek**：


下一集，我们将讨论残酷的达尔文式错误以及开源开发中失败的美丽之处 —— 它如何困扰我们，指导我们，并使我们变得更好。


**00:25:57 - Saron Yitbarek**：


《代码英雄》是红帽的原创播客。你可以在 Apple Podcast、 Google Podcast 或是其他你喜欢的途径免费收听。我是 Saron Yitbarek，坚持编程，下期再见。



> 
> **什么是 LCTT SIG 和 LCTT LCRH SIG**
> 
> 
> LCTT SIG 是 LCTT <ruby> 特别兴趣小组 <rt>  Special Interest Group </rt></ruby>，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。
> 
> 
> 欢迎[加入 LCRH SIG](/article-12436-1.html) 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。
> 
> 
> 




---


via: <https://www.redhat.com/en/command-line-heroes/season-2/ready-to-commit>


作者：[Red Hat](https://www.redhat.com/en/command-line-heroes) 选题：[bestony](https://github.com/bestony) 译者：[JonnieWayy](https://github.com/JonnieWayy) 校对：[acyanbird](https://github.com/acyanbird), [wxy](https://github.com/wxy)


本文由 [LCRH](https://github.com/LCTT/LCRH) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出