Author: rocksun Date: Mon Nov 24 11:47:09 2008 New Revision: 1573 Log: Finish chap04
Modified: trunk/zh/ch04.xml Modified: trunk/zh/ch04.xml ============================================================================== --- trunk/zh/ch04.xml (original) +++ trunk/zh/ch04.xml Mon Nov 24 11:47:09 2008 @@ -58,7 +58,7 @@ <para>随着项目的成长，通常会从慈善独裁模型转为更开放的民主系统。这不是必然由于某个BD的不满，而可以简单认为团队基础的管理更加“进化稳定”，借用一个生物学的隐喻。每当一个慈善独裁者引退，或尝试将决策责任更均匀的分配出去，这就是团队选定一个新的非独裁系统的好机会—也就是建立一个章程。团队可能错过了第一次机会、或者第二次，但是最终会这样做；一旦做了，这个决定就不太会反转过来。常识解释了原因：如果某个N位成员的团队给某个人特殊的权利，也就意味着有N - 1位成员都愿意降低自己的个人影响。人们通常不愿意这样做。即使他们这样做了，结果的独裁同志仍然是有条件的：团队推举了BD，团队也可以罢免BD。因此，一个项目的领导权一旦从某个魅力个人转移为更正式的团队为基础的系统，就很少会走回头路。</para> -<para>这类系统的工作细节有很大的区别，但是有两个共同的元素：首先，团队大多数时候在达成共识的情况下工作。其次，在无法达成共识时有一个正式的投票机制。</para> +<para>这类系统的工作细节有很大的区别，但是有两个共同的元素：首先，团队大多数时候在达成共识的情况下工作。其次，在无法达成共识时有一个正式的表决机制。</para> <para><firstterm>共识</firstterm>仅仅意味着每个人都能够接受的一种协议，它不是一种含混的状态：当有人提出某个共识已经达成，而且没有人提出反对意见，我们说一个团队对某个问题达成了共识。当然，提出共识的人应当详细说明共识的内容，如果不是显而易见的话，还要说明后续的动作。</para> @@ -79,201 +79,67 @@ </sect2> <sect2 id="voting"> -<title>如果无法达成共识，那么投票！</title> +<title>如果无法达成共识，那么表决！</title> -<para>不可避免的，一些争论无法达成共识。当打破死锁的所有其他方法都已经失效，最后的方案就是投票。但是，在投票之前，一定要理清投票的选项。这里一切又重演了，技术讨论的正常过程会混合项目决策程序的偶然发现。此类需要投票的问题通常会很复杂，具有多方面的问题。在所有此类复杂讨论中，需要有一两个人扮演<firstterm>诚实的中间人</firstterm>的角色：定期发布各种论点的摘要，并保持对于分歧（和一致意见）核心论点的跟踪。这些摘要可以帮助每个人评估所做工作的进展，并提醒每个人还需要解决什么问题。如果需要投票，这些摘要也可以作为投票表格的原形。如果诚实中间人的任务完成的好，当时机成熟就可以发布投票的可信请求，而团队会希望使用以他们对于此问题的摘要为基础的投票表格。中间人自己也可以参与辩论；只要他们可以理解并公平的表示其他人的观点，不会因党派观点而影响以中立地态度总结辩论的状态，就没必要让他们脱离争论。</para> +<para>不可避免的，一些争论无法达成共识。当打破死锁的所有其他方法都已经失效，最后的方案就是表决。但是，在表决之前，一定要理清表决的选项。这里一切又重演了，技术讨论的正常过程会混合项目决策程序的偶然发现。此类需要表决的问题通常会很复杂，具有多方面的问题。在所有此类复杂讨论中，需要有一两个人扮演<firstterm>诚实的中间人</firstterm>的角色：定期发布各种论点的摘要，并保持对于分歧（和一致意见）核心论点的跟踪。这些摘要可以帮助每个人评估所做工作的进展，并提醒每个人还需要解决什么问题。如果需要表决，这些摘要也可以作为表决表格的原形。如果诚实中间人的任务完成的好，当时机成熟就可以发布表决的可信请求，而团队会希望使用以他们对于此问题的摘要为基础的表决表格。中间人自己也可以参与辩论；只要他们可以理解并公平的表示其他人的观点，不会因党派观点而影响以中立地态度总结辩论的状态，就没必要让他们脱离争论。</para> -<para>投票的实际内容通常不应当是有争议的，当投票时刻到来，分歧通常会归纳为一些包含可识别的标签和简短描述的关键问题。偶尔某个开发者会反对投票本身的形式，有时候他的考虑是有道理的，例如，一个选项被遗漏了或描述的不够精确。但是还有一些时候，开发者仅仅希望避开这个投票，因为他知道投票不会得到自己期望的结果。如何处理此类蓄意阻挠可以看<phrase output="printed"><xref linkend="communications"/>的</phrase><xref linkend="difficult-people"/>。</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>要记住指明表决系统，因为有许多不同的类型，人们很容易错误的假定使用某个步骤。大多数情况下的较好选择是<firstterm>同意表决（approval voting）</firstterm>，也就是每个表决者可以选择多个中意的选项。同意表决易于解释和统计，也不会像其他方法那样，它只有一轮表决。关于同意表决和其他表决系统的更多细节可以看<ulink +url="http://en.wikipedia.org/wiki/Voting_system#List_of_systems"/>，但是要避免陷入使用何种表决系统的长期辩论（因为，当然你会发现你陷入了使用何种表决系统选择表决系统的辩论！）。同意表决是正确选择的一个原因是任何人都很难反对—作为表决系统它足够公平。</para> -<para>最后，公开引导投票。没有必要对公开讨论的事务进行秘密或匿名的投票，让每个参与者在项目邮件列表中发布自己的投票，这样每个观察者都可以自己检查结果，而且所有的内容都会记录到归档中。</para> +<para>最后，公开引导表决。没有必要对公开讨论的事务进行秘密或匿名的表决，让每个参与者在项目邮件列表中发布自己的表决，这样每个观察者都可以自己检查结果，而且所有的内容都会记录到归档中。</para> </sect2> <sect2 id="when-to-vote"> -<title>When To Vote</title> +<title>何时表决</title> -<para>The hardest thing about voting is determining when to do it. In -general, taking a vote should be very rare—a last resort for -when all other options have failed. Don't think of voting as a great -way to resolve debates. It isn't. It ends discussion, and thereby -ends creative thinking about the problem. As long as discussion -continues, there is the possibility that someone will come up with a -new solution everyone likes. This happens surprisingly often: a -lively debate can produce a new way of thinking about the problem, and -lead to a proposal that eventually satisfies everyone. Even when no -new proposal arises, it's still usually better to broker a compromise -than to hold a vote. After a compromise, everyone is a little bit -unhappy, whereas after a vote, some people are unhappy while others -are happy. From a political standpoint, the former sitation is -preferable: at least each person can feel he extracted a price for his -unhappiness. He may be dissatisfied, but so is everyone else.</para> - -<para>Voting's main advantage is that it finally settles a question so -everyone can move on. But it settles it by a head count, instead of -by rational dialogue leading everyone to the same conclusion. The -more experienced people are with open source projects, the less eager -I find them to be to settle questions by vote. Instead they will try -to explore previously unconsidered solutions, or compromise more -severely than they'd originally planned. Various techniques are -available to prevent a premature vote. The most obvious is simply to -say "I don't think we're ready for a vote yet," and explain why not. -Another is to ask for an informal (non-binding) show of hands. If the -response clearly tends toward one side or another, this will make some -people suddenly more willing to compromise, obviating the need for a -formal vote. But the most effective way is simply to offer a new -solution, or a new viewpoint on an old suggestion, so that people -re-engage with the issues instead of merely repeating the same -arguments.</para> - -<para>In certain rare cases, everyone may agree that all the -compromise solutions are worse than any of the non-compromise ones. -When that happens, voting is less objectionable, both because it is -more likely to lead to a superior solution and because people will not -be overly unhappy no matter how it turns out. Even then, the vote -should not be rushed. The discussion leading up to a vote is what -educates the electorate, so stopping that discussion early can lower -the quality of the result.</para> - -<para>(Note that this advice to be reluctant to call votes does not -apply to the change-inclusion voting described in -<xref linkend="stabilizing-a-release"/><phrase output="printed"> -in <xref linkend="development-cycle"/></phrase>. There, voting -is more of a communications mechanism, a means of registering one's -involvement in the change review process so that everyone can tell how -much review a given change has received.)</para> +<para>最难的事情是决定何时开始表决，通常情况下，很少会进行表决—是其他方法都失败后的补救方法。不要将表决当作解决争辩的重要方法，它不是。它可以终结讨论，也会结束关于此问题的创造性思考。只要讨论还会继续，就有可能会有人得出所有人满意的解决方案。这经常令人吃惊：活跃的争论可以产生关于问题的新方法，也会得出使每个人都满意的提议。即使没有出现新的提议，通常采纳某种妥协也比举行表决要好。经过妥协，每个人都或许会有点不高兴，但是表决过后，有些人会开心，还有些人会失望。从政治视角，前一种状态更可取：至少每个人都会感到为自己的不快萃取了一定的价值，他会不满意，但其他人也一样。</para> + +<para>表决的主要优点是最终可以解决问题，这样每个人都可以继续前进。但是通过数人头，而不是通过有理性的对话解决问题，可以让每个人得出相同的结论。开源项目中的人越有经验，就会越发现他们越不会急于用表决解决问题。相反，他们会尝试考察以前未考虑的解决方案，或者对以前计划的方法进行较大的妥协。有许多技术手段可以防止过早的表决，最明显的方法是说“我觉得还没有准备好开始表决，”然后解释为什么还不行。另一个方法是要求进行非正式（无约束力的）的举手表决。如果结果明确倾向到一边，就会让某些人立刻更希望进行妥协，以避免正式的表决。但是最有效率的方法是简单的提供一个新的方案，或者一个较早建议的新视点，所以人们可以重新审视问题，而不是简单的不断重复同样的论点。</para> + +<para>在某些很罕见的情况中，每个人都认为所有折中的解决方案都比任何一个非折中方案要差。当这种情况发生时，表决就会令人不快，不仅仅因为它能够得到一个高人一等的解决方案，而且因为人们不会对任何结果感到高兴。尽管那样，表决也不应该匆忙进行，导致表决的讨论可以教育全体选民，所以过早的结束讨论会降低结果的质量。 +</para> + +<para>（要注意前面所说的表决建议不适用于<phrase output="printed"><xref linkend="development-cycle"/>的</phrase><xref linkend="stabilizing-a-release"/>中描述的变更包含表决，此时，表决更像是一种交流机制，一种在变更评审过程注册某人参与的方法，这样每个人都可以说出对于一个变更收到了多少评审。）</para> </sect2> <sect2 id="electorate"> -<title>Who Votes?</title> +<title>谁进行表决？</title> + +<para>有了表决系统就会出现一个全民选举的问题：谁应该表决？这有可能成为敏感的问题，因为它强制项目正式识别出一些更应该参与的人，也就是比其他人更有判断力的人。</para> -<para>Having a voting system raises the question of electorate: who -gets to vote? This has the potential to be a sensitive issue, because -it forces the project to officially recognize some people as being -more involved, or as having better judgement, than others.</para> - -<para>The best solution is to simply take an existing distinction, -commit access, and attach voting privileges to it. In projects that -offer both full and partial commit access, the question of whether -partial committers can vote largely depends on the process by which -partial commit access is granted. If the project hands it out -liberally, for example as a way of maintaining many third-party -contributed tools in the repository, then it should be made clear that -partial commit access is really just about committing, not voting. -The reverse implication naturally holds as well: since full committers -<emphasis>will</emphasis> have voting privileges, they must be chosen -not only as programmers, but as members of the electorate. If someone -shows disruptive or obstructionist tendencies on the mailing list, the -group should be very cautious about making him a committer, even if -the person is technically skilled.</para> - -<para>The voting system itself should be used to choose new -committers, both full and partial. But here is one of the rare -instances where secrecy is appropriate. You can't have votes about -potential committers posted to a public mailing list, because the -candidate's feelings (and reputation) could be hurt. Instead, the -usual way is that an existing committer posts to a private mailing -list consisting only of the other committers, proposing that someone -be granted commit access. The other committers speak their minds -freely, knowing the discussion is private. Often there will be no -disagreement, and therefore no vote necessary. After waiting a few -days to make sure every committer has had a chance to respond, the -proposer mails the candidate and offers him commit access. If there -is disagreement, discussion ensues as for any other question, possibly -resulting in a vote. For this process to be open and frank, the mere -fact that the discussion is taking place at all should be secret. If -the person under consideration knew it was going on, and then were -never offered commit access, he could conclude that he had lost -the vote, and would likely feel hurt. Of course, if someone -explicitly asks for commit access, then there is no choice but to -consider the proposal and explicitly accept or reject him. If the -latter, then it should be done as politely as possible, with a clear -explanation: "We liked your patches, but haven't seen enough of them -yet," or "We appreciate all your patches, but they required -considerable adjustments before they could be applied, so we don't -feel comfortable giving you commit access yet. We hope that this will -change over time, though." Remember, what you're saying could come as -a blow, depending on the person's level of confidence. Try to see it -from their point of view as you write the mail.</para> - -<para>Because adding a new committer is more consequential than most -other one-time decisions, some projects have special requirements for -the vote. For example, they may require that the proposal receive at -least <emphasis>n</emphasis> positive votes and no negative votes, or -that a supermajority vote in favor. The exact parameters are not -important; the main idea is to get the group to be careful about -adding new committers. Similar, or even stricter, special requirements -can apply to votes to <emphasis>remove</emphasis> a committer, though -hopefully that will never be necessary. See <xref -linkend="committers"/><phrase output="printed"> in -<xref linkend="managing-volunteers"/></phrase> for more on the -non-voting aspects of adding and removing committers.</para> +<para>最好的方法是采用已存在的划分，提交访问，并为他们附加表决特权。在提供完全和部分提交访问的项目中，部分提交者是否可以表决的问题，很大程度上取决于部分提交访问被赋予的过程。 如果项目自由处理，例如，在版本库中维护许多第三方贡献工具的方法，那时就应当澄清部分提交访问只是关于提交，而不是表决。相反的暗示自然也成立：因为完全提交者<emphasis>会</emphasis>有提交特权，他们应当不仅仅是程序员，而且是全民选举的成员。如果某人在邮件列表中有分裂或破坏倾向，那么要小心将其加为提交者，即使这个人在技术上非常娴熟。</para> + +<para>表决系统本身应当用来选择新的提交者，包括完全和部分提交者。但这是一个不太常见的需要注意保密性的情况，你不能为一个潜在的提交者在公共邮件列表表决，因为不能伤害候选者的感情（和荣誉）。相反，通常的方法是某个现有的提交者在只包含提交者的私有邮件列表中发布一个私有邮件，建议给某人附加提交权限。其他提交者可以自由发表意见，他们清楚讨论是私下进行的。通常没有异议，因而没有表决的必要。在等待几天之后，确保每个提交者有机会回应之后，提议者通知候选者并赋予其提交权限。如果存在异议，因而出现其他问题的讨论，可能会导致表决。因为这个过程需要开放和坦白，所以发生讨论的事实应当完全保密。如果被考虑的人知道事情的进展，然后没有提交提交权限，他可能认为他已经在表决中失败，会感到受到伤害。当然，如果某人明确的要求提交权限，没有其他的选择，要么同意，要么拒绝。如果是后者，应当尽量的有礼貌，并使用清晰的解释：“我们喜欢你的补丁，但是还没有看到足够的补丁，”或者“我们感谢你的补丁，但是在实际使用之前需要相当大的调整，所以我们觉得现在还不能放心给你提交权限。我们希望下一次会有些改观。”请记住，你所说的会是一个打击，这要看个人的自信心水平。应当从他们的角度想想如果你看到那些邮件的感觉。</para> + +<para>因为添加新提交者不是那种一次性决定，会有后续的结果，某些项目会有表决的特殊要求。例如，他们会要求提议至少获得<emphasis>n</emphasis>个肯定的表决，而且没有否定的表决，或半数以上的赞同票。精确的参数并不重要；主要的思想是在添加提交者时需要让团队小心处理。类似的，或更严格的，特别的需求也可以应用到选举<emphasis>移除</emphasis>提交者上，尽管很希望那永远没有必要发生。关于添加和移除提交者的非表决方面的信息可以看<phrase output="printed"><xref linkend="managing-volunteers"/>的</phrase><xref +linkend="committers"/>。</para> </sect2> <sect2 id="polls"> -<title>Polls Versus Votes</title> +<title>民意调查 对 表决</title> -<para>For certain kinds of votes, it may be useful to expand the -electorate. For example, if the developers simply can't figure out -whether a given interface choice matches the way people actually use -the software, one solution is to ask to all the subscribers of the -project's mailing lists to vote. These are really -<firstterm>polls</firstterm> rather than votes, but the developers may -choose to treat the result as binding. As with any poll, be sure to -make it clear to the participants that there's a write-in option: if -someone thinks of a better option not offered in the poll questions, -her response may turn out to be the most important result of the -poll.</para> +<para>对于特定类型的表决，有时候扩展选民会很有用。例如，如果开发者只是不能确定哪种界面符合人们实际使用软件的方式，一个方法就是询问项目邮件列表中的所有人进行表决。这更应该叫做<firstterm>民意调查</firstterm>而不是表决，但是开发者可能将结果视为有约束力的。在任何民调中，要确保参与者可以附加选项：如果某人对于民调问题想到了更好的选项，她的回应会成为最重要的民调结果。 +</para> </sect2> <sect2 id="veto"> -<title>Vetoes</title> +<title>否决权</title> + +<para>某些项目允许一种特殊的表决类型，称为<firstterm>否决权</firstterm>。否决权是一种开发者停止仓促或考虑不够充分变更的方法，至少希望每个人能够再进行一些讨论。考虑到否决权介乎于强烈反对和阻挠之间，它确切的含义对于每个项目都不尽相同。有些项目让否决很难被逾越；有些则允许经过强制的更多讨论延迟后，被普通的多数投票替代。任何否决必须伴随完整的解释；任何没有这类解释的否决都应当被认为是无效的。 +</para> -<para>Some projects allow a special kind of vote known as a -<firstterm>veto</firstterm>. A veto is a way for a developer to put a -halt to a hasty or ill-considered change, at least long enough for -everyone to discuss it more. Think of a veto as somewhere between a -very strong objection and a filibuster. Its exact meaning varies from -one project to another. Some projects make it very difficult to -override a veto; others allow them to be overridden by regular -majority vote, perhaps after an enforced delay for more discussion. -Any veto should be accompanied by a thorough explanation; a veto -without such an explanation should be considered invalid on -arrival.</para> - -<para>With vetoes comes the problem of veto abuse. Sometimes -developers are too eager to raise the stakes by casting a veto, when -really all that was called for was more discussion. You can prevent -veto abuse by being very reluctant to use vetoes yourself, and by -gently calling it out when someone else uses her veto too often. If -necessary, you can also remind the group that vetoes are binding for -only as long as the group agrees they are—after all, if a -clear majority of developers wants X, then X is going to happen one -way or another. Either the vetoing developer will back down, or the -group will decide to weaken the meaning of a veto.</para> - -<para>You may see people write "-1" to express a veto. This usage -comes from the Apache Software Foundation, which has a highly -structured voting and veto process, described at <ulink -url="http://www.apache.org/foundation/voting.html"/>. The Apache -standards have spread to other projects, and you will see their -conventions used to varying degrees in a lot of places in the open -source world. Technically, "-1" does not always indicate a formal -veto even according to the Apache standards, but informally it is -usually taken to mean a veto, or at least a very strong -objection.</para> - -<para>Like votes, vetoes can apply retroactively. It's not okay to -object to a veto on the grounds that the change in question has -already been committed, or the action taken (unless it's something -irrevocable, like putting out a press release). On the other hand, a -veto that arrives weeks or months late isn't likely to be taken very -seriously, nor should it be.</para> +<para>否决权会带来对其的滥用。有时候开发者会急迫的通过否决权来为自己的论点加重砝码，而真正需要的是更多的讨论。你可以通过自己对于否决权的勉强使用来防止对于否决的滥用，并有礼貌的警告某人太过频繁的使用否决权。如果必要，你可以提醒团队，否决权只在团队也认可的时候有效—毕竟，如果很明显大多数开发者希望X，那么就应该采纳X。否决的开发者要么自己让步，要么让团队决定削弱否决权的作用。</para> + +<para>你可能会看到人们写了一个“-1”来表示否决，这种方法来自拥有高度复杂表决和否决过程的Apache软件基金会，具体内容可以看<ulink +url="http://www.apache.org/foundation/voting.html"/>。Apache标准也传播到了其他项目，你可以看到他们的习惯在开源世界的许多地方以不同的面貌出现。从技术上讲，即使根据Apache标准，“-1”也不是表示正式的否决，而只是一种表达否决或强烈反对的非正式方法。</para> + +<para>类似于表决，否决权也可以是追加的。无论有问题的变更是否已经提交，行动是否已经执行（除了一些不可挽回的事情，例如新闻发布），不应该去反对一个当场的否决。另一方面，如果否决在事情发生几周后才出现，它也不会被重视，而且这种情况根本不应该发生。</para> </sect2> @@ -281,93 +147,36 @@ <!-- ======================== SECTION ============================== --> <sect1 id="written-rules"> -<title>Writing It All Down</title> +<title>写下所有的内容</title> + +<para>有时，项目中的许多广为流传的惯例和协定变得非常重要，你需要记录下来。为了保证这种文档的正统性，要清楚的表明这些内容基于邮件列表的讨论，并已经形成协定开始生效。随着你的编写，应当引用邮件列表归档中的相关讨论，对于任何不能确定的要点，要重新询问并确认。文档中不应当包含任何出其不意的东西：它不应当是协议的来源，而只是对于协议的描述。当然，如果它足够成功，人们会开始引用它来作为自己权利的来源，但是这只是说明它精确的反映了团队的整体意愿。</para> + +<para>这是<phrase output="printed"><xref linkend="getting-started"/>的</phrase><xref +linkend="developer-guidelines"/>暗示的文档。当然，当项目还非常年轻时，你无法依靠项目的历史来规划指导方针，但是随着开发社区的成熟，你可以调整这些语言以反映实际的内容。</para> + +<para>不要尝试全面。没有文档能够涵盖参与一个项目所需的所有事情。许多项目演进出的习惯是永远不会说出来的，永远不会明确提出来，即使是所有人遵循的。还有一些内容则明显太过简单，无需提及，只会分散人们对于重要内容的注意力。例如，没有必要写下指导方针如“在邮件列表中要有礼貌，要互相尊重，不要激烈的争论”或“要写清楚的、可读的和无bug的代码。”当然，这些事情都是人们希望的，但是因为没有他们可能<emphasis>不会</emphasis>想象得到的内容，所以没有价值去提及。如果人们在邮件列表中过于粗暴，或编写了充满bug的代码，不会因为项目指导方针没有说，他们就会继续下去。这种情形出现时就会需要被处理，不会因为预先的劝诫就会好起来。另一方面，如果项目有关于<emphasis>如何</emphasis>写好代码的指导方针，例如关于使用何种格式记录API的规则，那么这个指导方针就应该尽可能的写完整。</para> -<para>At some point, the number of conventions and agreements floating -around in your project may become so great that you need to record it -somewhere. In order to give such a document legitimacy, make it clear -that it is based on mailing list discussions and on agreements already -in effect. As you compose it, refer to the relevant threads in the -mailing list archives, and whenever there's a point you're not sure -about, ask again. The document should not contain any surprises: it -is not the source of the agreements, it is merely a description of -them. Of course, if it is successful, people will start citing it as -a source of authority in itself, but that just means it reflects the -overall will of the group accurately.</para> - -<para>This is the document alluded to in <xref -linkend="developer-guidelines"/><phrase output="printed"> in -<xref linkend="getting-started"/></phrase>. Naturally, when the -project is very young, you will have to lay down guidelines without -the benefit of a long project history to draw on. But as the -development community matures, you can adjust the language to reflect -the way things actually turn out.</para> - -<para>Don't try to be comprehensive. No document can capture -everything people need to know about participating in a project. Many -of the conventions a project evolves remain forever unspoken, never -mentioned explicitly, yet adhered to by all. Other things are simply -too obvious to be mentioned, and would only distract from important -but non-obvious material. For example, there's no point writing -guidelines like "Be polite and respectful to others on the mailing -lists, and don't start flame wars," or "Write clean, readable bug-free -code." Of course these things are desirable, but since there's no -conceivable universe in which they might <emphasis>not</emphasis> be -desirable, they are not worth mentioning. If people are being rude on -the mailing list, or writing buggy code, they're not going to stop -just because the project guidelines said to. Such situations need to -be dealt with as they arise, not by blanket admonitions to be good. -On the other hand, if the project has specific guidelines about -<emphasis>how</emphasis> to write good code, such as rules about -documenting every API in a certain format, then those guidelines -should be written down as completely as possible.</para> - -<para>A good way to determine what to include is to base the document -on the questions that newcomers ask most often, and on the complaints -experienced developers make most often. This doesn't necessarily mean -it should turn into a FAQ sheet—it probably needs a more -coherent narrative structure than FAQs can offer. But it should -follow the same reality-based principle of addressing the issues that -actually arise, rather than those you anticipate might arise.</para> - -<para>If the project is a benevolent dictatorship, or has officers -endowed with special powers (president, chair, whatever), then the -document is also a good opportunity to codify succession procedures. -Sometimes this can be as simple as naming specific people as +<para>决定将什么内容纳入文档的最好方法是以新来者所经常询问的问题，以及资深开发者最经常的抱怨为基础。这不是说一定要变成一个FAQ表单—很可能需要一个比FAQ所能提供的更连贯的叙述结构。但是它必须遵循事实为根据的原理，记录问题实际发生的地址，而不是好像你预期会出现。</para> + +<para>如果项目是一个慈善独裁者所有，或者有拥有特殊权利的官员（总裁、主席或其他），那么继任程序也应当制定成法律形成文档。有时候，这仅仅是BD因故突然离开项目并简单的指定继任者。通常情况下，如果有一个BD，那么只有BD可以不必提名继任者。如果有当选的官员，必须将第一名记录到文档。如果原来没有程序，那么在编写前应该在邮件列表中达成共识。人们有时候可能对于等级结构十分敏感，所以主题应当敏感的达到这个目标。 +</para> +<!--Sometimes this can be as simple as naming specific people as replacements in case the BD suddenly leaves the project for any -reason. Generally, if there is a BD, only the BD can get away with -naming a successor. If there are elected officers, then the +reason. Generally, if there is a BD, only the BD can get away with naming a successor. If there are elected officers, then the nomination and election procedure that was used to choose them in the first place should be described in the document. If there was no procedure originally, then get consensus on a procedure on the mailing lists <emphasis>before</emphasis> writing about it. People can sometimes be touchy about hierarchical structures, so the subject -needs to be approached with sensitivity.</para> +needs to be approached with sensitivity. --> + + +<para>可能最重要的事情是表明规则是可以商量的，如果文档中规定的习惯变得束缚了项目，要让每个人想到这是一种对于团队意愿的生动反映，而不是挫折和堵塞的来源。如果某人养成了每当遇到妨碍自己的规则都要求重新考虑规则的习惯时，你不需要一直与其辩论—有时候沉默是最好的策略。如果其他人认可这种抱怨，他们会插话，也就是意味着某些事情很明显需要改变了。如果没有其他人认可，人们就不太会响应，那规则还是会保持不变。</para> -<para>Perhaps the most important thing is to make it clear that the -rules can be reconsidered. If the conventions described in the -document start to hamper the project, remind everyone that it is -supposed to be a living reflection of the group's intentions, not a -source of frustration and blockage. If someone makes a habit of -inappropriately asking for rules to be reconsidered every time the -rules get in her way, you don't always need to debate it with -her—sometimes silence is the best tactic. If other people -agree with the complaints, they'll chime in, and it will be obvious -that something needs to change. If no one else agrees, then the -person won't get much response, and the rules will stay as they -are.</para> - -<para>Two good examples of project guidelines are the Subversion -<filename>hacking.html</filename> file, at <ulink -url="http://svn.collab.net/repos/svn/trunk/www/hacking.html"/>, and the Apache -Software Foundation governance documents, at <ulink -url="http://www.apache.org/foundation/how-it-works.html"/> and <ulink -url="http://www.apache.org/foundation/voting.html"/>. The ASF is -really a collection of software projects, legally organized as a -nonprofit corporation, so its documents tend to describe governance -procedures more than development conventions. They're still worth -reading, though, because they represent the accumulated experience of -a lot of open source projects.</para> +<para>两个指导方针的好例子是Subversion的<filename>hacking.html</filename>文件，在<ulink +url="http://svn.collab.net/repos/svn/trunk/www/hacking.html"/>，以及Apache软件基金会管理的文档，在<ulink +url="http://www.apache.org/foundation/how-it-works.html"/>和<ulink +url="http://www.apache.org/foundation/voting.html"/>。ASF是真正的一组软件项目，合法的组织成一个非盈利公司，所以它的文档倾向于描述管理程序，而不是开发惯例。他们也值得阅读，因为他们代表了许多开源项目积累的经验。</para> </sect1> _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
