分享转载 | 如何为开源做贡献?

Martin老王
22阅读0评论4 个月前

想为开源贡献力量?本指南针为"菜鸟"和初学者而准备!

为什么要为开源做贡献?

avatar

在 [自由代码] 下工作,让我学习到了职业生涯中非常重要的技能,无论是大学还是实际的工作,我认为从开源项目中得到的收获的远大於我的贡献!
@errietta, “我为何是如此的热衷于为开源软件贡献力量”为开源贡献力量,得到的回报就是能够学习到很多、受教很多、且能够锻炼任何你能够想到的经验。
为什么会有人为开源做贡献?这可能是很多人都不明白的地方,这里不妨列出一些!


巩固现有技能
无论是撰写代码、设计用户界面、图形设计、撰写文档、亦或是组织活动,假如你有实践的愿望,你总能在开源项目中找到自己的位置。


遇见那些和你”臭味相投”的人
开源项目一般都会有一个和谐、热心的社区,以让大家团结一致。实际上,开源界经常发生这样的情形,很多人的深厚友谊都是通过共同参与开源所建立起来的,至于具体的方式,可能是在一次技术研讨会上相谈甚欢,也可能是一直在聊天室中探讨问题。


寻找导师,并且尝试帮助他人
和他人共同在一个共享的项目下工作,这意味着需要向他人解释清楚自己是如何做的,同理,也需要向他人求助,询问别人是如何做的。相互学习和彼此教学对于每位参与者都能满载而归。


在公众间建立你的声誉(职业口碑)
根据开源的定义,你在开源下所有的工作都是公开的,这也就意味着开源项目是一个很好展示你实力的地方。


学习领导和管理的艺术
开源为实践领导力和管理技能提供了很好的机会,比如解决冲突、组织团队、工作的优先级排列。


鼓励作出改变,哪怕改变是很微小的
在开源的世界里,作出贡献的不一定非得是花了很长时间拥有大量经验的人。你是否遇到过浏览某些网站发现有拼写错误,希望有人能修改它?其实,在开源的项目中,你只需要做就可以了。没有那么多的顾忌,开源让人们在很舒服的状态做事,而这才是这个世界应有的体验。


贡献意味着什么
如果你是一名开源界的新手,可能会对贡献的流程心生畏惧。比如:该如何找到正确的项目?不懂编码又想参与怎么办?万一做错事情了怎么办?
其实没有关系的啦!条条大路通罗马,开源项目有太多的路径可以参与!以下是一些实用的技巧,帮助你快速的获得经验。


你不具备编码的能力
对于为开源做贡献常见的误解就是:为开源做贡献必须得提交代码。事实上,代码固然重要,但是项目中不需编码的重要部分经常被忽视。你若做了这部分,对于项目来说可是莫大的贡献,而这根本就不需要什么撰写代码!

avatar

我被大家所熟知是因为为 CocoaPods 做了一些事, 其实大伙并不知道我实际并没有为 CocoaPods 本身做了什么,我大多数的工作是诸如撰写文档、品牌宣传之类的。
@orta, “默认迁移到开源软件”即使你是一位开发者,非代码的贡献对于项目来说也是举足轻重的,尤其是对于社区的其他成员来说。用心维系这些关系能够让你有工作到项目其它部分的机会。

avatar

我第一次接触 Python 开发团队(简称 python-dev)是在 2002年6月17日,当时我是向其邮件列表发送了一份邮件,是关于请求通过我的补丁的。我很快就又发现了开源的 bug,于是决定开始为小组收集邮件摘要,然后他们给了我一个澄清问题的理由,但是更加重要的是,我能够捕获到某人指出需要修复的问题。
@brettcannon, “维护者的故事”是否热衷于规划事件?

是否偏向于设计?

  • 重新布置布局以提高项目的可用性
  • 进行用户研究以重新组织和完善项目的导航或菜单
  • 整理一个风格指南,以帮助项目有一致的视觉设计
  • 创建t恤的艺术或一个新的标志,就像 hapi.js 的贡献者那样

你是否热衷于写作?

  • 撰写和改进项目的文档
  • 能够以实例来展示项目该如何使用的
  • 为项目撰写新闻稿,或者到邮件列表高调布道
  • 为项目撰写教程,一如 pypa 的贡献者所做的
  • 翻译项目的文档为本土语言
avatar

说真心话, [文档] 是非常重要的. 目前 Babel 的文档已经很棒了,这也是其杀手锏的特性之一。当然,还有一些章节需要大家的完善,即使是随便在哪儿增加一个段落都很感激。
@kittens, “贡献者召集令”你喜欢组织活动吗?

  • 链接重复的问题,并建议新的问题标签,使事物井井有条
  • 通过开放的问题,并建议关闭旧的,就像 @nzakas 为 eslint 做的
  • 把最近开放的问题阐述清晰,以推动讨论

享受编码的乐趣?

热衷于帮助他人?

  • 回答关于项目的问题,例如在 Stack Overflow(像 Postgres 的这个示例)或者 reddit 上
  • 为人们解答公开的问题
  • 帮助缓和讨论板或对话渠道

在编码方面是否喜欢帮助他人?

其实不必一定是软件项目
尽管人们一提起”开源”二字,默认就是指开源软件,其实不尽然,开源可以是任何事情的修饰,而不仅仅是指软件而言的。比如图书、食谱、列表、以及任何可以开源的项目类。
举例来说:

尽管你是一名软件开发者,也可以去撰写一些文档去帮助新的入门者。其实项目中那些看起来令人生畏的项目并不是写代码,做开发者总得挑战自己,其实在做得过程中可以增强信心和获得全新的体验。
选择一个项目加入贡献

avatar

如果你跟着了一条 issue,还发现了令人感到困惑的事情,这很正常,不是你一个人这样。这些工具需要大量的隐式的知识,但是总会有人带着你熟悉这些,当然你要找他们问对的问题。
@shaunagm, “如何为开源做贡献”为开源做贡献,除了单词拼写错误之外,大多数时候就像是走在陌生人中间,浑身上下不适。这就像人们已经在西边讨论的非常深入了,你突然开始讲东,肯定会让人感到不舒服。
与其盲目的在项目中游荡,不如静下心来学习规则。这样反而会让你的想法被注意到,也会有人听到你的声音。
分析感兴趣的开源项目
每一个开源社区都是不一样的。
在某一个开源项目扎根多年,这意味着你只是对这一个开源项目无比的熟悉。若是切换到不同的项目,可能会发现完全是另外一回事,所谓的使用词汇、习惯用语、沟通方式都发生了变化。
然而,很多的开源项目还是遵循类似的组织结构的。理解不同的社区角色和全部的流程,可以很好的帮助你快速的切入新的项目。
一个典型的开源项目均会有如下类型的人:

  • 作者: 项目的创始人或创始组织
  • 归属者: 代码仓库或组织的管理员(不一定和作者是同一个人)
  • 维护者: 贡献者,负责项目的未来走向和组织的管理(他们通常也是项目的作者或归属者。)
  • 贡献者: 只要是为项目做出了贡献,就算。
  • 社区成员: 那些使用项目的人们。他们或许是积极的讨论者,又或者是为项目的方向提出意见的人。

一个较大的项目,可能下面还会细分子社区,或者是针对不同的任务分成不同的小组,比如工具小组、分流、社区事务、以及活动组织等。径直到项目到 web 站点,找到”团队”页面,或者是查看治理文档,从而获得类似到信息。
靠谱的开源项目,一般都会有文档的,这些文档文件通常会在代码仓库的顶级目录列出。

  • LICENSE: 根据开源软件的定义,每一个开源项目必须是有开源许可协议的. 可以这么认为:假如说某个项目源码开放,但是没有任何的许可协议,那么它就不能叫做开源。
  • README: README 是一个介绍性的说明文件,对初次光临社区的人们表示欢迎,它通常会解释项目有何用处,为何发起,以及如何快速入门等。
  • CONTRIBUTING: READMEs 帮助人们来认识项目,CONTRIBUTING 这个文件则是帮助对项目如何做贡献。它解释了目前项目需要什么样类型对贡献者,社区的流程是什么样的。并非所有的项目都会有这个文件,它某种程度上也是展示项目对于贡献者的友好程度。
  • CODE_OF_CONDUCT: 顾名思义,即是一些参与社区时的一些礼仪、说话方式、行为等,帮助形成一种友好的氛围,不是所有的项目都会撰写行为准则文件,它某种程度上也是展示项目对于贡献者的友好程度。
  • 其它文档: 有些项目也许还有其它文档,例如教程、导游,或者是治理规则,这在大型项目中常见。

此外,开源项目还会利用如下一些工具来进行组织讨论,阅读这些归档对于理解社区的想法、是如何工作的有非常大的作用。

  • 问题追踪: 这里是人们讨论项目相关问题的地方。
  • Pull requests: 审核代码、以及相关的问题讨论。
  • 论坛或邮件列表: 一些项目会实用会话式的主题(例如 “How do I…““What do you think about…“ 来替代 Bug 报告或特性请求)。然而有一些项目关于讨论全部实用问题追踪。
  • 即时在线聊天: 有一些项目会实用聊天频道(诸如 Slack 或 IRC),从而能够随意的谈话、协作和快速交流。

找一个项目开始贡献
你读到这里,说明已经对于一个开源项目如何运作的有了清晰的认识,是该找一个合适的项目做贡献的时候了!
假如你之前从来都没有为开源做过贡献的话,那么请记住来自美国总统约翰 F.肯尼迪的这段话:不要问你的国家能为你做什么,要问你能为国家做什么。
开源项目的方方面面都需要贡献者,你先不要通盘考虑你的第一个贡献会是什么,或者是它看起来如何。
相反,从你已经使用到的或者打算用到的项目开启贡献之路,在你积极的贡献过程中,项目也会反馈给你,让你更好的定位自己。


一旦进入某项目,不论何时,你都要听从自己的直觉,做你认为更好或者不同的事情。
开源并不是高级俱乐部;它就是由你这样的人所浇铸和打造。“开源”只是针对这个世界的需要修复的问题的一个梦幻术语罢了。
你或许在查看 README 的时候,发现了损坏的链接,又或者拼写错误。又或者是你是一名新手,使用的过程中发现了问题,又或者是某问题应该在文档中注明。请不要坐视不理,径直绕开,或者是请求他人修复,伸出你的援助之手,解决这些你能看到的问题。而这正是开源的精髓之所在!
28% 的随意贡献 就是说明了文档的开源,诸如拼写错误,段落语句调整、或者是翻译。
你也可以利用如下列出的资源来找到合适的新项目:

提交贡献之前的检查列表
当你找到了你打算贡献的项目时,在进一步行动之前,作一个快速的扫描工作,以确保项目是否接受贡献的。否则,你煞费苦心的工作可能没有任何的回报。
这是一个简易的检查表,用来评估一个项目是否适合新的贡献者。


符合开源的定义
有许可协议吗?通常情况下,会在根目录有一个叫做 LICENSE 的文件。


项目被接收的提交活跃度
在主干上确认提交的活跃度。在 GitHub 上托管的开源项目,你可以在仓库主页上看到这些信息。

最后一次提交是在什么时候?
项目目前有多少贡献者?
人们提交的频繁吗? (在 GitHub,可以在顶栏里点击"commits"来展现。)
接下来,就是看项目的 issue 数量。
目前有多少个还处于开放状态的 issue?
项目的维护者对于处于开放状态的 issue 响应是否迅速?
是否有讨论很活跃的 issue?
issue 均是近期产生的吗?
有没有关闭的issue? (在 GitHub, 点击 "closed" 标签就可以看到所有已经关闭的 issue。)
同样再来看看 PR 的情形。
现下有多少处于开放状态的 PR?
当提交了 PR 后,维护者响应是否迅速?
是否有活跃讨论的 PR?
均是近期的 PR 吗?
最近有多少 PR 合并? (在 GitHub, 点击 PR 页面的 "closed" 的标签页来查看已经关闭的标签页。)


项目的受欢迎程度
一个项目的友好程度和受欢迎意味着更能吸引新的贡献者。
在 issue 的问题中,维护者的回答是否非常有帮助?
人们在 issue 的讨论中、在线聊天室、论坛是否很友好?
PR 是否被 review?
维护者是否对做贡献的人们道声"谢谢"?

avatar

当你看到一个很长的对话时,来自核心开发者的零星的响应排在列表的后面。你就得考虑,他们在作建设性的总结?是否保持风度的情况下做出最后的决定?如果你看到的是更多的口水仗,而且还在继续,这通常意味着社区的能量重心已经不在开发上了。
@kfogel, 开源软件生产力如何提交贡献
你已经找到了你喜爱的项目,也已准备好贡献了,迫不及待、跃跃欲试了。好吧!以下就是带领你如何以正确的姿势作贡献。


有效沟通
无论你处于什么样的目的:仅仅是一次性的贡献,亦或是永久性的加入社区,都得和他人进行沟通和交往,这是你要在开源圈发展必须修炼的技能。


avatar

[作为一名新手,] 我很快的就意识到,我若是要关闭一条 issue 时,我不得不问更多的问题。我浏览了代码库,一旦我觉得有什么问题的时候,我就得需要更多的指点,瞧! 在我得到所有的所需要的信息后,我就可以解决这个问题!
@shubheksha, 一名菜鸟进入开源世界的坎坷之旅在你开启一个 issue 或 PR 之前,或者是在聊天室问问题之前,请牢记下面所列出的几点建议,会让你的工作更加的高效。


给出上下文 以便于让其他人能够快速的理解。比方说你运行程序时遇到一个错误,要解释你是如何做的,并描述如何才能再现错误现象。又比方说你是提交一个新的想法,要解释你为什么这么想,对于项目有用处吗(不仅仅是只有你!)
😇 “当我做 Y 的时候 X 不能工作”
😢 “X 出问题! 请修复它。”


在进一步行动前,做好准备工作。 不知道没关系,但是要展现你尝试过、努力过。在寻求帮助之前,请确认阅读了项目的 README、文档、问题(开放的和关闭的)、邮件列表,并搜索了网络。当你表现出很强烈的求知欲的时候,人们是非常欣赏这点的,会很乐意地帮助你。
😇 “我不确定 X 是如何实现的,我查阅了相关的帮助文档,然而毫无所获。”
😢 “我该怎么做 X ?”


保持请求内容短小而直接。 正如发送一份邮件,每一次的贡献,无论是多么的简单,都是需要他人去查阅的。很多项目都是请求的人多,提供帮助的人少。相信我,保持简洁,你能得到他人帮助的机会会大大的增加。
😇 “我很乐意写 API 的教程。”
😢 ” 有一天我驾驶汽车行驶在高速公路上,在某个加油站加油的时候,突发奇想,我们应该这么做,不过在我进一步解释之前,我先和大家展示一下。。。”


让所有的沟通都是在公开场合下进行。 哪怕是很不起眼的小事,也不要去给维护者发私信,除非是你要分享一些敏感信息(诸如安全问题或严重的过失)。你若能够保持谈话是公开的,很多人可以在你们交换的意见中学习和受益。
😇 (评论) “@维护者 你好!我们该如何处理这个 PR?”
😢 (邮件) “你好,非常抱歉给发信,但是我实在很希望你能看一下我提交的 PR。”


大胆的提问(但是要谨慎!)。 每个人参与社区,开始的时候都是新手,哪怕是非常有经验的贡献者也一样,在刚进入一个新的项目的时候,也是新手。出于同样的原因,甚至长期维护人员并不总是熟悉一个项目的每一部分。给他们同样的耐心,你也会得到同样的回报。
😇 “感谢查看了这个错误,我按照您的建议做了,这是输出结果。”
😢 “你为什么不修复我的问题?这难道不是你的项目吗?”


尊重社区的决定。 你的想法可能会和社区的优先级、愿景等有差异,他们可能对于你的想法提供了反馈和最后的决定的理由,这时你应该去积极的讨论,并寻求妥协的办法,维护者必须慎重的考虑你的想法。但是如果你实在是不能同意社区的做法,你可以坚持自己!保持自己的分支,或者另起炉灶。
😇 “你不能支持我的用例,我蛮失望,但是你的解释仅仅是对一小部分用户起作用,我理解是为什么。感谢你的耐心倾听。”
😢 “你为什么不支持我的用例?这是不可接受的!”


最重要的是,保持优雅 开源社区有来自世界各地的协作者,所以跨语言、文化、地理位置和时区的情况下会丢失上下文语境。另外,书面交流使得传达语气或情绪变得更加困难。对话过程中善意的理解对方的意图。礼貌地反驳他人的想法,询问更多的上下文语境,或进一步澄清你的立场都是好事。我们要让互联网变得更加美好。
收集上下文
在正式开始之前,做一些快速的检查项,以确保你的想法是没有被讨论过的。遍历项目的 README、问题(开放的和关闭的都算)、邮件列表、Stack Overflow。毋需去花好几个小时去全部折腾一遍,但是使用几个关键的词汇来搜索一下是必要的。
如果你没有找到和你想法一样的内容,你就可以继续了。如果项目是在 GitHub 上的话,你可以通过开启一个 issue 或 PR:

  • Issues 开启一次对话或讨论
  • Pull requests 请求接受自己的解决方法
  • 少量的沟通, 诸如澄清或how-to的问题,尝试到 Stack Overflow、IRC、Slack 或其它聊天频道。

在你创建 issue 和 PR 之前,请检查项目的贡献者文档(文件名通常叫做 CONTRIBUTING,或者就直接包含在README中),找一些你需要的较具体的东西,例如,他们会要求你遵循某个模版,或者是要求你使用某个测试。
如果你做的是一个非常实际的贡献,在正式开启之前,先创建一个 issue。监视项目是很有帮助的(在 GitHub,点击 “Watch”,所有的对话都会通知到你),要让社区的成员们知道你要做的工作,免得你做了之后,再让他们知道,他们不同意,就浪费了。

avatar

你能够从单个的项目学习到 很多 ,只要你踊跃的去使用,在GitHub上密切观察项目,并阅读每一个 issue 和 PR。
@gaearon 参与项目创建 issue
你应该在遇到下列情况下,去创建一个 issue:

  • 报告你自己无法解决的错误
  • 讨论一个高级主题或想法(例如. 社区、远景、政策等)
  • 期望实现某新的特性,或者其它项目的想法

在 issue 的沟通中几点实用的技巧:

  • 如果你刚好看到一个开放的 issue,恰是你打算解决的, 添加评论,告诉他人你将负责这个。这样的话,可以避免他人重复劳动。
  • 如果说某个 issue 已经开放很久了, 这可能是已经有人正在解决中,又或者是早已经解决过了,所以也请添加评论,在打算开启工作之前,最好是确认一下。
  • 如果你创建了一个 issue,但是没多久自己解决了, 也要添加评论,让其他人知道,然后关闭该 issue。记录本身就是为社区的贡献。

创建 pull request
在下面的情形时,请你务必使用PR:

  • 提交补丁 (例如,纠正拼写错误、损坏的链接、或者是其它较明显的错误)
  • 开始一项别人请求的任务,或者是过去在 issue 中早就讨论过的

一个 PR 并不代表着工作已经完成。它通常是尽早的开启一个 PR,是为了其他人可以观看或者给作者反馈意见。只需要在子标题标记为”WIP”(正在进行中)。作者可以在后面添加很多评论。
如果说项目是托管在 GitHub 上的,以下是我们总结出的提交 PR 的建议:

  • Fork 代码仓库 并克隆到本地,在本地的仓库配置”上游”为远端仓库。这样你可以在提交你的 PR 时保持和”上游”同步,会减少很多解决冲突的时间。(更多关于同步的说明,请参考这里.)
  • 创建一个分支 用于自己编辑。
  • 参考任何相关的issue 或者在你的 PR 中支持文档(比如. “Closes #37.”)
  • 包含之前和之后的快照 如果你的改动是包含了不同的 HTML/CSS。在你的 PR 中拖拉相应的图片。
  • 测试你的改动! 若测试用例存在的话,跑一遍,以覆盖你的更改,若没有的话,则创建相应的用例。无论测试是否存在,一定要确保你的改动不会破坏掉现有的项目。
  • 和项目现有的风格保持一致 尽你最大的努力,这也就是意味着在使用缩进、分号、以及注释很可能和你自己的风格大相径庭,但是为了节省维护者的精力,以及未来他人更好的理解和维护,还请你容忍一下。

如果这是你第一次提交 PR。可以浏览 提交 PR的文档,这是 @kentcdodds 专门为初次创建 PR 的人写的公开的资料。
当你提交了之后会发生什么
很不错,你做到了!恭贺你成为开源贡献者。我们希望这是一个良好的开端。
在你提交了贡献之后,下面几种情形中的某种是可能发生的:
😭 没有人响应你。
希望你确认在开始工作之前检查过了项目的活跃度。不过,即使在一个活跃的项目中,你的贡献也有可能得不到响应。
如果过去了一周,依旧没有人响应,请心平气和的在后面跟帖,询求他人帮助你审核。如果你熟悉某个人可以审核你的贡献,你可以使用@+名字,直接提醒他一下。


千万不要 私下里去联系他人;一定要记住,开源项目所有的沟通都应该是公开的。
如果你做了所有该做的事情,还是没有人理你,那就是真的没有人对你的贡献做出响应。这可能令人难受,但是千万不要灰心,每个人都会遇到这样的情况。你没有得到回复的原因有很多,包括你无法控制的个人情况。再接再厉,试着寻找另一个项目或方式来做出贡献。


🚧 有人要求你对自己的提交做出变更。
被要求修改你的提交是很常见的,无论是对你的想法的反馈,还是对你代码的改动。
当有人提出变更时,请及时响应。他们花时间审核了你的提交,要尊重他们。开启 PR 然后一走了之是一种恶习。如果你不知道如何修改,请花时间深入研究,并在需要时寻求他人帮助。
如果你没有时间继续处理这个 issue(举例来说,如果对话持续了几个月,而你情况有变),那么请告知维护者你无法再及时响应了。或许有其他人乐意接手你的工作


👎 你的贡献没有被接受。
你的贡献最终可能被接受,也可能不被接受。真心希望你没有为此花费太多力气。如果你不确定为什么它不被接受,请维护者提供反馈和说明是完全合理的。但最终,无论如何,你都要对他们的决定表示尊重。不要去无谓的争论或者显露敌意。如果你坚持自己,你仍可以 fork 项目,按照自己的思路来发展分支。


🎉 你的贡献被采纳。
太棒了!你已经成功地完成了一次开源贡献!
你做到了!
你刚刚完成了自己的开源贡献处女秀,接下来,你可能打算寻找另外的方法来做贡献,希望本文给你提供了灵感去实践。即使你的贡献没有被采纳,也请对帮助过你的维护者表示感谢!
开源就是由你这样的人所铸造:一个 issue、一个 PR、一则回复、一次击掌。就是这么简单!

我尽力处理排版了。😂😂😂

来源:https://opensource.guide/zh-hans/how-to-contribute/

分享主题:
其它
加载中…
精选评论
暂无数据

暂无数据