在一个接收许多补丁的自由软件项目，跟踪到达的补丁以及所做的决定会成为一场噩梦，特别当通过非集中方式完成时。大多数补丁是以邮件的形式出现在项目开发列表（尽管可能有些最早出现在问题跟踪系统，或外部站点）的，在补丁到达时有许多不同的处理补丁的例程可以选择。

有时，某人评审了补丁，发现了问题，然后踢回给原作者整理。这通常会导致一个交互过程—都在邮件列表中可见—原始的作者一直发布修正的补丁版本，直到评审者无法找到更多的问题。有时很难说清楚这个过程已经结束：如果评审者提交了补丁，则可以说整个周期已经结束。但是如果她没有，或许仅仅因为她没有时间，或者没有提交权限，而且无法拉其他开发者做这件事。

另一个对补丁的常见回应是轻快的讨论，不必是针对补丁本身，而是关于补丁之后的概念。例如，补丁可能修正了一个bug，但项目希望用另一种方式修正这个bug，作为解决一个更普通类型问题的一部分。通常一开始这都是未知的，只是补丁激发了探索。

偶然情况下，发布的补丁可能会遇到完全的沉默。通常是因为没有开发者有时间在那个时刻去评审这个补丁，都希望其他人能去做这件事。因为每个人等待其他人捡起这个球的时间并不一定，而其他优先的事情不断出现，很容易会造成补丁被漏掉的情况，但这是任何人都不会希望发生的事情。项目可能以这种方式错误可用的的补丁，也有其他有害的副作用：会打击作者，他为补丁做了许多工作，让他觉得整个项目难以靠近，特别是对于其他考虑编写补丁的人。

补丁管理员的工作就是确保补丁不会漏掉。这是通过跟踪每个补丁的稳定状态实现的。补丁管理员观察邮件列表中每个由提出补丁引发的线索。如果最终以补丁的提交完成，他不需要做任何事。如果进入了评审/修正迭代，以补丁的最终版本结束，但是没有提交，他发起一个指向最终版本以及相关邮件列表的问题，这样之后跟进的所有开发者都有了一个永久的记录。如果补丁定位了一个现有的问题，他会将相关信息注释到该问题，而不会开一个新事物。

如果某个补丁没有回应，补丁管理员应该等待几天，然后询问是否有人会去评审它。通常会有响应：某个开发者会解释她认为该补丁不必应用，然后给出原因，或者她会去评审它，。如果还是没有回应，补丁管理员可以发起，也可以不发起一个补丁的问题，要根据他自己的判断，但至少最初的提交者得到了一些回应。

拥有一个补丁管理员为Subversion开发团队节省了大量时间和心力。如果没有指定的人负责，每个开发者需要一直担心“如果我没有时间现在回应补丁，我能指望别人做吗？我是否要一直盯着？ 但如果有别人盯着，同样的原因，这样是否是没必要的重复。” 每个开发者在第一次看到这个补丁的时候都要做这样的决定。如果她希望跟进评审，她就可以这样做—补丁管理员会根据情况调整他的行为方式。如果她希望完全忽略这个补丁，也没问题；补丁管理员会确保它没有被遗忘。

因为这个系统只有在补丁管理员不发生失误的情况下才能运作正常，所以这个角色必须正式任命。在Subversion，我们在开发和用户邮件列表中广而告之，得到了许多志愿者，并选了第一个回复的。当那个人请辞后（本章后面的the section called “转化”），我们重复了这个步骤。我们一直没有试图让多个人分担这个角色，因为他们之间会需要交流的负担；但是如果补丁提交的规模更大，则一个多头的补丁管理员就会有意义。

在软件项目中，“翻译”可能指的是两件完全不同的事。它可能指的是将软件文档翻译为其他语言，或者指的是翻译软件本身—也就是让程序使用用户选中的语言显示错误和帮助信息。两者都是复杂的任务，不过一旦建立了正确的基础架构，则可以很大程度上与其他开发分离。因为这些任务非常类似，所以设置一个单独的翻译管理员处理两部分任务就非常有意义（取决于你的项目），亦或者更好的方式是设置两个不同的管理员。

在Subversion项目，我们有一个处理两部分的翻译管理员。他自己并不编写翻译，当然—他可以帮助一两个，但是在写这些话时，如果他希望与他们所有人一起工作，他需要讲10种语言（12种方言）。因而，他管理志愿翻译者：他帮助他们互相协调，以及他们团队与项目其余部分的协调。

设置翻译管理员的一个原因是翻译者是与开发者不同的人。他们有时只有有限的甚至没有任何在版本控制版本库中工作的经验，也没有与分布式志愿团队一起工作的经验。但在另一方面，他们通常是最好的一类志愿者：拥有特定领域知识，可以看到需求，选择参与进来。他们也通常愿意学习，对工作充满热情。所需要只是有人告诉他们如何做。翻译管理员确保翻译不会没必要的干扰日常的开发。每当开发者必须被告知需要为支持翻译工作提供技术变更时，他也要作为翻译者作为一个统一整体的代表。

因此，这个位置最重要的技能是外交能力，而不是技术能力。例如，在Subversion我们有一个政策，每种语言的翻译都必须至少有两个人正在参与，否则，就没有人可以检查文本。譬如说，有新的志愿者请求提供Subversion马达加斯加语翻译时，翻译管理员必须提示他去与六个月前某个表达过马达加斯加语翻译意向的人建立联系，或者有礼貌的询问志愿者去寻找另一个马达加斯加翻译者与其搭档工作。当有了足够的人手，管理员就可以为他们设置正确的提交访问权限，告知他们项目的惯例（例如如何编写日志文件），然后紧盯他们是否遵循了这些惯例。

翻译管理员和开发者之间，以及翻译管理和翻译团队之间的对话通常使用项目原先的语言—也就是所以翻译的源语言。对于大多数自由软件项目，就是英语，但是是什么语言并不重要，只要项目认可即可。（对于希望吸引广泛国际开发社区的项目，英语可能是最好的语言。）

在特定翻译小组中的对话通常使用它们共享的语言，然而翻译管理员的另一个任务就是为了每个团队设定一个专门的邮件列表。通过这种方式，翻译者可以自由的讨论他们的工作，而不会打扰项目邮件列表中的人，他们可能根本不理解他们的翻译语言。

保持软件文档的实效性是一项无法结束的任务。每个进入代码的新特性或改进都可能会导致文档的变更。另外，一旦项目文档达到了一定级别的完整性，就会发现许多人发来的补丁是针对文档的，而不是代码。这是因为许多人是在文章中修正了bug，而不是在代码中：所有的用户都是读者，但仅有少数是程序员。

文档补丁通常比代码补丁更易于检查和应用。仅需要少许或无需测试，而且可以快速的通过检查评价变更的质量。因为数量很多，但是检查的负担相对较低，文档补丁中有效工作的管理负担比率远比代码补丁高。此外，大多数补丁需要一些调整，才能保持文档中作者语气的一致性。在大多数情况下，补丁通常会覆盖或影响其他补丁，在提交之前需要根据之间的关系进行调整。

出于处理文档补丁的紧迫性，以及需要持续监控代码基以便保持文档的实效性，有必要让某个人或一个小组专门从事这项任务。他们需要精确的保存文档在何处滞后于软件的记录，而且他们可以用一种整体方式的实践步骤来处理大量的补丁。

当然，这样不会阻碍项目中的其他人在工作中应用文档补丁，特别是时间允许时一些小的补丁。同一个补丁管理员（见本章前面提到的the section called “补丁管理员”）可以同时跟踪代码和文档补丁，当开发和文档团队希望时完成它们。（如果补丁的总数已经超出了单个人可以跟踪的容量，最好的一个步骤可能就是将补丁管理员分为代码和文档。）文档团队的关键是使人们把保持文档组织性、实效性和一致性当作自己的责任。在实践中，这意味着对于文档的熟悉，关注其他人提交给文档的变更，关注到来的文档补丁，并使用所有这些信息源完成保持文档健康的所有必要工作。

项目bug跟踪系统中问题的数量是随着使用产品的人数同比例增加的。因而，即使你在一个快速成长的健壮程序中修正bug并装运，您还是会看到大量开放的问题漫无边际的产生。重复问题，以及不完整或描述糟糕的问题也会频繁发生。

问题管理员通过关注进入数据库的信息，定期的清除特定问题有助于缓和这种问题。他们的大多数常见行为可以修正进入的问题，一方面因为报告者未能正确的处理部分字段，另一方面也因为问题与数据库中的一个问题已经重复。很明显，问题管理员对项目bug数据库越熟悉，他就越能有效率的检测到重复问题—这也是设置一小部分人专门关注bug数据库，而不是让每个人都特别参与其中的原因。当团队试图按照非集中式的方式完成这项任务时，就不会有任何一个人具备对于数据库内容的深入专业知识。

问题管理员可以帮助我们映射问题和个别开发者。当有大量bug报告进入时，不是每个开发者会以平等的态度读取问题通知邮件列表。然而，如果某人知道开发团队紧盯着所有进入的问题，她可以将注意力放到特定合适的bug上。当然，这需要对项目所有开发的事情，接受者期望和性情都很敏感。因而，问题管理员最好也是开发者的一分子。

取决于你的项目如何使用问题跟踪系统，问题管理员也可以调整该数据库以反映项目的优先级。例如，在Subversion我们将问题排入未来的特定发布，这样每当有人询问“某个bug X何时可以修复时？”我们可以说“之后的两个发布，”即使我们不能说出确切的日期。这个发布在问题跟踪系统中以目标里程碑的形式展示，也就是IssueZilla中的一个字段。^[27]作为一个规则，每个Subversion发布都有一个新的特性和一组特定的bug修正。我们为该发布的所有问题赋予一个合适的目标里程碑（包括新特性—它也会得到一个问题），这样人们就可以通过发布计划查看bug数据库。这些目标很少情况下会保持静止。随着新bug的到来，等级会发生切换，而且有些bug必须移到另一个里程碑，以保证每个发布的可管理性。再次，最好由对项目数据库的内容以及问题之间的关系有着整体意识的人完成。

问题管理员的另一项值得关注的任务是管理废弃的问题。有时，某个bug会因为软件一个不相关变更而意外的修正，或者有时项目对于特定行为是否为bug的意见发生改变。寻找废弃的问题并不简单：唯一的系统方法是清理数据库中的所有问题。随着问题数量的增长，完全的清理会变得越来越不可行。在达到某个点时，保持数据库健康的唯一方法就是分而治之：根据进入数据库的情况将问题分类，并直接分配给合适的开发者或团队。然后接受者负责问题余下的工作，根据需要决定是解决还是废弃。如果数据库足够大，问题管理员的工作就更倾向于协调，将会花费较少的时间用于自己查找问题，而是花更多的时间使之到达正确的人手中。

FAQ维护是一项出人意料的困难工作。项目中其他文档的内容都是由作者预先计划得到的，而FAQ则完全是被动的文档（见维护FAQ）。无论它变得如何巨大，你永远不知道何时会再一次添加。而且因为它总是零零散散的添加，它很容易变得不够一致并缺乏组织，甚至会包含重复的或半重复的条目。即使它没有任何此类的明显问题，项目之间也通常会有不引人注目的互相依赖—必须有链接，但是没有—因为与关联的项目添加的时间相差一年。

FAQ管理员的角色是双重的。首先，通过至少对所有问题的标题保持熟悉，她维护了FAQ的整体质量，这样每当有人添加的新条目与原来的条目重复或者相关，可以作出合适的调整。其次，她关注着项目的邮件列表和其他论坛中重复发生的问题或疑问，并根据这些输入编写新的FAQ条目。后一项工作可能非常复杂：必须能紧跟线索，识别出其中的核心问题，发表一个提议FAQ条目，组合来自其他人的评论（因为FAQ管理员不可能是FAQ包含的所有主题的专家），并感知何时结束这个过程并将其添加到FAQ。

FAQ管理员通常也会成为FAQ格式的默认专家。有许多保持FAQ结构的小细节（见Chapter 6, 交流的the section called “将所有的资源视为归档”）；当某人编辑了FAQ，他们可能会忘记这些细节。但只要FAQ管理员能够在之后查漏补缺，这样便没有任何问题。

许多自由软件可以用于辅助维护FAQ的过程。只要能够保证FAQ的质量，就可以选一个来使用，但是要避免过度自动化。一些项目试图完全自动化FAQ维护的过程，使用类似wiki的模式允许每个人贡献和编辑FAQ条目（见Chapter 3, 技术基础设施的the section called “Wikis”）。我曾经遇到过在Faq-O-Matic上发生的这种情况（http://faqomatic.sourceforge.net/），尽管我看到原因仅仅是对Faq-O-Matic超出本来目的的滥用。在任何情况下，虽然完全的分布式FAQ维护可以减少项目的负担，但也会导致较差的FAQ。没有人具备整个FAQ的广泛视野，没有人注意到了哪个条目需要更新或变得完全不可用，每个人看到的都是孤立的条目。结果是FAQ经常会无法为用户提供他们所需要查找的东西，甚至会误导他们。您可以使用任何必须的工具维护项目FAQ，但是不要因为工具便利性的诱惑而损害FAQ的质量。

见Sean Michael Kerner在http://osdir.com/Article1722.phtml的文章The FAQs on FAQs，描述和评估了开源FAQ维护工具。