[FZH] zz:社区的基础规则和原因

[bbbush]

站出来的人越多越好，被动等待是对自己心爱产品的不负责任

bbbush 通过 Google 阅读器发送给您的内容： 社区的基础规则和原因 于
11-3-19 通过 shell's home 作者：shell

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

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


可从此处完成的操作：
- 使用 Google 阅读器订阅shell's home
- 开始使用 Google 阅读器，轻松地与您喜爱的所有网站保持同步更新