オープンソースプロジェクトのさまざまな段階についてお話しします。どのようにプルリクエストを処理するか、規模に応じてどのようにサポートを変えていくか、ユーザー数が拡大していく中でどのように革新を起こしつづけるかをお話しします。 それらを念頭に置き、開発者がどのように問題を解決するのか、具体的にはワークフローの自動化、コントリビュータとの密接な関わり合い、プロダクトやドキュメントの改善について詳しく説明します。 おととしfastlaneで多くのことを学びました。オープンソースコミュニティのスケーリングについていくつかブログを準備しはじめました。
オープンソースコミュニティをスケールさせる
Twitterで仕事していてFastlaneを担当しています。
fastlaneミートアップが有りましてカッコいいTshirtを入手しましたありがとう御座います。
Googleのサイドプロジェクトとしてfastlaneに着手しました。
0から立ち上げて何万というユーザーになりました。OSSの段階をお話します。
Githubの40%はインタラクションがありません
プルリクエストなどが来るようになります
Twitterで推奨されたりカンファレンスで発表されたりします
私はラッキーで4つの段階を経験できました。2年間いろんなことを学びましたが人間的な要因について学ぶことができました。
同インパクトを与えるか、どうサポートできるか。
大きくなると初期のイノベーションが難しくなります。
機能を変えたりデフォルト値を変えたりできなくなります。
プロジェクトの仕事よりもユーザーサポートの時間。テキストエディタよりユーザーに2倍向き合っているということを表しています。
GithubのIssueをクローズすると文句を言われるので別のサイトを用意したほうが良いかもしれません。
くだらない、ビジョンに合わない要望を断る際に、正当化出来る必要があります。
壊れたら自分が治すことになります。Issueをレビューすることはコードを書くのと同じくらい考えます。
メンテナーがユーザーではなくなってしまう事が起きます。
ここでのチャレンジは何らかの形で困っていることを肌で感じ、期間配分をすることです。
たまに利用するようにしましょう。
Issueは多くのIssueの中の1つです。しかしユーザーにとっては自分のすべてです。
WWDCでしばらく前のIssueについて話をされたのが最初の体験でした。
まずエラーメッセージを改善することです。どんなに優れたソフトでもクラッシュはあります。エラーをどう表示するかが大事です。
Fastlaneでは異なる2つの表示をしています。
最初はStackTraceをすべて表示していましたが、これは情報が多すぎたようです。
エラーメッセージを赤で表示し、StackOverFlowへのリンク、再現するコマンドを表示しました。
次は簡単に問題を得られるようにすることです。
エラー発生時点で解決方法を見つけられるようにすべきです。
これによってユーザーは簡単にGithubの情報を探せる。
私はボットなどは好きではありませんが、規模が大きくなると何らかの方法で自動化が必要です。
バグレポートはソフトウェアエンジニアでもすべての情報を適用することは難しいです。
ユーザーがIssueを報告する時かなりの情報が欠落しています。
必要な情報がもれなく表示されるようにします。
そうでなければ入手方法が分かるようにしています。
似たようなIssueが来るなら根本的な問題やドキュメントを改善します。
10のユーザーがIssueを出すと多くのユーザーが同じように感じているのかもしれません。
Appleでしか解決できないCodeSiginingについての問題にガイドを書きました。
Issueをとにかく前にすすめることが大事です。
Appleのバグレポートで2年後に最新のOSを使えと言われるだけならイライラするでしょう。
応答がない場合はもう必要なくなっているかもしれません。
Issueに2ヶ月変更がないと、問題が完了しているのかボットが聞いてきて、誰も何も言わないとIssueがクローズされます。さらにその1ヶ月後にはロックされます。
何故ロックすべきか。
古いリリースのものからIssueが出てくることを避けることができます。
全く関係ないことを言ってきたり、不要なemail通知を発生させてしまったり。
bot導入で700から300にOpenチケットを減らすことができました。
大半のIssueはCIが前テストが合格していることをチェックしているが、テストだけでどのようにして変更が入ったかわからないわけです。Ortaを使うことであるファイルが変わった時にWarningを出すとか、20のコードラインが入ったならテストを要求することができます。
誰かがPullRequestを出す、ビルドがうまくいかない、AuthorがPRをアップデートしない、TestがFailしたら通知が行かない http://Danger.systemを使うことで解決できる。
大きなOpenSourceプロジェクトではVision.comを使ってビジョンを共有するようにしている。 コミュニティが増える、ということに安全な環境が必要です。コーディング規約が必要です。mono repoでなければすべてのリポジトリと依存性に問題がないかチェックをしています。
コードベースが複雑になるほど貢献できる人も少ない。
できるだけフレンドリーに、IssueやPRにはまず感謝を伝える。多くのフィーチャーやアイディアにNoと言わなければならないが、ユーザーがソフトを拡大できる様々な方法を取ることができます。CocoaPods, Bundlerなど。
StaticなValueを使うとか、Webサービスなどの外部の絵ソッドを利用できる
拡張時にコードに触ること無くやることが有ります。
デベロッパーのコミュニティを大きくしてプラグインで拡張できるようにします。
本体がスリムになってPRも減るかもしれません。そしてすでにある依存性を排することが出来る。
OSSの拡張は難しくいろいろな課題がある。
問題に対処しなければいけないのは一人の人ではなく多くの人が助けてくれる。
コミュニティなしでは今の状況は作れませんでした。
長く続くOSSもあるので、全世界のデベロッパーにインパクトを与えられます。
Q&A
メンテナンスしていないライブラリは有りますか?そういうものはどうしていますか?
宣言して、だれかにメンテナンスを引き継ぐ。透明性を持って引き継ぐ。