[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][TOP]

Re: [査読依頼]gnome-help#screen-shot-record


松澤です。

2011/11/4 Yasumichi Akahoshi <yasumichi@xxxxxxxxxxxxx>:
>  赤星です。
>  gnome-user-docs -> Tips & tricks -> Screenshots and screencasts
> にあたる部分を翻訳して push しました。
>
> https://github.com/jmatsuzawa/gnome-user-docs/commit/b72effc8ef5d2e3c8f16f1cef28b37942f209fcc
>
>  ご査読のほど、よろしくお願いします。

すみません・・・
gnomejaブランチにpushしましたよね。
以下のとおり、gnomejaブランチはレビューを経たものをcommitするように考えていました。

2011/10/21 Jiro Matsuzawa <jmatsuzawa@xxxxxxxxxxxxx>:
> 5. 翻訳者は、パッチ形式でML宛てにレビュー依頼を出す。
> 6. githubリポジトリの管理者は、レビューを通過したパッチをgnomejaブランチに取り込む
>  (各翻訳者がgithub側の更新権限を取得して翻訳者自身で更新してもよいと
>  思う。というのは自明な誤字脱字など細かい修正はレビューを経ずに翻訳者
>  が直接更新できると楽だから)
> 7. 本家リポジトリのコミッターは、ある程度の翻訳が済めばgnomejaの更新を
>  masterにマージして本家にpushする。

7以降でリリースに耐えられる分量の翻訳がgnomejaに溜まった段階で、gnomejaをmasterにマージして本家リポジトリにpushする、という流れです。
「各翻訳者がgithub側の更新権限を取得して翻訳者自身で更新してもよいと思う」というのは、レビューを通過したものを想定していました。

ちょっとこちらの考慮も説明も不十分だったと思います。申し訳ありません。
特に5番のレビューの仕方が不明瞭でしたね。
そこで、明確化も兼ねて、あらためて提案ですが、
レビュー自体もgitで管理した方がやりやすいと思うので、レビュー用のブランチを設けるようにしましょうか?
たとえば今回の例だと、review-screen-shot-recordのような名前でブランチを切って、そこでレビューをする。
レビュー受けて修正する必要が生じれば、review-screen-shot-record を更新していく。
レビューが完了した段階で、review-screen-shot-record を gnomeja にマージする。
マージが済めば、review-screen-shot-recordブランチは削除する。
で、どうでしょうか?

「こうした方がやりやすい」や疑問点などあれば遠慮なくツッコんでください。
GNOME翻訳の共同作業ノウハウも蓄積できればいいと思うので、各メンバーがやりやすいと思う方法をどんどん取り入れていきたいと思います。



-- 
Jiro Matsuzawa
E-mail:
  jmatsuzawa@xxxxxxxxxxxxx
  matsuzawa.jr@xxxxxxxxx
GPG Key ID: 0xECC442E9
GPG Key Fingerprint: E086 C14A 869F BB0E 3541 19EB E370 B08B ECC4 42E9