高尾です。

みなさん、ruby-lang.org でのるりまの提供についてのご意見ありがとうございます。

みなさんの意見の多くはるりまを提供するドメインに関するものですね。
それと、okkezさんからは提供するコンテンツについて具体的な質問がありました。

1. ドメインについて

みなさんからのご意見をまとめると、doc.ruby-lang.org のように新リファレンスだけでなくチュートリアルや各国のドキュメントを提供するためのドメインを用意する方向だと思います。それを第1候補としたいと思います。しかしながら、私はこの案に反対だったりします ;-)（以下に私の意見を述べますが、doc.ruby-lang.org が第1候補であることに変わりはありません。）

私が rurema.ruby-lang.org を候補とするまでに考えたことを説明します。

まず最初に私が考えたのは、ドキュメントを提供するためのドメインとして doc.ruby-lang.org を用意して、旧リファレンスのように /ja/man/<バージョン> で新リファレンスを提供することです。

しかし、現在 ruby-lang.org で提供されているドキュメントはリファレンスマニュアルと www.ruby-lang.org のものだけであり、しばらくは doc.ruby-lang.org で提供するのは新リファレンスだけになりそうです。

また、/ja/ を用意してゆくゆくは /en/ などの各国のドキュメントを提供することも考えました。
しかしながら、そのようなドキュメントは現在ありません。

あるとすれば RDoc ですが、それは新リファレンスとは独立しており、それが doc.ruby-lang.org/en/ で提供されたとしてもそれを翻訳したものは doc.ruby-lang.org/ja/ では提供しないと考えました。私からすると RDoc と新リファレンスはあまりにも違うものですから... このため RDoc は rdoc.ruby-lang.org/<バージョン> といった提供になると想像しました。
（こちらはるりまとは別件として ruby-lang.org での提供を管理者と相談したいと思います）

結局 /ja/man/ としても無駄に URI が長くなるだけで、今後もしばらくは私が想像したような新リファレンス以外の日本語のドキュメントや各国のドキュメントは提供されない可能性があります。

もちろん提供される可能性はありますが、そのようなドキュメントはまずは個人で記述して、そこへのリンクを www.ruby-lang.org に転記することから始まり、それが公式ドキュメントの昇格するような感じではないでしょうか。ruby のプロジェクトはすでに十数年が経過していますが、 www.ruby-lang.org からリンクされているドキュメントが少ないことを見ると今後もしばらくは ruby プロジェクトが公式に提供するようなドキュメントがあるとは思えませんでした。

以上から、新リファレンスのみを扱うドメインで新リファレンスを提供することを提案しました。それが rurema.ruby-lang.org です。URI も http://rurema.ruby-lang.org/<バージョン>/ と、とてもすっきりしたものになります。今後のことを考える必要はありません。 /ja/man/ なのか /ja/ref/ なのか、はたまた /ja/reference/ といった検討も不要です。

これが私が rurema.ruby-lang.org を提案したときの私の考えです。

みなさんの意見をお聞きしても私の考えは変わっていません。しかしながら、るりまプロジェクトでは今後とも作業される方の意見がとても重要だと思いますので、特に okkez さんの http://doc.ruby-lang.org/ja/<バージョン> は良いと考えています。

ドメインを検討する期限は 12/23 とします。それ以降だと会社が冬休みに入ってしまい ruby-lang.org の DNS の設定が難しくなりそうだからです。逆に言うとそれまでは検討できますので、もう少し意見をお待ちしたいと思います。

2. 提供するコンテンツについて

bitclust で動的なドキュメントを提供するならば静的なものは提供しません。okkez さんは両方のドキュメントを提供されていますが、静的なドキュメントを提供した方が良い理由はありますでしょうか。ユーザが permanent リンクをはるためにどちらか一方にしたほうが良いと考えています。bitclustより優れた検索機能を今月中に提供するのは難しいと判断し、bitclustだけを提供することにしました。

また、提供する新リファレンスのバージョンは doc.okkez.net と同じ全てのバージョンでよいと考えています。
1.8.0や1.8.1といった過去のバージョンを提供しないほうがよい理由は何かありますでしょうか。それによっては、最新のリリースバージョンのみにします。

なお、リリースバージョンの zip や chm の提供を考えております。過去のリリースバージョンを格納するための archives のようなディレクトリの用意もする予定です。

以上です。
よろしくお願いいたします。

On 2009/12/18, at 10:54, Takao Kouji wrote:

> NaClの高尾です。
>
> 新リファレンスマニュアルをruby-lang.orgで提供できるように準備しています。
> 前田さんと相談したところ、次のような方針でどうかという話になりました。
>
> * Rubyのプロジェクトで使える新マシンがあるので、そこで新リファレンスマニュアルを提供する。
> 　これは、新マシンのリソースに余裕があることと複数のマシンを管理するのは大変だからです。
>
> * 新リファレンスマニュアルを提供するためのサブドメインを用意する。
> 　これは、一部のサービスしか新マシンに移行できていないため、サブドメインを用意した方が都合が良いためです。
>
> そこで、サブドメインの名前を決めたいと思います。
> rurema.ruby-lang.org でいかがでしょうか。
> 今月中には移行したいので、なるべく早く意見がほしいです。（急がせてすみません）
>
> また、リファレンスマニュアルを提供するためのURLは以下を考えています。
> こちらにも意見が欲しいです。
>
> * http://rurema.ruby-lang.org/
> 　http://doc.okkez.net/と同様に各バージョンの新リファレンスマニュアルへのリンクと、ニュースやメンテナンス情報を提供する。
>
> * http://rurema.ruby-lang.org/<バージョン番号>
> 　各バージョンの新リファレンスマニュアルを提供する。問題がなければRack+bitclustで運用します。マシンへの負荷が高すぎるようであれば代替手段を検討します。
>
> 以上です。
> よろしくお願いいたします。
>
> ---
> TAKAO Kouji <kouji@t...>
> blog: http://d.hatena.ne.jp/kouji0625/
> twitter: takaokouji / projects: ruby, s7-seven
>
>
> --
> ML: ruby-reference-manual@m...
> 使い方: http://QuickML.com/

---
TAKAO Kouji <kouji@t...>
blog: http://d.hatena.ne.jp/kouji0625/
twitter: takaokouji / projects: ruby, s7-seven


--
ML: ruby-reference-manual@m...
使い方: http://QuickML.com/