希望各位参与过知名开源项目的朋友们给出一些自身的经验和体会。
回复内容:
最近几个月开始参与 mruby,不算知名项目,不过后来越想越觉得这个项目适合我这种菜鸟:
- 开发比较活跃,matz 在晚上基本上都会看
- matz 脾气特别好,回复也挺快的
- 代码规模较小,相对容易上手
- 还没有正式发布,所以不很稳定,bug 比较多
- 前景目测还不错
在参与之前只是简单过了一下它的垃圾收集部分,凑巧看到一处重复代码就删掉提了个 pr,很快就被merge了。胆大之后一边看代码一边发 pr 给垃圾收集部分加注释。慢慢对代码比较熟悉了一些,开始在 github 上 Watch 它,如果有人报了 bug 会收到邮件,报的 bug 基本上 100% 可复现,所以比较容易定位修复。但动作要快,不然让 matz 看见就被秒修了。修复之后尽量加上 regression test。
目前的遗憾是还没提交过 feature,但有几个小 idea酝酿中。
使用该软件
阅读源代码和文档
跟踪邮件列表
解答新手问题
提交BUG报告和重现BUG代码
提交Patch和测试代码,反复修改Patch
讨论新功能需求和设计
1. find interesting project
2. fix issues of this project
3. fork and pull request
4. congratulations !
转载。源地址: 一步一步教你怎样给Apache Spark贡献代码本文将教大家怎样用10个步骤完成给Apache Spark贡献代码这个任务
- 到 Apache Spark 的github 页面内点击 fork 按钮
- 你的github帐户中会出现 spark 这个项目
- 本地电脑上, 使用
<code class="language-bash">git clone <span class="o">[</span>你的 spark repository 的 github 地址<span class="o">]</span>
例如:
git clone git@github.com:gchen/spark.git
</code>
首先说说参与开源的好处,
- * 开阔眼界. 就像学画画要多看名家名作一样. 如果想提高自己的技术水平, 那眼光就不能只局限在在自己工作中开发维护的那一块代码. 高手的代码到处都有, 但活跃的开源项目无疑是一个非常好的途径. 纸上得来终觉浅, 如果能参与进去, 修复bug, 贡献代码, 那学习的效率比光看又高了一个量级. 从参与这个角度讲, 随书源码之类的无法和开源的代码比. 除了代码, 可以学到东西还有很多, 比如 设计模式, 开发流程, etc.
- * 职业加分. 开源项目可以和工作相关, 也可以和工作无关. 比如像想换方向, 但是又不想以新人的身份去求职, 那么先在开源项目上积累经验无疑是一个可行的办法. 如果和工作相关, 那么开源代码谁都能看到, 在求职的时候也更容易被人考察,认可. 想象一下简历里面这么一句会不会比较拽: "详细实现请fork: http://github.com/nnnbbb/"
- * 认识牛人的机会. 一个好的老师是无价的, 有时候一句话, 一个推荐也许就改变了你的职业生涯. 能和各种牛人战斗在一个战壕里, 这种机会不是随便一个公司能提供的.
- * 学英语. 鉴于大部分的开源项目还是用英语沟通, 所以也是一个见识地道程序员英语的好办法. 告别那些绞尽脑汁而又蹩脚的变量名和函数名吧.
- * 好吧, 我承认上面提到的都太功利了. 其实, 分享的乐趣, 代码被广泛使用的成就感, 也是很迷人的.
根据上面列表, 分析你的需求, 好好想想什么样的项目适合自己. 然后就是如何参与进去了, 要融洽的加入一个开源社区, 有一些要注意的地方:
- * 首先, 尊重他人的时间. 牛人都很忙, 不要用低级的问题, 低级的错误去麻烦他们. 先把文档都好好看了, 有什么看不懂的先搜索一下, 其他的关于提问的注意事项, 参见很多技术论坛都有置顶的 "提问的艺术"
- * 如果你不是很牛, 那么可以从使用, 测试开始做起. 再牛的开源项目也不会拒绝别人的bug report, 当然请注意提bug的方式, 通常, 版本, 环境, 重现步骤是不可少的. 还有一些其他的打杂的任务也是入门和混脸熟的好办法, 包括但不限文档翻译, 代码整理...
- * 然后就可以开始改改小bug了. 通常小步快走比一口吃成一个大胖子要靠谱. 等你熟悉项目了, 自然会发现自己的patch越来越大, 越来越重要.
- * 提交patch,或是 request pull之前先自己好好把代码整理, 测试了, 新手犯错是允许的, 但是老犯错就有问题了.
- * 代码风格和项目已有代码保持一致. 这个就像铁轨宽度一样, 没有对错, 1.4米宽的比1.3的好? 不一定, 但大家都1.4, 那就请你也1.4吧. 等你自己开个项目的时候, 你就可以爱怎么定就怎么定.
来自 github:shop
阅读代码,参与讨论,提交补丁,报告 bug,帮助重现 bug,修复 bug,帮助测试,帮助 Code Review,迭代你的补丁,报告基础测试数据,帮助回答其他人的问题,帮助补充文档。从修复一个拼写错误,增加一个测试用例,到提交一个功能,你可以做的很多。具体还要根据自己的兴趣和项目的需要了。
gh上很多开发者都很nice,自己主动一点,可以不从难点入手,先从一些小地方开始。
如果说“加入”一个项目,使用它也是一种加入。
如果说加入的意思是加入“开发者团队”,每个开源社区的文化和风格各不相同,最行之有效的方法是主动联系他们。
2008年,我开始使用FreeSWITCH(
http://www.freeswitch.org),加入邮件列表
http://lists.freeswitch.org,潜水
后来,我在
http://wiki.freeswitch.org上创建了一个账号,更新文档
后来,在
http://jira.freeswitch.org上创建了一个账号,汇报Bug
后来,申请了一个贡献者SVN上的权限(freeswitch-contrib目录,现已不用),在里面提交自己的一些脚本等
后来,项目库转到了Git,又申请了Git提交权限,可以更新核心代码。但一般更新前会跟相关模块或核心代码的原作者通过邮件或IM交流。如果是明显的错误(如笔误或编译错误等)或是自己负责的部分,就可以直接提交了。