How-To-Ask-Questions-The-Smart-Way.tar.gz

一个更简单的<<提问的智慧>>, 缓解 TL; DR

话不在多而在精

1. 表现出你为解决问题做过的努力, 愿意在找答案的过程中做点什么, 越有可能得到帮助
2. 不要在太多的不同群组上重复转贴同样的问题（cross-post）, 别像机关枪似的一次"扫射"所有的帮助渠道, 这就像大喊大叫一样会使人不快
3. 在即时聊天软件(如QQ)寻求帮助，最好不要发布很长的问题描述，有些人称之为频道洪水. 最好通过一句话的问题描述来开始聊天
4. 在邮件列表或论坛中, 大约 50 字以内的标题是抓住资深专家注意力的好机会

选择提问对象

5. 当某个项目提供开发者邮件列表时, 要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题
6. 如果一个项目既有"使用者"也有"开发者"板块, 非代码问题向"使用者"列表或论坛提问.
   不要假设自己会在开发者列表中受到欢迎，那些人多半会将你的提问视为干扰他们开发的噪音
7. 张贴前最好先暗地里观察几天以了解那里的行事方式

确定提问内容

8. 别用喋喋不休的"帮帮忙、跪求、急", 这样让人反感的话(用这种标题会被条件反射式地忽略) 来浪费这个机会.
9. 避免用无意义的额外提问，例如"有人能帮我吗？". 除非你想得到是或否类型的回答。例如：没错，没有人能帮你
10. 如果在非母语的论坛提问, 你可以犯点拼写和语法上的小错, 但决不能在思考上马虎 (没错，我们通常能弄清两者的分别)
    提示潜在回复者你有潜在的语言困难是很好的:

    English is not my native language; please excuse typing errors.

    • 英文不是我的母语, 请原谅我的错字或语法
11. 描述问题症状而非你的猜测
    告诉大佬们你认为问题是怎样造成的并没什么帮助. (如果你的推断如此有效，还用向别人求助吗？)
    你应当将你的推测付诸实践(如果这不是不可挽回的), 然后说明你做了什么尝试
12. 描述目标而不是过程
    如果你想弄清楚如何做某事(而不是报告一个 Bug), 在开头就描述你的目标, 然后才陈述重现你所卡住的特定步骤
13. 一个好标题范例是 目标 —— 差异式 的描述

提升人际交往能力

14. 彬彬有礼, 多用"请"和"谢谢您的关注", 或"谢谢你的关照". 让大家都知道你对他们花时间免费提供帮助心存感激

15. 如果你觉得被冒犯了, 试着平静地反应.
    如果有人真的做了出格的事, 邮件列表、群组或论坛中的前辈多半会招呼他.
    如果这没有发生而你却发火了, 那么你发火对象的言语可能在社区中看起来是正常的.
    而你将被视为有错的一方, 这将伤害到你获取信息或帮助的机会

    绝不要自以为够格得到答案, 你没有; 你并没有. 毕竟你没有为这种服务支付任何报酬.
    你将会是自己去挣到一个答案, 靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题, 而不仅仅是被动的从他人处索取知识