# 在提问之前 1. 在专业的社区，问专业的问题 2. 尝试在准备提问的论坛的旧文章中搜索答案 3. 上网搜索以找到答案 4. 阅读手册以找到答案 5. 尝试阅读常见问题文件（FAQ）以找到答案 6. 尝试自己试验找到答案.将问题分成更小的部分，然后 7. 向朋友找答案 8. 如果是程序开发者，尝试阅读源代码 如果你能一并表述在做了上述努力的过程中学到的东西会更好。即使没有结果，在寻求帮助时加上一句`我在XX中搜过下列句子但没有找到什么有用的东西`也是件好事，这么做可以让遇到相似问题的人通过搜索引擎引导到你的提问来。 另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的开端。`谁能给点提示？`、`我的这个例子里缺了什么？`、`我应该检查什么地方？`,你需要表现处只要有个人能指明正确方向，你就有完成它的能力和决心。 # 当你提问时 ## 选择提问的论坛 - 主题不和 - 进阶和初级 - 不同的新闻群组上重复转贴同样的问题 - 乱发私人电邮 搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括**阅读** FAQ）都没有结果，网站上也许还有报告 Bug（Bug-reporting）的流程或链接。 在选择论坛、新闻群组或邮件列表时，别太相信它的名字，先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题，这样可以让你感受一下那里的文化。事实上，事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意，也许这样就找到答案了。即使没有，也能帮助你归纳出更好的问题。 别像机关枪似的一次“扫射”所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。 搞清楚你的主题！最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错，最好在搞清楚这之间差异之前什么也别问。 ### Stack Overflow 搜索，*然后*在 Stack Exchange 问。 近年来，Stack Exchange 社区已经成为回答技术及其他问题的主要渠道，尤其是那些开放源码的项目。 因为 Google 索引是即时的，在看 Stack Exchange 之前先在 Google 搜索。有很高的几率某人已经问了一个类似的问题，而且 Stack Exchange 网站们往往会是搜索结果中最前面几个。如果你在 Google 上没有找到任何答案，你再到特定相关主题的网站去找。用标签（Tag）搜索能让你更缩小你的搜索结果。 如果你还是找不到任何对你的问题有用的内容，请把你的问题发在与它最相关的网站上。提问的时候请善用格式化工具，尤其注意为代码添加格式，并且添加相关的标签（特别是编程语言、操作系统或库/包的名称）。当有人要求你提供更多相关信息时，请编辑你的贴子来补充它们[而不是发一个回帖或回答！]。如果你觉得一个答案对你有帮助，点击向上的箭头来为它投票；如果一个答案提供了问题的正确解决方案，点击投票按钮下方的对勾来将它标记为正解。 Stack Exchange 已经成长到[超过一百个网站](https://stackexchange.com/sites) ## 提问准则 1. 最**基本**的准则就是**正确描述自己的问题并让其易于理解**。 明确指出你*究竟*对什么感到困惑。 多次review自己的问题，并提问自己：这个问题在描述什么？（对某个概念的解释）是否有矛盾的地方？你是否不明白正在阅读的某个段落？问题是否需要补充背景知识或测试？ 2. 让你的问题精确，而不是宽泛。通常，提出几个小而精确的问题比提出一个模糊而宽泛的大问题更好。 3. 简明扼要。你的贴子应该包含其他人帮助你所需的一切信息。如果有代码， 简化到重现错误所需的最低限度。 ## 网站和IRC论坛 本地的用户群组（user group），或者你所用的 Linux 发行版本也许正在宣传他们的网页论坛或 IRC 频道，并提供新手帮助（在一些非英语国家，新手论坛很可能还是邮件列表），这些都是开始提问的好地方，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。有广告赞助的 IRC 频道是公开欢迎提问的地方，通常可以即时得到回应。 事实上，如果程序出的问题只发生在特定 Linux 发行版提供的版本（这很常见），最好先去该发行版的论坛或邮件列表中提问，再到程序本身的论坛或邮件列表提问。（否则）该项目的黑客可能仅仅回复“使用**我们的**版本”。 在任何论坛发文以前，先确认一下有没有搜索功能。如果有，就试着搜索一下问题的几个关键词，也许这会有帮助。如果在此之前你已做过通用的网页搜索（你也该这样做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。 通过论坛或 IRC 频道来提供用户支持服务有增长的趋势，电子邮件则大多为项目开发者间的交流而保留。所以最好先在论坛或 IRC 中寻求与该项目相关的协助。 在使用 IRC 的时候，首先最好不要发布很长的问题描述，有些人称之为频道洪水。最好通过一句话的问题描述来开始聊天。 ## 使用项目邮件列表 当某个项目提供开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题。查一查项目的文件和首页，找到项目的邮件列表并使用它。有几个很好的理由支持我们采用这种办法： - 任何好到需要向个别开发者提出的问题，也将对整个项目群组有益。反之，如果你认为自己的问题对整个项目群组来说太愚蠢，那这也不能成为骚扰个别开发者的理由。 - 向列表提问可以分散开发者的负担，个别开发者（尤其是项目领导人）也许太忙以至于没法回答你的问题。 - 大多数邮件列表都会被存档，那些被存档的内容将被搜索引擎索引。如果你向列表提问并得到解答，将来其他人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。 - 如果某些问题经常被问到，开发者可以利用此信息来改进说明文件或软件本身，以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。 如果一个项目既有“用户”也有“开发者”）邮件列表或论坛，而你又不会动到那些源代码，那么就向“用户”列表或论坛提问。不要假设自己会在开发者列表中受到欢迎，那些人多半会将你的提问视为干扰他们开发的噪音。 然而，如果你**确信**你的问题很特别，而且在“用户”列表或论坛中几天都没有回复，可以试试前往“开发者”列表或论坛发问。建议你在张贴前最好先暗地里观察几天以了解那里的行事方式（事实上这是参与任何私有或半私有列表的好主意） 如果你找不到一个项目的邮件列表，而只能查到项目维护者的电子邮件地址，尽管向他发信。即使是在这种情况下，也别假设（项目）邮件列表不存在。在你的电子邮件中，请陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人（许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）。 ## 标题写法 标题需要做到让人**一目了然**。 1. 关于编程语言本身或者IDE的问题，需要用自然的方式。譬如使用*What are bytes signed in JAVA?*而不是*Java :what are bytes signed?*。 ​ `[C++] 在for循环写入数组时发生分段错误` 1. 灵活地使用tag 2. 不要强迫自己的标题设置为问题的形式 3. 准确而具体地描述问题，诸如*Why my ide breaks down* 缺乏关键信息 在邮件列表、新闻群组或论坛中，大约 50 字以内的标题是抓住资深专家注意力的好机会。别用喋喋不休的`帮帮忙`、`跪求`、`急`（更别说`救命啊！！！！`这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。不要妄想用你的痛苦程度来打动我们，而应该是在这点空间中使用极简单扼要的描述方式来提出问题。 一个好标题范例是`目标 —— 差异`式的描述，许多技术支持组织就是这样做的。在`目标`部分指出是哪一个或哪一组东西有问题，在`差异`部分则描述与期望的行为不一致的地方。 > 更聪明问题：X.org 6.8.1 的鼠标指针，在某牌显卡 MV1005 芯片组环境下 - 会变形。 编写`目标 —— 差异` 式描述的过程有助于你组织对问题的细致思考。是什么被影响了？ 仅仅是鼠标指针或者还有其它图形？只在 X.org 的 X 版中出现？或只是出现在 6.8.1 版中？ 是针对某牌显卡芯片组？或者只是其中的 MV1005 型号？ 一个黑客只需瞄一眼就能够立即明白你的环境**和**你遇到的问题。 总而言之，请想像一下你正在一个只显示标题的存档讨论串（Thread）索引中查寻。让你的标题更好地反映问题，可使下一个搜索类似问题的人能够关注这个讨论串，而不用再次提问相同的问题。 如果你想在回复中提出问题，记得要修改内容标题，以表明你是在问一个问题， 一个看起来像 `Re: 测试` 或者 `Re: 新 bug` 的标题很难引起足够重视。另外，在不影响连贯性之下，适当引用并删减前文的内容，能给新来的读者留下线索。 对于讨论串，不要直接点击回复来开始一个全新的讨论串，这将限制你的观众。因为有些邮件阅读程序，比如 mutt ，允许用户按讨论串排序并通过折叠讨论串来隐藏消息，这样做的人永远看不到你发的消息。 仅仅改变标题还不够。mutt 和其它一些邮件阅读程序还会检查邮件标题以外的其它信息，以便为其指定讨论串。所以宁可发一个全新的邮件。 在网页论坛上，好的提问方式稍有不同，因为讨论串与特定的信息紧密结合，并且通常在讨论串外就看不到里面的内容，故通过回复提问，而非改变标题是可接受的。不是所有论坛都允许在回复中出现分离的标题，而且这样做了基本上没有人会去看。不过，通过回复提问，这本身就是暧昧的做法，因为它们只会被正在查看该标题的人读到。所以，除非你**只想**在该讨论串当前活跃的人群中提问，不然还是另起炉灶比较好。 ## 使问题容易回复 以`请将你的回复发送到……`来结束你的问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦，我们也觉得花几秒钟思考你的问题更麻烦。如果你的邮件程序不支持这样做，[换个好点的](http://linuxmafia.com/faq/Mail/muas.html)；如果是操作系统不支持这种邮件程序，也换个好点的。 在论坛，要求通过电子邮件回复是非常无礼的，除非你认为回复的信息可能比较敏感（有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。如果你只是想在有人回复讨论串时得到电子邮件提醒，可以要求网页论坛发送给你。几乎所有论坛都支持诸如`追踪此讨论串`、`有回复时发送邮件提醒`等功能。 ## 使用清晰、正确、精准且合乎语法的语句 我们从经验中发现，粗心的提问者通常也会粗心地写程序与思考。回答粗心大意者的问题很不值得，我们宁愿把时间耗在别处。 正确的拼写、标点符号和大小写是很重要的。一般来说，如果你觉得这样做很麻烦，不想在乎这些，那我们也觉得麻烦，不想在乎你的提问。花点额外的精力斟酌一下字句，用不着太僵硬与正式 —— 事实上，黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它**必须很**准确，而且有迹象表明你是在思考和关注问题。 正确地拼写、使用标点和大小写，不要将`its`混淆为`it's`，`loose`搞成`lose`或者将`discrete`弄成`discreet`。不要**全部用大写**，这会被视为无礼的大声嚷嚷（全部小写也好不到哪去，因为不易阅读。[Alan Cox](http://en.wikipedia.org/wiki/Alan_Cox) 也许可以这样做，但你不行）。 更白话的说，如果你写得像是个半文盲[译注：[小白](http://zh.wikipedia.org/wiki/小白)]，那多半得不到理睬。也不要使用即时通信中的简写或[火星文](http://zh.wikipedia.org/wiki/火星文)，如将`的`简化为`d`会使你看起来像一个为了少打几个键而省字的小白。更糟的是，如果像个小孩似地鬼画符那绝对是在找死，可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）。 如果在使用非母语的论坛提问，你可以犯点拼写和语法上的小错，但决不能在思考上马虎（没错，我们通常能弄清两者的分别）。同时，除非你知道回复者使用的语言，否则请使用英语书写。繁忙的黑客一般会直接删除用他们看不懂的语言写的消息。在网络上英语是通用语言，用英语书写可以将你的问题在尚未被阅读就被直接删除的可能性降到最低。 如果英文是你的外语（Second language），提示潜在回复者你有潜在的语言困难是很好的： [译注：以下附上原文以供使用] > English is not my native language; please excuse typing errors. - 英文不是我的母语，请原谅我的错字或语法。 > If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question. - 如果你说**某语言**，请向我发电邮/私信； - 我需要有人协助我翻译我的问题。 > I am familiar with the technical terms, but some slang expressions and idioms are difficult for me. - 我对技术名词很熟悉，但对于俗语或是特别用法不甚了解。 > I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other. - 我把我的问题用**某语言**和英文写出来。 - 如果你只用其中的一种语言回答，我会乐意将回复翻译成为你使用的语言。 ## 问题描述 ### 背景 在正式问题前，需要介绍我们的编程语言、os、ide以及问题所处环境的一些限制。如 ``` Language: Java IDE: Idea2020.3 OS: Ubuntu Constraint: not allowed to operate as... ``` 其次，也需要把自己的try过的解决问题的思路描述出来。譬如我们安装了哪些lib、借鉴了哪些方法（最后附上借鉴的url）。 ### 正文 首先在提问的开头，我们尽可能提供一个对问题的概要，也就是所谓的snippet（代码片段），要让他人能从snippet中对问题有一个大概的了解。紧接着再补充问题的detailed description。 snippet的撰写，可以从 *what did you expect it do do?* *what are you trying to accomplish?* *what have you already tried?* *what happened in those attempts?* 即我们程序的目的、预期的输出、结果的输出、错误的信息（如果有）以及尝试过的工作[[#在提问之前]] 1. 你已经尝试过哪些方法来调试你自己的问题？你怀疑问题出在哪里？你还有哪些不确定的地方？ 2. 你究竟对什么感到困惑？ ### 用例 我们也需要为问题补充一个可浮现的场景，同时尽可能确保用例的方便性。 1. 提供需要的xml配置文件 2. 导出需求的包 3. 尽可能简短却能复现错误场景的代码 4. 尽量不要涉及ui，能用terminal就用terminal 5. 避免和db的对话 如果环境避免不了db，我们就要简化我们涉及的表。建立新表，并插入简单却能复现的记录。同时对我们的数据，我们需要补充期望的输出，并为输出做出简单的描述。 ## 问题规范 1. 我们首先需要在问题中使用合理的**大小写**逻辑，一个突出的大写字母会吸引他人的注意力，因此我们需要合适的地方使用大写。 2. 文章的排版。同时可以借助浏览器自带或通过插件安装的grammar check来避免错误拼写。减少不必要的简写。 ## 文明规范 1. 保持对自己提问的关注，当他人回答时，要尽量做到回应。如果独自解决了问题，，通过编辑来表达自己已经解决了，同时因为某个回答对问题做出了修改，我们也要告知答主。 # 总结 1. 简短但描述性的标题 2. 对问题的良好描述 3. 一个最小的、易于运行的、格式良好的程序 4. 您的预期输出以及实际结果。如果出现错误，请提供完整的错误信息。