寄付窓口はこちら

オープンソースコミュニティをスケールさせる | try! Swift Tokyo 2017 #tryswiftconf Day2-14 聞き起こし

twitter.com

オープンソースプロジェクトのさまざまな段階についてお話しします。どのようにプルリクエストを処理するか、規模に応じてどのようにサポートを変えていくか、ユーザー数が拡大していく中でどのように革新を起こしつづけるかをお話しします。 それらを念頭に置き、開発者がどのように問題を解決するのか、具体的にはワークフローの自動化、コントリビュータとの密接な関わり合い、プロダクトやドキュメントの改善について詳しく説明します。 おととしfastlaneで多くのことを学びました。オープンソースコミュニティのスケーリングについていくつかブログを準備しはじめました。

オープンソースコミュニティをスケールさせる

f:id:niwatako:20170303172829j:plain

Twitterで仕事していてFastlaneを担当しています。

fastlaneミートアップが有りましてカッコいいTshirtを入手しましたありがとう御座います。

f:id:niwatako:20170303172913j:plain

Googleのサイドプロジェクトとしてfastlaneに着手しました。

0から立ち上げて何万というユーザーになりました。OSSの段階をお話します。

f:id:niwatako:20170303172941j:plain

Githubの40%はインタラクションがありません

プルリクエストなどが来るようになります

f:id:niwatako:20170303173006j:plain

Twitterで推奨されたりカンファレンスで発表されたりします

f:id:niwatako:20170303173019j:plain

f:id:niwatako:20170303173055j:plain

私はラッキーで4つの段階を経験できました。2年間いろんなことを学びましたが人間的な要因について学ぶことができました。

インパクトを与えるか、どうサポートできるか。

f:id:niwatako:20170303173141j:plain

大きくなると初期のイノベーションが難しくなります。

機能を変えたりデフォルト値を変えたりできなくなります。

f:id:niwatako:20170303173204j:plain

プロジェクトの仕事よりもユーザーサポートの時間。テキストエディタよりユーザーに2倍向き合っているということを表しています。

f:id:niwatako:20170303173233j:plain

GithubのIssueをクローズすると文句を言われるので別のサイトを用意したほうが良いかもしれません。

f:id:niwatako:20170303173309j:plain

f:id:niwatako:20170303173320j:plain

f:id:niwatako:20170303173332j:plain

くだらない、ビジョンに合わない要望を断る際に、正当化出来る必要があります。

f:id:niwatako:20170303173339j:plain 壊れたら自分が治すことになります。Issueをレビューすることはコードを書くのと同じくらい考えます。

f:id:niwatako:20170303173427j:plain

メンテナーがユーザーではなくなってしまう事が起きます。

ここでのチャレンジは何らかの形で困っていることを肌で感じ、期間配分をすることです。

f:id:niwatako:20170303173516j:plain

たまに利用するようにしましょう。

f:id:niwatako:20170303173527j:plain

Issueは多くのIssueの中の1つです。しかしユーザーにとっては自分のすべてです。

WWDCでしばらく前のIssueについて話をされたのが最初の体験でした。

f:id:niwatako:20170303173617j:plain

まずエラーメッセージを改善することです。どんなに優れたソフトでもクラッシュはあります。エラーをどう表示するかが大事です。

Fastlaneでは異なる2つの表示をしています。

最初はStackTraceをすべて表示していましたが、これは情報が多すぎたようです。

f:id:niwatako:20170303173656j:plain

エラーメッセージを赤で表示し、StackOverFlowへのリンク、再現するコマンドを表示しました。

f:id:niwatako:20170303173712j:plain

次は簡単に問題を得られるようにすることです。

エラー発生時点で解決方法を見つけられるようにすべきです。

f:id:niwatako:20170303173812j:plain

これによってユーザーは簡単にGithubの情報を探せる。

私はボットなどは好きではありませんが、規模が大きくなると何らかの方法で自動化が必要です。

f:id:niwatako:20170303173832j:plain

バグレポートはソフトウェアエンジニアでもすべての情報を適用することは難しいです。

ユーザーがIssueを報告する時かなりの情報が欠落しています。

必要な情報がもれなく表示されるようにします。

そうでなければ入手方法が分かるようにしています。

f:id:niwatako:20170303173942j:plain

f:id:niwatako:20170303173948j:plain

似たようなIssueが来るなら根本的な問題やドキュメントを改善します。

10のユーザーがIssueを出すと多くのユーザーが同じように感じているのかもしれません。

Appleでしか解決できないCodeSiginingについての問題にガイドを書きました。

Issueをとにかく前にすすめることが大事です。

Appleのバグレポートで2年後に最新のOSを使えと言われるだけならイライラするでしょう。

f:id:niwatako:20170303174121j:plain

応答がない場合はもう必要なくなっているかもしれません。

f:id:niwatako:20170303174142j:plain

Issueに2ヶ月変更がないと、問題が完了しているのかボットが聞いてきて、誰も何も言わないとIssueがクローズされます。さらにその1ヶ月後にはロックされます。

何故ロックすべきか。

古いリリースのものからIssueが出てくることを避けることができます。

全く関係ないことを言ってきたり、不要なemail通知を発生させてしまったり。

f:id:niwatako:20170303174321j:plain

bot導入で700から300にOpenチケットを減らすことができました。

f:id:niwatako:20170303174327j:plain

大半のIssueはCIが前テストが合格していることをチェックしているが、テストだけでどのようにして変更が入ったかわからないわけです。Ortaを使うことであるファイルが変わった時にWarningを出すとか、20のコードラインが入ったならテストを要求することができます。

誰かがPullRequestを出す、ビルドがうまくいかない、AuthorがPRをアップデートしない、TestがFailしたら通知が行かない http://Danger.systemを使うことで解決できる。

f:id:niwatako:20170303174524j:plain

大きなOpenSourceプロジェクトではVision.comを使ってビジョンを共有するようにしている。 コミュニティが増える、ということに安全な環境が必要です。コーディング規約が必要です。mono repoでなければすべてのリポジトリと依存性に問題がないかチェックをしています。

コードベースが複雑になるほど貢献できる人も少ない。

できるだけフレンドリーに、IssueやPRにはまず感謝を伝える。多くのフィーチャーやアイディアにNoと言わなければならないが、ユーザーがソフトを拡大できる様々な方法を取ることができます。CocoaPods, Bundlerなど。

f:id:niwatako:20170303174741j:plain

f:id:niwatako:20170303174742j:plain

StaticなValueを使うとか、Webサービスなどの外部の絵ソッドを利用できる

拡張時にコードに触ること無くやることが有ります。

デベロッパーのコミュニティを大きくしてプラグインで拡張できるようにします。

本体がスリムになってPRも減るかもしれません。そしてすでにある依存性を排することが出来る。

OSSの拡張は難しくいろいろな課題がある。

問題に対処しなければいけないのは一人の人ではなく多くの人が助けてくれる。

コミュニティなしでは今の状況は作れませんでした。

長く続くOSSもあるので、全世界のデベロッパーにインパクトを与えられます。

Q&A

メンテナンスしていないライブラリは有りますか?そういうものはどうしていますか?

宣言して、だれかにメンテナンスを引き継ぐ。透明性を持って引き継ぐ。