zz54547tz さんが書きました:
＜kiyo4_k さんへ＞
私の未熟な行動により、あなたを不快にさせてしまったようで、申し訳ありませんでした。私はルールに従って行動しているつもりでしたが、不充分だったようです。今後はバグに関する内容は一切投稿しません。
これは前に書いてしまったのでもう良いです。それとバグに関する内容を投稿しないで欲しいとは言いません。
逆にバグと思われるような現象に関してのディスカッションは歓迎されるものではないでしょうか。
今回はBugzilla投稿への同意を求める形だけという投稿だったので警告しました。見る人によってはタダのクレーマーが「もう使わない」と捨て台詞を投稿するのと変わらないでしょう。そういうのはやめてください。
フォーラムは「ディスカッションを行う」ということに利用して下さい。
Bugzillaへの投稿には開発側スタッフを納得させられる証拠を集めたり仕様に関しての調査が必要です。パッチを作成してそのパッチを適用させることを納得させる方が早い場合も有りますが．．．どちらにしても物凄い労力が必要です。
zz54547tz さんが書きました:
＜今回のトピックの主題についての補足説明＞
【省略】（失礼）
前にも書いたかもしれませんが、mozilla製品は通常で言う「プロダクト」では無いと思っています。なのでお書きになったことが当て嵌まるかは疑問です。
オープンソースなので基本的に「自分で修正する」．．．でしょうか。
仕様や動作に関してはnetscape時代からソースを引き継いでいると思うので、基本的にそれを踏襲していると思います。仕様に関してはzz54547tzさんの言葉を借りればバグだらけだと思います。が、慣れていたり回避方法が分かっているものに関しては目をつぶっているという感が有ります。
それは修正を依頼する労力と運用やその他で回避する労力と天秤に掛けた結果かも知れません。
しかし、仕様の改善に関しては良い方策があります。
それはzz54547tzさんが、開発側の一員として参加することです。好きなようにパッチを作って投稿し、他のメンバーを納得させれば良いんです。
納得しなかったら私家版を作れば良いだけです。私家版が良いものなら本家に取り込まれます。それが可能なのがオープンソースでしょう。
「顧客満足度」という点なら、Thunderbirdのこういう動作で満足しているのか？ というディスカッションから始めて「満足していない」ユーザの実数を証拠として改善を要求するというのも手だと思います。そういうことで先の投稿は順序が違うでしょうと言いたいですが、順序を間違うとクレーマー扱いになっちゃいます。
現に私は最初の投稿を見た瞬間に「クレーマー」と言いました。
まずは仕様に不満を持っているユーザの数を出してしまうことでしょうかね。
今後も使用しての不満や疑問点を投稿してみることでThunderbird の成長と発展に貢献出来るかもしれません。最近はまた「Eudoraのように」、「outlookのように」、「Sylpheedのように」、「ここはこういう風になっていて欲しい」という要望を見かけるようになっています。そういう声を開発側に「届ける・目に付かせる」ということでも貢献出来るかもしれません。
zz54547tz さんが書きました:
具体例を示します。私がメーラーの仕様を設計したとします。その仕様書には、こう記述されています。「新規メール作成時、最初は添付ファイル名の一部しか表示しない。同業他社のメーラーは最初から全部のファイル名を表示するし、そもそも本メーラーも受信メールについては最初から全部表示する。だが、新規メー ル作成時でも、ユーザーが手動で表示範囲を変更したり、ユーザーがマウスオーバーしたりすることで添付ファイル名の全部が表示される。だから問題ない｡｣
これを上司に見せて、許可を求めます。すると、上司は私をしかります。「ふざけるな! ユーザーの視点が欠落しているぞ!」
これが「仕様不具合」です。私の主張は仕様不具合なので、「何らかの人為的な対処が可能かどうか」は意味を持ちません。むしろ「人為的に対処しなければいけない」ということが不具合だという主張です。ちなみに、多くの企業では仕様不具合もコード不具合も同様に Bugzilla などのバグ管理システムで管理しています。
仰ることは理解出来ます。が、Thunderbirdの開発に関しては「上司」とは誰のこと？ という点です。誰が当て嵌まるんでしょう？ 疑問ですが．．．
ここが「自分達」なんでしょうね。作る方も自分達のためにやっているので．．．それが一番の問題点なのかも。
だから、説得が物凄く難しいです。特にマルチバイト圏の問題を修正依頼するときは。
ログイン
ユーザー登録
FAQ
検索
