一個好的 Bug 對使用者、開發者都是很有幫助的，因此來學習如何報一個好的 Bug
而這篇文章也是 Bugzilla 系列的最終回
前些天瞭解了 Bugzilla 的使用操作與一些觀念，因此今天要回頭看第一篇文章提到的「Bug report writing guidelines」，藉此學習 Mozilla 針對貢獻者撰寫的 Bug Report 指引手冊。
這份手冊大綱有以下幾點
整份文件的精要其實都在 How to report a bug，以下其他幾點都是舉例說明，因此讓筆者快速總結寫一份好的 Bug Report，身為貢獻者的注意事項有哪些
在報 Bug 之前有件事情是相當值得初學者注意的
確保軟體是最新版本，理想來說，最好不是釋出的版本（Release）而是開發中（dev）的版本，避免你要回報的 bug 或許早已被修復
取得最新版本的方式隨著不同開源專案而變化，舉例來說：放在 GitHub 上的專案，通常會將開發中的分支（branch）當作主頁面的分支，而非 master。相對容易取得的釋出版本，開發中版本多處於需要自行編譯的狀況，因此如果第一時間發現 Bug 的軟體版本不是最新釋出版本，建議先取得最新的釋出版本嘗試一次，如果仍有狀況，就進到下一個步驟。
發起一個不重複的 bug 是昨天與前天文章的內容之一，在發起自己的 Bug 前，先確認是否已經有存在的 Bug 是一件很重要的事情，如果不是先調查，你的貢獻反而會變成專案維護者的負擔，因此 Bug 搜尋技巧相當重要。而後市選擇正確的產品與功能分類，以確保 Bug 的歸類是正確的。
好的 Bug Report 第一先決條件：下一個精要的標題！如同手冊舉的例子，要言簡意賅的描述 Bug
Good: "Cancelling a File Copy dialog crashes File Manager"
Bad: "Software crashes"
Good: "Down-arrow scrolling doesn't work in styled with overflow:hidden"
Bad: "Browser should work with my web site"
Bug 若無法重現，就無法修復
筆者認為在 Bug Report 的環節中，初學者要花點時間才能掌握好，不過如同手冊所說「Bug 如果無法重現，就不法修復」，對於有心想貢獻的朋友，務必謹記在心。
根據手冊，基本要素有三大項
簡單來說就是一種科學實驗的精神，描述步驟越詳細越好，然後還要清楚預期行為來當作對照組，也因此詳細記錄執行結果是很重要的。
筆者認為「額外資訊」就好比 Bug 的身分證名，舉凡
環境設定變數
此手冊舉 Firefox 使用者喜好來說明：建議使用一個初始化的使用者設定（profile）來當作重現 Bug 的環境，避免 Bug 的產生可能是具有多種變因，而導致後續修復的困難。
再舉 LibreOffice 為例，之前筆者見過一種例子：在 MS 的系統下，使用者常常會裝很多非開源字體，如果用 LibreOffice 開啟就有可能導致軟體崩潰/內容跑掉，這樣的情況對於開源軟體來說，不是一個可以修復的 Bug，因為源頭的字體並不是開源的。
錯誤訊息
筆者認為錯誤訊息的回報就真的需要有點經驗的使用者才能做到，手冊中指出的錯誤訊息根據不同的來源就有不同的回報方法，舉例來說如果是 Crash 比較好的錯誤訊息就需要提供 "stack trace" 的訊息，要能夠撈出 stack trace 的錯誤訊息，對於一般使用者來說是相當有難度的。
不過如果是在 Linux 底下，如果是 Crash 錯誤與其用圖示開啟，不訪可以嘗試用 Terminal 來開啟程式，也有機會撈出錯誤訊息，並加以回報
今天的主題「如何報一個好 Bug?」，雖然沒那麼簡單上手，但多練習幾次總會賞手的！那連續四天的 Bug 的主題就先暫時告個段落，希望有對讀者在參與開源軟體貢獻/管理專案的 Bug 知識有幫助。
明天的主題會再找一個跟開源組織相關的主題來探討，但是開源組織的生態觀察筆記要在 30 天內每天僅僅花 2 小時介紹，筆者想應該是介紹不完，而在寫文章的過程中，越發瞭解只有實際參與，才能真正了解開源組織，因此建議對開源有興趣的朋友也能及早投入，在開源組織，人人都能貢獻 :)
iThome鐵人賽
看影片追技術