[10:44] オンラインなもののちょっと席外したりします（あとわりとくたびれているので寝落ちの危険アリ） [10:44] そして先週はすんませんでしたー（熱出して死んでた） [10:45] いえいえ、ご自愛を最優先で [11:00] ちょこっと用事が終わってないので30minぐらい席外します、すみません [11:01] はーい [11:01] こんばんは [11:01] こんばんはー [11:01] こんばんは [11:01] こんばんは [11:02] 今日は誰が司会進行しましょうかー [11:02] こんばんは [11:03] いくやさんが司会がええんとちゃうかな [11:04] じゃあ今日もやりますか…… [11:04] では、IRCミーティングを始めます [11:04] んじゃぁ議事録やります。 [11:04] https://wiki.ubuntulinux.jp/IRCMeeting/20170312 [11:04] 以後終了まで発言できるのはCoCに署名した方のみです [11:05] 議題が増えていますね [11:06] 前回の議事録を参照して、金曜日に更新しておきました。 [11:06] ありがとうございます。 [11:06] 柴田さんgarevert 処理は [11:06] おっと [11:06] > 17.04 翻訳作業中に確認した問題について [11:07] あ、続けてください [11:07] 前回議題にあがったrevert処理は一通り完了しました。 [11:07] 柴田さんが土曜日にrevert処理を完了したと思いますので、 [11:07] 報告だけいただければいいかなーと思います。 [11:07] > revert 関係に関しては。 [11:07] ただ議題にあがったリストが妥当かという話がMLにあがっていますので、 [11:08] この議題の続きはMLですすめるという形で良いと思います。 [11:08] （ここで何か確認しておきたいことがなければ [11:08] 特に追加で話しておくことはないかなぁと思いますねぇ [11:09] 了解です。 [11:09] call for translationはどのタイミングで出す、というのはコンセンサスを得てもいいかもしれません [11:09] プロセスの見直しを考慮するかしないかという点で [11:09] CfTは、revert作業の完了が必須という認識です。 [11:10] あぁ、revert作業の完了とプロセスの見直しの完了の両方が必須？ [11:10] かどうかですね [11:10] あ、「必須とすべきかどうか」を議論する話だったのですね。理解できていませんでした。 [11:10] はい、そうです [11:11] 必須とするべきであれば、最悪17.04では見送らないといけなくなるかもしれません。かといって、見直しが完了しないのにCfTを出すのは誠実ではないと取られるかもしれません [11:12] 柴田としてはrevert作業については必須とすべきと考えています。プロセスの見直しは変更内容次第かなぁ。 [11:12] というわけで、議題としてプロセスの見直しを先にやるのはいかがでしょう？ [11:13] プロセスの見直しの結論は多分今日中には出ないので、それにつられてCfTが遅れるのはちょっと割けたいところです。 [11:13] なるほど。 === chonan_ is now known as chonan [11:14] いや、最低限のところだけ決めればいい気がしてきました [11:15] 普通に翻訳する分には、現行ので特に問題ないと考えています。 [11:15] https://wiki.ubuntulinux.jp/Develop/TranslationGuide [11:15] ですね。 [11:15] 問題となるのは https://wiki.ubuntulinux.jp/enroll/translator_candidates かなと。 [11:16] もしこの前提が正しければ、CfT自体を出すことは問題ないように思います [11:17] 改定案の1だけでも、CfTの前にやっておいたほうがいいとは考えています。 [11:18] そうですね [11:18] ただやるかやらないか、誰がいつまでにどうやるかってのを「プロセスの見直し」議論するだろうと思っていますので、その議論が終わるまで柴田としてはCfTのタイミングについて意見を出しづらいなと思っています。 [11:19] では、まずは先にプロセスの見直しの話をする、というところから始めましょうか。 [11:19] たぶん決を採る必要はないと思いますので、ご意見がある方はどうぞ [11:20] 案3と5はマージできそうですね。 [11:21] ちょいと気が早いですよ。。 [11:21] では、プロセスの見直しの話をします。 [11:21] 気になってしまったもので・・・。 [11:21] 上から行きましょうか。 [11:22] > 1. ライセンス(3-clause BSD)を遵守することを追加する(ikuya) [11:22] とはいえ、これはもう書いてあるんですよねぇ === ken-i54k is now known as ken-i54k_ [11:22] なので、このライセンスと互換性のないものを突っ込まないでください、書くのがいいのかなぁと思うのですが…… === ken-i54k is now known as ken-i54k_ [11:23] 何かご意見のある方はどうぞ [11:24] （ご意見がないのか私の進め方が悪いのかわからない……後者のような気がしますけど…… [11:24] 「追加する」というよりは「強調する」のがいいのでしょうか。 [11:25] なるほど、そうですね [11:26] いまだと重要度のわりに埋もれちゃっているなぁと。いや、これが出てきたころはライセンス遵守は当然で、「スタイルガイド」を順守してもらうほうが重要だと感じてはいたのですが…… [11:26] 仰るとおりすぎてなんともはやです [11:27] でも、強調するにしてもうまくやらないと「重要・緊急・必須・拡散希望・いますぐ拡散を！」みたいなノリになってしまうんですよね…… [11:28] 結局どれが一番大事なのかわからなくなってしまうと... [11:29] ですです（ここに書いてあることは全部大事なんですけどね……） [11:29] 実際どのように書き換えるのかを相談するはちょっとこの場では難しいので、とりあえず方針を確認するだけなのでそのあたりは一旦置いとくしかない気がしますね…… [11:30] ライセンスに関して何か新しい項目を追加する必要はなく、強調する方法を考えるということでいいのでしょうか？ [11:30] はい、それでいいと思います。 [11:30] 了解です。 [11:31] 一応決をとっておきます？ [11:31] ごめんなさい、一点だけ確認ですがこの記載の追加箇所は「TranslationGuide」であっていますか？「スタイルガイド」の方ですか？ [11:31] 前者という認識です [11:31] 了解です。 [11:31] 「TranslationGuide を改定したい」という議題なので、スタイルガイドは管轄外だと思ってました…… [11:31] 了解です [11:32] 「スタイルガイド」が話題に出ていたので、ちょっとごっちゃになりました。 [11:32] ちなみにそもそも論として、「参加する人はガイドを読んでくれる」は前提にいれていいんでしたっけ…… [11:32] すみません＞スタイルガイド [11:32] 個人的には注意点の欄を短文にまとめ太字、その後は現在の記載を連ねるのがわかりやすいかな。。とは思っています。 [11:33] いえいえ＞スタイルガイド [11:33] Launchpadの翻訳UIの先頭につねに表示される以上、そこは前提にしていいのではないでしょうか＞ガイドを読んでくれる [11:33] そうですね。頭に乗っています。＞TranslationGuide [11:34] ですねー（確認してました [11:34] > Before translating, be sure to go through Ubuntu Translators instructions and Japanese guidelines. [11:35] この英語を読めない人が翻訳しようとするというのは流石に考慮外でいいのではないかと思うのですが……。 [11:35] そういうときのための、2.の提案だという理解です＞考慮外 [11:35] いちまつの不安が拭いきれない自分がいます…… [11:36] これも改定案WIPページが必要ですね……。 [11:37] あーなんか個別論に入ると無限に時間が吸われますね [11:37] 2に進んでいいでしょうか [11:37] hito_jp: 前提に立たない場合どういう対応になるのでしょうか？ [11:37] たぶんガイドでカバーできないので [11:37] MLで定期的に流すとかそういうフォロー対応が必要かなぁ、と。 [11:38] ガイドは読んでくれないけど、MLは読んでくれるだろうという前提に立つ？ [11:38] とはいえ例外的な事象に対してプロセスを重くするとろくなことがないという製造業由来の教えもあるので [11:38] えーと、少なくとも単一の方法でアプローチすると漏れるので、穴の空いた靴下は複数履きましょうというやつです [11:38] そういう意味では、CfTにはガイドライン読んでねというのはすでに対応済みですよね？ [11:39] CfTより頻度上げないとだめかなと [11:39] なるほど。 [11:40] まあプロセス重くしない方向にするのがいい気はするので（今回のは例外的事象だと思われる）、とりあえず気にしない方向で……。 [11:40] IRCミーティングのログに毎回入れておくとかですかねぇ…… [11:40] とりあえず議事録にはそういう提案があったということだけ書いておいてもらえばいいのかな。 [11:40] IRCミーティング定期開催するのしんどいー…… [11:40] ログじゃないサマリー [11:41] はい > 議事録 [11:41] でもCfTよりは頻度が上がるはずです [11:41] まぁいいや、2に行きましょうか [11:41] 議事録上では、案のひとつとして扱えると思いました。 [11:41] えーと、「頻度を上げるべきか」と「頻度の上げ方」を同時に議論するとしんどい [11:41] はい。 [11:41] ＞2.に行きましょう [11:42] とりあえず走らせてから後からGoということで、司会はもうがんがん進めて良いと思います [11:42] 議事録は大丈夫でしょうか？ [11:42] 頑張ってます. [11:42] では次へ [11:42] 先に進んでもらって構いません。 [11:42] > 2. ライセンス違反と見られる行動があった場合はこのような行動を取るという(今回の結論)を追加する(ikuya) [11:43] ようは映画泥棒みたいなやつですね [11:44] これって「revertしてね、さもなければrevertするよ」に要約できるやつです？ [11:44] そうですね。 [11:45] 1の附則でもOKです？ [11:45] 分けない方が分かりやすい気がする、という意味で。 [11:46] 1と2ってコインの裏表だと思うので……。 [11:46] 一番下に書いておくくらいかなと思っていましたが、確かにまとめてしまったほうがいいかもですね [11:46] 「revertするよ」はライセンス違反だけが対象ですか？ライセンス違反をのぞくガイドライン違反でなんらかの対応が必要になったときは、また別途考えるということ？ [11:47] それは都度でいい気がするんですよね [11:47] ライセンス違反だけでいいんじゃないですかねぇ。ガイドライン違反はrevertではなく普通に上書きするだけでいい気がします [11:47] ライセンス違反限定なら、1の附則のほうがわかりやすいと思います。 [11:48] revertを要求するシリアスなガイドライン違反って何がありえそうでしょうか。とっさに思いつかない。 [11:48] たしかに＞revertが必要になる例 [11:49] ライセンス違反ぐらいしかなさそうですかね。 [11:49] 最初のイメージがガイドラインの一番下に「このガイドラインに違反した場合は」みたいな項目が追加されるのかなというものだったので。 [11:50] ああ、非常事態対応プロシージャとしての立ち位置ってことですね。それは個別に議論にしたい……。 [11:50] では、2は1とまとめて目立たせる、ということでいいでしょうか [11:50] はい。異論はありません。 [11:51] 反応必要そうな時は> peersとかしてもらえると+1で反応できるので議事録係がはっぴー [11:51] これも特に決は必要なさそうかなぁと思いました [11:52] 議事録的に問題なければ次に行こうと思います [11:52] 大丈夫です。 [11:52] peersコールしないで済むパターンなら、wait発生しちゃうので次に行く方がいいと思いますー。 [11:53] waitは意図的に入れていますすみません [11:53] ぉぅ [11:53] > 3. 予備審査にCoCに署名していることを追加する [11:54] まぁこれは不要と思う人はいないと思うのですが、現在のqueueをどうするかという問題があるように思います。 [11:54] 現在のqueueはredefineに伴ってリセットでいいと思うんですよね [11:54] やるつもりがある人なら手を上げる気がする [11:55] リセットで良いかと思います。 [11:55] Candidatesっていましたっけ。 [11:55] いません。 [11:55] リセットし、現在はkarmaしか見ていないのをCoCへの署名を確認するいう感じでしょうか [11:56] CoCへの署名も [11:56] そもそもプロセス変えるわけですから、queueはリセットで良い気がします [11:57] そうですね。既存のメンバーの方々には確認して対応のお願いをかける流れかなと考えます。 [11:57] これは大事なので決を採りますね。意見のある方はどうぞ [11:57] すみません、何に対して決をとるのでしょうか？ [11:57] リセットすること？CoCへの署名確認を必須とすること？ [11:58] 両方です。 [11:58] また、リセットとはLPでいうところのdeclineでしょうか、それとも https://wiki.ubuntulinux.jp/enroll/translator_candidates の何かを編集するのでしょうか？ [11:58] 現在のqueueをリセットし、karmaしか見ていないのをCoCへも署名を確認する [11:58] declineでいいのでは [11:59] declineした場合も、再申請可能でしたっけ（LPの仕様がわかっていません） [11:59] あとできれば確認するときには意見に方向性をもたせてもらえるとやりやすい気がする。そこで公平性重視してバランシングするの良くない [11:59] 私は後者と思っていました…… [11:59] Karma不足のときはdeclineしてるので申請可能 [11:59] ↑再申請可能 [12:00] なるほど、了解です＞再申請可能 [12:00] (declineってなんだっけというのを思い出した [12:01] declineは確かもう終わってるんですよね [12:01] 再申請可能であれば、declineもwikiの編集も大差ないと思いますので、柴田の疑問は解消済みです。 [12:01] https://launchpad.net/~ubuntu-l10n-ja/+members#proposed [12:02] ああ、まだいらっしゃいますね [12:03] あらためて多数決というか+1での確認でOKですかね [12:03] このページのproposedをadminが見れば、approve/declineボタンがでるんだと思います。 [12:03] 柴田としてはそれでOKです＞確認 [12:04] 現在のqueueをリセットし、またメンバー申請もdeclineし、karmaしか見ていないのをCoCへも署名を確認する [12:04] これが要約になるでしょうか [12:04] はい。ありがとうございます。 [12:05] あれそのまとめなんかおかしいかも [12:05] どのようにすればいいでしょう [12:05] 基本的にはtranslatorsの権限獲得要件は「既存のtranslatorsからendorsementを得ること」であって、karmaは必須要件じゃないです。そのまとめだと必須に読める。 [12:06] おお、それは知りませんでした [12:06] 「現在のqueueをリセットし、またメンバー申請もdeclineし、権限の獲得要件にCoCへのLP上でのサインを追加する」だとたぶん正しい [12:07] > review queueに含まれる貢献者は、karmaが規定を満たしており、最初の一票目の賛成を得られれば、「Candidates」になることができる。 [12:07] karma足りなくてもよそで十分な実績があって既存translatorsがレビューできるなら権限確保できるので。 [12:07] でもこう書いてあるんですが…… [12:07] それキューのプロセスのためのルールですね [12:07] 権限付与の条件じゃない気がする……する……少なくとも設計はそうじゃない…… [12:08] 私の誤解ということで理解しました [12:08] > 現在のqueueをリセットし、またメンバー申請もdeclineし、権限の獲得要件にCoCへのLP上でのサインを追加する [12:09] これで決を採りましょう [12:09] +1 [12:09] +1 [12:09] +1 [12:09] +1 [12:09] +1 [12:10] +1 [12:11] では次に行きましょう [12:11] > 4. 想定質問集みたいのを追加する [12:11] これはねこまつさんがいらっしゃらないので、意図をお聞きしないと難しい気がしますねぇ [12:11] 先に5の3へのマージ可能性確認した方がいいかも…… [12:12] （記憶が新しいうちにという意図） [12:12] 5.は3.とどうちがうのでしょう＞ kazken3 [12:12] 異論がなければ今日のところは4はスルーしようと思います [12:12] 同じですね。 [12:12] はい＞4のスルー [12:12] > 5. translator candidates での選考において、Code of conduct への署名を要求する [12:12] 5も完了、ですね。 [12:13] 私もそういう理解です [12:13] いいとおもいます＞5も完了 [12:13] では次へ [12:14] > 6. 相談先や連絡先の記載 [12:14] 基本, [12:14] いきなりubuntu-translatorsに投げないようにしましょうとかそういう話と理解していますが…… [12:14] ubuntu-jp@l.u.cでいいとは思っています。 [12:15] 「投げてから一週間ぐらいは待て」とかですかね…… [12:15] いままで、そのあたりの連絡先に明記がなかったので。 [12:15] それもありますね>1週間 [12:15] そうですね。 [12:15] 一週間は行き過ぎにしても三日ぐらいはないとbusyなときに応答性を保証できない気がします… [12:17] visibilityというかtransparencyというか、なんらかのpublic属性があって妥当な問い合わせ先ならOKですよね [12:17] ということでubuntu-jp@l.u.cに同意 [12:18] 個別に連絡が来ても応答はしませんとか明記した方がいいんですかね。。。 [12:18] 原則として、ですかね [12:18] そうですね。原則ですね。 [12:19] なんか個別に連絡がなされざるをえないことはありそうな気がする。具体的には特定のtranslatorsが死去したケースとか遺族から連絡が来ることありそう。 [12:19] 公開できない内容があるかもしれないですしねぇ [12:19] そうですねえ。 [12:20] 連絡先、返答までの待ち時間の目安、個別の連絡は原則として応答しない [12:20] の3点でしょうか。ほかにもあります？ [12:20] 自分は思いつかないです [12:20] 書き先はTranslationGuideに書く方向でいいですかね。 [12:21] はい、それでいいと思います [12:21] 了解です。私からは特にありません。 [12:21] （というかそれ以外にないというか…… [12:22] 決を採る必要もないように思うので次に行きましょうか [12:22] > 7. その他 [12:23] 私はMLにも書きましたけど、 [12:23] > 2017/2/28(日付は適当)以前のふうせんさんの翻訳の提案を見つけたときは消す [12:23] というのが必要のような気がしましたが、MLに報告する、でもいいかもしれません。が、負担も大きい気がしますしどうすればいいのやら…… [12:24] 全部クリアリングしないといけないんですよね…… [12:24] そうなんですが、現状逐次対応以外の方法が思いつかないです…… [12:25] LPのユーザーページから全部たぐってとにかく消す、みたいな作業をすれば現実的には可能ですかねぇ…… [12:25] 今ひとつよくわかっていないのですが、その「全部」の対象はzesty以外もってことでしょうか？ [12:25] 過去のやつも消さないと自動サジェスチョン経由でまぎれこんじゃうという理解をしています [12:25] ユーザーページから全部の翻訳が辿れるんですか？ [12:26] zestyに限ればkuromaboさんのチェックで「全部が保証されている」という認識でいます。 [12:26] ユーザーページからは直近のデータしかたどれないはずです。 [12:26] ですよねぇ [12:26] あーあれrecent activitiesに限定なんでしたっけ [12:26] 個々のパッケージページからは、過去の提案・却下分はチェックできます。 [12:27] （もちろん採用されている翻訳も） [12:28] 自動サジェストが問題になるのであれば、Launchpad以外の対応も必要になります。 [12:28] .po経由で拾ってきちゃうんでしたっけあれ [12:28] 拾ってきますね…… [12:28] それとも.poよりもさらにアクティブな収拾の仕組みがある？ [12:28] （ただし、ソースパッケージからの自動サジェストの名義はpoファイルの先頭になるので実質あまり気にしなくていいはずです） [12:29] いえ、.poのlast-transolator（だっけ？）フィールドの値です。 [12:29] あ、KDEは.poじゃないんですっけ。 [12:29] .po経由の自動サジェスチョン経由は頭痛いものの現実的にどうしようもない、という理解をしました [12:30] poだったと記憶しています。まぁrosettaでは翻訳できないですけど……。 [12:30] はい、どうしようもないと私も理解しています [12:30] あとは、ソースパッケージ外（LP上にあるUbuntu以外の翻訳プロジェクト）からの提案ぐらいでしょうか。 [12:31] あれってどういう仕組みで拾ってくるんでしたっけ [12:31] いやちがうな仕組みどうでもいいんだ [12:31] 原文が（ほぼ？）一致しているかどうか、かな。 [12:31] 現実的に対処可能？（yes/no）　だけ分かればとりあえずいいのかな [12:31] 「理論的には可能」ぐらいです。 [12:32] 「LPが、原文が一致している場合にライセンスに疑義のある候補を拾ってくる」はなんか別枠の問題のような気もするんですよね [12:32] はい、とりあえずそこまでは考えていませんが、クリーンルーム的な意味でサジェストを見たくない場合もあるかなぁと [12:32] 理論的に可能しかし現実的にムリ、かつ、そもそもLPの構造的問題、なんだけど、情を把握している我々として何が出来るか、ですかね問題意識としては。 [12:33] そうですね [12:33] あと、poファイルや外部プロジェクトの翻訳「提案」を「採用」する場合は「license compatibility確認してね」ってポップアップはでます。 [12:33] ほー [12:34] えっと、優先順位的に「1. zesty」「2. xenialなどのサポート対象」「3. サポート外になったubuntu」「4. ubuntu外のLPプロジェクト」「5. poファイル」みたいな感じで、 [12:35] 1-2ぐらいなら現実的に対処可能です。3は大変そう、4はかなり厳しいという印象になります。 [12:35] それは暗黙で「自分達で全部やる」が入ってますね？ [12:35] はい＞自分たち [12:36] 3までは自分達でやるが前提でいいとして、4はたぶんproject ownerに通知ぐらいでOKかなぁと思っています。でも今日はそこまで議論せずに済ませたい感 [12:37] で、今ここでの問題は5. 経由で 1/2 とか将来のubuntuが影響を受けるよねという点に限定してもいいです？　限定するとなにかまずそう？ [12:37] いえ、あくまで「自動サジェストに出てくる可能性がある」ことを問題視するなら、という話となります。 [12:38] そこの「いえ」は「限定するとまずそう」にかかってるでOKです？ [12:38] 「いえ」というのは「限定するとまずいとは思いません」という話です。 [12:38] はい＞かかってる [12:40] さしあたって、CfTを受けて実際に翻訳を始めたら見つけちゃった、その場合はどうしたらいいですかねという話に限定しようと思いましたが、結局そういう話になってしまいますね……。 [12:40] 見つけたらrevert、で実務的には問題ないということにしておきたい…… [12:41] 個人的には「zestyのクリーンナップで翻訳ファイルの禊は終わり」「それ以外で見かけても見なかったことにしてね」「revert権限があればrevertしておいて」ぐらいでいいんじゃないかと思います。 [12:41] 見なかったことに、というか、ベストエフォートでここにURL貼ってねページはあってもいいのかなと思いました [12:42] あくまでベストエフォートで。 [12:42] revert権限がない人が見つけたときに「だまっておいてね」はなんか公正さに欠ける気がする [12:42] revert権限がなければ、連絡してくれるとうれしいって話ですね。 [12:43] はい、「見なかったことにしてね」よりは妥当な表現・やり方だと思います。 [12:43] 連絡先はMLのほうがよくないです……？ wikiにページを作成します？ [12:43] 連絡する、だとデッドロックが生まれるので、「要revertページ」とかそんなの [12:43] MLに投げるのはわりとストレスだと思いますよ [12:43] どこまで対応してあるのかわかんなくなっちゃいますし。無限の処理力を仮定しないときびしい…… [12:44] Wikiは、wiki.ubuntu.com？ wiki.ubuntulinux.jp？ w.u.cのページの利点はLPのアカウントさえあれば書き込めるという点です。 [12:44] （それぐらいしか利点ないけど） [12:44] ある程度汎用化して、「あきらかに間違ってると確信できる or ライセンスイシュー」なので要revertみたいなwiki.ubuntulinux.jpにでも書いていってもらえれば…… [12:45] translatorsになるプロセスを考えると、基本的にはwiki.ubuntulinux.jpのwikiアカウントも持っているだろうと仮定していいように思います [12:45] なるほど。 [12:46] 翻訳あるいは提案を見つけた場合は、wiki.ubuntulinux.jpの当該ページに書き込んでください、という感じですかね [12:47] URLについて、一点気をつけなくてはいけないのは、翻訳ページと原文の両方を記載しないとidentifyできないということですね。 [12:47] ぬぬ。翻訳ページの絶対URLじゃダメなんでしたっけ [12:47] 訳語の順番（個々の訳語の順番）はパッケージのアップデートによって変わりうるので。 [12:48] あー。 [12:49] つらい…… [12:49] ikuyaNOTE: 「当該ページとその書き込み方法は別途調整する予定です」も追加で。 [12:50] （ちなみにzestyのonboardも、前回のミーティングと今回のミーティングの間で、New Upstream Releaseがありましたので、いろいろ書きなおしています） [12:50] 翻訳あるいは提案を見つけた場合は、wiki.ubuntulinux.jpの当該ページに書き込んでください。その方法は別途調整します、ですね [12:50] はい。 [12:51] これをTranslationGuideに追加する、ということでいいでしょうか [12:51] (wait中 [12:51] 特別 [12:52] 特別な例ではなく汎用化するという話だったと思いますので、ガイドライン追加案の1の編集結果に追記でいいのではないでしょうか。 [12:52] あのー、議事録係的には、個人を特定可能な名称を出すのはCoCというか良識に反する気がしますが、 [12:52] それでも記載しないとダメでしょうか? [12:53] いちおう今は以下のように記載してます。 [12:53] * 問題のあるメッセージを投稿した翻訳者の、過去の成果への対応について [12:53] えーとサジェスチョンのところです [12:53] ？ [12:53] ほわっつ [12:53] 問題のあるメッセージis何ってなってます [12:54] s/メッセージ/翻訳/ では? [12:54] 「ライセンス上互換しない翻訳提案を投稿した」、が「問題のあるメッセージを投稿した」になってる？ [12:54] そうです。 [12:54] 最初の議題が「> 2017/2/28(日付は適当)以前のふうせんさんの翻訳の提案を見つけたときは消す」でしたからね…… [12:54] それ明確なミスリードなのでまず直して頂いて [12:55] あんまり個人名残したくないですねぇ…… [12:56] 「ふうせんさんの翻訳」が契機にはなっているものの、ここの議事は「ライセンス違反の翻訳」が発覚した時の対応を議論しているつもりです。 [12:57] とりあえず議事録にはアカウント名入れない [12:57] ガイドラインとか作業上不可避なやつは入れるしか、と認識してますがみなさんいかがです？ [12:58] 仰るとおりです [12:59] はい。 [12:59] 「入れる」の目的語として「議事録に」が省略されているという理解でOK? [12:59] いや [12:59] ? [12:59] 議事録上はぜったいにいれない [12:59] ガイドライン等、実務上アカウント名なしで識別不可能なドキュメントには含める [12:59] 何を? [13:00] 問題のアカウント名を [13:00] あれ、今日の議事録の話です？ [13:00] > 21:52:34 mocchi > あのー、議事録係的には、個人を特定可能な名称を出すのはCoCというか良識に反する気がしますが、 [13:00] に関する話だと思ってるのですが…… [13:01] > ガイドライン等、実務上アカウント名なしで識別不可能なドキュメントには含め [13:01] こっちはどう理解すれば正しいですか? [13:01] すいません、すごい一般的な話をしているものだと。 [13:01] どうis何 [13:02] 端的に言うと、何を言っているのか私にはわからない。 [13:02] 私に対してどういう行動を期待されているのか、わからない。 [13:02] えーと、「アカウント名を含めるのはCoC違反ではないか、たとえば議事録に含めて良い？」という疑問だと認識していて [13:02] はい [13:02] 議事録には含めない、 [13:03] OK. [13:03] ガイドライン等、実務上アカウント名なしで識別不可能なドキュメントには含めざるをえない [13:03] という論理構造です [13:04] 今回の場合、議事録以外のドキュメントにおいては、実務上支障があるので、やむを得ないということですか? [13:04] （ミーティング開始から2時間経過しました） [13:04] yes > やむを得ない [13:04] OK. ようやくわかりました。どうもありがとうございます。 [13:04] 休憩を挟むのではなく次回回しにしたい気がします……（息切れしてる） [13:05] CfTを出すかどうかはこの場では決定しないということにします？ [13:05] リリースに支配的な影響を与えるところまでは合意形成完了してると思ってます（してないなら休憩入れてそこを解決、してるならあとは次回にして今日終了を提案したい） [13:05] あーすっかり出すつもりになってました…… [13:06] CfTはzestyのrevertが終わって、Guidelineを今回の内容にあわせてアップデートしてからにしたいです。 [13:06] それ重いなーと思っています [13:06] CfTに「今回の議事録をちゃんと読んでね」をいれてもらうでもかまいません。 [13:07] ガイドラインはアップデート中です議事録読んでね、で留めてもいいんじゃないかと [13:07] 重いねーってのはrevert完了もですか？ [13:07] 不明点があればこのへんに聞いてくれって [13:07] revertはやんないとダメかと [13:07] guideline更新が重いと思っています [13:07] revertも軽くはないんですが延期不能なので…… [13:08] 「revertが終わって」「ガイドラインの更新があることを通知する」なら、柴田としては異論はありません。 [13:08] （それ決めたらミーティング終わり、も異論ありません） [13:09] 見直し中のガイドラインを守って翻訳してね、というのはしんどくないでしょうか……。 [13:09] これまで作業してた人にとっては特に制約増えないと思うので…… [13:10] 文言が多少異なるだけで書くことは決まっている（議事録に書いてある）という状態ですしね。 [13:10] 増える制約って「作業中にこのアカウントからの翻訳提案見つけたらrevertするかrever待ちリストに書いてね」だと思うんで [13:10] そこだけ明確になってればあとは行動変わらないよって書いてればイケないですかね [13:10] ここまでの議事録: https://wiki.ubuntulinux.jp/IRCMeeting/20170312 [13:12] まぁCfTを出してもこれでは始められないよ、という人も出てくる人もいるかもしれないわけで、とりあえず出すだけ出す、でもいい気がしてきました。 [13:12] 「revertが終わって」「ガイドラインの更新があることを通知する」ののち、CfTを出す、ということでいいでしょうか [13:13] 通知するのはCfTの中でいいと思います。 [13:13] ああすみません、そうですね [13:13] これも特に決を採る必要はないように思います [13:14] 次はいつにしましょうか [13:14] （でいいんですかね [13:15] （でいいんです [13:15] 来週の同じ時間にします？もっと早いほうがいいです？ [13:15] はやめにきめないといけないことって残ってました？ [13:15] call for translation はいつ、誰が出すんですか? [13:15] 特にないように思います [13:16]