伊原
文章修正中\\
First reviewer†
○Evaluation\\
- 2ページ1カラム最後の行，「多くの不具合はアサインされていない」って言ってますが，「多く」って具体的に何件ですか？なぜアサインされないのですか？
- 現行のフォーマットに問題があります．
例えば，3ページ目1カラム4段落目，"bug transists to bug resolved"は"bug resolved"の方がいいですよ．後，文章中の引用符がおかしい．
3ページ目1カラム6段落目，"...analysis of bug tracking systems based [on] the division..."の"on"が抜けてるよ．
- 4.2章，なぜバグを分類しないの？結果には影響しないの？このことはリミテーションに入れた方がいいのでは？
- 全ての表はスモールキャピタルで書かれていますよ．Capsで書くようにしてください．
- 表2，各プロジェクトのBugzillaに全てを対象としているのか，一部のバグを対象としているのか明らかにしてません．もし一部のバグのみを対象としたものなら，おそらく図の違いはバグのフィルタリングが影響しているのではないですか？また，私は何カ月にも渡るバグの経過を生データで見てみたい．
- 表2，2002年に報告された古いApacheのバグ，2001年に報告されたFirefoxのバグを見たことがあります．しかし5.1節で著者たちはApacheは2003年にばBugzillaを使い始め，2002年にFirefoxを使い始めたと言ってますが，どのようにして古いバグのデータを手に入れたのですか？
- 4ページ目2カラム，Mozillaのこと説明する欄で，「Apacheが…」と書き始めてますよ．
- 4ページ目2カラム，"web browser product with the rapidly increasing share"は私なら"web browser product with a rapidly increasing market share"のように書きます．
- 表3，4に示すデータについて，全てフェーズの最小値は0日ですが，バグの修正や確認が0日のバグはどのようなバグなのですか？
- 5.3.1節最後の段落の最後，"web browser product with the rapidly increasing share"は私なら "web browser product with a rapidly increasing market share"のように書きます．
- 5.3.1節最後の段落,著者は「アサイン→解決」のバグは「承認→解決」のバグよりも短い．と言ってますが，それは明らかでないのでは？アサインしているバグは承認された後発生した，もしくは同時に行われたのではないですか？アサイン以前に承認されていない場合もありますが．あなたがこの意見を原稿に含めるなら，計算の妥当性のチェックをしてください．しかし，その発見は驚くような内容ではありません．
- 6.3節の"Threats to Balidity"は"Validity"です．
- 最後に，あなたの原稿でとても興味深いのは確認作業にボトルネックがあることです．
まとめのセクションでそれを含めてください．
Second reviewer†
○Summery\\
- 表はのy軸は対数スケールを使うべきです．そうしないと違いが目立たない
- 少なくとも状態遷移をループ回数をカウントすべきです
○Evaluation\\
- (+)不具合修正プロセスを定量化したことは評価できる
- (-)定量データを説明できていない．定量的な結果に驚けない．
- 私はこの原稿がワークショップの目的に合っているかどうかが疑問である．
この原稿のテーマは不具合修正プロセスデータを定量化することである．
ワークショップはLehman発見した法則に沿って進化の様子に焦点を当てた会議です．
どのようなシステムが時間の経過で進化するか．不具合修正はICSMやCSMRやWCREのような会議で
良く扱われています．
- 言語の問題が多くあります．PDFにマークしましたので，私のPDFファイルに注釈をつけたので参照してください．
Second reviewer†
○Evaluation\\
この原稿は興味深いエンピリカルな結果を報告しています．
しかし，ボトルネックの議論に賛成しません．
原稿の結果がプロセスの向上のために運営者のどのような助けになるか明らかにしていません．
初めに
開発者がアイドル時間を持たない限り，開発者の作業量は不変である．
ゆっくりしているバグが下がらない限り不具合修正を早くすることは不可能です．
2つ目に
結果に「アサイン→解決」，「解決→確認」に長い時間がかかっているのを示している．
これは期待していました．なぜなら修正や確認は時間がかかる．
これが異なる結果なら怖い．
そうは言っても，エンピリカルな発見はとても興味があり，ワークショップに関係している．
実際にあなたのアプローチはプロジェクトをモニターしたいとき，運営者にとても関連がある．
例えば，毎月提案されたステートチャートを計算することができ，次のグラフと比較したり，外れ値（大規模な変化）を検索したりできる．この進化を見ることはIWPSEワークショップに関係している．
指摘を試みてください．
表2のFirefoxの数は非常に低い．Mozillaのバグデータベースは全体で50万あり，わずか2376がFirefoxに影響を及ぼすとは思えません．同様に，表3で未対応フェーズで86個のバグはおかしい．これは90%のバグは投稿した後，直接解決したということを意味する．議論が全くされていません．
図5と8，empiricalな見方は興味があります．例えば，開発者はどこに時間を費やすのか，どの遷移に時間がかかるかなど．
この原稿は「ボトルネックを理解する」を絶えず繰り返す傾向がある．
これについて述べるのは1回か2回で十分です．特にそのような忠告は議論しなくてよい（上記参照）
7ページ1段落，3つのパターンを理解できない．「報告→解決」の遷移がa,b,cとどのように関係しているか確認できない
図3，4について詳細に議論してください
"Threats to Balidity" => "Threats to Validity"
日本語フォントをインストールしなければなりません
○指摘
- バグ修正の異なるフェーズ間の遷移を分析するアイデアは面白い
- 図5から図8の結果は面白い
- 時間を費やしている遷移が本当にボトルネックとなっているかは明らかでない
- 結果が明らかでない．運営者はそのような知見をどのように反応すればよいのか．
- プロジェクトをモニタリングするためにグラフを使用することはとても役に立つだろう
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
