Skip to content

Latest commit

 

History

History
264 lines (177 loc) · 14 KB

scenario.md

File metadata and controls

264 lines (177 loc) · 14 KB

シナリオ

用語集

はじめにこのワークショップで使う用語を説明します。

  • 進行役:ワークショップを進行する役割の人(すでにOSSの開発に参加している人)
    • 1人
  • ビギナー:OSSの開発に参加したいけどまだ参加したことがない人・参加したことはあるけどまだ自信がない人
    • 複数人
  • サポーター:ビギナーをサポートする役割の人(すでにOSSの開発に参加している人)
    • 複数人
  • サポートメンター:サポーターをサポートする役割の人(すでにサポーターの経験がある人)
    • 複数人

目的

「OSS Gateワークショップ」の目的は「OSS開発に参加する最初の一歩を支援すること」です。

対象

  • OSSの開発に参加したいけどまだ参加したことがない人
  • OSSの開発に参加したことはあるけどまだ自信がない人

目的の実現方法

OSSの開発に参加したいけどまだ参加したことがない人が参加していない理由は「漠然とした不安がある」からです。このワークショップでは「不安」を解消することによりOSS開発に参加する最初の一歩を支援します。

「不安」の原因は次の通りです。

  • 「やり方」を知らないから
  • やったことがないから

これらの「不安」の原因を解決するために次のことを実施します。

  • 「やり方」を伝える
  • 「やり方」を実際にやってみる

具体的には次の方法を実施して「不安」を取りのぞきます。

  • オススメのOSS開発参加方法を紹介
  • オススメの方法を実践

OSSの開発に参加する方法は無数にありますが、「好きなようにやっていいんだよ」と言うと不安を増す原因になってしまいます。「好きなように」と言われてもそもそもどのような「やり方」を選べるかもわからないからです。

このワークショップでは、OSS Gateがオススメする方法を「1つだけ」説明し、実際にビギナーが「やってみます」。あえて1つに限定することにより迷いポイントが減り、不安を軽減できるからです。

ビギナーがオススメの方法を試すとき、「こんなissueを立てて嫌がられないかな…」と「不安」にならないよう、サポーターがその場で「それをやっても大丈夫だよ、やってみよう!」と声をかけます。サポーターに大丈夫だと言ってもらえたら、その「不安」を取りのぞけるからです。

目的達成の評価方法

ワークショップ後、自分1人でもOSSの開発に参加できる「気がするか」どうかを判断基準とします。「気がする」なら、OSS開発への心理的敷居は十分に下がっていて、OSS開発参加への具体的なとっかかり方法が身についた、と判断します。

大事にしたいこと

ビギナー:

  • 実際にやってみる!(経験すれば多くの不安は解消するはず!)
  • 楽しむ!(経験すれば楽しいことがわかるはず!)

サポーターの人の動き方の方針:

  • 答えを教えない(開発に使う言語・開発対象のOSSが多様なので知らないことも多いはず)
    • 代わりに一緒にやる。自分のPCでも並行して作業してわかったら教える、ではなく、ビギナーのPCで一緒に作業ということ。そのとき、自分がどうして次にこう行動をしようとしているのかの理由を伝えながら一緒に作業する。
  • 自分ならこういうときにどう考えてどう行動するかを伝える
  • 自分がフィードバックを受ける側ならこう受け取る、ということを伝える

サポートメンターの人の動き方の方針:

  • サポーターが処理しきれないことをフォローする。
    • 同時に複数のビギナーからサポートを求められているサポーターがいたら、1人のサポートを引き取る。
    • サポーターが目的を見失っていそう(サポーターがビギナーに教えているとかはビギナーが体験する機会を奪っている!ので目的に沿っていない)なら目的を思い出せるようにフォローする。

当日までの準備

  • 会場の準備
    • 6人ぐらいが囲んで座れる場所を、いくつか用意できる会場がやりやすい
    • 説明用のプロジェクタは欲しい
    • ネットワークは必須
    • 参加者全員のPCのコンセントが繋がる必要
  • 参加者募集
    • 募集は今はDoorkeeperで募集している。
  • 進行役はこのscenario.mdやスライドソース)をあらかじめ確認しておく
  • 最後のふりかえりのためのアンケートを準備しておく

開催当日の開始前

  • ビギナーはネットワークの設定をすること
  • サポーターはネットワークの設定をすること
  • サポートメンターを決める
    • サポーターの中からOSS Gateの参加経験の多い人

10:30 アイスブレイク

目的:

  • ビギナー・サポーターともに話しやすい状態にする

やり方:

  • ビギナー・サポーターそれぞれ同じテーブルの人たちに自分がどうしてこのワークショップに参加したかを話す
    • 「声を出す」ことが大事。話題はなんでもよい。みんなが話せそうな話題だから「ワークショップの参加目的」にしているだけ。
  • Gitterのoss-gate/develに登録する。
    • 今回のワークショップだけでなく、今後のOSS開発でも相談できる場所。

10:45 進め方の説明

目的:

  • ビギナーがどうやってOSS開発に着手すればよいかわかること

今日の進め方を説明:

  • 進め方の説明の途中でビギナーが開発対象とするOSSを決める

    • 次のことを加味しながら決める。OSSの技術的な難易度はそれほど重視しなくてよい。
      • ビギナーが使っているOSSにする
      • ビギナーが困っているOSSにする(インストールがうまくいかないとか)
  • 進め方の説明の途中で作業ログ保存用のOSSを決める

    • 作業ログissueを作る
    • サポーターは担当するビギナーの作業ログへすぐにコメントを入れる
      • 互いのアカウントが把握できるようになる
      • ビギナーのログ更新をサポーターが通知で受け取れるようになる

11:15 開発対象OSSを動かす

目的:

  • OSS開発に着手したときに最初にやるべき「動かすこと」を実際にやる

目的達成のために達成したいこと:

  • 困ったら相談するという習慣を身につけて欲しい
    • 実際はリモートで相談することになるが、まずは隣同士、グループ内で相談できるようになる
  • 動かすことに集中する
    • 他のことに手を出したくなるかもしれないけど、まず動かすことが大事、ということを覚えてもらう
  • ドキュメントに不備があるときに、文句を言う(Twitterでアピールするとか)よりも、次にドキュメントを読んだ人が困らないように直しておこう、と考える習慣を身につけてもらう
    • 文句を言うことはスゴイことでもカッコイイことでもない!文句を言っている時間を使って直そう。

やること:

  • ドキュメント(READMEなど)に書いている通りにインストールしてみる
    • ドキュメントにtypoや古い記述など不備があったら作業ログissueにメモしておく。理由は後でpull requestするから。
    • インストール方法や使い方をググる前に公式ドキュメントを参照する習慣をつける。
      • ググって見つかる非公式の情報がないと使えないOSSよりも公式ドキュメントを読めばわかるOSSにするべきで、そうなっていないなら私たちが開発に参加してよいものにするべき。
  • インストールできたらドキュメントに書いている通りに動作を確認する

12:15 ミニふりかえり

目的:

  • ふりかえりのリハーサル
    • 作業ログが後で自分の役に立つことを実感してもらう
  • 今後進むべき方向を確認して、午後を有意義に過ごすため

目的のために達成したいこと:

  • 「まず動かす」のときに作業ログをとる

やること:

  • サポーターの人数よりビギナーの人数が多い場合
    • 1サポーターあたりn人のビギナーをフォローする
    • 1人のビギナーがふりかえりをしている間、別のビギナーはなにか得られるものがないかという気持ちで見守る
    • 1人終わったら別のビギナーと交代
  • ビギナーは作業ログの内容を順にサポーターに説明する。
  • サポーターは説明を聞いてビギナーにフィードバックをする。
  • ふりかえりをしたサポーターはビギナーの作業ログにコメントを入れる
    • 互いのアカウントが把握できるようになる
    • ビギナーのログ更新をサポーターが通知で受け取れるようになる

12:30 (昼食)

近所にランチを食べに行きましょう。

ビギナーは午前中に気になったことを進行役・サポーターに聞いてみてください。

進行役・サポーターはビギナーに楽しんでいるか聞いてみてください。

13:30 プロジェクトにフィードバックする

目的:

  • 「動かす」を実際にやってみて気づいたことをOSSプロジェクトにフィードバックすることを「体験」する

目的達成のために達成したいこと:

  • issueでもpull requestでもメールでのレポートでもなんでもよいのでフィードバックする

やること:

  • 「動かす」のなかで見つけたドキュメントの不備がどんなものか他の人に伝わるようにまとめる
    • わかりにくかったところに対する改善案をまとめるのもよい。
  • まずは自分の考えを整理する
    • OSSの開発ではインターネット越しのやりとりが基本なので、文章で伝える必要がある。
    • 少なくとも自分が理解できるような文章にまとめること。
    • 自分の考えを文章にまとめるのは難しいと思うのでサポーターには考えの整理を手伝ってあげて欲しい。
    • まとめたものは作業ログissueにコメント。
  • 自分の考えがまとまったら開発者に伝わるようにまとめ直す
    • 「読む人」が理解できることが大事
    • このように報告してほしいとまとめているOSSもある。たとえば、GitHubを使っているOSSはCONTRIBUTING.mdを使っていることがある。
    • サポーターは読む人視点を伝えてあげて欲しい。
    • これもまとめたものは作業ログissueにコメント。
  • 実際に報告する
    • これはupstream(開発元)のissueに報告。

15:30 休憩

10分休憩。

15:40 ふりかえり

目的:

  • ビギナーのよい行動を伸ばすため
  • ビギナーが困っていることを解決するため
  • ビギナーが見過ごしている問題(= 解決するべき問題)を気づかせるため
  • ビギナーが明日進むべき先を目指すため

目的達成のために達成したいこと:

  • ビギナーの作業ログを元にサポーターがビギナーをサポートする。

やること:

  • サポーターの人数よりビギナーの人数が多い場合
    • 1サポーターあたりn人のビギナーをフォローする
    • 1人のビギナーがふりかえりをしている間、別のビギナーはなにか得られるものがないかという気持ちで見守る
    • 1人終わったら別のビギナーと交代
  • ビギナーは作業ログの内容を順にサポーターに説明する。
  • サポーターは説明を聞いてビギナーにフィードバックをする。
  • ふりかえりをしたサポーターはビギナーの作業ログにコメントを入れてissueを閉じる
    • 互いのアカウントが把握できるようになる

15:55 まとめ

目的:

  • 今日やったことの意味を再確認する
  • 今日やったことを明日以降に活かす

目的達成のために達成したいこと:

  • 参加者が以下を体験したことに気づく。
    • 普段見逃しているだけでフィードバックポイントは今までもあった。
    • フィードバックは実は難しくない。

やること:

  • 今日やったことを再確認
  • 今日やったやりかたの思惑を説明
  • 明日からのヒントを提示

16:05 アンケート記入

16:15 ワークショップのふりかえり

  • アンケート結果をみながら今後もっとうまくやるにはどうすればよいかを検討する