新エスカレーションパス
出典: Mozwiki@jpmoz
- システムカスタマイズ (bugzilla)
- 実装案
- 運用案
- 名称案
- 求人案
- 他・過去からのスケール
現状
最終公開目標10月末。
- 試験サイト で報告・編集・完了のプロセスを試してプロセス本体の改善すべき点を見つける
- コミュニティー拡大
- Gecko関係コミュニティーへの宣伝を最終URLが決まれば行う
- Web表示に関するところは、ウェブデザイナコミュニティーと協業して一般的な HTML/CSS に関するものにできないか？
- たとえばHTML5の実装関係や、ブラウザ問わないナレッジベース構築とかの方向へ
- システム周りのメッセージの改善
- 内部にuiを含めたバグ登録を行う専用プロダクトを設置
- これができた段階で一旦DBをリセットして正式版として運用開始
背景
- プレゼンテーション @ 2008/春
- プレゼンテーション @ 2009/05 mozilla party 10 LT
- プレゼンテーション @ 2009/07 OSC 2009 Kansai LT
- プレゼンテーション @ 2009/10 OSC 2009 Tokyo Fall LT
現状の問題点:
- bugzilla-jpが唯一、開発者への日本語でのフィードバックパスになっているが、開発者の作業場としての性質上、敷居が高い(コメントに一定のクオリティが必要)
- bugzilla-jpは開発者、またはバグが主役であるため、投稿者(主にスレッドの作者)が主役となる他のフォーラムの感覚で利用しようとした利用者との摩擦が避けられない
これらの解決策として考えられるのは:
- bugzilla-jpの運営ルールの変更
- 別の窓口からbugzilla-jpへのエスカレーション
の2種類が考えられるが、bugzilla-jpは既に独特のルールに基づいて運営され、また、それに少なからず賛同している参加者・協力者が居るため、運営ルールの変更は現実的ではない。また、bugzilla-jpのインターフェース等は非開発者には使いにくいもので、この点からも現実的ではない。
エスカレーションのパスを新たに用意すれば、フィードバックをくれる人にあわせたルール、システム作りが可能。
これらの背景から問題報告センターが作られているが主にシステム的な問題を考慮すると違った形でコミュニティを作り上げることが好ましい。主な問題点:
- wikiベースなのでUI等に無理があるように思える
- アカウント無しで登録できるため、投げっぱなしの報告者に対してコンタクトをとれない
- セキュリティに関わる問題等を非公開にできない
- 過去の内容の検索機能が不十分
現状で新たに採用するシステムとして有望なのはUIを通常のフォーラムライクに改造したbugzilla-ja。アカウント作成の必要はあるが、アカウントを作ることを面倒くさがる人がきちんと検証に協力してくれるのか、と考えると、その手間は問題にはならないのではないかと考えられる。
フィードバックをくれる/欲しい層として想定しているのは:
- も組フォーラム等でバグではないのかと問い合わせる人
- Webデザイナ、Web開発者
これらの層ごとに窓口を用意することで今までよりも幅広い層からフィードバックを受け付けたい。
bug-jpとの差別化ポイントとして、考えているのは Masayuki 2009年5月25日 (月) 16:57 (UTC)
- 開発者コミュニティではなく、ユーザコミュニティ
- 全ての報告(スレッド)をbug-jpのように解決していくことを目指す運用ではない
- 大量に投げてもらって、良いものをピックアップして処理する感じ (bug-jpは良いものを投げてもらって、確実に処理していく感じ)