作島
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
]
開始行:
*Memo [#a11824de]
-[[研究テンプレート]]~
--https://docs.google.com/spreadsheets/d/1yvgRGxTOrHRpvd1...
-論文検索；ACM
--https://dl.acm.org/
*Link [#a11824de]
#ls
[[作島/研究テーマ]]
* 時間割 [#cf536001]
|>|>|>|>|>|CENTER:|c
| |~Mon|~Tue|~Wed|~Thu|~Fri|h
|~1||||||
|~2||||||
|~3|||||大ゼミ|
|~4||環境社会システム論||||
|~5||||||
* Meeting[#hb323ab0]
** 4/ 16 [#k04ce243]
***DONE [#pbf99c07]
***TODO [#m658a609]
** 4/9 [#re310c02]
*** DONE [#f9bb0c12]
- Continue Deployment の紹介論文を読んだ
*** TODO [#x54820af]
論文を読むよりも，まず用語をおさえる．
- 体系的に学習するために本を購入し，スライドにまとめる
**2/26 テーマ練り会 [#q6567033]
-management規格が存在するのでどのリスクをマネージメントし...
-- PMBOK，SWBOK，KPIなど
-プロジェクトや開発者にかかっている負荷を可視化できる指標...
-デスマーチ（death march）~
システム開発現場の過酷な労働環境を表す言葉．~
人員不足，短すぎる開発期間，予算不足，ユーザからの過剰な...
**2/21 [#m89b768c]
卒論の修正内容の確認
-研究の根拠はなになのか．
--報告回数，スタックトレース，共同回数で開発者群を分割し...
--多くの要因が考えられる中，その3つを選択しなぜそれが妥当...
**1/ 23 [#kb544e03]
考察を思案中
- JDTとPlatformを比較する必要はない
- あるコンポーネントでは修正時間が関わっているかも
-- 一つのコンポーネントが足を引っ張っていてコンポーネント...
-- まずJDTの各コンポーネントにおいて修正時間を算出してみ...
**1/ 15 [#o1967e3f]
- パターン4の箱ひげ図の上と下が含まれる結果になる要因を明...
- 縦軸を対数変換するとクラスタリングがいい感じになると思う
- 関わった回数が多い集団と少ない集団の代表者を見つけて，...
- 重要度や優先順位などは手動で行うため，分析に有用かどう...
- コンポーネントごとに分析するといいかも(UIとかは簡単な修...
**12/ 26 [#q808be47]
-調査結果を出す
-x軸割り当て時間，y軸修正時間のグラフ出す
-モチベーションがなにかを明確にする
***DONE [#uefc6f28]
-2章レビュー提出 (12/23)
-研究のモチベーション
--不具合パターンで他の開発者に修正を依頼する際に障壁とな...
先行研究のデータ(2007年1月→2009年12月)で出た結果を自分が...
-前処理
-- 再割当なし
--reopenなし
--FIXEDのみ限定
--修正時間を assigned_date → fixed_date から assigned_dat...
--assigned_dateとmodified_dateが全く同じ時間であるときは...
fixed_dateは，よくわからない．
modified_dateは，最終ラベルが貼られたときの時間を指す．
上記でやる場合，再割当も再修正もないため，割り当てられて...
RQ1 : 先行研究の不具合管理パターンのデータ割合や修正時間...
RQ2: 分担解決型において修正時間に影響を与える要因を調査す...
RQ1より分担解決型のみではなく，修正委託型にも同様の結果が...
RQ2:いままで管理者と修正者が関わった回数が修正時間に影響...
分担解決型，修正委託型，その両者
**12/ 17 [#m063caeb]
***TODO [#c19faca1]
-卒論2,3章書く．
-共同開発実績の回数のデータを出す．
-スタックトレースとかを抽出するスクリプトを作る．
***DONE [#ac714586]
- 卒論2,3章を書き，レビューをしてもらった(次回締め切り 12...
- RQ1-1の結果を出した．
-
**12/ 12 [#j7c01c95]
***ストーリー [#e188f83c]
先行研究で不具合管理パターンが修正時間に影響を与えている...
先行研究でパターン4にて修正時間が長い集団と短い集団が存在...
パターン4にて修正時間が長い集団を短い集団にしたい~
先行研究で触れられていない + 修正時間を短くしたい ~
→ パターン4にて修正時間が短い要因 or 長い要因を見つける...
不具合修正を短くするためには効率的な不具合管理プロセスが...
効率的な不具合管理プロセス：報告者が不具合の詳細を管理者...
パターン4のみ上記の2つの要素が関わっている．~
・パターン1,2：報告不要~
・パターン1,3：割り当て不要~
上記の2つがパターン4の修正時間に大きく関わっているのでは...
・報告に慣れている必要がある，報告で詳細を伝えることがで...
・適切に割り当てるためには管理者が修正者のことを熟知して...
報告の慣れ → 報告回数~
報告で詳細を伝えられている → 報告の際に，再現方法，スタッ...
修正者を熟知しているか→ いままでプロジェクト内で関わった...
RQ1 : 報告者が適切に報告できているかどうか(What makes a g...
・1-1：報告回数が多い開発者は少ない開発者よりも修正時間が...
・1-2：再現方法，スタックトレース，テストケースの記載の有...
RQ2 : 管理者が修正者のことを熟知しているかどうか~
パターン4の修正時間が短い集団と長い集団で比較~
***不具合の概要を伝えられているか否かをなにで評価するか [...
- 再現方法の記載の有無
- 報告回数 ( 報告に慣れているかどうか )
- スタックトレース( エラーが発生した時に表示される内容 )...
- テストケースの有無 ( コードの有無 → 目視 )
- スクリーンショットの有無 ( 添付画像の有無で取得 → 目視 )
- 文字数
***親密度を他の言葉で [#ve4b9b12]
- 協調作業
- 共同作業実績
**12/ 6 [#daae2456]
***DONE [#db21d4d6]
- 研究ストーリーを考えた．
***TODO[#db21d4d6]
- 親密度がなぜでてくるのかが書けていない．~
4つのパターンで不具合管理プロセスが運用されていて，全ての...
プロセスを円滑に進めるためには，主に2つが重要である．~
1つ目は，RT間では適切な不具合報告がなされているかどうかで...
2つ目は，TF間では当該不具合の修正に適切な修正者に割り当て...
適切な修正者に割り当てるためには割当者が修正者のことを熟...
- 親密度の言い方を変えたほうがいい．
- なにに注目すれば報告者が不具合の概要を適切に伝えられる...
-- what makes a good bug report?
--報告者：報告回数25回以上，修正担当記録なしのエンドユーザ
--修正者：修正回数50以上
-適切な報告されていないが，割当者と修正者間で親密度が高い...
*** ストーリー[#m93a1309]
不具合管理プロセスにはR=T=F，R=T≠F，R≠T=F，R≠T≠Fの4つのパ...
上記のパターンが不具合修正時間に影響を与えることが先行研...
しかし，修正時間が最も長いパターン4に他のパターンと同程度...
そこでパターン4で2つの集団が存在する理由があり，その理由...
本研究は，パターン4において修正時間が長い集団の修正時間を...
修正時間を短くするためには円滑な不具合管理プロセスが必要...
パターン4の修正時間に関わる要因を調査することで一つあたり...
パターン1,2は発見した不具合を報告する必要がない．そのため...
パターン1,3は報告された修正を他の開発者に割り当てることが...
パターン4において報告が適切に行われているか、と適切な割り...
RT間においては適切に不具合の概要が伝わっているのかが大切~
→概要を正確に伝えるためには報告するべき箇所を理解している...
→報告するべき点を理解するには多くの報告を経験する必要があ...
→報告に慣れている開発者が報告した場合と慣れていない開発者...
→報告回数に注目~
TF間においては適切な修正者に割り当てることができてるかが...
-親密度
--割り当て者と修正者の親密度が高い場合，短い場合よりも修...
--互いを熟知している間柄であれば修正時間が短くなる
-報告者の練度
--報告者として報告回数が多いほど、修正時間が短い
-- 報告することに慣れており，修正者がスムーズに修正するこ...
-報告者の練度とTF間の親密度の関係
--報告者が報告慣れしていなくても，親密度が高ければ修正時...
--親密度が高くなくても，報告者が報告慣れしていれば修正時...
***FOSE [#m93a1309]
-
- 修正者がどの行を変更しているのかがわかれば，作った人が...
-報告者に関して
-- 報告者がエンドユーザなのか，開発者なのかで差
-- 報告者が報告慣れしている場合とそうでないの差
--親密度で差を図る際に，親密度は高くないが報告者が報告慣...
-OSSではわからないが，業務の際に締め切りを早めに設ける人...
-報告とか割り当ての際のテンプレを作るといいのかもしれない
-同時期に抱えてるタスクが関係している
-- 修正者が抱えているタスクが多い
-- 普段は割り当て，修正者を自身で行なっているが，抱えてい...
- 考えられることが多くて目的を見失いやすそう
**11/ 26 [#cd7df2e4]
- パターン4のみにしかいえない特徴に注目
- リーダーはすべてのパターンに言えるから論理的に矛盾して...
***親密度 [#h6ebbfdb]
- 割当者と修正者とのペアの回数が多い
-- 多い場合と短い場合で比較
-- いろんなコンポーネントを担当するが遅い
-- 1つのコンポーネントしか担当しないが短い
- Aが見つけてAが割り当てるという場合と~
誰かわからない人からの報告を割り当てる場合とは違う．
***リーダー [#zc9d8ecf]
- 修正リーダー・修正時間に着目する
- 修正リーダー：コンポーネント単位の不具合において最も修...
(関わっている年月が最も長い人物・両方でみてもいいかも)
-RQ1 : 修正リーダーの割合は？
-- 各リーダーが全体の何割を占めているのかを知るため
-RQ2 : 修正リーダーは他の開発者よりも修正時間が短いのか
--短い場合 -要因- ~
・ コンポーネントを熟知している (修正リーダーが創立者，関...
・ 修正リーダーのスキルが高い (修正パッチが再修正になるこ...
・ 重要度，優先度が高い修正依頼が多い(急かされている)~
--長い場合 -逆の要因- ~
・ 修正リーダーに修正困難な不具合が修正するため (Reopened...
・ 同時期に複数の修正依頼を抱えていることが多いため~
--有意差なし -どうして差がないのか- ~
・修正リーダーがリーダーではない(修正回数でリーダーを定義...
・修正リーダーのスキルが同程度 (修正パッチが再修正になる...
**11/ 20 [#r06f3d9b]
- 要因だけでは広義だから，「？？」の要因を調査するという...
- ストーリーがないといけない
-- 有意差がでればOK，でなければダメ，という仮説ではいけない
**11/ 14 [#df07d9a5]
-スライドの流れ~
OSS開発において日々多くの不具合報告がなされている．~
利用するにあたって必要な箇所がいつ修正されるのかを知りたい~
不具合修正の時間を予測する必要がある．~
予測するツールがさまざまある~
精度向上に関する研究が多くなされているがまだ不十分~
精度向上を目指す→ 説明変数になる要因を探す．~
-修正時間はR≠T≠Fが最も時間がかかる要因は未解明
-予測の精度は低い
**11/ 5 [#m097f550]
-モジュールごとに長がいるかもしれない
--専門知識が必要でそれを修正できるひとが限られるからとか
-修正時間が短い集合と長い集合から組み合わせを抽出する
--最終的に比較するからこの集団を使う
--中央値より短いか長いかで集団を区切る
-状況を理解する必要がある．仮説を細かく考える必要がある．
--研究発表のスライドを作る
-修正時間が負の場合も削除する必要はない
--他のデータが100日単位でずれていたりなど，見えていないデ...
--不適切なデータで見えている分を削除したくなるが他のデー...
***TODO [#zf4cf1ed]
-研究発表のスライドを作る
-短い集団と長い集団の取り方を修正する
-システマチックに仮説を立てる
**10/ 31~ [#m39c14e3]
***REPORT [#oac82db5]
--&attachref(進捗報告.key);
--&attachref(進捗報告.pdf);
***TODO [#eaebde5d]
-修正時間をプロットする
-仮説と前処理がうまいこと噛み合ってない気もする
--修正時間が短い場合と修正時間が長い集団を抽出して，その...
-3543件→17件にしたが，削除した組み合わせと比較するしたい
--17件の各修正時間(箱ひげ図)と削除した組み合わせの修正時...
-
**10/ 23~ [#eaa12d89]
-割り当て者と修正者の関係のほかに，報告者と割り当て者の関...
-分布をみて明らかに割り当て回数が少ないのは重要なデータで...
→分布から見て100件以上でフィルタリングを行う，で良い．
-自分以外の割り当ての多い開発者に注目する，という認識でOK
--数値的な閾値は考える必要がある
**10/ 23[#v0ff48ce]
***TODO [#v188c985]
-割り当て者の分布を算出する
-全ての工程が違う開発者の場合の修正時間を短縮したい~
→親密度の高い人同士なら早いのではという仮説~
→親密度を割当率でやっていた~
→率ではなくて数でやったほうがいいのではないか
***DONE [#ka1999c0]
-前処理
--assigner, assigneeの文字列に[ indox, eclipse, php, plat...
-割り当て者の分布算出
-結果
--eclipseプロジェクトにおける割り当て者：21323人，割り当...
割り当ての80％を担当している割り当て者：1760人
--&attachref(報告.pdf);
**10/15 [#ad4f0d7b]
-assigner : 譲渡人(割り当てる人)
-assignee : 譲り受け人(修正者)
***DONE [#u8d7fbe8]
-前処理を丁寧にした
--プロジェクトをeclipseに限定
--Noneや空白を除外
--メールアドレスに@がない，.orgがあるものを除外
--割当者と修正者が同一人物であるものを除外
-[求める結果]
--上位割当者に割り当てられている修正者が共通して1人以上いる
--明らかに割り当てられている割合が大きい開発者がいる
-[ぱっと見わかったこと]
--10%以上割り当てられている開発者が3名
---Erich Gamma(2)，Martin Aeschlimann(2)，Dirk Baeumer(1)
--10名の内訳に多く存在する開発者
---Erich Gamma(7)，Tod Creasey(6)，Olivier Thomann(5)，
---Martin Aeschlimann(4),Dirk Baeumer(2)
***TODO [#yf11e5b5]
-Erich Gamma は eclipseの創立者だからその人しか直せない場...
-データ分布がわからないと分析，議論できない
--上位10人がデータ分布の８割を占めるなどの根拠がないとい...
-もともとある仮説を元に分析しているのでそれが当てはまって...
--全ての工程が違う開発者の場合の修正時間を短縮したい~
→親密度の高い人同士なら早いのではという仮説~
→親密度を割当率でやっていた~
→率ではなくて数でやったほうがいいのではないか．分布がわか...
-組織を削除する処理が雑~
→eclipseから割り当てられているメールアドレスならorgがつく...
**10/7 [#r27e3ef3]
***ADVICE [#tc744ee2]
-データ設計が8割
-自分の見たいデータのみにすることがまず大事
--自分が報告して自分で修正している人の割合を見るとがっか...
--人が人に割り当てていることに着目するべきでBotが割り当て...
-未加工のデータ知る
-
-
***TODO [#xfadca5b]
-一つのプロジェクトにのみ着目する
--[eclipse]
-割当者が組織であるケースを削除
-自分が自分に割り当てているケースを削除
-結果を見る際に期待している結果とどの程度差異があるのか
--[求める結果を書く]
-自分が扱っているデータがなにかをよく知る
***DONE [#u9886247]
-
**10/1 [#r1f928e2]
***DONE [#dcffaf96]
-assignee_nameがunknownでもメールアドレスがわかっている場...
-プロジェクトごとの割当数
終了行:
*Memo [#a11824de]
-[[研究テンプレート]]~
--https://docs.google.com/spreadsheets/d/1yvgRGxTOrHRpvd1...
-論文検索；ACM
--https://dl.acm.org/
*Link [#a11824de]
#ls
[[作島/研究テーマ]]
* 時間割 [#cf536001]
|>|>|>|>|>|CENTER:|c
| |~Mon|~Tue|~Wed|~Thu|~Fri|h
|~1||||||
|~2||||||
|~3|||||大ゼミ|
|~4||環境社会システム論||||
|~5||||||
* Meeting[#hb323ab0]
** 4/ 16 [#k04ce243]
***DONE [#pbf99c07]
***TODO [#m658a609]
** 4/9 [#re310c02]
*** DONE [#f9bb0c12]
- Continue Deployment の紹介論文を読んだ
*** TODO [#x54820af]
論文を読むよりも，まず用語をおさえる．
- 体系的に学習するために本を購入し，スライドにまとめる
**2/26 テーマ練り会 [#q6567033]
-management規格が存在するのでどのリスクをマネージメントし...
-- PMBOK，SWBOK，KPIなど
-プロジェクトや開発者にかかっている負荷を可視化できる指標...
-デスマーチ（death march）~
システム開発現場の過酷な労働環境を表す言葉．~
人員不足，短すぎる開発期間，予算不足，ユーザからの過剰な...
**2/21 [#m89b768c]
卒論の修正内容の確認
-研究の根拠はなになのか．
--報告回数，スタックトレース，共同回数で開発者群を分割し...
--多くの要因が考えられる中，その3つを選択しなぜそれが妥当...
**1/ 23 [#kb544e03]
考察を思案中
- JDTとPlatformを比較する必要はない
- あるコンポーネントでは修正時間が関わっているかも
-- 一つのコンポーネントが足を引っ張っていてコンポーネント...
-- まずJDTの各コンポーネントにおいて修正時間を算出してみ...
**1/ 15 [#o1967e3f]
- パターン4の箱ひげ図の上と下が含まれる結果になる要因を明...
- 縦軸を対数変換するとクラスタリングがいい感じになると思う
- 関わった回数が多い集団と少ない集団の代表者を見つけて，...
- 重要度や優先順位などは手動で行うため，分析に有用かどう...
- コンポーネントごとに分析するといいかも(UIとかは簡単な修...
**12/ 26 [#q808be47]
-調査結果を出す
-x軸割り当て時間，y軸修正時間のグラフ出す
-モチベーションがなにかを明確にする
***DONE [#uefc6f28]
-2章レビュー提出 (12/23)
-研究のモチベーション
--不具合パターンで他の開発者に修正を依頼する際に障壁とな...
先行研究のデータ(2007年1月→2009年12月)で出た結果を自分が...
-前処理
-- 再割当なし
--reopenなし
--FIXEDのみ限定
--修正時間を assigned_date → fixed_date から assigned_dat...
--assigned_dateとmodified_dateが全く同じ時間であるときは...
fixed_dateは，よくわからない．
modified_dateは，最終ラベルが貼られたときの時間を指す．
上記でやる場合，再割当も再修正もないため，割り当てられて...
RQ1 : 先行研究の不具合管理パターンのデータ割合や修正時間...
RQ2: 分担解決型において修正時間に影響を与える要因を調査す...
RQ1より分担解決型のみではなく，修正委託型にも同様の結果が...
RQ2:いままで管理者と修正者が関わった回数が修正時間に影響...
分担解決型，修正委託型，その両者
**12/ 17 [#m063caeb]
***TODO [#c19faca1]
-卒論2,3章書く．
-共同開発実績の回数のデータを出す．
-スタックトレースとかを抽出するスクリプトを作る．
***DONE [#ac714586]
- 卒論2,3章を書き，レビューをしてもらった(次回締め切り 12...
- RQ1-1の結果を出した．
-
**12/ 12 [#j7c01c95]
***ストーリー [#e188f83c]
先行研究で不具合管理パターンが修正時間に影響を与えている...
先行研究でパターン4にて修正時間が長い集団と短い集団が存在...
パターン4にて修正時間が長い集団を短い集団にしたい~
先行研究で触れられていない + 修正時間を短くしたい ~
→ パターン4にて修正時間が短い要因 or 長い要因を見つける...
不具合修正を短くするためには効率的な不具合管理プロセスが...
効率的な不具合管理プロセス：報告者が不具合の詳細を管理者...
パターン4のみ上記の2つの要素が関わっている．~
・パターン1,2：報告不要~
・パターン1,3：割り当て不要~
上記の2つがパターン4の修正時間に大きく関わっているのでは...
・報告に慣れている必要がある，報告で詳細を伝えることがで...
・適切に割り当てるためには管理者が修正者のことを熟知して...
報告の慣れ → 報告回数~
報告で詳細を伝えられている → 報告の際に，再現方法，スタッ...
修正者を熟知しているか→ いままでプロジェクト内で関わった...
RQ1 : 報告者が適切に報告できているかどうか(What makes a g...
・1-1：報告回数が多い開発者は少ない開発者よりも修正時間が...
・1-2：再現方法，スタックトレース，テストケースの記載の有...
RQ2 : 管理者が修正者のことを熟知しているかどうか~
パターン4の修正時間が短い集団と長い集団で比較~
***不具合の概要を伝えられているか否かをなにで評価するか [...
- 再現方法の記載の有無
- 報告回数 ( 報告に慣れているかどうか )
- スタックトレース( エラーが発生した時に表示される内容 )...
- テストケースの有無 ( コードの有無 → 目視 )
- スクリーンショットの有無 ( 添付画像の有無で取得 → 目視 )
- 文字数
***親密度を他の言葉で [#ve4b9b12]
- 協調作業
- 共同作業実績
**12/ 6 [#daae2456]
***DONE [#db21d4d6]
- 研究ストーリーを考えた．
***TODO[#db21d4d6]
- 親密度がなぜでてくるのかが書けていない．~
4つのパターンで不具合管理プロセスが運用されていて，全ての...
プロセスを円滑に進めるためには，主に2つが重要である．~
1つ目は，RT間では適切な不具合報告がなされているかどうかで...
2つ目は，TF間では当該不具合の修正に適切な修正者に割り当て...
適切な修正者に割り当てるためには割当者が修正者のことを熟...
- 親密度の言い方を変えたほうがいい．
- なにに注目すれば報告者が不具合の概要を適切に伝えられる...
-- what makes a good bug report?
--報告者：報告回数25回以上，修正担当記録なしのエンドユーザ
--修正者：修正回数50以上
-適切な報告されていないが，割当者と修正者間で親密度が高い...
*** ストーリー[#m93a1309]
不具合管理プロセスにはR=T=F，R=T≠F，R≠T=F，R≠T≠Fの4つのパ...
上記のパターンが不具合修正時間に影響を与えることが先行研...
しかし，修正時間が最も長いパターン4に他のパターンと同程度...
そこでパターン4で2つの集団が存在する理由があり，その理由...
本研究は，パターン4において修正時間が長い集団の修正時間を...
修正時間を短くするためには円滑な不具合管理プロセスが必要...
パターン4の修正時間に関わる要因を調査することで一つあたり...
パターン1,2は発見した不具合を報告する必要がない．そのため...
パターン1,3は報告された修正を他の開発者に割り当てることが...
パターン4において報告が適切に行われているか、と適切な割り...
RT間においては適切に不具合の概要が伝わっているのかが大切~
→概要を正確に伝えるためには報告するべき箇所を理解している...
→報告するべき点を理解するには多くの報告を経験する必要があ...
→報告に慣れている開発者が報告した場合と慣れていない開発者...
→報告回数に注目~
TF間においては適切な修正者に割り当てることができてるかが...
-親密度
--割り当て者と修正者の親密度が高い場合，短い場合よりも修...
--互いを熟知している間柄であれば修正時間が短くなる
-報告者の練度
--報告者として報告回数が多いほど、修正時間が短い
-- 報告することに慣れており，修正者がスムーズに修正するこ...
-報告者の練度とTF間の親密度の関係
--報告者が報告慣れしていなくても，親密度が高ければ修正時...
--親密度が高くなくても，報告者が報告慣れしていれば修正時...
***FOSE [#m93a1309]
-
- 修正者がどの行を変更しているのかがわかれば，作った人が...
-報告者に関して
-- 報告者がエンドユーザなのか，開発者なのかで差
-- 報告者が報告慣れしている場合とそうでないの差
--親密度で差を図る際に，親密度は高くないが報告者が報告慣...
-OSSではわからないが，業務の際に締め切りを早めに設ける人...
-報告とか割り当ての際のテンプレを作るといいのかもしれない
-同時期に抱えてるタスクが関係している
-- 修正者が抱えているタスクが多い
-- 普段は割り当て，修正者を自身で行なっているが，抱えてい...
- 考えられることが多くて目的を見失いやすそう
**11/ 26 [#cd7df2e4]
- パターン4のみにしかいえない特徴に注目
- リーダーはすべてのパターンに言えるから論理的に矛盾して...
***親密度 [#h6ebbfdb]
- 割当者と修正者とのペアの回数が多い
-- 多い場合と短い場合で比較
-- いろんなコンポーネントを担当するが遅い
-- 1つのコンポーネントしか担当しないが短い
- Aが見つけてAが割り当てるという場合と~
誰かわからない人からの報告を割り当てる場合とは違う．
***リーダー [#zc9d8ecf]
- 修正リーダー・修正時間に着目する
- 修正リーダー：コンポーネント単位の不具合において最も修...
(関わっている年月が最も長い人物・両方でみてもいいかも)
-RQ1 : 修正リーダーの割合は？
-- 各リーダーが全体の何割を占めているのかを知るため
-RQ2 : 修正リーダーは他の開発者よりも修正時間が短いのか
--短い場合 -要因- ~
・ コンポーネントを熟知している (修正リーダーが創立者，関...
・ 修正リーダーのスキルが高い (修正パッチが再修正になるこ...
・ 重要度，優先度が高い修正依頼が多い(急かされている)~
--長い場合 -逆の要因- ~
・ 修正リーダーに修正困難な不具合が修正するため (Reopened...
・ 同時期に複数の修正依頼を抱えていることが多いため~
--有意差なし -どうして差がないのか- ~
・修正リーダーがリーダーではない(修正回数でリーダーを定義...
・修正リーダーのスキルが同程度 (修正パッチが再修正になる...
**11/ 20 [#r06f3d9b]
- 要因だけでは広義だから，「？？」の要因を調査するという...
- ストーリーがないといけない
-- 有意差がでればOK，でなければダメ，という仮説ではいけない
**11/ 14 [#df07d9a5]
-スライドの流れ~
OSS開発において日々多くの不具合報告がなされている．~
利用するにあたって必要な箇所がいつ修正されるのかを知りたい~
不具合修正の時間を予測する必要がある．~
予測するツールがさまざまある~
精度向上に関する研究が多くなされているがまだ不十分~
精度向上を目指す→ 説明変数になる要因を探す．~
-修正時間はR≠T≠Fが最も時間がかかる要因は未解明
-予測の精度は低い
**11/ 5 [#m097f550]
-モジュールごとに長がいるかもしれない
--専門知識が必要でそれを修正できるひとが限られるからとか
-修正時間が短い集合と長い集合から組み合わせを抽出する
--最終的に比較するからこの集団を使う
--中央値より短いか長いかで集団を区切る
-状況を理解する必要がある．仮説を細かく考える必要がある．
--研究発表のスライドを作る
-修正時間が負の場合も削除する必要はない
--他のデータが100日単位でずれていたりなど，見えていないデ...
--不適切なデータで見えている分を削除したくなるが他のデー...
***TODO [#zf4cf1ed]
-研究発表のスライドを作る
-短い集団と長い集団の取り方を修正する
-システマチックに仮説を立てる
**10/ 31~ [#m39c14e3]
***REPORT [#oac82db5]
--&attachref(進捗報告.key);
--&attachref(進捗報告.pdf);
***TODO [#eaebde5d]
-修正時間をプロットする
-仮説と前処理がうまいこと噛み合ってない気もする
--修正時間が短い場合と修正時間が長い集団を抽出して，その...
-3543件→17件にしたが，削除した組み合わせと比較するしたい
--17件の各修正時間(箱ひげ図)と削除した組み合わせの修正時...
-
**10/ 23~ [#eaa12d89]
-割り当て者と修正者の関係のほかに，報告者と割り当て者の関...
-分布をみて明らかに割り当て回数が少ないのは重要なデータで...
→分布から見て100件以上でフィルタリングを行う，で良い．
-自分以外の割り当ての多い開発者に注目する，という認識でOK
--数値的な閾値は考える必要がある
**10/ 23[#v0ff48ce]
***TODO [#v188c985]
-割り当て者の分布を算出する
-全ての工程が違う開発者の場合の修正時間を短縮したい~
→親密度の高い人同士なら早いのではという仮説~
→親密度を割当率でやっていた~
→率ではなくて数でやったほうがいいのではないか
***DONE [#ka1999c0]
-前処理
--assigner, assigneeの文字列に[ indox, eclipse, php, plat...
-割り当て者の分布算出
-結果
--eclipseプロジェクトにおける割り当て者：21323人，割り当...
割り当ての80％を担当している割り当て者：1760人
--&attachref(報告.pdf);
**10/15 [#ad4f0d7b]
-assigner : 譲渡人(割り当てる人)
-assignee : 譲り受け人(修正者)
***DONE [#u8d7fbe8]
-前処理を丁寧にした
--プロジェクトをeclipseに限定
--Noneや空白を除外
--メールアドレスに@がない，.orgがあるものを除外
--割当者と修正者が同一人物であるものを除外
-[求める結果]
--上位割当者に割り当てられている修正者が共通して1人以上いる
--明らかに割り当てられている割合が大きい開発者がいる
-[ぱっと見わかったこと]
--10%以上割り当てられている開発者が3名
---Erich Gamma(2)，Martin Aeschlimann(2)，Dirk Baeumer(1)
--10名の内訳に多く存在する開発者
---Erich Gamma(7)，Tod Creasey(6)，Olivier Thomann(5)，
---Martin Aeschlimann(4),Dirk Baeumer(2)
***TODO [#yf11e5b5]
-Erich Gamma は eclipseの創立者だからその人しか直せない場...
-データ分布がわからないと分析，議論できない
--上位10人がデータ分布の８割を占めるなどの根拠がないとい...
-もともとある仮説を元に分析しているのでそれが当てはまって...
--全ての工程が違う開発者の場合の修正時間を短縮したい~
→親密度の高い人同士なら早いのではという仮説~
→親密度を割当率でやっていた~
→率ではなくて数でやったほうがいいのではないか．分布がわか...
-組織を削除する処理が雑~
→eclipseから割り当てられているメールアドレスならorgがつく...
**10/7 [#r27e3ef3]
***ADVICE [#tc744ee2]
-データ設計が8割
-自分の見たいデータのみにすることがまず大事
--自分が報告して自分で修正している人の割合を見るとがっか...
--人が人に割り当てていることに着目するべきでBotが割り当て...
-未加工のデータ知る
-
-
***TODO [#xfadca5b]
-一つのプロジェクトにのみ着目する
--[eclipse]
-割当者が組織であるケースを削除
-自分が自分に割り当てているケースを削除
-結果を見る際に期待している結果とどの程度差異があるのか
--[求める結果を書く]
-自分が扱っているデータがなにかをよく知る
***DONE [#u9886247]
-
**10/1 [#r1f928e2]
***DONE [#dcffaf96]
-assignee_nameがunknownでもメールアドレスがわかっている場...
-プロジェクトごとの割当数
ページ名:
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
