アカウント名:
パスワード:
受け取る相手に寛容さが皆無な場合は悲劇にしかならない。
「このファイル(相手もアクセス可能)を読み込んで、こーやってあーやって操作すると、こんなメッセージを吐きました。メッセージから推測すると、これが原因ではないかと思うのですが」
という私の報告に「あんたのファイルが悪いんだろ(文章は当然違うが、文意は同じ)」と返事が返ってきたときには、さすがにキレた。
ファイルがどうのという前に、せめて「再現出来
それは本当にそのファイルが悪かったんじゃなくて?
例えて言うなら「Photoshopでデータを読み込んで、ツールパレットのとある機能を選択した瞬間に落ちる」という感じ。
という状態。どう考えても、その機能自体にバグがあるとしか考えられなかった。
むしろ余計な推測を挟まれると気分を害する人も居ますし、推測が的外れだった場合にはプログラマに小ばかにされるだけですし。
小ばかにされても結構。それで結果的にこっちの仕事が進むなら。「バグではなく仕様です」と言い切っても構わん。他の手を
どう考えても、その機能自体にバグがあるとしか考えられなかった。
だとしたら、推測をバグレポートに含めることに害はないかもしれませんが、そうする意味もありませんよね。 バグレポートに原因の推測を含めないも意味がない理由は、
からです。バグレポートに原因の推
では元ネタのまとめを参考に、自分のバグレポを振り返ってみました。
バグ報告の最初のねらいはプログラマに自分の目で故障を分からせることである。彼らのところに行って失敗するところを見せることができないなら、彼ら自身で失敗させることができるような詳細な指示書を与えよう。
ソフト、ハードのセットアップは彼ら(私がバグレポをした相手)が行ったものです。したがって環境はすべて把握しているはず。基本的にユーザーが環境を変更することは許されていないし、実際していませんでした。そういう環境下で、特定のファイルを読み込み、特定の操作を行うことで確実にフリーズする、という内容でした。
確かに蛇足だったかもしれない推測は、裏で動いてたシェルのコンソールに出力されていたメッセージを全文引用し、その上で自分の考えを書き添えたものです。
最初のねらいがうまくいかなくて、プログラマ自身では失敗が確認できなかったら、バグ報告の次なるねらいは何がおかしくなるのかを記述することだ。全てを詳細に記述しよう。何を見たのか、どうなるべきだと思うのか述べよう。エラーメッセージを書き留めよう。特に数字が含まれているものは。
彼らが確認できたのかどうかすら判りませんでした。これではその先に進めません(藁
ホントに最初のコメントの内容(「お前のファイルが悪い」)としか書いてなかったんですよ。ま、電子会議室上での文字データだけのやり取りの話なので、バグレポの内容がどうの以前にコミュニケーション能力に問題あり(私もその一言で頭に血が上ったんで、多分双方とも)、ということではないかと。
行間が読めなかったのなら説明するが、彼らは同じ社内にいる管理者、すなわちrootで、こっちは一般ユーザー、しかも設定変更すら許されていないただのアプリユーザー。
セットアップすべてを行った彼らに、いちいち動作環境を報告する必要があるか?マシン名だけで十分だろ。ファイルを提供したのかって?まさか今時各個人がリムーバブルメディアでデータを持っている、とか思ってる?当然サーバー上のファイル名を教えたが、それじゃ不足だとでも?
俺がムカついたのは、バグレポは俺の本来の仕事じゃないにも関わらず
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
効果的に報告をしたつもりでも (スコア:1, 興味深い)
受け取る相手に寛容さが皆無な場合は悲劇にしかならない。
という私の報告に「あんたのファイルが悪いんだろ(文章は当然違うが、文意は同じ)」と返事が返ってきたときには、さすがにキレた。
ファイルがどうのという前に、せめて「再現出来
効果的な報告と思っていても…… (スコア:1, 興味深い)
この説明だと、本当に仕様外のファイルを読ませて仕様外の操作をした結果、仕様外だっつーのっていうエラーが表示されたのを、「エラーだ!」と騒ぎ立ててバグ報告をして、向こうに「だから仕様外だって言ってんだろ!」と呆れられた、というシチュエーションも想像できてしまいます。
バイナリファイルをc
Re:効果的な報告と思っていても…… (スコア:1, 興味深い)
例えて言うなら「Photoshopでデータを読み込んで、ツールパレットのとある機能を選択した瞬間に落ちる」という感じ。
という状態。どう考えても、その機能自体にバグがあるとしか考えられなかった。
小ばかにされても結構。それで結果的にこっちの仕事が進むなら。「バグではなく仕様です」と言い切っても構わん。他の手を
Re:効果的な報告と思っていても…… (スコア:1)
だとしたら、推測をバグレポートに含めることに害はないかもしれませんが、そうする意味もありませんよね。
バグレポートに原因の推測を含めないも意味がない理由は、
からです。バグレポートに原因の推
鵜呑みにしてみる?
Re:効果的な報告と思っていても…… (スコア:1, 興味深い)
では元ネタのまとめを参考に、自分のバグレポを振り返ってみました。
ソフト、ハードのセットアップは彼ら(私がバグレポをした相手)が行ったものです。したがって環境はすべて把握しているはず。基本的にユーザーが環境を変更することは許されていないし、実際していませんでした。そういう環境下で、特定のファイルを読み込み、特定の操作を行うことで確実にフリーズする、という内容でした。
確かに蛇足だったかもしれない推測は、裏で動いてたシェルのコンソールに出力されていたメッセージを全文引用し、その上で自分の考えを書き添えたものです。
彼らが確認できたのかどうかすら判りませんでした。これではその先に進めません(藁
ホントに最初のコメントの内容(「お前のファイルが悪い」)としか書いてなかったんですよ。ま、電子会議室上での文字データだけのやり取りの話なので、バグレポの内容がどうの以前にコミュニケーション能力に問題あり(私もその一言で頭に血が上ったんで、多分双方とも)、ということではないかと。
Re:効果的な報告と思っていても…… (スコア:1)
つまり動作環境に関しては報告しなかった、ということですよね?
こういう~だから~はず(今回だとセットアップしたのは彼らだから動作環境は把握しているはず)みたいなのは報告を聞く側としては嬉しくないでしょうねえ。
異常動作したファイルというのは開発側に提供されたのでしょうか?
>(私もその一言で頭に血が上ったんで、多分双方とも)
なんにしろ短気すぎでは。
Re:効果的な報告と思っていても…… (スコア:0)
行間が読めなかったのなら説明するが、彼らは同じ社内にいる管理者、すなわちrootで、こっちは一般ユーザー、しかも設定変更すら許されていないただのアプリユーザー。
セットアップすべてを行った彼らに、いちいち動作環境を報告する必要があるか?マシン名だけで十分だろ。ファイルを提供したのかって?まさか今時各個人がリムーバブルメディアでデータを持っている、とか思ってる?当然サーバー上のファイル名を教えたが、それじゃ不足だとでも?
俺がムカついたのは、バグレポは俺の本来の仕事じゃないにも関わらず
Re:効果的な報告と思っていても…… (スコア:0)
違うと断言してもよいよ(w