2011年3月19日星期六

社区的基础规则和原因

    1.社区中的常规事务由个人申请,申请到的人全权处理问题。
    2.
在申请前,需要在社区公共平台呼叫请求。大致类似于"我要做某事了,有没有人在做或者能够提供帮助,请联系我"
    3.
如果有人对贡献者所做的工作有异议,可以请求修改或者复议。
    4.
如果仍旧不满意,可以申请替换贡献者。经过全社区成员投票后就会变更贡献者。
    5.
如果不能明确归属的事情,或事情本身就比较重要,则由全社区成员投票。
    6.
如果具体操作者在不确定做法的时候,可以发起讨论和投票,获得社区意见。

    
为什么社区通常具有以上工作模式?
   
首先,社区的原则是自愿。通常社区是不会为个人的工作支付薪酬的。因此,谁愿意做什么事情,做到什么质量,完全是不可控制的。这也就是为什么社区事务是由个人申请的,因为并不能向社区中的具体人员指派工作。当一个问题比较严重的时候,也只能由资深社区人员呼吁有没有人志愿解决,而不能强行分派。这是社区为各个软件公司所诟病的特性之一。
   
为什么申请前需要在公共平台呼叫请求?这样首先防止了工作冲突。尤其是上游发行一个新包的时候,如果没有呼叫请求(debian社区好像叫做ITP),就会出现两个打包者重复工作的问题。其次,如果前任因为某些因素放弃了继续处理,也许他能给你一些额外的帮助。尤其是兼容性问题上的帮助,这样比较有助于保障一致性。
   
为什么通常事务由申请到的人全权负责?因为一个事务会牵涉到非常多和复杂的细节问题。例如一个包的临时文件位置是使用/tmp还是/var/tmp,依赖库是使用gcc4.1还是gcc4.4。这些细节问题要一一搞定,社区没有那么多时间。如果志愿者是个熟练的人,往往问题的决策会采用比较通用的方案,社区会无条件接受志愿者的方案。当志愿者的方案比较糟糕,或者至少说有待推敲的时候。如果有人用的不爽,就会提出异议,或者更进一步提出解决方案。如果没人关心,那就让他去了。
   
为什么对于仍旧不满意的问题,只能替换贡献者,而不能强迫贡献者接受方案呢?因为,上文阐述了,贡献者是出于自己的自愿,来帮助社区的。强迫他们接受某个他们所不习惯的想法首先并不尊重他们,招致他们的强烈反感。其次,这些方案可能扰乱他们的工作思路。所以从这个角度来说,当志愿者愿意接受你的方案时自然好说。而如果万一他不接受,要使得自己的想法实现只有让全社区基本同意,你,或者其他人接替这个志愿者的部分工作。
   
为什么社区在决定性的问题上,采取贡献者民主投票的方式呢?因为,如前我们看到,社区的发展是每个贡献者提供自己的力量共同发展的。这样的社区一定会有不协调的情况。而让冲突升级,导致社区分裂,是不利于社区发展的。可以看到,社区是要讨好贡献者的。更多,更强力的贡献者,社区就能够有更好的发展。所以,采取民主投票的方式,是征求最多贡献者的同意,让他们支持社区,愿意继续为社区作出贡献。并且期待不同意的贡献者,能够理性的作出一定妥协,接受社区的大多数意见。
   
当然,由于意见未能统一而倒置社区分裂的情况常有发生,尤其是社区同时拥有两位强势的领导的时候,并且他们的意见碰巧相左的时候。但是在大多数时候,贡献者会考量,自己是否值得为了某个意见放弃整个社区。考量的结果往往是接受社区的结论,但是保留自己意见。这种行为会保留社区中最多的人,并且可以期待剩下的人能够接受。这一原则,我们称为"尊重大多数贡献者"。而社区中,部分事物自主可决定的规则,只是因为社区假定你的行为会被大多数贡献者接受。
   
我们可以看到,社区在发展中采取了很多自主判断假设和市场机制。社区需要假定你的行为是被大多数贡献者所能接受的。社区假定你能够分辨什么是"比较重要"的事情,从而需要征求多数意见。什么是你不需要劳动社区帮忙的事物。在正常的世界中,我们的假定通常都是成立的。debian社区大部分打出来的包并没有人提出异议。对于社区中文名定名或者下一开发版代号之类的问题,通常也是社区协商确定后再行处理的。因此,我们的社区通常工作良好。但是在某些特例下,例如有人无法理解什么问题是重要问题,哪怕大多数的人对这个问题的认识并没有困难。或者,更进一步说,有人捣乱。在这些特例下,社区往往会陷入一种比较混乱的状态。国外经常有所谓"民主效率低于专制"的结论,就是这个现象的集中爆发和体现。
 

没有评论: