Author: rocksun
Date: Sun Nov 2 05:11:03 2008
New Revision: 1550
Log:
Complete chap3 review.
Modified:
trunk/zh/build.xml
trunk/zh/ch03.xml
Modified: trunk/zh/build.xml
==============================================================================
--- trunk/zh/build.xml (original)
+++ trunk/zh/build.xml Sun Nov 2 05:11:03 2008
@@ -126,7 +126,7 @@
</target>
<!--Total time: 43 seconds-->
- <target name="html" depends="html.init" unless="html.isUpToDate"
description="Generate document - html">
+ <target name="html" depends="html.init" description="Generate document -
html">
<filter token="docbook5.xsl.url" value="${docbook5.xsl.url}"/>
<copy file="stylesheets/html-import.tmpl.xsl"
tofile="stylesheets/html-import.xsl" filtering="true" overwrite="true"/>
<copy file="stylesheets/styles.css"
tofile="build/zh_CN/svnbook/styles.css" />
Modified: trunk/zh/ch03.xml
==============================================================================
--- trunk/zh/ch03.xml (original)
+++ trunk/zh/ch03.xml Sun Nov 2 05:11:03 2008
@@ -9,14 +9,13 @@
url="http://en.wikipedia.org/wiki/Brooks_Law"/>。</para></footnote>，也就是说向一个已经延期的项目增加人力，只能使项目延期更多。佛雷德.布鲁克观察到，项目的复杂性同参与人员数量的<emphasis>平方</emphasis>成正比。当项目中只有少数几个人时，大家可以容易的互相交谈。但当有上百人参与时，不可能让每个人都能知道别人正在做什么。如果说优秀的自由软件项目的管理是让每个人都感觉是在同一个屋子里共同工作，很明显问题在于：当在一间拥挤的房间内同一时间每个人都想发出声音，会发生什么？
</para>
-<para>这不是一个新问题。在现实中的拥挤房间中，解决方案是<firstterm>议会程序</firstterm>：我们需要正式的指导规则：包括如何在一个大型团队中进行即时的的讨论，如何保护重要的异议不会在一片“我也是”的回复中淹没，如何形成小组委员会，如何识别出何时作出决定。议会程序的一个重要组成部分是指明团队如何同它的信息管理系统互动，有些评论“为了被记录”而存在的，有些则不是，记录本身经常是被直接处理的，不能根据字面意义去理解，而是代表了团队已经确立达成<emphasis>共识</emphasis>。记录并非一成不变，为不同的目的会有不同的形式。它可以包括个人会议记录、每次会议的完整记录、摘要、议程及其注解、委员会报告，来自未出席通信者的报告，活动项目列表等等。
+<para>这不是一个新问题。在现实中的拥挤房间中，解决方案是<firstterm>会议程序</firstterm>：我们需要正式的指导规则：包括如何在一个大型团队中进行即时的的讨论，如何保护重要的异议不会在一片“我也是”的回复中淹没，如何形成小组委员会，如何识别出何时作出决定。会议程序的一个重要组成部分是指明团队如何同它的信息管理系统互动，有些评论“为了被记录”而存在的，有些则不是，记录本身经常是被直接处理的，不能根据字面意义去理解，而是代表了团队已经确立达成<emphasis>共识</emphasis>。记录并非一成不变，为不同的目的会有不同的形式。它可以包括个人会议记录、每次会议的完整记录、摘要、议程及其注解、委员会报告，来自未出席通信者的报告，活动项目列表等等。
</para>
-<para>因为互联网并不是一个真实的房间，所以我们也无须担心复制诸如让部分人在别人讲话时保持安静之类的议会程序。但当它和信息管理技术接合时，一个运作良好的开源项目就会是打了兴奋剂的议会程序。由于开源项目中的交流都是通过书写方式完成的，由此发展出了复杂的系统：为了恰当导向和标记数据；为了避免会造成误解的重复；为了储存和检索数据；为了纠正错误和废弃的信息；以及为了在发现不相关信息的新关系时进行关联。开源项目中的活跃参与者已经将掌握了其中的很多技术，并且经常为了确保信息被正确的导向而进行复杂的手工任务，但是所有的努力都是依赖于复杂的软件支持。交流媒体应该尽可能地依靠自身完成发送、标签和记录工作，应该确保人尽可能方便地得到这些信息。当然在实际中，在整个过程中的很多方面还是需要人的干预，并且重要之处在于软件使得这种干预也是方便的。但总得来说，如果人能确保首次进入系统时信息的导向和标签都是正确的，软件应该被配置成可以充分利用这些元数据。
+<para>因为互联网并不是一个真实的房间，所以我们也无须担心去复印诸如让部分人在别人讲话时保持安静之类的议会程序。但当它和信息管理技术接合时，一个运作良好的开源项目就会是打了兴奋剂的会议程序。由于开源项目中的交流都是通过书写方式完成的，由此发展出了复杂的系统：为了恰当导向和标记数据；为了避免会造成误解的重复；为了储存和检索数据；为了纠正错误和废弃的信息；以及为了在发现不相关信息的新关系时进行关联。开源项目中的活跃参与者已经将掌握了其中的很多技术，并且经常为了确保信息被正确的导向而进行复杂的手工任务，但是所有的努力都是依赖于复杂的软件支持。交流媒体应该尽可能地依靠自身完成发送、标签和记录工作，应该确保人尽可能方便地得到这些信息。当然在实际中，在整个过程中的很多方面还是需要人的干预，并且重要之处在于软件使得这种干预也是方便的。但总得来说，如果人能确保首次进入系统时信息的导向和标签都是正确的，软件应该被配置成可以充分利用这些元数据。
</para>
-<para>此章中的建议都是非常务实的，都是基于明确的软件和使用模式的经验。但这里不仅仅是教授实用的技术，而是通过许多小范例来演示一种总体态度，这种态度可以最大程度的促进你项目中的好的信息管理。这种态度包含了技术技巧同人力技巧的结合，并且技术技巧是关键，因为当新的需求出现时，信息管理软件总需要配置，以及一定量的持续维护和调整（例如，关于如何处理项目成长的讨论参加本章后面的<xref
linkend="bug-filtering"/><phrase output="printed"></phrase>）。人
-力技巧也是不可或缺的，因为人类社区也需要维护：如何利用这些工具的优势有时候不是立刻就很明显，在有些项目案例中甚至有冲突的习惯（例如，参见<xref
linkend="mailing-lists"/>中的关于在外发的邮件列表通告中设置<systemitem>Reply-to</systemitem>头的讨论）。应该鼓励项目相关的每一个人在正确的时间、正确的地点尽自己的职责来保持项目信息组织的良好。贡献者参与的程度越深，就越能预期她能学习更复杂和专业的技术。
+<para>此章中的建议都是非常务实的，都是基于明确的软件和使用模式的经验。但这里不仅仅是教授实用的技术，而是通过许多小范例来演示一种总体态度，这种态度可以最大程度的促进你项目中的好的信息管理。这种态度包含了技术技巧同人力技巧的结合，并且技术技巧是关键，因为当新的需求出现时，信息管理软件总需要配置，以及一定量的持续维护和调整（例如，关于如何处理项目成长的讨论参加本章后面的<xref
linkend="bug-filtering"/><phrase
output="printed"></phrase>）。人力技巧也是不可或缺的，因为人类社区也需要维护：如何利用这些工具的优势有时候不是立刻就很明显，在有些项目案例中甚至有冲突的习惯（例如，参见<xref
linkend="mailing-lists"/>中的关于在外发的邮件列表通告中设置<systemitem>Reply-to</systemitem>头的讨论）。应该鼓励项目相关的每一个人在正确的时间、正确的地点尽自己的职责来保持项目信息组织的良好。贡献者参与的程度越深，就越能预期她能学习更复杂和专业的技术。
</para>
<para>信息管理没有现成的解决方案，有着众多的不确定因素。你可能好不容易才把所有事情都按照自己的意愿完成配置，并且社区的大多数人参与进来，但随着项目的成长让某些实践不能扩展。或者本来你的项目正在稳步发展，技术基础架构也能使开发者和用户的社区关系融洽。但突然某些人出现，发明了一个全新的信息管理服务，很快新来的会质问为何你的项目不用它—例如很多在维基（参见
<ulink
url="http://en.wikipedia.org/wiki/Wiki"/>）发明之前建立的自由软件项目就正面临这一问题。很多问题需要决断，比如权衡生产信息的方便性还是消费信息的方便性？或者权衡花在配置信息管理软件上的时间与其为项目带来的益处？</para>
@@ -89,7 +88,7 @@
<sect1 id="mailing-lists">
<title>邮件列表</title>
-<para>邮件列表有如项目交流的面包和黄油。如果用户在除了网页之外的地方浏览，最有可能是项目的某一个邮件列表。不过在体验邮件列表本身之前，他们将接触邮件列表的界面—也就是加入列表的（“订阅到（subscribe
to）”）的机制，由此带出了邮件列表的#1法则：</para>
+<para>邮件列表有如项目交流的面包和黄油。如果用户在除了网页之外的地方浏览，最有可能是项目的某一个邮件列表。不过在体验邮件列表本身之前，他们将接触邮件列表的界面—也就是加入列表的（“订阅到subscribe
to”）的机制，由此带出了邮件列表的#1法则：</para>
<blockquote>
<para><emphasis>不要试图手工管理邮件列表—让软件来做。</emphasis></para>
@@ -105,7 +104,7 @@
<varlistentry><term>同时通过邮件和网页订阅</term>
<listitem>
-
<para>当一名用户订阅一个列表，她<i>应当</i>能立即收到一条表示欢迎的回复，告知她订阅了什么，下一步该如何使用邮件列表软件，并且（也是最重要的）告知如何退订。当然，这个回复还应该能被定制地加入诸如项目的站点，常见问题和回单等等项目的特定信息。</para>
+
<para>当一名用户订阅一个列表，她应当能立即收到一条表示欢迎的回复，告知她订阅了什么，下一步该如何使用邮件列表软件，并且（也是最重要的）告知如何退订。当然，这个回复还应该能被定制地加入诸如项目的站点，常见问题和回答等项目的特定信息。</para>
</listitem>
</varlistentry>
@@ -117,7 +116,7 @@
<varlistentry><term>审核特性</term>
<listitem>
-
<para>在邮件发送到整个列表之前的“审核”是检查邮件以确保：a) 不是 垃圾邮件，以及b) 符合 主题。审核必须有人参与，但软件能很大程度的使之变得容易。后面还有关于审核的更多内容。</para>
+
<para>在邮件发送到整个列表之前的“审核”是检查邮件以确保：a) 不是垃圾邮件，以及b) 符合主题。审核必须有人参与，但软件能很大程度的使之变得容易。后面还有关于审核的更多内容。</para>
</listitem>
</varlistentry>
@@ -199,13 +198,13 @@
<para><literal>[EMAIL PROTECTED]</literal></para>
</blockquote>
-<para>with</para>
+<para>为</para>
<blockquote>
<para><literal>jrandom_AT_somedomain.com</literal></para>
</blockquote>
-<para>or</para>
+<para>或者</para>
<blockquote>
<para><literal>[EMAIL PROTECTED]</literal></para>
@@ -316,13 +315,13 @@
<itemizedlist>
<listitem>
- <para><emphasis role="bold">勿动eply-to</emphasis>,
+ <para><emphasis role="bold">勿动eply-to</emphasis>，
<emphasis>Chip Rosenthal</emphasis></para>
<para><ulink
url="http://www.unicom.com/pw/reply-to-harmful.html"/></para>
</listitem>
<listitem>
- <para><emphasis role="bold">把Reply-to设置为列表地址</emphasis>,
+ <para><emphasis role="bold">把Reply-to设置为列表地址</emphasis>，
<emphasis>Simon Hill</emphasis></para>
<para><ulink
url="http://www.metasystema.net/essays/reply-to.mhtml"/></para>
@@ -355,11 +354,11 @@
<varlistentry><term>立刻更新</term>
<listitem>
-
<para>人们经常会参考在上个小时所做的归档发表，如果可能，归档器必须能够立刻归档每个发布，这样发表出现在邮件列表时，它也就出现在了归档中。如果没有这个特性，至少应该将其设置为每小时更新一次。（缺省情况下，一些归档器会每夜更新，对于一个活跃的邮件列表这有点太滞后了。）</para>
+
<para>人们经常会引用在上个小时所做的发布归档，如果可能，归档器必须能够立刻归档每个发布，这样发布出现在邮件列表时，它也就出现在了归档中。如果没有这个特性，至少应该将其设置为每小时更新一次。（缺省情况下，一些归档器会每夜更新，对于一个活跃的邮件列表这有点太滞后了。）</para>
</listitem>
</varlistentry>
- <varlistentry><term>参考稳定性</term>
+ <varlistentry><term>引用稳定性</term>
<listitem>
<para>一旦一个信息已经归档到特定URL，它应该在相同的可访问URL，并尽可能的永远保持。即使归档重建，从备份中恢复，或者其他修正，任何已经公开的URL应该保持相同。稳定引用可以让Internet上的搜索引擎能够索引归档，可以方便用户查找答案，稳定引用也非常重要，因为邮件列表经常会被bug跟踪（见<phrase
output="printed">本章后面的</phrase><xref
linkend="bug-tracker"/>）或其他项目文档中引用。</para>
@@ -466,7 +465,7 @@
<para>一个<firstterm>版本控制系统</firstterm>（或<firstterm>修订控制系统</firstterm>）是跟踪和控制项目文件变更的技术与实践的组合，包括源代码、文档和网页。如果你以前从来没有使用过版本控制，那你最好赶快找一个有经验的人加入。现今，所有的人都希望你的项目源代码存放在版本控制下，如果不使用版本控制，人们将会轻视项目。</para>
-<para>版本控制如此广泛的原因是因为它实际上能帮助运营一个项目的所有方面：内部开发者交流、发布管理、缺陷管理、代码稳定性和试验开发投入，以及对某个变更所属开发者的归因和授权。版本控制系统为这些领域提供了一个集中的协调力量。版本控制的核心是<firstterm>变更管理</firstterm>：识别对项目文件的每一个不相关的变更，使用元数据例如变更的日期和作者来注解每个变更，然后在无论使用什么方法，任何人询问时，重放这个事实。这是变更是信息的基本单元的交流机制。</para>
+<para>版本控制如此广泛的原因是因为它实际上能帮助运营一个项目的所有方面：内部开发者交流、发布管理、缺陷管理、代码稳定性和试验开发投入，以及对某个变更所属开发者的归因和授权。版本控制系统为这些领域提供了一个集中的协调力量。版本控制的核心是<firstterm>变更管理</firstterm>：识别对项目文件的每一个不相关的变更，使用元数据例如变更的日期和作者来注解每个变更，之后无论使用什么方法，任何人询问时，重放这个事实。这是变更是信息的基本单元的交流机制。</para>
<para>这个部分不会讨论使用版本控制的所有方面，它是如此包罗万象，我们不得在本书不时不时的提及。因此，我们会通过促进协作开发的方式，专注于版本控制系统的选择和设置。</para>
@@ -613,7 +612,7 @@
<para>可浏览性非常重要，因为它是一个轻量级的项目数据门户，如果不能通过web浏览版本库，那一个人如果希望检查特定的文件（例如，看一下某个bug修正是否已经进入代码），他必须在本地安装版本控制客户端，这会让一项只需要两分钟的任务变成一项半小时或更长的任务。</para>
-<para>可浏览性也暗示了浏览文件特定修订版本的标准URL，以及任意给定时间最近的修订。在技术讨论或向人们指明作为证据时这非常有用。例如我们不会说“关于调试服务器的提示，可以看你工作拷贝中的www/hacking.html”，而会说“关于调试服务器的提示，可以看<emphasis>http://svn.collab.net/repos/svn/trunk/www/hacking.html</emphasis>，”，给定一个会一直指向<filename>hacking.html</filename>最新修订的URL。URL会更好，因为它不会导致混淆，也避免了地址是否有最新工作拷贝的问题。</para>
+<para>可浏览性也暗示了浏览文件特定修订版本的标准URL，以及任意给定时间最近的修订。在技术讨论或向人们指明作为证据时这非常有用。例如我们不会说“关于调试服务器的提示，可以看你工作拷贝中的www/hacking.html”，而会说“关于调试服务器的提示，可以看<emphasis>http://svn.collab.net/repos/svn/trunk/www/hacking.html</emphasis>，”，给定一个会一直指向<filename>hacking.html</filename>最新修订的URL会更好，因为它不会导致混淆，也避免了用户是否有最新工作拷贝的问题。</para>
<para>一些版本控制系统包含内置的版本库浏览机制，而其他一些依赖于第三方的工具实现。这类工具有<firstterm>ViewCVS</firstterm>（<ulink
url="http://viewcvs.sourceforge.net/"/>）、<firstterm>CVSWeb</firstterm>（<ulink
@@ -680,7 +679,7 @@
</sect3>
<sect3 id="vc-singularity">
-<title>信息单一</title>
+<title>信息单一性</title>
<para>合并有一个推论：不要对同一个变更提交两次，也就是一个修改只进入一次版本控制系统。变更的修订（或一组修订）可以在其进入版本控制系统之后唯一标示。如果它需要应用到还没有应用过的分支，那么它应该从最初的入口点合并到其他目标—而不是直接提交相同的文本，这样虽然对代码的效果是一样的，但会导致我们无法进行精确的记录和发布管理。</para>
@@ -690,7 +689,7 @@
<para>同样的原理也适用于撤销一个变更，如果一个变更从代码中撤销，那么这个撤销的日志信息也应该仅仅是指明撤销的是哪些特定的修订版本，而<emphasis>不是</emphasis>描述撤销过程中实际变更的代码，因为变更的内容可以通过阅读原来的日志信息和修订获得。当然，修订版本日志信息也应当说明恢复变更的原因，但它不应该从原始变更日志信息复制任何东西。如果可能，回到原来的变更日志信息，并指明它已经撤销了。</para>
-<para>前面所说的都暗示了你应该使用一致的语法来引用这些修订版本，这不仅仅在日志信息中有益，在邮件、bug跟踪和其他地方也同样重要。如果你使用CVS，我建议“<literal>path/to/file/in/project/tree:REV</literal>”，其中的REV就是CVS的修订版本好吗，例如“1.76”。如果你使用Subversion，修订版本1729的标准语法是“r1729”（文件路径不是必需的，因为Subversion使用全局修订版本号）。在其他系统中，也都有一些表达变更集的标准语法，无论对你的系统什么是合适的语法，鼓励人们使用它们来饮用变更。对变更名一致的表达方法可以帮助项目更简单的纪录（在<xref
linkend="communications"/>和<xref
linkend="development-cycle"/>我们将会看到），而且因为许多纪录是由志愿者完成的，它应该尽可能的简单。</para>
+<para>前面所说的都暗示了你应该使用一致的语法来引用这些修订版本，这不仅仅在日志信息中有益，在邮件、bug跟踪和其他地方也同样重要。如果你使用CVS，我建议“<literal>path/to/file/in/project/tree:REV</literal>”，其中的REV就是CVS的修订版本好吗，例如“1.76”。如果你使用Subversion，修订版本1729的标准语法是“r1729”（文件路径不是必需的，因为Subversion使用全局修订版本号）。在其他系统中，也都有一些表达变更集的标准语法，无论对你的系统什么是合适的语法，鼓励人们使用它们来引用变更。对变更名一致的表达方法可以帮助项目更简单的纪录（在<xref
linkend="communications"/>和<xref
linkend="development-cycle"/>我们将会看到），而且因为许多纪录是由志愿者完成的，它应该尽可能的简单。</para>
<para>在<phrase
output="printed"><xref linkend="development-cycle"/>的</phrase><xref
@@ -718,7 +717,7 @@
<para>归纳起来，不要在版本控制的授权系统上花费太多时间，除非你有特别的原因，复杂的授权系统不能带来实际的好处，依赖人为控制有更多的优点。</para>
-<para>当然，上面所说的并不意味着限制本身不重要，项目不应该鼓励人们在不够格的地方提交。此外，在很多项目中，完全（无限制）的提交访问有一个特别的状态：它隐含了项目范围
问题的投票权。提交访问的政治方面将会在<phrase output="printed"><xref
linkend="social-infrastructure"/>的</phrase><xref
+<para>当然，上面所说的并不意味着限制本身不重要，项目不应该鼓励人们在不够格的地方提交。此外，在很多项目中，完全（无限制）的提交访问有一个特别的状态：它隐含了项目范围问题的投票权。提交访问的政治方面将会在<phrase
output="printed"><xref linkend="social-infrastructure"/>的</phrase><xref
linkend="electorate"/>详细讨论。</para>
</sect3>
@@ -781,7 +780,7 @@
<para>除了这些情况，不同的跟踪软件也有一些其它小的生命周期细节，但基本的生命周期是相同的，生命周期本身并不特定于开源软件，这暗示了开源项目如何使用他们的bug跟踪系统。</para>
-<para>就像步骤1暗示的，跟踪系统和邮件列表或网页一样，是项目的门面。任何人可以发起一个问题，任何人可以浏览当前打开的问题列表。由此我们也能推断我们无法知道有多少人在等待给定问题的进展，而开发社区的规模和技巧限制了问题解决得速率，项目至少应该知道每个出现的问题。即使问题会缓慢小时，一个回复也会鼓励报告者保持参与，因为她能感觉到有人已经为其所作的事情登记（请牢记填写一份问题远比发一封邮件更麻烦）。此外，一旦开发者看到一个问题，它就进入了项目的意识中
，也就是开发者会查看此问题的类似情况，或者会与其他开发者讨论，等等。</para>
+<para>就像步骤1暗示的，跟踪系统和邮件列表或网页一样，是项目的门面。任何人可以发起一个问题，任何人可以浏览当前打开的问题列表。由此我们也能推断我们无法知道有多少人在等待给定问题的进展，而开发社区的规模和技巧限制了问题解决的速率，项目至少应该知道每个出现的问题。即使问题会缓慢小时，一个回复也会鼓励报告者保持参与，因为她能感觉到有人已经为其所作的事情登记（请牢记填写一份问题远比发一封邮件更麻烦）。此外，一旦开发者看到一个问题，它就进入了项目的意识中
，也就是开发者会查看此问题的类似情况，或者会与其他开发者讨论，等等。</para>
<para>及时反应的需求意味着两件事：
@@ -818,7 +817,7 @@
<para>第一种技术看起来被广泛使用，即使项目有巨大的问题数据库（例如，Debian在<ulink
url="http://bugs.debian.org/"/>的bug跟踪系统，目前有315,929个问题）也是这样安排的，这样<emphasis>某人</emphasis>进入时就能看到所有的问题，不同的问题类别可能是不同的人。例如，Debian项目包含了一组软件包，这样Debian就能够自动路由每个问题到合适的包维护者。当然，用户有时会把问题类别搞错，这样一开始问题就会发送到错误的人，而他可以再将其转向到其他人。然而，最重要的事情是负担被分担了—无论用户在填写的时候是对是错，问题监视的任务还是会在开发者之间分配，所以每个问题都能够得到及时的回复。</para>
-<para>第二种技术应用的没有那么广泛，可能因为它很难被自动化。本质思想是每个新问题都是经过搭档处理后进入到的数据库中。当用户认为他发现了一个问题，他就会被要求在邮件列表或IRC频道中对其进行描述，然后得到某个人对其是bug确认，尽早引入第二双眼睛可以防止许多虚假的报告。有时候第二方可以识别出这个行为不是一个bug，或者已经在最近的发布中被修正。或者她可能由于类似症状bug而感到熟悉，而且可以通过给用户指明老的问题来防止重复的填写。通常仅仅是询问用户“你查找过bug跟踪系统以确定这个问题是否已经报告过了？”许多用户不会想到这个一点，如果有人<emphasis>期望</emphasis>，你可以愉快的为他们查找一下。</para>
+<para>第二种技术应用的没有那么广泛，可能因为它很难被自动化。本质思想是每个新问题都是经过伙伴处理后进入到的数据库中。当用户认为他发现了一个问题，他就会被要求在邮件列表或IRC频道中对其进行描述，然后得到某个人对其是bug确认，尽早引入第二双眼睛可以防止许多虚假的报告。有时候第二方可以识别出这个行为不是一个bug，或者已经在最近的发布中被修正。或者她可能由于类似症状bug而感到熟悉，而且可以通过给用户指明老的问题来防止重复的填写。通常仅仅是询问用户“你查找过bug跟踪系统以确定这个问题是否已经报告过了？”许多用户不会想到这个一点，如果有人<emphasis>期望</emphasis>，你可以愉快的为他们查找一下。</para>
<para>这种伙伴系统确实可以保证问题数据库的清洁，但是也有一些不利的地方。许多用户无论如何也要独立发起问题，对为发起新问题而寻找伙伴的指南看不到或者视而不见。因此，还是需要有志愿者关注问题数据库。此外，因为许多新报告者不理解维护问题数据库的难度，对他们忽略指南的行为进行过于严厉的斥责是不公平的。所以志愿者必须保持警觉，联系如何反弹未经搭档处理的问题给报告者。目标是训练每个报告者在未来使用伙伴系统，这样就有一个日益增长的能够理解问题过滤系统的用户池。当看到一个未经伙伴系统处理的问题时，理想的步骤是：</para>
@@ -836,9 +835,7 @@
<para>请记住尽管系统会逐渐改善问题数据库的信/噪比，但是不会阻止误填的发生。完全防止误填的唯一方法是关闭bug跟踪系统，只开放给开发者—治愈几乎永远比疾病本身更坏。应当接受无效问题的清理是项目日常维护的一部分，并努力得到更多的人们来帮忙。</para>
-<para>See also
-<xref linkend="issue-manager"/><phrase output="printed"> in
-<xref linkend="managing-volunteers"/></phrase>.</para>
+<para>还可以看<phrase output="printed"><xref
linkend="managing-volunteers"/>的</phrase><xref linkend="issue-manager"/>。</para>
</sect2>
@@ -849,7 +846,7 @@
<title>IRC / 实时聊天系统</title>
<para>许多项目使用<firstterm>互联网多线交谈</firstterm>（<firstterm>IRC</firstterm>）提供实时聊天室，作为用户和开发者互相提问并得到及时答复的讨论场所。即使你<emphasis>可以</emphasis>在你的服务器运行IRC服务器时，也不必为此事麻烦。而应该象其他人一样：在Freenode（<ulink
url="http://freenode.net/"/>）运行你的IRC频道。Freenode给了你足够的权利来管理你项目的IRC频道，<footnote>
-<para>没有要求或期望你能够为Freenode捐献，但是如果你或你的项目能够负担，请考虑贡献一下。他们在美国有一个免税的慈善团体，提供有价值的服务
+<para>没有要求或期望你能够为Freenode捐献，但是如果你或你的项目能够负担，请考虑贡献一下。他们在美国有一个免税的慈善团体，提供有价值的服务。
</para></footnote>可以让你摆脱维护IRC服务器这类无意义的麻烦。</para>
<para>首先要选择一个频道名称，最明显选择是你的项目名—如果在Freenode存在的话，就使用它。如果不存在，可以选择一个与项目名接近的名称，尽可能的易于记忆。在你的项目网站上将频道广而告之，这样期望快速提问的访问者可以立刻看到它，例如，Subversion主页上显著放置的方框中所出现的：</para>
@@ -867,7 +864,7 @@
</blockquote>
<para>一些项目有多个频道，每个子主题一个。例如，一个频道关注安装问题，另一个是使用问题，还有一个是开发聊天，等等。（<phrase
output="printed"><xref linkend="communications"/>的</phrase><xref
-linkend="growth"/>讨论了如何划分多个频道）。当你的项目海年轻时，应该只有一个频道，所有人在一起讨论，之后，随着用户到开发者比率增加，也就有必要分开单独的频道。
+linkend="growth"/>讨论了如何划分多个频道）。当你的项目还年轻时，应该只有一个频道，所有人在一起讨论，之后，随着用户到开发者比率增加，也就有必要分开单独的频道。
</para>
<para>人们如何知道所有的已有频道，以及在哪个频道讨论？他们何时交谈，如何知道当地的习惯？</para>
@@ -939,7 +936,7 @@
<sect2 id="irc-archiving">
<title>归档IRC</title>
-<para>尽管可以将IRC频道发生的任何事情都归档，但这不是必要的。IRC对话名以上是公开的，但是许多用户认为这是非正式的，半私人的对话，用户会对语法不是很在意，而且经常会表达意见（例如，关于其它软件或其他程序员），这些都不是他们希望永久保存归档的。</para>
+<para>尽管可以将IRC频道发生的任何事情都归档，但这不是必要的。IRC对话名义上是公开的，但是许多用户认为这是非正式的，半私人的对话，用户会对语法不是很在意，而且经常会表达意见（例如，关于其它软件或其他程序员），这些都不是他们希望永久保存归档的。</para>
<para>当然，有时候<emphasis>摘要</emphasis>必须能够保存，大多数IRC客户端可以在用户要求的情况下记录对话到一个文件，如果不能，人们也可以仅仅是将对华拷贝和粘贴到固定的论坛（经常是bug跟踪系统）中。但是不加区分的归档所有内容会让某些用户不悦，如果你需要归档所有的事情，请确认你已经在频道主题明确说明，并给出了归档的URL。</para>
@@ -971,14 +968,7 @@
</listitem>
</itemizedlist>
-<para>The common solution to all these problems is the same: have
-editorial standards, and demonstrate them not only by posting them,
-but by editing pages to adhere to them. In general, wikis will
-amplify any failings in their original material, since contributors
-imitate whatever patterns they see in front of them. Don't just
-set up the wiki and hope everything falls into place. You must also
-prime it with well-written content, so people have a template to
-follow.</para>
+<para>对所有这些问题的一般解决办法完全相同：有编辑标准，不仅仅是发表出来，而且要让编辑页包含它。通常情况下，wikis会放大原始材料中的所有缺陷，因为撰稿者会模仿任何眼前的模式。不要期望设置了wikis就会发现所有的事情来到恰当的位置，你还需要编写好好的例子，这样人们可以将其作为遵从的模板。</para>
<para>一个运行良好的闪耀例子是维基百科，尽管可能是部分因为它的内容（百科条目）本身就符合wiki的格式，但是如果你深入维基百科，你会发现管理员放置了对于合作<emphasis>非常</emphasis>完整的基础。有关于如何编写新条目，如何维护合适的视角，做何种编辑，避免怎样的编辑，争议编辑解决过程（涉及许多步骤，包含最终的裁决）等问题的大量文档。他们也有授权控制，这样如果某个页面是重复不合适编辑的结果，他们会锁定它，直到问题解决。换句话说，他们不仅是在网站上抛出了几个模板就希望坐享其成。维基百科能够成功是因为它的创建者仔细思考过如何让几千陌生人调整他们的写作来实现共同的梦想。虽然对于自由软件项目，你可能不需要同样级别的准备，但是其精神值得模仿。</para>
@@ -1014,9 +1004,9 @@
<title>选择一个包装站点</title>
<para>最大最著名的主机站点是<ulink
-url="http://www.sourceforge.net/";>SourceForge</ulink>，两个站点提供的相同或类似的服务<ulink
+url="http://www.sourceforge.net/";>SourceForge</ulink>，<ulink
url="http://savannah.gnu.org/";>savannah.gnu.org</ulink>和<ulink
-url="http://www.berlios.de/";>BerliOS.de</ulink>。一些组织，例如<ulink
url="http://www.apache.org/";>Apache Software
+url="http://www.berlios.de/";>BerliOS.de</ulink>这两个站点提供了相同或类似的服务。一些组织，例如<ulink
url="http://www.apache.org/";>Apache Software
Foundation</ulink>和<ulink
url="http://www.tigris.org/";>Tigris.org</ulink><footnote><para>免责生命：我由<ulink
url="http://www.collab.net/";>CollabNet</ulink>雇佣，它是Tigris.org的赞助商，我经常会用Tigris。</para></footnote>也会为开源项目提供免费主机，但要符合他们的目标和他们社区已有的项目。</para>
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
