# 从志愿者中获取最多 志愿者为什么要为自由软件项目工作？[[24](#)] 当被询问时，许多人声称自己只是因为希望制作好软件，或希望自己修复所需要的bug。但是这些原因并不是完整的故事。毕竟，你能想象如果没有人欣赏他的工作或倾听他的讨论，这个志愿者还会呆在这个项目吗？当然不会。很明显，人们在自由软件上花费时间的原因不仅仅是单纯的对生产良好代码的渴望。理解志愿者的真实动机将会帮助你能够合理的安排，以确保吸引和保持他们。对生产优秀软件的渴望、在复杂问题上获取的挑战和学习价值也许都是动机。但是人们有与其他人一起工作的内在期望，并在合作活动中提供和获取尊重。从事合作活动的团队必须进化出行为的标准，能够通过帮助团队的活动获取并保持那种地位。 这些标准并不总能自己出现。例如，在一些项目中—资深的开源开发者可以从顶级人员中去除几个人—人们明确的感觉到是通过频繁并详细的发布取得的这种地位。他们并不是偶然得到这个结论；这是因为他们曾经因进行长时间的，复杂的辩论中而得到尊重的回报，即使对项目没有实际的帮助。下面是一些创建氛围的技术，可以让获取地位的活动与建设性活动一致起来。 ### 委派 委派并不仅仅是将工作分散的方法；它也是政治和社会工具。考虑你要求某人做什么事情的所有效应。最明显的效应是如果他接受，就是他完成任务不是你。但是另一个效应则是他意识到你信任他能够处理这个任务。此外，如果你是在公共论坛发起这样的请求，那么他也知道团队中的其他人也表明了对他的信任。他也能感受到需要接受一些压力，这意味着你询问时要使用一种允许他拒绝的方式，如果他确实不想做这个工作的话。如果这个任务需要在项目中协调，你这样做可以有效的提议他更深入的参与进来，形成其他方式无法形成的契约，而且也有可能成为项目某个子领域权威的起源。增加的参与或许令人畏惧，也或者会导致他以其他方式参与进来，例如对于整体承诺的更多感觉。 因为所有这些效应，所以即使你认为你可以完成的更好更快，让其他人来完成也很有意义。当然，也有一个严谨的经济学效率作为论据：或许你自己完成的机会成本太高—在同一时间里你可以完成许多更重要的事情。但即使机会成本的论据并不适应，你*还是*会希望其他人完成这个任务，因为从长期来看你希望人们更深入的参与到项目当中，即使一开始需要花费更多的时间关注他们。相反的技术也适应：如果你偶然志愿完成其他人不喜欢或没时间完成的工作，你会得到他的友好关系和尊敬。委派和代理并不仅仅是要完成单个任务；他们也是将人们引入到项目核心的方法。 ### 明确区分调查和指派 有时可以很明确的期待某人会接受特定的任务。例如，如果某人编写的代码带来了bug，或者提交的代码明显未能符合项目的指导方针，那么直接指出问题，那么之后你可以认为他会小心避免此类问题。但是在一些情况下，没有明确的方法可以确保你获得期望的行动。这个人可以听你的，也可以不听。因为没有人喜欢被熟视无睹，你需要敏感的察觉到这两种情形的区别，并以此为依据调整你的请求。 你让某人做某事，如果你采用的方式让人感觉这是他理所当然的责任，而实际上他并不是这么想的时，几乎一定会立刻让他们感到非常的厌恶。例如，分配的问题可能会带来很多讨厌的事。项目的参与者通常知道谁是某个领域的专家，所以当出现了bug报告，通常会有大家都知道的一两个人可以立刻快速的修正它。然而，如果你没有得到先前的许可就将问题分配给她，她会感觉自己处于一个不舒服的地位。她会感受到这种被期望的压力，而且感觉她是由于其专业技能而被惩罚了。毕竟，获取技能的方法就是通过修正bug，所以某人会接受这个问题！（请注意，在问题跟踪系统中根据bug报告的信息自动分配的问题通常并不太冒犯，因为每个人知道分配是自动的过程，并不代表人们的预期。） 虽然应该尽可能将负担均匀的分配，但有时你需要鼓励能够以最快速度修正bug的 人。考虑到你可能无法承受为每个这种分配进行这种交流的负担（“你愿意看一下这个bug吗？” “可以。” “好的，一会儿吧这个问题分配给你。” “好的。”），你应当以询问的形式进行分配，不要传递出任何压力。事实上所有的问题跟踪系统都允许为任务分配的问题作出评论。在那个评论中，你可以这样说： > 把这个分配给你，jrandom，因为你可能是最熟悉这些代码的。如果没时间，尽管踢回来。（如果你想在以后接受这中请求，请让我们知道。） *请求*完成工作与某人*接受*工作有明显的区别。在这里观众不仅仅是被分配工作的，而是所有人：整个团队可以看到被安排工作的人的专业技能得到了公开的确认，但是这些信息也明确的表明他可以自由的接受或者拒绝这种责任。 ### 指派后要继续跟踪 当你要求某人做一些事情时，请牢记所做的，并无论如何要继续跟踪他。大多数请求是在公共论坛中做出的，形式大体上类似“你能处理一下X吗？我们只是要获知；如果你不行，那么没问题，我们只需要知道。 ”不一定会得到回应。如果你得到的回应是负面的，则环路可以关闭—你需要尝试其他的策略来处理X。如果有正面的回应，那就需要继续关注这个问题的进展，并为可见和不可见的进展作出评论（当知道其他人会欣赏他的作品时，每个人都会做的更好）。如果几天内没有回应，可以再次询问，或者发表文章说明你没有得到回应，希望找其他人做这件事。或者直接自己完成，但也要说明最初的询问未能获得回应。 公开提示缺乏回应的目的并*不是*要羞辱任何人，你的评论一定不要造成这种效果。目的仅仅是说明你还在跟踪自己征求的问题，而且你已经注意到了一些反应。这样做可以增大人们在下一次说同意的机会，因为他们会知道（即使只是无意的）你会注意到他们所做的任何工作，包括许多不太起眼的，人们会忽略的事件。 ### 通知感兴趣的人 另一件可以让人们高兴的事情就是通知他们所感兴趣的事情—通常情况下，你注意到并记住某人的个性方面越多，他会越觉得舒适，他也就越会希望参与你的团队一起工作。 例如，在Subversion项目有一个非常有明显区别的划分，期望达到决定性的1.0发布的人，和那些主要希望添加新特性，并完成感兴趣的问题，但对1.0并不太关心的人。两者的地位相当；他们只是不同类型的开发者，都在项目中完成了大量工作。但是很快认识到我们绝*不能*假设所有的人都是由1.0发布的喜悦所驱动的。电子媒介可能很有迷惑性：在你感觉到共同目标的氛围中，实际上只是你与谈过话的人有共同的目标，而其他人则有完全不同的优先级。 你对人们对于项目的期望了解越多，你就越能有效发出请求。即使仅仅是描述一下他们所期望目标的理解，甚至不必发出任何相关的请求，也非常有用，这样可以确保所有人不仅仅是无差别群众中的粒子。 ### 赞扬和批评 赞扬和批评并不矛盾；在大多数情况下，是类似的。都是关注的形式，越是明确就越有效。二者必须在牢记实在目标的情况下实施。两者都有可能因为夸大而削弱：赞扬过多或太频繁会使赞扬贬值；对批评也是同样，尽管在实践中，批评通常会有反作用，因而更加不容易贬值。 一个重要的技术文化特性是将详细的，不带偏见的批评当作一种赞扬（正如在[Chapter 6, *交流*](# "Chapter 6. 交流")的[the section called “识别无礼”](# "识别无礼")中所讨论的），因为这隐含了接收者的工作值得花时间去分析。然而，两种条件—*详细的*和*不带偏见的*—必须同时满足。例如，如果某人对代码做了些马虎的修改，如果只是说“很马虎”是毫无用处（而且通常是有害的）的。马虎最终是*人*的一种特性，而不是作品的，应该将反应集中到作品上。更有效的方法是描述变更中所有错误的地方，巧妙而无恶意。如果这是某人连续第3，或者第4次作出疏忽的修改，则可以再说一次这些事—不必发怒—批评的最后，要清楚的说明同样的模式早已经被注意到了。 如果某人对于批评不做任何改进，解决办法不应该是更多或更强的批评。对于团队来说，解决方法是将这个人从不能胜任的位置删除，并尽可能使用一种不会造成情绪伤害的方法；见[the section called “转化”](# "转化")本章后面的例子。但实际上，这种情况通常很少发生。大多数人可以很好的回应批评，当然批评必须要特定，详细并有明确的（即使没有说出来）改进预期。 赞扬不会伤害任何人的感情，但并不意味着使用时可以不像批评那样小心。赞扬是一种工具：在使用之前，要问自己*为什么*你希望使用它。作为一条戒律，不应该因为人们经常做的事情，或正常的和参与到团队中应当要做的行动赞扬他。如果你这样做，估计就停不下来了：你因为普通的事情而赞扬*每个人*？毕竟，如果你漏掉了某人，他们会问为什么。如果能珍惜你的赞扬和感激会更好，要针对不寻常或意料之外的努力，以鼓励此类努力为目的。当某个参与者永久的进入了更高生产力的状态，要根据此人调整赞扬的阀值。对普通的行为进行反复的赞扬会变得毫无意义。相反，这个人也应该感觉到自己较高的生产力水平已经是正常和自然的，只有超出这个范围的才会被特别关注。 当然，这并不是说不应该感谢某人的贡献。但是请牢记，如果项目设置正确，这个人做的任何事情都会看到，所以这个团队会知道（这个人也会知道团队中的其他人所知道的）所有她所做的。除了直接的赞扬，我们也有其他的方法感谢某人的工作。你也可以采用曲折战术，在讨论相关主题时，她已经给定领域做了许多工作，成为了领域专家；你可以公开的向她咨询代码的问题；或者更有效的，你可以大张旗鼓的进一步利用她的工作，这样她就会为别人依赖于她的工作结果而感到舒服。通常不必在这些问题上精打细算。那些有规律的为项目作出贡献的人知道自己会自然的得到有影响的地位。通常没有必要为此采取明确的步骤，除非你感觉到无论出于什么原因，贡献者都无法得到正确的评价时。 ### 防止割据 请留意那些试图在项目中独占某一领域，或希望完成某一领域所有工作的参与者。此类行为已开始看起来很健康。毕竟，在表面上似乎是某人在肩负更多的责任，并展示在特定领域增长的活动。但从长期来看，则并没有建设性。当人们感觉到“禁止入内”的标志时，他们就会离开。这种结果会减少这个领域的检查，会使之更加脆弱，因为孤单的开发者成为失败的单独一点。更严重的，它会削弱项目的合作，平等精神。理论上应该欢迎任何开发者在任何时间帮助完成任何任务。当然，在实践中会有些不同：人们在不同领域的影响总有差别，非专家通常与项目特定领域的专家不同。但关键是这都是自愿的：非正式的权威是根据竞争性和证明的判断能力赋予的，而不可以主动的*获取到*。即使某人期望的权威是能够胜任的，仍然需要她非正式的保持权威，通过团队的共识和那种永远不会将其他人排除在该领域之外的权威。 当然，因为技术原因反对或编辑某人的工作则是完全另外一回事。决策因素是工作的内容，而不应该是谁恰好是守门人。也许也是同一个人完成恰好完成了最多的工作，但只要他没有阻止其他人完成这个工作，就没有问题。 为了对抗地方主义的萌芽，许多项目采用禁止在源代码文件中包含作者名或维护者签名的方法。我完全认可这种实践：我们在Subversion项目中也遵循这个方法，这也算是Apache基金会的一种正式政策。ASF成员Sander Striker是这样做的： > *在Apache软件基金会中我们不鼓励在源代码中使用作者标签。除了法律分歧以外，还有多方面的原因。协作开发是以一个团队一起工作，将整个项目看作一个团队。给予信誉非常好，必须有人这么做，但是必须使用不会允许错误归因的方式，即使是通过暗示的方式。何时添加或删除作者标签没有明确的标准。在你修改注释后添加你的名字？或者是添加了一行的修正？在你重构了代码，改变了95%时就可以删除其他作者的标签？当人们去接触每一个文件，修改足够多的内容以达到名字标签的限额，这样他们的名字就会出现在每个地方时，你会怎么做？* > *提供信誉可以有更好的办法，我们推荐这些。从技术观点上讲，作者标签并不是必需的；如果你希望知道哪个人写了某段代码，版本控制工具可以提供。作者标签也经常失去时效性。你希望被私下咨询5年前编写，而且已经希望遗忘的代码？* 软件项目的源代码文件时身份的核心。必须要反映整个开发社区为此负责，而不仅仅是简单的各自的封地。 人们有时会为源代码中作者或维护者标签的风格而争论，他们认为这些东西是所做工作的可见信誉。这种论点有两个问题。首先，不可避免的要面对多少工作量才可以进入这个列表的尴尬问题。其次，这样会将信誉的问题与权威合并了：过去曾经完成了工作并不意味着对于曾经工作区域的所有权，但是如果单个人的名字出现在源文件的顶部，想避免这种暗示就变得几乎不可能。在任何情况下，信誉信息都可以从版本控制日志和其他诸如邮件列表归档等外带机制中获取，所以在源代码文件中禁止其出现不会损失任何信息。[[25](#)] 如果你的项目禁止在源代码文件中包含姓名，请务必不要过分执着。例如，许多项目会有一个保存小工具和辅助脚本的`contrib/`区域，通常由与本项目不相关的人编写。这些文件可以包含作者姓名，因为他们完全不是由项目维护的。另一方面，如果贡献的工具被项目的其他人修改了，最终你希望将其从孤立的位置移出，如果原始作者许可，就可以删除作者名称，这样代码就像其他社区维护的资源一样了。如果作者对此有些敏感，折衷的方案也是可以接受的，例如： ~~~ # indexclean.py: 从Scanley索引删除旧数据。 # # 原始作者: K. Maru <kobayashi@yetanotheremailservice.com> # 现在维护者: Scanley项目组<http://www.scanley.org/> # 和K. Maru。 # # ... ~~~ 但是最好避免此类折衷，如果可能，大多数作者会被说服，因为他们都会乐于自己的贡献更紧密的成为项目的一部分。 重要的是请牢记项目的核心和外围是一个连续体。项目的主要源代码文件显然是核心部分，会被认为应当是由社区维护的。在另一方面，伙伴工具或一些文档则可能是单独某个人的作品，始终独自维护，即使这些作品是与项目关联，甚至是与项目一起分发的。没有必要应用一个适用于所有文件的规则，只要坚持社区维护的资源不允许成为个人领土的原理就可以了。 ### 自动化率 努力不让人做机器可以做的事情。作为一种经验法则，将一项工作自动化花费的工作量即使十倍于手工执行也是值得的。对于非常频繁或复杂的任务，这个比率可以轻松的达到20倍或更高。 将自己想象为“项目管理员”，而不仅仅是开发者，可能是一个有效的态度。有时，单个开发者会过于沉溺于较底层次的工作，而无法看到全局图并意识到每个人都在手工执行自动化任务上浪费了大量精力。即使那些意识到的人也可能不会花时间解决问题：因为每个个体都不会感觉此类任务是一个巨大的负担，没有人已经厌烦到要为此做些什么。使自动化如此引人注目的是每个很小的负担需要乘上每个开发者执行的次数，然后还要乘上开发者的*数量*。 这里，我广泛的使用的术语“自动化”，并不仅仅是重复每次只需要修改1到2个变量的动作，而且包括任何辅助人们的技术基础架构。最低标准的自动化需要按照[Chapter 3, *技术基础设施*](# "Chapter 3. 技术基础设施")中描述的方式运行一个现在的项目，但是每个项目也都有自己的特殊问题。例如，一组编写文档的人会希望有一个网站能够在任何时间都显示最新版本的文档。因为文档通常由如XML的标记语言编写，会有一个编译步骤，通常非常复杂，包括创建可显示或可下载的文档。组织这种会在每次提交时进行此类编译的网站可能会有点复杂和花费时间—但是这样很值得，即使这要花费你一天或更多的时间。拥有最新网页的整体收益是巨大的，即使*没有*的代价仅仅是每个开发者需要每次多一些很小的烦恼。 进行这种步骤不仅仅可以消除时间的浪费，也可以确保消除在执行手工操作时步骤出错（不可避免的会发生）时的痛苦和沮丧。多步的，确定的操作恰好是发明计算机的目的；将人们拯救出来可以做更有意义的事情。 ### 自动测试 自动测试对任何软件项目都有用，特别是开源软件项目，因为自动测试（特别是回归测试）可以让开发者舒服的修改自己不熟悉的代码，因而鼓励了探索性的开发。因为手工检测损坏是这样困难—需要从本质上猜测可能损坏的事情，而且必须尝试多种实验证明其没有损坏—通过自动化方法检测这种损坏为项目节省了*大量*时间。它也可以让人们可以更放松的大幅度重构代码，从而对软件的长期可维护性贡献良多。 **回归测试** *回归测试*指的是判断已修正bug是否重新出现的测试。回归测试的目的是减少代码变更以不可预料的方式破坏软件的机会。随着软件项目的增大和复杂，这种不可预料的副作用会急剧增长。好的设计可以减少随着变更增长带来的这种比率，但是不能完全消除这种问题。 结果就是许多项目都有了一个*测试套*，一个单独的可以按照过去模仿bug发生的方式进行调用的程序。如果测试套成功的使某个bug出现，这被称作*回归*，意味着某人的变更意外的将以前修正的bug又修正回来了。 请看[http://en.wikipedia.org/wiki/Regression_testing](http://en.wikipedia.org/wiki/Regression_testing)。 回归测试并不是万能药。首先，它非常适于批量样式界面的程序。对于主要使用图形用户界面操作的软件很难程序化驱动。回归测试的另一个问题是测试套框架本身可能非常复杂，自己有一定的学习曲线和维护负担。减少这种复杂性是你可以做的一件非常有用的事，即使这需要花费相当多的时间。将新测试添加到测试套越简单，就会有越多的开发者这样做，发布中漏网的bug也就会越少。在使测试更简单上的努力将会在项目的生命周期中得到成倍的回报。 许多项目有一个*“不要破坏构建！”*的规则，意思是：不要提交会使软件不能编译或运行的变更。成为破坏构建的人通常会导致温和的窘迫和取笑。拥有回归测试套的项目通常有一个推论的规则：不要提交会导致测试失败的任何变更。如果整个测试套会自动每夜运行，随着结果发送到开发列表或专门的测试套列表，这类失败可以轻松定位；这是自动化价值所在的另一个实例。 大多数志愿开发者会愿意用额外的时间编写回归测试，只要测试系统是可理解的并易于使用。变更搭配测试可以理解为一种责任，也是协作的一种简单的机会：通常要由两个开发者分担bug修正的工作，其中一个编写修正本身，另外一个编写测试。后一个开发者通常要以更多的工作结束任务，因为编写测试并没有实际的修正那样让人愉悦，测试套不应当使测试体验超出本来应有的痛苦。 一些项目走的更远，*每个*bug修正或新特性都要伴随新的测试。这是否是个好主意取决于许多因素：软件的特性，开发团队的组成和编写新测试的难度。CVS（[http://www.cvshome.org/](http://www.cvshome.org/)）团队一直有这样一个规则。在理论上这是一个好政策，因为CVS是版本控制软件，所以非常希望规避处理或误处理用户数据可能性的风险。问题是在实践中CVS的回归测试套是一个单独的巨大shell脚本（好笑的是叫做`sanity.sh`），难于阅读，也难于修改或扩展。增加新测试的难度，以及对于新增补丁必须包含测试的要求，决定了CVS有效的阻碍了补丁。当我在CVS上工作时，我见过有人着手，甚至完成了一个CVS自己代码的补丁，但是当被告知需要在`sanity.sh`增加新测试时则放弃了。 编写新的回归测试比修正原来的bug花费更多的时间非常正常。但是CVS将这种现象发挥到了极致：一个人需要花费数小时才能正确的设计自己的测试，但仍然得到错误的结果，因为修改这样一个35000行的Bourne shell脚本有太多不可预测的复杂情况。即使是长期的CVS开发者也会为增加新测试而感到郁闷。 这种情况源于我们对于自动化比率考虑的失败。转换到一个真正的测试框架—无论是自定义的还是成品的—都会成为一种主要的动力。[[26](#)]随着时间的推移，这种忽视给项目带来更多的代价。有多少bug修正和新特性*未能*进入现在的CVS，仅仅因为这尴尬的测试套的阻碍？我们不知道精确的数量，但是一定远大于开发者为了开发新测试系统（或集成一个成品的系统）而会放弃的bug修正或新特性数量。这个任务只会耗费有限的时间，但如果无动于衷，则使用现有测试套的惩罚将会永远持续下去。 重点不在于强制编写测试是错误的，也不是说编写Bourne shell脚本的测试系统必然是不好的。它可能工作的很好，这取决于你的设计和测试的需要。重点仅仅是说当测试系统成为开发的明显障碍时，必须要有行动。同样的道理适用于所有成为障碍或瓶颈的常规过程。 ### 将每个用户当作潜在的志愿者 与用户的每次交流都是发展新志愿者的好机会。当一个用户花时间在项目邮件列表上发表文章或报告bug时，他已经认为自己比大多数用户（那些项目永远听不到回音的人）有更大参与的可能。紧跟这种潜力：如果他描述了一个bug，感谢他的报告，并询问他是否有兴趣自己修正它。如果他说FAQ中漏掉了一项重要问题，或者程序的文档有些不足，请坦率的承认问题（假定确实存在），并询问他是否有兴趣自己编写遗失的材料。很自然，大多数时候这个用户不会同意。但是多问一句也不累，而且只要你每次都这么问，也会提醒论坛中的其他听众参与到项目当中是每个人都可以做的。 不要将你的目标限制在新开发者和文档编写者上。例如从长期来看，即使训练人们编写优秀的bug报告也是值得的，如果你没有在每个人身上花费*太*多时间，而且如果在将来继续提交更多的bug—如果第一次报告时能获得建设性的互动，以后更有可能这么做。建设性的互动不必是对于bug的修正，尽管那样是理想的；它可以仅仅是一种要求更多信息的恳请，或仅仅是那种行为*是*bug的确认。人们希望被倾听。其次，他们希望自己的bug被修正。你可能无法一直及时的给予后者，但你（或者说整个团队）可以给他们前者。 一个推论就是开发者不能向出于好意提出含糊bug报告的人们表现出愤怒。这是我个人很气恼的事情。我在许多不同的开源邮件列表中看到许多开发者一直这样做，危害是显而易见的。一些倒霉的新手会发布无用的报告： > 嗨，我没法运行Scanley。每当我启动它，就会报错。有人遇到过这个问题吗？ 一些开发者—可能已经遇到此类报告几千次了，但丝毫不考虑这个新手从未遇到过—会这样回复： > 这么点信息我们能怎么做？天呐。请给点细节，例如Scanley的版本、你的操作系统和错误信息。 开发者无法从用户的角度看待事物，也未能考虑到这种反应对于观看这种交互的*其他*人的效果。很自然，对于没有编程经验的用户，之前没有报告bug的经验，当然不知道如何编写bug报告。对于这种人该怎样正确处理呢？教育他们！要使用会促使他们回来获取更多信息的方式： > 很遗憾你遇到了困难。我们需要更多信息才能找出发生的问题。请告诉我们Scanley的版本，您的操作系统和错误的精确文本。最好能提供一份你所运行命令的脚本，以及对应的输出。更多信息请看http://www.scanley.org/how_to_report_a_bug.html。 这种从用户那里榨取信息的响应方法远谈不上有效率，因为它是从用户的角度编写的。首先，它展示了同情：*你遇到了问题；我们也感到痛*。（即使在bug报告回应中也不是必须的；这取决于问题的严重程度以及感觉到的用户的伤心程度。）其次，没有对她不知如何报告bug表示轻视，而是告诉她如何，以及怎样的详细程度才会实际有效—例如，许多用户并不理解“请给些细节”的意思是“展示错误的精确文本”，不要遗漏或删节。当你第一次与这样一个用户工作时，你需要说明这些。最后，应该提供到更加详细和完整的报告bug指导的链接。如果你成功的让用户感觉在为她考虑，她通常会花时间阅读该文档并按照你所说的去做。当然，这通常意味着你需要预先就准备好文档。必须说清楚哪种类型的信息是开发团队在每个bug报告中希望看到的。理想情况下，可能需要通过回应多个这样的用户，逐渐的查漏补缺，使之更好地为项目服务。 Subversion项目的bug报告指导可以说是这类形式的标准案例（见[Appendix D, *报告bug的样例指导*](# "Appendix D. 报告bug的样例指导")）。请注意他们是如何以请求提供一个bug的补丁或修正结束的。这不是因为这种请求将会导致更高的补丁。报告率—大多数能够修正bug的用户都知道如果能提供补丁会受到欢迎，无需告知他们。请求的真实目的是为了向所有读者，特别是刚来到项目，或者刚来到自由软件的人强调，这个项目是通过志愿者的贡献运营的。这是许多新用户通常不熟悉的一个关键点。一旦他们意识到这一点，他们就更有可能在发生时帮助完成修正，即使不能提供代码，也会提供更完整的重现步骤，甚至是为其他人发布的内容测试修正。目标是让每个用户认识到他们和为项目工作的人没有*天生*的区别—问题只是他们能投入多少时间和力量，而不在于是谁。 对于愤怒回应的告诫不能适用于粗暴的用户。偶尔会有一些人会发送毫无信息量的bug报告或投诉，表现对项目某些失误的蔑视。通常此类人会在轻蔑与谄媚之间转换，例如Subversion邮件列表的这个人： > 为什么几乎6天了还没有Windows平台的二进制程序？！？每次都是同样的故事，确实让人灰心。为什么这类工作就不能自动化，可以立刻出现。？？当你发布“RC”构建时，我想你们的意思的是让用户测试构建，但是你们没为此事做任何事。如果你们没提供测试方法，又何必搞一个浸润期？？ 对于这种激动文章的最初回应是令人吃惊的克制：人们指出该项目有自己的发布政策，不会提供官方的二进制文件，并告诉他如果要改变恼人的程度，他应该志愿自己编译代码，如果真的对他很重要的话。相信与否，这段话属于他的下一次发布： > 首先，我要说我认为Subversion很彪悍，很感谢每个参与者的努力。 [...] ...然后他*再次*继续为项目没有提供二进制，现在仍然没有志愿者做这件事而斥责项目。之后，大约50人跳了出来，我必须说我确实注意到这一点了。在[Chapter 2, *起步*](# "Chapter 2. 起步")的[the section called “防无礼于未然”](# "防无礼于未然")提出的，针对粗鲁行为的“零容忍”政策，已经潜移默化的应用到每个人的交互中。但是，当人们认清他一开始就要当一个喷子时，没人能给他好脸色。 很幸运，这些情形非常罕见，很少需要被项目特别关注，并投入力量去保持用户建设性的和有礼貌的交互。 [[24](#)] 这个问题已经被详细研究，Karim Lakhani和Robert G. Wolf的一篇论文有非常有趣的结果，题目为*Why Hackers Do What They Do: UnderstandingMotivation and Effort in Free/Open Source SoftwareProjects*。见[http://freesoftware.mit.edu/papers/lakhaniwolf.pdf](http://freesoftware.mit.edu/papers/lakhaniwolf.pdf)。 [[25](#)] 但是邮件列表中链接为[http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee](http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee)的*“having authors names in .py files”*的这篇文章是一个很好的抗辩，作者是William Stein。我认为关键在于许多作者来自一种将信誉直接取自源代码视为标准并高度评价的文化。在那种环境中，可能有必要将作者的名字置于源代码中，并精确的描述每个作者的贡献，因而大多数潜在的贡献者会希望有这种样式的承认。 [[26](#)] 请注意，没有必要将所有已存在的测试转化到新框架；二者可以和平共处，只需要转化需要改变的测试。