BugTrack/560 tracker_listの高速化
が、jjyunさんの働きでなかなか興味深い状態になっています。ちょっと様子を見ていただけませんか? ついでに久しぶりに1.4ブランチに顔を出して下さい ;)
開発談義に書くつもりでしたが、長くなってしまったのでこちらで。
pukiwiki.org移転時にゆうさんとちょっと濃い話をしたのですが、PukiWikiは、傍目にみてもある種の臨界点をとっくに超えたプロダクトになってしまっていますね (^^; PukiWiki関連のサイトも(orgもdevも)、PukiWikiの内部実装も、その位置付けにより相応しい構造に変えていく必要があるようです。
ということで、PukiWiki.orgやdevの現状のサイト構成について、私の現状の認識をコメントしておきます。
BugTrack、質問箱、雑談、FAQ、自作プラグイン、ちょっと便利に、開発日記といったそれぞれの中コンテンツに引っ張られる形で、とてもうまく「日々をこなせる」システムが作られていると思います。しかし実はそれぞれのコンテンツの整理や集約があまりできていなかったり、その方法が明確でなかったり、それぞれのコンテンツごとの相互リンクが疎かだったり、それぞれの中コンテンツだけの視点による変更がバランスを崩したりして、情報が日々発散しながら蓄積される傾向が高くなっている様に思います。このようなサイトをただそのまま抱えてしまったら、ちょっと気を許しただけで「忙殺されてしまう環境」が立ち上がり、それが永遠に続くことでしょう。私も耐えられるかどうかわかりません。
このような状態になり続ける背景には、『Wikiはコンテンツドリブンである(「とにかく」「今」「これが」 役に立てばいいや)』という少し偏った考え方があると思っています。私も以前はコラボレーションの部分に夢中になっていましたが、今はもうそれだけが大事だとは思っていません。上に挙げた我々の例も、まさにコンテンツドリブンの集合体が行き詰まりかけている実例と認識しています。
ここで少し考えていただきたいのは、基本的でもっと大事なこと、つまりorgやdevが何のためにあるのか、というコンセプトです。中コンテンツ同士を再構成したり、奇跡的に/発作的に生まれた素晴らしいコンテンツを維持する構造を(毎回が人海戦術にならない様に)改めるためには、1つのコンセプトから引き出された強力な問題意識が必要です。ですから今の私は、Wikiもコンセプトドリブンでなければならないと考えています。
ちょっと前、スラッシュドットに掲載されたWikipedia創始者のインタビュー(翻訳)から一部引用します。
これはWikipediaの例です。
あんまり続けると現実逃避になってしまうので、続きはまたいずれ。*1