Incorrect bedevere transition (the sequel)

[AlexWaygood]

It looks like there's still a few situations that confuse Bedevere when trying to figure out which labels to add or remove.

In python/cpython#104559:

1. I opened the PR, Bedevere added "awaiting core review" (correct, I'm a core dev)
2. Jelle approved the PR; Bedevere removed "awaiting core review" and "awaiting merge" (correct)
3. I then converted the PR to draft, as I had cold feet. Bedevere removed "awaiting merge" as a result (not sure if that's correct or not? we could debate what the desirable behaviour might be there)
4. I then moved the PR out of draft again; Bedevere added "awaiting core review" (definitely incorrect; the PR had already been approved by a core dev)

Cc. @itamaro :)

[itamaro]

In my mind, moving a PR to draft and then back to published is equivalent to submitting a new PR (under the unfounded assumption that you move to draft only if you want to significantly rework the PR).
I can see how other interpretations also make sense, and I don't have a strong opinion myself (especially not being a core dev :) ) and happy to look into making changes in the draft workflow - but I'd like to have someone authoritative (that someone can be you ofcourse) providing guidance about what should be the desired workflow first!

[AlexWaygood]

under the unfounded assumption that you move to draft only if you want to significantly rework the PR

For me, that's an incorrect assumption ;)

It's not unusual for me to do testing locally, think I've got a strong PR, file it on GitHub... then get cold feet, so I'll put it back into draft while I do some more testing locally, just in case somebody else merges it while I'm doing more testing. But then my local testing proves my fears were incorrect, so I move it out of draft again without having changed much at all!

[hauntsaninja]

In general, I agree with Itamar. But if the commit hasn't changed since it was approved, and if it's easy to check that, I think would be nice to go straight back to "awaiting merge"

[itamaro]

But if the commit hasn't changed since it was approved, and if it's easy to check that

I'm sure it could be done with a bunch of additional labels. I don't know if this would be considered easy (or desirable) :)

[AlexWaygood]

More labels sounds like a bad idea!

I found the sequence in python/cpython#104559 surprising, but it sounds like I might be in the minority (and it's not a huge issue, anyway), so better to do nothing here than add loads more complexity, I think :)

[Mariatta]

Let's not add more labels. In my mind if a PR already has awaiting merge label, we should not move it back to draft. You could add the "do not merge" label if you still need to work on it more. So I think the behavior that's currently implemented is correct.