绿野org开放式网站开发管理制度（初稿）

yyquick

上周末和小李见面之后，小李对开放式网站开发管理的理念也十分认同，并嘱咐我拟一个相关的流程。为此我利用业余时间，研究了一些开源项目的开发管理方法，同时结合当前网站的实际，设计了这个管理制度的初稿，欢迎大家讨论。制度内容如下：

为了让更多的人可以比较容易的参与网站的开发，最大限度的发挥各位驴友的能力来建设我们的网站，现草拟一份开放式的网站开发管理制度。这个制度的目的，一个是为了让大家有条不紊的参与网站开发，另一个就是最大限度的减轻管理的成本，减轻每一个有心为网站做贡献的人的压力。

网站开发要解决两件事情：一是如何提出需求，二是如何实现需求。而为了大家一起来合作解决这两件事情，一是要明确贡献者的角色分类和各自的职责，二是要明确履行各个职责的时候需要遵循的规范。有了明确的职责和规范，大家一起合作才不至于乱成一团最终一事无成。

一、贡献者角色分类和职责：

普通用户：普通用户是指关心绿野org网站的活跃用户。普通用户的职责是根据自己使用网站的情况，报告网站的bug和提出网站需要实现的新功能，简而言之就是提需求。普通用户需要是可以在绿野org网站发帖的正式用户。

开发人员：开发人员是指有能力给网站贡献代码，实现某些需求的工程师。开发人员的职责是按照规定的规范来编写代码，实现普通用户提出的需求或者解决普通用户发现的bug。开发人员需要同时符合成为一个普通用户的条件，也就是说是绿野org网站的正式用户。

技术小组成员：技术小组成员是由网站管理小组选拔出来的对网站的开发质量负责的人。技术小组成员的职责，一个是整理普通用户提出的需求，和普通用户沟通和探讨需求的合理性和可行性，判断需求的优先级，保持网站功能的整体协调；另一个就是审核开发人员提交的实现需求的代码，确保代码符合规范、正确的实施了需求、代码安全没有明显的漏洞和没有恶意的木马，并且做好代码的分支管理工作。技术小组成员同时可以兼有普通用户的身份或者是开发人员的身份。

二、需求的提出和确认

任何一个普通用户都有权提出自己对网站的看法、需要做的改进和新的功能需求，又或者是报告bug。普通用户提出需求的方式是在技术小组版面发起一个主帖，主帖标题包含“[需求]”或者“[BUG]”字样，方便大家辨认。其他普通用户和技术小组的成员可以在主帖下回复来讨论该需求或者BUG，以期达成一致意见。

对于BUG来说，由技术小组确认并组织开发人员尽快解决。对于新需求，技术小组成员定期收集用户提出的新需求，给每个新需求赋予一个唯一的编号，整理出来和判断各个需求的级别（高、中、低、暂不实施、废弃），并通过在技术小组版面发帖的形式公布，从而形成一个需求实施的计划。

如果有普通用户对需求实施计划有异议，则有异议部分暂时停止实施，技术小组继续和用户沟通。当超过一个星期还无法达成一致意见时，由管理小组投票决定该需求的级别。

三、开发人员实施需求的规范

绿野org的代码放在github.com上进行公开保管。任何人都可以对其进行阅读和复制。开发人员可以从需求实施计划中挑选自己感兴趣的需求来实施，但为了让开发人员顺利的提交代码，开发人员必须要有github.com的账号。具体实施的步骤如下：

1、在github.com上对应的repository上新建一个issue，标题上指出要实施的需求的编号，内容是对实施这一需求的简要介绍，和技术小组对开发的过程和对开发结果的讨论均在这个issue上面讨论。

2、fork代码到自己的账号，然后用fork出来的代码进行开发。开发的代码需要符合相关的代码规范，同时也必须包含足够的说明文档，以便于技术小组成员审核。

3、开发人员代码开发完成，并且自己测试通过之后，再原repository上发出一个pull request。

4、技术小组成员收到pull request请求之后，对代码进行测试和审核。这个过程中发现的一些问题都在对应的issue上进行沟通。直到代码测试和审核通过为止。

5、代码通过测试和审核之后，技术小组成员通过开发人员发出的pull request请求，将代码合并到主分支。

6、技术小组成员定期发布上线分支，以将主分支上实施的功能放到测试网站进行上线前的测试。并且在技术小组版面上发布测试通过，告知新的测试网站实现了哪些新的需求。

7、所有网站用户都可以对测试网站进行测试。如发现有bug，则把所有发现的bug集中起来，由技术小组成员和对应的开发人员共同在主分支上修正bug。修正bug的流程和实施新需求一样，需要由发一个新的issue开始。然后再次发布测试版本。这个过程直到测试不再发现新的bug。接下来就可以把该分支版本直接推送到线上服务器。

8、如果任何时候遇到有比较严重紧急的bug，技术小组成员可以直接在主分支上commit代码，并且上线解决。除此之外，技术小组原则上不通过commit代码的方式来提交新的需求实现代码。

可能会有部分开发人员不太熟悉git这个版本管理工具和github.com这个网站的使用方法。对此可以参考一下知乎的这个问答：http://www.zhihu.com/question/20070065

这是一个初步拟定的规范，大家可以就此提出各种意见和建议。最后希望大家都愿意为网站贡献出自己力所能及的力量。

笑对人生_

先说点不想干的，我经常参与的一个apache项目，几个月前刚把代码转到github管理，虽然不能作为apache committer直接push代码了，还是觉得github pull request机制要比apache的review board好使多了。

言归正传，如果绿野代码开源，谁是贡献者？
大部分活跃的开源项目，除去源代码贡献者，最主要的代码贡献者其实也是使用者，再然后就是义务贡献者，再次就是闲着没事做找漏洞的。

就绿野源代码而言，我不清楚有多少人会选择绿野的源码安装使用，我还没看到新网站，无法评估，但我想很有限。这些人又有多少会贡献代码，估计屈指可数了。先说点不想干的，我经常参与的一个项目，几个月前刚把代码从Apache转到github管理，虽然不能作为apache committer直接push代码了，还是觉得github pull request机制要比apache的review board好使多了。

言归正传，如果绿野代码开源，谁是贡献者？
大部分活跃的开源项目，除去源代码贡献者，最主要的代码贡献者其实也是使用者，再然后就是义务贡献者，再次就是闲着没事做找漏洞的。

就绿野源代码而言，我不清楚有多少人会选择绿野的源码安装使用，我还没看到新网站，无法评估，但我想很有限。这些人又有多少会贡献代码，估计屈指可数了。要说我可能会算一个。

至于有找漏洞的，有人可能会觉得是好事，使系统更安全。好吧，反正我是希望有漏洞也别让人那么容易找出来的。有源代码相对容易很多。

从目前看来，完全开源似乎没有太大意义，贡献者实在有限。还是先考虑自己内部怎么开发方便吧。github是个挺时髦的地方，当然确实也很不错。代码放github，加上权限管理，除了技术小组人员，可以也邀请绿野感兴趣的朋友(我是比较有兴趣的，上班闲着没事可以研究下)，再把技术小组板面当jira使，就差不多了。

来自旧版论坛的签名

Smile, and the world smiles with you

sutrip

github 确实挺时尚的 [sign]泰国旅行社华东旅行社[/sign]

Wood

1. 我没有抱怨，也没有冷言冷语。就事论事说观点。
2. 我表达了感谢和支持这种积极想法。积极想法和做事方法是两回事。
3. 这个帖子本身就是来征求意见的，就事论事谈意见，本来就是因该的事情。

来自旧版论坛的签名

朦胧睡眼半睁开，
衣冠不整起床来。
觉时枕席应犹在，
向来烟霞青天外。
无言可对漫天雨，
冷看镜中鬓毛衰。
心如秋月霜明静，
不知何处可徘徊。

suxiaoyu

任何事都会有不同的声音出现，很正常，支持

来自旧版论坛的签名

没有比脚更远的路，没有比人更高的山

红狐

openssh的四个主要开发者都是完全公开的，什么背景什么来历业界都知道；

植入恶意代码，和账号安全紧密相关，审核未必能审核出来，只要发生一次，那么org的账号密码就会泄露，备份数据仅仅是实现数据完整性的安全，重启回退也是在知道发生泄露的前提下知道漏洞植入的时间点，如果发生在不知不觉中将失去控制；

毕竟是业余开发，所以项目推动的管理会没有开源的那种靠荣誉感、热情的动力足，以前org创始时尚可，现在开发的动力我认为是缺乏的；

当然了，以上只是我认为的负面的因素，先考虑一下可能的问题 [sign]在绿野感悟了很多o_^现在是回馈的时候[/sign]

Wood

开源并不是一个唯一的解决方案. 对于绿野org, 可以说不是一个很好的解决方案.因为绿野org对于平台的要求并不是特别高. 平台功能越强大, 维护成本和要求的效率越高. 这次的升级主要是因为脱离时代太远了, 需要补齐一些基本的需求,以及安全相关的基本措施.

顺便说一句,我在这个业界工作有十几年了, 在绿野org也有十年多了.这个世界很复杂.

最后,请不要误解,我很赞赏和感谢你的积极想法和愿意为绿野org做贡献的意愿.希望有机会能一起走走.

来自旧版论坛的签名

朦胧睡眼半睁开，
衣冠不整起床来。
觉时枕席应犹在，
向来烟霞青天外。
无言可对漫天雨，
冷看镜中鬓毛衰。
心如秋月霜明静，
不知何处可徘徊。

yyquick

首先，能够贡献代码的人就不多，即使有人要故意作恶，也必须要有一定的技术基础。
其次，对于一个有相当互联网开发经验的人来说，鉴别一段是否有恶意的代码是不难的。
再次，即使有漏网之鱼，对故障的分析也能够确定问题所在，找到合理的回退点。
最后，我想知道作恶的人的动机是什么？
按照你的理解，这个网站原地踏步就是最好的，对吗？

Wood

鉴别善意贡献的开销和风险太大,和收获相比, 不值得.

即便有定期备份,在多次部署版本更新后,如何确定哪个版本为最佳回退点? 攻击很有可能不是立刻发生在问题版本部署之后.

从这次网站升级进度看来,我很难相信技术小组可以高效及时的监控和消除这些风险.

来自旧版论坛的签名

朦胧睡眼半睁开，
衣冠不整起床来。
觉时枕席应犹在，
向来烟霞青天外。
无言可对漫天雨，
冷看镜中鬓毛衰。
心如秋月霜明静，
不知何处可徘徊。

ading

有想法并付之于行动，总是好的