请选择语言

如何参与开源 | GitHub 开源指南系列之一

正文大纲
  1. Section 1 - 为何要为开源贡献力量?
    1. 巩固现有技能
    2. 遇见那些和你“臭味相投”的人
    3. 寻找导师,并且尝试帮助他人
    4. 在公众间建立你的声誉(职业口碑)
    5. 学习领导和管理的艺术
    6. 遇鼓励作出改变,哪怕改变是很微小的
  2. Section 2 - 贡献的具体含义是什么
    1. 如果你是一名开源界的新手,可能会对贡献的流程心生畏惧。比如:该如何找到正确的项目?不懂编码又想参与怎么办?万一做错事情了怎么办?
    2. 你不具备编码的能力
    3. 是否热衷于规划事件?
    4. 是否偏向于设计?
    5. 你是否热衷于写作?
    6. 你喜欢组织活动吗?
    7. 享受编码的乐趣?
    8. 热衷于帮助他人?
    9. 在编码方面是否喜欢帮助他人?
    10. 其实不必一定是软件项目!
  3. Section 3 - 根据项目定位自我
    1. 分析感兴趣的开源项目
  4. Section 4 - 寻找打算做贡献的项目
    1. 提交贡献之前应做的检查列表
      1. 符合开源的定义
      2. 项目被接收的提交活跃度
      3. 项目的受欢迎程度
  5. Section 5 - 如何提交成果
    1. 有效沟通
    2. 收集上下文
    3. 创建 issue
    4. 创建 pull request
  6. Section 6 - 在提交完之后需要善后事宜
    1. 😭 没有人响应你。
    2. 🚧 其他人的要求你对自己的提交做出变更。
    3. 👎 你的贡献没有获得通过。
    4. 🎉 你的贡献被接收。
  7. Section 7 - 你已经做到了!

Section 1 - 为何要为开源贡献力量?

在【自由代码】下工作,让我学习到了职业生涯中非常重要的技能,无论是大学还是实际的工作,我认为从开源项目中得到的收获的远大於我的贡献!

—— @Errietta,《我为何是如此的热衷于为开源软件贡献力量?

为开源贡献力量,得到的回报就是能够学习到很多、受教很多、且能够锻炼任何你能够想到的经验。

为什么会有人为开源做贡献?这可能是很多人都不明白的地方,这里不妨列出一些!

巩固现有技能

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

遇见那些和你“臭味相投”的人

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

寻找导师,并且尝试帮助他人

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

在公众间建立你的声誉(职业口碑)

根据开源的定义,你在开源下所有的工作都是公开的,这也就意味着开源项目是一个很好展示你实力的地方。

学习领导和管理的艺术

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

遇鼓励作出改变,哪怕改变是很微小的

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

Section 2 - 贡献的具体含义是什么

如果你是一名开源界的新手,可能会对贡献的流程心生畏惧。比如:该如何找到正确的项目?不懂编码又想参与怎么办?万一做错事情了怎么办?

其实没有关系的啦!条条大路通罗马,开源项目有太多的路径可以参与!以下是一些实用的技巧,帮助你快速的获得经验。

你不具备编码的能力

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

我被大家所熟知是因为为 CocoaPods 做了一些事, 其实大伙并不知道我实际并没有为 CocoaPods 本身做了什么,我大多数的工作是诸如撰写文档、品牌宣传之类的。

—— @Orta,《默认迁移到开源软件

即使你是一位开发者,非代码的贡献对于项目来说也是举足轻重的,尤其是对于社区的其他成员来说。用心维系这些关系能够让你有工作到项目其它部分的机会。

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

—— @Brettcannon,《维护者的故事

是否热衷于规划事件?

  • 为项目组织研讨会或线下分享,一如 fzamperin 为 NodeSchool 所做的那样
  • 为项目组织大型会议(假如它有的话)
  • 帮助社区成员寻找合适的技术会议,且帮助有实力的成员提交演讲的拟稿

是否偏向于设计?

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

你是否热衷于写作?

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

说真心话,【文档】是非常重要的. 目前 Babel 的文档已经很棒了,这也是其杀手锏的特性之一。当然,还有一些章节需要大家的完善,即使是随便在哪儿增加一个段落都很感激。

—— @kittens,《贡献者召集令

你喜欢组织活动吗?

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

享受编码的乐趣?

  • 找到一个开放的问题并解决它,就像 @dianjin 为 Leaflet 做的
  • 想一想你是否可以帮忙写一个新的功能
  • 自动化项目设置
  • 改进工具和测试

热衷于帮助他人?

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

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

其实不必一定是软件项目!

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

举例来说:

@sindresorhus 创建了 “惊奇” 列表

@h5bp 维护了针对前端开发者的面试题

@stuartlynn@nicole-a-tesla 制作了收集关于海雀的有趣的事实

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

Section 3 - 根据项目定位自我

如果你跟着了一条 issue,还发现了令人感到困惑的事情,这很正常,不是你一个人这样。这些工具需要大量的隐式的知识,但是总会有人带着你熟悉这些,当然你要找他们问对的问题。

—— @shaunagm,《如何为开源做贡献

为开源做贡献,除了单词拼写错误之外,大多数时候就像是走在陌生人中间,浑身上下不适。这就像人们已经在西边讨论的非常深入了,你突然开始讲东,肯定会让人感到不舒服。

与其盲目的在项目中游荡,不如静下心来学习规则。这样反而会让你的想法被注意到,也会有人听到你的声音。

分析感兴趣的开源项目

每一个开源社区都是不一样的。

在某一个开源项目扎根多年,这意味着你只是对这一个开源项目无比的熟悉。若是切换到不同的项目,可能会发现完全是另外一回事,所谓的使用词汇、习惯用语、沟通方式都发生了变化。

然而,很多的开源项目还是遵循类似的组织结构的。理解不同的社区角色和全部的流程,可以很好的帮助你快速的切入新的项目。

一个典型的开源项目均会有如下类型的人:

  • 作者: 项目的创始人或创始组织

  • 归属者: 代码仓库或组织的管理员(不一定和作者是同一个人)

  • 维护者: 贡献者,负责项目的未来走向和组织的管理(他们通常也是项目的作者或归属者。)

  • 贡献者: 只要是为项目做出了贡献,就算。

  • 社区成员: 那些实用项目的人们。他们或许是积极的讨论者,又或者是为项目的方向提出意见的人。

一个较大的项目,可能下面还会细分子社区,或者是针对不同的任务分成不同的小组,比如工具小组、分流、社区事务、以及活动组织等。径直到项目到 web 站点,找到“团队”页面,或者是查看治理文档,从而获得类似到信息。

靠谱的开源项目,一般都会有一个文档的,这些文档文件通常会在代码仓库的顶级目录列出。

  • 许可协议: 根据开源软件的定义,每一个开源项目必须是有开源许可协议的. 可以这么认为:假如说某个项目源码开放,但是没有任何的许可协议,那么它就不能叫做开源。

  • README: README 是一个介绍性的说明文件,对初次光临社区对人们表示欢迎,它通常会解释项目有何用处,为何发起,以及如何快速入门等。

  • 贡献: READMEs 帮助人们来认识项目,贡献这个文件则是帮助对项目如何做贡献。它解释了目前项目需要什么样类型对贡献者,社区对流程是啥样的。并非所有的项目都会有这个文件,它某种程度上也是展示项目对于贡献者的友好程度。

  • 行为准则: 顾名思义,即是一些参与社区时的一些礼仪、说话方式、行为等,帮助形成一种友好的氛围,不是所有的项目都会撰写行为准则文件,它某种程度上也是展示项目对于贡献者的友好程度。

  • 其它文档: 有些项目也许还有其它文档,例如教程、导游,或者是治理规则,这在大型项目中常见。

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

  • 问题追踪: 这里是人们讨论项目相关问题的地方。

  • Pull requests: 审核代码、以及相关的问题讨论。

  • 论坛或邮件列表: 一些项目会实用会话式的主题(例如 “How do I…““What do you think about…“ 来替代 Bug 报告或特性请求)。然而有一些项目关于讨论全部实用问题追踪。

  • 即时在线聊天: 有一些项目会实用聊天频道(诸如 Slack 或 IRC),从而能够随意的谈话、协作和快速交流。

Section 4 - 寻找打算做贡献的项目

你读到这里,说明已经对于一个开源项目如何运作的有了清晰的认识,是该找一个合适的项目做贡献的时候了!

假如你之前从来都没有为开源做过贡献的话,那么请记住来自美国总统约翰·F·肯尼迪的这段话:不要问你的国家能为你做什么,要问你能为国家做什么。

开源项目的方方面面都需要贡献者,你先不要通盘考虑该往哪里贡献,或者是它将如何看。

相反,从你已经使用到的或者打算用到项目开启贡献之路,在你积极的贡献过程中,项目也会反馈给你,让你更好的定位自己。

一旦进入某项目,不论何时,你都要听从自己的直觉,做你认为更好或者不同的事情。

开源并不是高级俱乐部;它就是由你这样的人所浇铸和打造。“开源”只是针对这个世界的需要修复的问题的一个梦幻术语罢了。

你或许在查看 README 的时候,发现了损坏的链接,又或者拼写错误。又或者是你是一名新手,使用的过程中发现了问题,又或者是某问题应该在文档中注明。请不要坐视不理,径直绕开,或者是请求他人修复,伸出你的援助之手,解决这些你能看到的问题。而这正是开源的精髓之所在!

28% 的随意贡献 就是说明了文档的开源,诸如拼写错误,段落语句调整、或者是翻译。

你也可以利用如下列出的资源来找到合适的新项目:

提交贡献之前应做的检查列表

当你找到了你打算贡献的项目时,在进一步行动之前,作一个快速的扫描工作,以确保项目是否接受贡献的。否则,你煞费苦心的工作可能没有任何的回报。

这是一个简易的检查表,用来评估一个项目是否适合新的贡献者。

符合开源的定义

  • 有许可协议吗?通常情况下,会在根目录有一个叫做 LICENSE 的文件。

项目被接收的提交活跃度

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

  • 最后一次提交是在什么时候?
  • 项目目前有多少贡献者?
  • 人们提交的频繁吗? (在 GitHub,可以在顶栏里点击“commits”来展现。)

接下来,就是看项目的 issue 数量。

  • 目前有多少个还处于开放状态的 issue?
  • 项目的维护者对于处于开放状态的 issue 响应是否迅速?
  • 是否有讨论很活跃的 issue?
  • issue 均是近期产生的吗?
  • 有没有关闭的 issue? (在 GitHub, 点击“closed”标签就可以看到所有已经关闭的 issue。)

同样再来看看 PR 的情形。

  • 现下有多少处于开放状态的 PR?
  • 当提交了 PR 后,维护者响应是否迅速?
  • 是否有活跃讨论的 PR ?
  • 均是近期的 RP 吗?
  • 最近有多少 PR 合并? (在 GitHub , 点击 PR 页面的“closed”的标签页来查看已经关闭的标签页。)

项目的受欢迎程度

一个项目的友好程度和受欢迎意味着更能吸引新的贡献者。

  • 在 issue 的问题中,维护者的回答是否非常有帮助?issue 的讨论中、在线聊天室、论坛是否很友好?
  • PR 是否被 review?
  • 维护者是否对做贡献的人们道声”谢谢”?

当你看到一个很长当对话时,来自核心开发者的零星的响应排在列表的后面。你就得考虑,他们在作建设性的总结?是否保持风度的情况下做出最后的决定?如果你看到的是更多的口水仗,而且还在继续,这通常意味着社区的能量重心已经不在开发上了。

—— @kfogel,《开源软件生产力

Section 5 - 如何提交成果

你已经找到了你喜爱的项目,也已准备好贡献了,迫不及待、跃跃欲试了。好吧!以下就是带领你如何以正确的姿势作贡献。

有效沟通

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

作为一名新手,我很快的就意识到,我若是要关闭一条 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”,所有的对话都会通知到你),要让社区的成员们知道你要做的工作,免得你做了之后,再让他们知道,他们不同意,就浪费了。

你能够从单个的项目学习到很多,只要你踊跃的去使用,在 GitHub 上密切观察项目,并阅读每一个 issue 和 PR。

—— @gaearon,《参与项目

创建 issue

你应该在遇到下列情况下,去创建一个 issue:

  • 报告你自己无法解决的错误

  • 讨论一个高级主题或想法(例如. 社区、远景、政策等)

  • 期望实现某新的特性,或者其它项目的想法

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

  • 如果你刚好看到一个开放的 issue,恰是你打算解决的,添加评论,告诉他人你将负责这个。这样的话,可以避免他人重复劳动。

  • 如果说某个 issue 已经开放很久了,这可能是已经有人正在解决中,又或者是早已经解决过了,所以也请添加评论,在打算开启工作之前,最好是确认一下。

  • 如果你创建了一 issue,但是没多久自己解决了,也要添加评论,让其他人知道,然后关闭该 issue。记录本身就是为社区的贡献。

创建 pull request

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

  • 提交补丁 (例如,纠正拼写错误、损坏的链接、或者是其它较明显的错误)

  • 开始一项别人请求的任务,或者是过去在 issue 中早就讨论过的

一个 PR 并不代表着工作已经完成。它通常是尽早的开启一个 PR,是为了其他人可以观看或者给作者反馈意见。只需要在子标题标记为“WIP”(正在进行中)。作者可以在后面添加很多评论。

如果说项目是托管在 GitHub 上的,以下是我们总结出的提交 PR 的建议:

  • Fork 代码仓库 并克隆到本地,在本地的仓库配置“上游”为远端仓库。这样你可以在提交你的 PR 时保持和“上游”同步,会减少很多解决冲突的时间。(更多关于同步的说明,请参考这里

  • 创建一个分支 用于自己编辑。

  • 参考任何相关的 issue 或者在你的 RP 中支持文档(比如 Closes #37)

  • 包含之前和之后的快照 如果你的改动是包含了不同的 HTML/CSS。在你的 PR 中拖拉相应的图片。

  • 测试你的改动! 若测试用例存在的话,跑一遍,以覆盖你的更改,若没有的话,则创建相应的用例。无论测试是否存在,一定要确保你的改动不会破坏掉现有的项目。

  • 和项目现有的风格保持一致 尽你最大的努力,这也就是意味着在使用缩进、分号、以及注释很可能和你自己的风格大相径庭,但是为了节省维护者的精力,以及未来他人更好的理解和维护,还请你容忍一下。

如果这是你第一次提交 PR。可以浏览 PR 制造 的文档,这是 @kentcdodds 专门为初次创建 PR 的人写的公开的资料。

Section 6 - 在提交完之后需要善后事宜

很不错,你做到了!恭贺你成为开源贡献者。我们希望这是一个良好的开端。

在你提交了贡献之后,下面几种情形中的某种是可能发生的:

😭 没有人响应你。

希望你确认在开始工作之前检查过了项目的活跃度,不过即使检查过了,也不保证一个活跃的项目,没有人理会你的贡献也是很正常的。

如果过去了一周,依旧没有人响应,请心平气和的在后面跟帖,询求他人帮助你审核下。如果你熟悉某个人可以审核你的贡献,你可以使用@+名字,直接提醒他一下。

千万不要 私下里去联系他人;一定要记住,开源项目所有的沟通都应该是公开的。

如果你做了所有该做的事情,还是没有人理你,那就是真的没有人对你的贡献做出响应。这可能感觉上不太好受,但是千万不要灰心。每个人都会遇到这样的情况。其实有太多种原因没有人响应你的提交了,包括很多个人情形都是不在你控制范围的。再接再厉,换一种方法去提交,或者换一个项目。这年头,很多社区成员都在积极的参与和响应他人,都在抢夺优秀的人才,若没有人搭理你,你换地方是没有任何不对的地方的。

🚧 其他人的要求你对自己的提交做出变更。

对于自己的提交作出变更这件事非常的普遍,可能是你获得了反馈,也可能是变更了代码。

当有人提出变更时,请表现出大度的地方,要及时响应。他们花时间审核了你的提交,要尊重他们。开启了 PR,然后一走了之,是一种恶习。如果你不知道如何修改,请花时间深入研究问题的所在,如果还是没有想到好的办法,那么是该向他人求助的时候了。

如果你因为没有时间而无法继续在此 issue 继续工作(举例来说,如果对话已经过去了一个月了,没有任何的回复和进度,环境肯定变得不一样了),那么请向维护者告知你无法在及时的响应了,肯定有人非常乐意接替你的工作的。

👎 你的贡献没有获得通过。

你的提交最后可能没有被接受。真心希望你没有在此作出过多的努力。如果你不确定为什么没有被接收的话,这正是一个很好的询问维护者反馈和澄清的机会。最终,无论如何,你都要对他们的决定表示尊重。不要去做过多无谓的争论或者是充满敌意的谩骂。如果你坚持自己,你可以随意的 fork 项目,按照自己的思路发展出分支来。

🎉 你的贡献被接收。

太棒了!你已经成功的做到了,为开源做贡献也不过如此!

Section 7 - 你已经做到了!

你刚刚完成了自己的开源贡献处女秀,接下来,你可能打算寻找另外的方法来做贡献,希望本文给你提供了灵感和实践。即使是你的贡献没有被采纳或接收,也不要有失风度,请对帮助过你的维护者表示感谢!

开源就是由你这样的人所铸造:开启一个 issue,在提交 PR,评论、讨论、收集反馈,直到被接收。就是这么简单。