[FZH] zz:社区的基础规则和原因
by Yuan Yijun
站出来的人越多越好，被动等待是对自己心爱产品的不负责任
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 阅读器，轻松地与您喜爱的所有网站保持同步更新
13 years, 1 month
[FZH] linux下面有什么比较好用的ssh客户端工具么
by xie yunpeng
linux下面有类似于secureCRT这类的工具么，现在比较头疼的一件事是，使用gnome
terminal想登录服务器以后马上ssh-agent一下目前还没有找到方法，每天都要登录很多服务器，有的服务器没有外网ip，不能直接登录，总是登上一台然后当入口很麻烦
还有想知道大家在linux下面是怎么工作的
13 years, 1 month
[FZH] 关于DVD跟live CD的疑问?
by 好大一只鸟
Hi All
大家安装fedora用DVD还是live CD呀
我一直都用DVD的文件，感觉ubuntu的live CD安装挺好的，不知fedora的live CD安装好后跟fedora的DVD
安装好后有啥区别，以前安装过，感觉少了很多东西，不知影响不影响使用！貌似系统服务都不太一样！
Best regards
Big Bird
13 years, 1 month
[FZH] 如何加入本邮件列表
by Dee.H.Y
我邀请一个哥们加入邮件列表,但是我不知道该如何让其加入.谁可以告诉他.
我请他来做翻译的,他现在在上海做同声传译工作,应该可以帮忙的.
13 years, 1 month
[FZH] [T] Fedora 15 发布前翻译计划
by Tian Shixiong
亲爱的 Fedora 中文翻译弟兄们：
截止目前，Fedora 15 软件翻译完成率为 75%，排行第七。如果顺利的话，在 3
月 29 日前希望能完成 80% (3 月 29 日是 Fedora 15 软件翻译的截止日期)。我
想对于强大的中文翻译团队来说，其实 100% 都不是问题。
但是，这其中最重要的是翻译质量。我们的劳动成果最终受益人是 Fedora 中文用
户，当然还有我们自己。好的翻译，是对最终用户的负责，是对 Fedora 发行版的
认可，也是我们翻译团队的荣誉。
因此在接下来的翻译中，请大家在以下方面多注意一些：
1. 已有翻译的正确性
在进行翻译的同时，要检查已有翻译内容 (输入错误，错别字，语法等等)
对于正确的翻译，没有任何硬性、明确的规定。在我自己看来，正确的翻译起
码应该做到：
完整表达原意；
让人可以看的明白，不误解；
读的舒服；
多使用书面语；
尽可能与原文格式/风格保持一致；
2. 自己翻译的正确性
对于自己翻译的内容，要保证没有错别字，没有拼写错误，没有输入错误。
3. 术语的统一性
目前我们的术语表还在完善之中。对于实在无法确定翻译的术语，请发邮件到
列表讨论， 或者查询 wiki。
保证在所翻译组件/文档中术语的统一。
4. 格式的正确性
括号使用英文半角()；
汉字及英文还有数字之间加上空格，比如 “欢迎加入 Fedora 项目“
快捷键请用英文括号，前方加上空格，快捷键字母大写，比如 “确定 (_O)”
另外，请目前组件/文档翻译的参与者对该组件/文档进行检查。检查内容：
1. 以上提到的各种问题
2. “你”字，请用“您”字代替
对于较大的组件/文档，可以考虑使用 Transifex 的搜索，或者进行抽检。
以上是我自己对翻译的一些见解和计划，希望大家纠正错误并进行补充。
谢谢，翻译愉快！
回复邮件，请删除不必要的引用内容。这是个好习惯。
--
Regards,
Tiansworld
Fedora Project Ambassador & Contributor
13 years, 1 month
[FZH] 这个配置玩Linux怎么样？
by 好大一只鸟
Hi All
最近准备攒台电脑，大家看看下面这个配置玩Linux如何！可以很好的支持吗？
CPU AMD羿龙II X4 955/黑盒 1个
主板 技嘉GA-870A-UD3 1个
内存 威刚2G DDR3 1333万紫千红 2个
硬盘 西部数据1TB SATA3 32M蓝盘 1个
显卡 迪兰恒进 HD5850恒金1G 1个
刻录机 先锋DVR-219CHV 1个
Big Bird
Best regards
13 years, 1 month
