11 Jun 2022 |
piroor (YUKI "Piro" Hiroshi)💪 | これまでのワークショップでは「公式のREADMEの不備を洗い出す」ということを初心者視点でやってみてもらっていて、一定の成果が出ていると思うのですが、「そもそもREADMEも出来が良い」ケースが今は増えてきていて、フィードバック事項が特にないということが結構ある、という実感があります。 | 05:02:20 |
piroor (YUKI "Piro" Hiroshi)💪 | * これまでのワークショップでは「公式のREADMEの不備を洗い出す」ということを初心者視点でやってみてもらっていて、一定の成果が出ていると思うのですが、「そもそもREADMEも出来が良い」事例が今は増えてきていて、フィードバック事項が特にないケースが結構ある、という実感があります。 | 05:03:02 |
piroor (YUKI "Piro" Hiroshi)💪 | ソフトウェアの品質的にも、それを使う側の知見的にも、ある程度使い込んでみてやっと違和感に気付ける、という事が結構あることを思うと、「1日の中で、ソフトウェアを使ってみて、つまずきに気付いて、報告までする」という一通りのことをやるのはかなり大変で重たくて、成功体験を持ち帰ってもらえる打率が低くならざるを得ないなと。 | 06:20:02 |
piroor (YUKI "Piro" Hiroshi)💪 | 「Good First Issueに取り組む回」という切り口だと、課題はすでに発見されているので、ゴールが明確で、解決するにせよ追加の情報を提供するにせよ、成功体験を得やすいし、数をこなす中で単純接触効果によって「Issueってこんなものでいいんだ」と自分の中のハードルが下がって、Issueを立てることの心理的な抵抗が減る。 「Issueの発見に取り組む回」という切り口だと、「何か報告できるネタを見つけなきゃ」と焦らずに、時間いっぱ落ち着いて取り組めるので、これも成功体験を得やすい。 ということが言えるんじゃないかなあと思ったのでした。 たとえばですが、次の7月は「Issue発見特化回」、次の8月? 9月?は「Good First Issue特化回」という感じで、交互に開催してみてはどうかなと。 | 06:30:06 |
piroor (YUKI "Piro" Hiroshi)💪 | あと、「次回の開催準備」の作業を、ワークショップの後の時間でやるようにしてはどうかと考えています。 現在のシナリオでもワークショップ本体の後にアンケートとその結果を見ながら話す時間は設けているのですが、これをもっとはっきり「アンケートを取るまではワークショップ」「アンケート回収後は次回開催に向けての作業時間」と位置付けて、作業時間の枠の中で、Doorkeeperのイベント作成などのタスクを雑談しながら実施する、という案です。 「美容院の予約の電話や連絡が面倒なので、1回行ったら会計の時に次の予約もその場で取る」のような要領ですね。 一人で後でやるのは億劫でも、気分が盛り上がってるうちなら無理なくできるのではないか、という実感に基づいたアイデアなのですが、どうでしょうか。 | 06:50:25 |
piroor (YUKI "Piro" Hiroshi)💪 | 同じ日に続けては難しければ、Doorkeeperにイベントを立てる際に、1週間後とか3日後とか翌日とかのように機械的に日を決めて、ワークショップそのもののDoorkeeperイベントと一緒にイベントを立てておく、というのもアリだと思っております。 | 06:54:44 |
piroor (YUKI "Piro" Hiroshi)💪 | Good First Issueと似たラベルでHelp Wantedというのもあって、Good First Issue回ではそれもスコープに入れるといいかなと思っています。 | 06:58:54 |
13 Jun 2022 |
piroor (YUKI "Piro" Hiroshi)💪 | Good First Issueに取り組んでみるのをお手伝いする、というのを業務で最近少しやってるんですが、実際にやってみると、ほぼマンツーマンでガッツリになっちゃう感じはありました。なのでサポーターに求められる役割は、今のワークショップよりは重たくなりますね。少なくとも、ある程度知見のある分野にかすってないと、「こう調べていきましょう」みたいなアドバイスもできないし。 実際にやるときは、サポーターの得意分野を申込時に列挙してもらって、それをビギナー参加者を募る前にイベントページに「今回対応できる分野の範囲はこれ」と反映する、みたいなことをしたほうがいい気がします。 | 01:28:01 |
daipom (Daijiro Fukuda) 💪 | Good First Issue、 経験ないですが、本格的に課題に取り組める感じになりそうで、面白そう。 ただ、今までのようになるべくビギナー主役で、サポーターは補助に徹するという形では難しくなるかもしれないですね。
実際にやってみると、ほぼマンツーマンでガッツリになっちゃう感じはありました。なのでサポーターに求められる役割は、今のワークショップよりは重たくなりますね
そうですよね。その分野に詳しい人が強く主導しつつ、皆さんに体験をしてもらう形になるんでしょうかね。 例えば自分なら、以前の形のworkshopならばサポーター側で参加するでしょうが、 「Good First Issue」なら、詳しくないけど興味のある分野を扱う予定の会があれば、ビギナー側で参加してみるのも良いかなあと。 つまり、「Good First Issue」会だとちょっと「サポーター」/「ビギナー」対象層が少し変わってくるのかなあ、というイメージを持ちました。 とりあえず何度か試しにやってみるの面白そうで良いと思います! | 03:06:25 |
daipom (Daijiro Fukuda) 💪 | Redacted or Malformed Event | 03:08:29 |
daipom (Daijiro Fukuda) 💪 |
「次回の開催準備」の作業を、ワークショップの後の時間でやるようにしてはどうかと考えています。
なるほど、ということは9月の開催については7/30時点で雑談しつつ決めるという感じでしょうか? | 03:09:04 |
piroor (YUKI "Piro" Hiroshi)💪 | そうですね、そういうイメージです。ただ、この提案は開催形態の見直しとは別の話として、今の形態のまま継続するとしても、毎回1ヵ月前とかにリマインダーを流し忘れるのをどうにかしたいという思いでの提案なので、特に相談とかのない、もっと単純作業的な、「さて閉会したので次の回のissueを立てましょう、カレンダーにもリマインダーを設定していきましょう」みたいなことを想定していました。 | 06:58:41 |
piroor (YUKI "Piro" Hiroshi)💪 | 自分が業務でやった事例は、Rubocop(Rubyのlinter)のgood first issueとして立てられている物について、実際に手元で動かして、スタックトレースを見て、実装のここに手を入れたらよさそうだとアタリを付けて、必要な変更はどういう物かを検討して……という感じでした。 | 07:00:07 |
piroor (YUKI "Piro" Hiroshi)💪 | どちらかというとOSS Gate Onboardingに近いかもしれません。Onboardingは期間を決めてやるのに対し、こちらはワークショップの1回分でできるところまでやる、みたいな違いでしょうか。 | 07:02:40 |
piroor (YUKI "Piro" Hiroshi)💪 | 先輩側がやるのをビギナーさんに見てもらう、という形ではなくて、「こういうときどんな方針でやればいいか分からない」と相談されたら「まずは実際の動作を確認してみるといいです(何故なら……)」とアドバイスする、という感じで、サポーターとビギナーの関係そのものは変わらない想定です。 サポーターに必要な知見が「障害の報告一般」ではなく「実装の調査」などよりプロダクトや言語に固有の話になるという点が、最大の違いですね。 | 07:13:16 |
piroor (YUKI "Piro" Hiroshi)💪 | 先の事例では、僕自身も具体的な解決策は知らなかったので、プルリクエストには辿り着けなくて、「こういうことが分かったけどどうしたらいいでしょう?」とプロジェクトオーナーに質問するコメントを投稿する、というのが到達点になりました。 ビギナーにあたる方は、この経験を通じて「完璧に仕上げられなくても関わっていいんだ、できる範囲での協力でいいんだ」ということにカルチャーショックを覚えておられた様子で、こういう点は今のワークショップで「とりあえず報告してみるだけ」が到達点だったときの「報告だけでも貢献になるんだと知ってびっくりした」みたいな感想と似ていると感じました。 | 07:21:39 |
piroor (YUKI "Piro" Hiroshi)💪 | なので、サポーターもエキスパートである必要まではないと思っています。good first issueに取り組むビギナーの方とほぼ同じ目線で、ただし取り組み方は知っている、という所が立場の違いになるかなと。 | 07:22:44 |
daipom (Daijiro Fukuda) 💪 | 4回分先までのDoorkeeperイベントページの作成 をどうしようかと思っているのですが、これはいったん止めて、1個1個終わったら次の作成、という形にしてみてもよいのでは、ってことですかね?それとも日程とイベントページだけは先に作っておいた方がよいですか? | 09:01:35 |
daipom (Daijiro Fukuda) 💪 |
サポーターとビギナーの関係そのものは変わらない想定
なるほど。 確かに無理にそのissueの解決まで行こうとせず、動作確認とか出来る範囲でコントリビュートすれば良いんだということなら、 今での形とそこまで変わらないのかもしれませんね。 | 09:06:17 |
daipom (Daijiro Fukuda) 💪 | そしてそのできる範囲でのコントリビュートでいい、という感覚こそ大事だと! | 09:06:46 |
piroor (YUKI "Piro" Hiroshi)💪 | この点は、 「1個1個終わったら次の作成、という形にしてみてもよいのでは」 ということではなく、 「4回分先までの作成をしそびれていた回がもしあった場合は最大4回分作成し、前回終了時に作成しそびれていなければ4回先の1回分を作成する」 イメージでした。本当に、現在のワークフローでのイベント作成作業をこのタイミングでやるというだけの想定です。 | 10:14:18 |
14 Jun 2022 |
daipom (Daijiro Fukuda) 💪 |
9,10月の開催は以下のような形にしますか? しばらく休日開催が続くので、いったん9月を平日にしてみる(曜日は適当ですが)
- 9/6(火) 13:00 ~ 19:00
- 10/29(土) 10:30 ~ 17:00
もし問題なければこの日程でとりあえず2回分作っておこうと思いますが、どうですか? | 01:19:21 |
piroor (YUKI "Piro" Hiroshi)💪 | はい、宜しくお願いします! | 01:20:48 |
piroor (YUKI "Piro" Hiroshi)💪 | Doorjeeperのイベントは開始時刻の違いに合わせてタイムテーブルの時刻が2種類あるので、開始時刻が合っている物の方をコピーして作成して頂ければ幸いです | 01:21:58 |
daipom (Daijiro Fukuda) 💪 | かしこまりです! | 01:33:03 |
23 Jun 2022 |
kou (Sutou Kouhei) | @daipom Doorkeeperからの通知って届いています? https://manage.doorkeeper.jp/groups/oss-gate/events/129874/tickets/swzmcuGRxz_jexKz5sZs の方は https://oss-gate.github.io/workshop/beginner-preferential-treatment.html の「3.2 次回はサポーターとして参加するビギナー」に相当するのでDoorkeeperで繰り上げ処理をしてみませんか? | 04:31:55 |
26 Jun 2022 |
okuramasafumi (OKURA Masafumi) | お久しぶりです。 ふと気になって調べてみたら、このアプリ(gitter)はもう2年近く更新されていないらしく、使い勝手もいまいちであることから、他のアプリ(チャットツール)に乗り換えてはどうかと思うのですが、いかがでしょうか? | 04:46:45 |
kou (Sutou Kouhei) | https://gitlab.com/gitterHQ/webapp を見るとそんなことはなさそうなんですが、どこ情報ですか? ところでGitterじゃなくて○○だったらもっとコミュニケーションするのになぁというおすすめチャットツールはありますか? (ちなみに、私はSlackがすごく苦手です。。。) | 04:52:22 |
| Kimiaki Kuno joined the room. | 05:14:44 |
Kimiaki Kuno | gitterのルームは https://element.io/ からも閲覧書き込みできるようです(セキュリティキーの管理が面倒くさそうですが) | 05:22:10 |