公募トーク
- nikkie にっきー [Takuya FUTATSUGI]
トークを募集するフォームを「プロポーザル」（提案の意味）と呼んでいる（カンファレンスで話したい人はプロポーザルを応募する）
英語ではプロポーザル募集を、Call for proposalsのように言う。これを略してCfPということもあり、PyCon JPスタッフの中でもプロポーザルの意味でCfPということがある
概要
トークセッションを公募・選定し、当日の全公募トークセッションを実施する
もう少し詳しく言うと
国内外やPython歴の長短を問わず、Python使いから広くトークを募集する
カンファレンスで話すトークを選定する（全スタッフ・外部レビュアーの力を借りる）
スピーカーとやり取りし、当日のトークを実施する
目的
PyCon JPのミッションの1つ「知識を分け合う」を実現する
誰に：トークする人（＝スピーカー）
届ける価値：
Pythonに関する自分のPython知識が他のPython使いに共有できて嬉しい
アウトプットすることで学びになる
ブランディングになる面もある（国際会議で登壇したという実績。転職などにつながる可能性）
誰に：トークを聞く人（＝参加者）
届ける価値：
Pythonの知らない面を知られて嬉しい
自分の開発の中で試せて恩恵を受けられる
スケジュール（オンライン開催想定）
6ヶ月前 プロポーザル募集開始の準備に着手する
5ヶ月〜4ヶ月前 プロポーザルを募集する（募集期間：1〜2ヶ月間）
3ヶ月前 レビュー開始までに採択するトークの本数が決まっている
3ヶ月前 レビューを開始する（レビュー期間：1ヶ月間）
2ヶ月前 採択したプロポーザルを発表する
1ヶ月前 確定したタイムテーブルを発表する
当日に向けての連絡を適宜行う
気をつける点
PyCon JPは国際会議なので、海外のスピーカーとのやり取りは必須
プロポーザルの募集要項やスピーカーとのやり取りは日本語だけでなく英語も必要
トークの本数を決めるためには、カンファレンスが何日間で、各日何コマあり、並行何トラックかが決まっている必要がある
トークの本数＝2日間合計のコマ数 × 並行トラック数
内訳は15分トーク◯本、30分◯本、45分◯本のようになる
応募期間がひと月あり、最後に駆け込まれがちだが、仮に採択率が50%を超えそうな場合は、トラック数を減らして、トークの本数を減らしたほうがよいと思われる（2020は本数がギリギリだった）
プロポーザル募集時に、YouTubeへのアーカイブNGか、発表中の写真撮影NGかを聞いていた
レビューは1つのプロポーザルを3人以上でレビューする（多様な視点でレビューする）
採択以外に待機リストを用意する
辞退や連絡がつかない場合に待機リストから繰り上げ採択する
スピーカーがプロポーザルの内容を変更することを許容すると、スタッフのタスクは減り運用しやすくなる
2020はsessionizeのプロポーザルデータをマスタデータとして、PyCon JPサイトに掲載した（システムチームのページ参照）
スピーカーは申し出れば表示名やtypoの修正ができた（要望を聞いてスタッフが直すという作業が発生しなかった）
2019以前（現地開催）では、VISAの発行を考慮し、採択発表は3ヶ月前にしていた
辞退や渡航準備が間に合わない場合に備え、待機リストを手厚く用意していた
チェックリスト
スケジュールを参考にしてください（重複すると思ったので書きません）
各タスクの詳細
プロポーザルの募集を始める
2020の例：https://sessionize.com/pyconjp2020/ （2020年5月の1ヶ月間募集した。1人何本でも応募可能）
レビューから逆算してプロポーザルに必要な項目を設計する
コンテンツチームで検討し、他のスタッフにも意見を聞く（全員でレビューするため）
🚨注意🚨：プロポーザルの応募フォームでは反社会的勢力排除の項目を設ける
プロポーザル募集に使うツールを選定する
プロポーザルを書くときの注意事項をPythonコミュニティに周知する（※）
PyCon JP Blogで書く（日英）
PyCon JPのTwitterアカウントで定期的に発信
（※）続くレビューではプロポーザルの情報をもとに判断する（プロポーザルの記載以外に判断材料はないということ）
そのため、プロポーザルの記載は非常に重要。
どのプロポーザルにもレビューに必要な情報が揃うことを狙って、2020では注意事項を手厚く準備した（1, 2）。
また、サンプルプロポーザルも用意している
レビュー
レビュー観点を決める（どんなカンファレンスにしたいかによる）
コンテンツチームで検討し、他のスタッフにも意見を聞く（全員でレビューするため）
レビューするための仕組みを整理する
20-30人でレビューするので、誰もが守れる簡潔なルールを決める
好みでなく観点に即してレビューする
3段階（採択すべき、採択できる、採択すべきでない）で評価する（過去に食べログ形式を試した際は会議が紛糾したと聞く）
採択すべきでないでない評価の場合は理由を書く（採択会議で参照するため）
2020はレビューに使うWebアプリを自作した
レビュー用アプリは決して必須ではない
（経緯）sessionizeのレビュー機能が分かりづらく、レビュー用アプリまでいかなくてもGoogleフォームなどの準備は必要だった。Googleフォーム+レビューを円滑にすすめる自動化の規模を考えると、Webアプリ自作とそんなに変わらなさそうだったので、経験を積みたいnikkieがレビュー用アプリを作った
sessionizeでもpapercall同様のレビュー機能を開発中とのこと
採択会議を開催する
スタッフを含む全レビュアーが集まり、プロポーザルの中から採択と待機リスト入りを決める
だいたい1日かかる（全てのプロポーザルを議論しなくても）
発表は1人につき1回。複数提出した場合は、一番評価が高いプロポーザルについて議論すると進めやすい
トークのカテゴリ（2020ではTrackと呼んでいた）の間のバランスも考慮したい（NGな例：機械学習のトークばかり）ので、事前にどのカテゴリは何本くらい採択できそうかを算出しておく
トークの難易度（聴衆のレベル）についても同様
事前の評価の平均を取り、上位から採択していく
レビューが全員Yesのように評価が高いプロポーザルに関しては、採択会議で議論せず、機械的に採択する
レビューが高いがNoがある場合はそのレビュアーに意見を求める（ここが懸念など共有してもらう）
レビューが高くても、同じカテゴリのトークや同じ難易度のトークが枠数採択されている場合は、待機リストに入れる（機械学習など人気のカテゴリで発生しがち）
採択結果の連絡
プロポーザルを募集したシステム（2020はsessionize）の機能を使って、プロポーザルの応募者全員に採択結果を連絡する
採択者には期日を切って、発表が可能か応答してもらう（応答がない限りスピーカーとしては確定しないことに注意）
採択者から辞退の連絡があることもある
PyCon JP Blogに採択速報を出す
待機リストからの繰り上げ採択
期日までに応答がない採択者のプロポーザルは却下する（採択の取り消し）
辞退した採択者や応答がない採択者の分、待機リストから繰り上げ採択する
スピーカーへの連絡
2020はsessionizeからスピーカーを選んでメールを送ることができた。
スピーカーには1つのGoogleドキュメントを共有し、更新するたびにメールで「変更しました」と連絡した。
連絡事項は1箇所にまとまっていたほうが後から見返しやすいため。また、メールを長文にしても読まれにくいため（Googleドキュメントは差分だけ確認しやすい）
https://docs.google.com/document/d/1g8Ly6n03avly-p3GMoQZhS9hIFm9-WwsoHTSUgqS0ZI/edit?usp=sharing
主な連絡内容
当日までのスケジュール（見込みでも採択直後時点から共有しておく）
フォームの案内（採択直後）
タイムテーブルの希望調査
Tシャツ送付のための送付先（※Tシャツ送付についてはデザインチームのページ参照）
チケット購入依頼（採択直後）
オンライン登壇について（開催1ヶ月前から。情報共有やリハーサル案内）
タイムテーブル発表（開催1ヶ月前）
質問への回答（←Googleドキュメントに記載しましたと回答することで、他のスピーカーにも共有できる）
タイムテーブル発表
スピーカーから集めた希望をもとに、タイムテーブルを用意する。
並列するトークの中でTrackが重複しないようにする（NGな例：ある時間帯で機械学習のトークが2つ）。
これは、機械学習のトークを中心に聞く、Webのトークを中心に聞くという参加方法をサポートするため。
2020はsessionizeの機能でバランスを見ながらタイムテーブルを用意できた
タイムテーブルはPyCon JP Webサイトにも載せる。
Webサイトの実装を担当しているスタッフと連携する（システムチームのページ参照）
2020はsessionizeのAPI機能を使い、マスタデータをsessionize管理でWebサイトに載せることができた（スタッフでマスタを管理するという作業が発生しなかった）