正在提问时
按时间先后列出问题
问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。
记录从哪里开始
时间顺序不需要从你安装系统那天开始。它应该从“与问题可能相关的第一步”开始，例如最近一次升级、配置变更、依赖安装、数据导入、命令执行或重启。
一个有用的时间线通常包含：
- 你做了什么。
- 系统返回了什么。
- 你接着尝试了什么。
- 问题第一次出现在哪里。
- 之后你如何确认它仍然存在。
调试信息要适量
如果挂掉的程序有诊断选项（如 -v 的详述开关），试着选择这些能在记录中增加调试信息的选项。记住，多不等于好。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。
一大段未经筛选的日志会增加阅读成本。更好的做法是保留完整日志的链接或附件，同时在正文里引用最相关的几十行，并说明它们为什么重要。
长问题先给摘要
如果你的说明很长（如超过四个段落），在开头简述问题，接下来再按时间顺序详述会有所帮助。这样黑客们在读你的记录时就知道该注意哪些内容了。
摘要可以很短，例如：升级到 2.4.1 后，导入 CSV 会在第三步报 UnicodeDecodeError；回退到 2.3.8 后恢复正常。下面是完整时间线。 这样的开头能让回答者先建立整体判断，再进入细节。