|
オープンソースソフトウェアへの貢献方法がわからない？まずはバグ報告から始めましょう。もしかしたら報酬がもらえるかもしれません！Qian Hongさんの体験談をご覧ください。 今年のFreedom of Software Day（SFD）では、広州Linuxユーザーグループ主催のオフラインイベントで「オープンソースコミュニティの隠れた名人になる（パート1）」と題したプレゼンテーションを行いました。より多くの方々と共有できるよう、プレゼンテーションを再構成・拡張し、トランスクリプトを作成しました。 金庸の小説には、「掃き清僧」と呼ばれる伝説の人物が登場します。その経歴は謎に包まれており、武術の腕前は比類なきものです。小説の中の掃き清僧は、登場した瞬間から達人のように振る舞いますが、どのようにしてそのような境地に達したのかは誰にも分かりません。このような「掃き清僧」は、まさに到達不可能な存在です。しかし、誰もが真似て到達できる別のタイプの掃き清僧も存在します。それを「偽掃き清僧」と呼びましょう。 最近、ある実話が話題になっています。広東外語大学の寮長が、中山大学と広東外語大学の会計学講座を聴講し、公認会計士試験に合格した後、大手4会計事務所に転職したのです。さらに有名な例としては、今年のロンドンオリンピック閉会式のリオ大会で8分間のサンバダンスを披露したブラジル人清掃員が挙げられます。彼はまさに「隠れた名人」で、ブラジルのダンススクールで清掃員として働いていました。 どの山の要塞でも、掃討作戦を担当する僧侶はインスピレーションを与える人物です... この記事は、オープンソースコミュニティにおいて、一見地味ながらも非常に優れたスキルを持つ人物の、試練と苦難を乗り越えてレベルアップしていく道のりを紹介しています。もちろん、このタイトルはクリックベイトのためのもので、本当のタイトルは次のとおりです。 =バグレポートからGoogle Summer of Codeへ= サブタイトルは: ==200のバグから5,000ドルへ== 端的に言えば、要点は: ===どうやってお金を騙し取るのか? === プレビュー：この記事はかなり長いです。読み切れない場合は、5000ドルくらいで購入を検討してくださいXD バグ報告と詐欺行為に何の関係があるのでしょうか？これはすべてGoogle Summer of Codeから始まりました。 GSoCはGoogleがスポンサーとなっているサマーキャンププログラムで、学生はオープンソースプロジェクトでコードを書くことで報酬を得られます。プロジェクトが提供するマンツーマンのメンターシップも受けられます。GSoCプログラムは3ヶ月間続き、プログラムを修了し、評価テストに合格した学生全員に5,000ドルの賞金が授与されます。公式の説明はかなり長いので、もし迷ったら5,000ドルについて考えてみてください。http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs GSoCは毎年、世界約200のオープンソースプロジェクト組織と連携し、年間4,000名以上の学生からの応募を受け付け、最終的に1,000名以上が合格しています。合格者の大多数は中間評価と期末評価に合格しています。幸運にも合格できた方は、常に誠実に、怠けずに、そして頻繁に指導を受ければ、評価に不合格になることを心配する必要はありません。GSoCの合格率は、翌年のオープンソースプロジェクト組織に割り当てられる学生数に影響を与える可能性があるため、メンターが困難を乗り越えるお手伝いをいたします。もちろん、別の視点から言えば、合格した暁には、この機会を大切にし、目標達成に向けて努力する責任も負うことになります。 申請、中間レビュー、最終レビューなど、オープンソースプロジェクトのメンターは各段階で最終決定権を持ちます。そのため、金銭を詐取しようとしているなら、オープンソースプロジェクトの開発者と事前に知り合うのが良いでしょう ;-) 2011年の初めから、私はWineプロジェクトに意図的にバグを報告し、床掃除をし、テストを行い、人々と知り合いになるよう努めました。2012年4月、WineプロジェクトのGSoC（Global System for Computing）に応募し、大した苦労もなく承認され、私の詐欺行為は成功しました[注1]。今年は10名以上の学生がWineプロジェクトのGSoCに応募しましたが、Wineプロジェクトには学生の枠が5名しかありませんでした。もし事前に計画を立てていなかったら、人を騙す機会は絶対に得られなかったでしょう。 一人で詐欺をするより、みんなで詐欺をする方がましです。私の金銭詐欺の経験を共有したいと思います。- 1年前から準備を始め、バグ報告やオープンソースプロジェクトへの参加を始めました。私は1年間で約200件のバグを報告しました。- バグ報告を通して、オープンソースプロジェクトのワークフローを理解し、開発者と知り合い、彼らの知識を「盗んで」オープンソースプロジェクトの開発を始めました。- バグ報告を通して、開発者との信頼関係を築き、GSoCへの参加を「詐欺」で獲得し、最終的に5,000ドルの賞金を騙し取りました。 簡単に言えば、お金をだまし取るコツは、バグを報告してオープンソース プロジェクトに参加し、課題を克服して常にレベルアップし、それによって自分のスキルを向上させ、GSoC アプリケーションの成功率を高めることです。 真面目な話、オープンソースプロジェクトに200件のバグを報告した人は、そのプロジェクトを心から大切に思い、オープンソースコミュニティにおける自分の評判を大切にしているはずです。貢献もせずにただ金銭を詐取するような人ではないはずです。GSoCの目的は、オープンソースプロジェクトへの新たな貢献者を育成し、サマーキャンプ終了後も学生が貢献し続けることを期待することです。200件のバグを報告すること自体が大きな貢献です。オープンソースプロジェクトの開発者の観点から言えば、1年間かけて200件のバグを報告し続ける学生は、報酬を受け取った後も貢献を続ける可能性が高いため、そのような学生に機会を与えるのは理にかなっています。したがって、信頼と機会は努力によって得られるものであり、いわゆる「詐欺」は単なる冗談であり、真剣に受け止めるべきではありません。 200 個のバグを報告するのは難しいように思えますが、200 個のバグを報告すると 5,000 ドル稼げると固く信じれば、突然簡単になります :D バグはどのように報告すればいいのでしょうか？実は、成熟したオープンソースプロジェクトには必ず詳細なバグ報告ガイドラインがあります。そのドキュメントに従えば、バグの報告方法がわかるはずです。もしそのようなドキュメントを読んだことがない場合は、以下のキーワードの組み合わせでGoogle検索してみてください：XXX + QA / テスト / バグレポート。例えば、http://lmgtfy.com/?q=libreoffice+qa http://lmgtfy.com/?q=chromium+bug+report https://www.google.com/search?btnG=1&pws=0&q=ubuntu+testing など。 これらの文書は通常かなり長いので、読めなくなったら 5,000 ドルの値札を考えてみてください ;-) ほとんどのドキュメントには多数の外部リンクが含まれており、可能な限りそれらを読むべきです。これらのリンクには、オープンソースプロジェクトのテストリリースサイクルの説明、専用のバグ報告およびデバッグツールの紹介、プロジェクト関連のメーリングリストに関する情報の提供、さらにはオープンソースプロジェクトのワークフローの説明などが含まれている場合があります。 ワークフローとは一体何でしょうか？例えば、病院に行くには、登録、診察、検査、料金の支払い、薬の受け取り、そして場合によっては賄賂の渡し合いなど、様々な手続きが必要です。学校に行くには、入学手続き、コースの選択、授業の欠席、課題の提出、試験の受験、そして場合によっては不合格になって再受験することなど、様々な手続きが必要です。GSoC（Global System for Computing and Research）に参加するには、プロジェクトやトピックの選択、人々との交流、応募、コードの作成、評価、そして最も重要な、金銭を詐取するといった手続きが必要です。つまり、ワークフローとは、一見面倒で退屈に見える一連の手続きであり、時にはそれらをこなさなければならないこともあるのです。 オープンソース プロジェクトのワークフローには、バグを報告する場所、バグのライフサイクルの仕組み、パッチを送信する場所、パッチが受け入れられない場合の対処法、オープンソース プロジェクトのバグ トラッカーへの管理アクセスを取得する方法、公式のコード送信権限を取得する方法などが含まれます。 新規参入者にとって、オープンソース プロジェクトに参加する際の最大のハードルは、技術的なスキルやプログラミング言語ではなく、ワークフローの理解不足である場合があります。問題をどこに報告すればよいのか、誰にパッチを送信すればよいのか、どこに助けを求めればよいのかなどがわかりません。営利企業の開発者も、この問題に遭遇することがあります。たとえば、仕事でオープンソース プロジェクトを使用し、いくつかのバグを修正しても、コミュニティにパッチを送信する方法がわからない場合や、パッチが一度も受け入れられなかったために改善を諦め、長期間ローカル ブランチを維持する場合があります。これにより、本来は双方にとってメリットのある状況が複雑になり、余分な負担が生じます。実際には、オープンソース プロジェクトのワークフローは大体似ています。1 つのプロジェクトで作業したことがあれば、ドキュメントを参照することで他のプロジェクトのワークフローを理解することは難しくありません。 バグ報告のワークフローを基本的に理解していれば、バグ報告はフォーラムへの投稿と非常に似ていることに気づくでしょう。ただし、投稿はバグトラッカー上で行われる点が異なります。この観点から見ると、バグ報告の技術的なハードルは非常に低くなっています。技術的な内容が不足しているからこそ、「床を掃く」ような作業と言えるのです。 バグ報告はフォーラムに投稿するのと同じくらい簡単ですが、質の高いバグレポートを書くには、やはり献身的な努力が必要です。バグ報告に関する一般的なチュートリアルはいくつかありますが、最も効果的なのは「バグを効果的に報告する方法」です。同様に役立つ記事として、「質問することの知恵」があります。これらの記事をよく読み、自分の実践を振り返ることで、質の高いバグレポートを作成できるようになります。どちらの記事もかなり長いので、行き詰まったら5000ドルのことを考えてみてください。すると、急に短く感じられるかもしれません。両方をよく読んでみると、質問することとバグを報告することには、基本的に同じ資質が求められることがわかります。「バグ報告の仕方がわかった」と自信がついたら、フォーラムに投稿されているほとんどの質問を見てみてください。多くの人が質問の仕方を知らないことに気づくかもしれません。もしかしたら、あなた自身も過去にそうだったかもしれません。200件のバグを報告してみてください！ :P 質の高いバグ報告は開発者に歓迎されますが、質の低い報告は逆効果となり、時間を無駄にしてしまう可能性があります。「バグを効果的に報告する方法」や「質問術」をじっくり読むことに抵抗を感じる人も多いかもしれません（もしかしたら5000ドルのボーナスをもらえないかもしれません！ :P）。誰かが一度に200件もの低品質なバグを報告してしまうのを防ぐために、注意点をお伝えしましょう。質の高いバグ報告者は、以下の点に注意する必要があります。- プロジェクトのバグ報告ガイドラインを読む！ガイドラインを読まずにバグを報告するのは無責任です。- バグごとに1つの問題だけを報告する。- 関連するプログラムのバージョン番号とオペレーティングシステムのバージョンを正確に指定する。- バグを再現するための正確な手順を時系列順に列挙する。- 開発者からの質問には必ず迅速に回答する！ もう1つ追加すべき点がありました。バグを報告する前に、Googleとプロジェクトのバグトラッカーの両方で重複した問題を検索してください。しかし、重複した問題の検索は、初心者、特に英語が苦手な人にとっては最も難しい部分です。 繰り返し発生するバグの検索と特定方法を知っていれば、もう初心者ではありません。バグの品質基準を上げることを検討してください。 - 一貫したスタイルを確立します。固定形式でバグレポートを作成するようにします。これにより、習慣が身につき、厳密に考えることが促進され、重要な情報を見逃すことがなくなります。多くのバグ追跡システムでは、バグレポートのテンプレートが用意されています。この習慣を身に付けるには、これらを参照してください。 - 50 件のバグを報告したと想像してください。6 か月後に 1 つのバグをランダムに選択してレビューするとしたら、一度読んだだけで再現できると保証できますか。この考え方でバグを報告し、多くのバグを報告したら、レポートをレビューします。一度読んだだけで再現できない場合、他の人はどうやって再現できるでしょうか。 - オープンソース プロジェクトのバグ追跡システムを購読/フォローします。他の人がどのようにバグを報告しているかを観察し、経験豊富な開発者から学び、初心者を積極的に支援します。他の人を助けることは、自分自身を向上させる方法でもあります。バグ報告に関する重要なドキュメントを読んで要点を把握すると、次のことがわかるかもしれません。バグを報告することが問題なのではありません。問題はバグがあることではありません! 確かに、バグを報告するのは難しくありませんが、見つけるのは簡単です。日常的な使用状況でバグを発見できるかどうかは、運次第です。そうでなければ、誰もそのソフトウェアを使いたくなくなるでしょう ;-) しかし、本当にバグを報告したいのであれば、バッチバグ検出の方法を学ぶ必要があります。たとえそのような方法がなくても、自分で作るべきです！ えっ？大量のバグを見つけるって？実は、大量のバグを見つけるのは珍しいことではありません。大量のバグを見つける仕事があり、そのような職種はテスター、QA（品質保証）、QE（品質エンジニアリング）と呼ばれています。 大量のバグを見つけるには、まず「早期」に行う必要があります。 多くのオープンソースプロジェクトには、開発版、アルファ版、ベータ版といった様々な開発・テスト版に加え、いわゆる最終版や安定版があります。オープンソースソフトウェアの「安定版」に不安定さを感じても、心配する必要はありません。多くのオープンソースプロジェクトには徹底的なテストを行うための人員が不足していますが、商用ソフトウェアには通常、専任のQAチームが多数存在します。逆に、深刻なバグに遭遇していないのであれば、オープンソースプロジェクトに静かに貢献しているQAチームに感謝すべきです。「一括バグ報告」の機会を逃さないためにも、ソフトウェアの新バージョンがリリースされたら、できるだけ早くテストを行うべきです。最初のバージョンはアルファ版、2番目はデイリービルド版、3番目はGitリポジトリからダウンロードしてコンパイルするリアルタイム版です。 早起きは三文の徳ですが、大量のバグを見つけるには通常、経験豊富なプログラマーが必要です。そのため、2つ目のポイントは、彼らから学ぶことです。オープンソースプロジェクトのバグリストを購読し、他者が報告したバグを観察し、経験豊富なプログラマーを見つけ、彼らがどのようにバグを発見し報告しているかを観察しましょう。QAドキュメントをよく読んでください。大量のバグを見つけるための方法やツールが、そこに記載されている場合があります。 バグをまとめて見つけるのは、時にとても簡単です。例えば、Wineで200個のバグを報告するにはどうすればいいでしょうか？私が使った最も簡単な方法は次のとおりです。- ソフトウェアダウンロードサイトにアクセスし、上位100個のアプリを見つけます。時間があるときにWineでテストします。時間があれば、必要な数のバグを見つけることができます。- 様々なオンラインバンキングシステムのコントロールをターゲットにダウンロードしてインストールするテストです。これにより、無意識のうちに多くのバグが報告され、ICBCやCMBのオンラインバンキングシステムの多くの問題が改善されました。- メーリングリストやフォーラムで他のユーザーが報告したWineの問題にも注目してください。関連がありそうな投稿を見つけたら、テストに協力してバグをいくつか報告してください。 ;-)#p#
|
