标签 贡献 下的文章

体验为开源做出贡献的快乐。

难以用言语形容我在收到合并通知(如下图)时的喜悦,当然这要归功于现在我上的工程学校 AltSchool Africa

successful merge message

在此之前,我曾多次接触过开源的概念,了解了它在技术领域的重要性,甚至参加过开源会议(比如 OSCAFest)。我曾多次跃跃欲试,但当打开 GitHub 来想创建些东西时,冒名顶替综合症就会冒出来。

时间来到 2022 年 8 月 8 日星期一,当观看了 Bolaji 为开源做贡献的视频之后,我重新振奋起来。不过,想要把我学到的东西付诸实践,我注意到需要下面几个步骤:

步骤:

  1. 我要下定决心,做好为一个开源项目做出贡献的心理建设。
  2. 我要根据我的技能水平进行筛选,我从一个站点(Good First Issues)寻找我开始的第一个项目。我不停地往下翻看,直到找到了一个符合心意的项目。
  3. 我要确定自己掌握完成项目所需的 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,在那里我们发现了贡献代码,以及在其开发和支持过程中和别人分享的机会。

在今天,我们有无尽的贡献开源的机会。无论是贡献代码,还是制作一个视频教程,都是贡献的一种途径。

不过,我将直接跳过整个贡献代码的部分。诚然,我们中有许多写代码但不认为自己是开发者的人,他们也可以 贡献代码。但是,我更想提醒大家,还存在很多 非代码形式可以贡献开源。接下来,我会谈到其中的三种。

提交错误报告

有一种重要而具体的贡献形式,它可以被描述为“不要畏惧 提交一个像样的错误报告”以及 与此相关的所有后果。有时,要 提交一个像样的错误报告 是很有挑战性的。比如说:

  • 某些错误可能很难记录或描述。当计算机启动时,屏幕上可能会出现又长又复杂的信息,其中包含各种不能理解的代码。或者屏幕上可能显示有一些“异常行为”,但是却没有提供具体的错误信息。
  • 某些错误可能很难重现。它可能只发生在某些特定的硬件/软件配置上,或者它可能很少被触发,或者错误的产生场景不明确。
  • 某些错误可能与一个非常特殊的开发环境配置有关,但是这个配置庞杂混乱,无法分享,需要先耗费大量精力创建一个精简后的例子才行。
  • 当向发行版报告一个错误时,维护者可能会建议将该错误提交给上游,这有时会需要付出大量的工作,因为发行版所提供的版本不是上游社区感兴趣的主要版本。(当发行版提供的版本落后于官方支持的发布和开发版本时,就会有这种情况发生)。

尽管如此,我还是鼓励那些潜在的错误报告者(包括我)继续努力,并尝试让错误得到完整的记录和确认。

但如何开始呢?你可以使用你最喜欢的搜索工具寻找类似的错误报告,看看它们是如何描述的,它们被归档在哪里,等等。你也可以留意你使用的发行版(例如,FedoraopenSUSEUbuntu)或软件包(LibreOfficeMozilla)的错误报告页面,它们定义了正式的报告机制,你可以按步骤为他们报告相关错误。

解答用户的问题

我潜伏在各种邮件列表和 论坛 里,偶尔也会冒个泡,例如 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中国 荣誉推出

你的开源贡献将会向潜在雇主表明,你会主动寻求学习、成长和挑战自我的机会。

 title=

不管你是一个对技术写作有所涉足的技术爱好者,还是一个想要转职为职业技术写手的成熟技术专家,你都可以构建你的技术写作作品集,并将你的开源贡献作为作品集的一部分。为开源项目写作是一件有趣、灵活且低风险的事情。按照自己的时间安排来为你感兴趣的项目做贡献,你将会为社区是多么热情或你对社区产生影响的速度而感到惊喜。

你的开源贡献将会向潜在雇主表明,你会主动寻求学习、成长和挑战自我的机会。和任何事情一样,你需要从某个地方开始。为开源项目做贡献可以让你在展示你的才华的同时学到新技巧、新技术。另外,为开源项目写作能让你接触到新的社区、跨越时区与新鲜面孔合作,并建立你的社交网络。当你挖掘到新的开源机会后,你的简历将更抢眼,让你在其他候选人中脱颖而出。以下是为开源做出贡献的四个建议,这可以让你走向技术写作的职业生涯。

学习行业工具

作为开始,我建议先熟悉 Git,并建立 GitLabGitHub 帐号,然后寻找一个趁手的文本编辑器。我个人喜欢使用开源工具 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 SIG

LCTT 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-Hartmanstaging tree 是提交你的 第一个补丁 的最好的地方,因为他更容易接受新贡献者的补丁。在你熟悉了补丁发送流程以后,你就可以去发送复杂度更高的子系统专用的补丁。
  • 你也可以从纠正代码中的编码风格开始。想学习更多关于这方面的内容,请阅读 Linux 内核编码风格文档
  • checkpatch.pl 脚本可以帮你检测编码风格方面的错误。例如,运行如下的命令:perl scripts/checkpatch.pl -f drivers/staging/android/* | less
  • 你可以去补全开发者留下的 TODO 注释中未完成的内容:find drivers/staging -name TODO
  • Coccinelle 是一个模式匹配的有用工具。
  • 阅读 归档的内核邮件
  • 为找到灵感,你可以去遍历 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.

(所有问题全部回复,并且这种方式还保存了阅读的时间。)

想学习更多内容,阅读 KernelNewbies 的第一个内核补丁教程。之后如果你还有任何问题,可以在 kernelnewbies 邮件列表 或者 #kernelnewbies IRC channel 中提问。


via: https://opensource.com/article/18/8/first-linux-kernel-patch

作者:Sayli Karnik 选题:lujun9972 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出