堀口 の履歴(No.17)

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

---

研究概要†

要旨†

• 企業発オープンソースプロジェクトのコミュニティネットワークについて、その構造と統計量の時系列データの変化と、プロジェクトの品質（バグの量、保守性、機能の数とか？）の時系列データの変化を見て、どんなコミュニティ構造や統計量が、プロジェクトの品質に良い/悪い影響を与えるのか調べる。
• コミュニティネットワークの分析においては、企業の開発者とコミュニティの開発者の区別や、周辺的な参加者と中心的な参加者を区別したコミュニティ構造と統計量（企業の開発者の人数、コミュニティの開発者の人数、人数の割合）を盛り込むことで、新規参加者が、周辺的な参加者から中心的な参加者に役割を変化していく様子も捉える。
• 企業発オープンソースプロジェクトの品質向上に向けたコミュニティの設計に貢献できる。

新しい点†

• 企業発オープンソースプロジェクトに着目して、コミュニティネットワークの変化とプロジェクトの品質の変化の関係を調べる
• 企業の開発者とコミュニティの開発者や周辺的な参加者と中心的な参加者を区別した統計量を使う

関連研究†

• OSSコミュニティの時間に伴うコミュニティネットワークの変化に着目した分析
  「OSS コミュニティにおけるオープンコラボレーションの理解」より

ToDo:†

• リサーチクエスチョンを決める
  Yes/Noで答えられる形式にすると分かりやすい。
  まずは研究の目標を決め、それに対して結論が出せるような質問（RQ）を設定する。
  組織がスポンサーをする動機について調べる→組織は何がしたいのか
  個人がOSSコミュニティに参加する動機について調べる→個人は何がしたいのか
  これが分かれば、この研究では組織、個人がしたいことについて、どのように貢献できるかが明らかになる。
  

• ネットワーク全体のSNA、ネットワーク自体の性質を調べる
  • クラスタリング係数　→　
  • 平均経路長　→　コミュニティのサイズがわかる
  • 次数分布　→　
  • モジュラリティ
  • コミュニティ中心性
• コミュニティ抽出法を使う
  • 抽出したコミュニティの性質を見る
  • 抽出したコミュニティごとの分析
• スポンサー付きオープンソースプロジェクトに関する既存研究から、歴史の長いプロジェクトを見つける
• 論文を読む
  • The Emergence of a New Commercial Actor: Community Managed Software Projects

研究MTG†

8/20†

やったこと

• An Empirical Study of Long Lived Bugsを読んだ
  長期間解決されないバグについての分析。
  すぐ解決されるバグに比べて特筆すべき特徴や傾向はなし。
  ソフトウェアのクラッシュやデータの損失など、重大なバグの中にも放置されているものもあった。
  
• オープンソースプロジェクトに参加してみようとした
  
  • 現在の開発状況が分かりにくい（どこまで作業が完了していて、今何を議論していて、何をやろうとしているのかわかりにくい）
  • Slackなどの縦に流れるチャット履歴を追うのがしんどい
• PRを送ってみた
  issuehuntでお金が着いているissueの中で、good first issueのラベルが付いているissueに取り組んだ。
  単純な修正だったので即承認してもらえたが、プログラムを考える時間よりも、ドキュメントや周辺のソースコードを読むのに時間がかかった。
  

次のMTGまでにやること

• 自分がコミュニティに参加するのに役立つようなことを考える
• コミュニティの履歴やチャンネルでの議論の可視化、要約
  • どんな要約があったらいいかを考える
  • 既存の可視化、要約技術について調べる
    • CodeCity: モジュールを街(建物)に見立てて可視化
    • Gource: プロダクトを開発者が作り上げる過程を可視化
• issueの難易度の推定
  • 開発者の実績を基にバグをアサインするバグトリアージに近い？
  • good first issueラベルを使う
  • 素人とエキスパートの解決するissueの違いについて調べる

• 論文を読む
  • SocialBarrier関連で初心者向けに要約を行う論文がある
    • Overcoming Open Source Project Entry Barriers with a Portal for Newcomers
  • APIドキュメントの要約などの論文を読み、どのような評価が行われているか調べる
    • A free Web API for single and multi-document summarization
    • Generating query-specific class API summaries
  • 素人と熟練者が取り組んだissueやコードの違いを比較した論文がないか調べる

8/7†

やったこと

• どんなOSSを対象にした研究がしたいか考える
  
  • 開発者は完全にボランティア
    例: Apache
    Apacheは財団があるが、開発者は完全なボランティアで、財団からの給料は出ていない。
    他の会社に勤めていて、かつApacheのOSSにフルタイムで開発にあたっている人もいるかもしれないが。
    TODO: Linuxカーネルとかディストリとかはどうなんだろう？
    
  • コア開発者がフルタイムで開発にあたっている
    つまり、コア開発者はそれを本業の仕事として給料をもらい、生計を立てているようなOSS
    例: React(Facebook), TensorFlow(Google), VSCode(Microsoft), etc.

• 研究対象のOSS開発者がどういった問題を抱えていそうか調査してみる
  コア開発者がフルタイムで開発にあたっているOSSであるvscodeについて、issue、PRで、更新が古い順かつ、開いているものを5つ程見てみた
  • issue
    • 一番古いのは4年前
    • MS社員が担当者の任命やラベル付けはしているが、コメントがない
    • 議論がされているものの、結論が出ていない。途中で止まっている
  • PR
    • 一番古いのは2年前
    • 社員にケチをつかられて、PRを立てた人が追加の変更をしないまま放置
    • PRを立てた人が実装を途中であきらめた
    • 社員によるレビューが何回か行われているのに、途中で行われなくなった（理由は謎）
    • issueに基づくPRではあるが、プランに含まれていないという理由で1年以上Backlogに放置（issueの方もオープン状態）
  • その他issueとPRを見てて分かったこと
    • issueのコメントでいろんなユーザが「はよこの機能追加してくれ」と言っているが社員のレスポンスがないものがあったりする（issueの参加者は65人）

来週までにやること

• 研究対象のOSS開発者がどういった問題を抱えていそうか調査してみる(継続)

7/25†

やったこと

• 以下の論文を流し読みしました
  • Two case studies of open source software development: Apache and Mozilla
    上位15名の開発者が、コード生成への貢献の約80%を占めていることがわかった。
    コア開発者は新機能の開発、ペリフェラル開発者はバグ修正を主なタスクとしていることがわかった。
    
  • Who Gets a Patch Accepted First? Comparing the Contributions of Employees and Volunteers
    ボランティアは従業員よりも26倍多くrejectされていることがわかった。
    プルリクが作られてからマージされるまで、従業員は2日なのに対して、ボランティアは11日かかっていることがわかった。
    
    • 気になったこと
      時間がかかると貢献から遠のいてしまうのではないか？
      ボランティアが遠のくと、OSSの品質（細かなバグ）に影響が出るのでは？
      パッチ受け入れとOSSの品質に関係する論文を探す

• その他気になっていること
  • OSSを収益化すれば、OSSが廃れる？
    社会規範から市場規範へ切り替わることで問題は発生するのか？
    OSSの持続可能性を高めるため, OSSを収益化する動きがある.
    
    • GitHub Sponsors(GitHub, Inc.): 5000ドルばらまくキャンペーン
      GitHubのOSS開発者への寄付が可能.
    • Issuehunt(BoostIO, Inc.): 資金調達1億円
      Issueに報酬を設定し, PRが承認されれば報酬を得る.
    • Beerpay
      オープンソースプロジェクトへの寄付が可能.
    • Dev(FRAME00, Inc.):
      オープンソースプロジェクトに対して毎月仮想通貨を配布.

• これによる問題
  OSSコミュニティに市場規範が持ち込まれると, 今まで金銭的見返りを求めずに貢献されていたものに対して, 対価を求めるようになるのではないか？
  今までは非金銭的な動機でOSSに貢献していたのが、金銭的な動機に切り替わるのか？
  金銭的見返りのないコミュニティ（社会規範のコミュニティ）に, 優秀な貢献者が来なくなる？金銭的見返りのないコミュニティが廃れていくのでは？
  市場規範: 金銭的なつがりを基に価値判断される世界の規範. 賃金を払う. 対価を求める 社会規範: 社会的なつながりを基に価値判断される世界の規範. ギフト経済. 金銭的見返りを求めない
  

来週までにやること

7/18†

やったこと

• 以下の論文を流し読みして、オープンソースプロジェクトの新参者に関する研究について少しわかってきた
  • オープンソースプロジェクトへ初めて参加する際の社会的障壁に関する論文
    • Socialization in Open Source Software Projects A Growth Mixture Modeling Approach
    • Social Barriers Faced by Newcomers Placing Their First Contribution in Open Source Software Projects
  • One-Time Contributorsに関する論文
    • One-Time Contributors to FLOSS Surveys and Data Analysis
    • Understanding the impressions, motivations, and barriers of one time code contributors to FLOSS projects a survey
  • 読んでて気になったこと
    そもそもコア開発者とペリフェラル開発者の割合ってどのくらい？One-Time Contributorの割合は？どれくらい貢献してる？
    昨日それっぽい論文見つけたので来週までに読んできます
    

来週までにやること

• コア開発者やペリフェラル開発者について知るため
  • https://dl.acm.org/citation.cfm?id=567795
  • More Common Than You Think: An In-Depth Study of Casual Contributors
    コア開発者、ペリフェラル開発者の割合、ペリフェラル開発者が実際どの程度役に立っているのかわかりそう。
  • How does contributors involvement influence open source systems
    コア開発者、ペリフェラル開発者によって投稿されたパッチのビルドの成功率の比較。ペリフェラル開発者が投稿するパッチの質が分かりそう。
• めっちゃ読みたい論文
  Who gets a patch accepted first?: comparing the contributions of employees and volunteers
  企業のオープンソースプロジェクトにおいて、従業員の開発者とボランティアの開発者の提出したパッチの受け入れに関する違いについて調査した論文。
  ボランティア開発者が何かしらの問題に直面してそう。
  

6/17†

やったこと

• CytoscapeのAPI機能を利用して、ネットワークの図の作成を自動化した
• GitHubから適当なリポジトリを選んで、Cytoscape Core AppsのNetwork Analyzerを使って分析してみた（結果を見せる）

問題点

• CytoscapeのNetwork Analyzerは機能が限定的で、かゆいところに手が届かない
  ⇒ pythonのSNAライブラリNetworkXに移行する

進行中

• issueやissue_commentの数が多いリポジトリのからのデータの取得
• issueやissue_commentの数が多いリポジトリからネットワークを抽出する

6/10†

やったこと

• GitHub APIから特定のリポジトリの全てのissue(open and closed)とそれに対応するcommentを取得する
• issue投稿者とcomment投稿者のノードを作り、コミュニケーションをとった人同士でエッジを作って、1か月ごとにDBに保存する

6/3†

やったこと

• 研究概要を考える

5/23†

やったこと

• The Role of Participation Architecture in Growing Sponsored Open Source Communitiesを読んでいます。
  

5/7†

やったこと

• グラフ描画のツール作成
• 「Contrasting Community Building in Sponsored and Community Founded Open Source Projects」を読んだ
  アメリカ合衆国退役軍人省の医療情報システム(public domain)を分析して、 コミュニティ主導のオープンソースプロジェクトとスポンサー付きのオープンソースプロジェクトの主要な課題を明らかにした。
  スポンサー付きのオープンソースプロジェクトでは、健全なコミュニティの構築、優秀なコントリビュータを惹きつけること、所有権とコントロールに関する曖昧さの解決、つまり、スポンサー付きのオープンソースプロジェクトでは所有権とコントロールに関することが曖昧になるということが課題であると述べていた。

4/18†

やったこと

• mysqlの設定を変更して、ghtorrentのデータをにインポートを高速化した
  今のペースだと最低1か月以上かかるので、
  日別に分割されたmongoのダンプファイルが公式から出てるので、これを使ってみる？

• 「Two Case Studies of Open Source Software Development: Apache and Mozilla」の一部を読んだ
  アブストラクトとイントロダクションのRQの部分を訳した。
  この論文が何を明らかにしようとしているのかは分かった（多分）。
  

Templates†

• 添付
  [添付]