追求真相的聖堂 – Bugzilla

整個 Mozilla 的軟體開發流程中，有個非常重要的 Bug 追蹤系統 – Bugzilla 。在 Bugzilla 中，能讓世界各地所有人提出 Bug、提出個人的看法、以及提出解決 Bug 的 Patches。也因此，整個溝通體系架構是相當龐大。且為了找出真正的問題點，提升整個軟體的成熟度穩定性，甚至有些 Bug 的 Comments 達到數十篇。所有參與 Bugzilla 的人，大家所追求的都只有一件事 – 找出問題的真相，因此稱呼 Bugzilla 為追求真相的聖堂並不為過。

而這個流程也需要非常巨大的時間成本。試想，當測試者想要提出一個新的 Bug 時，測試者就已經花費時間推論這個 Bug 是否存在以及提供必要資訊。而當開發者開始解決 Bug 時，使用者、測試者、Reviewer、與開發者需要來來回回花費更多時間來找出這個 Bug 的真正問題點並解決問題。再從另一面向來看，管理者需根據 Bugzilla 系統上 Bug 的數目、更新速度來思考這些現象背後的真正原因。從上述整個流程看下來，在整個 Bugzilla 中所花費的時間成本是相當驚人的。也因此，為了讓每個參與認同 Mozilla 宗旨的人，能夠更有效率地完成更多的軟體。在這個聖堂中有許多規範需要被遵守。

首先，在 MDN 中的 Bug writing guidelines 提供了創建新 Bug 時需要確認下列的步驟：

1. 創建新 Bug 之前需先

1) 確認是用最新的軟體測試。

2) 確認 Bugzilla 上沒有相同問題的 Bug。

3) 按照 Bugzilla 上的” Enter a bug “的流程來創建新的 Bug 。

2. 寫出詳細的複製步驟。

3. 清楚地說明問題。

4. 選擇 Bug 發生在哪一個產品的哪一個模組中。

5. 指定 Bug 的型態。

而在 Bugzilla 網站上，也列出在 Bugzilla 上溝通時，所需要遵守準則：(詳細的內容請參照 https://bugzilla.mozilla.org/page.cgi?id=etiquette.html )

1. Comments 時，需要注意下列幾點。

1) 不作沒有重點的 Comments – 除非有建設性或是有幫助的評論，否則不要在 Bug 上評論。

2) 開發者沒有義務的解決問題 – Open Source 不代表開發者有義務滿足個人的要求。

3) 不要提供攻擊人的 Comments – 批評可以幫助大家建構出更好的軟體，但前提是提供針對事情的評論，否則會失去討論的重點。

4) 不要用私人信箱來溝通 – 所有的 Comments 都需要寫在 Bug 上，讓所有人都知道。

2. 修改 Bug 欄位時，

1) 不要修改屬於其他人的 Bug 。

2) 不要直接改變別人的決定。

3. 不確定是否要遵守上述規則時，即預設這些規則是一定要遵守。

誠如 Bugzilla 開發網頁所說，Bugzilla 是開發來讓程式員或是不同的群體”有效地”追蹤 Bug，並讓各個 Team 能夠有組織且”有效地”溝通。其中提到了有效地 ( effectively ) 兩次，很明顯的，Mozilla 很希望藉由 Bugzilla 來幫助所有人”有效地”完成的軟體開發工作。所以，每一位使用 Bugzilla 的人需遵守上述的規範，來進行有效地追求真相的流程，也才能維護這個聖堂存在的目的。