元木です。 もう議論がほぼ終わったあとですが、私の考えを一応書いておこうと思います。 # メールが多すぎてどれにつなげればよいのか分かりませんが、スレッドにぶら下げるために # 適当にピックアップしてリプライにします。ピックアップしたメールに意図はありません。 翻訳、校正に対する考え =================== プロジェクト参加者は対等であり、翻訳のレビュー／議論は参加者間で行われる。 参加者は翻訳がより良いものとなるよう、それぞれが可能な範囲で努力する。 読み手のことを考えると、動作を確認してみて裏付けを取る、なども、そのひとつでしょう。 義務ではありません。気がついた人がコメントすればいいですし、その人が全部確認できる わけではないので、翻訳者の人にも確認してみて、というお願いすることもあるでしょう。 会社のプロジェクトと違い、みんなが同じ優先度で動いているわけではないので、 あくまで各人は自分のペースで議論に参加する。 リリースに対する考え ================= リリース（別プロジェクトでいうと merge とか commit になるのかな）に関しては、 人数が少ないプロジェクトで、各自の優先度も違う中では、 軽いプロセス かつ ボトルネックが少ないやり方が望ましいと思っています。 例えば、私が参加している大規模なOSSプロジェクトでは、 コードのマージ権を持つ人が 2人 Looks Good をつけたら、2人目のマージ権を持つ人が merge/approve を行う、というモデルを基本としています。 これが基本ですが、もっと人数が少なくなると、マージ権を持つ人 1人で approve する こともありますし、状況によっては self approve もあります。 JM にあてはめると、現在は self approve になるのかなと思います。 これが、コメント、フィードバックが一通り出て反映したと思った段階でリリース宣言する、 という運用になっているのだと思います。 もう少し LGTM のような positive な ACK をもらってリリース判断をしたい、という気持ちも 分かります。それなら、コメントを反映した上で、LGTM を 2つもらったらリリースにする、 そうでなければ、N 日間待って（自分で見直して OK なら）リリースする、とか、 Single LGTM でリリースする、とか、といった緩い運用もあると思います。 （すでに別のスレッドで案として上がっていますよね） 一方で、提案にあった機械的な承認に関しては、あまり効果はないと思っています。 見ていないのに LGTM はつけられません、SNS の「いいね」の例がありましたが、 それでも中身を見てもいないのに「いいね」することはないと思います。 プロジェクト管理者？に対する捉え方 ============================= 私自身は「プロジェクト管理者」という言い方をこれまで使ったことがありませんでした。 場を提供する作業をしている「インフラの管理者」という認識でいます。 linuxjm という osdn.net のプロジェクトの場の用意、コンテンツの取りまとめ、 ウェブ経由での公開、などを行っている。 osdn.net の用語として「(プロジェクト) 管理者」という言い方は出てきますが。 po4a の導入など git リポジトリを取得して直接作業を行った方が楽であり、 翻訳作業でも Git リポジトリを扱う場面が出てきた、という状況の変化により、 従来の説明では不十分で、 translation_list を使った仕組みなど、いろいろな場面で、 混乱が生じているのだと思います。 余談 ==== 時間が取れていた頃は matsuand さんの翻訳にコメントをしていましたが、 あまりの物量に圧倒されて気力が尽きたのと、コメントをしてもその後の反応が かなり経ってからでこちらも内容を忘れてしまっているのですぐに反応できず、 という負のループに入ってしまった印象があります。全部捌き切れるのが理想的 でしょうが、ひとつひとつをじっくり見るスタイルの自分には無理で力尽きました。 今振り返ると、ページごとに短いフィードバックループで片付けてリリースまで 持っていけたら、状況は違っていたのかな、とも思いますが、あとの祭りですね。 以上、考えていることを書き連ねてみました。
Fork