ふじこ/修士論文 の履歴(No.6)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• ふじこ/修士論文 へ行く。
  • 1 (2010-11-12 (金) 02:21:56)
  • 2 (2010-11-12 (金) 02:21:56)
  • 3 (2010-11-13 (土) 06:59:54)
  • 4 (2010-11-13 (土) 06:59:54)
  • 5 (2010-11-29 (月) 07:47:30)
  • 6 (2010-12-05 (日) 04:38:39)
  • 7 (2010-12-05 (日) 04:38:39)
  • 8 (2010-12-05 (日) 04:38:39)
  • 9 (2010-12-05 (日) 04:38:39)
  • 10 (2010-12-25 (土) 06:30:21)
  • 11 (2011-02-05 (土) 04:02:32)
  • 12 (2011-02-16 (水) 03:17:05)

---

ふじこ

修士論文†

修論関連日程†

論文審査書類提出期限：2月3日(木)17時

修論構成(未完成)†

• はじめに
  • 研究背景
  • 関連研究

• OSS開発におけるパッチレビュープロセス
  • パッチレビューの流れと開発者の役割
  • 遅延の実態
  • 遅延を解消させるための方法
    • コミッター選出のための調査(昇格前のコミッターと非コミッターを比べる)
    • 現状のコミッターのタイプの調査(各コミッターの昇格前と昇格後のactivityを比べる)
      ３章以降で使う言葉を匂わせる（もしくは定義する）ような説明をする

• 分析
  • ○○のためのhoge hoge
    • コミッター選出のための調査
      　　パッチ投稿に関する分析(パッチ投稿数（月平均）・パッチ編集時間・パッチ品質)
      　　レビューに関する分析(レビュー数（月平均）・レビュー時間)
    • コミッターの分類調査
      　　パッチ投稿に関する分析(パッチ投稿数（月平均）・パッチ編集時間・パッチ品質)
      　　レビューに関する分析(レビュー数（月平均）・レビュー時間)
  • 分析方法
    • データの取得
      (Bugzilla)
      (Source Code Repository (commit log))
    • データ整形
    • 手順

• ケーススタディ
  • 対象プロジェクト
  • 基本統計量

• 分析結果
  • コミッター選出のための調査結果
  • 現状のコミッターのタイプの調査結果

• 議論
  • 考察
  • 制約

• おわりに
  • 結論
  • 今後の展望

• 謝辞

• 参考文献

• 付録
  • 100プロジェクト分（仮）の分析結果詳細

スケジュール†

11月30日

• 個別MTG
  • 分析：10プロジェクトDONE

12月3日

• OSS班MTG
  • 分析：30プロジェクトDONE，品質の定義に関する予備調査DONE
  • 修論：目次完成
  • IWESEP：ポスター第１稿

12月6日

• IWESEP：ポスター完成

12月7日

• IWESEP Poster発表

12月8日

• 個別MTG
  • 分析：50プロジェクトDONE
  • 修論：分析項目・分析方法　第１稿

12月15日

• 個別MTG
  • 分析：100プロジェクトDONE
  • 修論：はじめに・OSS開発におけるパッチレビュープロセス　第１稿

12月22日

• 個別MTG
  • 分析：100プロジェクトDEADLINE
  • 修論：ケーススタディ・分析結果・議論　第１稿

12月29日

• 個別MTG？
  • 修論：全章埋めた状態　第１稿

1月5日〜

• 修論修正

1月12日

• 修論：第2稿

1月19日

• 修論：第3稿

1月26日

• 修論：完成

1月27日

• 修論が完成した状態で24歳を迎える

1月28日〜

• 修論最終チェック・微調整
• OSS原稿執筆

2月*日

• 修論提出日

2月**日

• 修論発表

2月20日

• OSS原稿〆切

対象プロジェクト†

対象プロジェクトのリスト: OSS_Bookmarks.csv

参考文献†

• Design Principles for Developer-Centered Collaborative Software Development Environments
  • 論文PDF: [添付]
    • Historical Contextにおいてソフトウェア開発に関する研究の着目点によって３つのパターンに分類している
    • 自分の研究は「School1：熟練者と初心者の違いに着目する研究域」に該当している

• Small Patches Get In!
  • 論文PDF: [添付]
    • FLACとOpenAFSを対象に，パッチの行数とアクセプト率を分析
    • 行数が小さいほどアクセプトされやすい
    • アクセプトされるまでの時間も調べたが，行数とは関係がなかった

• Detecting Patch Submission and Acceptance in OSS Projects
  • 論文PDF: [添付]
    • パッチのアクセプト判定アルゴリズムの提案
    • パッチの差分情報がリポジトリ内の対象ファイルのリビジョン情報に含まれていたらアクセプトと判定

• The Organization of Open Source Communities: Towards a Framework to Analyze the Relationship between Openness and Reliability
  • 論文PDF: [添付]
    • Reliabilityの定義とOpennessの要素
    • Reliability：指定された時間内に，要求された機能をエラーなく動作する確率
    • Openness：誰でもソースコードへアクセスできる．コミュニティ内の開発者がアイデアを共有できる．誰でもコミュニティ内の開発者が何をしているのか見ることができる．コミュニティ内と外の人の間に壁は存在しない．

• Role Migration and Advancement Processes in OSSD Projects: A Comparative Case Study
  • 論文PDF: [添付]
    • Apache, Mozilla, NetBeansを対象に，開発者の役割と昇格プロセスについて分析
    • 昇格プロセスとパッチレビュープロセスを一緒に説明しているモデル図がある

• Understanding the Process of Participating in Open Source Communities
  • 論文PDF: [添付]
    • MySQL, OpenOffice.org, GNOMEを対象に，不具合修正プロセスにおける開発者の特徴を調査した．
    • OOo(writer)，GNOME(GTK+)どちらにおいても，時間とともにコミッター総数が増えるが，アクティブコミッター（毎月コミットを行っているコミッター）の総数はほぼ一定であった

• Two Case Studies of Open Source Software Development: Apache and Mozilla
  • 論文PDF: [添付]
    • Apache, Mozilla，商用ソフトウェアを対象に，以下の点について分析した
    • 開発プロセス，コア開発者の活動，Code ownership，欠陥密度，解決時間

• The Role of Patch Review in Software Evolution: An Analysis of the Mozilla Firefox
  • 論文PDF: [添付]
    • Mozillaにおけるパッチレビュープロセスの詳細を分析
    • Module owner, Peer, Developerの役割と関係を提示
    • レビュープロセス効率化の一例として，「パッチへのRubber stamping(review+)」によるレビューのスキップがあげられている
    • パッチのアクセプト率は53.55%

その他†

コメント: