发言的礼仪 —— 参与开源社区

仔细聆听别人的声音，也努力表达自己对技术的看法，并随时将你的宝贵经验与社区分享 ，这样你不仅能获得技术上的提高，还可以得到整个社区的认可和尊敬。  

14.4.3 发言的礼仪

通过适当的礼仪和友好的行为方式，可以更有效地通过邮件列表解决项目中的问题。 Eric Raymond 对此有非常精彩的讨论，见其《 提问的智慧 》一文，以下部分观点就来自于该文。

1.        提问

新加入一个社区总有许多东西是你不了解的，通常我们会阅读手册和源代码解决大部分的疑问 。但仅靠个人，总有无法解答的问题，在邮件列表上提问是更直接有效的解决问题的方式。

社区的开发者总是乐意帮助别人解答问题的，虽然黑客通常有遇到简单问题就表现出敌视或傲慢的名声，但事情并非如此。他们只是毫无歉意地敌视那些提问前不愿思考、不愿付出的人。 因此你不必在技术上很在行才能吸引注意，但表现出希望解决问题的正确态度，积极主动参与问题的解决 。

在提问前，请先尝试通过以下方式获取答案（非常不错的解决问题套路！我平时就是按照这个思路的，强烈建议你也尝试着将它变成一种习惯！ ） ：

（1）      尝试阅读手册 以找到答案。

（2）      尝试阅读“常见问答 ”（ FAQ ）以找到答案。

（3）      尝试在你准备提问的邮件列表的历史文档 中搜索答案。

（4）      尝试搜索互联网 （用 www.google.com 搜索的资料要好于其它 Google 搜索 ，例如 www.google.com.hk ）以找到答案。

如果还是没有找到答案，你就可以着手撰写邮件求助了：

首先要选择一个清晰、明确的标题 。如果项目有预定义的标签，选择合适的标签可以让你更容易地找到该领域的专家。开发者 每天要处理大量的邮件，他们不可能仔细地阅读每一封邮件的内容，他们往往通过标题来判断是否对该主题感兴趣 。因此，在标题中简单扼要的概括问题，能更好地帮助你吸引对此在行的人 。而“紧急！！”、“请帮我！！”之类的唠叨，除了帮你博取更多的同情之外，并不能加速解决问题。

接下来，需要详细、完整、客观的描述问题的症状，以及问题发生的环境 ，比如操作系统、软件版本、重现步骤等。如果你在提问前做了初步的诊断和研究，在描述完问题之后，描述你为定位问题所采取的诊断步骤。但一定要说清楚，哪些是客观情况，哪些是你的推理和猜测，避免造成人们混淆猜测和真正的症状，从而无法准确地判断问题产生的原因。一般你的猜测对解决问题不会有太大帮助，确保只描述问题的原始症状，让社区的专家来解释和诊断。

在开头就描述你要实现的目标，然后才陈述遇到问题的特定步骤。 很多时候寻求技术帮助的人在实现其目标的过程中被某个具体的问题卡住了，然后跑来问这个问题该如何解决，他可能根本没有意识到自己的方法是错误，结果在错误的道路上被错误的问题浪费了不必要的时间和精力。

刚出问题之前发生的事情通常 包含解决问题的关键线索 。所以应准确地描述你及电脑在发生问题之前都做了些什么。日志对解决问题是非常有帮助的 （ 完全赞同！ ） ，试着选取适当的日志级别以便提供更有用的信息 ，而不是将阅读者淹没在无用的信息中。

如果你要讨论代码中的问题，在张贴代码时应当附加一定的说明和注释。没有人愿意去阅读没头没尾的问题代码，随手张贴几百行的代码，然后说一声“它不能运行”，这样让别人无从下手，你也无法获得帮助。增加必要的注释和说明能有助于其他人对这段代码的理解。对于专家来说代码的背景和目的更加重要，由此可以找到最有可能出问题的部分。

最后，问题解决后应该追加一条消息，让他们知道问题是如何解决的并表示感谢。 如果其他人将来也遇到类似的问题，可以尝试编一份文档或常见问答补丁并发送给维护者。这种良好的后继行为并不仅仅是出于礼貌，也是你善待他人而赢得声誉的方式。

2.        回答问题

前面我们看到提问时是需要智慧的，但实际上回答问题更需要智慧。就像一个好的老师对学生的重要性。在社区中常常有这样的人，他们可能并不知道你提出的问题的正确答案，但往往能提出一些建议性的意见，帮助你找到正确的答案 。下面的几点可能会对你成为一个好的回答问题者 有所帮助。

（1）      耐心

尽管到处都在强调提问的智慧，但总是会有 RTFM 的问题。当然对那些懒虫报怨一声 RTFM 无可厚非，但如果可以指出文档的具体位置，或者建议谷歌搜索的关键词 （ 自己已经在尝试着这样做了，非常好！ ） ，会更好！

对于专家显而易见的概念在初学者看来可能就是天书。尝试用通俗易懂的语言解释和描述技术性的问题 ，帮助初学者更快地融入社区的工作。友善的社区氛围总是能吸引更多开发者的参与，从而扩大项目的影响力。

（2）      启发式的反问

启发式的反问往往可以将很差的提问转变成好提问 ，从而吸引更多人的思考与讨论，提问者也可以从中学到更多的东西，下次的问题就会变得更好 。

（3）      授人以渔

获得答案的过程往往比结果更重要。 如果结论并不是显而易见，在回答时描述你获得答案的方法和过程，不仅有助于提问者理解，还可以做到“授人以渔”。

3.        讨论问题

开源项目中的技术决策不仅是开放的，也是民主的。针对一个技术问题，开发者会提出各自的观点和解决方案。对各种方案的优劣进行详细的讨论和比较 ，一般会得出一个令大多数人都满意的方案。 如果有多个方案争执不下，最后会通过投票做最后的决定。

在邮件列表中讨论问题是开发开源项目必不可少的。在 Linux Kernel 的邮件列表上经常会看到人们对某个问题热烈的讨论，回复经常达到上百封，其中不乏数十页的长篇大论。这就是开源项目的工作方式，聆听每个人的声音，汇集所有人的智慧。

（1）      坦率地表达自己的观点

只要是合理、可行的观点都会被采纳。不要担心自己的观点是否幼稚，或者与社区中某个资深开发者的观点相左而保留你的观点。社区需要每个参与者的声音，在社区中所以参与者都是平等的，坦率地表达你的观点在任何时候对社区都是有益的。

（2）     提出建设性的意见

如果你的回复仅仅是指出对方拼写或语法上的错误，请不要将它发送出去。这对解决问题没有任何帮助，只是在浪费别人的时间和带宽。

（3）      只针对问题本身

永远不要针对个人。你永远也不知道电脑的另一头坐着一个怎样的人，不要对此妄下断言。关注问题本身及如何解决问题，与之无关的东西都可以丢到一边。

（4）      避免情绪化的措辞

确保点下“发送”按钮的时候你处于冷静的状态。情绪化的措辞除了带来无意义的争吵外，对社区没有任何意义。

（5）      对待无礼

大多数情况下，社区中看似无礼的行为并不是存心冒犯。相反，它是直截了当、一针见血的交流风格，他们更关注解决问题而不是使别人感觉舒服（表达方式不同，但目的是出于好心。所以，要懂得多体谅别人！目前，自己也有这样的不好习惯，平时要有意识地改正哦！ ）。 如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，不予回应就是最好的回应。

 

参考资料： 提问的智慧

 

摘自：《开源软件之道》 14.4.3 发言的礼仪