如何选择(和贡献)你的第一个开源项目

by admin on 2020年1月12日

摘要:作为一名开源项目新晋贡献者,作者经常会感到迷失和沮丧。搞不明白不同的模块有什么区别,在体量巨大的代码库市场中也找不到方向。那么如何打破这样的状态……

本文是Github官方给出的参与Github上开源项目的一些指导,对希望加入开源社区的开发者是一个不错的参考。

翻译于github的文章推荐:How to choose (and contribute to) your first
open source
project
——作者 Katrina
Owen

图片 1

  最近一年开源项目特别的热,很多技术大会或论坛都以开源项目作为主题进行探讨,可见这是一种趋势。而Github作为开源项目的著名托管地,可谓无人不知,越来越多的个人和公司纷纷加入到Github的大家族里来,为开源尽一份绵薄之力。对于个人来讲,你把自己的项目托管到Github上并不表示你参与了Github开源项目,只能说你开源了自己的项目,可以任别人自由下载。

第一个贡献总是令人生畏的,这有点像走进一间全是陌生人的房间,他们大多数人之间似乎都认识对方。你不懂他们的圈内笑话(inside
jokes),或是圈外的笑话,进一步说,他们谈论的流行文化(pop
culture)是你从来没有听说过的。你不知道如何融入他们之间,如果有人侧身让你加入他们的交谈,他们可能会给你一个轻蔑的眼神,他们会告诉你,你穿错了衣服,你眼睛的颜色不对,甚至你的发音也不对。

作为一名开源项目新晋贡献者,我经常会感到迷失和沮丧。搞不明白不同的模块有什么区别,在体量巨大的代码库市场中也找不到方向。

那么该如何参与Github的开源项目呢?相信很多人都有这方面的疑问,网上
也有一些参差不齐的教程教大家如何“Pull
Request”、如何“Commit”等等。但这些教程往往不够全面或不够完全正确,搞不好可能让你陷入一个误区。鉴于此,前几天Github官方团队写了一篇很棒的文章
Contributing to Open Source on
GitHub,专业指导大家如何参与Github的开源项目。 下面是 原文的翻译。

这可能不仅仅发生在你提交第一个pull
request,甚至打开一个issue也让你感到胆怯。你遇到的是真正的问题吗?他们可能会告诉你你非常的愚蠢——因为你应该去做点什么小玩意。

我们中的很多人都经历过这个阶段,而这也是一个必然的阶段。我曾经挣扎无比。幸运的是,我最终还是走出来了。项目维护者们开始接受我的pull
request。我也重新找回了自信。


作为Exercism项目的维护者,我看到过许多人开始使用新的编程语言,提交或接受关于代码的反馈,以及对开源项目作出第一个贡献。你的第一个贡献可能很可怕,但是有了正确的指导,我相信你会像我一样热爱开源社区并热衷于成为其中的参与者。

我曾经写过一篇博客,里面描述了我的经历,并且鼓励其他刚刚成为开源项目贡献者的人们勇敢起来。这篇博客吸引了很多人的注意,他们也对我进行了回复。

参与开源项目的最佳办法就是加入到你正在使用的已有项目上来。Github上有500多万开源项目,涉及到各个领域的技术,像 recipes,
HTML/CSS,
Ruby,
Astrophysics等等。该指南将涵盖你在一个典型的项目中可能出现的事情以及如何为开源项目作出贡献。

这里有一些我挑出来的资源可以帮助你找到第一个开源项目以及做出有影响力的贡献来提高自己的编程技巧。

很多人联系到我,说我的那篇文章成功的鼓励了他们开始(或是重新开始)为开源项目做贡献。还有几个项目维护人员甚至重新查看了我以前提交的一些pull
request,并且通过了这些请求。能够得到这样的结果,我还能要求什么呢?

找项目

我们推荐你从已正在使用的或感兴趣的项目开始。这里有几个很棒的地方供你参考:

  • GitHub
    Explore
    :受欢迎和热门的项目。
  • GitHub
    Stars:被其他人star过的项目(指的是你自己库的项目)。
  • GitHub
    Showcases:一个能搜索相关库的方法。
  • LayerVault
    News:前端和设计相关的项目。
    图片 2
    项目示例

从你使用的项目开始

将你已经使用过的开源项目作为开始是最好的方法,有以下好处:

  • 你会更熟悉这个项目是什么以及它是如何工作的
  • 你更加能投入于项目的改进和效果
  • 你与项目的关系会更进一步,更加可能使你保持持续进步

想想你喜欢的库、模块、插件或者工具,看看你的工作项目或副项目(side
projects)的依赖性列表,找到repository并且浏览下里面的代码,文档,打开issue感受一下该项目的感觉。

不必去寻找你能想到的最大、最令人印象深刻的开源项目,有时候一个小一点项目能够让你的头脑更清醒。而且因为贡献者比较少,项目的维护者有更大的几率感谢你的贡献。

没有办法能够预先知道项目是否会接受你的贡献,但是有两件事可以提高你的代码被采纳的几率。

第一件事就是找到项目中欢迎贡献者的有关信息,第二件事就是弄清楚他们需要贡献的是什么内容。

在思考了一段时间之后,我总结出,我的那篇博客之所以能够吸引那么多人的注意力,是因为很长时间以来,有关开源项目贡献的话题,都在围绕着一方:维护者。

一个典型的项目

下面是一些你在Github开源项目中可能遇到的因素。

评估项目

你可以通过观察两件事——活动和交流风格,来对项目有一个更好的直觉——你是否想参与它。

查看commits列表,最近有commits吗?更新commit的的频率怎么样?大部分的commit是由一个人提交的还是有许多人们共同参与?

然后看看issues,查看open的issues。里面有多少issue?有新的吗?有时间很长的吗?维护者是否对其中的issue作出回应?他们进行了活跃的讨论了吗?然后再看看已经关闭的issues,近期他们有关闭过issue吗?

然后到pull request里面看看,像commit和issue一样。

当然,这些都不是绝对的,你不是在寻找绝对的数字。即使他们没有很多的活动,这也有可能是一个很好的项目,只不过它已经比较成熟和稳定了,不需要改变很多。但是如果一个项目有很多打开很久的issues和pull
requests,却没有得到维护者的回应,这可能是一个危险的信号。

按照评论数量查看 issues 和 pull
request,看看评论最多的,熟悉大家交流的风格,他们对贡献者友好吗?他们会处理好分支吗?维护者会对贡献者表示感谢吗?

有些维护者会对新的贡献者表示欢迎,会发送友好的感谢信息或emoji表情。

花点时间读读旧的issues或是邮件列表内容,如果他们有闲聊或是一些社交聊天频道,可以去看看,尽可能的收集关于项目工作的信息。对项目的交流有一个更好的感觉并且确保你愿意花时间跟这些人们共同参与这个项目。

当我第一次听到Babel的时候,我对它能够增加开发经验的方式感到非常兴奋。我遵循了Dan
Abramov的建议:“观察” Github
repo,尝试在项目和它的issues中得到更多的上下文信息,我在2015年3月2日提交了我的第一个
Babel pull request。
——
@hzoo

维护者总是在发表各种文章,讨论贡献者可以参与到项目中来。他们付出了很多努力,让自己的项目对于初学者也显得很友好。他们还写了大量的指导文章,告诉我们如何为开源项目贡献力量,并且在Quora和其他一些问答平台上回复人们提出的各种问题。

The Community(社区)

项目通常会有一个社区维护,由不同角色(正规或非正规)的其他用户组成:

  • 所有者(Owner):即创建该项目且在他们Github账户上有该项目的用户或组织。
  • 维护者和协作者(Maintainers and Collaborators):
    致力于一个项目并促进该项目发展的用户。通常所有者和维护者是同一个用户或组织,他们对项目库都有写的权限。
  • 贡献者(Contributors):每一个对该项目发出过pull
    request并合并到项目中的用户都是贡献者。
  • 社区成员(Community
    Members):即那些经常使用且非常关心该项目的用户,他们在讨论功能特征和pull
    request上非常活跃。

尝试

一旦找到一个你想为之贡献的项目,查看它的README文件,Readme通常有项目的贡献指南的链接,通常叫做Contributing.md,如果没有在Readme中找到它,你可以直接在项目中搜索它。

这些文件并不是一个项目的标准需求,但是这对于项目寻找贡献者以及贡献内容是一个很好的途径。

另一个寻找这些内容的地方是issues,你可以查找类似带有“help
wanted”或是“good first issue”之类标签的issues。

不要仓促的打开issue或是pull request

当你准备好为项目做一个贡献时,最好从小的地方做起。小的贡献能够让项目的维护者更了解你,这使他们可能更容易接受你的一些更大的贡献。

最好的开始贡献的方法之一就是帮助测试项目,当一个新的bug被发现的时候,看看你是否能复制这些错误,然后提交你的发现。

如果你一直观察,你会发现那些重复的问题以及那些被fixed却从未被关闭的issue。人们会问一些你知道答案的问题,你可以指引他们到相应的文档,如果没有文档,你可以向文档提交一个修复的建议。

我决定开始为这个团队管理电子邮件摘要,这给了我很好的机会来弄清一些话题,但是更重要的是我可以看到人们指出哪些问题需要被修复。
—— @brettcannon in his Open Source
Story

文档可以是最简单的,也可能是最难的贡献。有些唾手可得的拼写或是语法上的错误;另外文档的改变经常是在一定的范围内,可能是某一部分重新更改,用来提高可读性;或者是为遇到的一个特殊案例更新文档。一些更具有挑战性的文档可能涉及到重构或是一些底层指导。

从测试和文档开始,你可以看到你所贡献的一些小小的改变。

但是,很少有新的贡献者写文章讲述他们为开源项目贡献力量的故事。我个人阅读过很多维护者写的指导文章,但是我觉得这些文章都不如贡献者的实际经验那样实用。 

The Docs(文档)

一般项目中都有的文件。

  • Readme:几乎所有的Github项目都包含一个README.md文件。readme提供了该项目的一个概览及关于如何使用、构建甚至如何贡献于一个项目的相关细节。
  • Contributing:项目和项目维护者不同,所以每个项目所期望的作贡献的最佳方法也会有所不同。一定要注意一个标注为CONTRIBUTING的文档,Contributing文档详细描述了一个项目的维护者希望看到贡献的补丁或功能应该符合怎样的规格。这可能包含要写什么测试,代码语法规范或补丁集中的区域。
  • License:一个LICENSE文件当然就是该项目的许可证了。一个开源项目的license会告诉用户他们能做和不能做的(例如使用、修改、重新发布),及告诉贡献者他们允许其他人做的。有许多的办法对开源项目加上许可证,你可以在
    choosealicense.com读到更多的关于每个许可证的含义。
  • Documentation and
    Wikis:许多大型项目有的不只有一个readme来指导人么如何使用他们的项目。在这种情况下你通常能够发现一个指向库中名为“docs”的另一个文件或文件夹的链接。
![](http://cms.csdnimg.cn/article/201404/14/534b71d05b57b.jpg)
文档



  另外,该库也可能使用Github wiki来代替文档。



![](http://cms.csdnimg.cn/article/201404/14/534b7235b755f.jpg)

了解别人是怎么做的

如果你很想开始你的第一个贡献,但是又感到非常的紧张,这并不只有你一个人。即使是专业的软件开发人员也会感觉开源软件令人生畏,因为这涉及到你可能要与从未见过的人合作。

读读这些别人的经历来减弱你的害怕,从刚刚起步到成为专业的软件开发者,每个人都有关于第一次贡献代码的故事。

  • A Beginner’s Very Bumpy Journey Through The World of Open
    Source
  • Lessons from my First Open Source
    Contribution
  • Open Source: 9 steps to my first feature contribution in
    Babel
  • Figuring out how to contribute to open
    source

在交流的时候,如果只有一方在滔滔不绝,那么这个对话就很难实现平衡。我希望多读到点新晋贡献者所写的文章,讲述他们参与的项目,以及他们所遇到的各种困难和最终的解决办法。

贡献于一个项目

既然你已经找到了理解该项目的相关资料,下面你就可以采取一些行动了。

寻找一个陌生的,热情的项目

从一个你已经使用过的项目开始是一件比较容易的事情——如果你想为一个从来没接触过的项目或是想法做贡献,下面这些资源可以帮助你:

  • Your First
    PR
  • Up for Grabs: Projects which have curated tasks specifically for
    new
    contributors
  • CodeTriage: Help out your favorite open source projects and become
    a better developer while doing
    it.

如果你正在寻找对新的贡献者特别友好的项目,可以看看这些社区。它们有很好的文件和热情的氛围:

  • rust-lang/rust
  • HospitalRun /
    hospitalrun-frontend
  • hoodiehq /
    hoodie
  • pybee /
    batavia
  • Homebrew /
    brew

因此,我想要鼓励所有新的贡献者们记录自己的经历,帮我们找回对话中的平衡。我保证,你完全值得花时间和精力去做这件事情。

建立一个话题

如果你发现了你正在使用的项目中的一个bug(但是你不知道怎么去修复它),或对文档有不解或对项目有疑问

那么创建一个话题吧!这非常容易且一般你不管创建什么话题,你都可能不是唯一一个出现该问题的人,所以其他人可能会发现你的话题很有帮助。关于更多的话题介绍,请查看我们的
Issues
guide。

舒服的工作

如果你没有被这个过程吓到,你会对开源贡献感到更有信心。这里有一些资源可以帮助你开始:

  • How to Contribute to Open
    Source
  • Make a Pull
    Request
  • Patchwork: Casual, mentored workshops for beginners to Git and
    GitHub.

这里有一些组织帮助你了解Git,Github和对贡献开源软件:

  • freeCodeCamp
  • CodeBuddies
    Community
  • Your First
    PR
  • NodeSchool
  • OpenHatch

记录参与开源项目的经过,能够给你带来很多种好处。当你在写作的时候,你会回忆起许多细节。写作会强迫你客观的理解你所做过的事情。写作还能帮你更好的总结做过的事情,例如何时开始、以及当前的进度。

话题专业提示

  • 在建话题之前检查已有的话题:话题重复对双方都无利,所以搜索整个正开放和已关闭的话题以检查你遇到的问题是否已经有人解决了。
  • 务必对自己的问题有清晰的认识:期望的结果是什么?然而却发生了什么?
    详细描述其他人如何重现该问题。
  • 在像JSFiddle或
    CodePen类似的平台上重现该问题并给出问题demo的链接。
  • 包含一些系统相关的细节,比如用的什么浏览器、库或操作系统及版本号。
    在你的话题或在Gist里贴出你的错误输出或日志。如果在话题里贴出来,请用三个反引号“`
    包围起来使得能够良好的呈现给大家。

让这些成为习惯

每个人都有新的一次尝试,你的第一个开源贡献可能要花费一些时间,但这不是结束,规律性的贡献代码对你自己和你的社区都是很棒的事情。这些程序可以帮助你保持动力,让贡献开源代码成为你的习惯:

  • Open Source
    Friday
  • 24 Pull
    Requests

本文遵循自由转载-非商用-非衍生-保持署名(知识共享3.0协议)
This article follows the CC-3.0 License.

你可能担心自己知道的东西不足以让你写出好文章。但是我想说的是,在写作的时候,你不需要让自己成为某一领域的专家。你只需要把你理解的写下来就好。

Pull Request

如果你能够修复bug或自己添加功能 — 太棒了,请发一个pull
request吧!确保你已经读过任何关于contributing的文档,且需要理解license以及已经签过CLA(如果需要的话)。一旦你提交了一个pull
request,维护者就会将你的分支与已有的分支作比较来决定是否要合并(即pull
in)你作的改动。

最坏的结果,无非就是你把一些东西写错了。而如果你真的出了错,很可能有人会指出来。这个人会帮你进步,填补你知识的空白。这是一个双赢的局面。 

Pull Request专业提示

  • Fork
    该项目库及将它clone到本地。通过添加为远程的方式在本地连接到原来的‘upstream’库。经常从‘upstream’库pull
    in改动以保持库最新,这样当你提交pull
    request时,就不大可能发生合并冲突了。点这里看更多的指导细节。
  • 为你的编辑单独建立一个分支
  • 务必清楚所出现的问题以及如何重现该问题或为什么你的功能有帮助。然后同样的要清楚做一些改变有哪些步骤。
  • 最好测试一下。在任何已有的测试(如果存在)上运行你所做的改动并在必要时创建新的测试。不管测试存不存在,都要确保你的改动不会破坏已有的项目。
  • 如果你的改动包含了HTML/CSS方面的不同,那么请包含改动前和改动后的截图。将你的图片拖放到你pull
    request的正文里。
  • 尽你所能的在项目的风格上多做努力。这可能意味着使用不同于你自己Github库中采用的缩进,分号或注释,但是这让维护者更容易合并,也让其他人更容易理解和以后的维护。
![](http://cms.csdnimg.cn/article/201404/14/534b7275380df_middle.jpg?_=53854)

在其他开发者的博客中寻找启示

我的草稿箱中还有几篇文章没发。因为这些文章还不够好,还需要润色。

每当我有这样的想法的时候,我都会在互联网上寻找灵感和启示。有一天,我看到了A.
Jesse Jiryu
Davis写的文章《编写优秀的编程博文(Write
An Excellent Programming
Blog)》。在此之后,我会不断的重新阅读这篇文章,尤其是当我没有写作主题的时候,或是我觉得自己不够格就某一个话题撰写文章的时候。

另一个我经常去的寻找灵感的地方,就是Julia
Evans的博客。她的博文店铺很短、很简单,但是读起来令人愉悦。几乎她的每一篇文章,都能让我学到一些什么。

我还会时不时的看一看Stack Overflow的联合创始人博客:Joel On
Software and Coding
Horror。这里有很多优秀的文章,主题涵盖了与科技相关的各个领域。

当你开始寻找灵感以后,你就会找到很多好的资源。每一天,都会有很多开发者在网上发布大量有见解的文章。

开放的Pull Requests

一旦你打开一个pull
request,就会有一个讨论,围绕你提出的改变作出探讨。其他的贡献者和用户可能会参与进来,但最终由维护者做决定。你可能会被要求对你的pull
request做一些改变,如果这样,请给你的分支添加更多的commit并push它们 —
它们将自动的加入到已有的pull request里。
  如果你的pull
request被合并了——太好了!如果没被合并的话,也没什么大不了的,也许这不是项目维护者所期望看到的改动,亦或者他们已经致力于该bug或功能。这种情况有可能发生,所以我们的建议是:对收到的结果做出反馈,进一步努力然后再次pull
request出去— 或者创建你自己的开源项目。

如何寻找写作主题

在刚开始写作科技博文的时候,你很可能会感到不自信,这是很正常的事情。但是慢慢的,你会习惯。最开始的时候,你写的东西可以仅仅是记录每一天所做的事情:

  • 你是如何接触到你当前所参与的项目的?

  • 这里的社区都是什么样的人?他们对于新加入的贡献者是否展现了欢迎?

  • 你选择了哪个项目?为什么决定参与这个项目?

  • 设定本地环境以及克隆项目repo是否非常困难?你在哪里遇到了问题?最终如何解决了这个问题?

  • 你是否找到了要解决的第一个issue?

  • 如果项目给你指派了一个导师,你和这个导师相处的怎么样?他为你提供了哪些帮助?

  • 你以前觉得开源项目是什么样的?在真正参与之后,你现在觉得开源项目是什么样的?

  • 在参与了一段时间之后,你能给未来的新人提供哪些建议?

  • 在机构的IRC频道或是Gitter聊天室内,你要如何表现?要问哪些问题?

以上只是我现在能想到的一些主题。毫无疑问,在参与开源项目的过程中,你一定会想到其他一些更有意思的话题。

你不用特别给自己设定更新周期,有感觉了,想和其他人分享了就去写——无论是你克服了一个小困难,还是给项目做了巨大的贡献。

随着经验的不断丰富,你可以开始写一些技术性更强的文章。例如,你长时间研究的东西,也可以使你获取知识或是学习新语言/框架/库的过程。

你可能会觉得,你想些的话题,很多其他人都已经写过了,你可能想要写一些更具原创性的东西。

这么说吧,无论谁、写过多少类似的东西,这一点都不重要。对于同一件事情,每个人根据自己的理解,都会有不同的观点。你所写的每一篇文章,都折射出你自己的理解,而你对一件事情的理解,很可能与另外一个人大相径庭。 

你的任务,就是记录下你对开源项目的贡献。在你学习的过程中不断的写作。结果就是,你的学习速度会更快,最终成为一名更好的开发者。

你能够为其他迷失的人提供帮助,让他们找到一条通往开源软件的通途。

相信我,得知你写的东西为其他人提供了帮助,会让你有一种无与伦比的满足感。

  • 原    文:Hey newbie open source contributors: please blog
    more.

  • 译    文:SDK.cn

  • 作    者:Christian(编译)

  • 来源:SDK.cn

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图