mirror of
https://github.com/yunfei-dev/How-To-Ask-Questions-The-Smart-Way.git
synced 2025-02-25 21:04:04 +08:00
Ryan Wu
GitHub
commit
2128e06701
144
README-zh_CN.md
144
README-zh_CN.md
@ -6,13 +6,13 @@ Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen
|
||||
|
||||
本指南英文版版权为 Eric S. Raymond, Rick Moen 所有。
|
||||
|
||||
原文网址:[http://www.catb.org/~esr/faqs/smart-questions.html](http://www.catb.org/~esr/faqs/smart-questions.html)
|
||||
原文网址：[http://www.catb.org/~esr/faqs/smart-questions.html](http://www.catb.org/~esr/faqs/smart-questions.html)
|
||||
|
||||
Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
|
||||
|
||||
本中文指南是基于原文 3.10 版以及 2010 年由 [Gasolin](https://github.com/gasolin) 所翻译版本的最新翻译；
|
||||
|
||||
协助指出翻译问题，__请[发Issue](https://github.com/ryanhanwu/smartquestions/issues/new)，或直接[发Pull Request](https://github.com/ryanhanwu/smartquestions/compare/)给我。__
|
||||
协助指出翻译问题，__请[发 Issue](https://github.com/ryanhanwu/smartquestions/issues/new)，或直接[发 Pull Request](https://github.com/ryanhanwu/smartquestions/compare/) 给我。__
|
||||
|
||||
本文另有[繁體中文版](https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/master/README.md)。
|
||||
|
||||
@ -25,7 +25,7 @@ Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
|
||||
* [当你提问时](#当你提问时)
|
||||
* [慎选提问的论坛](#慎选提问的论坛)
|
||||
* [Stack Overflow](#stack-overflow)
|
||||
* [网站和IRC论坛](#网站和irc论坛)
|
||||
* [网站和 IRC 论坛](#网站和-irc-论坛)
|
||||
* [第二步，使用项目邮件列表](#第二步使用项目邮件列表)
|
||||
* [使用有意义且描述明确的标题](#使用有意义且描述明确的标题)
|
||||
* [使问题容易回复](#使问题容易回复)
|
||||
@ -33,7 +33,7 @@ Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
|
||||
* [使用易于读取且标准的文件格式发送问题](#使用易于读取且标准的文件格式发送问题)
|
||||
* [精确的描述问题并言之有物](#精确的描述问题并言之有物)
|
||||
* [话不在多而在精](#话不在多而在精)
|
||||
* [别动辄声称找到Bug](#别动辄声称找到bug)
|
||||
* [别动辄声称找到 Bug](#别动辄声称找到-bug)
|
||||
* [可以低声下气，但还是要先做功课](#可以低声下气但还是要先做功课)
|
||||
* [描述问题症状而非猜测](#描述问题症状而非猜测)
|
||||
* [按发生时间先后列出问题症状](#按发生时间先后列出问题症状)
|
||||
@ -47,7 +47,7 @@ Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
|
||||
* [礼多人不怪，而且有时还很有帮助](#礼多人不怪而且有时还很有帮助)
|
||||
* [问题解决后，加个简短的补充说明](#问题解决后加个简短的补充说明)
|
||||
* [如何解读答案](#如何解读答案)
|
||||
* [RTFM和STFW：如何知道你已完全搞砸了](#rtfm和stfw如何知道你已完全搞砸了)
|
||||
* [RTFM 和 STFW：如何知道你已完全搞砸了](#rtfm-和-stfw如何知道你已完全搞砸了)
|
||||
* [如果还是搞不懂](#如果还是搞不懂)
|
||||
* [处理无礼的回应](#处理无礼的回应)
|
||||
* [如何避免扮演失败者](#如何避免扮演失败者)
|
||||
@ -60,13 +60,13 @@ Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
|
||||
|
||||
##声明
|
||||
|
||||
许多项目在他们的使用协助/说明网页中链接了本指南，这么做很好，我们也鼓励大家都这么做。但如果你是负责管理这个项目网页的人，请在超链接附近的显着位置上注明：
|
||||
许多项目在他们的使用协助/说明网页中链接了本指南，这么做很好，我们也鼓励大家都这么做。但如果你是负责管理这个项目网页的人，请在超链接附近的显著位置上注明：
|
||||
|
||||
__本指南不提供此项目的实际支持服务！__
|
||||
|
||||
我们已经深刻领教到少了上述声明所带来的痛苦。因为少了这点声明，我们不停地被一些白痴纠缠。这些白痴认为既然我们发布了这本指南，那么我们就有责任解决世上所有的技术问题。
|
||||
|
||||
如果你是因为需要某些协助而正在阅读这本指南，并且最后离开是因为发现从本指南作者们身上得不到直接的协助，那么你就是我们所说的那些白痴之一。别问我们问题，我们只会忽略你。我们在这本指南中是教你如何从那些真正懂得你所遇到软件或硬件问题的人取得协助，而99%的情况下那不会是我们。除非你确定本指南的作者之一刚好是你所遇到的问题领域的专家，否则请不要打扰我们，这样大家都会开心一点。
|
||||
如果你是因为需要某些协助而正在阅读这本指南，并且最后离开是因为发现从本指南作者们身上得不到直接的协助，那么你就是我们所说的那些白痴之一。别问我们问题，我们只会忽略你。我们在这本指南中是教你如何从那些真正懂得你所遇到软件或硬件问题的人取得协助，而 99% 的情况下那不会是我们。除非你确定本指南的作者之一刚好是你所遇到的问题领域的专家，否则请不要打扰我们，这样大家都会开心一点。
|
||||
|
||||
##简介
|
||||
|
||||
@ -102,13 +102,13 @@ __本指南不提供此项目的实际支持服务！__
|
||||
1. 尝试阅读常见问题文件（FAQ）以找到答案。
|
||||
1. 尝试自己检查或试验以找到答案
|
||||
1. 向你身边的强者朋友打听以找到答案。
|
||||
1. 如果你是程序开发者，请尝试阅读源代码以找到答案
|
||||
1. 如果你是程序开发者，请尝试阅读源代码以找到答案。
|
||||
|
||||
当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所**_学到_**的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。
|
||||
|
||||
运用某些策略，比如先用Google搜索你所遇到的各种错误信息（既搜索[Google论坛](http://groups.google.com/)，也搜索网页），这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果，在邮件列表或新闻组寻求帮助时加上一句 ```我在Google中搜过下列句子但没有找到什么有用的东西``` 也是件好事，即使它只是表明了搜索引擎不能提供哪些帮助。这么做（加上搜索过的字串）也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。
|
||||
运用某些策略，比如先用 Google 搜索你所遇到的各种错误信息（既搜索 [Google 论坛](http://groups.google.com/)，也搜索网页），这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果，在邮件列表或新闻组寻求帮助时加上一句 ```我在 Google 中搜过下列句子但没有找到什么有用的东西``` 也是件好事，即使它只是表明了搜索引擎不能提供哪些帮助。这么做（加上搜索过的字串）也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。
|
||||
|
||||
别着急，不要指望几秒钟的Google搜索就能解决一个复杂的问题。在向专家求助之前，再阅读一下常见问题文件（FAQ）、放轻松、坐舒服一些，再花点时间思考一下这个问题。相信我们，他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑拋出，只因你的第一次搜索没有找到答案（或者找到太多答案）。
|
||||
别着急，不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前，再阅读一下常见问题文件（FAQ）、放轻松、坐舒服一些，再花点时间思考一下这个问题。相信我们，他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑拋出，只因你的第一次搜索没有找到答案（或者找到太多答案）。
|
||||
|
||||
准备好你的问题，再将问题仔细的思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。
|
||||
|
||||
@ -131,15 +131,15 @@ __本指南不提供此项目的实际支持服务！__
|
||||
|
||||
黑客会剔除掉那些搞错场合的问题，以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。
|
||||
|
||||
因此，第一步是找到对的论坛。再说一次，Google和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括**_阅读_**FAQ）都没有结果，网站上也许还有报告Bug（Bug-reporting）的流程或链接，如果是这样，连过去看看。
|
||||
因此，第一步是找到对的论坛。再说一次，Google 和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括**_阅读_** FAQ）都没有结果，网站上也许还有报告 Bug（Bug-reporting）的流程或链接，如果是这样，连过去看看。
|
||||
|
||||
向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说，别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 -- 如果你不确定，那就向别处发送，或者压根别发。
|
||||
|
||||
在选择论坛、新闻群组或邮件列表时，别太相信名字，先看看FAQ或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题，这样可以让你感受一下那里的文化。事实上，事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意，也许这样就找到答案了。即使没有，也能帮助你归纳出更好的问题。
|
||||
在选择论坛、新闻群组或邮件列表时，别太相信名字，先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题，这样可以让你感受一下那里的文化。事实上，事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意，也许这样就找到答案了。即使没有，也能帮助你归纳出更好的问题。
|
||||
|
||||
别像机关枪似的一次"扫射"所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。
|
||||
|
||||
搞清楚你的主题！最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于Unix或Windows操作系统程序界面的问题。如果你不明白为什么这是大错，最好在搞清楚这之间差异之前什么也别问。
|
||||
搞清楚你的主题！最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错，最好在搞清楚这之间差异之前什么也别问。
|
||||
|
||||
一般来说，在仔细挑选的公共论坛中提问，会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点，一是看潜在的回复者有多少，二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。
|
||||
|
||||
@ -159,7 +159,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
* Stack Overflow 是问写程序有关的问题。
|
||||
* Server Fault 是问服务器和网管相关的问题。
|
||||
|
||||
### 网站和IRC论坛
|
||||
### 网站和 IRC 论坛
|
||||
|
||||
本地的使用者群组（user group），或者你所用的 Linux 发行版本也许正在宣传他们的网页论坛或 IRC 频道，并提供新手帮助（在一些非英语国家，新手论坛很可能还是邮件列表）， 这些地方是开始提问的好首选，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。有广告赞助的 IRC 频道是公开欢迎提问的地方，通常可以即时得到回应。
|
||||
|
||||
@ -169,7 +169,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
|
||||
通过论坛或 IRC 频道来提供使用者支持服务有增长的趋势，电子邮件则大多为项目开发者间的交流而保留。所以最好先在论坛或 IRC 中寻求与该项目相关的协助。
|
||||
|
||||
在使用IRC的时候,首先最好不要发布很长的问题描述，有些人称之为频道洪水。最好通过一句话的问题描述来开始聊天。
|
||||
在使用 IRC 的时候，首先最好不要发布很长的问题描述，有些人称之为频道洪水。最好通过一句话的问题描述来开始聊天。
|
||||
|
||||
### 第二步，使用项目邮件列表
|
||||
|
||||
@ -188,22 +188,22 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
|
||||
### 使用有意义且描述明确的标题
|
||||
|
||||
在邮件列表、新闻群组或论坛中，大约50字以内的标题是抓住资深专家注意力的好机会。别用喋喋不休的```帮帮忙```、```跪求```、```急```（更别说```救命啊！！！！```这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。不要妄想用你的痛苦程度来打动我们，而是在这点空间中使用极简单扼要的描述方式来提出问题。
|
||||
在邮件列表、新闻群组或论坛中，大约 50 字以内的标题是抓住资深专家注意力的好机会。别用喋喋不休的```帮帮忙```、```跪求```、```急```（更别说```救命啊！！！！```这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。不要妄想用你的痛苦程度来打动我们，而是在这点空间中使用极简单扼要的描述方式来提出问题。
|
||||
|
||||
一个好标题范例是```目标 -- 差异```式的描述，许多技术支持组织就是这样做的。在```目标```部分指出是哪一个或哪一组东西有问题，在```差异```部分则描述与期望的行为不一致的地方。
|
||||
|
||||
|
||||
> 蠢问题：救命啊！我的笔电不能正常显示了！
|
||||
|
||||
> 聪明问题：X.org 6.8.1的鼠标游标会变形，某牌显卡 MV1005 芯片组。
|
||||
> 聪明问题：X.org 6.8.1 的鼠标游标会变形，某牌显卡 MV1005 芯片组。
|
||||
|
||||
> 更聪明问题：X.org 6.8.1的鼠标游标，在某牌显卡 MV1005 芯片组环境下 - 会变形。
|
||||
> 更聪明问题：X.org 6.8.1 的鼠标游标，在某牌显卡 MV1005 芯片组环境下 - 会变形。
|
||||
|
||||
编写```目标 -- 差异``` 式描述的过程有助于你组织对问题的细緻思考。是什么被影响了？ 仅仅是鼠标游标或者还有其它图形？只在 X.org 的 X 版中出现？或只是出现在6.8.1版中？ 是针对某牌显卡芯片组？或者只是其中的 MV1005 型号？ 一个黑客只需瞄一眼就能够立即明白你的环境**_和_**你遇到的问题。
|
||||
编写```目标 -- 差异``` 式描述的过程有助于你组织对问题的细致思考。是什么被影响了？ 仅仅是鼠标游标或者还有其它图形？只在 X.org 的 X 版中出现？或只是出现在 6.8.1 版中？ 是针对某牌显卡芯片组？或者只是其中的 MV1005 型号？ 一个黑客只需瞄一眼就能够立即明白你的环境**_和_**你遇到的问题。
|
||||
|
||||
总而言之，请想像一下你正在一个只显示标题的存档讨论串（Thread）索引中查寻。让你的标题更好地反映问题，可使下一个搜索类似问题的人能够关注这个讨论串，而不用再次提问相同的问题。
|
||||
|
||||
如果你想在回复中提出问题，记得要修改内容标题，以表明你是在问一个问题， 一个看起来像 ```Re: 测试``` 或者 ```Re: 新bug``` 的标题很难引起足够重视。另外，在不影响连贯性之下，适当引用并删减前文的内容，能给新来的读者留下线索。
|
||||
如果你想在回复中提出问题，记得要修改内容标题，以表明你是在问一个问题， 一个看起来像 ```Re: 测试``` 或者 ```Re: 新 bug``` 的标题很难引起足够重视。另外，在不影响连贯性之下，适当引用并删减前文的内容，能给新来的读者留下线索。
|
||||
|
||||
对于讨论串，不要直接点击回复来开始一个全新的讨论串，这将限制你的观众。因为有些邮件阅读程序，比如 mutt ，允许使用者按讨论串排序并通过折叠讨论串来隐藏消息，这样做的人永远看不到你发的消息。
|
||||
|
||||
@ -223,9 +223,9 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
|
||||
正确的拼字、标点符号和大小写是很重要的。一般来说，如果你觉得这样做很麻烦，不想在乎这些，那我们也觉得麻烦，不想在乎你的提问。花点额外的精力斟酌一下字句，用不着太僵硬与正式 -- 事实上，黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它**_必须很_**准确，而且有迹象表明你是在思考和关注问题。
|
||||
|
||||
正确地拼写、使用标点和大小写，不要将```its```混淆为```it's```，```loose```搞成```lose```或者将```discrete```弄成```discreet```。不要**全部用大写**，这会被视为无礼的大声嚷嚷（全部小写也好不到哪去，因为不易阅读。[Alan Cox](http://en.wikipedia.org/wiki/Alan_Cox)也许可以这样做，但你不行。）
|
||||
正确地拼写、使用标点和大小写，不要将```its```混淆为```it's```，```loose```搞成```lose```或者将```discrete```弄成```discreet```。不要**全部用大写**，这会被视为无礼的大声嚷嚷（全部小写也好不到哪去，因为不易阅读。[Alan Cox](http://en.wikipedia.org/wiki/Alan_Cox) 也许可以这样做，但你不行。）
|
||||
|
||||
更白话的说，如果你写得像是个半文盲[译注：[小白](http://zh.wikipedia.org/zh-tw/小白)]），那多半得不到理睬。也不要使用即时通讯中的简写或[火星文](http://zh.wikipedia.org/zh-tw/火星文)，如将```的```简化为```ㄉ```会使你看起来像一个为了少打几个键而省字的小白。更糟的是，如果像个小孩似地鬼画符那绝对是在找死，可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）。
|
||||
更白话的说，如果你写得像是个半文盲[译注：[小白](http://zh.wikipedia.org/zh-tw/小白)]，那多半得不到理睬。也不要使用即时通讯中的简写或[火星文](http://zh.wikipedia.org/zh-tw/火星文)，如将```的```简化为```ㄉ```会使你看起来像一个为了少打几个键而省字的小白。更糟的是，如果像个小孩似地鬼画符那绝对是在找死，可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）。
|
||||
|
||||
如果在使用非母语的论坛提问，你可以犯点拼写和语法上的小错，但决不能在思考上马虎（没错，我们通常能弄清两者的分别）。同时，除非你知道回复者使用的语言，否则请使用英语书写。繁忙的黑客一般会直接删除用他们看不懂语言写的消息。在网络上英语是通用语言，用英语书写可以将你的问题在尚未被阅读就被直接删除的可能性降到最低。
|
||||
|
||||
@ -258,31 +258,31 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
|
||||
如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以：
|
||||
|
||||
* 使用纯文字而不是HTML ([关闭HTML](http://archive.birdhouse.org/etc/evilmail.html)并不难）
|
||||
* 使用MIME附件通常是可以的，前提是真正有内容（譬如附带的源代码或patch），而不仅仅是邮件程序生成的模板（譬如只是信件内容的拷贝）。
|
||||
* 不要发送一段文字只是一行句子但自动换行后会变成多行的邮件（这使得回复部分内容非常困难）。设想你的读者是在80个字符宽的终端机上阅读邮件，最好设置你的换行分割点小于80字。
|
||||
* 使用纯文字而不是 HTML ([关闭 HTML](http://archive.birdhouse.org/etc/evilmail.html) 并不难）。
|
||||
* 使用 MIME 附件通常是可以的，前提是真正有内容（譬如附带的源代码或 patch），而不仅仅是邮件程序生成的模板（譬如只是信件内容的拷贝）。
|
||||
* 不要发送一段文字只是一行句子但自动换行后会变成多行的邮件（这使得回复部分内容非常困难）。设想你的读者是在 80 个字符宽的终端机上阅读邮件，最好设置你的换行分割点小于 80 字。
|
||||
* 但是，对一些特殊的文件**_不要_**设置固定宽度（譬如日志档案拷贝或会话记录）。数据应该原样包含，让回复者有信心他们看到的是和你看到的一样的东西。
|
||||
* 在英语论坛中，不要使用```Quoted-Printable``` MIME编码发送消息。这种编码对于张贴非ASCII语言可能是必须的，但很多邮件程序并不支持这种编码。当它们处理换行时，那些文本中四处散布的```=20```符号既难看也分散注意力，甚至有可能破坏内容的语意。
|
||||
* 绝对，**_永远_**不要指望黑客们阅读使用封闭格式编写的文档，像微软公司的Word或Excel文件等。大多数黑客对此的反应就像有人将还在冒热气的猪粪倒在你家门口时你的反应一样。即便他们能够处理，他们也很厌恶这么做。
|
||||
* 如果你从使用Windows的电脑发送电子邮件，关闭微软愚蠢的```智能引号```功能 （从[选项] > [校订] > [自动校正选项], 勾选掉```智能引号```单选框），以免在你的邮件中到处散布垃圾字符。
|
||||
* 在英语论坛中，不要使用```Quoted-Printable``` MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的，但很多邮件程序并不支持这种编码。当它们处理换行时，那些文本中四处散布的```=20```符号既难看也分散注意力，甚至有可能破坏内容的语意。
|
||||
* 绝对，**_永远_**不要指望黑客们阅读使用封闭格式编写的文档，像微软公司的 Word 或 Excel 文件等。大多数黑客对此的反应就像有人将还在冒热气的猪粪倒在你家门口时你的反应一样。即便他们能够处理，他们也很厌恶这么做。
|
||||
* 如果你从使用 Windows 的电脑发送电子邮件，关闭微软愚蠢的```智能引号```功能 （从[选项] > [校订] > [自动校正选项]，勾选掉```智能引号```单选框），以免在你的邮件中到处散布垃圾字符。
|
||||
* 在论坛，勿滥用```表情符号```和```HTML```功能（当它们提供时）。一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来像个傻笑的小姑娘。这通常不是个好主意，除非你只是对性而不是对答案感兴趣。
|
||||
|
||||
如果你使用图形用户界面的邮件程序（如微软公司的Outlook或者其它类似的），注意它们的默认设置不一定满足这些要求。大多数这类程序有基于选单的```查看源代码```命令，用它来检查发送文件夹中的邮件，以确保发送的是纯文本文件同时没有一些奇怪的字符。
|
||||
如果你使用图形用户界面的邮件程序（如微软公司的 Outlook 或者其它类似的），注意它们的默认设置不一定满足这些要求。大多数这类程序有基于选单的```查看源代码```命令，用它来检查发送文件夹中的邮件，以确保发送的是纯文本文件同时没有一些奇怪的字符。
|
||||
|
||||
### 精确的描述问题并言之有物
|
||||
|
||||
* 仔细、清楚地描述你的问题或Bug的症状。
|
||||
* 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：```Fedora Core 4```、```Slackware 9.1```等）。
|
||||
* 描述在提问前你是怎样去研究和理解这个问题的。
|
||||
* 描述在提问前为确定问题而采取的诊断步骤。
|
||||
* 描述最近做过什么可能相关的硬件或软件变更。
|
||||
* 尽可能的提供一个可以```重现这个问题的可控环境```的方法
|
||||
* 仔细、清楚地描述你的问题或 Bug 的症状。
|
||||
* 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：```Fedora Core 4```、```Slackware 9.1```等）。
|
||||
* 描述在提问前你是怎样去研究和理解这个问题的。
|
||||
* 描述在提问前为确定问题而采取的诊断步骤。
|
||||
* 描述最近做过什么可能相关的硬件或软件变更。
|
||||
* 尽可能的提供一个可以```重现这个问题的可控环境```的方法。
|
||||
|
||||
尽量去揣测一个黑客会怎样反问你，在你提问之前预先将黑客们可能遇到的问题回答一遍。
|
||||
|
||||
以上几点中，当你报告的是你认为可能在代码中的问题时，给黑客一个可以重现你的问题的环境尤其重要。当你这么做时，你得到有效的回答的机会和速度都会大大的提升。
|
||||
|
||||
[Simon Tatham](http://www.chiark.greenend.org.uk/~sgtatham/)写过一篇名为《[如何有效的报告Bug](http://www.chiark.greenend.org.uk/~sgtatham/bugs-tw.html)》的出色文章。强力推荐你也读一读。
|
||||
[Simon Tatham](http://www.chiark.greenend.org.uk/~sgtatham/) 写过一篇名为《[如何有效的报告 Bug](http://www.chiark.greenend.org.uk/~sgtatham/bugs-tw.html)》的出色文章。强力推荐你也读一读。
|
||||
|
||||
### 话不在多而在精
|
||||
|
||||
@ -291,17 +291,17 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
这样做的用处至少有三点。
|
||||
第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；
|
||||
第二，简化问题使你更有可能得到**_有用_**的答案；
|
||||
第三，在精炼你的bug报告的过程中，你很可能就自己找到了解决方法或权宜之计。
|
||||
第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或权宜之计。
|
||||
|
||||
### 别动辄声称找到Bug
|
||||
### 别动辄声称找到 Bug
|
||||
|
||||
当你在使用软件中遇到问题，除非你非常、**_非常_**的有根据，不要动辄声称找到了Bug。提示：除非你能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则你都多半不够完全确信。这同样适用在网页和文件，如果你（声称）发现了文件的```Bug```，你应该能提供相应位置的修正或替代文件。
|
||||
当你在使用软件中遇到问题，除非你非常、**_非常_**的有根据，不要动辄声称找到了 Bug。提示：除非你能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则你都多半不够完全确信。这同样适用在网页和文件，如果你（声称）发现了文件的```Bug```，你应该能提供相应位置的修正或替代文件。
|
||||
|
||||
请记得，还有许多其它使用者没遇到你发现的问题，否则你在阅读文件或搜索网页时就应该发现了（你在抱怨前[已经做了这些，是吧](#在提问之前)？）。这也意味着很有可能是你弄错了而不是软件本身有问题。
|
||||
|
||||
编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了Bug，也就是在质疑他们的能力，即使你是对的，也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有```Bug```时，这尤其严重。
|
||||
编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug，也就是在质疑他们的能力，即使你是对的，也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有```Bug```时，这尤其严重。
|
||||
|
||||
提问时，即使你私下非常确信已经发现一个真正的Bug，最好写得像是**_你_**做错了什么。如果真的有Bug，你会在回复中看到这点。这样做的话，如果真有Bug，维护者就会向你道歉，这总比你惹恼别人然后欠别人一个道歉要好一点。
|
||||
提问时，即使你私下非常确信已经发现一个真正的 Bug，最好写得像是**_你_**做错了什么。如果真的有 Bug，你会在回复中看到这点。这样做的话，如果真有 Bug，维护者就会向你道歉，这总比你惹恼别人然后欠别人一个道歉要好一点。
|
||||
|
||||
### 低声下气不能代替你的功课
|
||||
|
||||
@ -321,16 +321,16 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
> 我怀疑某条飞线搭在主板的走线上了，这种情况应该怎样检查最好？
|
||||
|
||||
***聪明问题***
|
||||
> 我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（威盛 Apollo VP2芯片组），
|
||||
> 256MB Corsair PC133 SDRAM内存，在编译内核时，从开机20分钟以后就频频产生 SIG11 错误，
|
||||
> 但是在头20分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作20分钟。
|
||||
> 我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（威盛 Apollo VP2 芯片组），
|
||||
> 256MB Corsair PC133 SDRAM 内存，在编译内核时，从开机 20 分钟以后就频频产生 SIG11 错误，
|
||||
> 但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作 20 分钟。
|
||||
> 所有内存都换过了，没有效果。相关部分的标准编译记录如下…。
|
||||
|
||||
由于以上这点似乎让许多人觉得难以配合，这里有句话可以提醒你：```所有的诊断专家都来自密苏里州。``` 美国国务院的官方座右铭则是：```让我看看```（出自国会议员 Willard D. Vandiver 在1899年时的讲话：```我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。```） 针对诊断者而言，这并不是一种怀疑，而只是一种真实而有用的需求，以便让他们看到的是与你看到的原始证据尽可能一致的东西，而不是你的猜测与归纳的结论。所以，大方的展示给我们看吧！
|
||||
由于以上这点似乎让许多人觉得难以配合，这里有句话可以提醒你：```所有的诊断专家都来自密苏里州。``` 美国国务院的官方座右铭则是：```让我看看```（出自国会议员 Willard D. Vandiver 在 1899 年时的讲话：```我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。```） 针对诊断者而言，这并不是一种怀疑，而只是一种真实而有用的需求，以便让他们看到的是与你看到的原始证据尽可能一致的东西，而不是你的猜测与归纳的结论。所以，大方的展示给我们看吧！
|
||||
|
||||
### 按发生时间先后列出问题症状
|
||||
|
||||
问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如20行）记录会非常有帮助。
|
||||
问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。
|
||||
|
||||
如果挂掉的程序有诊断选项（如 -v 的详述开关），试着选择这些能在记录中增加调试信息的选项。记住，```多```不等于```好```。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。
|
||||
|
||||
@ -338,16 +338,16 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
|
||||
### 描述目标而不是过程
|
||||
|
||||
如果你想弄清楚如何做某事（而不是报告一个Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
|
||||
如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
|
||||
|
||||
经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。
|
||||
|
||||
**蠢问题**
|
||||
> 我怎样才能从某绘图程序的颜色选择器中取得十六进制的的RGB值？
|
||||
> 我怎样才能从某绘图程序的颜色选择器中取得十六进制的的 RGB 值？
|
||||
|
||||
**聪明问题**
|
||||
> 我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot），
|
||||
> 但却无法从某绘图程序的颜色选择器取得十六进制的的RGB值。
|
||||
> 但却无法从某绘图程序的颜色选择器取得十六进制的的 RGB 值。
|
||||
|
||||
第二种提问法比较聪明，你可能得到像是```建议采用另一个更合适的工具```的回复。
|
||||
|
||||
@ -367,13 +367,13 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
|
||||
要理解专家们所处的世界，请把专业技能想像为充裕的资源，而回复的时间则是稀缺的资源。你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答。
|
||||
|
||||
所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你有用答案相当有帮助 -- 但这技巧通常和简化问题有所区别。因此，问```我想更好的理解X，可否指点一下哪有好一点说明？```通常比问```你能解释一下X吗？```更好。如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。
|
||||
所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你有用答案相当有帮助 -- 但这技巧通常和简化问题有所区别。因此，问```我想更好的理解 X，可否指点一下哪有好一点说明？```通常比问```你能解释一下 X 吗？```更好。如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。
|
||||
|
||||
### 询问有关代码的问题时
|
||||
|
||||
别要求他人帮你调试有问题的代码，不提示一下应该从何入手。张贴几百行的代码，然后说一声：```它不能工作```会让你完全被忽略。只贴几十行代码，然后说一句：```在第七行以后，我期待它显示 <x>，但实际出现的是 <y>```比较有可能让你得到回应。
|
||||
|
||||
最有效描述程序问题的方法是提供最精简的Bug展示测试示例（bug-demonstrating test case）。什么是最精简的测试示例? 那是问题的缩影；一小个程序片段能**刚好**展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试示例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试示例越小越好（查看[话不在多而在精](#话不在多而在精)一节）。
|
||||
最有效描述程序问题的方法是提供最精简的 Bug 展示测试示例（bug-demonstrating test case）。什么是最精简的测试示例？那是问题的缩影；一小个程序片段能**刚好**展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试示例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试示例越小越好（查看[话不在多而在精](#话不在多而在精)一节）。
|
||||
|
||||
一般而言，要得到一段相当精简的测试示例并不太容易，但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何自行解决这个问题 —- 而且即使你的尝试不成功，黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作。
|
||||
|
||||
@ -409,7 +409,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
|
||||
彬彬有礼，多用```请```和```谢谢您的关注```，或```谢谢你的关照```。让大家都知道你对他们花时间免费提供帮助心存感激。
|
||||
|
||||
坦白说，这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的Bug报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）
|
||||
坦白说，这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）
|
||||
|
||||
然而，如果你有一串的问题待解决，客气一点肯定会增加你得到有用回应的机会。
|
||||
|
||||
@ -419,7 +419,7 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
|
||||
问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个说明比较恰当。
|
||||
|
||||
最理想的方式是向最初提问的话题回复此消息，并在标题中包含```已修正```，```已解决```或其它同等含义的明显标记。在人来人往的邮件列表里，一个看见讨论串```问题 X```和```问题的X - 已解决```的潜在回复者就明白不用再浪费时间了（除非他个人觉得```问题 X```的有趣），因此可以利用此时间去解决其它问题。
|
||||
最理想的方式是向最初提问的话题回复此消息，并在标题中包含```已修正```，```已解决```或其它同等含义的明显标记。在人来人往的邮件列表里，一个看见讨论串```问题 X```和```问题 X - 已解决```的潜在回复者就明白不用再浪费时间了（除非他个人觉得```问题 X```的有趣），因此可以利用此时间去解决其它问题。
|
||||
|
||||
补充说明不必很长或是很深入；简单的一句```你好，原来是网线出了问题！谢谢大家 – Bill```比什么也不说要来的好。事实上，除非结论真的很有技术含量，否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。
|
||||
|
||||
@ -436,18 +436,18 @@ Stack Exchange 已经成长到[超过一百个网站](http://stackexchange.com/s
|
||||
## 如何解读答案
|
||||
|
||||
<a id="RTFM"></a>
|
||||
### RTFM和STFW：如何知道你已完全搞砸了
|
||||
### RTFM 和 STFW：如何知道你已完全搞砸了
|
||||
|
||||
有一个古老而神圣的传统：如果你收到```RTFM （Read The Fucking Manual）```的回应，回答者认为你**应该去读他妈的手册**。当然，基本上他是对的，你应该去读一读。
|
||||
|
||||
RTFM 有一个年轻的亲戚。如果你收到```STFW（Search The Fucking Web）```的回应，回答者认为你**应该到他妈的网上搜索**过了。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 **[Google是你的朋友](http://lmgtfy.com/)**！）
|
||||
RTFM 有一个年轻的亲戚。如果你收到```STFW（Search The Fucking Web）```的回应，回答者认为你**应该到他妈的网上搜索**过了。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 **[Google 是你的朋友](http://lmgtfy.com/)**！）
|
||||
|
||||
在论坛，你也可能被要求去爬爬论坛的旧文。事实上，有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照，提问前应该先搜索一下旧文。
|
||||
|
||||
通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为
|
||||
|
||||
* **你需要的信息非常容易获得**；
|
||||
* **你自己去搜索这些信息比灌给你，能让你学到更多**。
|
||||
* **你需要的信息非常容易获得**；
|
||||
* **你自己去搜索这些信息比灌给你，能让你学到更多**。
|
||||
|
||||
你不应该因此不爽；**依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见**。你应该对他祖母般的慈祥表示感谢。
|
||||
|
||||
@ -455,7 +455,7 @@ RTFM 有一个年轻的亲戚。如果你收到```STFW（Search The Fucking Web
|
||||
|
||||
如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。
|
||||
|
||||
比方说，如果我回答你：```看来似乎是 zentry 卡住了；你应该先清除它。```，然后，这是一个**_很糟的_**后续问题回应：```zentry是什么？``` **_好_**的问法应该是这样：```哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？```
|
||||
比方说，如果我回答你：```看来似乎是 zentry 卡住了；你应该先清除它。```，然后，这是一个**_很糟的_**后续问题回应：```zentry 是什么？``` **_好_**的问法应该是这样：```哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？```
|
||||
|
||||
### 处理无礼的回应
|
||||
|
||||
@ -467,7 +467,7 @@ RTFM 有一个年轻的亲戚。如果你收到```STFW（Search The Fucking Web
|
||||
|
||||
（有些人断言很多黑客都有轻度的自闭症或亚斯伯格综合症，缺少用于润滑人类社会**正常**交往所需的神经。这既可能是真也可能是假的。如果你自己不是黑客，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们**_喜欢_**我们现在这个样子，并且通常对病患标记都有站得住脚的怀疑。）
|
||||
|
||||
Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http://www.mit.edu/~jcb/tact.html)**)。
|
||||
Jeff Bigler 的观察总结和这个相关也值得一读 (**[tact filters](http://www.mit.edu/~jcb/tact.html)**)。
|
||||
|
||||
在下一节，我们会谈到另一个问题，当**_你_**行为不当时所会受到的```冒犯```。
|
||||
|
||||
@ -481,11 +481,11 @@ Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http:/
|
||||
|
||||
社区的标准不会自行维持，它们是通过参与者积极而**_公开地_**执行来维持的。不要哭嚎所有的批评都应该通过私下的邮件传送，它不是这样运作的。当有人评论你的一个说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处，这些都是失败者的态度。
|
||||
|
||||
也有其它的黑客论坛，受过高礼节要求的误导，禁止参与者张贴任何对别人帖子挑毛病的消息，并声称```如果你不想帮助用户就闭嘴。``` 结果造成有想法的参与者纷纷离开，这么做只会使它们沦为毫无意义的嘮叨与无用的技术论坛。
|
||||
也有其它的黑客论坛，受过高礼节要求的误导，禁止参与者张贴任何对别人帖子挑毛病的消息，并声称```如果你不想帮助用户就闭嘴。``` 结果造成有想法的参与者纷纷离开，这么做只会使它们沦为毫无意义的唠叨与无用的技术论坛。
|
||||
|
||||
夸张的讲法是：你要的是**友善**（以上述方式）还是有用？两个里面挑一个。
|
||||
|
||||
记着：当黑客说你搞砸了，并且（无论多么刺耳）告诉你别再这样做时，他正在为关心**你**和**他的社区**而行动。对他而言，不理你并将你从他的生活中滤掉更简单。如果你无法做到感谢，至少要表现地有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人像对待脆弱的洋娃娃那样对你。
|
||||
记着：当黑客说你搞砸了，并且（无论多么刺耳）告诉你别再这样做时，他正在为关心**你**和**他的社区**而行动。对他而言，不理你并将你从他的生活中滤掉更简单。如果你无法做到感谢，至少要表现得有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人像对待脆弱的洋娃娃那样对你。
|
||||
|
||||
有时候，即使你没有搞砸（或者只是在他的想像中你搞砸了），有些人也会无缘无故地攻击你本人。在这种情况下，抱怨倒是**_真的_**会把问题搞砸。
|
||||
|
||||
@ -505,7 +505,7 @@ Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http:/
|
||||
|
||||
问题：[我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？](#q4)
|
||||
|
||||
问题：[我的程序/设定/SQL语句没有用](#q5)
|
||||
问题：[我的程序/设定/SQL 语句没有用](#q5)
|
||||
|
||||
问题：[我的 Windows 电脑有问题，你能帮我吗？](#q6)
|
||||
|
||||
@ -540,7 +540,7 @@ Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http:/
|
||||
回答：试试看就知道了。如果你试过，你既知道了答案，就不用浪费我的时间了。
|
||||
|
||||
<a id="q5"></a>
|
||||
> 问题：我的{程序/设定/SQL语句}不工作
|
||||
> 问题：我的{程序/设定/SQL 语句}不工作
|
||||
|
||||
回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣 -- 我有更有意思的事要做呢。在看到这类问题的时候，我的反应通常不外如下三种
|
||||
|
||||
@ -551,9 +551,9 @@ Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http:/
|
||||
<a id="q6"></a>
|
||||
> 问题：我的 Windows 电脑有问题，你能帮我吗？
|
||||
|
||||
回答：能啊，扔掉萎软的垃圾，换个像 Linux 或 BSD 的开放源代码操作系统吧。
|
||||
回答：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开放源代码操作系统吧。
|
||||
|
||||
注意：如果程序有官方版 Windows 或者与 Windows 有互动（如Samba），你**_可以_**问与Windows相关的问题， 只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 一般来说实在太烂，这种说法通常都是对的。
|
||||
注意：如果程序有官方版 Windows 或者与 Windows 有互动（如 Samba），你**_可以_**问与 Windows 相关的问题， 只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 一般来说实在太烂，这种说法通常都是对的。
|
||||
|
||||
<a id="q7"></a>
|
||||
> 问题：我的程序不会动了，我认为系统工具 X 有问题
|
||||
@ -585,7 +585,7 @@ Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http:/
|
||||
|
||||
**_聪明问题_**：
|
||||
|
||||
> 我用Google搜索过 "Foonly Flurbamatic 2600"，但是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料？
|
||||
> 我用 Google 搜索过 "Foonly Flurbamatic 2600"，但是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料？
|
||||
|
||||
这个问题已经 STFW 过了，看起来他真的遇到了麻烦。
|
||||
|
||||
@ -594,13 +594,13 @@ Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http:/
|
||||
|
||||
> 我从 foo 项目找来的源码没法编译。它怎么这么烂？
|
||||
|
||||
他觉得都是别人的错，这个傲慢自大的提问者
|
||||
他觉得都是别人的错，这个傲慢自大的提问者。
|
||||
|
||||
**_聪明问题_**
|
||||
|
||||
> foo 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ，但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录，我有什么做的不对的地方吗？
|
||||
|
||||
提问者已经指明了环境，也读过了FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注。
|
||||
提问者已经指明了环境，也读过了 FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注。
|
||||
|
||||
|
||||
**_蠢问题_**
|
||||
@ -621,7 +621,7 @@ Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http:/
|
||||
|
||||
通过我的提问方法，我给了别人可以咀嚼玩味的东西；我设法让人们很容易参与并且被吸引进来。我显示了自己具备和他们同等的能力，并邀请他们与我共同探讨。通过告诉他们我所走过的弯路，以避免他们再浪费时间，我也表明了对他们宝贵时间的尊重。
|
||||
|
||||
事后，当我向每个人表示感谢，并且讚赏这次良好的讨论经历的时候， 一个 Linux 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的**_名人_**，而是因为我用了正确的方式来提问。
|
||||
事后，当我向每个人表示感谢，并且赞赏这次良好的讨论经历的时候， 一个 Linux 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的**_名人_**，而是因为我用了正确的方式来提问。
|
||||
|
||||
黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我**_像_**个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视。他建议我记下这件事，这直接导致了本指南的出现。
|
||||
|
||||
@ -655,7 +655,7 @@ Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http:/
|
||||
|
||||
**_如果你决定回答，就请给出好的答案_**。当别人正在用错误的工具或方法时别建议笨拙的权宜之计（wordaround），应推荐更好的工具，重新界定问题。
|
||||
|
||||
**_正面的回答问题_**！如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 ```试试看 A 或是 B``` 或者 ```试试X 、 Y 、 Z 、 A 、 B 、 C``` 并附上一个链接一点用都没有。
|
||||
**_正面的回答问题_**！如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 ```试试看 A 或是 B``` 或者 ```试试 X 、 Y 、 Z 、 A 、 B 、 C``` 并附上一个链接一点用都没有。
|
||||
|
||||
**_帮助你的社区从问题中学习_**。当回复一个好问题时，问问自己```如何修改相关文件或常见问题文件以免再次解答同样的问题？```，接着再向文件维护者发一份补丁。
|
||||
|
||||
@ -663,9 +663,9 @@ Jeff Bigler的观察总结和这个相关也值得一读(**[tact filters](http:/
|
||||
|
||||
## 相关资源
|
||||
|
||||
如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅[Unix系统和网络基本原理](http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/)。
|
||||
如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅 [Unix 系统和网络基本原理](http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/)。
|
||||
|
||||
当你发布软件或补丁时，试着按[软件发布实践](http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html)操作。
|
||||
|
||||
## 鸣谢
|
||||
Evelyn Mitchel贡献了一些愚蠢问题例子并启发了编写```如何更好地回答问题```这一节， Mikhail Ramendik贡献了一些特别有价值的建议和改进。
|
||||
Evelyn Mitchel 贡献了一些愚蠢问题例子并启发了编写```如何更好地回答问题```这一节， Mikhail Ramendik 贡献了一些特别有价值的建议和改进。
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user