- 追加された行はこの色です。
- 削除された行はこの色です。
- 研究 は削除されています。
- 研究 の差分を削除
[[おおさわ]]
* 目次 [#s4cf349e]
#contents
* 予定 [#gcd4f37c]
- 11/25 ゼミナール発表Ⅱ一回目(＠L1 3限)
* 研究 [#nbe9b8dd]
- [[不具合修正に関与する開発者コミュニケーションの分析>おおさわ/不具合修正に関与する開発者コミュニケーションの分析]]
* めも的ななにか [#vcefbf83]
*** おおさわの趣味趣向および悪趣味 [#p094dd57]
- "バグズライフ！！"修正予測モデルありきだけど，報告者に対して"？%なう"的なの表示したら面白いかも -- &new{2010-05-19 (水) 11:36:36};
#comment
* トゥードゥー [#h5cba731]
* 読物 [#vecdaa13]
- なんて名前？？
-- どこのだっけかなぁ？？
-- 概要
-- 感想文(適当文字数)
-- 論文&attachref();
----
- Predicting Build Failures using Social Network Analysis on Developer Communication
-- ICSE 2009
-- ワークアイテム(ソースコードと思われる)に付随するコメントから開発者のコミュニケーションネットワークを作成する．コミュニケーションネットワークをSNA的尺度を使用してbuildが成功するか失敗するかを予測できるか．また、複数のコミュニケーションネットワークの尺度を用いてbuildの失敗を予測できるか．
-- ふむふむ
-- 論文&attachref(Predicting_Build_Failures_Using_Social_Network_Analysis_on_Developer_Communication.pdf);
#comment
----
- How Developer Communication Frequency RElates to Bug Introducing Changes
-- IWPSE-Evol2009
-- 概要:開発者が頻繁にコミュニケーションをとるとバグの修正が進行するのかどうか．結果としては，開発者のコミュニケーションの頻度とバグの修正の進行には相関がある．
-- ケーススタディ:eclipse-JDT，メーリングリスト
-- 感想文(適当文字数)
-- 論文&attachref(How_Developer_Communication_Frequency_RElates_to_Bug_Introducing_Changes.pdf);
#comment
----
- What Makes a Good Bug Report ?
-- FSE2008
-- 概要:開発者は報告者からの報告を基に不具合の修正を行う．しかし，開発者が必要としている情報と報告者が報告する情報との間にはミスマッチが起きている．修正を円滑に行うために，開発者が必要としている情報を明確化し，報告者が何を報告すべきなのかを把握できるような新型BTSを提案する．
-- ケーススタディ:MOZILLA，ECLIPSE，APACHE
-- 開発者が修正の際に何を重要としているのかがわかった．OSSで参加者のモチベーション云々の話に対応できるような，参加者へのメリット的なのがあったので，これをまるっとパクる．ただ，論文の内容がオール開発者目線だったので，「ユーザ目線どうなってるの？」っとは思った…．ってなとこ．
-- 論文&attachref(bettenburg-fse-2008.pdf);
#comment
----
- Information Needs in Bug Reports : Improving Cooperation Between Developers and Users
-- CSCW2010
-- 概要:バグ報告者の活動はバグ報告にとどまらず，修正プロセスにも進出してきている．現行のBTSを改善するための4つの手法を提案する．
-- ケーススタディ:MOZILLA，ECLIPSE
-- 感想文(適当文字数)
-- 論文&attachref(breu-cscw-2010.pdf);
#comment
----
- Towards the Next Generation of Bug Tracking System
-- VL/HCC2008
-- 概要:「What Makes a Good Bug Report?」(以下make good)の続編．make goodで得られた開発者，報告者からのコメントを基に，現行BTSの改善方法を提案する．#1開発者が必要な情報が何なのかを報告者に知らせる(情報のミスマッチから)#2不具合報告を翻訳してくれる人を探す(言語的な問題から)#3報告者のスキルに合わせて入力インタフェースを買える(人によって収集できる情報が違うのだから)#4報告者を奨励する(そりゃそうだろ…)#5報告者のプロファイルを作成する(開発者だって報告者の情報が欲しい)#6強敵かつ簡単な不具合検索システム(2重登録を防ぐためにね)#7既にある不具合報告を提示して書き方をそれと無しに教える(どこまで書けば良いかわからないみたいだから)
-- make good では開発者よりの提案が多かった気がするが，今回は報告者視点の内容があったので，フムフム的な何かがあった．確かに，報告者に全てを求めるのではなく，報告者のスキルに合ったシステムは重要だと思う．いきなり敷居の高い情報を求めても，報告者が新規に報告をするようになって，それを継続的に続けるコア報告者になるかどうかはわからないから．んでもって，適当な不具合を報告してMOZILLAからTシャツゲットするぞ！！
-- 論文&attachref(just-vlhcc-2008_0.pdf);
- 参考文献[8] Modeling bug report quality (ASE2007)ね！！ -- [[おおさわ]] &new{2010-05-19 (水) 11:13:06};
#comment
----
- Modeling Bug Report Quality
-- ASE2007
-- 概要
-- 感想文(適当文字数)
-- 論文&attachref(p34-hooimeijer.pdf);
#comment
----
- Characterizing and Predicting Which Bugs Get Fixed: An Empirical Study of Microsoft Windows
-- ICSE2010
--
-- 感想文(適当文字数)
-- 論文&attachref(guo-icse-2010.pdf);
#comment
----
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
