![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
#author("2019-12-05T14:50:47+09:00","","") #author("2019-12-06T14:00:52+09:00","","") *Link [#z4499fc8] -[[作島]] *したいこと [#x170d127] -人間と同等の振る舞い，言葉遣いを感情や個性によって変化させることが可能なBotの作成 -新人教育などの教育指導の支援 * Sample [#pe866fdf] -タイトル --著者 --出典 --内容 --スライド ---関連研究 *考え方 [#r5d5aaa4] -なぜその問題解決方法でいいのかという気持ちで読む．(仮説，アプローチ，話の落とし方) --もっとほかの手法や考え方があるのでは -怒りの気持ちを感じるためにはその分野のスタンダードを知っている必要がある． -&color(red){多くのリソースをかければかけるだけいい結果になるなんてくだらない結果は求めてない}; -理想的な研究流れ --学部生：影響に関連する変数を明らかにする --院生：変数をアルゴリスムに乗せて精度を向上させる *テーマ決めの際 [#bb720f31] -自分が本当にしたいことから広げていく -自分の中では，経営に興味がある --OSS経営をしていて，成功パターンと失敗パターンを分析するとか *KeyWords [#x170d127] -不正を暴く -うまいこと人間関係をかわしていく -人間関係の打ち解け *研究テーマ [#k90f96ee] -概要 --バグ修正の際のR≠T≠Fのパターン時，どんなバグかを考慮せずとも修正までにかかる時間が最も長い． --R≠T≠Fで他のパターンを凌ぐ良い結果の場合が存在する． --Bestと，Worstに関してなぜそのようになるのかを分析する． --R≠T≠Fパターンの結果が不安定な理由を解明する． -背景 --不具合修正にかかる時間を予測したい． --不具合修正にかかる時間を最小にしたい． -問題点 --最も実際の作業環境であると考えられるR≠T≠Fパターンの精度が不安定． --なぜ良い場合もあれば悪い場合があるかの理解がない． --どうしてそのような結果になるのかという原因に関する言及がない(先行研究)． --PlatformとJDTの2つのプロジェクトでしか行なっておらず，一般性が乏しい(先行研究)． ---Eclipse Platform projects：統合開発環境(IDE) ---Eclipse Java Development Tools projects：プラグイン．Javaソースコードのコンパイル，実行機能，コード補完，APIリファレンスの表示，リファクタリング，デバッグなどの機能の提供 -貢献 --実際の業務形態に対して直接的に貢献を及ぼすことができる． --コミュニティでの作業効率の向上．~ →要因を理解することでコミュニティを効率よく運用するために必要な要因を理解し，的確なコミュニティ運用が可能となる * History [#q711700a] **12/ 6 [#daae2456] -RQ1 : 割当者と修正者の組み合わせ - 親密度 - -- 1-1：親密度が高いペアほど修正時間が短いのか． -- 1-2： -RQ2 : 担当コンポーネント数 -- 2-1：開発者が修正したコンポーネント数の分布はどうなっているのか． -- 2-2： *** ストーリー[#m93a1309] 不具合管理プロセスにはR=T=F，R=T≠F，R≠T=F，R≠T≠Fの4つのパターンがあり，それぞれパターン1，パターン2，パターン3，パターン4と呼称する．~ 上記のパターンが不具合修正時間に影響を与えることが先行研究で示されており，パターン4が他のパターンよりも修正時間が長い結果になっていた．~ しかし，修正時間が最も長いパターン4に他のパターンと同程度の修正時間が短い集団が存在していた．~ そこでパターン4で2つの集団が存在する理由があり，その理由を解明することで不具合管理プロセスをより効率化できると考えた． 本研究は，パターン4において修正時間が長い集団の修正時間を短くすることを目指す．~ 修正時間を短くするためには円滑な不具合管理プロセスが必要であり、それを実現するための必要な要因を調査する．~ パターン4の修正時間に関わる要因を調査することで一つあたりの修正時間を削減し，より多くの不具合を修正することを可能とする． パターン1,2は発見した不具合を報告する必要がない．そのため報告が適切に行われているかが関係していない．~ パターン1,3は報告された修正を他の開発者に割り当てることが行われない．そのため割り当てが適切に行われているかが修正時間に影響がない．~ パターン4において報告が適切に行われているか、と適切な割り当てができているかの2つの要因が修正時間に関わっている．~ RT間においては適切に不具合の概要が伝わっているのかが大切~ →概要を正確に伝えるためには報告するべき箇所を理解している必要がある~ →報告するべき点を理解するには多くの報告を経験する必要がある~ →報告に慣れている開発者が報告した場合と慣れていない開発者が報告した場合とで差があるのではないか~ →報告回数に注目~ TF間においては適切な修正者に割り当てることができてるかが大切→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, platform ] を含む列を除外 -割り当て者の分布算出 -結果 --eclipseプロジェクトにおける割り当て者：21323人，割り当て数：234960件~ 割り当ての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の創立者だからその人しか直せない場合がある(親密であるとは言えない) -データ分布がわからないと分析することができない -もともとある仮説を元に分析しているのでそれが当てはまっていなければその仮説が妥当ではなかったというだけ --全ての工程が違う開発者の場合の修正時間を短縮したい~ →親密度の高い人同士なら早いのではという仮説~ →親密度を割当率でやっていた~ →率ではなくて数でやったほうがいいのではないか．分布がわからない以上，議論ができない． -組織を削除する処理が雑→eclipseから割り当てられているメールアドレスならorgがつくから． -データ分布の８割を占めるのが上位10人だったのならわかるが。。 -分布をみる前にパーセントを出しても意味がない - **10/7 [#r27e3ef3] ***ADVICE [#tc744ee2] -データ設計が8割 -自分の見たいデータのみにすることがまず大事 --自分が報告して自分で修正している人の割合を見るとがっかりするが自分が見たいデータではない --人が人に割り当てていることに着目するべきでBotが割り当てているのは自分がみたいデータではない -未加工のデータ知る - - ***TODO [#xfadca5b] -一つのプロジェクトにのみ着目する --[eclipse] -割当者が組織であるケースを削除 -自分が自分に割り当てているケースを削除 -結果を見る際に期待している結果とどの程度差異があるのか --[求める結果を書く] -自分が扱っているデータがなにかをよく知る **7/31~ [#z4db96e4] *思ったこと [#x170d127] -どうしてOSSに参加し続けることができるのか． --趣味っていわれても． --考え方の違いかな． -&color(blue){誰に指示を受けたかで作業効率が違うものなのか}; -&color(blue){煙たがられている人と関わってるがうまいことかわして円滑にプロジェクトを進めるために必要なスキルってどんなものなのか．}; --頼りにされる人材とはなにで判断されているのか． --もちろん成果物の質や実績ではあると思うが．なにかこれで議論はできないかな． --実績はどのように積んでいくのがいいのか．(ロールアサインメントの話と似てる？) --&color(red){世渡りが上手なひとはどうしているのか．};解明したいなあ． -どうしてSAツールが使えないものなのか． --信頼性がまだまだ低いため --人でさえも一貫性を持って分類することが難しく，人がラベルをつけたものを学習しているため精度が向上しない --&color(red){複数の意味がある文では，最終的に何が言いたいのかを捉えることができていない}; --短いテキストと適切な語彙の重みに関して問題がある可能性がある． --明示的に書かれていることから測定することは可能であるが&color(red){文脈をとって考えることはできない}; --文脈をとらえることができないから言葉の含みを捉えることができない，皮肉を判別することができない． -様々なツールからどのように異なる結果をもたらすのかを示している-Jongeling- --その理由や原因についてなにか言及しているのかな(ここ読む) --結果が異なる要因の分析とかどうか -&color(blue){聞いてることと答えが食い違うことが多い}; --自己弁護が要因に考えられる --相手を恐縮させることなく会話を成立させることで無駄なコストや精神的負荷を軽減する -&color(red){どうして企業初とOSS発のプロジェクトでは顕著な扱いの差があるのか．}; --企業主導のOSSプロジェクトでの開発ではボランティアのパッチの承認率が非常に低い． --従業員とボランティアのマージまでの時間も大きく差がある．~ ---企業の開発者とOSS開発者での間でなにかが違うのではないのか． ---Big FiveやSAツールを適応して違いを見る． ---性格，他の開発者への態度(ボランティアと従業員) ---貢献者の新人が定着しにくい．(理由はたくさんある) ---その大きな理由の一つとしてコミュニケーションの態度にある(仮説) -&color(red){新人教育をする際に，どのようにすれば最適なのか}; --新人教育＋感情分析 --プログラム学習時に，専門用語が多いなど理解できないアドバイスがきて意欲がなくなる．(専門用語が多いなど) --教員による指導よりもTAによる指導の方が意欲がわく． --学習者の理解レベルに応じた会話の教え方を提供． --実験・評価が大変そう -対話Botの作成 --人間の言葉を理解するBotの作成 ---実現することが困難 ---なぜそれをする必要があるのか． ---問題点があるのか否かについては？ ~~ -感情分析ツールは正確ではない → 正確な感情分析ツールを構築する． --既存研究を拡張するという形になるが，&color(red){特定の問題点があり，それを改善した結果，精度が向上したというロジックがないと精度が向上するだけであまり意味がない．}; --代表的なツールの作成手法を調べてみる --自分ならどうするのか，既存ツール作成の際に何か違和感や疑問点はないか． -6つの感情分析ツールと1つのポライトネス分析ツールの分析とあるが，感情分析ツールの数のわりにポライトネス分析ツールって少ない？ -分類できるテキスト文と分類できないテキスト文の違いを分析するとか？ -感情分析ツールにはドメイン依存性があると書かれているがどのツールがどの分野に最適かなどをテーマにしている論文はあるのか．~ → 正確に分析できていないという論文があるが，適切な分野に使用すれば信頼性のある結果がある可能性がある．~ &color(red){各論文で目的とした分野での実装が最もいい結果になっているはず(そうでなければ論文になっていない)}; ~~ -
