Godfather.NTUpsy： 「親和力」還是「親合力」？ 前者是指一般的「容易接觸」，後者好像是用在一些化學作用之類的東西。 但在下不確定網站寫作是不是已經約定俗成要寫成後者。

http://dia.z6i.org/ 親和力

技術指導部分

[BobChao] 我這樣想：

1. 一開始我們先照目前的方式蒐集各網站的問題
2. 挑幾個比較重要的網站，為其建立專門的 Wiki 頁面，上面詳述每個人發現的問題（能有螢幕抓圖最好）
3. 到討論區 Call for help。
4. 討論區上的朋友看到後可以進入 Wiki，大家一起來編輯、寫對此網站的建議。
5. 當「建議」可以解決大部分問題後，某個人比照中文 Tech Evangelism 稍微改寫，貼到 Wiki (對，又開一頁)。
6. 再到討論區 Call for review，過兩天沒問題就寄出。

好像有點複雜，其實有點比照 Bugzilla 模式，多了一個「信件審查」的步驟。另外我發現大部分人不太有習慣看 Wiki 上的更動，所以如果有很重要的事情需要幫忙，或許還是得在討論區上廣告一下（也可以寫在簽名裡）。

[PowerOp] 聽起來不錯，可是我們就完全不用Bugzilla了嗎？

[BobChao] 我不知道該不該鼓勵大家用 Bugzilla 耶 @_@ 我們還沒有中文的 componet owner，而且也怕大家覺得太麻煩。（我個人花了好一段時間才習慣，而且現在提報還會很害怕自己做錯 XD）

[PowerOp] 我想，先鼓勵大家多參與Tech Evangelism，方法上，當然是wiki和討論區比較可親。至於Bugzilla，dwx說，在 Bugzilla 打中文不容易 (一個人打 UTF8，如果另一個人是預設 BIG5 的話又要換到 UTF8，這樣子有幾個發言人很快會有編碼上的衝突)，也許我們可以提醒自己還有這個（跟國外Mozilla社群）共通／同的提報系統，到時候看是要把所有的追蹤項目都去開bug report，或者選一些上去開。

停滯的專案，改良？

BobChao 11:30, 2 Apr 2005 (CST) : 這個專案立意良好，不過目前停滯了。為了提高效能，我想了以下的改良方式：

1. 目標先縮小到「Firefox 能看」，使用上沒問題的先放著。
2. 一次挑五個網站，徹底聯絡並解決問題。
   1. 挑五個大站，列上追蹤系統（rt: 新建立），一一檢查。 (2d)
   2. 列出「使用上」的問題，回報時順便貼一下該站客服信箱。（rt: 開啟，更動負責人為專案管理員）
   3. 所有具消費者身份的人先寄信給該站客服（rt: 已處理／待處理） (3d)
      • 如獲正面回應，貼上來且列入日後追蹤。（rt: 非常不嚴重）
      • 如三日相應不理／獲負面回應（只要沒有「承諾」改進都算，包括「我們會評估相關細節...」），繼續進行下一步。
   4. 找出問題解決方案。（亦即，這時才開始研究程式） (3d)
      • 我們不見得個個是高手，無妨，找不到就回報到 Bugzilla，請其他高手幫忙。
      • 找到的話把解決方案貼上來，進行下一步。
   5. 專人負責此站聯絡事宜，將解決方案以標準信方式寄給該站。（rt: 更動負責人） (10d)
      • 如獲正面回應，貼上來且列入日後追蹤。（rt: 非常不嚴重）
      • 如十日相應不理／獲負面回應，列入不理會名單，結案。（rt: 延宕）
   6. 日後追蹤名單: 每月底檢查此名單中網站是否已解決問題。
      • 已解決者結案。（rt: 已處理／已完成）
      • 未解決者標記之（rt: 嚴重），次月若仍未獲解決亦無後續回應，再發信（回到第五步）。循環兩次仍未獲解決者，列入不理會名單，結案。（rt: 延宕）
3. 處理目標: 每兩個禮拜處理八個網站，列入不理會／追蹤名單。
4. 我們需要一群固定人馬維持這個流程。（專案管理？ 有點複雜我也不太懂。）
5. 這個流程用 Wiki 太複雜了，我想可以到 http://rt.openfoundry.org 申請新專案，用裡面的錯誤追蹤系統，大家會比較方便（沒碰過的人也可以玩玩看 :) ）

大概是這樣，大家覺得呢？

補: 我列上了在 ossf 追蹤系統中各階段應標示的狀態