追求真相的聖堂 – 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 的人需遵守上述的規範,來進行有效地追求真相的流程,也才能維護這個聖堂存在的目的。

 

 

 

 

您可能也會喜歡

目前找不到相關文章

對此文章發表回應

你的電子郵件位址並不會被公開。 必要欄位標記為 *