どーも話についていけないと思ったら羊堂本舗を Sage に突っ込んでなかったのが原因ぽい。そうかそういうことか。わはは。日本Rubyの会Wikiを Sage に突っ込んだらとても悲しいことになったけどしょうがないのだろうか。かずひこさんに Sage のスクリーンショット送り付けて悲しいですって言うべきか？（パッチよこせと言われそうだけど Hiki の HEAD 追っかけなんてやってないよ。）[追記]2月14日にとても悲しいことからとてもステキなことに変わりました。
あげつらうだけなら楽だけど、具体的なアイディアじゃないと面白くないしね。考えてみよう。
- ファイル名が日付なのはいかがなものかと思う
ちょっとギョッとしますね、これは。tDiary を使っている限りしょうがないのかもしれませんが、今なら lily + CVS でいくか、Rubyist Magazine のような方向で構築する方がいいのかなとも思います。もちろん編集などのメニューが見えるのは不格好なのでやめてほしいです。どっちを使うにしてももうちょっとツールの完成度があがってからになるかもしれませんし、コンテンツの移行を考えるとすぐにはどうにもならないと思いますが。
- 本体だけでなくドキュメントにも snapshot とリリースがほしい
Ruby 界隈の人の力があればこれを自動化するのはまったく大変なことじゃないと思うのに、いつまでも正式に HTML ベースのドキュメントをリリースしないのはどうかと思います。正直言えば「1.8 がリリースされてからいったいどれだけ経ったと思ってんだ」という感想です。1.6 のドキュメントがダウンロードできて嬉しい人よりも 1.8 のドキュメントをダウンロードしたいと思う人の方が多いでしょう。
Wiki は確かに便利なのですが、自分の思ったようにちょこちょこ検索したいと思うと、サーバの負荷が気になります。ネットワークに繋がらないと使えないというのも不便です。
もう一つ、そのためにも RDTool の標準添付など Wiki 上のリファレンスを素早く HTML に起こすために必要な作業を進めるべきだと思います。
- Wiki で提供されている部分で突然見た目が変わるのはやめてほしい
サイトとしての統一感がなくて見ていてとても戸惑います。Wiki をやめろとは言いませんが、統一感のなさは問題だと思います。
- メニューを整理してほしい
ruby-lang.org にも日本Rubyの会Wiki にも言えるのですが、これらは Wiki ではあるけれども圧倒的に読者の方が多い Wiki であるということをもっと意識してほしいです。読者にとって不要なメニュー、読者がもっと素早くアクセスしたい検索などのメニューがすべて同一の重要度で並んでいるのは使い勝手が悪いです。
ruby-lang.org でサイト内検索がずいぶん下にあるのはなぜでしょうか？ これはもっと上にあるべきでは？
- 人手がほしいなら分かりやすく募集すべき
ruby-list で人手不足について書かれてもサイトを見ているだけの人には分かりません。サイト上に書いてないということは募集する気は特にないと言っていることと同じだと思います。
さて、Hiki の方にコピペすっか。……一気に送ったけど嫌がらせだと思われただろうか？(^^;
sheepman さんが Ruby のドキュメントに関して Wiki そのものにある編集に対する心理的ハードルに注目している。これについては以前からいろんな人が
- 編集したくなるメニューデザイン
- 署名
などの角度から議論をしている。まだそうした先人の知見を自分の中で整理しきれているわけではないけど、それらとはまた異なるアプローチでハードルを低くできないだろうかと考えたりする。
個人の Wiki でさえ編集することが躊躇されるんだから、Ruby の公式リファレンスマニュアル_の編集するまでに乗り越えるハードルはやっぱり高いんだろうか。どうやったら人が集まるだろう。
まず、Wiki なんだから編集すればいいというスタンスはなかなか分かってもらえないと思う。私のようにコミュニティの外様の場合はやはりかなり躊躇する。知らない人の Wiki に手を出せるのはせいぜい typo 修正止まりだと思う。1（逆引きRuby では正規表現マッチのところに手を出したけど。）
そういう意味でも先日書いていた編集権限と commit 権限を分離した Wiki があるといいなぁと思っている。小人も自由に書けるが、正式に承認されたバージョンに反映されるかどうかは committer の裁定に委ねてしまうことができる Wiki。つまり書き手の立場がいきなり core member と対等になってしまうのはビビるので、一段下にしてください、という寸法だ。もちろんこれは committer の負荷が上がるので運営側としては採用に躊躇する面があると思うけど、参加者を増やすという意味では悪くない案だと思う。
もう一つは、いろんな人が手を出してちまちま編集していることを分かりやすくて提示できたらよいと思う。例えば RuWiki のような保存の際にコメントを書ける Wiki であれば、ここに書くコメントで「編集行程の雰囲気」を伝えることができるのではないかと思う。もちろん本来はどのような修正が加わったのかが分かりやすく書かれていることが前提なんだけど、例えばここに「ぐはぁ、typo ハッケソorz」と書いてあったら、編集者のフランクな性格を表すことができると思う。2また先の編集と commit の区別があればこのコメントはもう少し書きやすいのではないだろうか。
可能なら、Wiki committer が ML でやりとりしている様子や、blog なんかも読めるといいのかなぁ。欲張り過ぎはよくないのでどういう風にサイト上に盛り込むかというのはとても難しい問題だけど。ちなみに pukiwiki.org ではこれが全部 Wiki 上で行われているので、参加の敷居は確かに低くなったが追っかけのコストがとても高いサイトになってしまっている。うまく間を取れればいいなと思う。
ただ、本家リファレンスマニュアルはどうしたって参加者は増えにくいと思う。よほど Ruby に自信がなきゃ書けませんよ、やっぱり。少なくとも私は書きたくありません。怖いです。
ソリッドとかリキッドとかメタルギアですかというネタはおいといて、ソリッドでもリキッドでもなく間をとって
IE 無視で max-width 指定するのがいちばんいいんじゃないの？
というのはたぶんみんなあえて無視してるんだろな。IE を考慮に入れなきゃプロのデザインとは言えないもんね。
私は6年くらい前からずっと max-width 大好きっこです。幅広げすぎると読みにくいじゃん。でもウィンドウを細くしても横スクロールしたくないじゃん。
ほんとはリキッドデザインて”ある意味”幻想だと思うんだけど、これも書き始めると長くなるので別な機会に。