☕ PRで盛り上がった時のコーヒーブランチ ☕

[KENCHjp]

各々がどうとかいうのではないことを前置きしまして、

レビューは、ディベートではなくてディスカッションかと思っております。

PRに対する指摘はある意味「突っ込み」的側面（精神的プレシャー含む）はあるかと思うのですが、コードの意図や根拠、指摘にも意図や根拠があるかと。

なぜそうしたのかその寄りところはなんなのかの提示と、指摘を受容することに対する懸念や問題点等を示すことによって、その指摘の妥当性やPRの妥当性の判断とまた別な解決策等よりよい結論に導けるのではないかなと。

他のソースやPR結果はある意味答えかもしれませんが、そこに至る経緯や意図の積み重ねの結果の産物であるかもしれず、必ずしも「他がそうだから」が、各々のPRの答えに繋がらないこともあるかもしれません。

言い方一つって場合もありますが、今集っているメンバーはものの言い方で意図や根拠を取り違えるよ
うなメンバーではないと思っていますので、今後とも、より活発で建設的な意見交換をよろしくお願いしたいところです。

[KENCHjp]

と書いたあとで相変わらず簡潔にまとめられない自分に嫌悪。。。

[KENCHjp]

https://gist.github.com/koudaiii/77ab8eb30512978d1122

こんなのも引用。釈迦に説法かもしれませんが。
以前誰かが引用してたような気も。。。

[ds14050]

名指しはされませんでしたが自首します。これが悪い指摘の例です>sakura-editor/sakura#653 (comment)

いきなり断定で否定するあたり、かなり険があると同時に慎重さを欠いています。ある Issue (※1)で反対意見を述べられたまま放置されているので(一時的に)意見を隠さなくなっていますが(※2)、感情に支配されている側面が大いにあるでしょう。※2 隠していないのは意見ではなく尊大な地金！(隠せ隠せ)

PR への指摘ではなく指摘への指摘であり、PR 投稿者を置き去りにしているあたりがまたよろしくない。

---

※1 週明けには沈黙を消極的賛成と見なす予定です。>sakura-editor/sakura#637 >@m-tmatma さん

[m-tmatma]

@ds14050 さんのコメントは非常に攻撃的で
コメントに反応するのに精神的に非常に疲れます。
なので、どうしても他の人の対応を優先したくなります。

あと、 sakura-editor/sakura#637
に関して言えば、まとまった時間がないので
何もしてないです。

[KENCHjp]

また、個々の話ではないと前置きしておいていいますが、
OSSは各自のリアル時間ののりしろで運営されているかと存じます。
以前 @kobake さんも言われておりましたが、何かを強要する振る舞いは避けたいです。
年に１回の参加であってもそれを消極的とは私は呼びたくないかと。

で、ここは @ds14050 さん向けで、指摘に対しての反駁に反応が無いのを、肯定なのか否定なのか待つ時間がじれったいのはわかります。
自分の思考がそこで停滞している場合にはなおさらかと思いますが、OSS上の時間の流れは人それぞれの余力の上で生まれることをくみ取る余裕も持ちたいかなと。

私個人的には一つのそれなりの規模の課題に対して、余力がちょっとづつ出来てもまとまった時間がないとなかなか手が付けられないというタイプなもので。。。

[KENCHjp]

改めて、 @ds14050 さんへ

名指しはされませんでしたが自首します。

確かにこのIssueを立てたきっかけの一つであることは否定するつもりはありませんが、以前から、PRって、あえて悪い単語を上げると「揚げ足取り」とか「つるし上げ」的な雰囲気になりがちなのかなと、悶々とおもっていました。

特に、私は仕事でコードレビューなどもやりますが、自身で考えたロジックに対しての指摘って攻撃されたように感じやすい行いではあるかなと。
ましてやGitHubは文字だけで全くの他人とのやり取りですし。

私自身は本体側のPRには口を出すスキルもないのではたから見てるだけですけども、「この部分はこういう理由に基づいてこう思うのですが、こう改善する事に何か支障はありますか？」というやり取りの応酬をしてるとは思うのですが、言い方ひとつで伝わったり伝わらなかったりする場面もあるのかなと。

人間なのでしょうがないですが、PRになるべく感情が入らないようにはしたいです。
それでせっかく改善できる要件が改善されないのはそれこそ悲しいので。

[ds14050]

@ds14050 さんのコメントは非常に攻撃的で
コメントに反応するのに精神的に非常に疲れます。

気をつけます。(明確な答えがない)「意見」に対しては寛容であろうとしていますが、「誤り(※事実の一種)」であると見なすと態度と表現が変わってしまいます。そして裏返しですが、自分の「意見」にはかなり固執します。

「これは、バージョンダイアログにタグ名を表示するものです。」とコメントするだけでも誤解されかねないのですから、表現は難しい。

あと、 sakura-editor/sakura#637 に関して言えば、まとまった時間がないので
何もしてないです。

Issue なので必要なのは日本語のやり取りだけです。優先順位があるということは理解しました。

[KENCHjp]

@m-tmatma さんへ

コメントに反応するのに精神的に非常に疲れます。

ぶっちゃけ、内心思われていることを書いていただいて、ありがとうございます。
こういう心情って私書くの苦手なんですよね。引き合いにしてしまったようでもうしわけありません。

で、攻撃的かどうかは主観もあるかと思うので、どちらがどうと言うつもりはありませんし、 @ds14050 さんもその前の「険がある」と受け取られる指摘も（それが本当に「険があった」かどうかは別にして）もあるとのことで、仲良くしてとは言うつもりもないですが、（特に高スキルの人からの指摘って本人にその意思が無くても、思っている以上に相手に重く伝わっていることもあり）言葉のやり取りは慎重にしていきたと思っております。

その上で活発に意見交換なされることを切に希望です。

[ds14050]

@KENCHjp さん。こういう場を用意していただいてありがとうございます。独占してしまいましたがそろそろ別の「きっかけ」に譲ろうと思います。

[ds14050]

あっさり前言を翻してしまいますが、「攻撃的」と言われることに関して。問題を突き詰めなければ解決へは至れません。

sakura-editor/sakura#637 (comment) と sakura-editor/sakura#637 (comment) で書きました。

ですからオプションにしてデフォルトでオフなんです。

• ビルドが遅いのは潜在的な未来の問題ではなく今存在している問題です。
• 前提条件の違いは公式のリポジトリとクローンしたリポジトリの間の違いであって、片方のリポジトリに着目した場合に違いは存在しません。
  公式のビルド結果以外を気にかける理由はありません。

これは @m-tmatma さんが書いた

CI はクリーン環境でビルドしたいと思います。

余計なリスクを持ち込む可能性があるためです。

ビルドする条件によって、実際のビルドの前提条件が異なるので、
ある条件では問題が発生するが、別の条件では問題が発生しないという
ことが発生する

に対する、指摘は当たらないという直接の回答です。

@m-tmatma さんからの反応が得られていませんが、これらは攻撃ではなく事実と意見の提示です。事実認識に誤りがあれば指摘が欲しいですし、「公式のビルド結果以外を気にかける理由はありません」という意見に対してそうは思わないのであれば、根拠とともにそれが表明されるべきであると考えています。なされるべきがなされなければ異論無しと判断するというのが「週明けには沈黙を消極的賛成と見なす予定です」へつながっています。

このあたりディベートとディスカッションの区別がついていないと言われてしまうのでしょうか>#51 (comment)

実は正直よくわかりません。価値基準や優先順位次第で正解の出ない議論には近寄らないようにしていますから、自分のフィールドは専ら事実と論理での殴り合いです。事実誤認と論理の破綻に対する指摘は常に受け付けています。「公式のビルド結果以外を気にかける理由」があるのならば、自分の認識に誤りがあるのならば、知りたいと考えています。

[ds14050]

自分を守るためにあえて好戦的な表現をしますが、反論がないままであれば先に挙げた @m-tmatma さんの書き込み

CI はクリーン環境でビルドしたいと思います。

余計なリスクを持ち込む可能性があるためです。

ビルドする条件によって、実際のビルドの前提条件が異なるので、
ある条件では問題が発生するが、別の条件では問題が発生しないという
ことが発生する

が、自分が出した Issue に対する筋違いの攻撃以外のなんだというのでしょうか。

[m-tmatma]

↑ こういうコメントに対していちいち反論を書いて、時間をかけるのが
正直面倒くさいので、積極的に時間を取りたくない面があります。

[ds14050]

自覚するまでには至っていませんが

• 「あえて好戦的な表現」をすると断った上で書いたが、実は普段から攻撃と受け止めているのではないか。
• 「攻撃ではなく事実と意見の提示」と断った上で書いたが、世間一般ではそれを攻撃(反撃)と受け止めるのではないか。

ちょっと自分の言動を見返してよりよい振る舞い方のお手本を探すのがいいような気がします。

---

↑ こういうコメントに対していちいち反論を書いて、時間をかけるのが
正直面倒くさいので、積極的に時間を取りたくない面があります。

求めているのは Issue を前に進めるについて結論を出すための議論・反論です。「こういうコメント」もそのために存在しています>「反論がないままであれば」

[m-tmatma]

求めているのは Issue を前に進めるための議論・反論です。「こういうコメント」もそのために存在しています>「反論がないままであれば」

終わった話を蒸し返して、絡んでくることに対して、反応しないといけないので
めんどくさいんです。こういうことで時間を取られるので、本来、 @ds14050 が
進めたいであろう issue に対しても検討する時間を割く気力を失わせます。

私が意見を書いたときに、@ds14050 さんが反論したときに反対意見もあると
いうことを認識してほしいと書きながら、@ds14050 さんの issue に対して
反対意見を書いたら、攻撃と書くのでは理屈が通りません。

自分が関心のあるチケットに対して反応がないが、早く進めたいのであれば
該当のチケットに対して、コメントをくれるように求めればいい話です。

該当のチケットが作成されたのは 4日前です。何週間も反応がないわけではないです。

それにチケットはこれだけではありませんし、優先順位が高いとみんなが認識している
わけでもありませんし、四六時中サクラエディタの活動をしているわけではありません。

[ds14050]

終わった話

最初に思いつくのは else 節のことです。断り書きがあってもダメで、コーディングスタイルに関する場所に文脈から独立させてポエムとして書くべきだったんですね。次からそうします。

@ds14050 さんの issue に対して反対意見を書いたら、攻撃と書くのでは理屈が通りません。

「筋違いの攻撃」と書きました。なぜ筋が違っているのかは berryzplus さんとのやりとりを参照してください。

そして「攻撃」という言葉を使ったのは、自分のコメントが「攻撃的」だと評されたためです。一方的に攻撃者にされたのでは面白くないもんです。

該当のチケットが作成されたのは 4日前です。

@m-tmatma さんが書き込みをしているのは Issue #637 であり、作成されたのは 8 日前です。事実誤認を指摘せずに済ませることはできない性分です(そういえば berryzplus さんとのやりとりでもこう書きました)。

しかし最初にコメントが付いたのはやはり４日前なので、自分の感覚より半週間は時間が経っていないなというのもたしかです。

しばらくサクラエディタのことは忘れて PS4 でもします。

[KageShiron]

私もなかなかコメントするときに精神力を消費するので、忙しいと放置しがちになってすいません💦

個人的には、以下みたいなことを心がけてるつもりです。

• 文字数を減らす(すぐ長文を書いてしまうので、故意に減らしてます)
• 断定を避ける。絶対的な正解は存在しないので、「〜と思う」とか「〜かも」、「〜と感じる」のように書く。
• 絵文字や顔文字を入れる

[kobake]

離脱から何か月ぶりか忘れましたが、おひさしぶりです。
将来ちょっとケンカっぽいアレコレが発生してしまう予兆は、実は人集めをしている時点で既に気づいていました。

• 集まっている人材の傾向として、「人間関係や仕草」よりも「技術」側のほうに重きを置く側の平均値が高い。
• 話題領域によるが、こだわりの強い人同士がぶつかりどちらも降りないケースがある。
• 動作として問題ないPRであってもこだわりについての指摘が終着しないがばかりに、本来目をつぶれば進んでいたのに…というものがときどきある。（0 判定とか、別にあれスルーしても良かったんですよね、すみません）
• それぞれのメンバーのビジョンやスタイルが正確に共有されていなかった。
• トラブルが生じたときにそれを仲裁する役目を持つ人（常に誰か気づいた人が随時仲裁できるのであれば理想だが、それがなかなか難しいので、常に仲裁に気を配る人がいてくれるとありがたい）がいるのが理想ではあるが、なかなかその機構が動かない。（自分がそれをやっていくつもりでしたが、疲れて離脱しました。すみません。 @KENCHjp さんが最も中立に話ができる立場と人間性を持っていると思っていますが、技術レベルの差が少しある理由で口出しを控えている雰囲気をよく感じます。しょうもない状況の単品単品の対応でしたら僕も話に加わりますで遠慮なく僕を召喚してください。僕の動きは最近疲れていてノロノロですが）

OSSのチームスタイル

自分はチーム開発をうまく回せるかについて占める大きなファクターは「妥協」と「尊重」だと思っています。僕らのプロジェクトって別に仕事ではないんですよ。責任等は持っても良いが放棄しても良い。ちょっとくらいプログラムに問題があっても、それが致命的でなければ放置でも良い。誰かがいつかその箇所を重要と判断する人が現れたとき、その人に自発的に直してもらえば良い。

とはいえプロダクトのクオリティは保ちたい。例えばややコアな部分のPRについてなかなか話が進まないとする。それが技術だけの話であり、その難易度が高いからこそ意見が割れてそれで時間を食っているに過ぎないのは我慢してがんばる。ただ、そこに感情が入り始めると危うい。

泥沼のPRから脱する手段として、同様の（しかし規模は小さめの）PRを別途作ってしまい、それを見てもらう。PR同士を比べると白黒が付きやすい。そういう解決の仕方もあるよ、と手段だけ提示はしておきます。実際に行使するかどうかは人次第です。

あと、仕事ではないとはいえ、人間の集団です。
場所が物理的に同じ空間であろうが、場所がインターネットであろうが、人間同士の集まりです。
（特に）エンジニアの方々が軽く扱いがちな「社交辞令」等も場合によってはどんどん活用すべきです。社交辞令や挨拶、これ技術の話ではありませんが人間の心理を大きく変えます。人間がコードを書く以上、結果としてそれらのコミュニケーション改善により人間は気持ちよくコードを書けるようになり、品質は向上します。

妥協

いろんな妥協があります。

• 相手に同意するように見えて、実は内面では反対だけど、外面としてまぁここは妥協しておいたほうが良いよね、という判断で、外面としては同意を示すことがあります。実際自分もやりますし、さくらメンバーの中でそういう振る舞いを良い意味でしている人がいることを自分は察しています。
• 一方、妥協による同意を得られたほうは、その無言の妥協に気づくこともあれば気づかないこともあります。ちょっとでもそこに気づいていたとしたら、ひとつ借りができたな程度の気持ちを持つことにしましょう。
• 小さな問題についてお互いがお互いに明示的に妥協をすることを繰り返していくと、だんだん共通の「妥協ライン」が見えてきます。これだけでもコミュニティは割と安定して回るようになります。「妥協ライン」は暗黙知とはせずに新人さんが来ても困らないように明文化しておくのが好ましいでしょう。

他の OSS

まぁぶっちゃけウチだけじゃなくて他の OSS でもケンカは頻繁に起きてます。
意味のある喧嘩と意味のない喧嘩、両方ありますが。なので今のウチの状態が悪い状態かというとすごい悪いわけではないです。よくあることです。

現在のサクラコミュニティを一発で大向上させるソリューション

人によっては抵抗ある方もいらっしゃるとは思うのですが、ボイスチャットが有効です。

実は（タイミング合わせや好みの事情などで難しいことではあるのすが） チームメンバー全員で1時間か2時間ほどでもボイスチャットをすると、各自のスタイルや目的を細かいニュアンス入りで即座に共有できます。さらにこれまでのわだかまり等々をカジュアルに話せした結果、テキストベースの議論だけではなかなか齟齬の埋まれなかった問題が、口頭でだとそれがすぐに埋まり問題速攻解決、なんてザラです。

一度でも話を聞いたことのある相手の今後のコメントの解釈のしかたも良い意味で大きく変わると思います。コメントは書いた人ではなくその内容をみるべき、という意見もありますが、自分はこれには半分程度しか同意できません。同じコメントであってもそれを誰が書いたかによって意味が大きく異なることがあります。そういう意味でも一度メンバー同士の話の場を設けてメンバーの性質を知ることは意味のあるものになります。

ボイスチャットではなくテキストチャットでも良いんじゃない？と思われる方も多くいると思います。それは既に人間関係がうまく構築できている前提での話になります。まずはボイスチャットで忌憚なく各自それぞれの性質の共有や議論をしてみると、確実に何かが変わります。ちなみにテキストチャットには無いボイスチャットの利点はたくさんあるのですが、その中でも「合意の取りやすさ」「話がフィーバーしてきたら、でかい声でＳＴＯＰかけて話を仕切り直すことが容易な点」を自分は価値があるものと思っています。

「Issues で何週間かけても結論が出なかったものがボイスチャットだと10分で結論出た」なんたことはよくよくある話です。

興味ありますか？それとも絶対にやりたくありませんか？

もしそれをやってみることになるとしたらお声かけください。
（離脱している身でなんですが）支障なければ自分がそのファシリテーターを議事録役を務めます。

[KENCHjp]

@kobake さん、召喚しちゃったみたいですいません。
＆貴重なご意見ありがとうございます。

都度ジャッジして早めに交通整理できればいいんでしょうが、おっしゃる通りC++は、うんちくこぼせるレベルでは（他の言語でうんちく垂れれるかと言うとそれもないけど）ないので、
なるべくコーダーの皆様の邪魔をしないようにってことで、遠巻きに干渉しないようにってのは見透かされている通りです。

ただ、目的は、サクラを良くしたい、リリースしたいっていうのが共通項だと思うので、
それが共有できているかぎり、最後はまとまるもんだと信じております。

ただここが居心地が悪い場所になっても「OSS」ですからね。
なるべくいい場所になれるようにしたいとはおもいますが。

[kobake]

ひとつ告白しておきます。

GitHub移行後のリリースをどうするかについて、一度「メデイアを意識して目玉機能はあるべき」との意見がありましたが、実はあれには内面では大反対でした。

注目される必要なんてないんです。メデイアを意識する必要もない。ここはマーケのKPIがある世界でもありません。ユーザの流入数を気にする世界でもない。僕は粛々とただできることを進めていけば良いと思っていました。しかし注目されたい人がいることも確かでしょう。僕は前者でしたが、せっかくの新人さんからの提案を無下にするのも恐縮だったもので、否定することはやめておきました。

まぁこれについては #52 を静観して流れを見ておくことにします。

そんなわけで、誰もが話す言葉をそのまま鵜呑みにするのも良いですが、場合によっては正反対のオブラートすら駆使されていることもあり得ることは気に留めておいてください。

インターネットは特別な場所ではなくなったのです。普通の対面の人付き合いと同じ温度感でコミュニケーションができるように、できるだけ配慮いただけると嬉しいです。場面にもよりますが、できるだけマイルドにやっていきましょう。

それはそれとしてマサカリを飛ばすこともありますけどね。これもケースバイケースです。

[berryzplus]

仕事でプログラマを始めてからだいぶ経ちます。
１つ確実に言えることは、自分には呪術師の才能がないってことです。
才能なくて良かった、と思ってます。いやホントに。

あまり人間のできたほうではないので、
ここ始まってからブチ切れた回数は十数回じゃきかないです。
呪術師の才能あったら大変なことになってますね、たぶん。

最近読んだ本、確か Clean Code だったと思うんですけど、
クリーンなコードを書くには気遣いが大切、みたいなことが書かれていました。
ボーイスカウトの子たちがするように、自分が来たときよりもきれいにするくらいのつもりでコードと向き合うべきだ、みたいなことが書かれていました。

自分が気遣いができる人間かというと、まぁ、違う気がします。
違うので、できるだけ色んなことを考えるようにしています。
たぶんそれでもダメな部分が残りそうなんで、周りの人に突っ込んでもらうようにしています。
「意外とアフォです。」とたまに言うのはツッコミ役をお願いするための方便でもあります。
事実、アフォな部分はあるし、アフォのままでいたい気持ちもあるんですけど。

いつになるか分かりませんが、大きなリリースをする前には kobake さんに仕切りをお願いしたいと思っています。（最短で「平成」が終わる直前くらいを予測しています。

ボイスチャットはそんときに気が向いたらってことで 😄

[kobake]

自分はOSSコミュニティのマネジメント手法にとても興味があり、数え切れないほどの関連本を読んできました。怪しい自己啓発と紙一重である面もあり慎重に情報の取捨選択を行なってきました。悪書があったことも否めませんがほとんどが良書であり、そしてほとんどの場合、その原著者は海外の人間でした。

お世辞にも日本のマネジメント能力は拙いです。
自分は前職でPMをやっていましたが改善点の多さには辟易しました。

僕自身も含めて、このチームのマネジメント能力もまた高くはないと考えて良いでしょう。マネジメント能力というのはマネージャー担当者単体を示すものでなく、チームの総合力と捉えてください。逆にいうと伸びしろはあります。できる限りのベストは尽くしてみましょう。

ボイスチャットはやるとしたら1月あたりですかね。エンジニアの中にはボイスチャットそのものが苦手な方がいらっしゃる事実も把握しています。どのように意思決定を行なっていくか、皆の意見を聞きながら、より良い体制をこれから作っていきましょう。

[berryzplus]

よし、いったんアタマ冷やす！　＞ To自分自身

[m-tmatma]

問題点を指摘するときに、

• 指摘の意図 (対応しなかった場合にどのような問題が発生するから、それを防ぐために変えたいということ)
• 問題点の前提条件
• 問題と考える根拠となる基本的な哲学 (単に好みの問題の場合は、私の好みですが と書く)
• 代替案 (代替案が思いつかない場合は、明示的に 代替案はないですが と書く、あるいは代替案になりうる条件)
• PR してくれたことに対する感謝コメント

とするとスムーズに進むのではないかと思いました。

単にスペルミスの指摘とかだったら、全部省略して指摘だけでもいいと思うので状況次第ですが。