PyCon JP 2015の作り方

こんにちは。メディアチームの今津です。

PyCon JP 2015では，現在「プログラム」「⁠事務局」「⁠会場」「⁠メディア」の4つのチームに分かれて様々な準備を行っています。この連載では，各チームがどのようにPyCon JP 2015を作っていっているのかを，それぞれの目線でご紹介していこうと思います。

第1回は，同じメディアチームの担当であるWebサイトについてご紹介します。

PyCon JP Webサイト開発について

PyCon JP 2015 Web担当の小松です。2015年度版Webサイト開発の裏側について，PyCon JPの作り方ということで紹介していきたいと思います。

Symposionを使用したサイト開発

PyCon JPのWebサイトでは，2014年よりSymposionをforkしたUS PyCon 2014のWebサイトのコードをさらにforkして使用しています。

• Symposion
  • GitHub

Symposionは，Djangoを使用して開発されたCMS（コンテンツ管理システム）です。プロポーザル応募などの機能が付いていて，プロポーザルの内容の編集を応募者が行うことができ，レビュワーによるレビュー，採択から掲載までが行えるなど，カンファレンス向けとなっています。

PyCon JPのスタッフは，Pythonに関心が高い人が集まっていることもあり，Django製のこのCMSは打って付けだったと思います。私たちはこのSymposionをさらに改良を加えて運用しており，そのソースコードはBitbucketで公開しています。

• pyconjp-website

2014年の段階で，いくつかの改良が加えられていましたが，今年はさらに来年以降も使い回しが効くようにハードコードを無くす方針で作業に取りかかりました。

機能要望のリストを作る

PyCon JPは前述のとおり4つのチームに分れており，PyCon JPのWebサイトを開発するにあたって，各チームからの要望を集めました。

機能要望は優先度と大まかな期限を一緒にGoogleスプレッドシートで受け付け，それをWebチームでJIRAにチケットとして登録していきました。一度運用されているシステムだけに，改善案も「ここがもっとこうだったら良いのに」といった内容がよく集まっていたように思えます。特に多かったのはやはりプログラムチームからのプロポーザル関連でしょうか。システム的な改修としてはさほど大きくはないものの，プロポーザル応募フォームの項目の整理などは昨年の運用からの意見だったのがうかがえます。

大きな改修としては，次の3点が挙げられます。

• 言語ごとのパーマリンクを作る
• プロポーザルが提出された段階で公開され，レビュー中のプロポーザルにソーシャルボタンで「いいね」などが出来るようにする
• Facebook，Twitterでもログイン出来るようにする

現在これらの機能は改修済みで公開しています。

受けた要望について，開発中の進捗管理，関係各所とのやり取りも基本的にJIRAで行い，必要に応じてSlackで相談したり，毎月一度の作業日に聞いたりという形で進めました。また，Slackや口頭で話した内容については必ずJIRAのチケットにメモを取るようにして，あとで「どうしてこうなったんだっけ？」と言うときに参照するようにしています。

一部の人を除いて，全員ボランティアで，プライベートな時間を使って作業を行っているので極力無駄な時間を取らないための対策でもありますね。

開発フローについて

前述のとおり，PyCon JPのWebサイトはBitbucket上でGitを使ってソースコード管理をしています。そして，JIRAとBitbucketを連携させて，ブランチ名をJIRAのチケット番号にすると該当チケットがひも付くようにしてあります。

開発の基本的なイテレーション

開発する人たちと相談のうえ，git-flowに載せて開発しようということになり，その上で，チケット駆動開発になるようにどういったイテレーションで開発するのかをチームで共有しました。

1. 要望をJIRAでチケット化。担当が明確であればその人に，無ければチームリーダーの小松に回す。
   • ゴールと期日は明確に記述する。（⁠Pythonプロフェッショナルプログラミング第2版5章P.116にあるテンプレートを使用しました。）
2. 自分が担当のチケットを受け取ったときに進行中に変更する。
3. 自分のリポジトリでfeature branchを切って，作業開始する。
   • ブランチ名はチケット番号（HTJ-XXX）にしてJIRAとの連携させる。
4. 作業が終わったらdevelop branchへマージする。
5. 本家リポジトリにpull reqを行い，チケットを解決にして小松へ返す。
6. 解決されているチケットがあったら，小松が確認のうえ，pull reqをマージしてチケットを閉じる。
   • もし，問題があったり，関係各所への確認が必要であれば，担当者をその人に回してチケットを再オープンし，解決されるまで 1.～5.を繰り返す。

当初，6.の確認する人をリーダーに一本化したほうが良いのかは少し悩みましたが，確認できる人が回して行くというふわっとした形にすると混乱するのではないか，ということで今の形に落ち着きました。なぜ悩んだかは後述します。