[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: where is a preferable place of -doc|www contents.
岡@奈良先端です。だいぶ時間が空いてしまいました。
"佐野"すなわちTaketoshi Sanoさんより:
佐野> 佐野@浜松です。
...
佐野> ということで、doc 関係の議論を考えていこうかな、と。
なので、一つ前のメールに遡ります。
"佐野"すなわちTaketoshi Sanoさんより:
佐野> 佐野です。
> 文書の置き場は Documents 以下でいいと思いますが、Project 内
> での作業のための情報は、devel/doc の下でいいと思ってます。
> # devel な用件のうち doc 管轄だと。
> 佐野> 既に devel/doc として作成してしまわれたようですが、www.debian.org を
> 佐野> 見るとすくなくとも /doc は /devel と独立した場所にあります。
>
> doc/ と devel/ を独立させる事自体には反対しませんが(devel,
> doc, www が独立になるって事ですよね)、
佐野> そのとおりです。 /devel, /doc, /www はそれぞれ独立にしたほうが
佐野> わかりやすいと思います。
であればこちらの方向性で。
> おっしゃるように、既に -doc な内容がこちらに入っていますが、
> 「Debianを使う上で参照するドキュメント」と「Debian JP
> Projectの活動上で必要なドキュメント」とは、明確に分離してお
> いた方がいいんじゃないかと思います。
佐野> 「ユーザマニュアル」と「開発者向けマニュアル」を分けよう、と
佐野> いう主張ですか ? それにはあまり賛成しませんが、とりあえず今回の件とは
佐野> 別に doc ML で議論したほうが良さそう。
違います。僕の認識では、
* User's Manual
* Developer's Manual
はDebian共通で使い回しが利くもの、つまりパッケージにもなって
いる程度のドキュメントで、それをWebにも置いている(あるいはパッ
ケージより最新版を参照できる)といった意味合いのものだと思い
ます。翻訳版についてもJP特有の事情が入っているものの、同じ程
度のものだと思います。
先のメールでの書き方が悪かったみたいなので書き直すと、
* Debian JP Project の作業で、*.debian.or{.jp,g} の運用に
かかわるドキュメント(Web,CVS,)。
を分離すべきだ、と言いたかったのです。-wwwであれば
www.debian.orgのコンテンツ翻訳作業に必要な情報を書いたドキュ
メント、-docであれば翻訳作業に必要なドキュメント、です。
佐野> 現状だと「JP オリジナル」の文書にも「日本語翻訳版」というタイトルが
佐野> 付いていて、おかしな気がするし、「リリースノート」と「インストール
佐野> マニュアル」が分離していて、それぞれまとまっているのは「リリース別」
佐野> にまとめたほうがユーザーにはわかりやすいだろうし。
佐野> 全体に「過去の (obsolete な) 文書」と「最近の (effective な) 文書」が
佐野> 混在していて、わかりにくい気がします。
パッケージがディストリビューションごとにリフレッシュされて健
全性を保っているのと同様、翻訳ドキュメントについても同じアプ
ローチが必要ですね。
# 完全に同じにするなら、追従できないのなら切り落すぐらいの
覚悟が必要 (^^;
佐野> あああ、このへんは doc ML にしよう、と書きながら意見を主張してますね。
佐野> ごめんなさい。続けるなら doc ML に振ってください。
で、振りましたが、あっち行ったりこっちへ行ったりですね。
そもそも-docと-wwwの境界線がはっきりしてなさすぎると感じるの
は僕だけでしょうか。
僕流の切り方をするなら、
devel-package:
パッケージ開発。
devel-server-admin:
*.debian.or.jp の管理。www, cvs 全て一任。コンテンツにつ
いては各々のプロジェクトに委譲、やりとりをする。
devel-translation:
Web, manual 問わず鬼のように翻訳をする。技術的な開拓作業
は他に委譲。
devel-i18n:
謎。
こうすればWebは同じ権限でいじりまわせて、妙な遠慮は無しにで
きます。翻訳はwww.debian.orgだから-wwwに入る、とか奇妙な分類
にならずに済みます。また、翻訳する人がWebに情報載せたいがた
めにそっちの仕事までやる事になる非効率も改善されるかもしれま
せん(きちんと委譲されれば)。
とにかく、抱え込んで転んでしまうアプローチ(?)は改善していか
ない長続きしません。
--
岡 充 (Mitsuru Oka)
奈良先端科学技術大学院大学