作島 の履歴(No.34)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 作島 へ行く。
  • 1 (2019-03-07 (木) 07:51:48)
  • 2 (2019-03-17 (日) 07:14:58)
  • 3 (2019-04-11 (木) 04:18:51)
  • 4 (2019-04-16 (火) 07:05:51)
  • 5 (2019-04-18 (木) 07:35:51)
  • 6 (2019-04-24 (水) 05:16:23)
  • 7 (2019-04-25 (木) 06:45:53)
  • 8 (2019-04-29 (月) 08:13:40)
  • 9 (2019-05-15 (水) 03:04:04)
  • 10 (2019-05-22 (水) 05:17:54)
  • 11 (2019-06-12 (水) 05:03:06)
  • 12 (2019-07-16 (火) 01:02:57)
  • 13 (2019-07-19 (金) 05:19:40)
  • 14 (2019-07-20 (土) 06:45:05)
  • 15 (2019-07-24 (水) 04:26:44)
  • 16 (2019-07-24 (水) 05:23:37)
  • 17 (2019-07-28 (日) 10:24:02)
  • 18 (2019-07-30 (火) 07:54:33)
  • 19 (2019-07-31 (水) 03:03:53)
  • 20 (2019-07-31 (水) 08:35:34)
  • 21 (2019-08-01 (木) 06:29:55)
  • 22 (2019-08-04 (日) 07:36:36)
  • 23 (2019-08-04 (日) 13:24:26)
  • 24 (2019-08-05 (月) 06:56:14)
  • 25 (2019-08-07 (水) 07:21:44)
  • 26 (2019-08-15 (木) 07:55:28)
  • 27 (2019-08-19 (月) 09:40:10)
  • 28 (2019-08-20 (火) 08:08:19)
  • 29 (2019-08-21 (水) 05:21:59)
  • 30 (2019-09-03 (火) 04:34:32)
  • 31 (2019-09-05 (木) 07:43:19)
  • 32 (2019-09-10 (火) 07:10:17)
  • 33 (2019-09-18 (水) 05:37:18)
  • 34 (2019-09-24 (火) 04:21:20)
  • 35 (2019-09-27 (金) 03:17:50)
  • 36 (2019-09-29 (日) 09:20:57)
  • 37 (2019-09-29 (日) 16:10:41)
  • 38 (2019-10-02 (水) 07:17:25)
  • 39 (2019-10-05 (土) 08:14:03)
  • 40 (2019-10-07 (月) 02:43:35)
  • 41 (2019-10-13 (日) 10:20:26)
  • 42 (2019-10-14 (月) 09:03:02)
  • 43 (2019-10-15 (火) 03:06:45)
  • 44 (2019-10-16 (水) 06:31:51)
  • 45 (2019-10-18 (金) 07:45:33)
  • 46 (2019-10-23 (水) 00:41:24)
  • 47 (2019-10-23 (水) 07:40:42)
  • 48 (2019-10-29 (火) 23:28:40)
  • 49 (2019-10-30 (水) 15:39:27)
  • 50 (2019-10-31 (木) 01:53:02)
  • 51 (2019-11-04 (月) 00:10:38)
  • 52 (2019-11-05 (火) 08:13:36)
  • 53 (2019-11-06 (水) 04:04:02)
  • 54 (2019-11-10 (日) 08:25:06)
  • 55 (2019-11-26 (火) 06:14:22)
  • 56 (2019-11-26 (火) 08:30:22)
  • 57 (2019-12-03 (火) 08:04:06)
  • 58 (2019-12-05 (木) 05:49:11)
  • 59 (2019-12-06 (金) 00:23:08)
  • 60 (2019-12-06 (金) 05:33:09)
  • 61 (2019-12-11 (水) 09:05:34)
  • 62 (2019-12-12 (木) 02:29:33)
  • 63 (2019-12-16 (月) 05:47:08)
  • 64 (2019-12-21 (土) 04:53:43)
  • 65 (2019-12-22 (日) 08:36:54)
  • 66 (2019-12-24 (火) 02:43:52)
  • 67 (2020-01-15 (水) 02:03:25)
  • 68 (2020-01-23 (木) 02:33:46)
  • 69 (2020-02-24 (月) 07:07:48)
  • 70 (2020-03-16 (月) 06:22:08)
  • 71 (2020-04-09 (木) 11:30:35)
  • 72 (2020-10-05 (月) 16:24:13)

---

Memo†

• 研究テンプレート
  
  • https://docs.google.com/spreadsheets/d/1yvgRGxTOrHRpvd1xt3etVEwwVunkwxjAt0t8HjttxW0/edit?usp=sharing
    
• 論文検索；ACM
  • https://dl.acm.org/

Link†

• 作島/task/task_01
• 作島/task/task_02
• 作島/メモ
• 作島/研究テーマ
• 作島/考え
• 作島/輪講

Sample†

• タイトル
  • 著者
  • 出典
  • 内容
  • スライド
    • 関連研究

Schedule†

考え方†

• なぜその問題解決方法でいいのかという気持ちで読む．(仮説，アプローチ，話の落とし方)
  • もっとほかの手法や考え方があるのでは
• 怒りの気持ちを感じるためにはその分野のスタンダードを知っている必要がある．
• 多くのリソースをかければかけるだけいい結果になるなんてくだらない結果は求めてない
• 理想的な研究流れ
  • 学部生：影響に関連する変数を明らかにする
  • 院生：変数をアルゴリスムに乗せて精度を向上させる

研究テーマ†

• 概要
  • バグ修正の際の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リファレンスの表示，リファクタリング，デバッグなどの機能の提供

• 貢献
  • 実際の業務形態に対して直接的に貢献を及ぼすことができる．
  • コミュニティでの作業効率の向上．
    →要因を理解することでコミュニティを効率よく運用するために必要な要因を理解し，的確なコミュニティ運用が可能となる

Meeting†

9/24†

TODO†

• パッと結果を出していかないと面白くない結果になったとき，どうしようもなくなる．
• 今週中に上位10名は行う．

9/18†

TODO†

• 仮説を実際にデータで調査してみる
  • 他のプロジェクトに参加しているかどうかをみるなら GitTorrent を使えばいい
  • 仮説よりも，システマティックに考えられる仮説に変更することも大事
• 堀口くんに相談をしてみる
• 割り当て者が割り当てる開発者はさまざまだが，最も多くの割合でタスクを頼まれている開発者はなぜなのか．もいいかも

すること†

• 各assignerが割り当てている開発者の上位10名を列挙
  • assignerを絞り込むためのフィルターもなにか設定する
    ・プロジェクト単位で絞る
    ・
    
• 割り当てられている上位開発者の割合算出

9/3†

TODO†

• 全ての工程を違う開発者で行って最高のパフォーマンスを出せた場合，どのような要因があったからなのか(仮説)

DONE†

• 先行研究の分析では
  • このパターンで修正が早いものと遅いものを比較した結果，
    discussions about a bug in Bugzilla が多いほど，修正時間が短い．
  • 割り当て者はバグの再現方法と修正方法について，修正者は誰が適切かについて，議論している
  • 割り当て前の議論を時間をかけずに適切に行うことでバグ修正時間は最適化できる

• 他の要因
  • バグ(バグレポートの内容)
  • 日時
  • 利害関係者

• 成功する場合に起きていると考えられる仮説
  • 3者共通の関係性
    • 信頼している→実績とか
    • 他のプロジェクトに参加しているのか，何に参加しているのか，
      ・(ex)AとBとのプロジェクトなら修正時間に変化はないが，AとCなら修正までに長い時間がかかる．
    • 3者のプロジェクトに参加した時期が近い
      
    • Backyardが似ている
      ・いままで関わってきたプロジェクト開発の傾向が似ている
      ・以前に同じ開発者に師事していた → 最初に関わった開発者が同じ
      ・以前に同じ開発に関わっていた → 1回なのか，複数回なのか
      
    • コミュニケーションの取りやすさ（会話ができる）
    • 開発以外での交流がある

• 報告者と割り当て者の関係性
  • 報告者との会話数が多い

• 割り当て者と修正者の関係性
  • この人！！って割り当てるか，適当に分散してタスクを割り当てているのか
    ・eclipseプロジェクトのバグの44%は複数の開発者に割り当てられる．[Who should fix this bug?]
    ・複数人に割り当てた場合，何人に割り当てるのが最適か，結果に違いはないのか
    ・割り当て者が複数人の開発者を抱えているが，タスクを割り当てる割合は平等ではない
    →多くの割合で割り当てられている開発者の特徴や2者での関係性に特徴があるのか． ・
    
  • 修正者が抱えているタスクが少ない
    ・どこまでなら複数のタスクを抱えていてもある程度の結果が得られるのか．
    
  • 修正者の活動率が高い

• 思ったこと
  • 仮説を立てているうちに修正者が一番重要な位置にいる

8/20†

TODO†

• SourceTree，Bitbucket，eclipseの使い方確認

• 現在あるスクリプトの理解・使用法を確認

• 分析するデータ(どのプロジェクトにおいてどんな成果物を見るのか)を決める
  • 大平先生の論文ではPlatform，JDTのみしかやっていない←少ない
  • 性質の違うプロジェクトを比較するのもあり

• DBのコマンドの確認

• データを取得する

DONE†

• repo_toolsをローカルにクローン

8/7†

• 誰から指示を出されるかでパフォーマンスが変化するのかに関する論文を読む．
  • 分析
    • 指示されてから修正完了するまでの修正時間，返答のときの文字数の違い，具体例を頻繁に記述しているか否かなどで評価する．
    • 貢献者と採択者の組み合わせを調べる．
  • 対処法
    • Aにはこのような話し方，手順を踏むと円滑に会話が進む，
  • 目的
    • 適切に自分の成果物を判定してもらうため

疑問†

• 不具合修正などの予測に関する説明変数を提供する
• 社会的関係性によって修正者がタスクの優先度を決めると考えられるが，優先度を高くする関係性とはどのようなものなのか．相性など．
• 仮説-具体例を多く記述する管理者は割り当てたタスクを優先的に修正してもらいやすい
  →本質的な問題点を改善するというものがない．
• R≠T≠Fの場合の精度をもっとも向上させることができると社会的貢献は大きい→現実的なプロセスだから

DONE†

The Impact of Bug Management Patterns on Bug Fixing: A Case Study of Eclipse Projects†

• pattern_5.pdf
• Patterns_slide.key
• 背景
  • 効率的なバグ管理プロセスが必要
  • 多くの研究はバグ修正時間を短縮する手法に焦点を置いている．割り当てる際

• 先行研究
  • バグ選別の自動化，重複バグの自動検出，バグ発生理由の理解

• 貢献
  • バグ管理システムにおいて，社会的および知識共有要因の重要性を強調．
  • 研究者に対し，役割と個人を統合して考えることの重要性を示す．

• 目的
  • プロセスに関与する個人とバグ修正プロセスの効率に対する個人間の関係の影響を調査し，
    バグ管理システムの新しい理解を知ること

• 結果
  • バグ報告者(R)，バグ割り当て(T)，修正者(F)
  • R=Tの場合，R≠Tよりも17-47%割り当てが早い
  • T=Fの場合，T≠Fよりも割り当ての時間が48-58%長い．修正までにかかる時間は半分．
  • 全行程が異なる開発者で行われる場合は最悪のパフォーマンスになる．
    →場合によっては最高のパフォーマンスを示した．
    →バグコミュニケーションの数が多いほど修正時間が徐々に短くなる．

• 所感・疑問
  • R≠T≠Fの時，バグコミュニケーションの数が多くなるほど修正時間が短くなるとあるがこれに関してもっと深く調査することは可能なのか．
  • 純粋に会話数なのか，そのバグに至るまでの経緯の説明の有無，具体例の有無．これはコンポーネンツに含まれているのか．細分化するとか？

OSS開発における管理者と修正者の社会的関係を考慮した不具合修正時間予測†

• TaskPref_1.pdf
• TaskPref_slide.pdf
• 背景
  • OSSには不具合報告が多数．次期バージョンへ移行，ベンダ企業もOSSを利用したソフトウェア開発を行なっている．
  • 不具合修正が完了するまでの時間を知る必要がある．

• 仮説
  • タスクを割り当てる管理者によって優先順位を決めている
  • その優先順位によって修正までの時間が変わる
• 先行研究
  • 粒度の大きい範囲でしか予測をすることができない
  • 管理者と修正者の社会的関係が優先順位と修正時間に大きな影響を与えることが示唆されている．
• 問題点
  • 大きい粒度の予測しかできない．
  • 予測精度がまだまだ改善の余地あり．

• 目的
  • 特定の管理者から割り当てられたタスクを他の管理者から割り当てられたタスクよりも優先して修正した割合を説明変数に追加(TaskPref)
  • 上記の説明変数が予測精度の向上に寄与するかどうかを調査
• 結果
  • 説明変数 TaskPref は，1日以内の修正予測に関して有用

• 所感・疑問
  • どのような関係性であれば ，TaskPrefの値が大きいのか．
  • 1日という短い期間でTaskPrefは有効であるが，長い範囲での予測に関する説明変数はないのか．→ Patternsがそれに該当

7/31†

• 自分が何をしたいのかを常日頃考えること．

DONE†

• sentiment analysis toolとpoliteness tool を要約
  • TaskPref_0.pdf

7/24†

TODO†

• 論文2本読む．
  • Sentiment and Politeness Analysis Tools on Developer Discussions Are Unreliable, but so Are People
  • On Measuring Affects of GitHub Issues’ Commenters

DONE†

• Sentiment_and_Politeness_Analysis_Tools_on_Developer_Discussions_Are_Unreliable_but_so_Are_People.pdf
  • Nasif Imtiaz, Justin Middleton, Peter Girouard, and Emerson Murphy-Hill
  • 2018 ACM/IEEE 3rd International Workshop
  • ソフトウェア工学での研究で感情分析，ポライトネス分析ツールが多く使われている
    6つの感情分析ツールと1つのポライトネスツールの分析と行う
    →ツール，もっと言えば人でさえも一貫性を持った分類をすることができていない
    

• survey_3.pdf
  • 気分は伝染し，パフォーマンスに影響を与える
  • 感情分析の既存ツールを使用する際，ドメイン依存性がある
    →他のコーパスでの適応が困難
    
  • 同じデータであっても感情分析ツールの結果は異なる
    →この差異を理解することが感情分析についての理解を深める
    それぞれが異なる学習で構築されたモデルであるので，異なる結果になることはさして驚く内容ではない．
    

• ツールをドメイン特化にカスタマイズする
  →ラベル付けがおかしいorコード体系を使わなかったからいい結果がでなかった
  

  
  

• Exploring_Word_Embedding_Techniques_to_ImproveSentiment_Analysis_of_Software_Engineering_Texts.pdf
  • Eeshita Biswas, K. Vijay-Shanker, Lori Pollock
  • 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR)
  • 感情分析ツールにおける訓練データの不均衡が影響を及ぼすのか
    →Yes．訓練データの分布を均等にすると精度が向上．

• 既存ツールをドメインごとにカスタマイズするとどのように影響を及ぼすのか．
  →影響なしという結果．ただしデータ数が足りないだけで，データ数を確保できれば影響があるかもしれない．
• どの程度データを増やせばその影響力を調べることができるのか． データの過学習に関しての言及がいまいち
• MSR19.pdf
  • 広く使われている4つ(SentiStrength，NLTK，Stanford CoreNLP，AlchemyAPI)のSAツールの比較．
    →どれもSEドメインで表現された感情を正確に予測できていない．
  • OSSからのコードレビューコメント用にカスタマイズされたSAツール，SentiCR を開発
  • SEデータについてSAツール：SentiStrength，SentiStrength-SE，Senti4SD，SentiCRの比較
    →SE固有のカスタマイズは正確さを向上させる．
  • 既存の感情分析ツール，ポライトネスツールは正確に識別することができていない．
  • 
アンダーサンプリング，アンダーサンプリング&オーバーサンプリングの組み合わせが感情分析の分類性能をどのように改善するのか~→

• On_Measuring_Affects_of_GitHub_Issues’_Commenters.pdf
  • Giuseppe Destefanis1, Marco Ortu2, David Bowes1, Michele Marchesi2, Roberto Tonelli2
  • 2018 ACM/IEEE 3rd International Workshop
  • 内容
  • [添付]
    • 参考文献

7/16†

TODO†

• Big 5論文を読んでリスト化する
  • An Empirical Investigation of Personality Traits of Software Testers
  • What can OSS mailing lists tell us?


• Politeness論文を読んでリスト化する（来週以降）

DONE†

• An_Empirical_Investigation_of_Personality_Traits_of_Software_Testers.pdf
  • Tanjila Kanij，Robert Merkel，John Grundy
  • 2015 IEEE/ACM 8th International Workshop
  • ソフトウェアテスターは他の開発者に比べ，誠実性が高いが理由は不明
  • survey_1.pdf
    • by the MBTI as "logical and ingenious" はコードレビューのタスクが得意
    • extrovert personality traits(社交性) が effective exploratory testing と相関あり
    • by the MBTI as “sensing and judging” はsoftware testing が得意になるだろう
    • *ソフトウェアテスターに必要なスキルを "big five"の性格特性にマッピング．テスターには開放性と誠実性が大事
    • テストは退屈な作業．若手とベテランではソフトウェアテストに対するモチベーションが異なる．
    • ソフトウェアエンジニアに求められるスキルをMBTI性格タイプと関連づけ，ソフトウェアエンジニアのさまざまな役割に適した性格タイプを提案
    • by the MBTI as "thinking and judging"はソフトウェアエンジニアでは過剰に表現される
    • ソフトウェアテスターはcreative, accurate and strict な人が良い
    • ソフトウェアテスターは間違いを見つける好奇心を持っている悲観的な人が良い
    • ソフトウェアテスターにはcommunication skills, problem solving and team playing capability が大事，また creative and open to new challenges であるべき．

      
      

• What can OSS mailing lists tell us?_0.pdf
  • Peter C. Rigby，Ahmed E. Hassan
  • Fourth International Workshop on Mining Software Repositories (MSR'07)
  • OSS開発者の性格タイプはどのようなものか．
    →ベースラインの開発者たちとは違う性格特性を持つ． 重要なApacheリリースの責任者だった開発者2名は同じような性格特性であり，外交性・開放性が低い(予想外の結果ではない＆結果の妥当確認性がない)

• 言葉や態度がプロジェクトnew,current,departで変化するのか．→Yes
• リリース前後で word usage が違うのか→ LIWCでの有意性なし
• survey_2.key
  • 特定のLIWC dimentions はbig fiveパーソナリティ指標と相関あり

5/22†

DONE†

• 大まかな研究方針を組んだ

4/23†

DONE†

• LIWCスライド
  • LIWC.pdf
• 研究の流れ
  • 研究.pdf

Todo†

• LIWCの理解
• 関連論文読む

4/16†

DONE†

• 関連論文のスライド
  • What can OSS mailing lists tell us?.pdf

Todo†

• 研究テーマの背景，問題点，目的をスライドにまとめる．
• 以前紹介してもらった関連論文を読破する．

3/14†

Todo†

• 日程確認
• Mac配布

研究方針†

• プロジェクトの中心人物数人に着目し，プロジェクト初期から末期までの会話データから人と人の打ち解け方やそのタイミングを分析する．
• プロジェクトからデータを取るにはApacheが一番簡単．
  • Mozilla，Linuxやeclipseはデータを取ることが困難(時間的にも)
  • メイリスから取ってくるのがいいかも

• 話し合いの分析を行なった結果，話しやすい環境であれば的確な指示を出すことができて生産性が向上するまで出せたらいい感じ
• ポライトネスが高いとバグの修正までの時間が長くなる
  • 遠回しな言い回しをするから
  • ポライトネスとネットワークの次数の関係をみるといい感じかも(ほりほりと関連ありそう)
• あるコミュニティに属する、ある条件を満たすユーザの時系列性格分析を行う
  • コミュニティを維持するために必要な条件要素を調査する