如何管理好开源软件社区:开源项目管理方法(2)

　　所有的代码必须以Patch的形式提交到大家共用的项目库

　　所有提交的的Patch必须要由团队核心成员审核后方可入库(有的项目中，有这种权力的人只有一个。比如Linux Kernel，一些核心模块，比如内存管理和进程调度，只有Linus本人有Patch合并权力)

　　比如我要给RESTEasy项目交代码：

　　https://github.com/resteasy/Resteasy

　　首先我要将项目fork到自己的空间：

　　https://github.com/liweinan/Resteasy

　　然后clone出来做修改，将修改提交进自己的代码库，并将修改内容生成Patch交由Bill Burke审核：

　　https://github.com/resteasy/Resteasy/pull/35

　　可以看到，把代码库迁到Github，不光是改变一个代码库管理工具这样简单，随之而来的是整个流程管理的一种改变。围绕着Git的这种代码管理流 程，是Linux Kernel社区长久以来一直使用的模式，是社区管理成功经验的直接沿用。有关github的Pull Request，可以参考：

　　http://help.github.com/pull-requests/

　　接下来我们谈谈质控：在JBoss AS7这个项目中，测试过程基本上是全自动化的，所有的测试最终必须形成单元测试代码，用到的技术也非常丰富，包括：JUnit，Arquillian, Selenium等等。

　　这些可能和别的项目没什么区别，但AS7的质控流程不只自动化到这种程度，它在所有的“连接环节”也是自动化的。这些环节包括：

　　Github中有Patch提交过来时，自动执行项目测试。

　　Jira中的Bug报告与Github中的Patch相关联。

　　有了这两点，则从代码提交，到测试，到Bug跟踪记录的过程便全联系在一起了，中间环节不需人工干预。

　　看下Github与项目测试之间的连接，具体看下AS7的这个Patch提交请求：

　　https://github.com/jbossas/jboss-as/pull/1676

　　注意到这两条日志：

　　可以看到在github中有jboss-as-pull-request这个用户将这个Patch与AS7的Jenkins测试服务器中的代码进行了合并，并触发执行了测试工作：

　　http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-param-pull/

　　jboss-as-pull-request这个用户实际上是机器人，用于定时查找提交给AS7的Patch，执行合并测试工作并最终给出测试结 果。上面的地址是AS7的Jenkins测试服务器所在位置，仅能从github上面看到链接但无法从外网访问。因此我将服务器的运行情况截图如下：

　　有关Jenkins的使用方法，本文不准备展开讲解，有兴趣可看此篇文章： 《基于Jenkins的持续集成》

　　接下来我们看看github上面的代码流程是如何和Jira结合在一起的。试着打开一个AS7的Bug Report看看：

　　https://issues.jboss.org/browse/AS7-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel#issue-tabs

　　看到有这样一栏：

　　Github的Pull Reqest与Bug Report连系在了一起。这是通过JIRA与Github之间的插件完成的。下面是JIRA与Github之间相联系的流程，在Jira中进行了定制实现：

　　通过Jira中的Link Pull Request，将代码与Bug管理联系在了一起。

　　除了与代码相关的内容，社区必备的组成部分还应有文档，论坛，及邮件列表。还是以JBoss社区为例，JBoss的文档位于：

　　http://community.jboss.org/wiki

　　及：

　　http://docs.jboss.org/

　　都有专门的文档团队在维护，团队规模并不小。接下来是论坛：

　　https://community.jboss.org/index.jspa

　　邮件列表也是社区常用的沟通工具：

　　https://lists.jboss.org/mailman/listinfo

　　因此，社区的管理并不是想象中的那么“松散”。相反，社区的组织模式对管理提出了更高要求。而这些协作工具的发展，正是多年成功项目管理的经验模型。希望通过这篇文章能帮助大家对开源社区的工作有更多的了解。

　　国内开源社区产品到现在也有七八个年头了，过去的开源社区产品比较单一，我们叫作传统论坛社区，其核心就是单一的论坛产品。站长们用论坛产品做社区也有很长时间了，开源论坛产品经历这些年头的风风雨雨，也服务了很多企业和个人站长。

　　当互联网在中国的不断发展，互联网概念在中国网民心中不断变化，很多模式也经历了出现、繁荣、没落的过程。从web1.0到web2.0时代的演化，甚至有人开始提web3.0的概念;从文本、bbs、blog、cms、podcast到近年热门的电子商务、sns、miniblog等等，不同概念不同模式都承载了不同时代互联网的特征和需求。

　　有很多模式在中国互联网发展的潮流中倒下了，如单一的blog模式，因为找不到更好的盈利模式，国内有几家当年极为流行blog托管站点都萎靡不振;有些模式在这个潮流中被融合和混搭了，如sns，08年红红火火，但因为用户门槛高，烧钱厉害，这种模式逐渐被混搭到其他站点上来增加用户黏度，成了站点的一个标准配置。传统论坛社区在经历这些年互联网的变迁，单一的论坛社区产品再也不能更好的承载信息和价值。新社区成了很多站长共同的需求，产品的mash up(混搭)也成了开源社区的企业必须要做的事情，此时，开源社区产品多模式化的概念由此诞生。

　　如何满足不同的站长在新时期互联网的大环境大市场下能更好的运营，更好的去承载信息和价值，是开源社区需要思考的。

　　社区产品多模式化，真正实现mash up(混搭)!

原文转自：http://www.ltesting.net