Author: rocksun Date: Sun Nov 16 11:16:49 2008 New Revision: 1568 Log: * ch04.xml: just commit some change.
Modified: trunk/zh/ch04.xml Modified: trunk/zh/ch04.xml ============================================================================== --- trunk/zh/ch04.xml (original) +++ trunk/zh/ch04.xml Sun Nov 16 11:16:49 2008 @@ -30,261 +30,65 @@ <sect1 id="benevolent-dictator"> <title>慈善独裁者</title> -<para>The <firstterm>benevolent dictator</firstterm> model is exactly -what it sounds like: final decision-making authority rests with one -person, who, by virtue of personality and experience, is expected -to use it wisely.</para> - -<para>Although "benevolent dictator" (or <firstterm>BD</firstterm>)is -the standard term for this role, it would be better to think of it as -"community-approved arbitrator" or "judge". Generally, benevolent -dictators do not actually make all the decisions, or even most of the -decisions. It's unlikely that one person could have enough expertise -to make consistently good decisions across all areas of the project, -and anyway, quality developers won't stay around unless they have some -influence on the project's direction. Therefore, benevolent dictators -commonly do not dictate much. Instead, they let things work -themselves out through discussion and experimentation whenever -possible. They participate in those discussions themselves, but as -regular developers, often deferring to an area maintainer who has more -expertise. Only when it is clear that no consensus can be reached, -and that most of the group <emphasis>wants</emphasis> someone to guide -the decision so that development can move on, do they put their foot -down and say "This is the way it's going to be." Reluctance to make -decisions by fiat is a trait shared by virtually all successful -benevolent dictators; it is one of the reasons they manage to keep the -role.</para> +<para><firstterm>慈善独裁者</firstterm>这一称号确实名副其实：最终的决定权完全取决于一个人，因为其人格和经验的力量，他被认为可以明智的运用这个权力。</para> + +<para>尽管“慈善独裁者”（<firstterm>BD</firstterm>）是这个角色的标准术语，但是更应该将其视为“社区认可的仲裁者”或“裁判者”。通常来说，慈善独裁者并不会作出所有的、甚至大多数的决定。一个人很难拥有在项目所有领域中都能做出正确决定的专业技能，毕竟，如果对于项目的方向没有任何影响，有价值的开发者也不会在此停留。因此，慈善独裁者通常不会非常的独裁。相反，他们会尽可能的让事情在讨论和实验中顺其自然。他们自己也会参与讨论，但是作为某领域的普通开发者，他们一般会尊重拥有更多专业知识的领域维护者。只有当明显无法得出结论时，而且大多数成员<emphasis>期望</emphasis>有人能够指导作出决定，并让开发继续时，他们才会采取坚定的立场并说“这是我们前进的路。”避免使用命令作决定是所有成功慈善独裁者共同的特征；也是他们设法保持这个角色的一个理由。</para> <sect2 id="benevolent-dictator-qualifications"> -<title>Who Can Be a Good Benevolent Dictator?</title> +<title>谁可以成为一个慈善独裁者？</title> + +<para>成为一个BD需要许多特性的组合。首先，要对自己在项目中的影响有经过充分磨练的敏感性，这样可以保证自我约束。在一个讨论的早期阶段，一定不能过于确定的表达自己的意见和结论，以至于让别人觉得继续发生分歧毫无意思，人们应当能自由的放飞思想。BD也会不可避免的屡屡发表愚蠢的意见，所以这个角色也必须具备认可和承认自己作出错误决定的能力—尽管这是一个<emphasis>所有</emphasis>优秀开发者都应该具备的能力，但如果她要长期呆在一个项目，这一点特别重要。但区别是BD无法无视其信誉的长期损害，但资历尚浅的开发者不必如此谨慎，所以BD必须对批评或反对决定的语句小心措辞，对于词汇的分量十分敏感，不仅是技术上的，还包括心理的。</para> + +<para>BD的技术技能<emphasis>不</emphasis>需要超越项目中的所有人，但她对于自己的代码工作必须足够精通，也必须能够理解所有考虑中的变更评论，但这还不够。BD的位置并不是通过恐怖的编码技巧获取或保持的，重要的<emphasis>是</emphasis>富于经验和全局的设计感觉—不必是根据要求生产好设计的能力，只需要有识别好设计的能力，无论什么来源。</para> + +<para>慈善独裁者经常是项目的创建者，但这只是关系，而不是原因。这类特性让一个人能够成功的开始一个项目—技术能力、说服别人加入的能力等等—也都是BD所需要的。当然，创建者开始就自动有了相关的资历，在成为慈善独裁者的方法中，是所担心的阻力最小的。</para> -<para>Being a BD requires a combination of traits. It needs, first of -all, a well-honed sensitivity to one's own influence in the project, -which in turn brings self-restraint. In the early stages of a -discussion, one should not express opinions and conclusions with so -much certainty that others feel like it's pointless to dissent. -People must be free to air ideas, even stupid ideas. It is inevitable -that the BD will post a stupid idea from time to time too, of course, -and therefore the role also requires an ability to recognize and -acknowledge when one has made a bad decision—though this is -simply a trait that <emphasis>any</emphasis> good developer should -have, especially if she stays with the project a long time. But the -difference is that the BD can afford to slip from time to time without -worrying about long-term damage to her credibility. Developers with -less seniority may not feel so secure, so the BD should phrase -critiques or contrary decisions with some sensitivity for how much -weight her words carry, both technically and psychologically.</para> - -<para>The BD does <emphasis>not</emphasis> need to have the sharpest -technical skills of anyone in the project. She must be skilled enough -to work on the code herself, and to understand and comment on any -change under consideration, but that's all. The BD position is -neither acquired nor held by virtue of intimidating coding skills. -What <emphasis>is</emphasis> important is experience and overall -design sense—not necessarily the ability to produce good -design on demand, but the ability to recognize good design, whatever -its source.</para> - -<para>It is common for the benevolent dictator to be a founder of the -project, but this is more a correlation than a cause. The sorts of -qualities that make one able to successfully start a -project—technical competence, ability to persuade other people -to join, etc.—are exactly the qualities any BD would need. And -of course, founders start out with a sort of automatic seniority, -which can often be enough to make benevolent dictatorship appear the -path of least resistance for all concerned.</para> - -<para>Remember that the potential to fork goes both ways. A BD can -fork a project just as easily as anyone else, and some have -occasionally done so, when they felt that the direction they wanted to -take the project was different from where the majority of other -developers wanted to go. Because of forkability, it does not matter -whether the benevolent dictator has root (system administrator -privileges) on the project's main servers or not. People sometimes -talk of server control as though it were the ultimate source of power -in a project, but in fact it is irrelevant. The ability to add or -remove people's commit passwords on one particular server affects only -the copy of the project that resides on that server. Prolonged abuse -of that power, whether by the BD or someone else, would simply lead to -development moving to a different server.</para> +<para>请记住，潜在的分叉会以两种方式出现。一个BD可以和其他人一样分出一个项目，确实有些人已经这样做了，只要他们觉得要将项目带领到大多数项目成员不希望的方式中。因为可分叉的能力，无论慈善独裁者是否有项目主服务器的root权限（系统管理员特权），人们有时候会将服务器的控制能力当做对于一个项目的权力根源，但是机上这毫不相干。将某服务器商某人的提交密码添加或删除的能力只会影响存放在那个服务器上的项目拷贝，对于此权力长期滥用，无论她是BD或其他人，都会致使开发转到其他服务器上。</para> </sect2> -<para>Whether your project should have a benevolent dictator, or would -run better with some less centralized system, largely depends on who -is available to fill the role. As a general rule, if it's simply -obvious to everyone who should be the BD, then that's the way to go. -But if no candidate for BD is immediately obvious, then the project -should probably use a decentralized decision-making process, as -described in the next section.</para> +<para>无论你的项目是否存在一个慈善独裁者，或能够在一个较弱的集中式系统下运行良好，都十分依赖于谁在承担这个角色。作为一个普遍的规则，通常对每个人来说谁是BD非常的明显，然后就会如此继续。但是如果没有明显的BD候选者，项目通常会使用分散的决策过程，这就是下个小节所描述的。</para> </sect1> <!-- ======================== SECTION ============================== --> <sect1 id="consensus-democracy"> -<title>Consensus-based Democracy</title> +<title>共识为基础的民主（Consensus-based Democracy）</title> + +<para>随着项目的成长，通常会从慈善独裁模型转为更开放的民主系统。这不是必然由于某个BD的不满，而可以简单认为团队基础的管理更加“进化稳定”，借用一个生物学的隐喻。每当一个慈善独裁者引退，或尝试将决策责任更均匀的分配出去，这就是团队选定一个新的非独裁系统的好机会—也就是建立一个章程。团队可能错过了第一次机会、或者第二次，但是最终会这样做；一旦做了，这个决定就不太会反转过来。常识解释了原因：如果某个N位成员的团队给某个人特殊的权利，也就意味着有N - 1位成员都愿意降低自己的个人影响。人们通常不愿意这样做。即使他们这样做了，结果的独裁同志仍然是有条件的：团队推举了BD，团队也可以罢免BD。因此，一个项目的领导权一旦从某个魅力个人转移为更正式的团队为基础的系统，就很少会走回头路。</para> + +<para>这类系统的工作细节有很大的区别，但是有两个共同的元素：首先，团队大多数时候在达成共识的情况下工作。其次，在无法达成共识时有一个正式的投票机制。</para> + +<para><firstterm>共识</firstterm>仅仅意味着每个人都能够接受的一种协议，它不是一种含混的状态：当有人提出某个共识已经达成，而且没有人提出反对意见，我们说一个团队对某个问题达成了共识。当然，提出共识的人应当详细说明共识的内容，如果不是显而易见的话，还要说明后续的动作。</para> -<para>As projects get older, they tend to move away from the -benevolent dictatorship model and toward more openly democratic -systems. This is not necessarily out of dissatisfaction with a -particular BD. It's simply that group-based governance is more -"evolutionarily stable", to borrow a biological metaphor. Whenever a -benevolent dictator steps down, or attempts to spread decision-making -responsibility more evenly, it is an opportunity for the group to -settle on a new, non-dictatorial system—establish a -constitution, as it were. The group may not take this opportunity the -first time, or the second, but eventually they will; once they do, -the decision is unlikely ever to be reversed. Common sense explains -why: if a group of N people were to vest one person with special -power, it would mean that N - 1 people were each agreeing to -decrease their individual influence. People usually don't want to do -that. Even if they did, the resulting dictatorship would still be -conditional: the group anointed the BD, clearly the group could depose -the BD. Therefore, once a project has moved from leadership by a -charismatic individual to a more formal, group-based system, it rarely -moves back.</para> - -<para>The details of how these systems work vary widely, but there are -two common elements: one, the group works by consensus most of the -time; two, there is a formal voting mechanism to fall back on when -consensus cannot be reached.</para> - -<para><firstterm>Consensus</firstterm> merely means an agreement that -everyone is willing to live with. It is not an ambiguous state: a -group has reached consensus on a given question when someone proposes -that consensus has been reached, and no one contradicts the assertion. -The person proposing consensus should, of course, state specifically -what the consensus is, and what actions would be taken in consequence -of it, if they're not obvious.</para> - -<para>Most conversation in a project is on technical topics, such as -the right way to fix a certain bug, whether or not to add a feature, -how strictly to document interfaces, etc. Consensus-based governance -works well because it blends seamlessly with the technical discussion -itself. By the end of a discussion, there is often general agreement -on what course to take. Someone will usually make a concluding post, -which is simultaneously a summary of what has been decided and an -implicit proposal of consensus. This provides a last chance for -someone else to say "Wait, I didn't agree to that. We need to hash -this out some more."</para> - -<para>For small, uncontroversial decisions, the proposal of consensus -is implicit. For example, when a developer spontaneously commits a -bugfix, the commit itself is a proposal of consensus: "I assume we all -agree that this bug needs to be fixed, and that this is the way to fix -it." Of course, the developer does not actually say that; she just -commits the fix, and the others in the project do not bother to state -their agreement, because silence is consent. If someone commits a -change that turns out <emphasis>not</emphasis> to have consensus, the -result is simply for the project to discuss the change as though it -had not already been committed. The reason this works is the topic of -the next section.</para> +<para>一个项目的大多数对话是关于技术主题的，例如如何修正bug的正确方法、是否添加某个特性、以及文档接口有多严格等等。共识为基础的管理之所以可以工作正常，是因为它无缝的混入了技术讨论当中。在一个讨论的最后，通常是确定方向的协定，某些人会创建一个结论帖，作为所作决定的总结，同时也是隐含的共识提议。这也给了某人最后一次机会说“等等，我对此并不同意，我们应该再讨论一下。”</para> + +<para>对于小的有争议的决议，这种共识的提议是隐含的。例如，当一个开发者本能的提交了一个bug修正，提交本身就是一个共识提议：“我料定我们都认可这个bug需要修正，而这就是我做的修正。”当然，开发者不会真的这么说；她只是提交修正，而项目中的其他人无需表明立场，因为沉默代表了认可。如果有人提交的结果<emphasis>没有</emphasis>导致共识，结果就是项目会象这个变更没有提交一样进行讨论，这个方法可以正常工作的原因请看下一个小节。</para> <sect2 id="version-control-relaxation"> -<title>Version Control Means You Can Relax</title> +<title>版本控制意味着你可以放轻松</title> + +<para>如果项目源代码已经纳入版本控制，这意味着大多数决定都可以轻易的取消。一个常见的情况是某人自以为提交了一个别人会喜欢的变更，但实际上并不如此。通常始于反对者对于遗漏某个预先讨论的道歉开始，当然，如果反对者在邮件列表归档中没有发现此类讨论的纪录，可以省略这一步。另一个方法是，变更是否已经提交没有理由影响我们讨论的基调。所有的变更都可以回退，至少在引入依赖的变更之前都没有问题（例如，在移除原来的变更后会破坏新代码）。版本控制系统让项目有能力收回错误或仓促判断的后果，这也释放了人们，使他们对做任何事情之前需要多少反馈可以相信自己的直觉。</para> + +<para>这也意味着达成共识的过程不需要非常正式，许多项目跟着感觉处理。小的变更可以直接引入，而无需讨论，或者只需要通过最少的讨论来点头确认。对于重要的变更，特别是有可能造成大量代码不稳定的变更，人们应当需要等待一两天才能达成共识，不应当因为某人没有足够频繁的检查邮件，而将其排斥在对话之外。 +</para> -<para>The fact that the project's source code is kept under version -control means that most decisions can be easily unmade. The most -common way this happens is that someone commits a change mistakenly -thinking everyone would be happy with it, only to be met with -objections after the fact. It is typical for such objections to start -out with an obligatory apology for having missed out on prior -discussion, though this may be omitted if the objector finds no record -of such a discussion in the mailing list archives. Either way, there -is no reason for the tone of the discussion to be different after the -change has been committed than before. Any change can be reverted, at -least until dependent changes are introduced (i.e., new code that -would break if the original change were suddenly removed). The -version control system gives the project a way to undo the effects of -bad or hasty judgement. This, in turn, frees people to trust their -instincts about how much feedback is necessary before doing -something.</para> - -<para>This also means that the process of establishing consensus need -not be very formal. Most projects handle it by feel. Minor changes -can go in with no discussion, or with minimal discussion followed by a -few nods of agreement. For more significant changes, especially ones -with the potential to destabilize a lot of code, people should wait a -day or two before assuming there is consensus, the rationale being -that no one should be marginalized in an important conversation simply -because he didn't check email frequently enough.</para> - -<para>Thus, when someone is confident he knows what needs to be done, -he should just go ahead and do it. This applies not only to software -fixes, but to web site updates, documentation changes, and anything -else unlikely to be controversial. Usually there will be only a few -instances where an action needs to be undone, and these can be handled on -a case-by-case basis. Of course, one shouldn't encourage people to be -headstrong. There is still a psychological difference between a -decision under discussion and one that has already taken effect, even -if it is technically reversible. People always feel that momentum is -allied to action, and will be slightly more reluctant to revert a -change than to prevent it in the first place. If a developer abuses -this fact by committing potentially controversial changes too quickly, -however, people can and should complain, and hold that developer to a -stricter standard until things improve.</para> +<para>因此，当某人相信他知道应该做什么，他应当继续前进和完成它。这不仅仅适用于软件修正，也可以用于网站更新、文档变更和其他任何不会引起争议的事情。通常情况下，需要进行回退操作的情况很少，应当根据实际情况处理。当然，不应当鼓励人们刚愎自用。正在讨论和已经生效的决定会造成一定的心理差异，即使它在技术上是可逆的。人们一直认为动力等同于行动，相对于回退变更，人们更情愿在开始的时候阻止它。如果开发者滥用这个事实，过于快速的提交有争议的变更，不管怎样，人们可以也必然会抱怨，会将开发者置于更严格的标准，直到事情改进。</para> </sect2> <sect2 id="voting"> -<title>When Consensus Cannot Be Reached, Vote</title> +<title>如果无法达成共识，那么投票！</title> + +<para>不可避免的，一些争论无法达成共识。当打破死锁的所有其他方法都已经失效，最后的方案就是投票。但是，在投票之前，一定要理清投票的选项。这里一切又重演了，技术讨论的正常过程会混合项目决策程序的偶然发现。此类需要投票的问题通常会很复杂，具有多方面的问题。在所有此类复杂讨论中，需要有一两个人扮演<firstterm>诚实的中间人</firstterm>的角色：定期发布各种论点的摘要，并保持对于分歧（和一致意见）核心论点的跟踪。这些摘要可以帮助每个人评估所做工作的进展，并提醒每个人还需要解决什么问题。如果需要投票，这些摘要也可以作为投票表格的原形。如果诚实中间人的任务完成的好，当时机成熟就可以发布投票的可信请求，而团队会希望使用以他们对于此问题的摘要为基础的投票表格。中间人自己也可以参与辩论；只要他们可以理解并公平的表示其他人的观点，不会因党派观点而影响以中立地态度总结辩论的状态，就没必要让他们脱离争论。</para> + +<para>投票的实际内容通常不应当是有争议的，当投票时刻到来，分歧通常会归纳为一些包含可识别的标签和简短描述的关键问题。偶尔某个开发者会反对投票本身的形式，有时候他的考虑是有道理的，例如，一个选项被遗漏了或描述的不够精确。但是还有一些时候，开发者仅仅希望避开这个投票，因为他知道投票不会得到自己期望的结果。如何处理此类蓄意阻挠可以看<phrase output="printed"><xref linkend="communications"/>的</phrase><xref linkend="difficult-people"/>。</para> + +<para>要记住指明投票系统，因为有许多不同的类型，人们很容易错误的假定使用某个步骤。大多数情况下的较好选择是<firstterm>同意投票（approval voting）</firstterm>，也就是每个投票者可以选择多个中意的选项。同意投票易于解释和统计，也不会像其他方法那样，它只有一轮投票。关于同意投票和其他投票系统的更多细节可以看<ulink +url="http://en.wikipedia.org/wiki/Voting_system#List_of_systems"/>，但是要避免陷入使用何种投票系统的长期辩论（因为，当然你会发现你陷入了使用何种投票系统选择投票系统的辩论！）。同意投票是正确选择的一个原因是任何人都很难反对—作为投票系统它足够公平。</para> -<para>Inevitably, some debates just won't consense. When all other -means of breaking a deadlock fail, the solution is to vote. But -before a vote can be taken, there must be a clear set of choices on -the ballot. Here, again, the normal process of technical discussion -blends serendipitously with the project's decision-making procedures. -The kinds of questions that come to a vote often involve complex, -multifaceted issues. In any such complex discussion, there are -usually one or two people playing the role of <firstterm>honest -broker</firstterm>: posting periodic summaries of the various -arguments and keeping track of where the core points of disagreement -(and agreement) lie. These summaries help everyone measure how much -progress has been made, and remind everyone of what issues remain to -be addressed. Those same summaries can serve as prototypes for a -ballot sheet, should a vote become necessary. If the honest brokers -have been doing their job well, they will be able to credibly call for -a vote when the time comes, and the group will be willing to use a -ballot sheet based on their summary of the issues. The brokers -themselves may be participants in the debate; it is not necessary for -them to remain above the fray, as long as they can understand and -fairly represent others' views, and not let their partisan sentiments -prevent them from summarizing the state of the debate in a neutral -fashion.</para> - -<para>The actual content of the ballot is usually not controversial. -By the time matters reach a vote, the disagreement has usually boiled -down to a few key issues, with recognizable labels and brief -descriptions. Occasionally a developer will object to the form of the -ballot itself. Sometimes his concern is legitimate, for example, -that an important choice was left off or not described accurately. -But other times a developer may be merely trying to stave off the -inevitable, perhaps knowing that the vote probably won't go his way. -See <xref linkend="difficult-people"/><phrase output="printed"> -in <xref linkend="communications"/></phrase> for how to deal with -this sort of obstructionism.</para> - -<para>Remember to specify the voting system, as there are many -different kinds, and people might make wrong assumptions about which -procedure is being used. A good choice in most cases is -<firstterm>approval voting</firstterm>, whereby each voter can vote -for as many of the choices on the ballot as he likes. Approval -voting is simple to explain and to count, and unlike some other -methods, it only involves one round of voting. See <ulink -url="http://en.wikipedia.org/wiki/Voting_system#List_of_systems"/> for -more details about approval voting and other voting systems, but try -to avoid getting into a long debate about which voting system to use -(because, of course, you will then find yourself in a debate about -which voting system to use to decide the voting system!). One reason -approval voting is a good choice is that it's very hard for anyone to -object to—it's about as fair as a voting system can be.</para> - -<para>Finally, conduct votes in public. There is no need for secrecy -or anonymity in a vote on matters that have been debated publicly -anyway. Have each participant post her votes to the project mailing -list, so that any observer can tally and check the results for -herself, and so that everything is recorded in the archives.</para> +<para>最后，公开引导投票。没有必要对公开讨论的事务进行秘密或匿名的投票，让每个参与者在项目邮件列表中发布自己的投票，这样每个观察者都可以自己检查结果，而且所有的内容都会记录到归档中。</para> </sect2> _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
