正在提問時
按時間先後列出問題
問題發生前的一系列操作，往往就是對找出問題最有幫助的線索。因此，你的說明裡應該包含你的操作步驟，以及機器和軟件的反應，直到問題發生。在命令行處理的情況下，提供一段操作記錄（例如運行腳本工具所生成的），並引用相關的若干行（如 20 行）記錄會非常有幫助。
記錄從哪裡開始
時間順序不需要從你安裝系統那天開始。它應該從“與問題可能相關的第一步”開始，例如最近一次升級、配置變更、依賴安裝、數據導入、命令執行或重啟。
一個有用的時間線通常包含：
- 你做了什麼。
- 系統返回了什麼。
- 你接著嘗試了什麼。
- 問題第一次出現在哪裡。
- 之後你如何確認它仍然存在。
調試信息要適量
如果掛掉的程序有診斷選項（如 -v 的詳述開關），試著選擇這些能在記錄中增加調試信息的選項。記住，多不等於好。試著選取適當的調試級別以便提供有用的信息而不是讓讀者淹沒在垃圾中。
一大段未經篩選的日誌會增加閱讀成本。更好的做法是保留完整日誌的鏈接或附件，同時在正文裡引用最相關的幾十行，並說明它們為什麼重要。
長問題先給摘要
如果你的說明很長（如超過四個段落），在開頭簡述問題，接下來再按時間順序詳述會有所幫助。這樣黑客們在讀你的記錄時就知道該注意哪些內容了。
摘要可以很短，例如：升級到 2.4.1 後，導入 CSV 會在第三步報 UnicodeDecodeError；回退到 2.3.8 後恢復正常。下面是完整時間線。 這樣的開頭能讓回答者先建立整體判斷，再進入細節。