Mergify.IO （自動マージ機能）を導入したい

[KEINOS]

CircleCI をパスして、レビューに n 件の LGTM（Approve）が付いたら、もぅ強制的に master にマージさせたい。 （👍 ×3 以上で可決）

また、Approve できるレビューアーはコラボレーター（リポジトリ大臣）に限定せず、コントリビューター（ユーザー）も参加できるようにする。

• GitHub で CI をパスしたら自動的にマージさせたい。 @ Qiita
• Github レビューでの Approve / Request Changes / Comment の使い方 @ Qiita

P.S.
リリース（master を gh-pages にマージ）するタイミングは、コラボレーターの多数決で適宜行うこととする。可能なら、これも自動化につなげていきたい。

[yumetodo]

必要性がわかりません。その方式で #62 でのもぐらたたきゲームを完遂できるのか疑問です。
多数決は意見を集約するのに役立ちますが、品質を担保する機能は持っていません。

何人が検証したか、ではなくどの観点で検証がされたか、を重視するべきではなりませんか?

またそもそも「GitHub で CI をパスしたら自動的にマージさせたい。 」というのは、十分にカバーされたテストが存在していて初めて発生する議論ではありませんか？

[sasanquaneuf]

「レビューでどれぐらいOKだったらマージするか」を今後決める必要はありそうですね。
多数決が正しいかと言うと、必ずしも正しくないような気はします。
ただ早くマージされないと、開発速度が遅くなったりコンフリクトが発生したりという事はあるので、早くマージしやすいようなレビューフローを決めるのですかね。

[KEINOS]

必要性がわかりません。その方式で #62 でのもぐらたたきゲームを完遂できるのか疑問です。

端的でポイントを付いていて良いのですが、もうちょっと優しく言ってちょ。おいどんは意外にナイーブなんです。

必要性は、、、単純に運用と管理が面倒臭いからです。

#62 の PR も、運営的に完璧な状態にしてからマージしようとして、PR 者も修正が多くなってきて、運営も周りもわけわかめになってて、みんなが疲弊したように見えました。

全員が本業があるなか時間を割いて改善 PR して、同様に時間を割いてレビューする。

たいへん素晴らしいのですが、#62 もなかなかマージされないのも見ていて心苦しかったです。

メガトン級の対応にはヘカトン・ケイレスな対応能力が必要です。しかし、私はヘタレトン・ケイノスなので、対応はおそらく無理です。そのため #62 もコラボレーターさんにおまかせして傍観すらしていました。

品質ですが、おっしゃる通り担保されません。テストもないし。本 Issue の方法だと、まぁ商品レベルには到底追いつかないでしょう。クオリティもレビューアーに依存する方式なので。

ただ１点、重要なのが Qithub-ORG に移管したから商品レベルを目指しているわけではありません。

@hidao さんが思いつきで作ったものが 、Qiitadon のみんなでワチャワチャとイジって形になっていったことが、見ていて面白く、参加して楽しかったのです。

つまり、「品質優先よりは、形になっていくこと優先」でいることをご了承ください。

小粒な PR をマメにマージして、トラブったら治して、よさげになったらリリース。

それだけです。ある意味、

テストが必要と思えば作ればいいし、レビューもザルになってきたと感じたら n 件の数値を上げるか、ガチ・レビュー大臣に来てもらうかその時に考えれば良いと思います。自動マージが危険となれば、外せばいいとすら思っています。

楽をしたいのです。

経験上、先手を打って用意しておいた方がいいことも多いと思います。また、せっかく時間を割いたのにクオリティが低いと「こんなことに参加している」と言えないのも辛いかもしれません。

結果、商品レベルになるのであれば、それで良いです。

ただ、それを目指すぎるがあまり、各々の義務や責任が強くなり、「楽しくなくなってきた」のであれば、閉鎖も考えています。MIT ですし、できる人にお任せしたいと思います。

とは言え、常にクオリティは念頭に置く必要は理解しています。

それによって「形になっていく」から「良い形になっていく」わけですから。企業でも品管（品質管理）は警察というか嫌われ者になっていくのを幾度と見かけましたが、「良くしたい」という気持ちからなんだというのもわかりました。

そのため、ご指摘の内容は大事だと思っていますし、いつかそこにたどり着ければと思っています。

ぬるいと感じるかもしれませんが、今の私にはそれくらいが適温なのです。
そんなレベルでよければクオリティ維持のため、今後もご協力お願いいたします。

[yumetodo]

もう少し他の例を出すと、#48 を例えば3人でレビュー集まるのを待つのが妥当かというと多すぎない？ということです。もっとカジュアルにマージするためにも数は意味を持たないともいます。

よその例で申し訳ないですが
https://github.com/cpprefjp/site
の場合

1. 一度でもPull Requestを投げてきた人はMemberに入れる
2. 次からはMemberなので小規模ならmasterに直接、ちょっと大きそうならPRを投げるしそのときに権限があるのでReviewers を指定できる、そしてだれか他の人(アクティブなのは4人くらい)が時間のあるときにマージ

というフローになっています。

あんまり悪意のある開発者とかは考えなくても回るはずなので、masterに直接投げるかは別としてこのくらいふんわりしていても手間なく回ると思います。

つまり数にこだわると開発速度が不必要に落ちたり、一方で品質も落ちたりでだめじゃないですか？という話がしたかったのです。

[KEINOS]

3人でレビュー集まるのを待つのが妥当か

ふむ。確かに。

基本的に運営が楽する目線なので「マージ権限者の登場を待つ」よりは「n 人レビューさえあれば運営を待たずに進む」という意識でした。

しかし、いまのように有志のレビューアーが数人常にいるというわけでもないですもんね。

ちょっと郵便局に行かないと行けないので道中考えます。

[KEINOS]

帰って来たのですが、すみません。考えてませんでした。

いま、ちょっとアイコン作成に夢中になってます。（いや、考えてるんだからね）

[yumetodo]

まあそこまで急ぐ話でもないのでは(自分は #72 やってるので