openSUSE:Bug reporting FAQ
目录
您想要哪一種的回饋?
我們希望正向和負向的回饋都有 - 當然還有改善的點子。
- 正向的回饋意思是，我們很高興能聽到一個系統成功安裝並運作，某個部份已經過測試並工作正常。請回報這些到我們的 opensuse@opensuse.org 郵件列表。 正向的回饋會收錄在我們的測試資料庫。
- 對於負向的回饋，意即我們所遇到的任何問題，我們使用 Bugzilla。 請針對您遇到的每一個問題填寫一份個別的報告。這份 FAQ 會在後面解釋填寫錯誤回報的細節。
- 此外，改進的點子，通常稱為 feature requests(功能要求), 我們也很需要。我們使用 openFATE ，我們的功能資料庫，來收集這些意見。
一般錯誤處理
哪些地方應該一開始就要填寫? 哪些是我應該要變動而哪些不是?
- Component (部件)
注意: 並不是所有安裝過程中的錯誤都是 YaST 的錯，他也有可能是，例如說，核心的錯誤。 - Platform (平台)
如果您認為這是一個跨平台的問題，請使用 “all"，否則請描述您的平台。 - Summary (摘要)
人們看到摘要應該可以了解發生了什麼事。 - Bug description (錯誤描述)
加上所有關於這個錯誤的細節。注意，您不應該說 "如摘要描述"，因為摘要可能會變動。 - How to Reproduce? (如何重現?)
這一項很重要，針對這個我們有額外的解釋在 問題: 2-2.5 - Severity (嚴重性)
選擇正確的嚴重性，如果他會阻擋您在此產品的工作，將他標示為 “blocker (阻擋)" 。如果您認為我們不應在產品中搭載此未修正的錯誤，還有一個旗標 SHIP_STOPPER 可用。 - The rest (其他)
您不需要去填寫其他的區域，預設值就可以了。
在我回報錯誤之後會得到任何回饋嗎?
是的, 如果您的 "prefs"(偏好設定) 沒有變動，您將經由郵件收到相關的任何變動。
如果您被問了任何問題或覺得需要對任何的回應提出您的評論，請勿直接回覆到評論者的郵件位址(這是直接由 bugzilla 自動產生)，您應該使用 bugzilla 的網頁介面來溝通，因為這是唯一能讓相關資訊傳達給所有相關人士的方法。
哪些地方是我該變更，哪些不是?
通常身為一個非開發者僅要增加附加的評論，或將您自己加到 CC(副本)。 如果此錯誤是處於狀態 “NEEDINFO" ，記得在提供所有資訊後將狀態改為 “ASSIGNED" 。
如果在現在的 openSUSE 版本發現了和舊版本相同(或類似)的錯誤，我該怎麼辦?
建議要去移動此套件的版本，並在評論中寫類似 "這個已被回報為 openSUSE x.y 的錯誤仍然會在 openSUSE u.v 中出現，我將他調整了版本"。如果這個錯誤之前已經結案，您應該重新開啟他。
為什們大家會對我抓狂，只因為我在 Bugzilla 的"如何重現"區域填寫了"安裝 openSUSE x.y-Beta-z"，為什麼?
因為這是完全無用的資訊 - 對於如何重現這個錯誤是多餘且完全沒幫助的。 我們已經知道了這個錯誤是關於安裝方面，因為您已經在 Bugzilla 的部件列表中選擇了 "Installation"(安裝)，我們也同時就在此資訊的旁邊知道您安裝的是什麼版本。
我們真的需要知道的事你做了什麼，並如何去做 - 類似 "從 CD1 開機, 選擇 "安裝", 選擇語言 "Klingon", 安裝設定完全沒變動, 確認安裝, 然後我就看著我的硬碟冒出火花燃燒。"
不，我們真的不是吹毛求疵 - 我們有這麼多的安裝模組以及這麼多的安裝途徑，要將他們全部都弄清楚可能要花數年，您那裡有現成的可用資訊，所以請將他填寫在這個區塊。
當然，當您回報在最後的某個硬體設定對話框(像是印表機、電視卡，等等)有說明文字錯誤時，我們並不需要太過細節的描述 - 但是，我們真的需要知道您的操作步驟，如何到發生問題的地方。我們有許多的對話框，真的不容易得知您說的是那一個，您的操作路徑是哪一條。
人們非常不高興，因為我在 Bugzilla 錯誤描述中只寫了"如標題"--但是我的標題真的已經解釋了一切啊!如果堅持錯誤回報者一定要在描述的地方再重複一次，這不是吹毛求疵嗎?
不, 完全不是這樣。
標題總是會被變更。 您回報的問題可能只是冰山的一角 - 真正的問題可能出在一個完全不同的地方，之後發覺問題所在當然會改成對應的標題，這表示您的原本標題將會遺失。
所以，現在應該很清楚了，標題絕對不是一個拿來保存相關資訊與所回報問題的地方，而這些資訊是這個錯誤回報中唯一且最重要的資訊。
而重複所有在標題中的資訊也是個不好的格式。這樣有點懶惰，他可能只花你重做一次的時間，但每一個為此錯誤工作的人得要一次一次的搜索整個地方來找到相關資訊。
除此之外, 標題應該是簡潔明確的 - 但錯誤描述應該是要解釋清楚的。兩者的要求是截然不同的。
錯誤狀態 NEEDINFO(需要資訊)
錯誤狀態 NEEDINFO 是什麼意思，這個該如何處理?
NEEDINFO 表示此錯誤的擁有者 (只限在負責這個錯誤的人) 需要更多關於此錯誤的資訊 - 通常需要由錯誤的回報者提供。
如果您發現您所回報的錯誤被標示為 NEEDINFO, 請在之後的評論找尋問題或提供更多資訊的需求(像是紀錄等)。
在這種情況下，請一個一個回答問題或依照需求提供資訊，並在 Bugzilla 錯誤細節頁將錯誤狀態設為 ASSIGNED - 按 Accept bug(接受錯誤) (變更狀態為 ASSIGNED) 。
請使用 bugzilla 網頁介面來回答問題或附貼紀錄，不要用郵件寄出此資訊，除非您真的有非如此不可的理由這樣做。通常會有更多人幫忙處理這問題，所以此資訊必須讓他們都可以存取，確保這個錯誤可以被迅速修正。
當我將這個錯誤的狀態由 NEEDINFO(需要資訊) 變更為 ASSIGNED(已標定) ，會變成這個錯誤的的有擁有者(owner)嗎? (在 Bugzilla 錯誤細節 (bug details) 頁面，使用 Accept bug(接受此錯誤) 將狀態改為 ASSIGNED)
不, 錯誤擁有者不會改變，只有狀態會變動。您可以很安心的做這件事，不用擔心這會變成你的責任。
為什麼我將錯誤狀態由 NEEDINFO 改為 ASSIGNED 是重要的? 這不是錯誤擁有者的責任嗎?
不, 不論任何人回答問題或是提供了所需的資訊，就應該負責做這件事。
錯誤的擁有者使用 NEEDINFO 讓他們能更容易看清，什麼是他們使上力的(就是那些被標為 ASSIGNED(已標定), NEW(新的), 或 REOPENED(重新開啟)的) ，而哪些是因為缺少重要資訊而卡住的 - NEEDINFO 錯誤不會出現在他們的開啟錯誤的工作清單上。
這就是為什麼將狀態由 NEEDINFO 切換到其他狀態是重要的 - 錯誤的擁有者可能大概看一下由 Bugzialla 自動傳來的郵件，裏面有某個錯誤評論增加的訊息，但這個錯誤可能會留在 NEEDINFO 的狀態一段時間。
我們的維護者在尖峰時間(例如在 Beta 期間)會收到許多產生的郵件，他們很有可能無法對每一個做出個別的對應，所以經過一段時間後，他們得借助錯誤狀態的清單 - 他會看到某些要求的資訊已經做出回應，可以繼續解決此錯誤。
所以每個錯誤的回報者在回答了問題之後，應該將錯誤狀態由 NEEDINFO 改成別的。
當然，有時候你很幸運，錯誤的擁有者知道所要求的資訊現在已經足夠了，並自己將錯誤的狀態改成 ASSIGNED ，但只靠運氣通常不是個好策略。
請注意，有些一開始或在過程中指定給 BNC-Screening-Team (主要是 YaST- 以及 X11-相關問題) 的錯誤，不需要由回報者或提供資訊的人將狀態由 NEEDINFO 改為 ASSIGNED ，這是因為有不同工作流程的緣故，請特別注意。
如果我沒有回應我處在狀態 NEEDINFO 的錯誤，後續會如何呢?
如果一個錯誤一直維持在 NEEDINFO 的狀態超過一個月，可能會以 "Resolved: NORESPONSE" (已解決:無回應)來結案，並加上一個友善的訊息，像是 "所要求的資訊尚未提供，至今已四周，現在以 NORESPONSE(無回應)結案。請提供資訊後再次開啟此錯誤。"。
同為錯誤審查的一份子，其他的開發者可能也會做如此處理。
錯誤狀態 VERIFIED(已驗證) / CLOSED(已結束)
當我看到問題在新的版本或使用更新後已解決，我該將這個錯誤標示為 VERIFIED 或 CLOSE 嗎?
[TBD(尚待討論)]
錯誤狀態 WONTFIX(不修正)
請參考 Status WONTFIX
如何針對 ... 回報錯誤
關於針對不同部件回報錯誤，例如 Kernel(核心), KDE 或 Yast, 請參閱 遞交錯誤回報
openSUSE 文件
回報 openSUSE 文件的缺失，請在 Bugzilla 選擇 (component: "Documentation")。
Beta 測試
我想要參與 openSUSE 的 beta 測試，我該跟誰聯絡呢?
openSUSE 是開放的，只要去訂閱 openSUSE 計劃郵件列表 並回報您的問題，請參考 遞交錯誤回報。
我想要參與其他產品，像是 SLES 或 SLED，的 beta 測試，我該跟誰聯絡呢?
並非所有的產品都有 beta 程序，如果他有的話，應該可以由 The Novell Beta Program 存取。