こういう社内勉強会をやってみたい、というアイデアのメモ。うまくいくかどうかはわからない。仕事が一段落したらやり始めたい。とかいってるといつまでたっても始まらないので今から始める。
https://github.com/kyanny/jquery
- オープンソースソフトウェアのソースコードリーディング勉強会を、内輪（社内とか、あまり人数多くない）でやる
- 担当を決めて各人でソースを読んできて、集まったときに発表をする（ここがわかりませんでした、とかでよい）
- Github に勉強会用のレポジトリを作ってそこに読むソースコード一式を入れておき、ソースにコメントを書いていく（コメントとコミットログが発表資料がわり）
メリット
- 資料作ったり準備する手間がはぶける（勉強会用レポジトリを clone しておいて時間あるときに読みながらコメント書いてコミットして発表前に push すればいい）
- 複数人でコラボレーションするのが楽（そういう機能は Github 任せで良い） Wiki とか Issues とか好きに使えばいい
- 特殊なツールや環境を用意しなくてもよい（git が使えて Github のアカウント持っててエディタがあればいい）
- 参加してないひととの情報共有が楽（毎回発表した内容を Wiki にでもまとめておけばよい）
- Github にレポジトリがあるもの (jQuery とか) ならば fork してくるだけで準備が済む
デメリット
- コメント何か書かないと読んだことにならない（特に書くことがない、というときに困る）記録に残すためには何か書けというのは仕方ない気も
- Github のアカウントを知られてしまう
- あんまり思いつかない
- そもそも公開されてるソースを読むのだからよほどまずいコメントを書かないかぎり公開して困る事態には陥らないはず
- 誰がどこまで読んでるかを把握するのは難しくなりそう、なので書いたコメントがコンフリクトしたりするとめんどそう
- 聞きたいだけのひとは参加できない（これはむしろメリットだと思っていて、一部のやる気あるひとが最初は頑張れてもまわりの反応が薄いといずれ力尽きてしまうが、やる気のあるひと同士ならお互いに刺激しあって完走できる確率が高まるのではないか）
- git が使えないひとは参加できない（がんばれば Github のウェブサイト上から参加することもできる、が、そもそも git の使い方を覚える気がないひとに参加してもらう必要はないと考える）
どこまで読んだかわかんなくなる問題についてはエディタ側で解決できるかも。 Emacs なら bookmark に追加するときポジションも覚えてくれるので続きから読める。ただし先頭から順番に読む必要がある。ほかに注釈を入れるツールを何か使ったり、「YYYY/MM/DD ここまで読んだ by 誰それ」というコメントを残す、というやり方もありかもしれない。
