Fork#44275: 全体課題
登録: 2022-04-03 11:06
最終更新: 2022-04-19 09:58
このチケットのURL:
https://osdn.net//projects/linuxjm/ticket/44275
このチケットのRSS feed:
https://osdn.net/ticket/ticket_rss.php?group_id=5110&tid=44275
---------------------------------------------------------------------
このチケットの最終修正/コメント:
2022-04-19 09:58 更新者: matsuand
* 詳細が更新されました
---------------------------------------------------------------------
チケットの状態:
報告者: matsuand
担当者: matsuand
チケットの種類: サポートリクエスト
状況: オープン [担当者決定済み]
優先度: 9 - 最高
マイルストーン: (未割り当て)
コンポーネント: (未割り当て)
重要度: 5 - 中
解決法: なし
---------------------------------------------------------------------
チケットの詳細:
本チケットは、当プロジェクト全体にわたって、課題と捉えられるものを総括的に示すものです。
今後、課題と認識されたものは、当チケット本文に加筆していきます。
各課題個別の討議や検討進行は、新たにチケット起票していくことにします。
本チケット内の各課題がすべて、個別のチケットに起票された段階で、本チケットは終了とします。
プロジェクト全体
* 管理者不明確: システム管理者が不明、不在
* プロジェクト憲章なし
* プロジェクトの意思決定手続きが不明； http://linuxjm.osdn.jp/copyright.html に「多数決で意思決定される」とあるが、母数が何か不明； JM:02434 にて「標準協議手続き素案」が掲示されたが、議論立ち消え。
用語
* man ページのことを随所で roff ページと表現しているが不自然。man ページと表現すべき。
ドキュメント
* Web上ドキュメント不十分
* Web上ドキュメント古いまま
サーバーバッチ
* サーバーサイドにて定例バッチを動かして、tarball 生成や関連htmlを定期的に生成しているが、これが本当に必要なのか不明。不要として良いのでは？ そのかわりにリリース時に単発バッチを起動して、同じことをリリースタイミングごとに手動起動すればよい。その方が手間がかかるとも言えるが、１つのコマンド実行が増えるだけと考えれば、さしたる手間ではない。むしろその方が合理的（＝リリースしたい時にリリースする。リリースを間違えた時はその場で直す。draft を挙げたい時にアップロードする。これらの例はサーバーバッチ処理方式では、すべて定期実行タイミングを待たなければならない）。
配布物
* 全体アーカイブ (man-pages-ja-YYYYMMDD.tar.gz) が、更新がなくても月１回の定例バッチにより、新たな日付で提供されている。
* パッケージ別アーカイブ (man-page-ja-<packagename>-YYYYMMDD.tar.gz) が、更新がなくても月１回の定例バッチにより、新たな日付で提供されている。
* パッケージ別アーカイブ (man-page-ja-<packagename>-YYYYMMDD.tar.gz) の名称に、"man-page-ja" をつけることがそもそも不自然。LDP man-page の名称に "-ja" をつけたものと解釈される。名称が長くなりすぎるので、たとえばばっさりと "jm-" といったプリフィックスのみとするのがよい。
* パッケージ別アーカイブは、man-page-ja-<packagename>-<version>.tar.gz のように、元々の翻訳対象パッケージのバージョンに合わせて提供すべき。(git 管理手法をどうするか、定例バッチの大々的改修にも及ぶため、おおごと。ただし重要なこと。)
* 全体アーカイブ、パッケージ別アーカイブの生成は月１回の定例バッチに委ねられており、リリース担当者によりリリースの都度、アーカイブ生成する手順が確立していない。
* パッケージ別アーカイブ内の README ファイルが、全体アーカイブの README となっていて、パッケージ別の README になっていない。
* http://linuxjm.osdn.jp/download.html のパッケージ別アーカイブでは、man-page-ja-<packagename>-YYYYMMDD.tar.gz と nn kbytes: yyyy-mm-dd という２箇所において年月日表記が存在する。これらは定例バッチ内にて日付文字列を取得する方法が異なっており(ロケールが統一されていないため)、定例バッチを日中に実行すると日付がずれる。
* 配布にあたって "Linux packages" と "Miscellaneous package" と切り分けているが、その切り分け方が不明。
* JM インデックス (作業状況) (http://linuxjm.osdn.jp/INDEX/progress.html) の存在意義が不明確。何を示すページなのか。作業中であり、途中経過を暫定公開する意味？ 翻訳意欲を促す意味？ 「×」、「ｃ」、「☆」しかないものは表示する意味なし。極論すれば、ドラフトページへのリンクのみが存在して、「現在この翻訳が進行中です」と示したら十分ではないか。
* JM インデックス (作業状況) (http://linuxjm.osdn.jp/INDEX/progress.html) において、translation_list のステータス記号を用いているが、そもそもこの記号を正確に分かる者は、たぶん当プロジェクト内にも存在しない？！ それをユーザーに示したところで、ユーザーは理解できるはずがない。たとえ冒頭に凡例および説明を付けたとしても、理解できるはずもなく、理解しようとするユーザーは皆無のはず。改訂すべき。
translation_list
* 各項目をコロンで区切る書式としているが、各項目内にコロンが入ることを想定していない； 一例として http://～ といった表記を含めるとカラム区切りがおかしくなる； 通常はカンマ区切りかタブ区切りとして、各項目を必要に応じてクォート括りとするのが一般的
* man ページの拡張子が *.\[0-9n\]$ しか想定されていない； *.1x, *.3pm, *.3ssl などに対処できていない ＝＞ #43966 へ
* ステータスのあり方が全体に不自然； 「☆：原文の改訂版がリリースされた。要改訂」の存在意義なし（翻訳作業のステータスではない）； 「▲: 翻訳予約・作業中」と「■: 改訂予約・作業中」の両存在の意義不明（＝翻訳第１回めと２回め以降を区分けしているが、２回めと３回め以降は区分けしていないという不自然）； オブジェクト指向設計やDBテーブル設計を想起すると、如何に不自然か
* 第8カラムめのライセンス表記欄は、運用不徹底の様子 ＝＞ #44233 へ
* translation_list 内にかつて含まれていたエントリーが不要（manページ削除等)とされた際に obsoleted_list なるファイルに転記しているが、このファイルの存在意義が不明。ファイルそのものが不要ではないか。
* 第2カラムにて、「リリース版・ドラフト版・オリジナル版でバージョンが異なってしまった場合には、 => で区切って記述」とあるが、この "=>" を設ける意味が全くわからない。不要。旧バージョンを保持したところで、それが何の役に立つのかも皆目不明。「これは ver 1.1、これは ver1.2 、・・・」と示されたところで、ユーザーが対処を切り分けて行動するのか／させるのか？ ＝＞ このカラムにおける「旧ver => 新ver」表記の真の意味は、新規訳作業着手中であって旧訳が存在しているという状態を示す "フラグ" の意味ではないか。つまり旧verが必要なのではなく、=> という文字表記が "フラグ"（旧訳が存在しているかどうか）を表すのではないか。
--
Linux JM (Japanese Man-page) Project プロジェクトのチケット情報です
Linux JM (Japanese Man-page) Project プロジェクトはOSDNにホスティングされています
プロジェクト URL: https://osdn.net/projects/linuxjm/
OSDN: https://osdn.net
このチケットのURL:
https://osdn.net/projects/linuxjm/ticket/44275
このチケットのRSS feed:
https://osdn.net/ticket/ticket_rss.php?group_id=5110&tid=44275