-----------------------------
review comment 1
-----------------------------
■ 総合点
4
■ 確信度
3
■ 査読コメント
インタビュー、実装、評価、ときれいな構成の論文である。内部で利用しているSelective UndoのアルゴリズムはYoonらのICSE '15論文と同一のようなので、新規性は提案されているユーザインタフェースにある。
つまり、著者らによれば、Yoonらの手法では(ユーザが厳密にUndo内容をコントロールするために)「複雑なインタフェースが利用されている」が、これをシンプルなUndo提案インタフェースにしたところが研究上の貢献である。
Yoonらの手法・インタフェースと比べたとき、インタフェースをシンプルにしたためにコンフリクトが解消できなかったり曖昧になったりすることがないのか、「6 制限」についてもう少し議論がほしい。
その他:
結果1の図がおかしい(undoされていない。)
■ レビューサマリー
Selective Undoのアルゴリズムには新規性がないことから、インタフェースの設計が肝となる論文ですが、説明が粗削りで言葉足らずなところがあります。
着眼点は面白いし、WISSで議論を呼ぶようなよい研究だろうという点では査読者の意見は全員一致しています。
インタフェースに関する説明を分かりやすくして、手法のリミテーションを議論して明らかにしてください。
カメラレディ原稿では、査読者に指摘されたコメント・疑問になるべく全て応えられるよう心がけてください。とくにreview 176の挙げた疑問およびreview 175の指摘した手法の限界についての議論を行ってください。
-----------------------------
review comment 2
-----------------------------
■ 総合点
2
■ 確信度
2
■ 査読コメント
評点の根拠：
本研究では、プログラミングの中でも小規模な変更の繰り返しに適したバージョン管理操作を支援するための新しいインタフェースを提案している。提案インタフェースでは、最近の編集に対するバージョン管理操作がテキストエディタ上にパネルとして表示され、ユーザはそれをクリックすることで部分的なundoができる。
小規模バージョン管理ツールに関するインタビュー調査から得られた知見、およびそれ基づく提案インタフェースは、WISSコミュニティにとっても興味深いものであると考えます。しかし、本研究のもっとも重要なインタフェースについて説明不足な点が見受けられます。以上の理由に基づいて評点を付けました。
論文改善のためのコメント、疑問：
＜パネルの選択方法について＞
変更点の種類に応じて，6 種類のパネルのいずれかが選択されるとのことですが、1行に複数個所（たとえば関数の三つある引数のうち最初と最後の二つを変更など）の変更があった場合は、行変更として扱われるのか、テキスト変更として扱われるのか、どちらになるのでしょうか。また、後者の場合は二つのテキスト変更をどのようにパネル表示するのでしょうか。
＜パネルの表示方法について＞
「プログラマは最近のテキスト編集を操作対象にする可能性が高い (p.5)」ため、直近N回の編集がすべて同じ個所に対する異なる操作であることは、容易に起こり得ると思います。この場合、どのようにパネル表示するのでしょうか。「1) 4行目を追加」「2) 4行目を置換」「3) 4行目を削除」「4) 4行目を追加」といった操作が行われた場合、4行目にはどのようなパネルが表示されるのでしょうか。
＜図4-E の説明＞
「E) 行を置換する」の説明がよくわかりません。なぜ行置換のときだけ「置換後の行」が二つあるのでしょうか。また、行の置換なのになぜ行頭のテキストは置換対象とならないのでしょうか。
＜出力するundo操作について＞
「最新N 個のテキスト編集をそれぞれ選択的undo する操作が，ユーザが次に行う可能性の高い操作であると推測 (p.5)」とありますが、これは現在フォーカスされている個所（例えばカーソルのある行や表示中の全行など）に影響を与える選択的undo のうち最新N個が表示されるのでしょうか？それとも直近N個が表示されるのでしょうか。
もし前者であるならば、重要な個所ですので、そのように動作することおよびその動作を実現する仕組みを明記した方が良いと思います。一方で、もし後者であるならば、問題が生じると思われます。
ある部分を修正した後に、それに影響を受ける他の部分を修正する、といったことは多々おきますが、後者の場合（直近N個のみ表示）は、Nステップより前に編集した箇所に関しては選択的undoが使えないということになります。しかし、一般的に開発者はコメントアウトをそのような用途（Nステップ後に再編集する可能性があるため、小規模バージョン管理としてコードをコメントアウトする）で使うことがあると思われます。「プログラマは最近のテキスト編集を操作対象にする可能性が高い (p.5)」は事実と思われますが、それはある程度前のテキスト編集をまったく操作対象にしないことを意味しません。
-----------------------------
review comment 3
-----------------------------
■ 総合点
4
■ 確信度
3
■ 査読コメント
従来あまり注目されていなかった「プログラミングの際に小規模なバージョン管理をコメントアウトを使って行っている」という点をとりあげたのが素晴らしいと思います。
査読者もこの「コメントアウトにより小規模バージョン管理」を多用する人間であり、ソースコードレビューで「コメントアウトが残りすぎている」と指摘を受けることが多いです。しかし実際にその利点も実感しているのでコメントアウトを捨てるわけにもいかず、と悩んでいました。このように問題に直面しながら、そこに解くべき問題が存在していることには気がついていませんでした。
実装されたインタフェースも荒削りながら、実際のプログラミング作業をよく考えた上で提案されており、好感が持てます。論文中にも書かれているようにアルゴリズムの単純さが実用性の観点から気になるところですが、それは今後の改善に期待でしょう。
以下は本論文をよりよいものにするためのコメントです。
・ビデオはもう少し本論文の狙い、良さがわかるものにできると思います。論文を読む前にビデオをみたのですがその良さが伝わりませんでした。
・要件明確化のためにインタビューをしていますが、実際のプログラム作業の「観察」を行った方が（あるいは併用したほうが）より有効な情報が得られたと思います。実際に問題を抱えているユーザは、その問題を正しく認識しているとは限りません。