提问和回答前请看
徐栖(选书师就是书架的)
I. 提问的智慧 http://www.catb.org/~esr/faqs/smart-questions.html （英文版） https://github.com/ruby-china/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md （中文版） 作者希望大家在网上能搜到的这篇文章都是更新的版本，所以他们鼓励镜像和贴链接而不鼓励静态复制和节选、删改文章。翻译版本则必须负责跟踪英文版本的更新并给出英文版本的链接，所以这里也只给出链接，请发问前先确定你至少浏览了一遍《提问的智慧》。 II. 回答的智慧 原文作者 Andrew Clarke（http://radiofreetooting.blogspot.com/） 原文地址 http://radiofreetooting.blogspot.com/2005/11/how-to-be-good-guru.html “How To Be A Good Guru" （需翻墙） 原文主要是基于 Oracle 数据库及其社区写的，但对 Emacs 社区同样适用。 回答的智慧 1. 不要回答你不知道答案的问题 很明显，要是自己不知道，我们是不会回答的。但要注意我们的知识很容易变得过时，甚至从来没有正确过。比如数据库显式游标的性能并不比隐式的更好，但人们还是建议使用显式游标。如果你贴了什么与事实不符的回答在网上，肯定会有其他人能坏笑着指出你的错误。正确的靠后的回答要比错误的“沙发”更有用。 自行研究寻找你以前不确定或不了解的答案完全可以接受。在论坛上回答问题的好处之一就是我们能发现以前不知道的东西。那些让我们不知所措的问题也许能让我们了解更多有趣（有时甚至有用）的知识。 2. 解释你的回答 Eric Raymond 建议新手把向高手求助作为自己学习过程的一种补充。在邮件列表上提问应该作为新手最后不得已的解决手段。在新手们吸收了集体的智慧，提供了对问题的详细描述，包括完整的环境参数和配置描述，加上他们尝试所有想得到的方法和读过所有相关手册、白皮书等等之后，才来向我们高手寻求最基本的帮助。当然那些只求不劳而获的废柴从不这样做，但我们还是应该有理有节地回应。 简单地给出正确答案是不够的，要试着解释为什么这个答案是正确的。这样提问的人才明白答案为什么正确，下周它就不会再贴一个几乎一样的问题。有可能的话，加上手册相关章节的链接。链接到特定的章节开头比链接到目录要好，但手册并不总是清晰地被划分成小段的。类似地，如果你需要更多的信息来回答问题，要解释你还需要知道什么以及为何需要。如果你需要（比如说）一个数据库的 explain plan 但怀疑提问人不知道这个概念，就给它手册的相关链接。 3. 授人以渔，只提供最低限度的帮助 最有效的学习方法是自己去发现。教人如何检查自己的代码（使用 SQL> SHOW ERROR，查找错误，在文档中查看语法说明）比为它们重写代码要好。特别是在重写代码的过程中我们可能会违背我们不知道的一些行业规则。 4. 展示你的操作过程 当回答与 SQL 有关的问题的时候最好添上一个实际运行的例子。从 SQL*Plus 里复制粘贴文本来展示你的论断的依据。当你自己研究找到答案时尤其应该如此。 如果由于时间和运行环境的限制（比如你无法实际操作一个数据库），可以贴出未测试的代码，但前提是： * 你说明你的困难； * 你认为没有测试过的代码示例也比完全没有代码强； * 你认为它很可能是对的 :p。 一段不能编译的代码是暴露不懂装懂的人最快的证据，所以你一定要确保有把握。 5. 有分寸地使用幽默 论坛的许多用户第一语言不是英语。人们并不总能理解其它文化的幽默。有些提问者在有关工作的场合不期望有人说笑话。此外，即使在说同样语言的用户中，正确地表达幽默也需要借助于身势和表情信号。特别反讽是很难表达的。当然，幽默是能活跃讨论气氛的好东西，所以尽可能做一个聪明的幽默家（但是不聪明的笑话实在是糟透了）。表情符号可以用来表明你前一句话是有意的幽默，即使它算不上高水平的写作。简·奥斯汀反正不上 Oracle 的邮件列表 :) 噢，但是冷嘲热讽可不行。 6. 要是你说不了好话，就不要说 你的母亲也这么告诉过你。 没有愚蠢的问题，只有愚蠢的回答。如果你觉得别人贴出的某个问题不值得回答，那就不用回答。记住：你是自愿的，没有人强迫你，你选择回答这个问题。所以，如果有人提了一个蠢问题浪费你的时间，你给它一个愚蠢（或愤怒或嘲讽或蔑视）的回答就是浪费你自己的时间。想法解释这样的问题不好在哪里，提示怎样更好地表述问题或者要求更多的细节。如果有新手提问“我的代码不起作用”，让它们描述运行时的行为，解释与预想的行为有什么不同，把错误信息和变量数据贴出来（如果有的话）。 如果有人特别不讲道理——在星期六早晨贴出一个“急！！！”的问题然后不断顶贴抱怨没人回复，尽管向它们解释你是个自愿者，论坛是免费服务，也没有产品支持协定。事实上，如果它们真的需要在有限的时间内得到答案，它们就应该大方一点买一个产品支持服务。同时，如果我怀疑发帖人是希望让我做它们作业的学生，我会要求分享它们的学分。 7. 避免使用术语、难懂的缩写和俚语 Fnord。这只是又一种显示你相对提问者的优越感的方式。当然，你如果觉得看你帖子的人能懂，你也可以像使用幽默一样使用术语。或者，加一个术语词典的链接，虽然这么做就失去使用缩写的意义了。LOL。 8. 永远永远不要用“RTFM”回复 叫新手“RTFM”完全是自大的表现。这种回复只满足了回复者的自我而不能让提问者有所收获，除了知难而退不再到论坛提问以外。Barbara Boehmer 告诉了我这一点。要记住 Oracle 的 f**king manual 篇幅浩大，分为数十卷，而在线版的搜索引擎又不是那么好用。最起码，在写“RTFM”的同时给出到该死的手册的相关部分的链接。这样至少提问者下次就知道该到哪里找答案了。 STFW 至少是一样糟，甚至更糟的回答。搜索关于 Oracle 的问题需要许多技巧，不仅要会选择关键词，还要知道哪些结果可以相信。 9. 为将来考虑 今后其它人能通过搜索结果读到你的帖子。当然如果它们用 Oracle Technology Network 的搜索引擎，它们可能是在找完全不同的东西而不会看你的帖子，但 Google 也索引 OTN 论坛。所以注意让你的回答适用范围广一些。此外，像 Jakob Nielsen 提到的，你将来的老板可能也会看。 10. 保持一颗新手的心 我们都曾经是新手。我们对于数据库的某些方面仍然都是新手。一个人的大脑根本不可能知道一切。即使 Tom Kyte 也时不时要向 Sean Dillon，Cameron O'Rourke 等人提问。所以下次你将要给一个“蠢”问题写一篇讽刺的回复的时候要记住：有一天，在某个论坛，你会提一个蠢问题，而一个自大傲慢的家伙会把你拍得无地自容。 ~~~~~~~~~~~~~~~~~~~~~~~ 我个人觉得对于本小组还应加上一条： 11. 不要随意推荐新的不稳定版本和同类软件 当 GNU Emacs 21 向 22 过渡的时候，对于新手请教关于 mule-gbk 的问题，各种论坛和邮件列表上最常见的回复就是“换 22 吧”。现在许多人遇到的问题又开始被“换 23 吧”对付过去。类似地，也有“不要用 Windows 了，换 Linux/BSD 吧”或者“不要用 emacs-wiki 了，换 muse 吧”等等这样的回复。 不是说不能这么回复，但新手在 22.x 的问题没有解决，轻率地没有调查研究就让它们换 23.x 没有解决问题，提问者和回答者没有学到东西，新手在使用新版本的过程中仍然可能遭遇已有的问题和新软件、不稳定版本带来的其它问题，久而久之，大家都只是在折腾新版本，却没有知识的积累。 推荐新版本或者某个系统/软件/扩展的替代品前，请首先确定提问者的问题与旧版本或其软件配置有直接的因果关系，并向提问者说明为什么新版本或替代品能够解决其问题。当然提问者也要提供尽可能详细的软硬件环境和配置信息，以及先尝试自己解决，以便定位问题。
你的回复
回复请先 登录 , 或 注册
相关内容推荐
最新讨论 ( 更多 )
- 小组估计没人了 (人生意义)
- el-get 很好很强大 (J)
- 进入emacs，字体不能正常显示，怎么办？ (dayafterday)
- slime (皱月名)
- 彻底解决 frame size 问题 (皱月名)