研究概要†
OSSプロジェクト（のメンター）が新人を大切にしているか？
- メンタリングの充実度と、新人の定着度の比較
- プロジェクトの品質、持続可能性との関係
研究MTG†
9/25†
やったこと
- データ集め
- StackOverflow
sotorrentをDLしてmysqlデータベースにインポート中。
あと最低2週間はかかる見込み。
- GitHub(対象のリポジトリはvscode)
issueとissueについたコメントを取得するプログラムを作成中。
GitHub APIの制限に引っ掛からない速度でゆっくりデータ収集。かかっても丸1日。
来週までにやること
- issueのリプライの数/速さを箱ひげ図にプロットする
- リプライの数: 質問や問題があるときにコミュニティの誰かが関心を持ってくれるかどうか
- リプライの速さ: 質問や問題があるときにコミュニティがどれだけ早く解決しようとしてくれるか
- 新人が発言する割合: 新人が発言しやすいメディアかどうか（要相談）
あるユーザの発言があったとき、それ以前に発言したことがないユーザだった場合は、そのユーザの発言は新人の発言とする。
新人が発言する割合 = 新人の発言の合計数 / 全てのユーザの発言の合計数
- StackOverflowからGitHubの開発コミュニティに移動する割合（要相談）
StackOverflowなど（Gitter, Slack, Twitter）のメディアが、新人の開発コミュニティへの参加のきっかけになるかどうかの指標になる。
StackOverflowで質問や回答をした人が、GitHubのissueで議論したり、プルリクを書いたりする割合は？
その中で新人の割合は？逆に新人の中で、過去にStackOverflowに質問や回答をしたことのある人の割合は？
アカウントの紐づけに関する研究がある？
9/19†
やったこと
- Who is Going to Mentor Newcomers in Open Source Projectsを読んだ
新人が求める知識を教えてくれそうなメンターを推薦するツールを作った。
- 考えたこと
- FreeBSDではメンターと新人のペアでのメールのやり取りが少なく、新人がML全体に投げることが多かったらしい
1人または複数のメンターによって1人の新人を教えるだけではなく、コミュニティ全体が新人を支える仕組みがあるといい
- メンターはいらない！1人でやりたい！でもプロジェクトのアーキテクチャと実装の詳細、開発ガイドライン、組織的側面など、貢献に必要な知識は欲しい！
メンターなしで、1人でやったほうが良かったみたいな新人はいない？メンターいると気軽にプロジェクトに参加できないような・・・
メンターはどんなことを新規参入者に教えている？
メンターが必要なぐらいドキュメントが整備されていないプロジェクトってやだな・・・
メンターのやってることを機械が代替できないか？
- そもそもメンタリングすることで新人に対してどんな効果があるのかを研究した論文が読みたい
https://dl.acm.org/citation.cfm?id=1806842
9/12†
やったこと
- 分析対象のリポジトリを選んでみた
2010年以前にGitHubに登録されたリポジトリをfork数で降順ソートして上位5つを選択。
その中から、コントリビュータの数が一番多いrailsリポジトリを選択(2番目と比べて約3倍のコントリビュータがいる)。
- 分析対象のコントリビュータを選んでみた
https://github.com/rails/rails/graphs/contributorsから、コミット数が多い順にコントリビュータを並べたグラフを見て、
リポジトリ登録から2年以降に初めてのコミットがあり、コンスタントにコミットを続けているコントリビュータ上位4名選択。
- 分析対象のコントリビュータのコミットを集めてみた
途中
9/5†
やったこと
- 論文を読んだ
- OSSプロジェクトへの新規参入者のための研究
- Overcoming Open Source Project Entry Barriers with a Portal for Newcomers
OSSプロジェクトの新規参入者をサポートするために作成されたポータルを作成。次の内容を表示する。
貢献を始めるためのステップバイステップのフロー、簡単なタスクのリスト（プロジェクトによって提供されるタグに基づいてフィルターされたタスク）、
プロジェクトに必要なスキル、コミュニティが提供するチュートリアルへのリンク、コミュニティとの対話のためのメッセージテンプレート、
ドキュメントに関連する整理された情報、コーディングスタイルなどのコード関連のドキュメントへのリンク。
65人の学生にポータルを使用してOSSプロジェクト（LibreOffice, JabRef）に参加してもらい、日記、アンケートなどの定性的データから有用性を評価。
- Hipikat: A project memory for software development
タスクに関連するソースコード、ドキュメント、ディスカッション等のアイテムを推奨するツールを作り、新規参入者を支援する。
関連しているアイテム同士にリンクを張り、リンクされているアイテムを推奨アイテムとして表示。
評価は、Eclipse Bugzillaから修正済みバグレポートをサンプリングし、ツールにバグを入力した際に、実際にバグに関連したソースファイルを推奨できるかprecisionとrecallの測定、
Eclipseの過去に完了した機能拡張に関するタスクに取り組んでもらう。その際にツールを使用してもらい、ツールの有用性を確認するためのインタビューを実施。
また、Eclipseの開発メンバー数人にツールを利用せずに同様のタスクに取り組んでもらい、ツールを利用する新規参入者と利用しない熟練者の結果を比較。
- バグレポートの要約に関する研究
- Summarizing Software Artifacts: A Case Study of Bug Reports
バグレポートの要約を正確に行えるかどうかを検討。
7人の大学院生に計36個のバグレポートの要約を作成してもらい、これらを用いて抽出型のサマライザを学習し、学習していないサマライザとのROC曲線と、AUROCの比較。
- Unsupervised Deep Bug Report Summarization
AutoEncoderモデルを使った、抽象型のサマライザを実装。
公開されているバグレポートの要約を使ってサマライザを学習し、precison、recall、F-score、Rouge-Nで以前のアルゴリズムと比較。
- 自分がOSSプロジェクトに参加するのに役立つこと
- これらが分かりやすく示されていると参加しやすい
- 歴史
- 現在抱えている問題、議論と、これらに助けが必要かどうか。問題に関連するソースコードやドキュメント等。
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ドキュメントの要約などの論文を読み、どのような評価が行われているか調べる
- 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†
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
