很开心看到原PO分享GitHub open source的心得 私以为台湾软体在有资源的不懂软体，懂软体的没资源情况下， 靠open source似乎是唯一的出路，所谓 "自己的软体业自己救" ! 小弟也在这分享自己的open source小小心得， 虽然自己没有repo，但有靠发PR(Pull Request)成为collaborator的经验 :) 先附上在PyConTW 2015 lightning talk的slide: http://goo.gl/fTUPGC 小弟比较有贡献的repo是 (工商一下...XD) * https://github.com/djacobs/PyAPNs * https://github.com/mher/tornado-celery < 重点心得 > PR能不能被merge的关键似乎不在於coding多厉害，解决多复杂的问题， 而是 "PR解决的问题大家觉得重不重要" < 基本 > 必须了解repo解决了甚麽问题，用了甚麽方法，coding structure/convention， patch加在哪边最适合，会不会影响到原本structure，有没side effect等 < 让别人好review/merge > code diff保持很乾净，尽量做到让reviewer好auto-merge, 技巧如 1. push上remote前先git squash整理一下 2. 开PR专用branch，里面只放PR的change 3. 如自己的fork要发PR但是upstream已经变很多 => 先fork最新upstream成新branch再cherry-pick要PR的部分 4. 如PR发很久还没被merge, upstream又变动到conflict的话, 自己先merge from upstream < 提升PR的重要性 > 如果owner迟迟不merge的话，有几种可能， 1. 他懒 2. 他觉得不重要 3. 他觉得PR不够好 要验证是何者的话，就用对PR做点PR(Public Relations)试试看吧...XD * 我会先发一个issue，蒐集遇到类似问题的人，强化重要性。 下面我会贴我的fork/PR请遇到问题的人回去试试看，通常试成功的人会回文 就变成很好的"见证"...XD * 另外，我也会在相关issue，stackoverflow相关问题上贴我的fork/PR， 累积到一定的量，其他user会反过来push owner来merge PR e.g. https://github.com/djacobs/PyAPNs/pull/78 * 积极回应网友issue与对你发的PR的challenge * 经我实验本来PR 2个月没人理，用上述方法後没多久就被merge惹 < 成就 > * 在贡献过程中看到自己的code有帮助到人，如user会在GitHub上或是mail表示 这个code work! 或是表达感谢，自己也会觉得鸠甘心，进而化为继续贡献的动力 * 有些conference可以用contributor的名义申请票就不用跟别人抢...XD < 後记 > 有时候该专案已经跟目前工作/side project距离太远时，会觉得懒得去maintain/ 回应user问题，这时候就是该放手让对此专案更有热情的人接手了。 这也是原PO说的open source精神之一~ ※ 引述《huei90 (huei90)》之铭言： : 本鲁在 Soft_Job 版吸收了各位大大的精华，久而久之也变成了一个 Coding 乡民，我相信每个乡民都有自己的专业，卖鸡排也是个专业，而我很荣幸成为一位程式开发者！ : 这篇拖了一年了，我想是时候把两年多在 Github 上开发 Open Source Project 的经验分享给各位，虽然不及神级的开发者，但我始终相信，分享、自由、开放、讨论和开发者是 Open Source 的精神。 : 如果你不懂什麽是 Github，但你多少也应该听过 Bitbucket, CodePlex, Google Code, GitCafe 等等。如果都没听过，那就左转出去吧～ : 文长，对着电脑的各位，夜深了，进入正题前，记得泡好咖啡！ : [接触 Github] : N 年前听教授介绍 Open Source 有多威，国外是怎麽玩 Open Source 的，就从那一刻开始，接触了 Github（Github Private Repo 要付费，Bitbucket 免费喔）。用过 Github 应该可以感受到，大众还是趋向 Github，而不是 Google Code。UI/UX、效率、社群都是 Github 优势的关键。 : 开始玩一玩就立马上手，根本就是快快乐乐学 Git/Github，透过 Github 才慢慢了解 Git。一开始使用 Github 提供的 Github Desktop 来 commit push，但後来好像 bug 很多并开始接触 command line，就一直用到现在，现在已经回不去 GUI 了。 : 有付费买 Github Private Repo 的人和公司也不少，但费用也不便宜。还记得之前在公司直接用 Github Importer 把整个公司专案复制一份到 Github 上，不费吹灰之力就完成了，如果你的专案是 svn，转过去 git 也是没有问题的喔！ : [前辈] : 两年前自己很菜（现在还是很菜），前辈开始教我多看看别人的专案、学习模仿等等的，到现在我还是很感激这位前辈，没有他推我一把，我可能就没继续 Open Source 下去了。看了几个星期後，前辈让我开一个专案，刚好公司专案是使用 angularjs 当前端架构开发，那就写一个前端验证工具吧。定义需求、规则、功能，再来定义最重要的 SPEC，接着开始 Coding 主要模组，其中当然少不了被前辈念说这怎麽这样写等等之类的。 : 我还记得很清楚，前辈说：那开始写测试吧，写测试的时间是写模组的两倍喔（吓！笑）。问题是，我怎麽知道该如何写测试，而且是用该死的 angularjs，哪懂什麽 protractor，又一堆什麽 BDD/TDD, JUnit, QUnit, Jasmine, Mocha, blablabla。就直接模仿了前辈的程式，也终於把完整的测试给写出来了。从开始写到结束大概花了三个月的时间，前辈也已经离职了。大致初步功能也完成了，DEMO 页面也写好了，就立马开源，这里简称 A-V！（原谅我一下 Open Source 一下开源） : [N4J] : 其实在 A-V 出来之前，我只会 jQuery，正在学习 jQuery 写第三方套件的时候开发了 N4J 的前端工具，N4J 是纯粹学习用的，学习如何使用 Github、结构的 Coding 以及书写 Document。还记得自己写得很开心，多年回去看还记得那时候的兴奋，後来毕业後也用 N4J 拿到了 Offer，无缝接轨毕业没有失业即马上就业。 : [A-V] : 先说说 A-V 目前的状况，有 2xx commits、1x releases、2x contributors，比起大型专案这个数字没什麽，但对我来说，这些数字都是一个肯定，一个成就，我想这是 Open Source 带给我的好处之一，也是让我持续投入时间的原因。 : 完成第一个版本後就马上上线了，写过程式的人都知道，这时候就会出现上线臭虫，版本 1.0.5, 1.0.6, 1.1.0 後，才开始慢慢稳定下来。 : 很快的，我试着在各论坛发表自己的作品，也包括台湾的前端社群，分享自己这几个月下来的成果，但很可惜没人理我，也许是作品没有爆炸性，毕竟只是个前端验证工具。其实不免有点小小的失望，没有人讨论，没有任何回馈。但有一点值得注意的是，angularjs 在这方面还没有太多相关的套件和讨论，所以我算是进入了对的时间点。 : 几个月下来，我持续开发、增加功能、把程式写得更好，来了第一个 issue，後来也陆续来了几个，应该是我之前在某个论坛发文，有人看到进来给我意见。当然我就立即回覆谢谢他们的提议，马上修改或者问说有什麽建议等等之类的。因为有人看到，star 了过後就会更多人看到，甚至有人开始丢 PR 给我，在这里我学到，有人丢 PR 给你，你一定要接受，除非他的程式充满问题，但也不能马上拒绝，要提出自己的理由决定是否要对方修改还是继续讨论下去。其实我在别人的 Open Source 也是这样，丢了一个 : PR，几天内没有人回覆会觉得很伤心，但一旦被接受或者回覆，心理会很开心，太棒了，被接受了！这是一种被肯定，支持的动作。所以只要有人丢 PR 我大部分都会接受。 : 接下来的几个月，更多的 issue 更多的 PR，一个人无法承担所有的问题，所以很多我回覆後就没有继续了，一旦有时间可能是一个月後，才有时间回来看到底发生什麽问题，就这样慢慢把 bug 修复。还记得有一次，有个 issue 几个月下来都解不了，某天晚上到了咖啡厅坐下，瞬间就解掉了，这一定要上一个新 tag 说 “fix feature or major improvement”，其实这是开发 Open Source 的小确幸，只有你知道发生了什麽事，即使你公告了你修复这个功能，会理你的人没有多少。 : 中间当然有停下的时候，完全没有任何声音自己也没动力继续开发解 bug，但突然有人丢了一个 bug 或者 PR 过後，又会瞬间热血起来，不修掉不行的那种感觉，修掉後会很开心，然後又会安静一阵子。大概就是这样来来回回的状况。 : 当然如果你的专案是那种爆炸性的，比如说 pageres、express、awesome，不会是以上的故事 : 前几个月，因为自觉专案掉入了谷底，很久没有更新也没有人问说进度，开了一个 issue “Looking for Collaborators”，自以为会有人自告奋勇的说：“我来”，结果一个都没有。在这里我学习到的是，Open Source 这东西，就是要让他慢慢的酝酿，果然某一天有人丢了个 PR 几乎大改了我整个专案的架构，改着改着他的兴趣就来了，我就问他说要不要当 Collaborator，他也就马上说好。後来我们也开了个 Slack 群组，讨论着 A-V 的开发。也许有人觉得这没什麽，但是这种与网友一起奋斗，讨论着彼此的专业，这份经历是工作永远无法取代的。 : 以上故事就是不停的 loop，持续了两年，直到现在不是一个人在开发修 bug，而是有 collaborators 一起讨论，彼此给意见，这就是 Open Source 的魅力所在。 : A-V 过後，陆陆续续展开对 Open Source 的兴趣，看了很多 license 的选择（还是觉得迷迷糊糊的），期间也开了不少的专案，像是 I-G、G-E、S.S.S、J-S-D 等等的，虽然没有像 A-V 那麽精彩，但难免还是有 issue 有 PR（真的很珍贵）。 : [A-J] : A-J 专案虽然不是我开始的，是我主动寄信给作者要求成为 Collaborator 。A-J 属於爆炸性的专案，现在已经有四位数的星星，通常这类型的专案 issue 和 pr 会多到你接手软会想吐，大概会忽略他一阵子，然後一段时间後再来慢慢处理。但是既然是自己主动要求帮忙的，就有责任继续维护它，Open Source 要学习的其中一点就是－主动，包括提出问题、意见、结果、拒绝，你的任何一个动作都在帮助一个 Open Source 专案的进步，这里就真的是责任制了。每个专案都有自己的步调，你也可以不要主动，让 owner 自行决定专案方向。 : [Gitter] : 其实我觉得 Github 提供的 Issue 已经很好用了，整个专案的讨论都能在 Issue Comment 完成，有必要还能互相 reference，甚至下 label 来整理 Issue 分类。但有时候不是所有人都喜欢在 Issue 问问题，也有可能担心问到重复的问题。 : 如果你的专案很大，你可以建议大家到 stackoverflow/irc 寻找问题，但对於比较小的专案，可以使用 Gitter。Gitter 是一个聊天室，会自动整合 Github 专案，任何的动向都会纪录在 Gitter 内，让所有人进入一个独立的空间讨论问题。多一个管道让大家凝聚，其实多少也能帮助到你，因为一个聊天室里面，大家都能发言，你不回答其他人会帮你回答的。 : [已死?] : 常常逛 Github，你会发现有很多有趣的专案，但看到最新的更新时间，什麽！是一年前。这时候就会开始脑补，是不是专案已经没有在开发了，作者似乎也消失了，有好多 issue 好多 PR 都没有被接受。自己也尝试丢了 issue 询问专案开发进度，当然也没得到任何回应。偶尔还是会觉得很可惜，这麽棒的一个专案是不是被抛弃了。 : 但是不要气馁，就因为这是 Open Source，这是一个开放的社群，任何人都有权利查看修改更新（有的 License 是不允许的），先查查看 fork 分支，有时候分支的星星数还会比原本的专案多，再看看 issue 里面有没有人在讨论替代方案。最後一招就是自己 fork 自己改，当然你也可以开一个全新的专案来做一样的事情。 : [END] : 以上是我在 Github 上学习 Open Source 的经验分享。对我来说，逛 Github 和 Facebook 一样重要，都成为生活中的一部分。打开 Github 点击 Explore 常常会有意想不到的新专案，也是吸收新知识、新趋势的好地方。 : 有人说，维护 Open Source 专案，就像是开一间公司，你要不停的对他持续开发，对的时机对的功能，持续研究并找寻突破点，公司才能活得久。 : 原谅我把专案的名字都缩写了，因为这不能是个广告文，但 : 不瞒各位，我就是来骗赞数的啦，骗星星为其次，再来骗 followers，但我一定会做好做满，继续 Open Source。 : 不知道大家的开发 Open Source 经验是什麽呢？ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.160.114.196 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1451014129.A.D43.html