builderscon2017/OSS貢献超入門
@shigemk2さん
Scala, Hadoop, Reactの人
akix.icon感想
もう今日からやろうという気持ちがわいてきた
密度が濃かった
-.icon
結論
好きなリポジトリをウォッチしよう
対象者
（いろいろ理由があって）したくてもできない、という人
=わりと昔の自分
参加してる
Emacs
cookpad/kuroko2
rundeck
github/hub
OSSとは
概念に基づきソフトウェアのソースコードが無償で公開され、改良や再配布を行うことが誰に対しても許可されているソフトウェアのこと
概念（OSDが提唱している）
10個
OSSの概念を完全に理解していなくても、パッチやバグレポートはできる
厳格に理解しようとするとつらい
（超ゆるい定義だと）Githubなどにソースコードが公開されているソフトウェアはだいたいOSS
You Ain't Gonna Need it!
機能が必要になるまでは追加しない
人力YAGNI
パッチやバグレポを投げてからOSSの勉強するでもアリ
貢献できない理由
どこから手をつけていいか分からない
どんなバグレポやパッチを出せばいいのか分からない
ケーススタディ
ScalaのPlay Framework
ソースコードがGithubに上がってる
上の方にIssue/Pull RequestボタンがあってIssue200個近くある
次のアクションが分からなくて、もうこのままでいいんじゃないかなと思っちゃう
OSS多すぎ
Gemfileとか
開発環境
エディタ/IDE
＋付属するライブラリとかプラグインとか
ログインシェル
特に意識しないと普通に使えちゃう
ググったりQiitaとかStackOverflow見るだいたい解決しちゃう
ソースコードを読んでも分からない
ファイル数多すぎてどこから手を付けるか
時間がなくて無理
こういうのは業務外？
時間と気力は限られている
技術的に無理
出来ない理由を片付けていく
＊どこから手を付けていいか分からない☞
理由付けが必要
プログラマーとしての成長のため
バグとかドキュメントを直すため
欲しい機能を追加するため
パッチが取り込まれるのが嬉しい
自分の思うとおりにOSSを作り替えていく
具体的なアクション
機能追加
バグ修正
リファクタリング
ドキュメント編集
ドキュメント翻訳
必要性がないと動かないので、必然性を高めよう
公式ドキュメント/ソースコードを読む
StackOverflowやQiitaは使わない
マイナス検索を使う
使ったとしても副読書程度で
Google検索-stackoverflow -qiitaの理由
最新性
正確性
に問題がありがち
あくまでハマった時のソリューションなので本家で何が問題になってるか分からなくなる
心構え
公式が間違ってるかもしれない説と、自分が間違ってる説を半々ぐらいで持ちながら開発する
＊ソースコードを読んでも分からない☞
雰囲気をつかもう
なぜ？ -> 他の人が何をやってるか分かるから
OSSの開発の雰囲気をつかむためにとても参考になる本
様々なアセンブリ言語をフィーリングで読む本
熱血バイナリアン十訓
☞OSSのソースコードを読むのにとても参考になる
何を読むべきか
左側ペインがリポジトリベースの部屋
READMEにgitterのボタンがあれば入ってみる
gitterにはアプリもある
CodeHubとかGHFeed
アプリは微妙に使いづらいことが一長一短
両方入れて交互に見る
メーリングリスト
いつ読むか
休憩時間
通勤時間
寝る前
ビルド時間
その他空いている時間
ポイント
雰囲気で読む
分からなくても気にせず読む
飽きたら別のリポジトリをwatchする
毎日読む
Linux/Emacsのメーリングリストは毎日数百数千とかメールが来てる
メーリス購読でGmailの容量が死ぬ
PrestoとかElasticSearchhとかは毎日すごい数のissue/prが飛んでる
通知をONにしよう辛いけど
得られる雰囲気
どんなissue/ prを出しているか
どんな文章をどう書いているか
フォーマット無視してる人がいたりする
どんなコードを書いているか
真似する際にすごく参考になる
すごく参考になったブログ
時間について
帰ったらすぐやる
時間とやる気を捻出する
仕事の時間や昼の休憩時間を使う
技術的に無理
すべてを理解しようと思わなくていい
修正したい箇所を重点的に
find-grep/検索
最低限CONTIRIBUTEページは読もう
どういう風に書いて良いか分からない場合
☞ 他の人が書いたソースコードを参考にしよう
分からない関数や処理が分かる
純粋に勉強になる
テストコードを読んで挙動を知る
テストコードすら無いリポジトリはいったん置いておく
動きが分かる
API実行時のparamsが分かったりする
ケーススタディ
歴史と伝統のある大きなOSS
emacs
問題
zshファイルのsh-modeが起動しない
shmode自体はzsh対応済み
以前は自分のinit fileに書いていた -> 書きたくなかったのでpullreq投げた
やったこと
contribute emacsでググった
sh-modeのwikiを調べる
るびきち氏にメルマガ経由で確認した
「出してもいいですかね？」「いいんじゃない？！」
苦しいポイント
Githubじゃなくてメールベース
最近出来た新興のOSS
RUN DECK
gradleで書かれている高機能cron
「リンク切れ修正しました」☞こんなもんでもいい
ドキュメント修正も貢献
Kuroko2
GUIベースのジョブスケジューラ
問題点
ドキュメントにない機能の存在
☞ pullReqなげた
kuroko2にはないDSL
cho, retry, if-else
☞ オペレータを追加するpullReq投げた
ドキュメントをなぞっても環境構築できない
≒なにもしてないのに壊れた
下準備
ドキュメント側で指定しているバージョンで試す
エラーログを読んでソースコードを読む
☞ ソースコード側に起因するものならバグ
Rails5対応してなかったっぽい？
おまけ
開発前にコード読んでてtypo見つかったらpullreq出せた
新しめのOSSはContribution pointが多い
全然開発されていないOSS
google-translateというemacs lisp
やったこと
出力先にポップアップ・エコー領域に加え、「今のバッファ」を追加した
問題点
自分より前のコミットが半年前
Pull Requestを投げても放置されるパターン
アプローチ
@作者でGithubにコメント
@ツイート
メールアドレスに直接メール
何もしない
forkして自前で開発をすすめる
おまけ
PullReq前にTravisCIがコケてた
テスト修正のやつも投げた
まとめ
雰囲気をつかむのが重要
毎日続けることが重要
ドキュメントとソースコードを読むこと
守破離の守