ワークフローに関する質問 #1276
未完了
コミッタの方によるパッチ投稿
説明
#1269#note-1 での議論。
コミッタからパッチ付きの提案チケットが投稿された場合、
誰がどう判断してステータスを進めるべきか。
- コミッター+モデレータのメンバーのうち少なくとも 2人がOKと言ったら進める?
- slack や mastodon とかでとしぁさんと会話して「いいよ」だったら進めるとか?
- 最終的に「パッチ適用待ち」にするときにコミッタの判断が入るなら最初は緩くてもいい?
#1269#note-2 のコメントは以下
cob odo さんは書きました:
提案チケットの進め方によれば、
ステータス「分類待ち」の場合
この場合、モデレータがその提案が妥当なものなのか判断し返信する。
妥当でないならばその理由を説明し、ステータスを「却下」に変更する。
モデレータがそれを取り込むべきと判断すれば、以下の条件に従って次に進める。ということなので、
このあたりのGOの判断を誰がどうするか
は、「独断で（もちろん理由は挙げるとして）GO/NO-GOを判断できる権限がモデレータに与えられている」と解釈するのかなーと思いました。
そうは言っても判断が微妙な提案はあると思いますし、迷ったら適宜相談という形でいいのではないかと個人的には思います。「提案」フローについては、単に「こういう機能がほしい」という提案が（非コミッタ・非プログラマ）から出た場合、モデレータがGOの判断をしてもまだパッチは無いので「パッチ適用待ち」にはできなそうだなとは思いました。
それに対する返信 #1269#note-3
Izumi Tsutsui さんは書きました:
cob odo さんは書きました:
このあたりのGOの判断を誰がどうするか
は、「独断で（もちろん理由は挙げるとして）GO/NO-GOを判断できる権限がモデレータに与えられている」と解釈するのかなーと思いました。
そうは言っても判断が微妙な提案はあると思いますし、迷ったら適宜相談という形でいいのではないかと個人的には思います。仕様としては歓迎するが、実装（コード）はわからん、という場合は迷うんですよね……。（非プログラマのつぶやき）
公開API変更のような互換性で禍根を残すようなものは別として、「やってみてイマイチだったら元に戻せばいい」という程度の変更なら
あまり気にせず「コミッタorモデレータのうちひとりがOKと判断すれば進める」というゆるいルールでよいような気はします。
Izumi Tsutsui さんが6年以上前に更新
承認要否¶
続きで以下の議論もありました。
従来はコミッタの方が限定されていたので「パッチ適用待ち」の場合は
暗黙的にとしぁさんが担当ということになっていた気がしますが、
コミッタの方が入れたチケットの場合はとしぁさんにも何かしらOKもらうべきですかね?
#1268#note-2
cob odo さんは書きました:
コミッタが提案した場合、としぁさんではなくても、最低限、別のコミッタが確認することはフローとして必要なのかな、と思います。
それで滞りすぎるようだと問題かもしれませんが、勝手に進めすぎるのも問題だと考えています（暴走する自信があるため）。私の場合、特にWSL環境でしかテストしていないので、一応"Linuxとか"でも見てほしいなーというのもあります。
Izumi Tsutsui さんが6年以上前に更新
レビュー待ちの担当¶
#1262#note-3 が以下の状態です。
- コミッタの方のパッチに対してとしぁさんがOKを出す
- →そのコミッタの方がブランチにコミットした
上記の場合、「レビュー待ち」では通常パッチを投稿した人がレビューしますが、
パッチ投稿者とブランチにコミットした人が同一の場合どうするか。
Izumi Tsutsui さんが6年以上前に更新
cob odo さんは書きました:
例えば、僕が「提案」した #1268 や #1269 は既に「パッチ適用待ち」なので、 #1278-1 に基づくフローでは……
- コミッターの僕が議論無しでブランチを作ってcommitしてpushし、
- 「レビュー待ち」に遷移して起票者である僕がコミット内容を確認して終了。
あれ、マージ待ちがないですね。コミッタ以外が起票した場合に、起票者がレビューした後にコミッタがマージするのを待つステータスが必要な気がします。
#1278-1 によれば、パッチの適用（コミット）可否の判断は「パッチ適用待ち」の時点のみだと思います。
フローで「レビュー待ち」と「マージ待ち」とが分かれているのは以下の理由とのことだったので、パッチ提供者とコミッタとが同一の場合は「マージ待ち」は不要ということになると思います。
- パッチが git-format-patch で作られていない場合、どのリビジョンに対するパッチかが確認できないことがある
- コミッタがパッチをそのまま適用せずに修正して適用する場合がある
→それぞれ意図通りに適用できているかがパッチ提供者に確認してもらう必要がある
#1268 や #1269 はそのままマージまで進めてもらってOKです。
それはともかくとして、議論が煮詰まっていないのに進みすぎてしまっているチケットは分類待ちに戻すことが必要でしょうか？
既存のチケットについては無理して変える必要はないということでよいです。
ステータスを変えたほうが適切に拾ってもらえる or 議論が進む可能性があるなら
変えたほうが良いかも、というくらいの判断基準で良いと思います。
「提案」チケットで「実装待ち」になっているものがあるのでそれは別途 #1277 のほうに書きます。
toshi_a 初音 さんが6年以上前に更新
Izumi Tsutsui さんは書きました:
cob odo さんは書きました:
例えば、僕が「提案」した #1268 や #1269 は既に「パッチ適用待ち」なので、 #1278-1 に基づくフローでは……
- コミッターの僕が議論無しでブランチを作ってcommitしてpushし、
- 「レビュー待ち」に遷移して起票者である僕がコミット内容を確認して終了。
あれ、マージ待ちがないですね。コミッタ以外が起票した場合に、起票者がレビューした後にコミッタがマージするのを待つステータスが必要な気がします。
#1278-1 によれば、パッチの適用（コミット）可否の判断は「パッチ適用待ち」の時点のみだと思います。
フローで「レビュー待ち」と「マージ待ち」とが分かれているのは以下の理由とのことだったので、
パッチ提供者とコミッタとが同一の場合は「マージ待ち」は不要ということになると思います。
そうなりますね。
実際にそういう手順をやってみて、バイパスできるワークフローを作ったほうが良さそうですね。
（チケット作成者＝コミッタならパッチ適用待ち→終了のフローができる、とか）
それはともかくとして、議論が煮詰まっていないのに進みすぎてしまっているチケットは分類待ちに戻すことが必要でしょうか？
既存のチケットについては無理して変える必要はないということでよいです。
ステータスを変えたほうが適切に拾ってもらえる or 議論が進む可能性があるなら
変えたほうが良いかも、というくらいの判断基準で良いと思います。
既存のチケットを新しいワークフローに直す必要はありません。理由は3つあって:
- 古いワークフローになっているチケットが既に大量にあるので、これを修正したら通知地獄になる
- ワークフローは完成することがないため、大きな変更があるたびに過去のチケットを追随させるのはコストが高い
- 上記2つの理由から、古いワークフローで進めているチケットが進行不能にならないように互換性のある変更しかしていない
「提案」チケットで「実装待ち」になっているものがあるのでそれは別途 #1277 のほうに書きます。
例として、 提案 トラッカーに 実装待ち があったのは設定バグですが、単に消すのではなく 分類待ち→実装待ち(モデレータ) のフローを消しただけなので、既に 実装待ち になっているチケットは パッチ適用待ち に遷移可能だったりします。これは意図したものです。
あとはつついさんのおっしゃってるとおりです。