写在前面
因为机缘巧合参加了Github中国的第一次用户活动，所以最近有参与一些开源项目的外围维护。简单来说就是去issues 区域解答初级用户的问题，以及尽可能的提出Pull Request。就我这两周对一两个开源项目的观察，更多地发现了一些共有的社区问题，希望可以拿出来探讨下。
社区特点
拿百度之前捐给Apache 基金会的Echarts 项目为例，功能很强大，用户特别多，仅仅是used by 就有接近5w 个，fork 有1.1w个，这充分说明Echarts 库起步早，用户多。
但是从开源社区用户特点讲，有几点：
- 中国用户多，issue 多为中文
- issue 中许多问题在文档中有描述，有效issue不占多数
- 贡献者多为国内开发者
这几个特征其实也是很多国内开源项目共有的。这直接导致国内开源项目维护的难题：
- issue 中文多，国外开发者难以提供帮助，项目生态很难在国外推广
- issue 质量不高，项目维护需要更多人力
- 维护者缺乏多样性，稳定性
现状和思考
由于我偶尔会到issue区逛逛，顺便解答一些力所能及的简单问题，也偶尔看看邮件列表，了解到这类项目维护的一些现状。其实从Github 项目的 Insight 中，也可以窥探出一些总体趋势。
例如最近一个月的代码改动状况，贡献人数，PR 的merge、open情况，多少个issues 被open 和close 了。能看出来，最近一个月，项目的维护效率算是比较高的，issue被处理的速度远超open 的速度。PR也是同样，大部分都快速review 和merge 到主分支了。
相比之下，ElementUI 项目似乎历史总体贡献者更多（接近500个），但最近PR的处理速率更慢些（核心member 似乎不够用，而PR 太多）
普遍的，都有现存issues量很大的问题，还有一些现象值得思考。
重复工作量
我在处理一个issue 中与维护人员多次交互，最后提了PR，但在查阅之前的 PR list 时，发现还有个类似的fix 没有被merge，是针对另外一个重复issue 的。这导致我的工作似乎是重复了。。但这个问题经过几天的讨论并没有被维护人员标记为duplicate，这使得工作量实际上是被浪费了。
不必要的需求
部分被用户提出的new feature，或者enhance 实际上优先级不高，或者完全没必要。这类feature，也许会占据开发者许多时间去实现或者对于功能稳定性 risk 较高。实际上需要更多的内部投票，讨论去决定最终的方案，做还是不做，怎么做的问题。
这其实是个需求砍杀的问题，我在之前关于敏捷开发的文章中有提到过，合理的需求控制可以较好地让团队关注正在做的事情。
规范的树立
我始终认为，维护团队应该有自己的个性和强势理念。关于低质量issue，没有reproduce link 的issue 应该设定严格的超期时限，自动关闭，以减少对于团队精力的消耗。
作为一个致力于国际化推广的项目，可以考虑以下几点：
- 关闭中文issue的设定，自动化管理issue
- 尽快处理PR，标注重复issue
- 对issue进行难度评级，优先级评定，有利于招募贡献者
- 更清晰的 RoadMap，有利于招募贡献者
