Weex开源首月记 - Githubissues

lvscar commented 8 years ago

本文中的链接多指向目前“内测”阶段的Weex Github仓库
如访问时页面显示"404", 请移步至  http://alibaba.github.io/weex/  提交内测申请

Weex于 2016年4月21日在北京QCon大会上宣布开源并同时上线开源站点已近一月。对于技术同学来说,”开源”一词肯定经常听闻，不少同学还是知名或低调的开源项目的参与者或创建者。但这次“Weex开源”第一次让我们一个技术团队集体参与到开源项目中来, 其中经历，心得和收获我想无论是对于参与其中的同学，兄弟技术团队乃至业界都是有价值的。希望本次和其后的记录能给大家带来帮助.

“内测”与邀请

看多了不少“晒代码后撂下不管”式的开源项目 , 也观摩了很多代码质量，开发过程，社区活跃情况皆优的开源项目。同时，Weex又已经在内部开发了近一年时间，并已运用于多个关键阿里产品里。出于对“开源”和公司“数据安全”的敬畏, 我们决定采用以下三步走的策略来推进开源过程.

建立Github私有仓库，待通过专利，安全，集团开源委员会审核后把代码push到Github私有仓库，同时迁移开发过程到Github.
逐步分批邀请项目组之外的同学以 “Collaborator”的身份获得Weex Github仓库访问权限，在明确告知现状和规则后，邀请参与Weex开发。
完全开放Github仓库访问权限

我们目前处于第二阶段 , 对Weex感兴趣的同学请访问 http://alibaba.github.io/weex/ 提交你的个人邮箱和Github ID, Weex项目组期待与你在Github相会。

社区活跃情况

开源首月，截至至2016/05/12, 一共有3414位用户向我们提交了内测申请，我们分11批邀请了其中信息较为完整 (有工作/组织信息，有GithubID ,GithubID有活跃记录) 的1962位用户成为我们的Github “Collaborator”，月内，这些最早的Weex外部种子用户一共给我们提交了130项Github Issue 。某种程度上，这些Issue可以看做业界对Weex的第一印象，项目组同学们对此非常重视，在每一项Issue下面热情的为提出Issue的同学答疑解惑，目前已有92项Issue得到了解决。

Github Issue 除了作为“技术支持”的渠道，同时也是借助社区力量帮助Weex完善的平台。

通过这些Issue，有同学指出我们文档中的typo ; 有同学给我们提了组件完善建议；有同学甚至研究了我们的底层渲染策略后给出了可行的改进建议; 有同学通过Issue宣传自己的Weex技术交流QQ群 ; 当然，也有这样让列表气氛欢乐起来，最后不得不锁帖的Issue。

在自身的改进之外，作为一款UI框架，我们最期待用户能通过Weex做出新的，超出我们预计的App或Demo , 首月内，我们看到了内测参与同学的回应，虽然略显简单，但Weex项目组同学非常珍视，因为这令我们想起了改变世界的Web最初的时候，质朴中蕴含着无限的可能.

月内改进

可视化直观呈现开发过程数据是Github吸引开发者的一大特性, 通过下面的图表可以直观的看出在Weex开源首月，一共有25位同学在Weex Github仓库进行了401次提交和98次分枝间的Pull Request.

具体的变更记录可以在这里查看，为了保证工程质量，同时让新开发者参与Weex项目更容易，我们参考了多个开源项目后制定了关于 Commit Log 和 Branch Name的格式规范. 每个内测期受邀的用户，都会在代码库赋权通知邮件中被强调在开始参与Weex前需要学习并遵守这些规范。

本月之内的工作多是完善，改进和优化。内置组件中新增了移动应用中常见的Navigation Bar和Tab Bar ， List组件也添加了很多同学期待已久的"pull to refresh"特性。WeexDSL语法也有所增强, 马上同学们就能使用起 require/ inline event / require / compute等让你写we时更趁手一些的新语法。

完整的Change Log, 我们会在随后两天内和Weex 0.5版一起在Github上发布.

经验教训

Weex的代码组织结构在开源前发生了一次较大的变化，在Github提交前，我们把内部的10多个仓库中的内容合并到一个主仓库中. 这样做的好处是可以方便外部用户更快上手同时汇聚社区关注. 但为项目组也带来了不小的工程负担, 原来可以在不同仓库中分而治之的Android ,iOS, Javascript团队现在需要在一个仓库中协作. 每个部分都有独立的构建过程，同时又需要协调一致.

我们初步的解决思路是让不同的功能团队在不同的分枝中进行开发,功能完成后再合并到主分枝。

虽然在同一个库中，Weex不同部分依赖形式各不相同，有基于代码的依赖，有基于构建产出的依赖。为了修复问题，某个分枝会产生紧急变更，独立构建版本提供给Weex用户. 面对这样的情况，我们最初较为简单的分枝策略经历几次迭代就显现出局限性了，功能分枝合并时都每每遇到各种问题.

为了应对这种情况，我们把分枝策略进行了升级。最新的策略如下图所示

master
 ↑
dev         <--- PR(hotfix/typo)
 ↑ PR
daily       <--- CI
 ↑ merge/PR
{domain}    <--- PR(feature/bugfix)
 ↑ merge/PR
{domain}-feature-{date}

我们希望通过多层次的分枝结合CI ，能应付后续更复杂的代码管理情景.