研究概要†
OSSプロジェクト（のメンター）が新人を大切にしているか？
- メンタリングの充実度と、新人の定着度の比較
- プロジェクトの品質、持続可能性との関係
研究MTG†
10/29†
やったこと†
StackOverflowから活動を開始した開発者と，GitHubから活動を開始した開発者で，PRのマージされる割合に差があるのか？†
- 方法
下記２つの集団で，提出したPRがマージされる割合に差があるかどうかを，マン＝ホイットニーのU検定（片側検定）で確かめる．
- 最初の活動がStackOverflowでの質問または回答だった開発者集団
- 最初の活動がGitHubでのIssueの投稿，コメント，PR投稿，PRのマージだった開発者集団
- 結果
N=85
いきなりGitHubで活動を始めるよりも，StackOverflowから活動を始めた方が，PRがマージされやすいといえる．
- おまけ
それぞれの集団の，投稿したIssueに他人からコメントされる割合について差があるかどうかを，マン＝ホイットニーのU検定で確かめる．
N=1125
いきなりGitHubで活動を始めるよりも，StackOverflowから活動を始めた方が，Issueにコメントしてもらいやすい．
初心者と熟練者を分けて，上の検定をやる†
- 方法
上の検定で分けた集団について，さらに熟練者の集団，初心者の集団に分けて，同様の検定を行った．
- 熟練者：vscodeでPRを提出するより前に，ほかのリポジトリにPRを提出したことがある開発者集団
- 初心者：vscodeでPRを提出するより前に，ほかのリポジトリにPRを提出したことがない開発者集団
- 初心者(N=10)
サンプルが少なすぎて，そもそも検定がうまくいっていない．
使っているライブラリのリファレンスによると，片方の集団だけでサンプル数が20以上ある必要があるらしい．
次にやること（相談）†
- なぜ，「いきなりGitHubで活動を始めるよりも，StackOverflowから活動を始めた方が，PRがマージされやすい」のか調べる？
StackOverflowで具体的にどんな活動をすると，PRがマージされやすくなるのか？
どのくらいの期間，StackOverflowで活動すれば有意差が出るのか？
- そもそも検定に十分なサンプルが取れているのか？
ほかのプロジェクトのデータも集めてみる．
StackOverflowでの質問数や回答数が多いプロジェクトを探すと，アカウントの紐づけがしやすそう．
10/22†
やったこと†
- 開発者の階層分け
アクティブ開発者の閾値を調整．条件を2つ以上のPRを提出したことのある開発者のみにする．
OTCは1つ以上PRを提出したことのある開発者．
それに伴って階層名も変更．
- 結果
| 階層 | 人数[人] (割合[%]) |
| コア開発者 | 39 ( 0.08) |
| アクティブ開発者 | 480 ( 1.04) |
| One-Time Contributor | 1241 ( 2.66) |
| ペリフェラル開発者 | 44787 (96.22) |
- StackOverflowとGitHubのアカウント紐づけ
- 方法
先週は「josh-ua, joshua」や「leonadler, leon adler」といったアカウントを紐づけるために，
レーベンシュタイン距離を使ってアカウント名の類似度を計算していたが，
空白スペースやハイフンなどの記号なら前処理で除去できるので，
これらを除去したうえで，アカウント名の完全一致を探した．
- 結果
| 階層 | 紐づけられたユーザ数[人] (階層のユーザ数[人]) |
| コア開発者 | 8 (39) |
| アクティブ開発者 | 26 (480) |
| One-Time Contributor | 51 (1241) |
| ペリフェラル開発者 | 1496 (44787) |
次にやること（相談）†
- 紐づけられたユーザのGitHubでの活動履歴と，StackOverflowでの活動履歴を時系列で得る（階層の移動を追跡する）
例. ユーザA
2019/10/20 SOで質問
2019/10/21 GHでIssue立てる
2019/10/22 PR提出
2019/10/23 SOで回答
例. ユーザB
2019/10/20 GHでIssueを立てる
2019/10/21 GHでIssueにコメント
2019/10/22 SOで質問
- 活動履歴を使って何をする？
- SOで活動開始してから，GHで活動開始するまでの期間を得る(ROMってる期間がわかる？)
- タイプ分け？どうやって？
- 考慮すべきこと
- OSS開発初心者と熟練者を分ける．初心者，熟練者の境界は？
10/15†
やったこと
- StackOverflowとGitHubのアカウント紐づけ
- 方法1. StackOverflowのユーザの自己紹介文からGitHubアカウントへのリンクを探す
紐づけられたアカウント数 / SOでvscodeタグ付きの質問またはそれに対する回答をしたアカウント数（割合[%]）
278 / 23,356 (1.19%)
このうち、PRをマージした人、Issue・PR投稿またはそれらにコメントを付けた人はなし。
- 方法2. GitHubのアカウント名とStackOverflowの表示名の類似性（作業中）
GitHubのアカウント名とStackOverflowの表示名のレーベンシュタイン距離が1以下のアカウントを紐づける
（前処理として、それぞれの名前をすべて小文字に変換）
計算の40%が終わった段階で、紐づけができたユーザ数は800人。
この方法で紐づけられた人は、必ずどこかの階層（後述）に現れる。
しかし、PR投稿者の中に紐づけできた人がいるかどうかは現時点では不明。
- 無関係な人も紐づけてしまうことがある
例：ball, bball 目視したところ、全くの別人
かといって、レーベンシュタイン距離が0（まったく同じ名前）の人のみ紐づけると、
「josh-ua, joshua」や「leonadler, leon adler」といったアカウントが紐づけできないので、
Pythonのdifflibを使って文字列の類似性を測った値も併用する。
- 全探索しているのでかなり時間がかかる（3~4日かかる）
レーベンシュタイン距離とdifflibを使った類似性を計算して、DBに保存すれば、1度だけ計算しておけばOK。
また、ボトルネックはDBからデータを取り出すのにかかる時間であることがわかっている。
メモリ節約のためと思って、いくつかデータを取り出し、処理、破棄を繰り返しているので、
大量にデータをDBから取り出して、メモリに展開してから処理したほうが早くなりそう。
- その他の非現実的な方法について
- 自己紹介文の類似性
そもそも自己紹介文を書いてる人が少なすぎる。
- プロフィールアイコン画像の類似性
名前の総当たりだけでも3~4日かかるのに、画像比較なんてやったら・・・
- 開発者の階層分け
以下の4つの階層に分けた。
vscodeの場合、これらの開発者の分布は、
| 階層 | 人数[人] (割合[%]) |
| コア開発者 | 39 ( 0.08) |
| 定期的PR投稿者 | 7 ( 0.02) |
| 不定期的PR投稿者 | 3001 ( 6.00) |
| Issue投稿者, Issueコメント者, PRコメント者 | 46941 (93.90) |
- コア開発者
PRのマージをした人
- 定期的PR投稿者
PR投稿数が5個より多く、最も古いPR投稿から直近のPR投稿までの差が1年より長く、PR投稿の間隔が最低半年に1回以上ある場合
- 不定期的PR投稿者
定期的PR投稿者以外のPR投稿者
- Issue投稿者, Issueコメント者, PRコメント者
10/8†
やったこと
- データ集め
- StackOverflow
sotorrentはいったん放置して、Webスクレイピングの件を作業していた。
vscodeのタグが付いた質問と回答はWebAPIから取得しておいた。
- GitHub
プルリクエストを全部取得。
- データ分析
集めたデータを使ってコメント数の分布をプロットしてみた。
- 相談
- GitHubとStackOverflowのアカウント紐づけについて
とりあえず考えられる方法を試して、どのくらいのアカウントが紐づけられるか試してみようと考えています。
- StackOverflowのプロフィール(APIから取得可能な範囲で)からGitHubアカウントへのリンクを探す
- GitHubアカウントのプロフィールからStackOverflowアカウントへのリンクを探す
- StackOverflowのプロフィールからTwitterアカウントへのリンクを探し、TwitterプロフィールからGitHubアカウントへのリンクを探す（できるかは未調査）
- 2回目質問する割合について
発言のしやすいコミュニティかどうかを調べるのに役に立つ指標ではあるが、1回目の質問で回答がなかった際に2回目同じ質問をしている可能性
1回目と2回目が同じ質問かどうかを、自然言語処理の技術を使って判定できないか（レーベンシュタイン距離みたいな・・・）？
- 開発者の階層分けについて
「Toward an Understanding of the Motivation of Open Source Software Developed」を参考にGitHubでの活動と対応付けしてみた。
- Passive user: ただのユーザ。
- Reader: Issueやソースコードを読む人。
- Bug reporter(, Feature requester←この論文には書いてないけどこれしてる人はいるだろう): バグを発見して報告する。機能拡張の提案をする。Issueを書く人に対応。
- Bug fixer: 自分または他人が報告したバグの修正をする。バグ修正のためにPRを書く人に対応。
- Peripheral developer: 時々新機能を提供する。貢献が不規則。開発に関与する期間は短く散発的。機能拡張のためにPRを書く人に対応。
- Active developer: 定期的に新機能を提供し、バグを修正する。プロジェクトの主要な開発者。コンスタントにPRを書く人に対応。
- Core member: 開発の指導、調整を行う。比較的長い間プロジェクトに関与している。システム開発に大きく貢献した人。PRをマージする人に対応。
- Project leader: プロジェクトのオーナー。プロジェクトのビジョンと全体的な方向性を決める。
- 疑問1: Bug fixerとPeripheral developerを階層分けすべきなのか？（論文ではほぼ違いはないと言いながらも分けて書いてあった）
明記はされていなかったが、Bug fixerは1つのバグをFixするためだけに貢献した人（OTC）に対応していそう？
Peripheral developerは2回以上で貢献がコンスタントではない人に対応？
- 疑問2: issueやPRにコメントする人はどこに対応するのか？
Bug reporterと同じ層？コメントは問題提起よりも難易度が低いからBug reporterより下層？それとも、議論できるほど知識があると考えてBug reporterより上層？
ほかにも階層分けモデルがある？
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]")
