You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.




Mozilla 技術傳教程序說明

技術傳教的 Bugzilla 欄位

各個 Bugzilla 欄位在 Mozilla Site Evangelism 的意義。

欄位 選項 定義

Product (產品)

Tech Evangelism

所有技術傳教的 bug 回報都應該在 Bugzilla 的 Product 欄位勾選 Tech Evangelism

Component

Language-based

技術傳教用 components 欄位來區分語系。 請依照網站使用的語系來選擇最適當的 component。

Priority(順位)

P1

重要網站,重要問題 - 請優先處理這一類。 每位 component owner 有責任維護一份首要的網站清單, 並且把關於這些站台的 bug 報告用關鍵字 evang500 標明。

Priority(順位)

P2

重要網站,次要問題 - 可能的話,處理P1順位 bug 時一併處理這一類; 尤其當這問題很容易處理的時候。

Priority(順位)

P3

次要網站,重要問題 - 有多餘時間的情況下才處理這些網站。 因為要發揮最大效益,我們必須考量時間成本。但是如果處理這個網站 有助於產生有用的文件,以後能運用於幫助其他的網站,那麼就算有 更高順位的問題,我們可以讓這個插隊。

Priority(順位)

P4

次要網站,次要問題 - 很不幸地我們現在沒有時間處理這一類。 我們必須暫緩處理它們。

Keywords(關鍵字)

evang500

用 evang500 這個關鍵字來凸顯重要的、要優先並小心處理的網站。 可以查詢各個component的重要網站清單來確定是否要加這個關鍵字。

Severity(嚴重程度)

Major(重要)

Severity(嚴重程度)

Normal(普通)

Severity(嚴重程度)

Minor(次要)

Status(狀態)

UNCONFIRMED(待確認)

社群的新成員還需要時間證明她能夠提交正確、明確的 bug 報告。因此,當 她提交 bug 報告時,會標示為 UNCONFIRMED(待確認)。

對這類報告,應依本文件處理(如確認 Product, Priority 是否正確)這些 Bugs。

Status(狀態)

NEW

這狀態表示該 bug 報告已受人「確認」或是由有可自動確認權限的成員提報的。

Status(狀態)

ASSIGNED(已指派)

請妳先完成對網站的分析,並且寄出 Evangelism Letter 給站方之後, 再把 Evangelism bug 的狀態改為 Assigned (已指派)。 當妳首次分析一個網站時,除了檢視報告中原本提到的網頁,請多檢視幾個 網頁,找出這個網站整體的問題根源,並且寄出 Evangelism Letter,信中除了原本被點名的 URL,再加上之前妳檢視的 那些網頁;針對這些逐頁提出站方可改善事項,以及整體可改善方向。

使用本文稍後提到的 Status Whiteboard(狀態白板)來描述這個 Bugs,並且在 bug description (問題敘述)中明確地描述這個網站的問題的,例如: using LAYER tags, LAYER API, IE4 only API, Incorrectly Nested Tags 等等。

請牢記,我們的要求會給站方帶來額外的工作量。一定要注意禮節、專業 、尊重。把別人惹毛是沒有助益的。

Target Milestones (目標時程)

(追蹤月份/Future(未來))

使用目標時程來決定何時應該跟進這些技術傳教的 Bug。 技術傳教目前是以「月」為時程的單位。請依時程複查這些已經被 evangelized [status == ASSIGNED] 的 bug。 除非你是 Bug 的指派人,並已與站方溝通,否則不要竄改目標時程。

如果站方收到了兩次Evangelism Letters卻既不回應,也不 改正她們的網頁,那麼把目標時程設為FUTURE。

Resolution (判定)

WORKSFORME (我個人可以瀏覽)

當妳無法用自己的電腦重現這個問題的時候,判定為此類別。

Resolution(判定)

DUPLICATE(重複)

這個網站有類似問題已經被人提報過了。

Resolution(判定)

FIXED(修復)

站方已將問題修復

Resolution(判定)

WONTFIX

在Bugzilla的技術傳教類別裡,請不要使用 WONTFIX。 那些告訴我們,她們不打算修改她們的網頁的站方,請在 status whiteboard (狀態白板)裡面,標記為 not-responsive (不予回應)。

Resolution(判定)

INVALID(沒有根據的)

一般來說,在Bugzilla的技術傳教類別裡,不要使用INVALID。 不過component owner有自行決斷的自由,將某些 bug 判定為INVALID。

Summary(摘要)

網域 - 從使用者角度,簡短明確敘述網站的問題。

在填寫摘要的時候請使用底下的格式:

例如,如果 http://mail.netscape.com/ 的問題在於JavaScript 使用到Layer,那麼摘要可以寫成:

netscape.com - mail 使用 document.layers

Status Whiteboard(狀態白板)

not-responsive(不予回應)

在狀態白板中用 not-responsive 來標明那些表明不願處理的站方。

Status Whiteboard(狀態白板)

technote-needed(需要技術文件)

如果一個問題普遍到應該寫份教學文件,將這個問題在狀態白板標記為 technote-needed。 等到有人寫出這份教學文件之後,再移除 technote-needed的標記。

Status Whiteboard(狀態白板)

plugin(外掛模組)

在狀態白板使用plugin來標記那些跟外掛模組有關的問題, 後續需要聯絡或協助該廠商處理。

Status Whiteboard(狀態白板)

author(作者)

如果問題需要聯絡/協助網頁製作工具的開發廠商/程式撰寫者, 在狀態白板使用author來標記。

填份新的技術傳教 bug 報告

初次填寫 bug 報告之前請先看一下Getting Started

  1. Mozilla技術傳教組並不是用來提供妳投訴服務的。在妳填寫 bug 報告之前,冤有頭債有主, 第一步先寫信給網站站方,抱怨她們把網頁設計成不支援Mozilla。

  2. 確認這個問題屬於技術傳教類別。如果妳不確定的話,請針對最適當的類別(產品)提出 bug 報告

  3. 在 Bugzilla 開一個 bug 報告,在 Product (產品)項目選擇 Tech Evangelism。
  4. 選擇適當的Component,請依照網頁使用的語言分類。(例如選擇Chinese-Traditional,正體中文)。

  5. 選擇硬體平台和作業系統

    如果妳確定問題和特定平台/作業系統無關,請選All。

  6. 選擇這個 bug 的初始狀態(Initial State)

    如果妳確定這是一個 bug 的話,請選擇NEW(新的); 不太確定的話,選擇UNCONFIRMED(待確認),Mozilla社群會去確認。

  7. 選擇嚴重程度

    請在major,normal或minor中擇一,其他的選項對技術傳教類的 bug 來說 沒有意義。至於到底多嚴重?相信妳可以做出最佳的判斷。

  8. 選擇此問題的負責人(Assign to)

    如果妳要負責追蹤這個問題的話,可以填入自己的 電郵位址。不然就把這個欄位空白,讓 Component Owner 去處理。

  9. 輸入網址(URL)

    妳可以輸入用 Mozilla 瀏覽有問題的特定頁面。要注意的是,通常來說如果網站的特定頁面有問題。 可能首頁也有同樣的問題。如果真的是這樣的話,妳可以輸入網站的首頁來代表。

  10. 輸入摘要

    請輸入URL的"主要部分",後面加上 - 以及簡短描述。描述不需要很技術導向。

    舉例來說如果妳要提報 http://www.foo.bar.com/help/support/,那麼 bar.com就是URL的主要部分。 如此一來,大家可以用摘要的文字來對 bug 做分類,也可以把同一個公司的 bug 歸類在一起。

    • bar.com - Displays differently than IE5
    • netscape.com - Does not allow Mozilla
    • fubar.co.uk - Does not support secure connections in Mozilla

    請大家留意的是,摘要應該是一個普通的使用者也可以填寫和理解的。更多有關 技術細節的部分稍後可以加在Status Whiteboard(狀態白板)等到這個 bug 被歸類、指派之後。

  11. 輸入描述

    請針對妳瀏覽該網址所遇到的問題,填寫足夠的細節描述。Bugzilla系統中 有很多欄位是要在 bug 送出之後才能繼續填寫的。所以在此請填寫簡明的描述。在送出這份 bug 報告後,妳可以加入更多的細節資訊。

    。接著是一件很重要的事,請盡量把當初跟站方 接洽的訊息附上來。請記住,客戶的抱怨比不知名的Mozilla技術傳教者寄去的電郵有用多 了。如果妳希望站方能夠支援Mozilla妳一定要填寫客戶抱怨!

  12. 送出 bug 報告

    如果妳不做這個動作,這份報告不會被儲存,前面的辛苦都白費了!

  13. 修改剛剛送出的 bug 報告

    如果妳回報的是跟網頁顯示有問題,可以附上screen shot。 夾檔的時候請選擇正確的MIME type。請盡量縮小檔案的大小。妳可以減低color depth, 並且擷取比較小的畫面。只要能夠說明妳的問題就夠了。

    如果問題網頁有invalid HTML或JavaScript,請先存檔到妳的硬碟,然後在夾檔的時候 MIME type選擇text/plain。這麼做可以留下一份原始資料,讓我們可以跟後來的版本 (如果有的話)比對。

聯絡網站站方

  1. 重新檢視 bug 報告,如果有需要,執行 QA 流程

  2. 查出站方聯絡人

    設法用網站上的資訊找出站方的聯絡人。如果找不到的話,可以試著用 Internic 的 Whois 來找。

  3. 寄送Evangelism Letter

    Mozilla Evangelism Letters這封信件為本,妳可以跟站方描述她們網頁的問題,甚至建議如何修改才能支援Mozilla和(網頁)標準。

    在跟站方溝通的時候,請記得永遠保持"禮貌"和"專業"。這封信件是從妳個人的電子郵件 帳號寄出的,妳必須替自己的言論負責。

  4. 紀錄聯繫經過

    在 bug 報告中,註記你已經寄送Evangelism Letter,並簡述信件中妳加入的意見,以及站方聯絡方式。 不過不要把整封電郵貼上來。

    設定時程為初次聯絡後的一個月(至少)。之後你可以按月查詢、追蹤、重新測試這些站台。

    把這個 bug 報告指派給妳自己,然後標記為 ASSIGNED (已指派)。

  5. 如果Evangelism Letter被退信‧‧‧

    在 bug 報告中註記無法聯絡站方

    可能的話,試著找出其他的聯絡電郵,再重新寄送 Evangelism Letter。如果找不到, 在報告中註記,然後把這個 bug 的 Target Milestone (目標時程) 標記為 Future。

  6. 如果站方做出負面回應‧‧‧

    在這份 bug 報告的 status whiteboard (狀態白板)中標記為 not-responsive, 然後再出發。我們還有 很多站台可以去聯繫;以後也還可以回頭檢視這個當初拒絕我們的站台。

Quality Assurance(品質管制)

妳必須要先擁有對 bug 做Confirm的權限,才可以對 bug 做QA。 在執行(此任務)之前,妳必須對 Evangelism 程序非常熟悉,並且和下列人士討論過流程: Daniel Wang (中文亦可)、Zach Lipton(irc: zach)、Asa Dotzler (irc: asa)、或者 Evangelism 社群的其他活躍成員。 妳可以在 irc.mozilla.org 的 #evangelism#mozillazine 找到她們。

UNCONFIRMED / NEW (待確認 / 新的)

  1. 在 Bugzilla 搜尋是否為重複

    如果這個站台已經被提報過了,而且還沒進入 VERIFIED 的狀態,那麼就把新的這個標示為 DUPLICATE (Resolve bug, changing resolution to),並且輸入它和哪個號碼的 bug 重複。

    如果有任何新的,有關這個站台的資訊,請確認之後,加註在原來的 bug 的 comments。

  2. 親自瀏覽站台

    確認這個站台是否仍然不支援 Mozilla。如果站台用 Mozilla 觀看沒有任何問題,把這個 bug 標示為 WORKSFORME 。

    如果這個 bug 原本被標示為 UNCONFIRMED (待確認) 而站台的確有問題,請把狀態改為 NEW (新的)來確認這個 bug 的存在。

  3. 分析站台

    確認原來的 bug 報告各方面敘述是否明確、精準。有需要的話,可以加上另外的註解。

ASSIGNED(已指派)

重新檢視那些已指派,但是時程已經過期(上個月)的 bug 報告

再連上那個網站,看看問題是否依然存在。多點選幾個該網站的頁面來確認站方已將問題完全修正。 如果這個站的問題依然存在,與站方再度聯絡,或在 status whiteboard (狀態白板)裡面標記 not-responsive (不予回應)。如果用 Mozilla 瀏覽這個站 已經沒有問題,就可以把狀態設為 FIXED (修復)。

RESOLVED(已解決)

重新檢視已解決的 bug 報告

如果 RESOLUTION (判定)是 FIXED (已修復)或 WORKS FOR ME (我個人可以瀏覽)

再連上那個網站,看看問題是否依然存在。多點選幾個該網站的頁面來確認站方已將問題完全修正。 如果這個站的問題依然存在,把狀態設為 REOPENED (重新開啟)。如果用 Mozilla 瀏覽這個站 已經沒有問題,就可以把狀態設為 VERIFIED (已確認)。

如果 RESOLTION(判定)是 DUPLICATE(重複提報)

再連上那個網站,確認被標示為 DUPLICATE (重複提報)的 bug 報告,真的跟原來那份 bug 報告一樣, 提報了同一個網站。確認重複的 bug 報告中提到的所有訊息,都包含在原來的 bug 報告中了。如果沒有的話,請加在原來的 bug 報告中。