开源软件 贡献意味着什么?
如果你是一名开源界的新手,可能会对贡献的流程心生畏惧。
比如:
该如何找到正确的项目?
不懂编码又想参与怎么办?
万一做错事情了怎么办?
其实没有关系的啦!条条大路通罗马,开源项目有太多的路径可以参与!以下是一些实用的技巧,帮助你快速的获得经验。
你不具备编码的能力
对于为开源做贡献常见的误解就是:为开源做贡献必须得提交代码。事实上,代码固然重要,但是项目中不需编码的重要部分经常被忽视 。你若做了这部分,对于项目来说可是莫大的贡献,而这根本就不需要什么撰写代码!
我被大家所熟知是因为为 CocoaPods 做了一些事, 其实大伙并不知道我实际并没有为 CocoaPods 本身做了什么,我大多数的工作是诸如撰写文档、品牌宣传之类的。
— @orta , “默认迁移到开源软件”
即使你是一位开发者,非代码的贡献对于项目来说也是举足轻重的,尤其是对于社区的其他成员来说。用心维系这些关系能够让你有工作到项目其它部分的机会。
我第一次接触 Python 开发团队(简称 python-dev)是在 2002年6月17日,当时我是向其邮件列表发送了一份邮件,是关于请求通过我的补丁的。我很快就又发现了开源的 bug,于是决定开始为小组收集邮件摘要,然后他们给了我一个澄清问题的理由,但是更加重要的是,我能够捕获到某人指出需要修复的问题。
— @brettcannon , “维护者的故事”
是否热衷于规划事件?
- 为项目组织研讨会或线下分享,一如 @fzamperin 为 NodeSchool 所做的那样
- 为项目组织大型会议(假如它有的话)
- 帮助社区成员寻找合适的技术会议,且帮助有实力的成员提交演讲的拟稿
是否偏向于设计?
- 重新布置布局以提高项目的可用性
- 进行用户研究以重新组织和完善项目的导航或菜单
- 整理一个风格指南,以帮助项目有一致的视觉设计
- 创建t恤的艺术或一个新的标志,就像 hapi.js 的贡献者那样
你是否热衷于写作?
- 撰写和改进项目的文档
- 能够以实例来展示项目该如何使用的
- 为项目撰写新闻稿,或者到邮件列表高调布道
- 为项目撰写教程,一如 pypa 的贡献者所做的
- 翻译项目的文档为本土语言
说真心话, [文档] 是非常重要的. 目前 Babel 的文档已经很棒了,这也是其杀手锏的特性之一。当然,还有一些章节需要大家的完善,即使是随便在哪儿增加一个段落都很感激。
— @kittens , “贡献者召集令”
你喜欢组织活动吗?
- 链接重复的问题,并建议新的问题标签,使事物井井有条
- 通过开放的问题,并建议关闭旧的,就像 @nzakas 为 eslint 做的
- 把最近开放的问题阐述清晰,以推动讨论
享受编码的乐趣?
- 找到一个开放的问题并解决它,就像 @dianjin 为 Leaflet 做的
- 想一想你是否可以帮忙写一个新的功能
- 自动化项目设置
- 改进工具和测试
热衷于帮助他人?
- 回答关于项目的问题,例如在 Stack Overflow(像 Postgres 的这个示例 )或者 reddit 上
- 为人们解答公开的问题
- 帮助缓和讨论板或对话渠道
在编码方面是否喜欢帮助他人?
- 为他人的提交审核代码
- 为如何利用项目撰写教程
- 为其他贡献者做导师,正如 @ereichert 为 @bronzdoc 所做的那样,哦,是 Rust 项目
其实不必一定是软件项目!
尽管人们一提起”开源”二字,默认就是指开源软件,其实不尽然,开源可以是任何事情的修饰,而不仅仅是指软件。比如图书、食谱、列表、以及任何可以开源的项目类别。
举例来说:
- @sindresorhus 创建了 “令人惊叹的” 列表
- @h5bp 维护了针对前端开发者的面试题
- @stuartlynn 和 @nicole-a-tesla 制作了收集关于海雀的有趣的事实
尽管你是一名软件开发者,也可以去撰写一些文档去帮助新的入门者。其实项目中那些看起来令人生畏的项目并不是写代码,做开发者总得挑战自己,其实在做得过程中可以增强信心和获得全新的体验。