![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
[[おおさわ]] * 修士論文 [#ad6e2f38] #contents * 章構成 [#t7289b3d] - はじめに -- 研究の背景 --- OSSが流行っている --- OSSに関わる人も多くなってきている --- 不具合修正にも多くの時間が費やされている --- Bug Triage(不具合の判定，修正担当者の決定)はman powerです -- 目的 --- 修正時間を短くすること（大目的） --- assign の方法を分析する（中目的） --- best effort になっていないか？ --- どんなパターンが効率的か？ -- 論文の構成 - OSSにおける不具合修正に関して -- 不具合修正の手順 --- 不具合修正がどのようなプロセスで行われるのか --- どういった人が絡んでくるのか -- Reporter、Assignor と Resolver の関係（type分け） --- 特にAssignee(Assign To)に着目した理由 --- Reporter、Assignor と Resolver の関係について --- type1:A(a)→A --- type2:A(a)→B --- type3:A(B)→B --- type4:A(B)→C - 分析方法 -- データの取得、整形 --- BTSからのデータ取得 - ケーススタディ -- 対象プロジェクト --- 対象とした不具合報告（Resolution:fixed -> なんらかの修正が行われていることが期待できる） -- 基本統計量 --- プロジェクト毎の開発者，Assignorの分布 --- タイプ毎の修正時間について（タイプ間の差） - 考察 - 関連研究 z:Zimmermann s:Sunghum Kim -- 不具合報告に関する研究 --- what makes a good bug report ? (z) --- quality of of bug reports in eclipse (z) --- extracting structural information from bug reports (z,s) --- towards the next generation of bug tracking systems (z) --- modeling bug report quality --- duplicate bug reports considered harmful ... really (z,s) --- information needs in bug reports: improving cooperation between developers and users (z) --- a linguistic analysis of how people describe software problems --- do stack traces help developers fix bug ? -- 修正時間予測に関する研究 --- how long will it take to fix this bug ? (z) --- predicting eclipse bug lifetimes -- OSS開発における人的に関する研究 --- latent social structure in open source project --- who should fix this bug ? --- automatic bug triage using text categorization --- improving bug triage with bug tossing graph (z,s) - 結論 - 謝辞 - 参考文献 * 対象プロジェクト [#o70e3afb] - Eclipse - Mozilla - Apache - OpenOffice - LinuxKernel * 参考文献 [#z818aacb] * スケジュール [#xc1cec79] - 章構成作成 -- 〜12月3日 - 第一段階分析完了 -- 〜12/10 - 原稿執筆 * 年末報告会 [#ddb1db17] * 年末報告会の質疑応答から [#ddb1db17] ** 研究内容について [#u91a6588] - プライオリティで分けた方が良い -- 優先度と高いのと低いのが一緒なのはおかしい（低いのだけぬかす） - 会社の仕事でやっている人もいるので，それを考慮すべき -- Eclipse:IBM,Linux:RedHat - 誰からAssignされたかが重要ではないのか - プロジェクトを増やすより，特定のプロジェクトで深く分析した方が面白いと思う -- Eclipseに着目してみるとか - 予備分析は分析の１つとして言っても構わないのではないか -- RQ1としてしまっても問題ないと思う -- 他のRQが予備分析をやった上で立ててるのなら今のままで良いが，そう思えない - A-B-A型を考慮すべき -- 考慮しないならその理由をちゃんとすべき -- 頼まれているという観点から考慮すべきてはないか ** 発表について [#sea27696] - 全体にまとまりがない -- どこを重点的に言いたいのかをはっきりさせる -- 『オリジナルな部分はここです』とはっきり言う - トリアージの用法はそれであってるのか * めも [#k6e2fb1f] #comment
