"Being a Good OSS Contributer"を簡単に訳しました。 #phpmatsuri 参加報告に代えて

48JIGEN Reloaded

"Being a Good OSS Contributer"を簡単に訳しました。 #phpmatsuri 参加報告に代えて

2012/11/05

このプレゼンテーションは、Symfonyで活躍しているOSSデベロッパのFabien Potencier、Ryan WeaversやLukas Smithなどの有名なOSSデベロッパを引き合いに出しながら、彼らの多大な貢献が永遠に続くことを期待するなと説いています。

英語が十分に聞き取れないせいでダスティンの話の半分くらいしか理解できてませんでしたが、心が動かされました。熱意を持って語りかけてくれたダスティンに感謝をこめて、簡単にですが内容を訳したものを残しておきます。

※太字になってる部分は訳者の主観です。長文で読みにくくなってしまったので、主観で重要に感じた部分を強調表示しています。

OSSを使ってるのは？

以下のような人

OSSのMLにメールしたことがある
IRCで関わったことがある
Stack Overflowで回答したことがある
技術ブログを書いたことがある
Githubでissueを上げたことがある
ハッカソンイベントに参加したことがある（訳者注：つまり、Matsuri参加者全員;)）
pull requestを送ったことがある
bundleを公開したことがある

機会に満ちている
OSSには次のものが必要

エバンジェリズム
サポート
開発
ドキュメンテーション

エバンジェリズム

私たちはどうやって

オープンソースのプロジェクトを見つけるのでしょう？
そしてその中の一つを使おうと決めるのでしょう？
更に貢献までしようと思うようになるのでしょう？

Lukas Smithのサポートが無限に続くわけではない

あなたの経験を公開する

今いるユーザと、潜在的なユーザに向けて、ブログを書いたり、ケーススタディを公開したり
プロジェクトメンバに向けて、RFCについて答えてあげたり、新規フィーチャや変更について意見を伝えたり、うまくいくことといかないことを伝えたり

フィードバックは意思決定を導いてくれる

賞賛は励みになるし
批判は反省になる

批判を省略してはいけない

ポジティブなフィードバックのループは危険
最も良い批判というのは建設的なもの
良い意思決定には客観性が欠かせない

ただ信者になるのではなくて、主張する

コミュニティを育む

個人なら、カンファレンスに参加したり地方で勉強会を開催したりそこで友だちを作ったり
企業なら、これらをスポンサーしてあげたり

（訳者注：Javier Eguiluzというスペインのコントリビュータについて言及されていました。スペイン語圏への情報伝達を熱心に行っているコントリビュータとのこと。）

ドキュメンテーション

私たちはどうやって

始めたり、続けたり
OSSの使い方を覚えたり
新しいAPIについて熟知できたりするのだろう

Ryan Weaversのサポートが無限に続くわけではない

神話：スターはコードしか書かず、ドキュメントを書くのは観客（訳者注：⇒最もコードを書く人がドキュメントも大量に書いてるという事実。という意訳の方がわかりやすいかも）
ドキュメントの形態は多様

コード
APIドキュメント
テストケース
README
本
クックブックとかチュートリアルとか
サンプルアプリとか

でも、ほとんどのユーザに必要なのはREADMEからの後半4つ（README、本、チュートリアル、サンプルアプリ）
素晴らしいドキュメントはいかにしてできるか

一貫した記述方法
読者が最良の著者をつくる
コードが変化するという形で進化を遂げる

間違ったドキュメンテーションは危険
書くことに熟練するということが本質的に重要な事

コミットする前に

規約に従おう。書式、構造、書き方など。
変更箇所をテストしよう
内容のテスト⇒文法やスペルミス、リンクなどを
シンタックスのテスト⇒reStructuredTextやMarkdown、HTMLで
ビルドのテスト⇒SphinxやDocbookで

翻訳の機会
サポート

ユーザはうまくいくことを期待するもの

少数のユーザは質問をしてくれる
良いユーザはバグレポートをまとめて送ってくれる
素晴らしいユーザはパッチを送ってくれる

サポートは

感謝されないことが多い
成長のために欠かせない
終わりはない

容赦ない質問攻め

なぜユーザはこれを聞いてくるのか？
できたら過去ロとか関係するドキュメントを見てほしい
良い交換は見える化するに値する（訳者注：交換⇒意見交換のことだと思います）

バグレポート

ユーザに実際のケースを報告してもらうように促す（脆弱性について真摯に扱う）
優先順位づけすると時間を大切にできる（同一のバグレポートや無効なレポートを選り分けたりする。クロスリファレンスや最新の話題などによっても報告は増える）
ギャップを埋める（背景となる情報を提示したり、テストが落ちるケースを明示したり、ドキュメントに記載して仕様化するなどの方法もある）

コードレビュー

テストスイートが通ることを確認する。現状のカバレッジは十分だろうか。それから、travisbotにコメントするのを避けよう。
オブジェクト指向エクササイズに従う（助けになるがやりすぎないこと） （訳者注：原著は多分これ。Object Calisthenics、日本語だと「オブジェクト指向エクササイズ」で検索すると多数出てくるけど、例えばこちらのブログも簡潔にまとまってる）
コーディング規約に従う(phpcs-psrやPHP-CS-Fixerが便利)（訳者注：phpcs-psrは初めて知りました）

他の人に自分がやってることを伝える
サポートとは、その中の大きな一部分
開発

一歩目を歩みだす

一体いくつのOSSプロジェクトが、基本的な機能についての小さな要望をきっかけに始まったのだろう
一体何人のコアデベロッパが、小さなバグ修正を行うことからスタートを切ったのだろう

調査

バグ修正や小さなタスクから始める
大きな貢献のベースとなるフィードバックを集める
開発者の会話に交じってロードマップを議論する（※訳者注：@dustinwhittle が話してた様子だと、ダスティンが関わってるOSSコミュニティでは2週間に1回とかのペースで、中長期的なロードマップについて議論する機会が設けられてるそうです）

謙虚なコントリビュータであれ

誰のために実装してるのか
誰かに期待する前に自分で自分の実装をレビューする
コードレビューを宗教論争にしない

どんなコントリビュータも等しく重要なのであって、大小があるのは変更（changeset）だけ
存在しないところに境界線を引かない
コラボレーションが素晴らしい世界へと導く
作ることを止めない

謝辞

写真はZendConで@ooharabucyouがGETしてきたというZend Framework Elephants。

講演者の皆様、PHP祭り青年団の皆さん、青年団ではないけどお手伝いされた全ての方、Matsuriで毎年会う皆様、今回お会いできなかった方も含めて、皆様お疲れ様でした。Android賞とFusic賞ダブル受賞は素直に嬉しかったです。ネタでしかないAndroidアプリに脚光を浴びせてくれたrand()関数の神様に強く感謝しています。

来年は何かしらお手伝いができればと思ってますが、一参加者として来年も楽しみにしています。