もずはっく日記(2008年6月)

まずはベースとなるシステムが必要です。最低限必要と思われる機能は、まずはアカウントの作成機能です。これを煩わしい、と思うユーザのフィードバックはノイズとなって開発関係者の労働力を無駄に削ぐことになる可能性が非常に高いのでデメリットは無いと思います。アカウントにはメールアドレスを必須としておき、メールアドレスで最初のフィードバックに対するスタッフからの確認や問い合わせが通知可能である必要があります。

各フィードバックの内容は、ステータスを管理できなくてはいけないでしょう。例えば、フィードバック内容が未確認、フィードバック内容を確認済、Bugzilla-jpに報告済み、Bugzilla-orgに報告済み、Trunkでは修正済み、リリース版で修正済み、フィードバック内容はバグではなかった、等々が必要でしょう。

また、スクリーンショット等が必要になることも多いでしょうから、ファイルの添付機能も必要でしょう。

後は念のためにセキュリティフラグも用意しておいた方が良いと思います。

こういったシステムを作成、管理、メンテナンスしていくことが必要です。サーバ資源はもじら組等と交渉すれば使えると思います。

バグの再現確認は現在のbugzillaよりも手間がかかるでしょう。Bugzillaではリリース版のBranch限定のバグを取り扱う特殊な場合を除き、基本的に全ての報告者が最新のTrunkビルドを利用していることが前提となります。

ですが、ユーザにTrunkを使わせるのは酷ですので、全てスタッフ側で検証する必要があると思います。その場合、報告されたバージョン、最新のリリース済みバージョン、そしてTrunkでの検証が必要でしょう。

エンドユーザと、開発者では考え方等がかなり違います。また、エンドユーザ同士でも、そのバグで実害を被っているか、否かで意見が変わってくるでしょう。Bugzillaはバグの担当者や、コンポーネントのオーナーにその設定権限があるため、基本的にもめることはありませんが、ユーザ主体のコミュニティではそれはもめ事の種となってしまう可能性があります。作らない方が無難というものでしょう。

要望というものは人によって異常に温度差があるものです。

一部の人にはあったら便利なものでも、大多数のユーザにとって不要なものであったり、多数のユーザに混乱を与えかねないものは拡張機能にすべきものです。

また、より最悪な要望は技術的に困難すぎるものです。あれば理想的でも現実的ではない案であれば何の意味もありません。

ですが、要望を出した人というのは、真剣にその機能が実装されることを望んでいることに注意してください。要望を出す人は提案する内容がすばらしいと考えてフィードバックを返すわけですから、その提案を蹴られると不快に感じ、中には炎上する人も出てきます。

不毛な争いが起きないように要望は内容に関わらず一律受け付けない、という方針は必要でしょう。

開発未経験な人ほど、その報告内容は支離滅裂だったり、情報が不十分だったりすることが多いです。ですが、これは自然なことです。開発経験者がなぜ有用な報告を行いやすいかというと、開発者の求めている情報の察しがつきやすいからです。

この差はどうしようもないので、必要となる情報のガイドラインは必要でしょう。しかし、ガイドラインを作ってもおそらく報告者は読んでくれません。そのため、Bugzillaで採用しているような、ダイアログ形式の報告フォームを作らなくてはいけないでしょう。つまり、スタッフが欲しくなる情報を入力してもらえるよう、うまく誘導できるようにすべきです。

コミュニティリーダをトップに据え、システム管理者や、各種貢献者と、その貢献量をはっきりとさせた方が良いかもしれません。相手が一見さんであればあるほど、対応してくれている人がどのようなレベルの人なのか気になると思われます。また、なにか決断しなければいけなくなった時に上下関係がはっきりしているのであれば、その決断を誰が下すべきで、誰が従うべきかがはっきりします。意志決定プロセスを尊重できない人はその組織内での活動には不的確な人と言えます。

また、貢献者の評価をなんらかの形で明確に集計するのであれば、昇格だけではなく、ブランク期間に応じた降格も必要でしょう。貢献を途中で中断した人が、現役の貢献者よりも発言権があると問題だからです。