いしかわです。 こんにちは 大橋さん、小笠原さん 情報共有ありがとうございます。
横からすみません。 あまりLibreOffice の今までの開発の流れが分かっていませんが、少し気になった点を記しておきます。 長くなってしまいました。すみません＞＜ （１） > ・投票者はPootleアカウントを明記し、上記選択肢から1つ選択して投票。 > コメント欄に選択した理由を記入 > ・投票数の過半数を得たものを採用し、その他の提案は却下する > ・要継続検討になれば、本MLで話し合う > ・コメント欄は別途書き出してまとめる このへんもう少し詳しくご教授していただきたいです。 私の理解では、一つの訳の査読を複数の人で査読を行い、投票結果に基づき、訳を採用するかどうかを判断するということでしょうか？ もし、そうなら、投票がほとんどあつまらないとおもいます。（理由は手間だから） Calc で残査読をリストアップするのは良いと思います。 （※ 誰が管理するかで揉めそうな気もしますが。。。） 共有するのは github はどうかな？と思います。 google の機能はわかりませんが、github なら共有ができ、変更履歴を管理でき、ブランチを切れますしね。 （※ 特にgoogle で反対しているわけではありません。他の選択肢としてgithub があるというだけです。） ------ （２） この議論が出てきた背景には、「査読者の受け持つべき責任範囲が曖昧」であるのではと私は考えています。 正直な話、私が査読で見てほしいところは2 点だけです。 【a】 このままの翻訳データだと、ソフトウェアのビルドが止まってしまう事の指摘 【b】 文字化けしていないか？ です。 (前の査読依頼には書いてありませんでした。ガイドラインの議論を見直し、文章に起こしています） 特に専門的な内容の訳をだしたので、内容は翻訳者の私の方で責任を持つ考えです。 でも、おそらく、翻訳者によって査読でやってほしい内容が違うでしょう。 私の考えですが、以下の内容をガイドラインに入れることはどうでしょうか？ ★ 翻訳者が査読依頼をメールで出す時に、査読して欲しい観点を記すようにする ★ 査読者は翻訳者のメールに記されている内容と、最低限の査読(例えば上記【a】【b】※）を行う。 ★ 翻訳者のメールに観点が書いてなかったら、定められた最低限の査読だけを行う。 （※ 最低限の内容はここでは私が勝手に決めただけなので、要議論） で、できるだけ、査読のプロセスを軽いものにしたいです。（一番重要） 理由は、査読を本当にきっちりやっても、誤訳は残りますし、それよりは、苦痛にならないように査読をやってほしいです。 （たくさん残査読がありますし・・・） いかがでしょうか？ On Thu, 7 May 2015 14:47:17 +0900 Naruhiko Ogasawara <naru...@gmail.com> wrote: > 小笠原です。 > > 本件、査読権限を持つ持たないに関わらず広く意見を求めたいところです。 > > 個人的にはプロセスはもう少し軽いほうがいいかなと思いますが、代案が > あるわけではありません。 > 最終的な決定はベンダー中立な場所に置きたい気もしますがGoogle Docs > でもさしあたってはよいかなーと思います。 > > 2015年5月3日 0:18 Kazumi OHHASHI <paz.ohha...@gmail.com>: > > こんにちは、大橋です。 > > > > 本件、考えていることを書き出してみます。 > > （プランはいろいろあるんですが、まず一番シンプルそうな形で） > > > > ■目的 > > ・現在Pootle上で未査読の提案を集中的に整理する > > ・そのプロセスで査読の基準を明文化していく > > > > ■方法 > > ・「調整くん」のようなイメージでCalcファイルを用意 > > ・審査する各String ID に対し、以下の選択肢 > > 1.現行訳を存続 > > 2.現提案一番上を適用 > > 3.現提案上から2番めを適用 > > 4.現提案その他を適用（コメント欄で明示） > > 5.要継続検討、その他（コメント欄で明示） > > 6.提案者コメント > > > > ・投票者はPootleアカウントを明記し、上記選択肢から1つ選択して投票。 > > コメント欄に選択した理由を記入 > > ・投票数の過半数を得たものを採用し、その他の提案は却下する > > ・要継続検討になれば、本MLで話し合う > > ・コメント欄は別途書き出してまとめる > > > > ■スケジュール > > ・思いつきですが、今回は5.0のリリースに合わせることを目指したらどうでしょうか？ > > （Master がどのタイミングで取り入れられるかは理解できていませんorz） > > ・重要そうなフォルダから始めて、適宜追加していく > > > > > > ■未決 > > ・これでいくとして、どこにどうやって書き出すか > > （私はGoogle ドキュメントを共有するくらいしか思い当たりません） > > ・投票結果の決定プロセスはもう少し詰めたいところ > > > > > > > > 皆様のお知恵をお寄せいただければありがたい次第です。 > > どうぞよいGWを。 > > > > > > 大橋 和美 > > > > 2015年4月30日 23:50 Naruhiko Ogasawara <naru...@gmail.com>: > > > >> 小笠原です。 > >> > >> > >> 大橋さんの呼びかけはとても意義があることで、確かに効率的なやりかたを > >> 考えたほうが望ましいです。 > >> そのためには短い期間（スプリント）で一気に片付けるやり方がよいというの > >> も同意します。 > >> > >> メールを拝見するに、大橋さんの中では、どのように作業すればよいかという > >> 絵図がわりと描かれているのではないかなと思いますので、ぜひ、具体的な > >> 作業までをリードしていただくよう、お願いしたいです。 > >> 具体案のないまま進め方などをMLで議論すると、お見合いになってしまって > >> ずるずると決定が遅くなる嫌いがありますので、思いがある方がまずは骨格 > >> を提案していただく方が適切だと考える次第です。 > >> > >> > >> もちろん、なにか手伝えることがあれば、可能な限りお手伝いはします。 > >> > >> > >> では。 > >> > >> 2015年4月30日 22:31 Kazumi OHHASHI <paz.ohha...@gmail.com>: > >> > 大橋です。 > >> > > >> > 多くの方が忙しいところ手を動かしていると思うので > >> > 効率的に進めることを検討したいです。 > >> > > >> > まず、私が効率的にできていないだけで、いいやりかたを > >> > ご存知の方いらっしゃいましたらご教示いただければ有難いです。 > >> > > >> > ガイドラインを作るとしたら、テキストを書き始めるのでなく、 > >> > 現在Pootle上にある1300近い提案を、範囲と期間を決めて > >> > 集中的に意見をだしあうようなことができたらいいなと考えています。 > >> > （例：5月後半にはcuiフォルダの提案を集中審議する） > >> > > >> > その話し合いの中で出てきた判断材料をオンライン上（Wiki とか Google ？github？）で > >> > まとめていけば、それがガイドラインの元になるのでは、と考えております。 > >> > > >> > > >> > 大橋 > >> > > >> > 2015年4月28日 18:12 Naruhiko Ogasawara <naru...@gmail.com>: > >> > > >> >> 小笠原です。 > >> >> > >> >> 結論から書きますと、 > >> >> > >> >> > 査読のガイドラインか、それに類するものがありましたら教えてください。 > >> >> > 個人的には、提案を却下する基準があるとやりやすいかなと思います。 > >> >> > >> >> そういうものは現状存在しないというのが私の認識です。 > >> >> 私が査読を行うときになんらかの規範があるかというと、明文化できるのは > >> >> > >> >> ・特にMLなどで問題提起がなければ現行訳踏襲 > >> >> （もちろん、現行訳が明らかに間違いで、新規提案のほうが > >> >> 理にかなっているというのが明らかな場合は別） > >> >> ・現行訳を上書きする提案で、MLで議論があり、結論が出ていないものは提案却下しない > >> >> > >> >> ぐらいしかないですね。 > >> >> > >> >> # 私は提案却下に相当臆病なほうで、これは正直、査読者としては > >> >> # 欠点なんでしょうね。 > >> >> > >> >> > >> >> ガイドライン程度のものはあってもいいだろうなあとは思いますが > >> >> 整備しようという強い気持ちはないですね。 > >> >> どなたか主体的に動いてくださるなら、お手伝いはします。 > >> >> > >> >> > >> >> > 「エラーバー」については、議論があったので、コメント欄に記入しても > >> >> > いいのかな？と迷っています。 > >> >> > >> >> 「エラーバー」については問題提起はあっても結論は出ておらず、 > >> >> 問題としてはオープンなので、コメント欄に書いて提案は残して > >> >> おくのが私流です。 > >> >> > >> >> > >> >> > >> >> > 現在、多くの提案が出されていますが、査読時に判断に困ることが多く、 > >> >> > 同じ提案を何度も見たりして効率が悪いと感じています。 > >> >> > >> >> 非効率ではありますね。 > >> >> 一度えいやと整理したいところではありますが、無精で後手に回っ > >> >> ています。どなたか音頭をとって整理してくださると嬉しいです。 > >> >> > >> >> > >> >> では。 > >> >> -- > >> >> Naruhiko Ogasawara (naru...@gmail.com) > >> >> > >> > > >> > -- > >> > Unsubscribe instructions: E-mail to > >> discuss+unsubscr...@ja.libreoffice.org > >> > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > >> > List archive: http://listarchives.libreoffice.org/ja/discuss/ > >> > All messages sent to this list will be publicly archived and cannot be > >> deleted > >> > >> > >> > >> -- > >> Naruhiko Ogasawara (naru...@gmail.com) > >> > > > > -- > > Unsubscribe instructions: E-mail to discuss+unsubscr...@ja.libreoffice.org > > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > > List archive: http://listarchives.libreoffice.org/ja/discuss/ > > All messages sent to this list will be publicly archived and cannot be > > deleted > > > > -- > Naruhiko Ogasawara (naru...@gmail.com) > > -- > Unsubscribe instructions: E-mail to discuss+unsubscr...@ja.libreoffice.org > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > List archive: http://listarchives.libreoffice.org/ja/discuss/ > All messages sent to this list will be publicly archived and cannot be deleted -- Souichirho Ishikawa <souichi...@gmail.com> -- Unsubscribe instructions: E-mail to discuss+unsubscr...@ja.libreoffice.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/ja/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
