中本です。 > > > P1/P2も「未確認」とマークされているものはいらないんじゃないですか? > > > > で、unconfirmed(未確認)のものも除いて、一体いくつのバグがあるのでしょ > > う？全部リリースアナウンスに載っけられますか？ > > 良く考えてみましょう。unconfirmedだと、多すぎます。 > statusが「開始済み」でも多すぎです。よい基準を作ればよいだけでしょう。
IssueTrackerは活用しているつもりですが、その点はまだ慣れていない部分もあ りました。中田さんに提示していただいたクエリは大いに参考になりましたの で、今後バグの通知をするときの参考にしたいと思います。ありがとうございま した。うまくクエリを活用すれば、わりと使えますね。 ただ、クエリを使うだけといった画一的な方法だけではうまくいかないことがあ ります。単にクエリによってアナウンスできるだけの数に減らせばいいってもん じゃありません。 その端的な例がi80816ですかね。 私もFedora 7で試そうとしてなかなか起動せずに困っていたのですが、こういう ものはあらかじめ通知しておかないと本当にユーザーは何が起こっているのか訳 が分かりません。クラッシュして、クラッシュレポーターが開くのならまだし も、起動しようとしてもウンともスンとも言わないんですよ。これは、あらかじ め通知しておくなり、あるいは検索してすぐに引っかかるようにしないと、普通 のユーザーは途方に暮れるだけでしょう。コマンドラインから起動するのであれ ば、エラーメッセージが出るので検索しやすいのですが、メニューから起動して いるとそれこそ何にも起こりません。 Fedora 7なんていうのはデスクトップ向けのLinuxとしてはそれなりのユーザー がいるもんだと思います。Linuxの中でFedora 7がマイナーなわけないでしょ う。また、SELinuxはFedora 7ではデフォルトでEnforcingモードです。そう考え ると、2.3.1で直すべき問題だと思いますが、問題の解決方法がはっきりと決ま らない現状ではターゲットを2.4にせざるを得ないように見受けられます。 いずれにしても、これはFedora 7のユーザーのほとんどがこの問題に遭遇すると 予想される以上、クエリに引っかかるか引っかからないかなど関係なく、そのバ グの存在と回避方法を広く周知しなければならないでしょう。 > なお、cjk圏として思えばP1なIssueもP2とアサインされることを鑑み、cjk keywordを > 設置しようとしております。 > http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgNo=9427 最近よく言いいますが、CJKというくくりは多くの場合無意味です。 もし、QAプロジェクトとして何かしようとしているのであれば、 - Japanese - Chinese - Korean というようにキーワードを設定していただけるのがよいかと思います。日本語だ けに限ったバグというのは、特に翻訳関係でよくありますが、CJKだけのバグと いうのはほとんどありません。 # というか、そういうバグって今ありますか？ > > まぁ、私が選定したバグよりも、そんなにP1/P2とマークされたissueを周知す > > べきだと思うのであれば、つべこべ言っていないで、まず、各バグの概要(と > > できれば回避方法)を > > http://wiki.services.openoffice.org/wiki/Ja.openoffice.org/Documentation/2.3 > > に追加していったらどうでしょうか？2.3.1以降よろしくお願いしますね。 > > 私はIssueTrackerへのリンクで必要十分の情報だと思います。 > 翻訳もよいと思います。 IssueTrackerへのリンクは必要な情報です。追加してください。 ただ、それだけでは十分ではありません。記者でさえ英語を読めないのは別に珍 しいことではありません。ユーザーにどのようなバグがあるのかはきちんと日本 語で説明したいところです。 また、バグ報告をするときには再現手順を明確に開発者に伝えることが一つの大 きな目的ですが、ユーザーに伝えるべき情報はまた異なります。ユーザーがその バグに遭遇するのであれば、そのバグは通知するまでもなくそれはバグです。そ こで重要になってくるのが、回避方法を伝えることです。 # バグだと分かりづらいものもあるので、単にバグがあることを知らせるだけで # も意味がある場面は多々ありますが。 しかし、そういった情報は多くの場合IssueTrackerには載りません。ユーザーが 単にバグがあることを知っていても、望んだ機能を利用できるようにしなけれ ば、結局OOo は使い物にならんということになるだけなのです。だから回避方法 をまとめたページを作っています。 例えば、i81560にある軸ダイアログの一部の文字が見えないバグについては、別 にユーザーに通知するまでもなく、誰がどう見てもバグです。そんなことはいち いちユーザーにIssue番号を伝えるまでもなくバグであることは一目瞭然です。 重要なのはその先の回避方法であって、この場合にはちゃんと上からどういう設 定項目になっているのかということをユーザーに伝えることではじめてバグを通 知することに意味を成します。 # まぁ、この場合は普通に上から順番にX、Y、Zであることは容易に想像はできる # のであまりいい例ではありませんでしたかね。 -- 中本 崇志 (Takashi Nakamoto) E-mail: [メールアドレス保護] Homepage: http://bd.tank.jp/ Blog: http://bd.tank.jp/diary/ --------------------------------------------------------------------- To unsubscribe, e-mail: [メールアドレス保護] For additional commands, e-mail: [メールアドレス保護]
