交流

交流将代码写清楚的能力或许是开源环境中最重要的一项技巧。从长期来看，这不仅仅取决于编程天赋。即使是优秀的程序员，如果没有好的沟通技巧，在同一时间也只能完成一件事，即使如此也很难让其他人注意。但一个糟糕的程序员如果善于交流，则可以协调并说服许多人做很多事情，对于项目的方向和动力起着重要的作用。无论从哪个方向看，编写好代码的能力和与其他人交流的能力看起来毫不相关。编码能力和描述技术问题的能力则有一些关系，但是描述技术问题只是项目交流中很小的一部分。更重要的是移情到其读者的能力，可以像其他人那样去看待自己的文章和回复，可以让他人以同样的客观性看待自己的文章。同样重要的是发现某种媒介或交流方法不再有效，这或许是因为它并没有随用户数量的增多而扩展，然后花时间去解决它。在理论上很明显—但因为开源软件开发环境的受众和交流机制引起的混乱，在实践中的非常困难。一个给定的想法必须在邮件列表中作为bug跟踪系统的注释或代码的说明发布出来？当在一个公共论坛回答一个问题时，应该如何假定读者的知识水平，只是为咨询问题的“读者”解答，而是为所有会看到回复的读者？如何让开发者与其他用户保持建设性的联系，而避免陷入特性请求、虚假的bug报告和一般的聊天。如何知道一个媒介达到了容量的限度，你该如何做呢？针对这些问题的解决方案都只能是部分的，因为任何特定方案都会随项目结构的成长或变化而废弃。他们也经常是专门的方案，因为他们需要随机应变。所有的参与者需要意识到交流在何时，如何陷入困境，并立刻参与到解决方案中去。帮助人们完成这件事是管理开源项目的重要任务。本小节后面的部分会讨论如何引导你自己的交流，以及如何在项目中为所有人维护交流机制的优先级。关于这个主题有许多有趣的学术研究；例如Gutwin、Penner和Schneider所著的Group Awareness in Distributed Software Development。这篇论文曾经在网上出现过一段时间，之后消失，后来又在再次出现。所以，如果这个地址无法访问，请通过搜索引擎搜索新地址。人如其文考虑如下情况：因特网上别人对你的了解都来自你所写的东西。你或许是一个富有才华、敏锐和领袖气质的人—但是如果的你的邮件散漫且没有组织，人们会以为你也是这样。或者也许你是一个散漫和无组织的人，但没人会知道这一点，只要你的文字能够清晰且言之有物。在写作上的投入回报巨大。长期自由软件黑客Jim Blandy说过这样一个故事：

回到1993，我为自由软件基金会工作，正在为GNU Emacs的19版本进行beta测试。我们每周都会发布一个这样的beta版本，人们会进行测试并回馈我们bug报告。有一个我们都不认识的人，但是完成的工作很好：他的报告总是十分清晰，并能让我们直接找到问题，而且当他自己提供修正时，也几乎都是正确的。他是顶尖人物。现在，在FSF可以使用其他人编写的代码之前，我们会让他们准备一些文书工作，将该代码的版权利润赋予给FSF。完全获得陌生人的代码是处理法律灾难的好办法。所以我给这个家伙发了一份表单，说，“这里是我们需要的一些文书工作，你签署这一份，让你的雇主签另一份，然后我们就可以开始提交你的修正。非常感谢。” 他回复了一封信息说，“我没有雇主。” 所以我说，“很好，那就让你的大学签署它并发回来。” 不久，他又回复了，并说，“很好，实际上，我已经30岁了，与父母一起住。”

因为那个小孩并没有像30岁的人那样写东西，所以没有人知道他的情况。下面也是让你的写作能够带来良好印象的一些方法。结构和格式不要像编写手机短信那样编写所有的东西。要使用完整的句子，每个句子首字母要大写，也要根据需要分段。在编写电子邮件和其他内容时这一点最重要。在IRC或类似的短命论坛上，忽略大小写或压缩形式的常见短语也无所谓。只是不要把这个习惯带到更正式，会持久化保存的论坛中。邮件、文档、bug报告和其他会永久保存的东西，必须使用标准语法和拼写，并有一致的叙事结构。并不是因为任何事情都有遵循任意规则的内在特性，而是因为规则并不是任意的：他们演化成现在的形式是因为可以让文本更可读，因此你应该遵循这些规则。可读性是令人向往的，并不是因为这样人们就能够理解你所写的，而且是因为这样可以让你看起来像是人们可以花时间进行清晰交流的人：也就是值得人们关注的人。对于个别的电子邮件，有经验的开源开发者会使用特定的约定：只发送文本邮件，而不应该是HTML、富文本或其他格式，因为有许多只支持文本的邮件阅读器。将每行列长格式化为72。列长不要超过80，80已经成为事实上的标准终端宽度（也就是会有人使用更宽的终端，但没有更窄的）。通过将列数设置为小于80，可以为其他人回复中的引用字符留出空间，从而不必让文本强制换行。使用真正的换行。一些邮件程序可以使用一种假的换行，可以让你编写的邮件在没有实际换行时显示出来有换行。当邮件发送以后，邮件不会有你所以为的换行，他们会非常难看的出现在某些人的屏幕上。如果你的邮件程序使用假换行，应该找一个恰当的设置，可以在编写邮件时显示真换行。当包含屏幕输出，代码片段或其他格式化文本时，需要清晰的处理缩进，这样可以轻易的区分你的叙述和引用的内容。（当我开始撰写此书时，我没有想过编写这些建议，但是当在许多开源邮件列表中看到了很多人混合文本和其他资源，以至于无法区分开时，我改变了注意。这样的效果很让人灰心。这让他们的文章很难被理解，很明显也让这些人看起来有点混乱。）当引用其他人的邮件时，可以直接在合适的位置插入你的回应，如果需要可以在不同的位置，然后删节那些在你的邮件不使用的部分。如果你需要为全文进行评述，可以写在顶部（将你的回应置于引用的邮件文本之前）；否则，请首先引述原邮件的相关文本，然后紧跟你的回应。小心构建新邮件的主题行。这是邮件中最重要的一行，因为它可以让项目中的其他人决定是否进一步阅读。现代邮件阅读软件可以将相关信息组织成一组线索，并不仅仅是根据共同的主题，而且可以根据其他头（有时并不显示）。它遵循了如下原则，如果线索转移到另一个主题，你可以—也必须—根据回复修改主题行。由于其他邮件头，线索的完整性得以保全，但是新的主题可以帮助人们获知主题已经转移。同样的，如果你确实希望开始一个新的主题，那么可以发布一个新的邮件，而不是对现有邮件修改主题并回复。否则，你的邮件会仍然分组到你所回复的线程中，因此会让人们不知道讨论的内容已经改变。再次，惩罚不仅仅是所浪费的时间，也会使你使用交流工具的信用受损。内容组织良好的邮件会吸引读者，但是内容可以留住他们。当然，没有可以确保好内容的固定规则，但是有一些可以让其更像的原理。让事情对你的读者更简单。任何一个开源项目都有大量的信息，不能期望读者熟悉所有的东西—事实上，不可能期望他们知道如何熟悉。所以要尽可能让你的文章以尽量便利的形式提供给读者。如果你能够额外花费几分钟在邮件列表归档中找出特定线索的URL时，从而减少读者寻找的麻烦，这样做非常值得。如果你可以花费5到10分钟为复杂的线索总结一个结论，从而为人们理解你的文章提供一个上下文环境，那么一定要去做。可以这样考虑这件事，项目越成功，在任何论坛中的读者-作者比率越高。如果你的文章被n个用户看到，那么随着n的增大，扩展额外的努力节约其他人的时间就越值得。随着人们看到你将自己置于这个标准之下，他们也会在自己的交流中与此匹配。理想情况下，会带来项目整体效率的提升：当人们在n个人和一个人这样努力做出选择时，大家会选择前者。不要使用夸张法。在线发布中的夸大是经典的军备竞赛。例如，一些报告bug的人会担心开发者不会投入足够的注意力，所以他们将其描述为严重的、会中断他（以及他的所有朋友/同事/亲戚）使用该软件的问题，而实际上只是一般的不适。但是夸大并不限于用户—程序员也会在技术讨论时也这样做，特别是当问题是关于他们不认可的某种口味而不是正确性时。

“这样做事会让代码完全不可读。与J. Random的建议相比，这是维护的梦魇。”

当措辞不是如此尖锐，同样的感情也会变得更强：

“这样也可以工作，但是出于可读性和可维护性的考虑，并不是理想的方式，我认为。J. Random's的建议避免了这类问题，因为它...”

你不可能完全消灭夸大，一般来说也没有必要。与其他形式的交流问题相比，夸大并不是对所有人都有害—他只会伤害夸大者。接收者也会做出相应的抵消，每次都会让发送者损失自己的信用。因此，为了你自己在项目的影响力，请使用温和的方式。只有这样，人们在会在你真的需要表达强烈观点时重视你。编辑两次。对于任何超过中等长度段落的信息，请在你第一次认为完成之后再从头到尾检查一遍。这是所有参加过写作课程的人会得到的忠告，但是在在线讨论中格外重要。因为在线写作的过程很容易变得非常不连贯（在编写信息的过程中，你需要回头检查其他邮件，访问特定的网页，或者运行某个命令捕获调试信息等），这样很容易让你失去叙事的感觉。不连贯编写的信息，而且在发送以前也不检查通常会被认为会让他们的作者懊恼（或者这样某人会希望）。花时间检查你发送的内容。你的内容组织的越好，就会有越多的人去阅读。基调在写过几千条信息后，你一定会发现自己会趋向于简洁。这看起来是大多数技术论坛的标准，在本质上没有任何错误。在社会交流中不可接受的简洁程度则是自由软件黑客的默认程度。下面是我在一个邮件列表中发表的关于自由内容管理软件的文章，完全引用：您能更详细的说一下所遇到的问题吗？可能是：您使用什么版本的Slash？你能说出原始信息吗。你是如何编译的apache/mod_perl源？你尝试过发布在slashcode.com的Apache 2.0补丁吗？ Shane 这就是简洁！没有问候，没有他的名字以外的签名，整个信息本身只有一系列尽可能紧凑的疑问句。其中的一个祈使语句是隐含的对原始信息的批评。虽然如此，我还是很高兴看到Shane的邮件，并没有因为其简洁而把他当作一个大忙人。事实仅仅是他们在询问问题，而不是忽略我的问题，意味着他愿意在这个问题上花更多的时间。读者能够对这种方式作出正面的反应吗？这不是必须的；这取决于人和上下文。例如，如果某人刚刚承认她犯了一个错误（例如写了一个bug），而你根据以前的经验知道这个人容易不安全，那么你仍会编写一个紧凑的回复，你应当确信其中包含一些考虑其感受的内容。你的回复可能很简短，只有工程师对于形式的分析，和你想的一样简洁。但是在最后，应该指明你的简洁不应该理解为冷漠。例如，如果你要建议如何正确的修正某个bug，应该签署“好运，<这里是你的名字>”指明你希望他们做好工作而不会发疯。一个笑脸或其他符号表情通常也足够安抚你的对话者。也许像关心参与者所说事情的表面一样关心其情绪有一些古怪，但是认真的说，情绪影响生产力。由于其他原因情绪也非常重要，但如果仅出于功利原因，我们也能发现不快乐的人会写出糟糕的软件。因为大多数电子媒介的本性所限，通常没有关于人们情绪的明显线索。你应该根据这些猜测：a)大多数人在那种形势下的感觉，b)你在以前的交流中对参与者的了解。一些人采用更简单的态度，仅根据表面处理事情，如果没有参与者直接说出自己的感受，则别人没有义务像他已经说出那样去对待她。我不会选用这个方法，有如下一些原因。首先，人们在真实生活中并不是这样处事的，为什么要在线上这样？其次，因为所有的互动发生在公共论坛，人们会比私密情况下更加控制自己的感情表达。更精确的说，他们通常希望对某人直接表达感情，例如感激和愤怒，而不是直接的内部情绪，例如不安和骄傲。当知道其他人会关注到他的心理状态时，大多数人会工作的更好。通过在细微线索上投入注意力，你可以在大多数时候猜到问题，并且能够鼓舞人们比原来更深入地参与。我不是说，你的角色是团队治疗师，一直通过触及别人的情绪来帮助每个人。但是通过对于个人行为长期模式的观察，即使你们从来也没有面对面，也会获得像单个人之间的感受。而且通过对于自己文章基调的敏感性，你会为自己对于其他人情绪的影响力感到吃惊，最终会使项目受益。识别无礼开源文化的一个定性特征是对于何为无礼的特色定义。下面叙述的习惯不只是出现在开源软件开发，也不只是在一般软件—在数学、严密科学或工程纪律中也并不陌生—自由软件，由于其跨领域性，并有不断涌入的新来者，许多不熟悉这种环境的人将要面对这些习惯。我们先从不无礼开始。技术批评，即使很直接且没有铺垫，也不是无礼的。实际上，这可以看作是一种谄媚：批评者在说话，说明目标值得重视，值得花时间研究。可以说，平静只是简单的忽视某人的文章，花费更多时间批评它则是更多的赞美（当然，除非批评升级到了非理性的攻击或其他形式的明显无礼）。迟钝、朴实的问题，例如前面Shane的对我的邮件，也不是无礼。在其他环境下这种提问会看起来有些冷酷，玩弄文字或甚至是嘲弄，通常是有意的严重行为，而且除了尽快释放出信息，没有隐藏的日程表。著名的技术支持问题“你的电脑插电了吗？”是经典的案例。支持者确实需要知道你的电脑是否插电，经过一段时间的这类工作，他已经厌倦了在问题前点缀一些有礼貌的奉承（“请原谅，我只是要问一些问题以排除一些可能性。有一些可能很基础，请暂时忍受一下我...”）。此刻，他没有再做任何铺垫，只是直接问：到底插电了没有？类似的问题会一直在自由软件邮件列表中被问起。目的不是冒犯接收者，而是快速排除大多数明显的（或许也是最常见的）解释。理解这种行为并作出响应的接收者会因为大度的态度获得成功。不能正确反应的接收者也不会受到谴责。这只是文化的冲突，不是某人的过错。要和蔼的解释你的问题（或批评）没有隐藏的含义；只是希望让（或传递）信息尽可能有效率，无他。那么怎样是无礼？详细的技术评论一种形式的谄媚，同理，如果不能提供高质量批评也可以看作是一种冒犯。我不是说仅仅忽略某人的工作，是提议、代码变更、新问题添加或任何事。除非您之前明确的承诺会有详细的反应，不做任何反应也没有错。人们只会假设你没有时间回答。但是如果你要反应，就要用心：花时间真的去分析，提供合适的实在例子，在以前的归档中发掘相关的文章等等。或者如果你没有时间花费这种精力，但仍需要写一些简短的回应，然后在信息中公开说明缺陷（“我知道有一个对应的问题，不过我没时间去搜索，对不起”）。主要是认识到文化标准的存在，通过履行承诺或公开的告知缺乏时间实现。无论何种方式，标准都会被加强。即使不能达到标准，不要在同一时间解释为什么你没有达到，这样做好像是说这个主题（以及那些参与者）不值得你花费时间。更好地是通过简洁而不是懒惰展示你的时间的价值。也有一些其他形式的无礼，当然，但是大多数并不只存在于自由软件开发，而且常识足够引导你避免他们。如果你还没有看，可以看的。面容人脑中有一块专门负责识别面容的区域。它被非正式的称为“梭型面容区域”，其能力大多来自天生，而不是学习得到。因为识别单个人是至关重要的生存技巧，所以我们演化出了专门的硬件负责这个工作。互联网基于的交流从心理上说有些古怪，因为需要许多无法用自然，原始的方法识别对方的人，进行紧密的合作：首先是面部识别，也有声音和姿势等。为了弥补这种不足，可以在所有地方使用一致的屏幕名称。他应该是你邮件地址的一部分（@之前的部分），你的IRC用户名，你的版本库提交名，你的问题跟踪用户名等等。这个名字就是你的在线“面容”：一段可以同你的真实面容起到同样效果的标识字符串，尽管他不是，但至少模拟了内置在电脑的硬件。。屏幕名称应该是你真实姓名的直觉（例如我的是“kfogel”）展示。在一些情况中，会伴随你的完整名，例如在邮件头中： From: "Karl Fogel" <kfogel@whateverdomain.com> 实际上，这个例子有两件事。就像前面提到的，屏幕名称用直觉方式匹配真实姓名。但是，真实姓名是真实的。而不是某种修饰的名称： From: "Wonder Hacker" <wonderhacker@whateverdomain.com> Paul Steiner有一副著名的卡通，刊登在1993年6月5日的纽约客，里面是一条狗登录到了电脑终端并阴险的与另一个人交谈：“在因特网上，没人知道你是一条狗。”这类思想的背后是自我夸大，这些有些俏皮的在线标识的人给了他们自己—好像被叫做“Wonder Hacker”就真的是神奇黑客了。但是事实没有改变：即使没人知道你是条狗，你还是条狗。一个幻想的在线标识不会打动读者。相反，他们会认为你只是形象而没有本体，或者仅仅是你是不安全的。在所有的交流中使用真实姓名，或者因为某些原因需要匿名，那么就请起一个完全像真名的名称，并一直用下去。为了保持你的在线面容的一致，有一些方法可以让他更吸引人。如果你有正式的头衔（例如”博士“、”教授“和”导师“），不要炫耀，除非与对话内容相关，最好不要提及。作为一般的黑客之道，特别是自由软件文化，认为这些头衔是多余和不安全的标志（例如叫兽和砖家）。当然，如果这些头衔是作为标准的签名出现在每封邮件，不要把这个当作支持你在讨论中位置的工具—这种尝试必定事与愿违。你需要尊敬人的家伙，而不是尊敬这些头衔。说到签名区：要保证短小有意义，或者更好的情况是没有签名区。避免大段的法律免责声明出现在每个邮件的结尾，特别是当他们表达的感情与自由软件项目的参与精神不匹配时。例如，如下是我参与的一个公开邮件列表中的某个用户每个文章都会出现的的经典流派： IMPORTANT NOTICE If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to the statement below or contact the sender. This communication is from Deloitte & Touche LLP. Deloitte & Touche LLP is a limited liability partnership registered in England and Wales with registered number OC303675. A list of members' names is available for inspection at Stonecutter Court, 1 Stonecutter Street, London EC4A 4TR, United Kingdom, the firm's principal place of business and registered office. Deloitte & Touche LLP is authorised and regulated by the Financial Services Authority. This communication and any attachments contain information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please return it with the title "received in error" to IT.SECURITY.UK@deloitte.co.uk then delete the email and destroy any copies of it. E-mail communications cannot be guaranteed to be secure or error free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept liability for any such matters or their consequences. Anyone who communicates with us by e-mail is taken to accept the risks in doing so. When addressed to our clients, any opinions or advice contained in this e-mail and any attachments are subject to the terms and conditions expressed in the governing Deloitte & Touche LLP client engagement letter. Opinions, conclusions and other information in this e-mail and any attachments which do not relate to the official business of the firm are neither given nor endorsed by it. 对于只想偶尔询问一个问题的人，如此巨大的免责声明虽然有点傻，但是没有任何永久的伤害。但是，如果某人希望活跃的参与到项目中，这个法律的陈词滥调会开始一个更潜在的影响。它会释放出两个潜在的破坏性的信号，这个人对于自己的工具没有完全的控制权力—他陷入了某个公司的邮件系统，这个系统会在每个邮件结尾添加讨厌的信息，而他无法绕过—其次，他对自己参与的自由软件活动只有有限或没有任何组织支持。诚然，组织明显没有禁止他在公共列表发表文章，但可以让他的文章看起来明显的不受欢迎，仿佛泄漏机密信息的风险必须排在第一位。如果你所在的组织坚持对所有外发邮件添加这种签名区，应该考虑申请一个免费邮件帐号，例如，gmail.google.com、www.hotmail.com或www.yahoo.com，然后作为你在项目中的地址。避免常见的陷阱不要发表无目的的文章在线项目中一个常见的陷阱是认为你需要回复所有的东西。你不必如此。首先，一般会有太多你无法同时跟踪的线索，至少是经过它开始的几个月后。其次，即使你已经决定参与，人们说的大多数话都无需回应。开发论坛都会不同程度的由下列三类信息占据：提出重要事物的信息提出对他人曾经说过的话表示支持或反对的信息总结信息上述信息并不是必定需要一个回应，特别是当你根据到目前为止的线索，很确定其他人会说出以前你说过的话时。（如果你担心别人也使用这个策略，而落入等待-等待的循环，不必如此；几乎总会有某人愿意跳出来解决问题。）回复应该由明确的目的激发。首先要问自己，是否知道所期望的完成的任务？其次，是否如果没有你的话，这个事情就无法完成。在线索中发出你的声音的有两个理由，包括a) 当你在提议中发现了一个瑕疵，你怀疑你是唯一看到它的人，另外b) 你发现他人之间错误交流，并且知道你可以通过澄清文章修正它。通常在邮件中仅仅表明对某人工作的感谢或者只是说“我也是！”，因为读者可以立刻确认此类文章无需任何回应或进一步的动作，所以当读者达到邮件的最后一行，一个干净的结束符合他的心理需求。但是即使到了此时，说话之前也要再三考虑；一定要让别人觉得你说的太多而不是太少。（在忙碌的邮件列表中工作的更多想法的第二部分请看）多产VS非多产的线索在忙碌的邮件列表中，你有两个诫命。第一，很明显，要指出哪些需要关注，哪些需要忽略。第二，要避免产生噪音的方式：不仅仅是你希望自己的文章保持较高的信噪比，你也希望这些信息可以刺激其他人也保持同样的信噪比，或者干脆不发表文章。为了展示这是如何发生的，考虑一下事情发生的上下文。非多产的线索的特征是什么？发生的争论是在重复，仿佛发布者认为没有人听说过。随着赌注的缩小，夸大和连累的升级。大部分评论来自做过很少事情或没做过事情的人，而能帮助完成事情的人则保持沉默。大多数想法的讨论都没有作出明确的提议。（当然，任何有趣的想法都是从不清晰的远见开始；重要的问题是之后的方向。讨论是否将远见变得更具体，或者分裂为更小的远见，副远见和本体论的争论？）不要因为某个线索开始不够多产而认为它是浪费时间。它可能是一个重要的主题，正因为他非常棘手所以难以做出进展。将线索引向有用而不是蛮干是一项艺术，仅仅是告诉人们不要浪费时间，或者告诉他们在没有形成建设性的内容前不要说话并没有用。你或许可以在私下这样想一想，但是如果你大声的说出来就会成为一种冒犯。相反，你必须促成进一步进展的条件—给人们一条路，一条可以将结果导向期望的路，而无需发出指挥命令。这样的基调将会大为不同。例如，这样很不好：

这个讨论已经跑的漫无边际了。我们可以暂停这个主题，直到某人能够提交一个补丁实现这些建议吗？没有理由继续反复说同一件事情。代码比单词更有力，伙计们。

然而这样很好：

线索浮现出了多个提议，但都没有完成所有的细节，至少还不足以形成表决。然而现在我们也说不出新东西了；只是在反复重复以前说过的东西。此时，为了进一步的讨论，最好提供提议的完整规格或补丁。然后我们至少有明确的动作可以做（即对规格达成一致，或应用和测试补丁）。

第二种方法与第一种方法完全相反。第二种方法不会让你与他人发生联系，也不要指责他们将讨论带入了螺旋。无论你在之前是否参与到线索的讨论，都要说是“我们”，因为即使你一直在线索中保持沉默，线索的结果也有你的份。它描述了为什么线索到了乌有之地，这样做并没有轻蔑或判决的含义—它只是不带感情的对事实的描述。最重要的，它提供了一个行动的正面课程，这样人们就不会感觉到讨论被关闭了（对于他们可以被诱惑去造反的限制），而会感到获得了一个方法可以将对话带入更有建设性的水平。这是人们自然会期望遇到的标准。你不会一直希望让线程进入更有建设性的水平—有时，你只是希望它赶快离开。文章的目的只是从中选择一个，放弃另一个。如果你能断定线索离题太远，而且没有能实际上去完成你所建议的步骤，那么你的文章会有效的终止线索，而且不需要这样做。当然，没有关闭线索的安全方法，即使有，你也不会希望去使用。但是询问参与者在作出可见的进展和停止讨论之间做出选择则是完美可防卫的，如果可以圆滑完成的话。然而，还是要小心永久的平息线索。一些纯理论的讨论可能会十分多产，取决于主题，而且如果过快的要求解决也会扼杀创造过程，也会让你看起来不够耐心。不要期望线索会立刻停止。在你的文章之后，还是会有些文章，一方面因为邮件是排队传递的，另一方面是因为人们想说最后一句话。不必为此担心，你不用再说一遍。只需要让它逐渐消失或不消失，这取决于具体的情况。你不可能有完全的控制；另一方面，你可以期望在大量线索的统计上有显著的效果。主题越软，辩论越长尽管讨论会在任何主题上缓慢前进，但是随着主题技术难度的降低，缓慢前进的可能性就越高。毕竟，技术难度越大，能够理解的参与者也就越少。这些参与者更有可能是最有经验的开发者，他们已经参加过无数次这样的讨论，知道如何才能与每个人达成共识。因此，如果技术问题易于理解或容易得出自己的意见，或者是诸如组织、公开性和资金的软主题，就很难达成共识。人们可以永远参与到这种辩论中，因为这事没有门槛，没有决定（甚至在之后）正确或错误的明确方法，而且因为等待其他讨论者结束是一个成功的策略。对于长期的主题，讨论的数量与主题的复杂度成反比的原理，被非正式的称为Bikeshed效用。这里是Poul-Henning Kamp为BSD开发者作出解释的著名文章：

这是一个很长的故事，或者说是一个老故事，但它实际上很短。C. Northcote Parkinson在20世纪60年代初编写了一本叫做“Parkinson定律”的书，包含了许多管理动态性的真知灼见。 [...] 这些例子中包括自行车棚，另一个更重要的组件是核电站，我猜这描述了本书的年龄。 Parkinson展示了如何进入董事会，并得到建造花费几百万，甚至几十亿美元核电站的许可，但如果你希望建造自行车棚，则会陷入无休止的讨论。 Parkinson解释了这是因为核电站太大、太贵和太复杂了，人们无法掌握，所以不会去尝试，转而会假设某人会在需要时检查所有的细节。Richard P. Feynmann在他的书中提供了一些关于洛斯阿拉莫斯（美国新墨西哥州中北部一个无法人地位的社区，位于圣菲市西北。1942年被选作核研究基地，生产了第一批原子弹。从1947年至1962年原子能委员会统治着这个城镇。）的有趣而且非常到位的例子。另一方面是自行车棚。所人都可以在周末建一个车棚，而且还有时间看电视上的比赛。所以无论准备的多好，无论你的提议是多么的有道理，人们会抓住机会展示他在做自己的工作，他正在关注，他就在这里。在丹麦，我称之为“配置你的指纹”。它关于自尊和声望，关于能够指向某事并说“这里！我那样做的。”这是政客的典型特征，但是现在很多人都会这样。想想湿水泥中的足迹。

（他的完整文章也十分值得阅读。请看，以及。）任何参加过团队决策的人都会知道Kamp所说的东西。然而，通常还是不可能说服每个人避免喷刷自行车棚。最好你能指出这是一个必然存在的现象，并在你发现它时，说服高级开发者—这些文章拥有最高权重的人—尽早丢下他们的刷子，或至少不要添加噪音。自行车棚喷涂的聚会永远不会完全消失，但是你可以通过在项目文化中传播这个现象的知识让这种事变得时间更短，频率更低。避免圣战一场圣战是一场争论，经常但不会一直是相对的小问题，一般不会通过辩论得到解决，但是有人会充满热情的继续辩论，期望他们一方会获胜。圣战并不与自行车棚完全一样。人们粉刷车棚通常是突然跳出来的意见（因为他们可以），但是他们不必强烈的感觉必须如此，并且以后会表达其他的意见，互相矛盾的意见，以展示他们理解问题的所有方面。而另一方面，在圣战中，理解对方则是示弱的表现。在圣战中，每个人认为有一个唯一正确的答案；他们只是不认可是什么。圣战一旦开始，通常就不可能让每个人都满意。在正在进行的圣战中指出这点并没有好处。每个人都已经知道。不幸的是，但是对于通过连续的讨论能否解决争论这一问题，是圣战并不认可的一个常见特性。从外部看来，很明显没有一方可以改变另一方的意见。而从内部看，则认为另一方太过蠢笨，也没有想清楚，但是经过足够的恫吓则能回心转意。现在，我没有说在圣战中永远没有正确的一方。有时确实有—在我参加的圣战中，真理当然永远属于我这一边。但是没有关系，因为没有算法可以令人信服的描述某一方是正确的。人们试图解决圣战的一个常见的，但是不能令人满意的方法是说“我们的讨论已经浪费了过多的时间和精力！我们能不能把它忘掉？”这样有两个问题。首先，时间和精力已经投入，不可能收回了—现在唯一的问题是还有更多的力量吗？如果某人感觉更多的讨论会结束这个问题，那么继续就还有意义（从他们的角度看）。另一个要求这件事必须丢弃的问题是这通常等同于允许某一方打破现状，通过无为宣布胜利。在某些情况下，现状无论如何是不能接受的，每个人都认为需要作出决定，必须有所行动。为每个人丢弃这个主题通常比任何人放弃论点更坏。但是因为这种两难可以平等的应用到所有人，所以仍有可能永久结束辩论。那么你应当如何处理圣战？第一个回答是，做好准备避免其发生。看起来并不是完全没有希望：你可以预期到一些标准的圣战：可能关于编程语言、许可证（见的）、回复处理（见的）和一些其他主题。每个项目可能都有自己的圣战，长期开发者会很快熟悉。停止圣战，或者减少其危害的技巧在大多数地方都是相同的。即使你肯定你属于正确的一方，可以试着寻找一些方法展示自己对对方的同感，并理解另一方的论点。通常问题是在圣战中的每一方都尽可能高的建筑自己的墙，而使其他见解看起来是完全的愚蠢，放弃或改变思想的行动在心理学上变得不可忍受：这样做不仅仅是承认错误，而是必然并且会一直错下去。将这种承认变得可口的方法是展示你的不确定性—精确的展示你理解他们的辩论，发现他们至少很敏感，即使最终并不是令人信服。作出为回应姿态留出空间的姿态，通常情况会得到改善。也许你不会得到期望的技术结果，但是你可以避免对于项目士气的非必要相关损害。当圣战不可避免时，尽早决定你要关注多少，并乐意公开放弃。当你这样做，你可以说你正在退出，这场圣战毫无价值，而不要展示出挖苦，并且不要利用这个机会对对方的辩论做最后一次攻击。只有优雅的去做才能有效的放弃。编程语言的圣战有些特殊，因为虽然其本身的高技术性，然而很多人感觉自己有资格参与其中，因此结果可能取决于项目编码编写较好的部分的语言。最好的解决方案是尽早选定语言，由初始的有影响的开发者引入，根据你最舒服的语言，而不是因为其优于其他语言而使用。不要将对话退化为经典的编程语言比较（通常是当某人因为某些原因提出Perl。）；那是死话题，你应该明确的拒绝涉及。关于圣战的更多历史背景，可以看，Danny Cohen的论文普及了这个术语，。 “吵闹的少数派”效应在所有的邮件列表讨论中，都有一些少数派不断用大量冗长的邮件血洗列表，给人存在大量异议的印象。有些像filibuster（一种议会程序，阻挠议案的通过），但是这种广泛异议的幻想更加强大，因为它分割了任意数量的不连续文章，大多数人无法跟踪何人在什么时间说了什么。他们会产生主题存在严重争议的直觉印象，并等着小题大做的平息。中和这种效应的最好方法是明确指出并提供证据证明这种异议的数量与认可的数量相比是微不足道的。为了增大这种差距，你或许会希望私下调查大多数时候会保持沉默，但是你怀疑是认可大多数的人。不要说这些持异议者是故意夸大这种印象。他们一般不会是故意，即使故意，指出来也没有策略上的好处。你只需要指出双方实际数字的比较，人们就会认识到他们对于形势的直觉与现实不符。这个建议并不是只能应用到具备明确支持和反对位置的问题。它可以应用到所有小题大做的问题上，但是如果大多数人认为讨论的问题不是一个问题时，则不是这么清楚。如果经过一段时间，你认为这个问题并不值得行动，并且看到它无法获得更多的吸引力（即使有了大量的邮件），你可以公开评论其没有吸引力。如果“吵闹的少数派”正在工作，你的文章就会像一缕清风。大多数人对于这个讨论的印象都会有一些阴郁：“好象是发生了一些大事，因为有很多文章，但是我看不出有什么进展。”通过解释讨论的形式使其显得比实际上更加吵闹，你给其新的面貌，人们可以重新修订自己对于发生问题的理解。刺儿头在电子论坛对付刺儿头并不比在现实中容易。这里“刺”不是“无礼”。无礼的人很讨厌，但不一定难对付。本书已经介绍了如何处理他们：在第一时间回复无礼行为，之后，选择忽略他们或者同其他人一样对待他们。如果他们继续无礼，他们会让自己更加不受欢迎，并在项目中毫无影响力，所以这是他们自己的问题。真正的问题不是完全无礼的人，而是那些操弄或滥用项目进程，消耗他人时间和能量，而不会为项目带来任何利益的人。这些人经常会寻找项目规程中的楔点，而释放在其他地方无法获得的影响力。这比单纯的无礼更加狡猾，因为其导致的行为或损害都不是随意的观察者能够发现的。一个经典的案例是filibuster，某人会一直声称讨论的事情还没有准备好解决，并一直提供更多的解决方案，以及对旧方案的新视点，而实际上是他感到会达成共识或投票，而他可能无法保持领先。另一个例子是当一个辩论无法达成一致，但是团队尝试至少理清异议并为所有人制作一份以后可以参考的总结时。蓄意阻挠者知道总结会导向他不期望的结果，所以会通过反对合理的建议或引入意料之外的新条目来夸大问题的复杂性，试图延迟总结。处理刺儿头为了中和这种行为，我们需要理解从事这种行为的心理。人们并不是有意识的这样做。没有人会在早晨起床并对自己说：“今天，我会处理规程表单，从而成为恼人的蓄意阻挠者。”相反，这种行为经常是出于希望在项目互动和决策中发表意见的半偏执的情绪。有些人感觉自己没有被重视，或者（更严重的情况）认为存在一个针对自己的阴谋集团—其他项目成员决定成立一个排他的俱乐部，而他不是其成员。然后作为辩护，在他的思想中，认为按照字面意思遵循项目的规则，并参与到项目规程的正式处理中，从而让所有其他的人可以重视他。在极端的例子中，某些人甚至会认为自己正在为拯救项目而孤军奋战。不是所有的人在同一时间可以看到这种攻击，某些人可能会完全看不到，除非提供了强有力的证据。这意味着中和它需要大量的工作。说服自己它的发生并不足够；你也需要配置足够的证据说服他人，并使用考虑周到的方法分发这些证据。考虑到有大量的工作，最好不要容忍太长时间。考虑到它的寄生性，但只是温和的疾病：感染时并不会对项目造成过大的损害，药物反而可能有严重的副作用。然而，如果损害变得无法容忍，就应该采取行动。从收集见到的模式的记录开始。确保包含对公共归档的引用—这是项目保留这些记录的原因，所以你也可以利用它们。一旦建立了好的案例，开始与其他参与者的私下对话。不要告诉他们你所观察的；相反，首先要询问他们所观察的。这恐怕是你最后一次收集他人对于麻烦制造者行为未过滤反馈的机会；一旦你开始对此事的公开讨论，意见就会分化，没人会记得过去对于此事的想法。如果私下讨论表明至少有其他人也发现了这个问题，则是时候行动了。你应当十分小心，因为很容易给这些人机会让你显得对他们不够公平。无论你做什么，不要指控他们因为偏执狂恶意滥用项目的规程，或者任何你怀疑他们的事情。你的策略是必须保持合理性和对于项目整体利益考虑，以改良个人的行为或使之离开作为目标。取决于其他开发者，以及你与他们的关系，首先在私下里获取同盟者是一个优势。或者如果不是；则只能会暗中的破坏，如果人们认为你正在从事一项不当的政治诽谤活动。要牢记，尽管是另外一个人具有破坏性，但如果你不能支持你的公开指控，那么你就会看起来是那个破坏者。请确保你拥有足够多的实例来描述你所说的，并在直接说出的情况下尽可能的保持礼貌。你可能无法说服有问题的人，但只要能说服所有其他人就足够了。案例学习我只记得一次，在10年的自由软件工作中，事情变得太坏，以至于我们必须要求某人停止发布文章。更常见的情况是，他并不是无礼，只是希望更有益。他只是不知道何时发布何时不发布。我们的邮件列表对公众公开，但是他发布的太频繁，在许多不同的主题中提出问题，成为了社区的噪音问题。我们已经和蔼的告诉他在发表文章前对文章多做一点研究，但是没有效果。最终有效的策略是如何根据中立、定量的数据构建强大案例的完美案例。我们的一个开发者研究了一些归档，然后将如下信息私下发送给了一些开发者。冒犯者（在列表中的姓显示为“J. Random”）在项目中的历史不多，没有贡献任何代码或文档。然而他是邮件列表中第3活跃的用户： From: "Brian W. Fitzpatrick" <fitz@collab.net> To: [... recipient list omitted for anonymity ...] Subject: The Subversion Energy Sink Date: Wed, 12 Nov 2003 23:37:47 -0600 In the last 25 days, the top 6 posters to the svn [dev|users] list have been: 294 kfogel@collab.net 236 "C. Michael Pilato" <cmpilato@collab.net> 220 "J. Random" <jrandom@problematic-poster.com> 176 Branko Čibej <brane@xbc.nu> 130 Philip Martin <philip@codematters.co.uk> 126 Ben Collins-Sussman <sussman@collab.net> 我可以说这些人中的5位会在不久的将来将Subversion带到1.0。我也必须说我们中的一位也在消耗另外5人的时间和精力，更不用说整个邮件列表，因而（虽非故意）也延缓了Subversion的开发。我没有做线索分析但是通过vgrep我的Subversion邮件，我发现此人的每个邮件都会被上面5人中的2人回复过。我觉得有必要做一次根本的干预，即使我们会吓跑前面提到的这个人，和蔼和友好的方法被证明没有效果。 dev@subversion是辅助进行版本库控制系统开发的邮件列表，而不是一个团队心理治疗会议。 -Fitz，尝试从堆积了3天的svn邮件中费力前行尽管一开始还不明显，但J. Random的行为是滥用项目规程的典型案例。他不会像filibuster一个表决那样明显，但是他利用了邮件列表中成员自我评审的政策。我们依赖每个个体的判断。因此，我们没有规程资源可以处理某人是否没有或没有练习这种判断。没有可以让某人指出并说某个家伙违反的规则，但每个人知道他过于频繁的文章已经成为一个严重问题。 Fitz的策略是专横的事后回想。他收集了定量的证据，然后谨慎的将其首先发送给那些在任何过激行动中都会对支持起关键作用的人。他们认可有必要采取行动，最后我们在电话上联系了J. Random，直接描述了这个问题，告知他停止发表文章。他从未真的理解原因；如果能够理解，他可能会尝试首先进行合适的判断练习。但是他认可停止发布文章，邮件列表又变得可用了。这个策略可以发挥作用的部分原因或许是我们可以限制其发表的隐含威胁，我们可以通过软件的审核功能来防止垃圾邮件（看的）。但是我们能够让该选择作为备用的原因是Fitz已经从关键人物那里收集了必要的支持。处理成长开源世界中成功的价值很重。随着你的软件的流行，搜寻信息的人也会急剧增加，而能够提供信息的人则增长的慢很多。此外，即使比率能够保持平衡，在大多数开源项目中处理交流也依然存在基础扩展问题。以邮件列表为例。大多数项目有一个一般用户问题的邮件列表—有时，列表的名称是“users”、“discuss”、“help”或其他。无论名称是什么，列表的目的相同：为人们获取问题的答案提供一个场所，同时其他人可以观看并通过观察这种交换（假设的）获取知识。这种邮件列表可以在数千用户和每天几百文章的情况下工作良好。但之后不久，这个系统就会出现问题，因为每个订阅者看到的文章会超过单个订阅者每天可以处理的数量，这个列表成为了其成员的负担。想象一下，如果微软有一个针对Windows XP的邮件列表。Windows XP有数亿的用户，如果仅有千分之一的用户在24小时内有问题，那么这个假设的列表每天也会有数十万的文章！不可能有这种列表，因为不可能有人会一直订阅它。问题不仅仅限于邮件列表；同样的逻辑也可以应用到IRC频道，在线讨论论坛，以及所有从单个人获取问题的团队。其暗示并不吉利：大规模并行支持的普通开源模型不能扩展到支配全世界的级别。当论坛达到临界点时并不会发生爆炸。只有一个静悄悄的负面反馈效果：人们会取消列表的订阅，或者离开IRC频道，或者不再去咨询问题，因为他们无法去听所有的噪音。因为有越来越多的人作出了理性的选择，论坛的活动会看起来一直处于可管理的级别。但是，它精确的处于可管理级别是因为理性的（或仅仅是有经验的）人会去寻找其他地方获取信息—而缺乏经验的人会留下来继续发表文章。换句话说，随着项目的成长，如果仍使用未扩展的交流模型，那就会产生询问和回答的平均质量逐渐下降的副作用，感觉就好象新用户比原来更呆了，但实际上并不是如此。只是高人口论坛的收益/花费比变得更低，自然那些有经验的人会开始在其他地方寻找答案。根据项目的成长调整交流机制包含两个相关的策略：识别出论坛特定部分，甚至整个论坛正在经历有限制的增长，将这部分分割为新的更专业的论坛（也就是说不要让坏的拖累好的）。确保有许多自动的信息来源，并组织有序、更新及时和易于查找。策略（1）通常并不难。大多数项目有一个主要论坛开始：一个一般的讨论邮件列表，会包含所有的特性构想、设计问题和编码问题。项目的参与者都会在这个列表上。经过一段时间，整个列表就会很清晰的进化为基于不同主题的子列表。例如，一些线索很明显是关于开发和设计；而另外一些是诸如“如何完成X？”的用户问题；或许还有第三类关于如何处理bug报告和增强请求的主题；等等。对于每一个个体，或许会参与到许多不同的线索类型，但是这些类型之间没有过多的重叠。他们可以划分到不同的列表，而不会造成严重的割据问题，因为这些主题极少会跨越主题的边界。实际上这种分割是两步骤的过程。你创建新的列表（或者IRC频道，或任何其他的东西），然后你要花必要的时间有礼貌的唠叨和提醒人们使用新的更合适的论坛。后一个步骤会持续几周，但是最终人们会明白。你只需对所有发送到错误目标的人解释这个问题，然后因为大家都看到得到，人们就会被鼓励例行公事一样去帮助解决。当然，提供一个所有列表的指南网页也非常有用；你的回复可以直接引用网页，然后作为奖励，接收者会在发表文章前通过指南学习到一些东西。策略（2）是一个持续的过程，会伴随项目的一生，需要许多参与者。当然，它部分依赖于是否拥有及时的文档（的），并能够指引人们去观看。但不仅仅如此；这个小节的后面会详细讨论这个策略。归档的显著使用通常来说，开源项目中的所有交流（除了一些IRC的对话）都应该归档。归档应该公开且可搜索，并要具备引用的稳定性：也就是一旦信息记录到了特定的地址，就可以永远使用这个地址。尽可能多的使用那些归档，越显著越好。即使你知道某个问题的答案就在你的脑中，但如果你知道归档中有一个包含此答案的引用，那么请找到并展示出来。每次你使用公开可见的方式完成，有些人就会知道归档，并会在其中寻找答案。另外，通过引用归档而不是重写建议，可以加强对于复制信息的社会标准。为什么同一个答案会出现在不同的地方？当可以找到答案的地方还比较少，人们就更可能会记住地址并再次查找。精心放置的引用也可以帮助改进搜索结果的质量，因为他们可以加强目标资源在互联网搜索引擎中的权重。当然有时复制信息也有意义。例如，在归档中已经有了一个来自别人的回应说：看起来你的Scanley索引开始fronbnicated。为了unfrobnicate，可以按照如下步骤： 1. 关闭Scanley服务器。 2. 运行Scanley的'defrobnicate'程序。 3. 启动服务器。然后，几个月之后，你看到另外一篇文章显示某人的索引变得frobnicated。你搜索归档并发现了上面这个较早的回复，但是你认识到它遗漏了一些步骤（或许是因为误解，也可能是因为软件在那篇文章之后发生了改变）。最经典的方式是发表一篇新文章，更完整的指导，并明确的废弃较早的那篇文章：看起来你的Scanley索引已经变得frobnicated。我们在7月份看到过这个问题，而且J. Random在http://blahblahblah/blah发布过一个解决办法。下面是根据J. Random的指导unfrobnicate你的索引的方法，有一些扩展： 1. 关闭Scanley服务器。 2. 成为通常运行Scanley服务器的用户。 3. 作为该用户，在索引上运行'defrobnicate'程序。 4. 手工运行Scanley，并查看索引是否工作。 5. 重启服务器。（在理想的世界，可以为原来的文章附加一个注释，说明有较新的信息，并指向新文章。然而，我不知道有什么归档软件支持“废弃”特性，或许因为在不违反归档逐条的归档完整性的情况下实现有一点狡猾。这是设置一个专门的网页回答常见问题的另一个原因。）归档可能经常被用来查找技术问题的答案，但是他们对于项目的重要性不仅如此。如果说项目的正式指南的法定法律，那么归档就是不成文法：所有决策如何制定和如何得出的记录。对于任何重现的讨论，从归档搜索开始是义不容辞的。这允许你从当前状态、期望的目标、举反证和发现你没有想到立场的摘要开始讨论。另外，其他参与者会期望你已经做了归档搜索。即使之前的讨论没有结果，在你重新提出这个主题时也要指出它们，这样人们就可以自己看到a) 讨论没有结果，并且b) 你做了功课，那么现在说一些没说过的话吧。将所有的资源视为归档之前的所有建议不只是能应用到邮件列表归档。零散的信息都位于稳定，便利和可查询的地址，这必须成为项目所有信息的组织原则。我们以项目FAQ为例进行研究。人们如何使用FAQ？他们希望在其中查找特定的单词和短语。他们希望进行浏览，获取信息，而不是去寻找特定问题的答案。他们希望诸如Google之类的搜索引擎可以知道FAQ的内容，所以可以搜索到FAQ条目。他们希望在FAQ中直接为其他人提供特定项目的引用。他们希望为FAQ提供新的材料，但是注意到添加比查询回答要少许多—FAQ更多的是阅读，而不是编写。第1点暗示我们FAQ一定要以文本格式存在。第2和第3点暗示FAQ应当以HTML格式存在，第2点也说明HTML必须针对可读性进行设计（即你会希望控制起观感），而且必须有目录。第4点意味着FAQ的每个条目都赋予了一个HTML命名的Anchor，一个用户可以到达页面特定位置的标记。第5点说明FAQ的源文件必须用便利的方法存在（见的），并使用易于编辑的格式。命名的Anchor和ID属性有两种方法可以让浏览器跳到网页的特定位置，命名的Anchor和id属性。命名的anchor只是普通的HTML anchor元素（<a>...</a>），但包含一个“name”属性： <a name="mylabel">...</a> 更多现在版本的HTML都支持原始的id属性，可以附加到任何HTML元素，不仅仅是<a>。例如： <p id="mylabel">...</p> 命名的anchor和id属性以同样的方法应用。通过在URL后追加井号和标签，可以让浏览器直接跳转到页面的定点位置： http://myproject.example.com/faq.html#mylabel 事实上，所有浏览器都支持命名的anchor；绝大多数现代浏览器支持id属性。安全起见，我会建议要么单独使用命名的anchor，要么同时使用命名的anchor和id属性（当然要每一对使用相同的标签）。命名的anchor不能自关闭—即使元素中没有文本，你还是需要写成两部分的形式： <a name="mylabel"></a> ...尽管一般都会有些文本，例如小节的标题。无论你是用命名的anchor、还是id属性、或者两者皆有，请牢记那些没有使用标签的人看不到这些标签。但是这些人会希望知道特定位置的标签，这样他们就可以将某个FAQ的URL发送给自己的朋友。为此，需要为添加了“name”和/或“id”属性的元素添加title属性。 <a name="mylabel" title="#mylabel">...</a> 当鼠标指针移到有title属性的元素时，大多数浏览器会弹出小方框显示这个title。我通常会包含井号，提醒用户这就是添加在URL之后，从而可以在下次直接跳转的该位置。格式化FAQ只是如何让一个资源可以展示出来的例子。同样的属性—直接的咳嗽索性、主要搜索引擎的存在性、可浏览性、引用稳定性和（合适的地方）可编辑性—可以应用到其他网页、源代码树和bug跟踪系统等等。只是在不久之前大多数邮件列表归档软件才认识到了这些属性的重要性，也是邮件列表倾向于本身具备这些功能的原因，其他格式或许需要维护者花费更多的经历（讨论了如何在多个志愿者间分担负担）。编制法律的传统随着项目的日积月累和复杂化，每个新来的参与者必须吸收的数据量大增。那些伴随项目很长时间的人能够根据以前的经历认识到和发明项目的习俗。他们会本能的意识到积累了大量传统，并会为新来者的大量过失而感到惊讶。当然，问题不是新来者的质量降低了；而因为他们面对的是比以前更多的积累负担。一个项目积累的传统取决于他们交流和保存信息的方法，以及他们的编码标准和其他技术备忘录。我们已经看了两种标准，分别在的和的，也都有各自的例子。本小节关注的是如何在项目进化中保持指南的及时性，特别是关于如何管理交流的指南，因为这些指南会随着项目规模和复杂性的成长发生最显著的变化。首先，关注人们陷入混淆的模式。如果你看到同样的情形屡次发生，特别是发生在新参与者身上时，就是需要记录指南的机会了。其次，不要厌烦反复说同样的话，也不要表现出对说这些话的厌烦。你和其他项目老兵都需要经常的重复自己；这是新手到来时不可避免的副作用。每个网页、每个邮件列表信息和每个IRC频道必须考虑广告空间—不是商业广告，而是自己项目资源的广告。你所放置的内容取决于会观看它的人口统计数据。一个针对用户问题的IRC频道，其中通常是那些从未与项目交互的人—通常是只安装了软件，需要立刻获得问题答案的人（毕竟，如果他们可以等待，他们可以发送到邮件列表，整体上他将会花费较少的时间，尽管那样会需要更长的时间得到回答）。人们通常不会在IRC频道作出永久投资，他们会露面，询问问题，然后离开。因而，频道的主题必须针对那些希望立刻寻找软件技术回答的人，而对那些以长期方式参与项目的人，社区交流指南或许更合适。下面是真正忙碌频道的处理方式（的）：你现在位于#linuxhelp 关于#linuxhelp的主题请阅读 http://www.catb.org/~esr/faqs/smart-questions.html && http://www.tldp.org/docs.html#howto 询问问题之前 | 频道规则在http://www.nerdfest.org/lh_rules.html | 升级到内核2.6.x 请看 http://kerneltrap.org/node/view/799 | 内存读可能性: http://tinyurl.com/4s6mc -> 更新到2.6.8.1或2.4.27 | 哈希算法灾难: http://tinyurl.com/6w8rf | reiser4放出在邮件列表中，“广告空间”是追加在每封邮件后的小注脚。大多数项目会在这里放置订阅/取消订阅的指导，也可能是项目主页或FAQ的链接。你或许会认为所有订阅列表的人都会知道如何做，很可能是—但是会有更多不是订阅者的人会看到邮件列表信息。一个归档的文章会被链接到许多地方；实际上，某些文章最终会变得家喻户晓，有远多于列表订阅者的阅读者。格式化可以产生明显的区别。例如，在Subversion项目，我们在的中描述的使用bug过滤技术，取得了有限的成功。经验不足的人会一直发起许多虚假的bug报告，每当发生这种情况，档案管理员必须像他之前的500人那样对此有足够的认识。某天，我们的某个开发者终于忍无可忍，对那些不阅读问题跟踪系统指南的倒霉用户开始发火，另一个开发者则决定这种情况不应该再发生了。他建议重新调整问题跟踪首页的布局，这样最要的部分，也就是在提交之前必须在邮件列表中讨论bug的命令，将会使用较大和粗体红色字体，亮黄色背景，页面居中突出显示处理。我们这样做了（你可以在看到结果），结果是虚假问题的录入率大大降低。我们依然会得到虚假的问题，当然—我们一直会—但是比例显著降低，甚至是在用户数大增的情况下。结果不仅是bug数据库中的垃圾大大减少，而且那些响应问题的人也得到了好情绪，也就更容易在面对罕见的虚假bug时保持友好。这样不仅改善了项目的形象，也改善了志愿者的心理健康。仅仅是写出指导方针的课程对于我们来说还远远不够。我们也必须让最需要的人看到这些东西，它们的状态要像介绍材料一样格式化处理，这样对项目不熟悉的人们也可以立刻清晰明了。静态网页不是发布项目习惯唯一的维纳斯。一定数量的的交互政策（友情提示的感觉，而不是冷冰冰的手铐脚镣）也是必需的。所有的同级评审，甚至的描述的提交评审，都应该包括对于人们是否遵守项目规范的检查，特别是与交流习惯相关的。 Subversion项目的另一个例子：我们在版本控制版本库设定了“r12908”表示“修订版本12908”的习惯。小写的“r”前缀很容易输入，又因为它只有数字的一半高度，所以与数字在一起时非常易于识别。当然，设定了习惯并不意味着每个人都会一直以正确的方式使用它。因而，每当有这样包含日志信息的提交邮件时： ------------------------------------------------------------------------ r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines Patch from J. Random Contributor <jrcontrib@gmail.com> * trunk/contrib/client-side/psvn/psvn.el: Fixed some typos from revision 12828. ------------------------------------------------------------------------ ...某些提交评审者就会说“顺便说一句，请使用‘r12828’，而不是修订版本（revision）12828引用过去的变更。这不是卖弄学问；重要的是自动解析和人类阅读。通过遵循一般的原理，包括对常见实体的权威参考方法，以及必须放之四海皆准参考方法，这个项目输出特定的标准。这些标准使得人们可以编写工具用更有价值的方式展现项目交流—例如，一个格式为“r12828”的修订版本可以在版本库浏览工具中被转化为可用的链接。但是如果修订版本写成“revision 12828”，则这项工作将会难许多，一方面因为链接会在换行处分隔，另一方面也因为限制不足（单词“revision”会经常单独出现，一组数字也会单独出现，而他们的组合“r12828”则只意味着修订版本号码）。类似的，同样的关注面也适应于问题号码，FAQ项目（提示：在描述的，使用命名锚点的URL）等等。即使对于没有简短和权威形式的实体，也要鼓励人们提供一致的关键细节信息。例如，当引用到一个邮件列表信息时，不要只给出发送者和主题；请也给出归档URL和信息的ID头。这样可以让那些虽然自己也有邮件列表拷贝（人们有时会保存离线备份，例如在旅行中使用笔记本时）的人，能够明确无误的定位到正确的信息，甚至无须访问他们自己的归档。发送者和主题并不足够，因为一天里同一个人可能为某一个线索发表过许多文章。项目愈大，愈是需要这类一致性。一致性意味着人们会在所有的地方，看到被以相同的方式遵循的模式，这样他们知道自己也需要遵循这些模式。作为回报，减少了回答问题的必要。拥有几百万读者的负担并不比仅仅一个更大；扩展性的问题源于一定比例的读者开始提问了。随着项目的成长，必须依靠增加信息的密度和可访问性，才能减少这种比例，这样人们才能更容易的找到答案，而无需提问。 Bug跟踪系统中无对话对于积极使用bug跟踪系统的项目，要小心它变成讨论论坛，虽然邮件列表可能更好。通常情况下，它总是很无辜的开始的：某人评论了某个问题，例如提出了一个解决方案或部分补丁。另一个人注意到这个，认为这个方案有些问题，所以附加了另一个评论指出这个问题。第一个人再次回应，对问题作出补充，就这样一直继续下去。这样做的问题是，首先，bug跟踪系统用于讨论时非常的笨拙，其次，其他人可能不会投入关注—毕竟，他们希望在邮件列表中进行开发讨论，这也是他们查找问题的地方。他们可能没有订阅问题变更列表，即使订阅了，也不可能紧跟所有的变化。但是这个过程中到底何时出了差错？是不是那个人将自己的解决方案附加到问题时—她是不是应该发布到列表中？或者是当第二个人直接回复这个问题，而不是在列表回复时。这里没有正确的答案，但是有一般的原理：如果你仅仅是为问题添加数据，那么请在跟踪系统中操作，但是如果你想发起一次对话，那么请到邮件列表。不是每次都能判断出是哪种情况，但是你要作出最佳的判断。例如，当你提交的补丁会包含反对的解决方案时，你应当会预期有人会对此发出质疑。所以，即使你会自然的为该问题附加这个补丁（假定你不希望或者不能直接提交修改），也应当选择将其发布到邮件列表。有一定的可能性，整个交流最终会有得出结果，某一方可能会说应该不仅仅是追加数据，而应该开始一场讨论了—在本小节开头的例子中，也就是第二个回复者，他认识到了补丁的问题，预测到将会有真实的交流发生，因而应该通过更合适的媒介完成。用数学模拟来说，如果根据信息显示问题将会很快收敛，那么直接在bug跟踪系统中发布；如果看起来将会发散，那么邮件列表或IRC频道将会是更好的地方。并不是说在bug跟踪系统中不能有任何交流。例如，向原报告者询问重现的步骤细节就一般是一个很容易收敛的过程。人们的回应并不是提出新的问题，而仅仅是澄清已经记录的问题。没有必要分散邮件列表的注意力；并不一定要通过小心跟踪系统中一系列的评论实现。同样的，如果你认为这个bug是误报的（例如，根本就不是一个bug），你只需要在问题中说出来。甚至指出解决方案中的些许缺陷也没有问题，只要该缺陷不会影响整个解决方案。另一方面，如果你会在bug的范围或软件正确行为方式方面，指出哲学问题，你肯定会认为将有其他开发者参与。讨论也许会发散一段时间，那么请在邮件列表中完成。如果选择了邮件列表，就一直要在问题中保存到邮件列表讨论的链接。对于查看问题的人，能看到对应的讨论是非常重要的，即使问题本身不是讨论的场所。发起这个线索的人会发现有点牵强，但是开源从根本上说就是一种撰写-回应的文化：让成千上万的人读起bug来更容易，远比三五个编写者的麻烦重要的多。如果可以让读者更便利，可以将重要的结论或总结从邮件列表中粘贴到问题中。一个常见的习俗是开始一个列表讨论，在问题中附加讨论线索的链接，然后是讨论结束的时间，粘贴最终的总结（以及包含总结信息的链接），这样浏览此问题的人就可以轻松的看到已经得出的结论，而无需点击到其他地方。需要注意的是，这里不存在重复数据的问题，因为归档和问题回复都是通常是静态的，不会改变的数据。公开性在自由软件中，在纯内部讨论和公开联系声明之间通常有一个相对平滑的连接。这部分因为目标读者一直不明：因为大多数文章都是公开可访问的，项目无法控制整个世界对此的印象。某人—假设是slashdot.org的一个编辑—可能为谋篇文章带来几百万的读者，而本来没人认为它会被项目之外的人看到。这就是开源项目生活的世界，但是在实践中，这种风险通常很小。通常情况下，项目希望公开化的声明就会得到最大的公开化，只要你能用正确的机制指出其对外部世界的新闻价值。对于主要的声明，通常会有4或5个主要分发渠道，所有的声明最好尽可能同时发出：你的项目主页可能是项目中被看得最多的页面。如果你确实有主声明，请在此放一个夸张的广告。这个广告一定是一个简短的概要，可以链接到有更多信息的新闻稿。同一时间，你的站点一定也要有一个“新闻”或“新闻发布”区，可以详细写明声明。新闻稿的部分目的是提供一个单独的权威“声明对象”，这样别的站点可以用来链接，所以要以此为依据确保其结构：要么每个发布一个网页，或每个是一个博客条目，要么其他种类可以被链接的实体，同时与同一区域的其他新闻稿区分开来。如果你的项目有RSS供稿（见），请确保声明也会出现在这里。这也可能在你创建新闻稿时自动发生，取决于你是如何设置的站点。如果声明是软件的新版本，请更新中的项目条目（关于首次创建条目请看）。每当你更新Freshmeat条目时，该条目就会出现在Freshmeat当日的变更列表中。这个变更列表不仅仅会在Freshmeat本身更新，也会出现在许多被很多人关注的门户站点（包括）上。Freshmeat也会通过供稿提供相同的数据，所以即使那些没有订阅你的项目供稿的人，也会通过Freshmeat看到声明。向你的项目声明邮件列表发送一个邮件。这个列表的名称应当是“announce”，例如announce@yourprojectdomain.org，因为现在这已经成为了标准的习惯，而且列表的管理者一定要说明该列表的内容很少，仅用于主要的项目声明。大多数此类声明都是关于软件的新版本，但是偶尔也会其他事件，例如本章后面说的募集资金激励，发现安全漏洞（见），或者项目方向的重大转移，也会发布到这里。因为内容很少，只用于重大事件，所以announce列表通常是项目中订阅最多的列表（当然，这意味着你不要滥用它—发布之前一定要小心）。为了防止其他人，甚至是垃圾邮件发出声明，announce列表应该一直需要审核。要力争在所有的三个地方同时作出声明，越接近越好。人们在邮件列表中看到声明，而在主页或新闻发布区上没有对应的内容时就会感到困惑。如果你能将各方面的（邮件、网页等等）修改排队，并依次发出，你可以将这种时间差控制到最小。对于不太重要的事件，你可以省略上面的某个发布出口。根据事件的重要程度，该事件还是会被外部世界注意到。例如，软件的一个新版本是主要事件，而设定下一次发布的日期，即使有些新闻价值，也不会比发布本身更重要。设定日期值得我们在日常邮件列表（而不是声明列表）中发一个邮件，以及更新项目时间线或网页状态，但仅此而已。然而，你还是会在网上的其他地方的讨论中看到日期。在你的列表中的潜伏者仅仅会听，而不会说任何事，并不一定在其他地方也是沉默的。口碑会造成广泛的传播；你必须考虑到这一点，使用这种方式构建更小的声明，鼓励信息传递的精确性。特别的，你期望引用文章一定要在明确的在引用部分出现，就像你在写正式的新闻稿。例如：

仅仅是进度更新：我们计划在2005年8月中旬发布Scanley的2.0版本。你可以检查http://www.scanley.org/status.html的更新。新特性是正则表达式搜索。其他特性包括： ...也会包含其他bug修正，包括 ...

第一段很简短，仅提供了最重要的信息（发布日期和主要新特性），以及访问进一步新闻的URL。如果某人的屏幕仅出现这个段落，也完成的足够好了。邮件的余下部分可以省略，不会损失内容的要点。当然，有时人们会链接整个邮件，但是更常见的，他们只会引用一小部分。假设后一种的可能性，你所做的也让他们的工作更容易，此外也因为所引用的内容获得了更多的影响力。声明安全漏洞安全漏洞的处理与其他类型bug报告有所不同。在自由软件中，公开透明的工作方式通常几乎是宗教信条。只要你愿意，标准bug处理过程的每个步骤都是可见的：最初到来的报告，实现确认的讨论以及最终的修正。安全bug则有些不同。它们会危及用户数据，甚至是用户的整个电脑。如果公开讨论这个问题，就是将其公示天下—包括那些会恶意利用这个bug的人。甚至仅仅是有效率的提交一个修正宣布bug的存在（会有潜在的攻击者看到公开项目的提交日志，有系统的查找变更，以便在以前的代码中获取安全问题）。大多数开源项目都为公开性和秘密性的冲突准备了相同的处理步骤，基于如下的基本指导方针：在发现修正之前，不要公开谈论bug；然后在宣布bug的同时立刻提供修正。尽可能迅速的完成修正—特别是如果项目外的某人报告了这个bug，因此你知道至少有一个项目外的人能够破解这个漏洞时。在实践中，那些原理会导致一系列标准化的步骤，将会在下面的小节描述。接收报告很明显，人们需要从任何人那里接收安全报告的能力。但是不能用常规的bug报告地址，因为那样所有人都会看到。因此，可以设定一个接收安全bug报告的邮件列表。这个邮件列表一定不要有公共可读的归档，而且必须严格控制其订阅权—只有长期可信的开发者可以在列表上。如果你需要为“可信的”作出正式的定义，可以规定为“所有提交过两年及以上的人”，或类似的，避免偏袒。这将会是处理安全bug的团队。理想状态下，安全列表不应该是垃圾保护的或需要经过审核的，因为你不会希望仅仅因为在周末没有审核者而造成重要的报告被过滤掉或者被延迟。如果你使用自动垃圾邮件保护软件，可以尝试使用较高的容忍设置；允许部分垃圾邮件通过总比漏掉一个报告要好。当然，为了列表的效率，你应当将列表的地址广而告之；但是因为它没有审核，或者只有轻微的防垃圾设置，一定要确保要有邮件地址隐藏的变化，就像中的所说的。幸运的是，地址隐藏不需要将地址变的难以识别；举个例子，可以看，以及该网页的HTML源代码。默默的开发修正当接收到报告时，在安全列表上要怎么做？首要任务是评估问题的严重性和紧急性。漏洞很严重吗？它会造成使用该软件的计算机被恶意攻击接管吗？或者说，是否仅仅会泄漏他们文件大小的信息吗？破解这个漏洞很简单吗？攻击可以脚本化，还是需要环境相关的知识、有意识的猜测甚至运气？谁向你报告了这个问题？当然，这个问题的答案不会改变漏洞的本性，但你可以以此判断有多少人了解此事。如果报告来自于项目自己的开发者，你可以松一口气了（也就一口），因为你可以相信他们不会告诉别人。另一方面，如果是来自类似anonymous14@globalhackerz.net的邮件，你最好立即行动。尽管这个好人提醒了你，但你无法知晓她告诉了多少人，或者她还会等多少时间去破解正式安装系统中的这个漏洞。请注意，我们这里讨论的范围仅仅是紧急和极端紧急之间。即使报告来自于一个已知的、友好的来源，网上的其他人也可能早就发现了这个bug，只是没有报告。唯一不紧急的情况是，bug在本性上不会严重的影响安全。另外，“anonymous14@globalhackerz.net”的例子并不可笑。你可能真的会从隐形身份的人那里得到bug报告，根据他们的词汇和行为，你无法判断他们是否站在你一边。这没有关系：如果他们向你报告了安全漏洞，他们会觉得理应得到好的回报，你应当友好的回应。感谢他们的报告，给他们一个发布修正的时间或截止时间，并与他们保持联系。有时，他们会给你一个日期—那是将在该日期公布bug的威胁的暗示，无论当时你是否已经准备妥当。这看起来像是一种权利的欺凌游戏，但是更像是一种预先的免疫行动，因为之前有对许多令人失望的迟钝的软件制造者，没有将安全报告认真对待。无论如何，你不能对他视而不见，毕竟，如果bug很严重，他拥有的知识会给你带来很大的麻烦。友好的对待这种报告者，希望他们也能投桃报李。另一个安全bug的常见报告者是安全专家，一些长期审核代码并钻研软件漏洞的人。这些人通常精通两个领域—他们不仅会接收，也会发送报告，可能比你项目的大多数开发者都多。他们也通常会为修正某个漏洞设定公布于众的截止日期。截止日期也许可以讨价还价，但是这取决于报告者；截止日期已经成为安全专家唯一认可可靠方法，可以让组织迅速的定位安全问题。所以，不要认为截止日期很野蛮，这是久经考验的传统，这样做有足够的理由。当你知道了严重性和紧急性，你就可以开始修正了。有时，需要在优雅和速度之间做出权衡；这也是为什么在开始前要首先确认紧急性。当然，也要保证讨论仅限于安全列表用户，原始的报告者（如果她希望加入），以及所有因技术原因必须参与的人之间。不要提交修正到版本库。在公开之前，请一直用补丁的形式。如果你准备提交，即使采用了无辜的日志信息，也会让某些人注意到并理解此变更。你永远无法知道谁在关注你的版本库，以及他们感兴趣的原因。关闭提交邮件可能会有些用；但是毕竟提交邮件序列本身会让人起疑，而且数据已经进入了版本库。只应该以补丁的形式完成所有的开发，并保持补丁在私密的地方，也可以是一个单独的独立版本库，只有知晓此bug的人能够知道。（如果你使用分布式的版本控制系统，例如Arch或SVK，你可以在完全版本控制下完成这个工作，只需要保证外来者无法访问此版本库。） CAN/CVE号码你或许看到过随安全问题出现的CAN号码或CVE号码。例如看起来类似“CAN-2004-0397”或“CVE-2002-0092”。两种号码都代表了相同类型的实体：在上维护的“常见漏洞和曝光”列表中的一个条目。这个列表的目的为所有已知的安全问题提供标准化的名称，这样每个人都可以在讨论时使用唯一的标准化的名称，并提供一个可以查找更多信息的中心地点。 “CAN”和“CVE”的唯一区别是前者代表了候选条目，还未经CVE编辑委员会认可，而后者则是经过认可的条目。然后，两种类型的条目都对公众可见，条目的编号不会随着认可而改变—仅仅是“CAN”前缀替换成了“CVE”。 CAN/CVE条目本身并不包含bug的完整描述，以及如何防范的信息。相反，它只会包含一个简短的摘要，然后是到参考和外部资源的列表（例如邮件列表归档），人们可以去查看详细信息。的真正目的是提供一个组织良好的空间，每个漏洞都可以有一个名称以及获取更多信息的途径。一个条目的例子可以看。请注意，引用可以非常的简洁，其中的来源表现为神秘的缩写。这些缩写的关键点可以看。如果你的漏洞达到了CVE的标准，你或许会希望得到一个CAN号码。这个过程是故意封闭的：一般来说，你需要认识某人，或认识某人认识某人。这并不是表面上的那么疯狂。为了避免被伪造的或编写糟糕的提交压垮，CVE编辑委员会只从已知和信任的来源获取提交。然而，为了获取你的漏洞列表，你需要从你的项目找一个CVE编辑委员会认识的人。在你的开发者中询问一下是否认识某人之前曾经完成过CAN过程，或知道某人会认识。这样做的好处是该链路上的某处，某人会知道足够的信息告诉你 a) 根据MITRE的标准，它不会作为漏洞或曝光，所以没有提交的意义，或者 b) 这个漏洞已经有了CAN或CVE号码。后者可能是因为该bug已经在另一个安全忠告列表上发布了，例如位于或者位于的BugTraq邮件列表。（如果是在你的项目对此一无所知的情况下发生了这种情况，你一定会担心还有什么不知道的。）如果你已经得到了CAN/CVE号码，你一定希望尽早将其纳入bug研究中来，这样以后的所有交流都可以引用这个号码。在公布之前，CAN条目会被禁止访问；这个条目会作为占位符保持（这样就不会丢失名称），但不会揭示任何漏洞信息，直到你宣布此bug并修正了它。关于CAN/CVE流程的更多信息可以查看，一个开源项目中使用CAN/CVE号码的例子可以看。预通知一旦你的安全响应团队（那些在安全邮件列表上的开发者，或者那些你认为应该加入到解决特定报告的人）准备好了修正，你就要决定如何描述它。如果仅仅是提交你们的修正到版本库，或者是向全世界宣布，所有使用该软件的人就必须立刻升级，否则就要经受被攻击的风险。有时，更应该对某些特别重要的用户进行预提醒。对于客户端/服务器软件这一点尤其重要，因为也许某些用户的服务器是攻击的诱人目标。那些服务器的管理员也许会对提前一两天进行升级而感到感激，这样他们就可以在破解出现在公众之前做好保护。预提醒的意思是在公布之前向那些管理员发送邮件，告诉他们这些漏洞以及如何修正。一定要确保只向你相信会保守秘密的人发送预提醒。也就是，接收预提醒的资格包括两重意思：接收者一定是在运营一个大的，重要的服务器，影响重大，而且这些接收者也一定不会在公开之前到处乱说这个安全问题。向每个接收者单独（每次一个）发送预提醒邮件。不要一次向整个列表的接收者发送，因为他们会看到其他人的名字—那样意味着告诉了每个接收者他们的服务器有安全漏洞。完全通过暗送（BCC）也不是好方法，因为某些管理员使用垃圾过滤会屏蔽或减少BCC邮件的等级，因为现在有太多使用BCC发送的垃圾邮件。以下是一个预提醒邮件： From: 你的名字 To: admin@large-famous-server.com Reply-to: 你的名字（不要用安全列表地址） Subject: 重要Scanley漏洞提醒。这个邮件是Scanley服务器安全警告的重要预提醒。不要向任何人转发本邮件。公共声明将会在3月19日发布，我们很希望在此之前能够保密此信息。您收到此邮件是因为（我们认为）您运行了Scanley服务器，并希望在19号公布此安全漏洞之前做好补丁。参考： =========== CAN-2004-1771: Scanley查询堆栈溢出漏洞： ============== 如果服务器的locale设置配置错误，而且客户端发送了不合法的查询，会导致可以运行任何命令。严重程度： ========= 非常严重，可以导致服务器上任意代码的执行。周边工作： ============ 在scanley.conf中将'natural-language-processing'选项设置为'off'，可以关闭这个漏洞。补丁： ====== 以下补丁适应于Scanley 3.0、3.1和3.2。一个新的公共版本（Scanley 3.2.1）将会在3月19日发布，同时该漏洞也会公开。你可以现在打补丁，或者等待公开版本。3.2与3.2.1的唯一区别将是此补丁。 [...补丁在这里...] 如果你有CAN号码，即使该信息依然是保密的，它的MITRE页面没有任何内容，也请在预提醒中提供（上面例子中显示的）。包含CAN号码允许接收者可以知晓自己被预提醒的bug正是他们将来可能通过公共渠道获知的bug，这样他们就不必为是否要采取进一步的行动而感到担心，关键点就是CAN/CVE号码。公开分发修正处理安全bug的最后一步是公开分发修订。在一个单独的完整的声明中，你需要描述该问题，如果有CAN/CVE号码，也要提供，描述工作的背景，以及如何永久修正。通常情况下，“修正”意味着将软件升级到新版本，有时也可能是应用一个补丁，特别是如果你的软件以源代码形式运行时。如果你要发布新版本，一定要确保是与现有的某个版本的区别就是安全补丁。使用此方法，保守的管理员就可以作出升级，无需担心会影响其他的功能；他们也不必担心将来的升级，因为安全补丁将会理所当然的出现在未来版本中。（关于发布的详细信息可以看的。）无论公开修正是否包含了新的版本，不要像发布新版本那样粗糙：在项目声明列表中发送一封邮件，发布一个新的新闻稿，更新Freshmeat条目等等。你不应该因为项目的名誉，而试图减弱安全bug的存在性，你应当确立与安全声明问题的严重程度相匹配的基调和突出程度。如果安全漏洞仅仅是轻微的信息暴露，而不会导致用户攻克整个计算机，无需大惊小怪。你甚至会觉得无需为此分散声明列表的注意力。毕竟，如果项目每次都喊狼来了，用户会误以为软件很不安全，而且会在真的有大问题要宣布时不相信你。关于判断严重性的更好的介绍可以看。一般情况下，如果你对如何处理安全问题并不确定，可以找某个更有经验的人讨论一下。评估和处理漏洞更像是一种学习得到的技巧，一开始很容易误入歧途。