So the reasoning behind setting "awaiting merge" is because the "needs" label is meant to represent what is holding up the PR from being closed, and so a PR from a core dev is really just blocked on merging since they don't have to receive a review. Now, if people would rather move it over to "needs review" by default like any other PR then that's fine as well, but I don't know if that's going to help with INADA-san's worry about so many issues making a label less useful. On Wed, 5 Sep 2018 at 05:45 Berker Peksağ wrote:

On Wed, Sep 5, 2018 at 3:28 PM INADA Naoki wrote:

...

Other option is set "awaiting review" label instead of "awaiting merge", like PRs from other contributors.

+1. Personally, most of the time I request a review from another core developer, so setting the "awaiting review" label seems reasonable to me.

--Berker _______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

On Wed, 5 Sep 2018 at 13:37 Zachary Ware wrote:

On Wed, Sep 5, 2018 at 3:31 PM Brett Cannon wrote:

...

So the reasoning behind setting "awaiting merge" is because the "needs"

label is meant to represent what is holding up the PR from being closed, and so a PR from a core dev is really just blocked on merging since they don't have to receive a review.

...

Now, if people would rather move it over to "needs review" by default

like any other PR then that's fine as well, but I don't know if that's going to help with INADA-san's worry about so many issues making a label less useful.

What about no label at all on core dev PRs by default, but if one gets added the standard flow is followed?

I would be fine with that. What do others think? -Brett

-- Zach _______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

I prefer keeping the labeling as is, so core devs PR get "awaiting merge" label upon creation. If a core dev actually want someone else to review it, I suggest using the "request review" feature, and select another core dev to review the PR. At that time, bedevere should apply the "awaiting core review" label. At least, that would be my expectation. If it doesn't do that, then that's the change we should implement, instead of the "no label by default". Mariatta ᐧ On Thu, Sep 6, 2018 at 12:47 PM Berker Peksağ wrote:

On Thu, Sep 6, 2018 at 10:37 PM Brett Cannon wrote:

...

On Wed, 5 Sep 2018 at 13:37 Zachary Ware wrote:

...

What about no label at all on core dev PRs by default, but if one gets added the standard flow is followed?

I would be fine with that. What do others think?

+1

If no one beats me to it by the end of this month, I can submit a PR that implements Zachary's suggestion..

--Berker _______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

On Tue, 11 Sep 2018 at 05:13, Brett Cannon wrote:

On Mon, 10 Sep 2018 at 11:50 Mariatta Wijaya wrote:

...

I prefer keeping the labeling as is, so core devs PR get "awaiting merge" label upon creation.

If a core dev actually want someone else to review it, I suggest using the "request review" feature, and select another core dev to review the PR.

Do the people wanting other core devs to review typically have someone they want to review, or just anyone to do a review?

If I'm specifically waiting for feedback on a PR, I'll generally put an explicit "WIP: " (for work-in-progress) in the title to warn other folks not to merge it yet (it's a habit picked up when using GitLab, as that will actually prevent merging if you do that). So if folks don't want to make "No label" the default, then the convention could instead be to add "WIP: " to tell Bedevere to skip adding the "Awaiting merge" label. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

FYI I opened a poll at https://discuss.python.org/t/poll-what-label-should-prs-from-core-devs-autom... to settle this question of what label core dev PRs whould automatically receive. On Tue, Sep 11, 2018 at 2:49 PM Brett Cannon wrote:

On Tue, 11 Sep 2018 at 07:33 Nick Coghlan wrote:

...

On Tue, 11 Sep 2018 at 05:13, Brett Cannon wrote:

...

On Mon, 10 Sep 2018 at 11:50 Mariatta Wijaya wrote:

...

I prefer keeping the labeling as is, so core devs PR get "awaiting merge" label upon creation.

If a core dev actually want someone else to review it, I suggest using the "request review" feature, and select another core dev to review the PR.

Do the people wanting other core devs to review typically have someone they want to review, or just anyone to do a review?

If I'm specifically waiting for feedback on a PR, I'll generally put an explicit "WIP: " (for work-in-progress) in the title to warn other folks not to merge it yet (it's a habit picked up when using GitLab, as that will actually prevent merging if you do that).

We could set up a separate bot at this point, but with the new automerge bot this won't be such an issue as people will simply not add the "automerge" label until they are ready.

...

So if folks don't want to make "No label" the default, then the convention could instead be to add "WIP: " to tell Bedevere to skip adding the "Awaiting merge" label.

I think we may want to hold off on any changes until we see what happens to our standard practices with the automerge bot.

-Brett

...

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia