OSS Gate

debianのパッケージングができるようになった夏

Sat, 20 Nov 2021 00:00:00 +0000

この記事はdebianのパッケージングができるようになった夏がオリジナルです。 OSS Gateのサイトにあわせてマークアップを一部修正してあります。

こんにちは、しぶちゃりです。

僕は今年の夏にOSSオンボーディングという取り組みに参加し、debianのパッケージングを行いました。

この記事はその参加記録です。1人でもやってみたい人が増えればいいなと思い記事を執筆させていただきます。

応募した動機

OSSオンボーディングを知ったきっかけは、あるDiscordのチャンネルでdebianのイベントが開催されるらしいということを聞いたことが始まりでした。

その時の心境としては、最近はAPIの開発が多かったことからも全く関心がなかった技術分野を知りたいという気持ちでした。

その後実際に応募要項や今までdockerのimageとして用いるくらいであったdebianがどのようなものか調べていくうちに興味が湧き応募しました。

OSSオンボーディングの経験はとても楽しかったため、自分の多くのものに関心を持てる性格がプラスに働いたと感じます。

取り組んだこと

今回はdebianのパッケージングを実際にメンターの方と一緒に進めていくというコースに応募しました。

その際にパッケージングしてみたいものがあるかという項目が存在していたため、slack-termというコンソール上でslackを操作できるツールのパッケージングを希望しました。

このツールを選定した理由としては、普段自分自身がGoを書いていることが多いため、コードをいじることがあっても障壁を感じず、何かしらプログラムのランタイムエラーやコンパイルエラーを解決しなくてはいけないケースが生じてもdebianのことに集中できると仮定したからです。

また、インターンでSlackのAPIを触る経験があり、慣れ親しんだAPIであったため、Slack API関係の問題が生じた場合も、同様にdebianに集中できるということもありました。

実際に応募した際のページがこちらです。

debパッケージのメンテナンスやそれを支えるシステムの開発

その後、実際に受理され、面談を経たのちにスタートしました。

実際にパッケージングを行ってみると、普段の開発とは異なる苦労が存在しました。

例えば、slack-termをパッケージングするにあたり、slack-termが依存してるライブラリを調査することからスタートしました。

その結果

fuzzy-search
notificator
slack-go
term-ui

とい4つの依存が存在しました。

そのため、debianで動作するためにも先に上記の4つをパッケージングする必要があり、今回のOSSオンボーディングは最大限これらをパッケージングすることとなりました。

コードベースの依存性や、ライブラリの依存性などは以前から気にしていた部分ですが、動作する前提での依存性の話をする経験が多かった僕にはこの経験がとても楽しいと同時に多くの動作する環境を整備しているエンジニアの凄さを改めて感じました。

OSSオンボーディングの中ではfuzzy-searchとnotificatorのパッケージングを行いました。

このパッケージングにあたり、debianの環境で実際に動かすためにパッケージング対象のビルドテストを行ったり、有償ではなくコミュニティとして動いているdebianならではのライセンス問題や、debianのお作法として存在するフォーマットに合わせて、同様にdebian固有のファイル操作やコマンドを実行するなど多くの経験を積みました。

実際にOSSオンボーディング後もパッケージングは行っており、この時の経験と足りない部分はメンターであったKentaro Hayashiさんに質問するなどして活動を続けています。

よかったこと

まず、今まで触れたことがなかった領域に触れることができた経験が何よりも大きいです。

今まで僕はOSSへのコントリビュートや、自身でライブラリを作成する際にも、前提として動作することが当然であると考え開発していました。

もちろん、この考え方にある種の反論はあれど言語固有のツールを使う際には暗黙的に当然である考え方であると思います。

ここで感じたことは自身のライブラリがどこでどのように活用されるかわからない(OSSであり、誰でも介入できる)ので、多くの人がメンテナンスがしやすく、かつ動作をしやすい状況を維持するかを考え始めました。

実際に今僕は作成しているTwitter v2 APIのライブラリはテストコードで用いている3rdパッケージを除き、全てGoの標準パッケージで構成されています。

気になったこと

今回僕がパッケージングしたコードはGitLabにアップロードされており、実際にパッケージとして公開される前にも、mentors.debian.netというところにpendingとして挙げられacceptされることで公開される方式を取りました。

これはdebianでの権限などもあり、必ずしもこの方針を取る必要があるかは各々によるとは思いますが、初めてパッケージングする人にとってはセーフティーな環境となっています。

その反面、debianのお作法に則り統一するために普段用いるような(GitHub)などは用いていません。

仮にこの部分で面倒などの障壁を感じ、僕のようにメンターに聞ける環境がないばかりに諦めている方がいれば、とても惜しいなと思いました。

またdebianのパッケージングなどの情報はKentaro Hayashiさんの所属する企業である、Clear Codeの記事を除くとほとんど日本語で書かれた記事はなく、デザイン的もお世辞にも見やすいとは言えません。

これらのことが障壁となり関心があるが離れてしまった人がいる可能性は充分あると思うので、僕のようにdebianのパッケージングを楽しめる環境を作っていければいいなということが直近のdebianコミュニティを盛り上げることとしてやってみたいと構想しているミッションです。

応募前の想定と実際の内容とのギャップ

ここに関してはパッケージングをする上での苦労以外を除くと、僕の場合は大きな差分はありませんでした。

またこの苦労は望んでいたものなのでとても楽しかったです。

もしこの記事を読んで同じようにパッケージングをやってみたいという方がいましたら、情報の多くは英語で書いているものを読む方が情報が手に入るため、翻訳サービスを用いて読むなどの方法でも構いませんが、英語に心理的なハードルを設けていない方の方が向いているかと思いました。

今後の新人・先輩・運営へのコメント

Kentaro Hayashiさんをはじめとし、Clear Codeの皆様の暖かい気持ちとこちらの小さな疑問にも丁寧に答えていただける環境があったからこそ、OSSオンボーディングをとてもいい思い出として、楽しめたと思います。

そのため、今でもdebianのパッケージングをしようと考えていることは間違いなくこのおかげです。

改めて、とても楽しくいい経験を積ませていただきありがとうございました。今後ともよろしくお願いします。

もし、この記事を読み少しでも関心が湧いた方はぜひ僕のTwitterにDMしてください。

答えられる範囲であれば回答します。

最後までお読みいただきありがとうございました。

OSS Gateオンボーディング第一回を実施 - Debianコントリビューターを1人増やせた！

Fri, 08 Oct 2021 00:00:00 +0000

この記事は「OSS Gateオンボーディング第一回を実施 - Debianコントリビューターを1人増やせた！」がオリジナルです。 OSS Gateのサイトにあわせてマークアップを一部修正してあります。

Debian開発者としてDebianのコミュニティーで活動している林です。

2021年8月から10月にかけて、OSS Gateオンボーディングという取り組みを実施しました。 OSS Gateオンボーディングはより深く継続的にOSSを開発する人を増やすことが目的です。

この目的を実現するために、OSS Gateオンボーディングでは「開発者が増えて欲しい」先輩役と「開発に参加したい」新人さんをマッチングし、「開発に参加したい」人が「継続的に開発に参加する人」になれるように支援することにしました。

今回は、OSS Gateオンボーディングの第一回として「debパッケージのメンテナンスやそれを支えるシステムの開発」という内容で参加者を募集し、実際に支援をした内容を紹介します。

先輩役を務めることにした動機とは
支援のはじまり新人さんの募集
募集締め切りと応募者の選考
支援開始と初回のミーティング(8/11)
オンボーディング前半実施(8/17-8/24)
途中でのふりかえり(8/31)
オンボーディング後半実施(9/2-9/29)
まとめミーティング実施(10/6)
OSS Gateオンボーディングでのやりとり
OSS Gateオンボーディングを終えて
OSS Gateオンボーディングはどんな人に向いている?
さいごに

先輩役を務めることにした動機とは

Debianのローカルコミュニティーとして毎月1回東京エリア・関西合同Debian勉強会が開催されています。オンラインでの開催になったことで、地理的制約に縛られなくなり¹、これまでよりも参加しやすくなりました。ただ、(勉強会に限らず)もっと新しく参加してくれる人が増えて活性化するといいなと思っていました。

そこで、Debianに興味を持ってはいるものの、まわりに教えてくれる人がいないなど困っている人を支援できないか、ということで先輩役をやってみる²ことにしました。結果として、Debianコミュニティーにより深く関わってもらえたらいいなという思いもありました。

支援のはじまり新人さんの募集

まずは、興味を持って参加してくれる新人さんがいないとどうしようもありません。

そこで、募集要項を詰めた上で、7月17日のDebian勉強会でこれから実施しようとしている取り組みの紹介をしました。

OSS Gateオンボーディング - Debianプロジェクトを題材にした取り組みの紹介

また、Debian/Ubuntu関連に興味を持っている人ならメーリングリストに登録しているだろうということで、メーリングリストにて募集の告知を行いました。

ただ、どういうニーズがあるかはよくわからなかったので、いくつかパターンを用意して募集をかけてみました。具体的には次の3つのコースを用意しました。

Aコース: 新規Debianパッケージング作業
Bコース: 既存のdebパッケージの不具合報告や修正作業
Cコース: mentors.debian.netの改善

Aコースはパッケージ化したいソフトウェアがあるけどどうしたらいいかよくわかっていない人を支援する目的で用意しました。 Bコースは、Aコースよりはやや知識や経験のある人向けです。 Cコースは、やや異色の内容になっています。mentors.debian.netというのは、Debianパッケージを一時的にアップロードしてスポンサーを探したりするのによく使われているサイトです。パッケージングだけでなく、そういった作業を支えるシステムに興味を持つ人がいるかもしれないということで、テーマの1つとして取り上げてみました。フロントエンドにより興味がある人なら向いているのではと考えたためです。

募集締め切りと応募者の選考

告知してから約2週間後、7/31日に応募を締め切りました。 1件応募があればいいな、くらいのつもりでいました。

さいわいなことに5件の応募があり、そのなかから1件を採択しました。使っているソフトウェアをパッケージングしたいという明確な動機が全面にでていたこと、スケジュール感があいそうということで @sivchari さんと一緒にAコースの新規Debianパッケージングの作業をすることにしました。

なお応募者のなかで圧倒的に希望が多かったのは、Aコースの新規Debianパッケージングでした。また、知ったきっかけについてはdebian-usersではなくて、ubuntu-jpでの告知がほとんどでした。

締切直前の応募が多かったので、選考期間は少し長めにとっておくのがよさそうという知見³を得ました。

支援開始と初回のミーティング(8/11)

8/11に初回のミーティングを実施しました。

@sivchari さんは普段はmacOSを使っていて、DebianはConoHaのVPSで使ったりしているとのことでした。使い慣れた環境がよかろうということで、オンボーディングの支援期間中は、Debian unstableなインスタンスを用意してもらってそこで一緒に作業することにしました。

パッケージングの題材は希望のあったslack-termとしました。ただ、依存するライブラリーはその時点ではまだすべてパッケージ化されていませんでした。

依存パッケージも順にパッケージングしていきたいという意向だったので、その方針ですすめることにしました。なお、支援期間内にパッケージング作業がすべては終わらなそうであることは見えて⁴いたので、目標はすべてパッケージングを終わらせることではなく、それ以降も継続して進められるようになっていればよいことを確認して作業に着手することにしました。

その後も、オンボーディングは週1回、2時間のペースで実施しました。

オンボーディング前半実施(8/17-8/24)

事前にConoHaのVPSでセットアップしてもらいたい内容を共有しておいて、パッケージングの流れ⁵を説明したりしました。今回パッケージングしたい内容は、Go言語のプロダクトなので、Goのパッケージングのお作法をDebian Go teamの既存のドキュメントをもとに説明⁶しつつ進めました。

Goパッケージングではdh-make-golangコマンドを使うのですが、不具合があることがわかったので、フィードバックをしたりもしました。

dh-make-golang fails when upstream uses “../..” in import path

なお報告した不具合はdh-make-golang 0.5.0-1ですでに修正済みです。

オンボーディングの前半では、Debianプロジェクトの説明だったり、パッケージングのお作法を理解してもらうなど、どちらかというと実際に手を動かしてもらうよりは、解説する機会が多めでした。

途中でのふりかえり(8/31)

8月の終わりに途中までのふりかえりミーティングを実施しました。オンボーディングの本来の目的である、「OSS Gateオンボーディング後も新人が対象OSSの開発に継続的に参加する」ことができる流れになっているかどうかを再確認するプロセスです。方向性はぶれてなさそうだったのでそのまま進めていくことにしました。

この後しばらくして、オンボーディングのその後について、続報をメーリングリストに流しました。

オンボーディング後半実施(9/2-9/29)

オンボーディングの後半では、引き続き依存するライブラリーのパッケージング作業をすすめました。

ITP(パッケージングはじめる意思の表明)が済んでいないものを終わらせる
パッケージングするにあたりアップストリームで直してもらうべきものをフィードバックする
必要に応じてパッケージングに必要なパッチを作成する
パッケージの体裁を整える
パッケージのテストでコケてはまる

パッケージングをする上でありがちな問題などはひととおり体験してもらえたのではないかと思います。パッケージの体裁が整ったのでスポンサーアップロードして、ftp-master待ちの状態までいくつかこぎつけることもできました。

依存しているライブラリーのうちの1つであるgolang-github-lithammer-fuzzysearchがDebian入りしたあと、新しいバージョンが出ました。更新のやり方もあわせて体験してもらえたのは、その後も継続して開発するという観点から有意義でした。

まとめミーティング実施(10/6)

最終回では、まとめミーティング(ふりかえり)を実施しました。

手探りの状態で実施したため、いくつか課題はありましたが、おおむね新人と先輩双方にメリット⁷のある支援期間にできたのではないかと考えています。

OSS Gateオンボーディングでのやりとり

すでに述べたとおり、OSS Gateオンボーディングで目指したのはパッケージング作業が支援期間内に終わることではありません。新人さんがすべてひとりでできるようになる必要はなく、作業を相談しながら継続してすすめられるようになればOKです。

とはいえ支援期間中にどれくらい進められたのかは今後の参考になるかもしれないので紹介すると、次のような具合でした。

slack-term (もともとパッケージングしたい!と希望があったもの) ITP #994283済み
- golang-github-lithammer-fuzzysearch ITP #992838 Debian unstable入り
- golang-github-0xax-notificator ITP #993842 ftp-masterの審査待ち
- golang-github-erroneousboart-termui ITP #994282済み。パッケージの体裁を整えている途中
- golang-github-slack-go-slack ITP #993615済み。パッケージの体裁を整えている途中

slack-termはITPまで、その他の依存ライブラリーは一部Debian unstableにすでに入った状態になりました。

毎回のオンボーディングでやることなどはissueを作成して記録を残していました。作業状況を確認して、その日にやろうとしていることを共有⁸するためです。

2021-08 debian slack-term オンボーディングのissue

解決すべきことなどはsalsa.debian.orgの各リポジトリごとのissueでやりとりしたり、マージリクエストをだしてもらったりしました。普段のOSSの開発のやりかたをそのまま実践しています。

また、毎回終わりにその日の日報を作成(一緒に作業していない日も記録)するようにしていました。これは、オンボーディングのプロセスの改善につなげられるように、その材料となる情報を残しておく意味合いで実践しました。(ふりかえりはこの記録をもとに行いました。)

時間が経過するとどんどん忘れていくので、作業記録はとても重要でした。

支援期間中に紹介した記事や設定のまとめ

支援期間中に紹介した記事や設定等もまとめておいたので、今後参考になる⁹かも知れません。

OSS Gateオンボーディングを終えて

第一回のOSS Gateオンボーディングを終えてみてよかったことは、先輩役を楽しんでできたことです。今回はGoで書かれたソフトウェアのパッケージであり、Goのパッケージングはそれほどしたことがなかったので、これまで知らなかったことを知るよい機会となりました。古くなっていた知識をアップデートすることもできました。

新人さんがつまるところを知れたので、今後のドキュメントの改善などで新しく入ってくる人のフォローをできたらいいなと考えています。

OSS Gateオンボーディングはどんな人に向いている?

今回はDebianをテーマとしてオンボーディングを実施しました。より一般的な話にすると、次のような人におすすめできるのではないかと思います。

どこから手をつけてやるといいのかよくわからなくて不安な人(先輩が作業の交通整理をしてくれるはず)
ドキュメントを読んだが挫折した人(先輩がそのあたりを解説してフォローしてくれるはず)
プロジェクトの背景など雑多な話も聞きたい・楽しめる人(先輩が雑談としていろいろ話してくれるはず)

次回以降開催されるにしても、先輩役の人ごとに実施するテーマは変わるはずです。ただ、突っ込んで話を聞いたり知見を深めたりしたい、好奇心旺盛な人が向いているのではないでしょうか。

一方の先輩役をする人はこんな人が向いていそうです。

マイナーであってもいいから伝えたい知識を持っている(自分の持っている知識が新人さんの役に立って嬉しい)
ほかにあまり先輩役になれるひとが界隈に少ない(できるひとがそもそもすくないので希少価値がある)
人にものを教えたりした機会が少ない(新人さんに教えることで、新たな知見が得られたり、古い知識をアップデートする機会になったりします)

さいごに

今回はOSS Gateオンボーディングの第一回として、「debパッケージのメンテナンスやそれを支えるシステムの開発」という内容で参加者を募集し、実際に支援をした内容を紹介しました。

短期ではありましたが、今後継続していくうえで必要な知識や経験を伝授できたのではないかと考えています。

まだ手探りな部分も多いのですが、この取り組みをぜひ継続していきたいです。第二回がいずれ開催されるはず(内容は先輩役次第)なので、その際には新人さんはぜひ応募してみてください。

これまでオフラインだと参加できなかったけど、オンラインになったので鹿児島から参加してます、という人がいました。 ↩
かつて、Debian開発者のやまねさんにいろいろ教えてもらって助かったという体験があったので、同じようなことができないかという気持ちでいました。やまねさんはSoftware DesignでDebian Hot Topicsを連載されています。 ↩
7/31(土)に締め切り、8/2(月)に選考・連絡する予定にしていました。1件来たらそのまま採用、ぐらいの想定をしていました。 ↩
Goのパッケージングの場合、dh-make-golang estimateというコマンドを実行するとパッケージングされていない依存ライブラリーがわかる。 ↩
これまで公開していたDebian関連の記事が役に立つときが来ました。 ↩
ほかにもDebianプロジェクトの運営や、DPL選挙の話など、雑談でいろいろ話をしたりもしました。 ↩
先輩にとっても古くなっていた知識をアップデートすることができたり、Goパッケージングのツールの改善につながるフィードバックができたりしたため。 ↩
もちろん作業をすすめていくうちに、必ずしも予定通りにいかないことはあります。向き不向きはあるでしょうが、ゴールがわかりやすくなるのでそのようにしました。 ↩
端末の共有などは、今回はscreenで行いましたが、もっといいやりかたがあるかもしれないです。 ↩

OSS Gate のワークショップをFujitsuで再び実施してみた（開催レポート）

Mon, 28 May 2018 00:00:00 +0000

はじめに

こんにちは。@Yasunorigoto1です。

OSS Gateワークショップ、2018/5/29に富士通社内の実施として、2回目を開催することができました。前回のOSS Gateワークショップでは私から教育部門に「ぜひやりたい」と強く提案する形で実現しましたが、それに対して、今回は教育部門のほうから「やりましょう」と提案があって実現しました。（私も最初は知らなくて、気がついたら開催が決まってたというのが正直な所です。） OSS Gateワークショップ開催の意義が会社に認められたようで、大変ありがたい所です。そこで、今回は2回目の開催レポートを記載しました。

前回と同じ所／変更した所

前回は初回ということもあって、OSS Gateのカルチャーを富士通にできるだけ取り入れたいと考えていたので、主催者である須藤さんを司会進行役に呼んで開催しました。が、今回はいずれこの活動を富士通として自主的に行うものにしたいと考えていたので、筆者が司会進行役になりました。サポーターは、前回お願いした社内の人に今回もお願いしました。さらに、tDiaryで高名なただただしさんをサポーター役に迎えることができました。

また、前回は以下のような課題がありました。

本家のOSS Gateワークショップと同じように、参加者に作業用の端末を持ってきてほしいとお願いしたが、セキュリティ上、仕事の端末の持ち出しが難しいケースがあり、参加出来ない人がいた
社内の仮想化環境で作業してもらったが、proxyの設定でつまづくケースが非常に多く余計な時間がとられてしまった。

そのため今回は、教育部門が以下も用意してくれました。

作業端末として、会場にPCを用意実行環境として、社内ではなく、某パブリッククラウド環境を用意
ネットワーク環境も、社内ではなく、社外に直接接続する環境を用意

予算やコンプライアンス等々の色々な事務処理、社内調整を教育部門側でやっていただいたはずであり、大変ありがたいです。

一方、前回と同じ点としては、今回もOSS Gateワークショップ本体の解説の前に以下を実施しました。

社外秘や他社・お客様の情報を社外に出さないようにするための諸注意
知財部門からのOSS参加申請手続きの解説

これらは、 会社の業務として OSSコミュニティに参加することを想定した練習と位置づけているためです。

これが終わったあとは、いつもの本家OSS Gateワークショップと同様です。本家ワークショップの進め方は動画でも確認出来ますが、大まかに書くとやっていることはたったのこれだけです。

ユーザーとして使ってみる。この際、ドキュメントは 必ず公式のもの を確認する。
やっている作業を逐一メモして、自分がつまづいたり、分かりにくかったりする点などを洗い出す。
メモを元にどんなことをコミュ二ティにフィードバックできるかについて、経験者であるサポーターと考える。
バグ報告やドキュメントの改善提案などの形でコミュニティにレポートする。

コミュニティへのフィードバックが未経験だと、「初心者だから邪険に扱われそう」とか不安になってしまい、フィードバックがなかなかできないものです。 OSS Gateワークショップでは、上記の様にちょっとしたフィードバックを 実際に経験 することで、上記のような不安を払拭することを目指しています。

やってみて

前回は対象のOSSとしてOpenStackのどれかのコンポーネントを選ぶ人が多かったのですが、今回はSelenium IDE, Jupyter notebook, Docker, QEMU, Hyperledger fabricと多様になりました。

ワークショップの最初でパブリッククラウド環境の導入でバタバタしたので、「評価はどうかな？」とちょっと心配していました。

それもあってか今回は全員がフィードバック、すなわち質問やバグ報告を出すところまでたどり着いたか、あるいはその一歩手前のところまで時間内に進めることができました。（最後までいかなかったのは、フィードバックを出したら初めてCLAにサインするように求められたりしたケースです）

また、今回のワークショップでGitHubの便利さにも気がついた方も多かったように思います。 OSS Gateワークショップでは、最後のふりかえり用のアンケートをYAML形式で書いてpull requestを出す方式にしているのですが、これもOSSにpull requestを出す練習になっている点も効果が高いように思います。

課題と今後

今回は前回と比べると、ビギナーの募集に時間がかかりました。最初の参加者募集の文面が少し分かりにくかったかな？というのが個人的な反省点。

また、OSS Gateワークショップの趣旨や内容を伝えても、「そんなに不具合って簡単に見つかるの？イメージが沸かない」っていう反応もあったりしました。「OSSコミュ二ティにフィードバックができるのは、エキスパートの人だけ」というバイアスを払拭するのもこのOSS Gateワークショップの目的ではあるのですが、未参加の人にそれを伝えるのはなかなか難しいですね。

また、もう少しこの活動を軌道に乗せて、社内のあちこちに展開していけると良いなと考えています。

前回開催時の反応から

おまけですが、前回の開催レポート時にいただいた反応の中で、ちょっと気になったものをピックアップ

申請は面倒？

「OSSコミュニティに参加するのに会社に申請しないといけないとかめんどくさすぎる。もし自分がこの会社にいたらきっとやらない。」

うーん。これは家から趣味でOSSコミュ二ティに参加するケースを想定されているのか、会社の業務として参加を想定しているのかどちらなんだろう？と感じました。

一応念のため言っておくと、プライベートでまったくの趣味で、お家からOSSに参加する場合は、会社の手続きとかの縛りはまったくありません。（自宅での過ごし方を会社が縛ってはいけません）好きなように参加できます。

会社の業務としてであれば、OSSによってはContribution License Agreementに会社としてサインする必要があったりします。そういう文面のチェックとかを法務部門がやってくれるのはやっぱり便利だと思いますよ。

本社だけ？

「こんなことできるのは富士通本社だけだよね。子会社は関係ない」

んにゃ。そんなこと無いですよ。これまでにFujitsu OSS Gateワークショップにサポーターとして来ていただいたメンバには、弊社子会社でOpenStackのcore commiterになった人もいます。 (諸事情で、結局committerを返上しちゃいましたが）

こういうのへの理解って、本社かどうかとは関係ないです。結局 人による のです。OSSに対する認識って人によって大きく異なりますし、大きな組織って、なかなか一枚岩にならなくて、認識を全体に浸透させるのが本当に大変です。

弊社の中にはOSSに理解のない人がまだまだ沢山いるのは、おそらくその通りなのでしょう。

でも、私は希望を持っています。まず、このOSS Gateワークショップ自体、会社の中で草の根的な活動としてやっているわけではなく、 会社の役員クラスに認られたうえで 開催しています。（正確に言うと、「ソフトウェア技術交流会」と言う社外の人も交えた社内活性化のイベントが上記の下に行われていて、OSS Gateワークショップはその中の一セッションとして開催しています。）なので、会社のずっと上層部にOSSに理解している方々がいるということです。

今回一番うれしかったのは、最後の振り返りで、「どこでこのOSS　Gateワークショップを知りましたか？」という質問に、ビギナー7人のうち5人が 「上司から勧められた」 と回答してくれたことです。

上司が障害になってコミュ二ティに参加できないとか、あるいは相談しづらいというケースはまだまだ沢山あるとおもうのですが、理解のある管理職の方が増えてくれば風は変わると信じています。

以上。

OSS Gateワークショップを開催するには

Thu, 17 May 2018 00:00:00 +0000

OSS Gateワークショップは自由に開催することができます

OSS開発に参加する「入り口」を提供するOSS Gateは、OSS開発へのフィードバックを実際に体験するワークショップを開催しています。このワークショップを自分たちで開催しませんか！

これまでも、色々な地域や企業・イベントなどで開催してきました。

興味があれば、Gitter - oss-gate/generalで、相談してみてください。

OSS Gateの主な活動形式

これまで、OSS Gateでは、このような形式の活動を行ってきました。

ワークショップ：OSS開発の未経験者が、OSS開発へのフィードバックを実際に体験します
ミートアップ：特定のOSSを開発する人たちが集まる場です。他のOSS開発者と相談したり情報交換できます
もくもく会：色々なOSSを開発する人たちが集まって、雑談しながら各自で作業する会です

開催手順

Gitter - oss-gate/generalで、開催について相談・意思表示する
日時・場所を調整する
Doorkeeperで告知する(DoorKeeperで主催者となっているメンバーに相談する)
開催する
報告する(任意)

ワークショップ開催FAQ

ワークショップは、どのような内容ですか

簡単に言うと、「ユーザーとして使って気になったところをフィードバック」します。ワークショップレポートをいくつか読むと、内容がつかめるでしょう。

ワークショップは、どんなOSSを対象にしても良いですか

はい、構いません。多くの場合、参加者(ビギナー)に自分が興味のあるOSSを選んでもらっています。そのため、ひとつのワークショップで、ビギナーごとに異なるOSSにフィードバックすることがほとんどです。

参加者に自分で選んでもらうと、フィードバック方法を教えるのが大変ではありませんか

フィードバック経験のあるサポーターに参加してもらいます。この時、ビギナーが興味を持つOSSへのフィードバック経験がなくても構いません。サポーターの役割は、ビギナーがフィードバックする時に、背中を押してあげることです。

ワークショップを開催するには、どのような人材を集めると良いですか

まずは、主催者と進行役を確保すると良いでしょう。その他に、参加者(ビギナーとサポーター)なども募集します。

主催者：OSS Gateコミュニティや会場との調整役
進行役：当日の司会進行。シナリオやスライド・ビデオが用意してあるので、それを良く確認しておけば大丈夫
サポーター：OSSの開発に参加している人たち。または、これまでビギナーとして参加したことがある人たち。
ビギナー：OSS開発に参加したことがない。参加したことはあるけど、まだ自信がない人たちです。

サポーター数 >= ビギナー数 / 2 が、1つの目安になると思います。

サポーターが十分に集まらない場合、Gitter - oss-gate/generalで相談してもらうと、お手伝いできる人が見つかるかも知れません。

ワークショップには、どのくらいの時間がかかりますか

休日の5-6時間くらいを想定しています。一度に開催できない場合、2回に分ける場合もあります。

会場は、どのようなスペースが良いでしょうか

集客規模にも寄りますが、10人以上座れる机と椅子がある会議室などがやりやすいと思います。

会場には、どのような設備・備品が必要になりますか

進行用のプロジェクタ or ディスプレイ
参加者（ビギナーとサポーター）用の机と椅子
ネットワーク(WiFi)
電源
マイク(会場が広い場合)

ワークショップに必要なドキュメントはありますか

ワークショップ運営ドキュメントを用意しています。ここには、進行役のためのシナリオやスライドがあります。

ワークショップの開催は、どのように告知すれば良いですか

Doorkeeperを利用できるので、DoorKeeperで主催者となっているメンバーに相談してみてください。もちろん、自分たちでも、どしどし宣伝しましょう！

参加者を限定したり、クローズドに開催してもいいですか。

はい、構いません。これまでも、特定の企業内での開催や、イベントとの併設の実績があります。

スポンサーを募ってもいいですか

はい、構いません。これまでも、会場提供や懇親会の支援、社員を業務時間内にOSS Gateに参加させるなど、いろいろな形で支援して頂きました。

スポンサーの名前は、スポンサーページに社名を記載することができます。また、希望があれば、スポンサーの告知タイムを設けてもいる場合もあります。

この他に、質問や問い合わせ・フィードバックをしたい場合、どうすれば良いですか

oss-gate/general - Gitterで、相談してみてください。不足している情報があるかも知れないので、フィードバックをもらえるとありがたいです。

OSS Gate のワークショップをFujitsuでも実施してみた（開催レポート）

Mon, 02 Oct 2017 00:00:00 +0000

はじめに

はじめましての方も、そうでない方もこんにちは。＠YasunoriGoto1と申します。Fujitsuの中の人です。

私は現在、本業としてLinuxの不揮発メモリの開発に取り組んでいます。
そのかたわら、OSSの開発者を増やすことを私のライフワークとしていて、Fujitsu社内／社外でいろいろな活動をしています。

ちなみに、先月CROSS2017というイベントに行ったのですが、こんな感じで自己紹介を晒してました。

今回、FujitsuのOSSの開発者を増やすための活動として、 Fujitsu社内 でOSS Gateのワークショップを実施することができました。
これは、そのときの開催レポートです。

OSS Gateとは？

OSS Gateは、もともとはFujitsuとは関連があるわけではなく、思いを同じくする”有志”による取り組みです。
そのWebページでは以下のように紹介されています。

「OSS Gate」は、OSS開発に参加する「入り口」を提供する取り組みです。
OSS開発に未参加の人を参加する人へ、少し参加したことがある人を継続的に参加する人へ。
そうやってOSS開発に参加する人を継続的に増やしていく。それが「OSS Gate」の目的です。

この取り組みの活動の一つとして、OSS Gateワークショップがあります。
これは、OSSのコミュニティに参加したことがない未経験者の人に対して、経験者の方が隣についてコツを教えてあげながら、OSSコミュニティに質問やバグ報告を行う体験を 実際に してもらうという勉強会イベントです。
現在では、この様子のレポートや、ビデオも公開されているので、
実際の様子がどんな感じで行われているか？については、これらの資料からも分かると思います。

私はこの活動に大いに賛同し、これまでも微力ながらOSS Gateの取り組みに協力してきました。
しかしその一方で、社外だけでなく、常々 Fujitsu社内でも こういう活動が必要だと考えていました。

そこで、弊社ソフト教育部門にOSS Gate ワークショップの社内の実施を強くお願いしました。
またワークショップ実施に当たり、講師には須藤さん（クリアコード）をぜひお呼びしたいとお願いしました。
須藤さんは、ご自身もRuby系の様々なOSSを開発していらっしゃるだけでなく、
OSS Gateの主催として取りまとめていて、現在、様々なところでOSS Gateの取り組みを展開されています。

この結果、教育部門には色々な形で協力いただいて、今回のワークショップを実現することが出来たのです。

なぜOSSコミュニティに参加するの？

なぜ、会社としてOSSコミュ二ティに参加するのかというと、会社の立場、個人の立場、それぞれ色々な理由があると思います。
これについては非常に深いテーマで、書き出すと非常に長くなります。

しかし、ただ一つだけ伝えたいことを書くとするなら、私は、 Fujitsuの中のエンジニアが、OSSコミュ二ティという外の世界の人と触れられる場所に出て欲しいと 願っているからです。

これは、外の世界の人と触れることによって、

今まで社内だけでは分からなかったことに気がついたり、
あらたな人脈を築いたり、
新たな価値を生み出して欲しいと考えているからです。

先日も隣に座っている２年目の若手にちょっとした機能提案をさせたのですが、Intelのメンテナの方が相談相手としてFacebookの中の人を召還してました。
会社の中に閉じた仕事をしていると、Facebookの中の人の話を伺う機会は中々無いですよね？「OSSコミュ二ティに参加することで、初めて知ることが出来る世界がある」と私は信じています。

社外に出るのは怖い？

とはいえ、社外に出てOSSコミュ二ティに参加しようとするのは、色々な心理障壁があるのも事実です。
この中でも、心理障壁として象徴的だった、あるエピソードを記載します。

ワークショップの開催前のある日、参加予定者（後で分かったのですが、今年の新人）の方から以下の質問が届いたのです。

Githubアカウントを登録する際に用いるメールアドレスには
社内メールアドレス(@jp.fujitsu.com)の利用は可能でしょうか？
：
(中略）
：
社内規約等で社外サービスへの社内メールアドレス(@jp.fujitsu.com)の登録が
制限・禁止されているのではないかと考えました。
：
（以下略）
：

( ﾟдﾟ) ・・・ (つд⊂)ｺﾞｼｺﾞｼ (；ﾟдﾟ)？！

こういう点から、許されているかどうかをわざわざ確認したくなるとというのは、正直言うと私にとってかなり衝撃的な質問でした。新人の方がこういう「許しを得ないといけない」と感じる雰囲気みたいなものが、うちの会社予想以上に強くて辛いのだろうか？と。

実際には、私自身や私の所属する部署、さらにはFujitsu社内の色々な部署から、業務としてLinuxやOpenStackなど様々なコミュニティに会社のメールアドレスで投稿しています。また、これは他の多くの会社も同様です。前述の通り統計を取ってOSSへの会社の貢献度を会社としてアピールしていますから、むしろ会社名で投稿するのは必須と言っても良いぐらい。このような情報が伝わっていない要因はなんだろう？そして、どうあったら、この雰囲気を変えられるだろうか？と考えることになりました。

このときは結局、私と教育部門で、以下のような回答をしました。

教育受講とはいえ会社の業務であり、会社名義で問題ないこと。
（業務なのにプライベートのメールアドレスを使うことのほうが問題。）
OSS Gate開催にあたって、社内の各所とはすでに調整済みであること。
（実際、GitHubという公開の場所を使って、メモ書きすらも公開するワークショップを行うというのは、会社としてもはじめての経験でしたが、教育部門と共にがんばって各所と調整して、GitHubを使ったワークショップを実現しています。）
すでに私をはじめとした様々な人が、会社名義でOSSコミュニティに参加し、OSSの開発をしていること。
前述の通り、会社名義のパッチの数などをカウントして、「Fujitsu」のOSSへの貢献度として色々なところでアピールしていること。
そしてなによりも、質問者の方自身がFujitsuを代表するOSSの貢献者として、将来上記のようなアピールができるような人材になって欲しいこと！

会社のルールとOSS

とはいえ、会社として参加する以上、知財面のリスクなどの注意すべきことはやっぱりあります。
弊社、知財面ではOSS参加ガイドラインがつくられています。
これは、Japan Technical Jamboree 60で対外発表しているぐらい立派なものなのです。

しかし、こういうルールがあると、一人のエンジニアレベルでは 「あ、手続きメンドクサイ」 と敬遠してしまいがちです。「知財部門ってOSSに理解が無いよね？」みたいに思っていたり。

じゃあ、実際のところはというと、知財部門の方と実際に話すと分かるのですが、別に知財として「OSSコミュニティに出るな！」なんて言うつもりは まったく無い のですよね。
直接話を伺うと、 「むしろ、どんどんOSSコミュニティに出て欲しい」 とお話してくれます。

私は知財部門とは面識があることもあって、このOSS Gate実施にあたって、
社内の手続きについては事前にかなり協議しました。
その議論の結果、以下のメッセージを参加者の方々に伝えていこうという結論になりました。

今の社内ルールは、たしかに一見難しく見えている。しかし、よく読んでみると当たり前のことが書いてあるし、実際に手続きをしてみると思ったほどの手間にはならない。
現在の法律の下では、知財面からはこれ以上は簡略化が難しいという最低限のルールにしてある。
ルールを守ってさえくれれば、 何か問題がおきた時でも会社としてあなたを守ることができる 。
オープンソースライセンスや、OpenStackのContribution License Agreement のようなエンジニアには難しい文章の解釈について、この社内手続きを行うことで 知財・法務の専門家がサポートしてくれる便利なルール と、むしろ考えて欲しい。

これについては、当日のワークショップの最後に、知財さんから皆さんにお話しすることになりました。

OSS Gate ワークショップの開催の様子

SIerと言われ、色々な厳しいご意見を頂く弊社ですが、OSSコミュ二ティに参加したり開発した経験のある人は弊社にもいます。当日は、そういう人の中から仕事の都合がつく人を、受講者の指導をするサポーターとして５人集めました。

そして、初心者、すなわちビギナーの方も１０名程度集まりました。今回は、社内勉強会のメーリングリスト（現在８００人ぐらい参加）で、思いっきり宣伝したのが効いた様で、満席で参加できないという方もいました。（今回参加してくれた中には、須藤さんが来るということで参加してくれた方もいたようです。）

扱うOSSとしては、弊社がOpenStackを推進していることもあって、OpenStackのテーマを選ばれる方がやや多かったようです。

そして、始まると皆リラックスして励むことが出来たようです。なんといっても、須藤さん、いい意味でいつも「ふわっと」した柔らかいトークをされていて、それが非常に効果的だったと思います。

OSS Gateワークショップの内容も、外でいつも行っているワークショップと大体同じ形で進めることが出来ました。

OSS Gate ワークショップをやってよかったこと

Fujitsu社内でOSS Gate ワークショップをやってみると、やっぱり社内でやってみて良かったなと思います。

OSS Gateは、普段土曜日や残業時間などに活動していますが、時間やお金の面で中々都合がつかないとかある人もいると思います。そういう中で、会社の正式な教育として実施できた（つまり出張として扱うことができる）のは、意義が大きかったかな？と思っています。

また、常日頃から感じていたことですが、以下の点がOSS Gate ワークショップの長所だと思っていてこれを社内に伝えることが出来たのも良かったと思っています。

1. 「初心者だからこそ」の参加の仕方を教えてくれた

OSSの開発と言うと、すごい技術者がすごいソースを書く必要があるというイメージを持ちがちです。
そして、実際コミュニティにはすごい人も沢山います。
しかし、すごい開発者だからこそ、初心者がつまづくところが逆に分からなかったりします。
そういうところを分かりやすくするのは、初心者だからこそできることなのです。
当日は、そのような簡単な修正からやってみようということを勇気づけてくれました。

2. まずは質問やバグ報告からでOK

OSSコミュニティに質問やバグ報告をしている人は案外少ないですよね。
実際、弊社でアンケートをとってみると、OSSを使っている部署は凄く多いのに、「質問やバグ報告を行っていますか？」と聞くと驚くほど少ない…。
実際のところ、みなさんQiitaとかで回避策を探したり、Twitterで愚痴をいうだけで終わったりしていませんか？（正直、気持ちはとても良くわかります。）
でも、OSSコミュ二ティ内で、その詰まったところについて、公式ドキュメントを分かりやすく直してもらうことで、今後は愚痴を言ったりする必要はなくなります。
OSS Gateでは、「ちょっとしたことを直すだけでも意義がある」と教えてくれます。

3. ほとんどのことをGitHubで行う

ワークショップでは、参加者の作業ログ、アンケート、また、運営側の進行方法やプレゼンの資料に至るまで、ほぼ全てに対してGitHubを活用しています。（例外は、chatのためのgitterと、募集のためのDoorkeeperを使っていることぐらいでしょうか？）さらに、最後の参加者のアンケートは、YAML形式で回答した後、GitHubでpull requestを出す形になっています。

GitHubに慣れていない人が弊社にはまだまだ沢山いる中で、実際に触ってpull requestまでの一連の流れを体験してもらう非常に良い機会となりました。

4. 良い意味で「ふわっと」している

弊社、（私も含めて）良くも悪くも「かっちり」しているんですよね。
皆色々苦労してきているので、経験を踏まえて色々なリスクに対する準備を 用意周到に 行うのが普通になって、中々先に進めない。動かない。
でも、最初の第一歩を踏み出すべき初心者にとっては、それだとむしろマイナスの効果が大きい…。

OSS Gateでは、須藤さんのお人柄も大きいのですが、「とにかくやってみようよ」って声をかけることで、
初心者の人を前進させるように勇気付けてくれます。これがまた、あらためていいな！って思いました。

5. 最後にその場で振り返る

アンケートをとるのはどんなイベントでも行いますが、大体は終わってから後で集計しますよね？
でも、終わってからのアンケート集計だと、結果が分かるまで時間がかかります。
その間に熱が冷めたりして、（特に参加者にとって）次の行動につながらない可能性が高いです。

OSS Gateでは、”ワークショップの時間中に皆でその結果を確認し、参加者も運営側も今後の活動の継続･改善に繋げる”
というスタイルを取っています。その場で皆で振り返れば、だれもが次の行動にすぐ移すことができます。

最後に

アンケートでは非常に好評だったこともあり、次回以降も機会を設けてFujitsu社内でも今回のような取り組みを続けたいと考えています。

一方で、社内で実施したゆえの課題が残りました。特に、当日はビギナーの方がproxyの設定につまづいてgithub.comへのgit pushが通らなかったりしたのは、今後改善していきたいと思います。

謝辞、その他

何よりも、本OSS Gateを発案･主催し、当日のワークショップの講師を務めてくださった須藤さんに深く感謝します。
須藤さんがいなければ、このような取り組みを行うことは出来ませんでした。また、これまでOSS Gateに協力・参加してくださっている他の有志の方々全員にも感謝いたします。

さらに、弊社の教育部門、知財部門をはじめ、今回の実施提案と本レポート公開を受け入れ、調整に協力していただいた関係者の方々に感謝します。

なお、オリジナルの（つまり、富士通社外の有志の）OSS Gateも、定期的に開催していたり、関西などの各地で活動を展開しています。これについては、Doorkeeperで募集しているので、そちらもチェックしてくれると、個人的にもうれしいです。

以上

オープンソース開発プロジェクトの参加者になるワークショップ「OSS Gateワークショップ」

Sat, 24 Sep 2016 00:00:00 +0000

「OSS Gateワークショップ」は、OSS開発プロジェクトに参加したことがない人が、開発プロジェクトの活動を実際にやってみようというワークショップです。

自分が興味を持つOSS開発プロジェクトを選んで、ドキュメントのミスを直したり、バグレポートやパッチを送るといった活動を、4-5時間かけて実際に行います。もちろん、この短時間では充分な活動になりませんが、オープンソース開発プロジェクトに関わる最初の一歩になるはずです。

OSS Gateワークショップは、2016年の3月に始まり、2か月に1度のペースで、開発コミュニティの有志によって開催されています。

今回は、この「OSS Gateワークショップ」について、詳しく紹介します。

オープンソース開発プロジェクト敷居は高い?

システム開発では、不可欠な存在となったオープンソースソフトウェア(OSS)。あなたは、その開発プロジェクトに、どんなイメージを持っていますか？

GoogleやFacebookに所属している凄いハッカーが、ネットを介してバリバリとコードを書いているとか、イケてるWebサービスのCTOが、華麗なパッチを次々と投稿しているとか、あるいは、コンピュータサイエンスの天才的な研究者が、秘蔵のライブラリをネットで公開しているとかいった感じでしょうか。

とにかく、敷居は高そうですよね。普通のエンジニアには、関係のない世界のような気がするでしょう。

でも、本当は違います。もちろん、スター開発者もいるのですが、OSSの開発プロジェクトを支えているのは、非常に地道な活動の集まりです。書くべきコードはたくさんありますし、テストやドキュメント、バグレポートやプラグインなども必要です。そういう地道な活動成果が十分に集まるおかげで、現在のOSSの盛り上がりがあるのです。

伽藍とバザールで紹介された「リーナスの法則」のように、「目玉の数さえ十分あれば、どんなバグも深刻ではない」のです。

しかし、開発に参加してくれる人たちが十分に存在しなければ、話になりません。

そこで、開発コミュニティの有志が、OSS開発プロジェクトに参加したことがない人向けに、開発プロジェクトの活動の一端を実際に行ってもらうワークショップを開催しています。それが、「OSS Gateワークショップ」(Doorkeeper、GitHub)です。2016年の1月から始まって、2か月ごとの開催ですが、毎回多数のキャンセル待ちが出る人気イベントになっています。

未経験者が経験者になるワークショップ

ここ数年、GitHubの普及により、開発プロジェクトからソースコードを入手したり、活動の様子を垣間見ることが、かなり手軽になりました。しかし、オープンソース開発プロジェクトへの新しい参加者は、決して多くありません。これは、どの開発プロジェクトでも共通していると思います。

OSS Gateワークショップの参加者に、開発プロジェクトに参加していない理由を聞いてみると、「本業の仕事が忙しい」「間違ったことをするんじゃないかと不安を感じる」といった答えが返ってきました。

OSS Gateワークショップの目的は、このようなオープンソース開発プロジェクトの参加経験がない人を、経験者に変えることにあります。参加者も、そんな感じの人たちが集まっています。そして、このような活動を通じて、OSS開発者を継続的に増やしたいという目論見があります。

OSS Gateワークショップが始まったきっかけの一つは、2015年に開催されたOSS Hack Weekendというイベントでした。Ruby開発やリーダブルコードのあとがきなどで有名な、クリアコードの須藤功平さんを中心にして、学生を対象にして最初のワークショップが開催されました。そこで、「OSS開発プロジェクトに未参加の人は参加方法がわからないだけで、参加方法がわかればOSS開発に参加できる」という手応えを得たことから、このような取り組みを継続的に行っていくOSS Gateが始まりました。現在では、RubyやLinuxカーネルの開発者などが、参加しています。

キャンセル待ちの多い、人気の高いイベントに

OSS Gateは、これまでに6回のワークショップを開催しました。そのうち1回は、東京Ruby会議11に合わせて行われました。また、9月から札幌でもワークショップが始まっています。

ワークショップは、約10-20名程度のビギナー(これまでOSS開発に参加したことがない人)と、ビギナーにアドバイスをするメンター(OSS開発に参加したことがある人)で構成されています。メンター1名に対して、ビギナー1-2名というかなり手厚い体制です。

これまでに、のべ70名程度のビギナーの人が参加してくれました。ここ最近は、多くのキャンセル待ちが出る、人気の高いイベントになっています。

では、実際のイベントの様子を紹介しましょう。9月24日のワークショップは、恵比寿ガーデンプレイスにあるクラウドワークスのMixlab（ミックスラボ）というイベントスペースで行われました。

ワークショップが始まると、各自がノートPCやMacBookを持って席に着きました。このとき、メンターの両隣にビギナーが座るという形で始まりました。最初は、アイスブレイクを兼ねた自己紹介です。日ごろ、どんな開発に関わっているかとか、使っているプログラミング言語とかを紹介すると、みんなエンジニアなので、かなり盛り上がっていました。

実際のイベントは、要所要所で、OSS開発プロジェクトの勘所や次にやる作業などの説明が入りますが、かなり黙々と進んでいきました。

まず最初に、ビギナーは、自分が題材にするOSSをひとり一つ選びます。普段使っているものでも良いですし、興味を持っているだけのものでも構いません。メンターと相談しながら、題材を決めたら、それを実際に手元にインストールして、「Getting Started」などのドキュメントに沿って試してみます。そうすると、何かしらつまずいたり、インストール手順が情報不足だったり、サンプルコードが間違っていたり、typoが見つかったり、なんて事が起こります。

そんな時、これまでなら、愚痴るか、Twitterでつぶやくか、Qiitaで回避策を書くしかなかったかもしれません。

しかし、そこが開発プロジェクトにフィードバックするチャンスなのです。

OSS開発プロジェクトの参加経験者がメンターとなり、手厚くアドバイス

このようなポイントは、開発者としてもなかなか手が回らないところです。初めて使う人がどういう場所でつまずくか、開発者はなかなか知ることができません。そういうポイントを見つけて、気軽にバグレポートやプルリクエストを送ってみると、意外と簡単に開発プロジェクトに取り込んでもらえるのです。一度、修正してもらえれば、その分だけOSSのサポート品質が向上しますし、他の人がつまずくこともなくなるという訳です。

この最初の調査は、ビギナー各自が、OSS Gateでワークショップ用に用意した、GitHub上のIssueという課題管理機能に、作業ログとして書き込んでいきます。そして、メンターは、この作業ログをベースにして、開発プロジェクトへのフィードバックの方法をアドバイスしていきます。

ビギナーが選んだ題材について、メンターが詳しくないこともあるのですが、レポートの粒度を小さくしたり、開発版と安定版のリポジトリを確認したり、パッチの送り方を調べたりと、開発プロジェクトに参加してきたからこそ気づくポイントもあります。逆に、題材のOSSを知っていると、教えすぎないように我慢するのが大変だそうです。あるメンターさんが、「詳しく知らなくても、ビギナーの半歩先を行くぐらいが、ちょうどいい感じだ」と言っていたのが印象的でした。

ちなみに、、メンターがベテランで、ビギナーが若い人とも限りません。20代-30代でも、OSS開発プロジェクトでの経験があれば、メンターをやっていますし、エンジニアとしてはベテランでも、OSS開発者としては経験が少ないという人も参加しています

最終的に、ビギナーは、Pull-Requestやバグレポートを送ることを目指します。ここでも、バグレポートをどう書くべきか、こんな英語で通じるかとか、いろいろ悩みどころがあります。メンター同士でディスカッションしている場面も少なくありません。開発プロジェクトごとに流儀は違っていますし、そもそもレポートの書き方に正解はないので、ここはメンターに背中を押してもらって、エイっとばかりに送信します。

また、課題によっては、ワークショップの時間内では、環境構築に時間がかかり過ぎてしまうとか、見つけた課題の解決策を発見できないなんてことも起こりました。しかし、自分ひとりでは行き詰って時間ばかりが無駄に過ぎていくような場合でも、他の開発者はその過程でどんな作業をしているか、メンターを通じて体感することができるのです。

そして何より、ビギナーにとって、これは開発プロジェクトへの参加の第1歩です。ワークショップの時間内に終わらなくても、また続きをやればいいのだと思います。

今後の展開

ワークショップに対する評価は、おおむね高いようです。9月24日に東京で開催されたワークショップで、開催後に行ったアンケートでは、ビギナーのほとんどの人が、満足したと回答していました。

ワークショップの具体的な流れは、こちらの開催レポートに詳しくまとまっています。また、ビギナーやメンターの感想など、ブログなどでも公開されています。これは、過去のイベントページにも掲載されています。Twitterの#oss_gateでもたどることができます。

さて、OSS Gateでは、今後も継続的にワークショップを開催していく予定だそうです。

もしも、OSS開発プロジェクトに参加したことがない人で、OSS Gateに興味がある人は、イベント管理サービスDoorkeeperのOSS Gateページで、「コミュニティに参加」ボタンを押しておくと良いでしょう。そうすれば、次回の開催案内があったとき、すぐに知ることができます。

また、OSS Gateでは、OSS開発プロジェクトの参加経験があるメンターも募集しています。ビギナーの増加に合わせて、メンターが足らなくなるという心配もあるので、教えるのが好きな開発者は、ぜひ参加してみてください。

何より、自分たちのところでOSS Gateワークショップを開催してみたいという方が、どんどん増えてくると良いと思います。OSS Gateページから、主催者に問い合わせてみてください。

OSS Gateが盛り上がり、新たな開発者が増えると共に、開発プロジェクトがますます活性化することを期待しています。

2016.09 可知豊 - CC BY 4.0

参考ページ

OSS Gateワークショップ2016-06-11開催レポート

Sat, 11 Jun 2016 00:00:00 +0000

2016年6月11日（土）にOSS Gateワークショップを開催しました。

これまでのワークショップは広く参加者（ビギナーとメンター）を募集していますが、今回のワークショップは1つの企業の社員だけで開催しました。ビギナーもメンターも社員です。強制参加ではなく、希望者のみの参加です。この点はこれまでのワークショップと同様です。メンター全員が未経験者なのは一番最初のワークショップと同じです。なお、進行役だけは経験者である須藤が担当しました。

OSS Gateについての説明は、OSS Gateへようこそ！という記事をご覧ください。次回のイベントはOSS Gateワークショップ2016-07-30 - OSS Gate | Doorkeeperですが、現時点では満員になっています。 9月24日でもいいよという方はOSS Gateワークショップ2016-09-24 - OSS Gate | Doorkeeperに登録してみてください。

今回のワークショップでこれまでと違うところはレポート係というワークショップの内容をまとめる専門の人をおいたところです。これまでは、参加した人それぞれにブログにまとめてね、としていましたが、今回はまとめることに専念する人がいました。

レポートをまとめる目的は以下の3点です。

OSS Gateの取り組みを世に広め、OSSの開発に関わる人を増やす
ワークショップのやり方を広め、進行役・メンターを増やしたり、東京以外での開催を支援する
レポート係が客観的にワークショップの進め方を観察することで、ワークショップの改善点を見つけ、次回に活かす

今回もいつものように以下のような流れで進めました。

座席の配置
OSS開発手順
- 立場の説明
- アイスブレイク
- 開発対象のOSSを決める
- 作業メモについて
- 動かしてみる
- 他の人に説明する
昼食
フィードバック
- 整理する
- 編集する
- 報告する
- 他の人に説明する
まとめ

座席の配置

今回は、メンター（ビギナーをサポートする人）が5人、ビギナー（OSSの開発に参加したいけどまだできていない人）が12人と、1:2くらいの割合でした。メンター1人につきビギナーを2人くらい見ることになる計算です。

席の配置は重要です。メンターがビギナーをうまくサポートできるかどうかに関わるからです。ポイントはメンターとビギナーを隣同士にすることです。隣りにメンターがいないとビギナーは聞きにくくなります。メンターの目が届かないビギナーも出やすくなります。

これまではメンターがビギナーの2倍いることが多かったので1人のビギナーを2人のメンターで挟んでいましたが、今回は割合が逆なのでメンター1人の横にビギナー2人が座るようにしました。

ビ: ビギナー
メ: メンター
□: 机

スクリーン・ホワイトボード
　      進行役

ビ□ビ  ビ□ビ  ビ□ビ
メ□メ  　□メ  メ□メ
ビ□ビ  ビ□ビ  ビ□ビ

6人座れる島を3つ用意して、3つのグループに分けました。3人ずつの島を6つ用意することもできますが、そうすると横幅が広がって進行役が進め方を伝えるときに伝えにくくなるので3つの島にしました。体を横にするとスクリーンを見えるようにした（後ろを向かなくても全員がスクリーンを見れるようにした）ことも進行役が進めやすくするためです。

メンターが1人しかいないグループは進行役がサポートしました。

メンター1人につきビギナー2人だと、メンターが1人のビギナーにかかりきりになるともう1人のビギナーをサポートできなくなります。かかりきりになるような場面のときは進行役がサポートに入り、サポートが必要なビギナーが放置されないようにしました。

この体制で実施したところ、（未経験の）メンター1人につきビギナー2人という割合でもまわることがわかりました。これまではメンター2人につきビギナー1人という割合でやることが多かったので、どれだけメンターが少なくても大丈夫なのかはわかりませんでした。今回の経験はこれからの基準として使えそうです。

ただ、課題はありました。午後に数人のビギナーが同時に進行役のサポートが必要な状態になり、サポート待ちのビギナーがでる状態になりました。今回、進行役がやったような「メンターをサポートするメンター」を数人用意するとうまくまわりそうです。そうすればサポート待ちのビギナーを減らせます。この方法でうまくいくか、次回のワークショップで検証する予定です。

「メンターをサポートするメンター」が動きやすいように、それぞれの島の間に広めにスペースを作りました。これも席を配置するときの大事なポイントです。

OSS開発手順

以下の資料を使ってこのワークショップで体験するOSS開発手順を説明しました。

これまでと同じ資料を使っていましたが、資料をベースにしつつも随時説明を追加したり省略したりしました。進行役をできる人が増えるようにするためには、資料を更新し、須藤以外でも進行しやすいものにする必要があります。これは次回のワークショップでの課題です。

OSS Gateワークショップ（チュートリアル） - OSS開発手順

立場の説明

ビギナーとメンターの立場を説明しました。

ビギナーは、OSSの開発に参加したい人や、参加したことがあるけどまだ不安がある人です。目的はOSS開発に参加する（経験する）ことなので、なにかすごいことをする必要はありません。

メンターは、ビギナーをサポートする人です。相談されたときは答えを教えないことがポイントです。教えるのではなく、一緒に考えたり、一緒に調べたり、一緒に悩みます。具体的な言い方にするとこうです。サポートするときに自分のパソコンを使わないでください。検索するならビギナーのパソコンで検索します。動かして動作を確認するならビギナーのパソコンで動かして動作を確認します。それが「一緒に」ということです。ビギナーの目の前で「一緒に」やることで「メンターはすごいから自分でいろいろ解決できるんだよ」感を減らします。「結果」だけ与えられるとそう感じやすくなります。「過程」も経験すれば「自分でもできそう」感が増えます。

アイスブレイク

ワークショップをより充実したものにするためにいつもアイスブレイクを行っています。今回のワークショップでも行いました。

アイスブレイクの内容は、同じ島の人になぜ参加してみようと思ったかを話す、です。この内容にしている理由は次の通りです。

なにかしら理由があるはずだから話す内容に困らない
参加した理由を自分で再確認する機会になり、ワークショップでなにを得たいかが明確になりやすい
メンターがビギナーをサポートするときに助かる情報があるかもしれない

他に、「声を出すこと」自体がポイントです。一度声を出しておくと質問したり声をかけたりしやすくなるものです。

開発対象のOSSを決める

今日のワークショップでビギナーが開発対象にするOSSを決めます。決めるときはメンターがビギナーをサポートします。

これまでのワークショップではワークショップ開始前に進行役がすべてのビギナーの開発対象OSS決めをサポートしていました。メンターがすべてのビギナーの開発対象OSS決めをサポートをするのは今回がはじめてです。

メンターにビギナーのサポートの仕方を伝えるため、ビギナー1人に進行役の隣に来てもらい、決め方を実際に見せました。決めるときのポイントは、普段使っていて思い入れのあるものを選ぶことです。調べなくても名前が出てくるものや、どの機能で使っているかわかるものが望ましいです。有名なものよりも自分にとって思い入れのあるものを選びます。

実際に決め方を見せることにより未経験のメンターでもビギナーをサポートできることがわかりました。これは今回のワークショップで得られた知見です。

作業メモについて

何か新しい作業を始めたり、作業中に詰まったら、メモを残してもらいます。たとえば、インターネットで検索しようとしたときは「作業中に詰まった」ときなのでメモを残すポイントです。

メモにはできるだけ再現できる情報を書きます。実行したコマンドや表示されたエラーなどを省略せずに残しておくことが大事です。自分は不要だと思って省略した情報でも、開発者にとってはヒントになったりするからです。

作業メモを一覧しやすいように、作業メモはOSS GateのGitHub Issuesに作成しました。

動かしてみる

OSS開発手順の説明が終わったら、選んだOSSを実際に動かします。このときのポイントは、ユーザーとして動かすことです。動かしてみて詰まったことは都度メモしておき、あとで報告できるようにしておきます。

ビギナーは作業をしているとメモをとることを忘れてしまいがちです。ビギナーがメモをとることを忘れていそうなときにメモを取ることを思い出すようにすることは、メンターの大事な役割です。

他の人に説明する

午前の部の最後に、ビギナーはメンターに午前中にやったことを説明します。このとき、作業メモをベースに説明します。説明するメンターは違う島のメンターです。つまり、サポートしてもらっていたメンターとは別のメンターに説明します。

メンターはビギナーからやったことを聞いて次のようなことをフィードバックをします。

実は問題なのにスルーしてしまっていたり、無意識にやっていたけど実は大事なことだったといったことに気付くきっかけを与える
この後どうすればよいかわからなくなってしまった人には、次にどう進めばよいかのアドバイスをする

この時間はメンターとビギナーが一対一で話すことになるため、片方のビギナーが話を聞いてもらっている間は、もう片方のビギナーには二人の近くに行って話を聞きます。他のビギナーのやったことから学ぶ機会にします。

ここでも、最初にビギナー1人に進行役の隣に来てもらって例を示しました。以下のようなやりとりをしました。

進行役：「まず何をしましたか？」
ビギナー：「READMEを読みはじめました。長いなーと思いながら読み始めました。」
進行役：「READMEを見ながら話をしましょうか。（メモにREADMEへのリンクがなかったのを見て）READMEへのリンクをメモしておきましょうか。」
ビギナー：「READMEを読んでいたらRailsプロジェクトを作らないと試せないとわかったのでRailsプロジェクトを作り始めました。」
ビギナー：「Railsプロジェクトを作ろうと思ってrails newをしたらエラーがでたんですよね。」
ビギナー：「最初なにが悪いかわからなかったんですが引数が足りないのが悪いとわかったので…」
進行役：「ちょっと待ってください。もしかしてエラーメッセージが違ったらすぐになにが悪いか気づけたりしましたか？」
ビギナー：「あー、もしかするとそうかも…？」

昼食

ここで昼食休憩に入りました。チームごとにまとまってお昼ごはんを食べに行きます。

雑談で自分が使っているOSS開発に便利なツールを紹介している人がいました。こういう話を日常的にできるとよいですね。

フィードバック

午後からはフィードバックの時間です。以下の資料を使いました。

OSS Gateワークショップ（チュートリアル） - フィードバック

まず、改善できる箇所が見つかった人がどのくらいいるか確認しました。8割程度の人が見つかっていたので午後からはすぐにフィードバックをすることにしました。まだ見つかっていない人は進行役が順番にフォローすることにしました。ここでサポート待ちの人が増えてしまったことが課題です。「メンターをサポートするメンター」数人の体制で解決できないかを次回のワークショップで検証します。

まだ改善できる箇所を見つかっていない人に進行役がした質問は以下のようなものです。

今日やったことを教えてください。
なぜこれにしたんですか？
何が知りたいですか？
何を知れなかったですか？
どうなっているとよかったですか？

改善できる箇所が見つかった人はフィードバックを進めます。報告は以下の3ステップで進めます。

整理する
編集する
報告する

整理する

まず、ビギナーは自分にわかる文章としてまとめます。他の人にわからなくても自分がわかればOKです。

メンターは質問したり話をしたりしてビギナーの考えを整理します。

編集する

次は、報告を受ける側の開発者にとってわかりやすい文章にします。報告方法をまとめているOSSもあるので、その場合はそれに沿った報告方法にします。メンターは、自分が報告を受けたときはどういう情報があるとうれしかったかという経験に基づくアドバイスします。

OSSを開発しているのは日本の人だけはありません。いろいろな国の人が開発していることがあります。そうすると時間的・空間的に離れていることがあります。活動時間帯が異なると、1回のやりとりに丸一日かかってしまうことがあります。できるだけやりとりが少なくて済むように、想像しなくても伝わるような情報を提供することがポイントです。そのためには、やったことだけでなく、やっていないことも書くとよいです。

報告する

今回はすべてのOSSがGitHubを使っていました。

GitHubの報告方法には主に2種類あって、報告だけ（issue）の場合と、パッチを添える（pull request）場合があります。すぐにパッチを作れるのであればpull requestでよいです。実際の変更があった方が説明だけよりも伝わりやすいからです。すぐに作れない場合は作れるまで待つよりも、issueとして報告する方がよいです。後で報告しようと思ったまま忘れてしまうかもしれないからです。忘れてしまうよりは報告してあった方がよいです。

報告に対して開発者から反応がある前にパッチができたら後からpull requestを作ることもできます。そのpull requestに「このissueに対応するものだよ」と書いておけば伝わります。無理して最初からpull requestにする必要はありません。

このフェーズは、OSS開発の経験が少ないメンターだと難しいと感じることがあるかもしれません。そのときは、他のメンターや進行役に相談します。困ったときは相談する、というのはビギナーでもメンターでも一緒です。進行役がビギナーのサポートを引き取ったときは、ビギナーのサポートが一段落した段階でメンターに現状を共有し、その後のサポートを引き継ぎました。

以上の整理する、編集する、報告するという流れでは特に区切りを設けずに、それぞれのペースでやりました。メンターに見てもらってOKもらったら報告するというのがひとつのゴールで、それをみんなが一度は経験するというのを目指しました。

進行役がビギナーのサポートを多めに引き受けてしまい、予定よりも長めに時間をとることになってしまいました。このあたりも「メンターをサポートするメンター」を数人導入することで解消できそうです。

メンターからのよくあるアドバイス

説明が漠然としていたのでもう少し具体的にしたほうがよいというアドバイスはいろいろなところで聞かれました。ビギナーは開発者なら察してくれそうと思ってしまいがちですが、そういうことは期待しないほうがよいです。調べるのが難しいなら無理をしてまで調べる必要はありませんが、調べたことであればもれなく伝えます。

改善してほしい理由に対して指摘が入る場面もありました。ビギナーはつい「一般的には」という理由を使ってしまいがちですが、そうではなく「自分は」どうかという視点のほうがよいです。

例えば、RDoc形式のドキュメントをMarkdown形式に直してほしいとします。そのときに、「一般的にRDoc形式よりもMarkdown形式のほうがいい」という説明では、そのプロジェクトでの必要性が伝わりません。それに対して、「自分はドキュメントを改良したいけど、RDoc形式では書きたくない。Markdown形式ならドキュメントを改良してもいいと思っている」という伝え方をすれば、「改良してくれるならMarkdown形式にしてもいいかな」と開発者が思ってくれるかもしれません。

他には、複数の問題があるときに、どこまでをこのissueでやるのかといったアドバイスも行われていました。

他の人に説明する

すべての作業が終わった後に再びビギナーがメンターにやったことを説明する時間があります。

午前の最後に聞いてくれたメンターとは別のメンターに説明します。ポイントは午前の最後の時と同じで、ビギナーが気づいていなかった点を気づかせたり、気づかずによいことをしていたときによかったと気づかせたりすることです。

まとめ

さいごに、今日やったことをまとめました。資料は以下です。

OSS Gateワークショップ（チュートリアル） - まとめ

ビギナーには、詰まったらメモを残す進め方や、問題が見つかったときに直すという選択肢があることを経験してもらいました。また、OSS開発はすごいことをする必要はないことも伝えました。開発者はREADMEを読まないので、初心者だからこそ気づくこともあります。

アンケート

最後にアンケートをとってすぐに確認してワークショップ全体をふりかえりました。これはいつもやっていることです。

これまでのワークショップではGoogleフォームでアンケートをとっていましたが、今回はGitHubのリポジトリーに用意したYAMLファイルを編集してpull requestを送ってもらうことにしました。データをまとめることが楽になりそうだからです。

アンケート結果

ビギナー・メンターともに全員が「満足」・「すごく満足」したワークショップでした。また、想定以上（「想定通り」または「想定より充実していた」）の内容と感じていました。

ビギナーの多くはこれからはOSSの開発に参加するとのことでした。

メンターはサポートすることでいろんなことに気づくきっかけになったようでした。

おわりに

2016年6月11日（土）に開催したOSS Gateワークショップの内容をまとめました。

OSS Gateワークショップを通じてOSS Gateの取り組みを知ることはできたでしょうか？進行役やメンターをやってみたい人の参考になったでしょうか？

ワークショップに参加したいという方（メンターでもビギナーでも）は、DoorkeeperのOSS Gateコミュニティページに次のワークショップの情報があるので参考にしてください。OSS Gateメンバーに聞きたいことがある方はチャットルームを使ってください。

今回のように企業で開催したいという方は前述のチャットルームで相談してください。個別に相談したい場合は須藤（kou@clear-code.com）に相談してください。

2016年5月28日開催のOSS Gateワークショップは東京Ruby会議11と同建物で開催

Wed, 18 May 2016 00:00:00 +0000

OSS Gateワークショップ2016-05-28

2016年5月28日開催のワークショップOSS Gateワークショップ2016-05-28は東京Ruby会議11と同じ建物（秋葉原コンベンションホール）で開催します。東京Ruby会議11実行委員会から24名入る部屋を提供してもらったからです。ありがとうございます。

東京Ruby会議11ではOSS Gateに興味のある人が質問したりワークショップを見学できる機会を設けています。東京Ruby会議11に参加する方でOSS Gateに興味のある方は須藤さんを捕まえてください。

Rubyist向けOSS Gateの説明

一般的なOSS Gateの一般的な説明はOSS Gateへようこそ！にまとめてあるので、ここではRubyist向けにOSS Gateを説明します。

「OSS Gate」とはOSS開発に参加する人を増やす取り組みです。Rubyist向けに言い直すと、「gemの開発に参加する人を増やす取り組み」、「Ruby本体の開発に参加する人を増やす取り組み」と言ったところです。

「開発に参加する」というと敷居が高いと感じるかもしれませんが、ここでは「問題にぶつかったことを開発者にフィードバックする」というくらいのことです。たとえば、「READMEに誤字があったので教えてあげる」、「インストールが失敗したので相談する」、といったことです。「バグを見つけたので修正してパッチを送る」、「遅いので高速化する」、といった技術的に難しいことだけが「開発に参加する」ということではありません。

たとえフィードバック内容が技術的に難しくなかったとしても、実際にフィードバックしない人が結構いるのではないでしょうか。OSS Gateではそんな人たちをフォローしてOSS開発に参加する人を増やしたいのです。

OSS開発に参加する人を増やす方法

具体的にどうやってフォローするかというと「一緒にやって経験してもらう」です。前述の通り、技術的に難しいことではないので、フィードバックしようと思えば技術的には簡単にできます。しかし、技術的なこと以外の障害があります。「やったことがないから」フィードバックしていない、「やったことがないから」フィードバックするという選択肢がなかった、という人もいるのです。そんな人たちが「やったことがある」人たちになればフィードバックできるようになります。つまり、OSS開発に参加する人が増えます。

この「一緒にやって経験してもらう」を実現するために、隔月最終土曜日に「OSS Gateワークショップ」を開催しています。そして、次回開催が東京Ruby会議11と同じ2016年5月28日なのです。

「gemの開発に参加したいとは思うけどなかなか手をだせない」、「Ruby本体の開発に参加したいとは思うけどなかなか手をだせない」という方はぜひOSS Gateワークショップに参加してみてください。gemやRuby本体の開発に参加することの敷居がグッと下がるはずです。

なお、東京Ruby会議11とOSS Gateワークショップのどちらにも興味のある人は東京Ruby会議11の方に参加することをオススメします。前述の通りOSS Gateワークショップは隔月最終土曜日に開催しているため、この後も何度もありますが、東京Ruby会議11は今回しかないからです。

東京Ruby会議11のチケットには割引チケットもあります。学生の方は割引対象です。（学生以外にも割引対象となる方はいます。）ぜひ活用してください。

「gemの開発に参加したい」、「Ruby本体の開発に参加したい」という方は2016年7月30日開催のOSS Gateワークショップ2016-07-30に参加してください。

協力者募集

OSS Gateワークショップは「OSS開発経験者がOSS開発未経験者と一緒にOSS開発を経験する」ワークショップです。そのため、このワークショップを開催するには「OSS開発経験者」が必要です。gem・Rubyの開発に参加したことがある（たとえばバグレポートをしたことがある）人はぜひ「メンター」としてOSS Gateワークショップ2016-05-28に参加してください。（あるいは今後のワークショップに参加してください。）

前述の通り、技術的に難しいことを経験するワークショップではありません。なので、「バグレポートはしたことがあるけど、しょぼいやつだったから自分はメンターはできない…」と思わないでください。内容は問いません。経験したことが大事なのです。もし、自分は大したことがないと思っているなら、「こんな自分でも開発に参加できたよ。あなたも大丈夫だよ！」とフォローしてあげてください。未経験者は安心するはずです。

それでは、みなさんの参加をお待ちしています。

OSS Gateへようこそ！

Thu, 17 Dec 2015 00:00:00 +0000

OSS Gateとは

「OSS Gate」とはOSS開発に参加する人を増やす取り組みです。2015年12月15日から始めた取り組みです。

取り組みの名前に「Gate」と入れたのは、まだOSS開発に参加していない人が参加する人に変わる「入り口」を提供する、という理由からです。

OSS Gateを始めた理由

OSS Gateを始めたのは「まだOSS開発に参加していない人が参加する人になるための支援の仕方がわかった」からです。つまり、OSS開発に参加する人を増やす方法を1つ見つけたということです。

1998年にオープンソースという言葉ができてから15年以上たった現在、OSSは当たり前のものとなり、知らず知らずのうちに使っているものになりました。あなたがこのページを読むために使っているWebブラウザーもOSSかもしれません。

このようにOSSが普及したのは、OSSを使っている人だけでなく、OSSを開発している人たちがいたからです。しかし、OSSが普及して知らず知らずのうちに使っている人が増えるに従い、「OSSの開発に参加できる」ということが忘れられていきました。まわりに若い人がいたら聞いてみてください。「使っている人ならだれでもOSSの開発に参加できるって知っていますか？」

「OSSの開発に参加できる」ということを知らないと新しくOSSの開発に参加する人も減っていきます。OSSの開発に参加する人が減っていくとOSSが衰退していくかもしれません。それを危惧しています。

これからもOSSが普及していくためにOSS開発に参加する人を増やしたい、そして増やす方法を見つけた、それがOSS Gateを始めた理由です。

OSS開発に参加する人を増やす方法

まだOSS開発に参加していない人が参加する人になるための支援の仕方は簡単なことでした。一緒にOSS開発に参加すればよかったのです。

まだOSS開発に参加していない人が参加していない理由は漠然とした不安だったのです。知らないこと・やったことがないことに対して不安を覚える、と言えばピンとくる人もいるかもしれません。

この不安は一度経験してみれば解消できます。経験すればそんなに心配することでもなかったということがわかるからです。「くぐってしまえば、別になんてことはなかった。」OSS Gateという門をくぐることでそれを実感して欲しいのです。

そういうわけで、OSS Gateは「OSS開発経験者」が「OSS開発未経験者」を支援するワークショップを開催しています。OSS Gateワークショップです。このワークショップでは、「OSS開発経験者」が「OSS開発未経験者」がはじめてOSS開発に参加することをサポートします。「そういうときはこうしたらいいよ」、「バグレポートを出す前にレビューするよ、そしたら安心して出せるでしょ？」、「自分も最初は不安だったけどやってみたら大丈夫だったよ、さぁ、やってみようよ」、そんな風にはじめてのOSS開発を後押しします。

なお、「OSS開発経験者」は「すごいOSS開発経験者」でなくて構いません。テクニックを教えることが大事なのではなく、経験することを後押しすることが大事だからです。「自分もこの間はじめてOSS開発に参加したけど大丈夫だったよ！むしろ楽しかったよ！」そんな人でもよいのです。そんな人のサポートが未経験者の不安を払拭するかもしれません。

協力者募集

「OSS開発に参加する人を増やす」というOSS Gateの目的に賛同する協力者を募集しています。OSS Gateは「継続的に」OSS開発に参加する人を増やすことを大事にしています。そのためには、特定の人に依存しすぎず、いろんな人たちで運用できる必要があります。特定の人に依存するとその人が動けなくなったときに活動できなくなるからです。

次のような人の協力をお待ちしています。

OSS開発未経験者をフォローする人
- 「すごいOSS開発経験者」でなくて「ただのOSS開発経験者」で十分です。ワークショップに参加してフォローしてください。
ワークショップ会場を準備してくれる人
- ワークショップを開ける会場を確保してください。
宣伝してくれる人
- もっとOSS開発未経験者、協力者を増やしてください。
- イベントで紹介したり、ブログに書いたり、いろんなやり方があるはずです。

協力してくれる方はGitHubのoss-gate organizationのメンバーに加わってください。やり方はメンバー参加方法に書いています。

他にもチャットで既存のメンバーとやりとりできます。気になることはここで質問してください。

なお、OSS Gateに協力する理由はなんでも構いません。たとえば次のような理由でも構いません。

サポートすることが好きだ
採用につながるかも
楽しそう
自分のプロジェクトの開発に参加する人が増えるかも
会社の宣伝になるかも
友達が増えそう
なんとなくよさそう
ユーザーが自由に使えるソフトウェアが重要であると考える人が増えるといいな

OSSはざっくりいうとユーザーが実行・改造・再頒布できるライセンスを設定したソフトウェアのことです。それに対してどのようなメリットを見出すかは人それぞれです。OSSはそういうものです。そのため、OSS Gateも協力する理由をどのようなところに見出すかは人それぞれで構いません。

みなさんの協力をお待ちしています。

参考情報

OSS開発に参加する人を増やす取り組み「OSS Gate」を開始 - ククログ(2015-10-20)：OSS Gate立ち上げのアナウンスです。
…

OSS Gate

debianのパッケージングができるようになった夏

応募した動機

取り組んだこと

よかったこと

気になったこと

応募前の想定と実際の内容とのギャップ

今後の新人・先輩・運営へのコメント

OSS Gateオンボーディング第一回を実施 - Debianコントリビューターを1人増やせた！

先輩役を務めることにした動機とは

支援のはじまり 新人さんの募集

募集締め切りと応募者の選考

支援開始と初回のミーティング(8/11)

オンボーディング前半実施(8/17-8/24)

途中でのふりかえり(8/31)

オンボーディング後半実施(9/2-9/29)

まとめミーティング実施(10/6)

OSS Gateオンボーディングでのやりとり

OSS Gateオンボーディングを終えて

OSS Gateオンボーディングはどんな人に向いている?

さいごに

OSS Gate のワークショップをFujitsuで再び実施してみた（開催レポート）

はじめに

前回と同じ所／変更した所

やってみて

課題と今後

前回開催時の反応から

申請は面倒？

本社だけ？

OSS Gateワークショップを開催するには

OSS Gateワークショップは自由に開催することができます

OSS Gateの主な活動形式

開催手順

ワークショップ開催FAQ

ワークショップは、どのような内容ですか

ワークショップは、どんなOSSを対象にしても良いですか

参加者に自分で選んでもらうと、フィードバック方法を教えるのが大変ではありませんか

ワークショップを開催するには、どのような人材を集めると良いですか

ワークショップには、どのくらいの時間がかかりますか

会場は、どのようなスペースが良いでしょうか

会場には、どのような設備・備品が必要になりますか

ワークショップに必要なドキュメントはありますか

ワークショップの開催は、どのように告知すれば良いですか

参加者を限定したり、クローズドに開催してもいいですか。

スポンサーを募ってもいいですか

この他に、質問や問い合わせ・フィードバックをしたい場合、どうすれば良いですか

OSS Gate のワークショップをFujitsuでも実施してみた（開催レポート）

はじめに

OSS Gateとは？

なぜOSSコミュニティに参加するの？

社外に出るのは怖い？

会社のルールとOSS

OSS Gate ワークショップの開催の様子

OSS Gate ワークショップをやってよかったこと

1. 「初心者だからこそ」の参加の仕方を教えてくれた

2. まずは質問やバグ報告からでOK

3. ほとんどのことをGitHubで行う

4. 良い意味で「ふわっと」している

5. 最後にその場で振り返る

最後に

謝辞、その他

オープンソース開発プロジェクトの参加者になるワークショップ「OSS Gateワークショップ」

オープンソース開発プロジェクト敷居は高い?

未経験者が経験者になるワークショップ

キャンセル待ちの多い、人気の高いイベントに

OSS開発プロジェクトの参加経験者がメンターとなり、手厚くアドバイス

今後の展開

参考ページ

OSS Gateワークショップ2016-06-11開催レポート

座席の配置

OSS開発手順

立場の説明

アイスブレイク

開発対象のOSSを決める

作業メモについて

動かしてみる

他の人に説明する

昼食

フィードバック

整理する

支援のはじまり新人さんの募集