Fork 白方です。
それでは頂いたアイデアについて検討してみます。
まず、現状の流れをこう想定します。
* matsuandさんが翻訳する。
* ribbonさんが校正する。
(ribbonさんに完全に甘えた形になって済みません…)
* matsuandさんがリリースする。
今回のアイデアだとこうなるでしょう。
* matsuandさんが翻訳する。
* ribbonさんが校正する。
* 管理者全員(5人)の承認を得る。
* matsuandさんがリリースする。
ちなみに管理者は関根さん、matsuandさん、元木さん、長南さん、私です。
matsuandさんは本人票で問題ないとして残り4票です。
さて、これを実行するとどうなるかシミュレートしてみます。
1. リリースが止まる
おそらく関根さんはMLを読んでおられないと思うので(もし読んで
おられたらごめんなさい…)この変更に気付かず、関根さんの票が
入ることはないでしょう。
とは言えこれは直接関根さんに連絡を取ることで解決できます。
次に起きるのは:
2. 管理者を退任する
理由はともあれ現在全く関わっておられない関根さんにとって
定期的に承認してと言われても困るだけでしょうし、それなら
退任する、ということになると想像します。
(そもそも自分が管理者になっていることも覚えておられない
可能性もあります)
となると残り3票ですが、自分が多分想像するのは:
3. 機械的に承認する
本人が読んでおられるところで勝手に想像するのも失礼な話ですが、
もし校正をしっかり確認される余裕があるなら既にされているはずで、
その余裕がないということであれば良くてこれ、あるいは 2. かもしれません。
さて、これで管理者全員の承認によってリリースされることになります。
ところで、これで当初の目的である「リリース物の品質向上」は
実現されているでしょうか?
私には向上しているとは思えません。
先のメールでこのアイデアで実現できること、というのを
書いて頂いたので確認してみましょう。
> プロジェクトとして：
> ・翻訳成果物の一定の品質を、
> プロジェクト全体として評価したもので
> あることを内外に示すため。
正直これはよく分かりません。
制度を示したところで実際に品質が上がっていなければ
無意味ではないでしょうか?
これは保留としてみます。
> ・翻訳成果物の不備は、プロジェクト
> 全体で対応協議するものであり、
> 一翻訳者や一校正者に責任を
> 負わせない。また矢面に立たせない。
これは先のメールで:
> 仮に苦情が寄せられた場合には、
> 「プロジェクトとしては関知しない。翻訳担当者に文句を寄せる
> なりしてください」といった対応にもなりかねません。
と書いて頂いた話だと思うですが、これは誤解です。こうはなりません。
プロジェクトが責任を負わないのと同様、翻訳者や校正者も責任を負いません。
万が一(どのようなものを想定しているかは分かりませんが)苦情が
プロジェクトに寄せられたとしても、単に無視して終わりです。
さらに万が一どうしてもコメントが必要となったとしても
「無保証なのでプロジェクトとしても翻訳者個人としても関知しない。
文句があるなら自分で直してください。」というだけです。
従ってそもそもこれは問題になりません。
# 余談: 私はいろんなプロジェクトで翻訳作業をかれこれ20年はやっていますが、
# プロジェクトとしても個人としても苦情に類する物を受け取ったことは
# 1回もありません。
もちろん誤訳の指摘のような建設的な意見はプロジェクトで対応を
検討することが多いとは思いますが、それも実際作業するかはその時の
判断です。
> ・プロジェクト内部の問題として、
> 明らかに低品質と思われる成果物、
> あるいは悪意や不適切な表現など
> が行われる場合の歯止めとするため。
特に品質は上がっていないので歯止めとしては変わっていません。
> プロジェクト管理者として：
> ・プロジェクト管理者として、管理すべき
> 内容を常々自覚するため。
> （できる範囲で対応し、できない場合は
> 形式的な判断で済ます）
これが的外れと言うことは先のメールで説明しました。
「（できる範囲で対応し、できない場合は形式的な判断で済ます）」という
点についてはすでに皆さん実行されているのでこのアイデアで改善することは
特にないと思います。
ということで、追加で管理コストを掛けたにも関わらず特に付加価値を
生み出せていない、ということを自分なりに示してみました。
とは言え、先のメールで書いてくださったように「全員でなくても良い」となれば
多少話は変わります。LGTMの話まで辿り着けませんでしたが
既に長くなってるのでこの話は別メールにします。