アカウント名:
パスワード:
これね。そうなんだよね。再現手順を確認・最小化したり、コンパクトにまとめるとかかなりの手数だよ。そうやって報告として役に立つようにと努力したことが無に帰する。結果として無になるならまだしも、最初から無駄だったと思った時の脱力感。Thank youの一言でもあるとだいぶ違うんだけどね。
MSのテクニカルベータだとと、そういう扱い受けたレポートでも数に入って大抵最後にその製品もらえたりするから、参加してみたら?
> お礼は何もなかったけど。
その電話でお礼の言葉なかったんですか?
全く同意できません。傲慢さを感じますし、そんな考え方で普段の開発が効率よくできるのか・周囲は何も言わないのかと不思議に思います。
私は普段開発の側にいます。他の人が担当している部分で不具合を見つけたら報告もしますし、いわゆるオープンソースのものでも報告することがあります。開発者側から見て、バグレポートは確実に再現するなら再現方法が短い方が良いですし、あまり長いのも必要な情報をピックアップするのに手間がかかります。パッチの提供も実装方法はともかくコードの対応部分まで調べられているのですから、問題解決への時間は大きく変わります。試してみて動作が変われば確かに影響している部分だということは分かるわけですから。
開発者側から見れば、重要なのはバグのレポートであって、再現手順の確認とか、最小化は、開発側でも行える作業です。開発側から見れば所詮利用者でしか無い人が「役に立つ」とか「努力」と言っても、何を言ってんだか、と思われるだけです。
そうなの?オープンソースの開発を行っている側からすると、バグがあるという指摘だけでなく詳細な再現手順や解決するパッチがあると助かりますよ。
私もありがたいに同意します。ありがたいので、逆にそういう風に否定しないで頂きたいと思います。
報告する側としてはパッチはどう動くべきと考えているかを誤解される可能性が低く最良報告される側としては共同著作者が増えると場合によっては面倒
際限手順のないバグ報告なんかもらったって、役に立たないのだが。
バグの修正をしたことがない人ですか?
>際限手順のないバグ報告なんかもらったって、>役に立たないのだが。
むしろ、際限なく発生させられる手順のほうがありがたいのでは?
>所詮利用者でしか無い人と言うのであれば、なぜ生産物を公開しているのですか?
利用者を神様と思えとまでは言わないが、利用者の存在を軽視するのであれば、公開する行為の意味がよくわからない。
>再現手順の確認とか、最小化は、開発側でも行える作業です。開発側でも行える事であっても労力は変わりませんし、負担が減る(かも)という事実は変わらないでしょう。「役に立つ」とか「努力」とかいう事の押し売りが来るのも面倒だとは思いますが。その旨断りを入れるなりして対策しておくべきでしたね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
薄謝でもくれるだけマシ (スコア:2)
報告すると、それは「known Problem」だとか、あたかも、そんなのもう気が付いていたよ
みたいな対応ばかりで、やる気をなくしたものです。
多少でも評価してもらえるなら、やる気が湧くことでしょう。
Re:薄謝でもくれるだけマシ (スコア:2, 興味深い)
これね。そうなんだよね。
再現手順を確認・最小化したり、コンパクトにまとめるとかかなりの手数だよ。
そうやって報告として役に立つようにと努力したことが無に帰する。
結果として無になるならまだしも、最初から無駄だったと思った時の脱力感。
Thank youの一言でもあるとだいぶ違うんだけどね。
MSのテクニカルベータだとと、そういう扱い受けたレポートでも数に入って
大抵最後にその製品もらえたりするから、参加してみたら?
Re: (スコア:0)
Windows日本語版リリース間近のときに、
ビルドが更新されたら、あるルーチンでバグが出て、
レポートしたらMSから直接電話が来たことがあった。
話し合いの末、ビルドを戻すことになったけど、
そのときは参加しているという感じがしたね。
お礼は何もなかったけど。
Re:薄謝でもくれるだけマシ (スコア:2)
> お礼は何もなかったけど。
その電話でお礼の言葉なかったんですか?
Re:薄謝でもくれるだけマシ (スコア:1)
全く同意できません。傲慢さを感じますし、そんな考え方で普段の開発が効率よくできるのか・周囲は何も言わないのかと不思議に思います。
私は普段開発の側にいます。他の人が担当している部分で不具合を見つけたら報告もしますし、いわゆるオープンソースのものでも報告することがあります。
開発者側から見て、バグレポートは確実に再現するなら再現方法が短い方が良いですし、あまり長いのも必要な情報をピックアップするのに手間がかかります。
パッチの提供も実装方法はともかくコードの対応部分まで調べられているのですから、問題解決への時間は大きく変わります。
試してみて動作が変われば確かに影響している部分だということは分かるわけですから。
Re: (スコア:0)
開発者側から見れば、重要なのはバグのレポートであって、
再現手順の確認とか、最小化は、開発側でも行える作業です。
開発側から見れば所詮利用者でしか無い人が
「役に立つ」とか「努力」と言っても、
何を言ってんだか、と思われるだけです。
そうなの?
オープンソースの開発を行っている側からすると、バグがあるという指摘だけでなく
詳細な再現手順や解決するパッチがあると助かりますよ。
Re:薄謝でもくれるだけマシ (スコア:1)
私もありがたいに同意します。
ありがたいので、逆にそういう風に否定しないで頂きたいと思います。
Re: (スコア:0)
報告する側としてはパッチはどう動くべきと考えているかを誤解される可能性が低く最良
報告される側としては共同著作者が増えると場合によっては面倒
Re: (スコア:0)
際限手順のないバグ報告なんかもらったって、
役に立たないのだが。
バグの修正をしたことがない人ですか?
Re:薄謝でもくれるだけマシ (スコア:1)
>際限手順のないバグ報告なんかもらったって、
>役に立たないのだが。
むしろ、際限なく発生させられる手順のほうがありがたいのでは?
Re: (スコア:0)
>所詮利用者でしか無い人
と言うのであれば、なぜ生産物を公開しているのですか?
利用者を神様と思えとまでは言わないが、利用者の存在を軽視するのであれば、公開する行為の意味がよくわからない。
>再現手順の確認とか、最小化は、開発側でも行える作業です。
開発側でも行える事であっても労力は変わりませんし、負担が減る(かも)という事実は変わらないでしょう。
「役に立つ」とか「努力」とかいう事の押し売りが来るのも面倒だとは思いますが。その旨断りを入れるなりして対策しておくべきでしたね。