How To Ask Questions - 版本历史

2022年2月13日 (日) 10:46 Zhang3

2022-02-13T10:46:37Z

←上一版本		2022年2月13日 (日) 10:46的版本
第1行：		第1行：
	以下是对初学者和其他新手的一些提示，以最大程度地提高你获得有用答案的机会，并让社区乐于帮助你，而不是因你的抱怨而烦恼。它的灵感来自文档[http://www.catb.org/~esr/faqs/smart-questions.html 如何以聪明的方式提问]，你可以通过网页搜索 (Google How To Ask Questions The Smart Way) 轻松找到该文档。此处的指南仅是Eric S. Raymond的 “官方” 文档的子集，该文档主要适用于web论坛 (尤其是本论坛)。		以下是对初学者和其他新手的一些提示，以最大程度地提高你获得有用答案的机会，并让社区乐于帮助你，而不是因你的抱怨而烦恼。它的灵感来自文档[http://www.catb.org/~esr/faqs/smart-questions.html 如何以聪明的方式提问]，你可以通过网页搜索 (Google How To Ask Questions The Smart Way) 轻松找到该文档。此处的指南仅是Eric S. Raymond的 “官方” 文档的子集，该文档主要适用于web论坛 (尤其是本论坛)。

	'''注意：'''~~虽然这应该是显而易见的，但还是经常发生，所以需要提一下——“永远”不应该在任何Eric~~ S.Raymond和Rick Moen他们个人没有参与的软件项目上直接联系他们，寻求帮助！发生这种情况的事实表明，像这样的网站的读者还没有阅读和理解他们的建议。由于作者明确要求将这一警告与他们的文件链接在一起，因此需要在任何可能的机会都强调这一点。”		'''注意：''' ''虽然这应该是显而易见的，但还是经常发生，所以需要提一下——'''永远'''不应该在任何Eric S.Raymond和Rick Moen他们个人没有参与的软件项目上直接联系他们，寻求帮助！发生这种情况的事实表明，像这样的网站读者还没有阅读和理解他们的建议。由于作者明确要求将这一警告与他们的文件链接在一起，因此需要在任何可能的机会都强调这一点。''

	==用户标识和用户帐户==		==用户标识和用户帐户==
第21行：		第21行：
	的确，操作系统开发论坛有对新手苛刻的名声。这是有原因的: 操作系统开发不是一个新手程序员可以合理探讨的话题。在他们还没有真正了解自己在做什么的背景和经验之前，许多人过早地投身于这一领域，并因缺乏准备而感到焦头烂额。不幸的是，这导致我们一次又一次地看到许多相同的错误和问题，如果发帖者能阅读这些警告并遵循他们的建议，这些错误和问题是可以避免的。		的确，操作系统开发论坛有对新手苛刻的名声。这是有原因的: 操作系统开发不是一个新手程序员可以合理探讨的话题。在他们还没有真正了解自己在做什么的背景和经验之前，许多人过早地投身于这一领域，并因缺乏准备而感到焦头烂额。不幸的是，这导致我们一次又一次地看到许多相同的错误和问题，如果发帖者能阅读这些警告并遵循他们的建议，这些错误和问题是可以避免的。

	这不是一个可以通过简单的教程学习的领域，尤其是如果你什么都不做，只是复制和粘贴教程代码，并试图让它在你不理解的情况下工作。确实存在一些教程但更确切的说它们其实是方向指导，而不是cookbook。对于这一领域的大多数科目来说，很难简单而有条理的说明全部问题，所以没有任何完善教程。 ~~从几个不同的现有源中剪切和粘贴代码，并期望它们神奇地结合在一起，这在操作系统开发的简直是一种不可行的方法。~~ 在以有意义的方式进入这一领域之前，你需要学习很多知识，并彻底了解自己在做什么。		这不是一个可以通过简单的教程学习的领域，尤其是如果你什么都不做，只是复制和粘贴教程代码，并试图让它在你不理解的情况下工作。确实存在一些教程但更确切的说它们其实是方向指导，而不是cookbook。对于这一领域的大多数科目来说，很难简单而有条理的说明全部问题，所以没有任何完善教程。从几个不同的现有源中剪切和粘贴代码，并期望它们神奇地结合在一起，这在操作系统开发中简直是一种不可行的方法。在以有意义的方式进入这一领域之前，你需要学习很多知识，并彻底了解自己在做什么。

	==研究==		==研究==
第35行：		第35行：

	===关于过期或不完整的维基文章===		===关于过期或不完整的维基文章===
	对于任何大型协作项目(如维基)来说，不可避免的是，一些信息在没有人注意到的情况下就过时了，这是一个令人悲哀的事实。同样不可避免地，有些主题根本没有得到他们需要的关注。 ~~如果你注意到你认为发生了这种事情，请尽量不要生气；相反，礼貌地把它放在留言板上，这样某人——可能是你自己——可以添加和~~/或更新它。		对于任何大型协作项目(如维基)来说，不可避免的是，一些信息在没有人注意到的情况下就过时了，这是一个令人悲哀的事实。同样不可避免地，有些主题根本没有得到他们需要的关注。如果你认为发现了以上种事情，请尽量不要生气；相反，礼貌地把它放在留言板上，这样某人——可能是你自己——可以添加和/或更新它。

	可能是因为到目前为止还没有人注意到这一点，或者还没有主题专家解决过这个问题；也可能是有人将页面的副本挂到了自己的私人页面上，以便再进行大检查，而这还没有反映在官方页面中。甚至可能在如何解决该主题方面存在争议，导致了计划更新的延迟。 ~~相反，你可能错过了其他方面的某件内容（考虑到维基的规模和规模，这肯定会发生），熟悉该主题的论坛用户可以为你指明正确的方向。~~ 在任何一种情况下，反馈最好是建设性的和积极的，而不是对此大发雷霆。		可能是因为到目前为止还没有人注意到这一点，或者还没有主题专家解决过这个问题；也可能是有人将页面的副本挂到了自己的私人页面上，以便再进行大检查，而这还没有反映在官方页面中。甚至可能在如何解决该主题方面存在争议，导致了计划更新的延迟。相反，你可能错过了其他方面的某件内容（考虑到维基的大小和规模，这肯定会发生），熟悉该主题的论坛用户可以为你指明正确的方向。在任何一种情况下，反馈最好是建设性的和积极的，而不是对此大发雷霆。

	== 详细信息 ==		== 详细信息 ==
	操作系统代码高度相互依赖。如果你只给我们三重故障的中断处理程序的源代码，我们将无法在你的IVT设置中找到实际“导致”错误的错误。我们还需要知道你使用的是什么编译器/汇编程序/链接器，在哪个版本中，以及你使用的是哪些命令行选项。		操作系统代码高度相互依赖。如果你只给我们三重故障的中断处理程序的源代码，我们将无法在你的IVT设置中找到实际“导致”错误的错误。我们还需要知道你使用的是什么编译器/汇编程序/链接器，在哪个版本中，以及你使用的是哪些命令行选项。

	在[[Projects\|OS项目列表]]中创建一个描述你的项目和环境的条目，并在你的论坛签名中添加一个指向该条目的链接，还可以让我们快速获得诸如“你使用的是什么编译器？”等琐碎问题的答案。或者“你的开发环境是什么？”，“你在用GRUB吗？” Bochs？ VMware？”等等。		在[[Projects\|OS项目列表]]中创建一个描述你的项目和环境的条目，并在你的论坛签名中添加一个指向该条目的链接，还可以让我们快速获得诸如“你使用的是什么编译器？”等琐碎问题的答案。或者“你的开发环境是什么？”，“你在用GRUB吗？ Bochs？ VMware？”等等。

	正如提供的信息太少不行，太多也同样有害。很容易给人错误的印象 (“我有问题，但不愿费心缩小范围。帮我修好它!”)。		正如提供的信息太少不行，太多也同样有害。很容易给人错误的印象 (“我有问题，但不愿费心缩小范围。帮我修好它!”)。
第55行：		第55行：
	论坛有一个[code] ... [/code]格式化命令，你可以使用该命令突出显示你的代码片段，避免笑脸/字体标签弄乱你的帖子。		论坛有一个[code] ... [/code]格式化命令，你可以使用该命令突出显示你的代码片段，避免笑脸/字体标签弄乱你的帖子。

	把你的帖子分成几段。 ~~不要显得大喊大叫（例如用大写字母书写），也不要使用漂亮但无用的格式（比如发光的彩色字体、移动的文本、微笑的线条等）。~~ 如果可能，请使用“预览”功能。		把你的帖子分成几段。不要显得大喊大叫（例如用大写字母书写），也不要使用漂亮但无用的格式（比如发光的彩色字体、移动的文本、成排的表情符等）。如果可能，请使用“预览”功能。


	== 描述目标 ==		== 描述目标 ==
	当一个人在处理一个特定的问题X时，通常会找到一个看起来合适的解决方案Y，但你不知道如何正确地实现，或者在调试中遇到问题。这可能会导致你发布一个关于如何正确做Y的问题。这可能也行，''但是''这样做而不解释为什么要解决问题Y的上下文 (问题X) ，可能会导致解决了Y，但不是解决问题X的目标。实际上，可能是Y根本不能解决问题X，或者有一个更好的方案，你不知道。 ~~在这种情况下，询问Y会将把你引向死胡同。~~ 充其量，这会使那些可能对你的目标感到困惑的人更困惑，即使他们实际上知道如何解决X，他们也根本不会回答。		当一个人在处理一个特定的问题X时，通常会找到一个看起来合适的解决方案Y，但你不知道如何正确地实现，或者在调试中遇到问题。这可能会导致你发布一个关于如何正确做Y的问题。这可能也行，''但是''这样做而不解释为什么要解决问题Y的上下文 (问题X) ，可能会导致解决了Y，但不是解决问题X的目标。实际上，可能是Y根本不能解决问题X，或者有一个更好的方案，你不知道。在这种情况下，询问Y反而会把你引向死胡同。充其量，这会使那些可能对你的目标感到困惑的人更困惑，即使他们实际上知道如何解决X，他们也根本不会回答。

	这种错误的解决方案求助方式被称为[https://en.wikipedia.org/wiki/XY_problem XY问题]（或者更幽默地说，是一个[https://weblogs.asp.net/alex_papadimoulis/408925 ~~“瓶子或旧鞋”问题），这是论坛上最令人沮丧的沟通问题之一。~~		这种错误的解决方案求助方式被称为[https://en.wikipedia.org/wiki/XY_problem XY问题]（或者更幽默地说，是一个[https://weblogs.asp.net/alex_papadimoulis/408925 “瓶子或旧鞋”问题]），这是论坛上最令人沮丧的沟通问题之一。

	为了避免这种情况，你应该仔细考虑一下，在寻求帮助时，你是否已经充分解释了你试图实现的目标。你不需要详细说明你的项目，但是眼前目标的大体介绍 (以及你过去使用过的任何解决方案) ~~可以在为受访者建立足够的上下文，进而对回答你的问题有很大的帮助。~~		为了避免这种情况，你应该仔细考虑一下，在寻求帮助时，你是否已经充分解释了你试图实现的目标。你不需要详细说明你的项目，但是眼前目标的大体介绍 (以及你过去使用过的任何解决方案) 可以为受访者建立足够的上下文，进而对回答你的问题有很大的帮助。

	==识别问题并向他人描述==		==识别问题并向他人描述==
第77行：		第77行：


	遵循上述准则会大大提高你获得快速而有用答复的机会。 ~~（这会让帮助你变得更受欢迎，这样那些有专门知识的人会留下来，下次仍然可以帮助你。）~~		遵循上述准则会大大提高你获得快速而有用答复的机会。（这会让你变得更受欢迎，这样那些有专门知识的人会留下来，下次仍然可以帮助你。）

	[[Category:OS Development]]		[[Category:OS Development]]

2022年2月13日 (日) 09:44 Zhang3

2022-02-13T09:44:15Z

显示更改

Zhang3：创建页面，内容为“以下是给初学英语的人和其他新手的一些提示，以最大限度地提高你获得问题有用答案的机会，并让社区乐于帮助你，而不是因为你的抱怨而烦恼。它的灵感来自于[http://www.catb.org/~esr/faqs/smart-questions.html 如何聪明提问]文档，您可以通过web（谷歌）搜索轻松检索该文档。这里的指南只是Eric S.的“官方”文件的子集。雷蒙德：这适用于网络论坛（尤其…”

2021-12-21T01:21:05Z

创建页面，内容为“以下是给初学英语的人和其他新手的一些提示，以最大限度地提高你获得问题有用答案的机会，并让社区乐于帮助你，而不是因为你的抱怨而烦恼。它的灵感来自于[http://www.catb.org/~esr/faqs/smart-questions.html 如何聪明提问]文档，您可以通过web（谷歌）搜索轻松检索该文档。这里的指南只是Eric S.的“官方”文件的子集。雷蒙德：这适用于网络论坛（尤其…”

新页面

以下是给初学英语的人和其他新手的一些提示，以最大限度地提高你获得问题有用答案的机会，并让社区乐于帮助你，而不是因为你的抱怨而烦恼。它的灵感来自于[http://www.catb.org/~esr/faqs/smart-questions.html 如何聪明提问]文档，您可以通过web（谷歌）搜索轻松检索该文档。这里的指南只是Eric S.的“官方”文件的子集。雷蒙德：这适用于网络论坛（尤其是这个论坛）。

“注意：”“虽然它应该是显而易见的，但它经常出现，需要说出来-埃里克S。 Raymond和Rick Moen应“永远”直接联系，以获得他们未亲自参与的任何软件项目的帮助！事实上，这种情况的发生表明，像这样的网站的读者还没有阅读和理解他们的建议。由于作者明确要求将这一警告与他们的文件的任何链接一起包含，因此需要在任何可能的机会都强调这一点。''

== 识别和用户 ==
花点时间在前面设置一个用户帐户，上面有一个可识别的用户名和头像。根据问题描述和IP地址，试图找出“aetroi”是否与“sdfoiu”是同一个人，将导致反复提出相同的问题。您的用户帐户为我们提供了一种私下联系您的方式，如果我们觉得回复偏离主题或太长，我们可以通过电子邮件发送回复。独特的头像有助于一眼就能识别你的帖子。

''注意：在OSDev上注册。组织论坛是强制性的。作为注册的一个好处，您还可以注册以获得wiki编辑访问权限。''

== 标题 ==
这有助于“我们”识别我们知道的主题。 “内核问题”是一个糟糕的线程标题。 “IVT问题”是一个稍微好一点的标题。 “鼠标移动时的中断处理程序三重错误”是一个极好的线程标题。很多论坛常客并不是每一个话题都读；论坛流量现在已经增加到几乎不可能的程度（特别是在OS开发子论坛中）。一个好的标题会吸引那些知道这个话题的人的注意力。

== 语法 ==
糟糕的语法、拼写和/或标点符号会让你的帖子“更难理解”。最终，人们会忽略您的帖子或调试您的语言，而不是调试您的问题。远离1337和短信快捷方式。基本上，使用正确的英语（无论是英国还是美国的拼写在很大程度上是无关的）。

作为补充说明，OSDev。除英语外，组织论坛目前没有任何其他语言的子论坛。这是故意的。将论坛拆分得越多，阅读和回答每个主题的人就会越少。 Eric S.Raymond还指出，一般的编程（特别是操作系统开发）是一个使用了大量英语单词的主题，因此用英语交流更容易。

== 编程背景 ==
OS开发不是学习如何使用C、汇编或任何其他语言编程的合理场所，这是本wiki和论坛规则中都指出的。这些警告的存在是有原因的，如果你问一个问题，表明你没有阅读和理解这些规则，或者选择无视这些规则，那么你不太可能在这里赢得很多同情。

== 编程背景 ==
OS开发不是学习如何使用C、汇编或任何其他语言编程的合理场所，这是本wiki和论坛规则中都指出的。这些警告的存在是有原因的，如果你问一个问题，表明你没有阅读和理解这些规则，或者选择无视这些规则，那么你不太可能在这里赢得很多同情。

的确，操作系统开发论坛以对新手苛刻而著称。这是有原因的：操作系统开发并不是一个新手程序员可以合理处理的话题。很多人过早地进入这个领域——在他们有背景和经验来真正理解他们正在做什么之前——并被他们缺乏准备所烧伤。不幸的是，这导致我们一次又一次地看到许多相同的错误和问题，如果海报只是阅读这些警告并遵循他们的建议，这些错误和问题是可以避免的。

这不是一个可以通过简单的教程学习的领域，特别是如果你什么都不做，只是复制和粘贴教程代码，并试图在不理解它的情况下使其工作。确实存在的教程——对于这一领域的大多数科目来说，没有任何教程，而且它们也不能合理地“是”任何教程——只是作为指导方针，而不是食谱。从几个不同的现有源代码中剪切和粘贴代码，并期望它们神奇地结合在一起，这对于操作系统开发来说是不可行的。你需要学习很多东西，彻底了解你正在做什么，然后才能期望以有意义的方式进入这个领域。

== 研究 ==
维基不断地扩展和修改。很有可能你的问题已经有了答案。如果您在开发周期的早期遇到问题，这一点尤其正确：诸如[[Interrupts]]、设置[[GCC交叉编译器]]和[[Printing to Screen]]等主题在wiki中已经有了“大量”的信息。

如果您使用的是更常见的教程/示例内核，那么您的问题可能已经在论坛上得到了回答。使用论坛搜索功能，答案将等待。

如果你的问题是“我在哪里可以找到X”，或者“有没有可以找到Y的程序”，搜索引擎几乎肯定会给你一个比我们这里更快、甚至更好的答案。

一旦你找到一个解决方案，坚持使用它是很常见的——这里的很多人可能会给你指出一两个选择，但可能会错过最适合你的一个。

你不太可能通过问一些一般性的问题得到你想要的答案，比如“我如何从一张胖磁盘上读取？”，“如何加载程序？”，或者“有内存管理教程吗？”问这样的问题表明缺乏必要的编程技能；程序员应该能够自己解决问题，这清楚地表明他们还没有完成研究。一个更好的例子是将问题改为“我正在尝试做X”。我做了Y，但我不完全理解Z。"

=== 关于过期或不完整的Wiki文章 ===
任何大型协作项目（如wiki）都不可避免地会有一些信息在未被注意的情况下过时，这是一个令人悲哀的事实。同样不可避免的是，有些主题根本得不到他们需要的关注。如果你注意到你认为发生了这样的事情，请尽量不要生气；相反，礼貌地把它放在留言板上，这样某人——可能是你自己——可以添加和/或更新它。

这可能是因为到目前为止人们一直没有注意到这一点，也可能是因为还没有一位主题专家对此进行过讨论；也可能是有人将该页面的副本挂到了自己的私人页面上，以便对其进行重大修改，而这一点尚未反映在官方页面中。甚至可能在如何解决该主题上存在争议，这推迟了计划的更新。相反，你可能错过了其他地方的东西（考虑到维基的规模和蔓延，这肯定会发生），熟悉该主题的论坛访问者可以为你指明正确的方向。在这两种情况下，最好是建设性的、积极主动的，而不是火冒三丈。

== 细节 ==
操作系统代码高度相互依赖。如果您只提供tripple故障的中断处理程序的源代码，我们将无法在您的IVT设置中找到实际“导致”错误的错误。我们还需要知道您正在使用的编译器/汇编器/链接器、版本以及使用的命令行选项。

在[[Projects | OS Projects list]]中创建一个描述您的项目和环境的条目，并将该条目的链接添加到您的论坛签名中，这也将使我们能够快速获得诸如“您使用的是什么编译器？”等琐碎问题的答案或者“您的开发环境是什么？”或者“您正在使用GRUB？Bochs？VMware？”等

正如提供的信息太少，太多也同样有害。很容易给人留下错误的印象（“我有一个问题，但不能费心去缩小它。帮我修一下！").

虽然您的项目结构对您来说可能是完全合乎逻辑和直观的，但其他人可能仍然感到困惑，并且没有人喜欢通过挖掘几十个源文件来了解发生了什么。

试着找到一个足够重现问题的最小代码子集。（这也是一种很好的调试技术；您可以自己在过程中找到错误。)

和往常一样，任何操作系统项目的一个关键组件都应该是一个非现场源代码管理存储库；除了在代码保留和备份方面的优势外，它还允许响应者查看有问题的代码，而无需费力阅读大量代码帖子，或要求反复发布代码。如果您有这样一个存储库（而且您应该这样做），请确保包含指向您遇到问题的代码部分位置的链接。这将允许论坛访问者看到最新版本的代码，并直接参考它。如前所述，您应该将代码发布限制在您遇到问题的代码部分；如果问题在其他地方，回购协议应允许随着时间的推移确定问题。

== 格式化 ==
论坛有一个[代码]。。。[/code]格式化命令，您可以使用该命令突出显示代码段，避免smilies/fontifig标记弄乱文章。

把你的文章分成几个句子的段落。不要大声喊叫（例如用大写字母书写）或使用漂亮但无用的格式（如发光的彩色字体、移动的文本、微笑的线条等）。)。如果可能，请使用“预览”功能。

== 描述目标 ==
当一个人处理一个特定的问题X时，通常会找到一个看起来合适的解决方案Y，但您不知道如何正确实现，或者在调试时遇到问题。这可能会导致您发布一个关于如何正确执行Y的问题。这很好，“除了”这样做而不解释为什么要解决问题Y的上下文（问题X）可能会导致解决Y的答案，但不是以解决X的方式。事实上，可能是Y根本不能解X，或者有一个更好的解可以解X，而你却不知道。在这种情况下，询问Y会让你走上死胡同。充其量，这可能会让那些可能回答的人对你的目标感到困惑，导致他们根本不回答，即使他们可能真的知道如何解决X。

This sort of false solution is known as the [https://en.wikipedia.org/wiki/XY_problem XY Problem] (or more humorously, a [https://weblogs.asp.net/alex_papadimoulis/408925 'Bottle or Old Shoe' Question]), which is one of the most frustrating communication problems one can have on a forum.

为了避免这一点，你应该仔细考虑你是否已经解释了当你寻求帮助时你想要完成的事情。你不需要详细描述你的项目，但是一个直接目标的略图（以及你过去使用过的任何解决方案）可以在很大程度上为回答你的问题的人建立足够的背景。

== 识别问题并向其他人描述 ==
在发布之前，尽可能地隔离你的问题，并在帖子中尽可能多地提供信息。信息太少和太多都会使回答问题变得更加困难，但总的来说，信息太多总比信息太少好。

一般来说，在寻求编程帮助时，最好给出一个[http://www.sscce.org/简短、自包含、正确（可编译）、示例]，与实际代码库隔离。然而，在OS-Dev中，这可能是不可能的，因为bug通常与整个环境紧密相关，并且在任何情况下，为内核或驱动程序操作隔离代码都是不可能的。如果你能给出一个——即使它需要一些额外的支架——那么就这样做，因为这将大大有助于将问题与无关的细节隔离开来，但如果你不能，我们不会责怪你（尽管如果你“不愿意”，我们可能会责怪你，因为至少不尝试是不礼貌的）。

=== 发布代码示例与链接到存储库 ===
在解释问题时，您可能需要提供问题部分的代码示例或到代码存储库的链接，或者两者都提供。通常，在发布代码示例时，您希望提供足够的代码来说明问题，而不是更多。然而，这到底有多大可能很难判断。此外，非常长的代码示例往往很难在文章中通读，因此，如果一个代码段中有超过（比如）50行的代码，那么最好链接到它。即使是一个较小的片段，包括一个链接到您的回购是感激的，因为它可以让我们获得一些额外的背景问题。

请注意，张贴代码或回购链接，并告诉我们“这不起作用”是不够的。简单地给出一个大的代码示例或一个到回购协议的链接，期望我们回答您的问题，而不至少告诉我们您认为问题在代码库中的什么位置，这是非常不礼貌的。这样做而不解释故障模式（即，发生了什么或没有发生什么）更是如此。有人会认为这不需要说，但显然是这样。

----

遵循上述指导原则可以大大提高您获得快速、有用回复的机会。 (它使帮助你变得更有趣，所以那些有诀窍的人会留下来，明天仍然可以帮助你。)

[[Category:OS Development]]