<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We turned on require code review for the PR, though at the time I *thought* it still allowed you to approve your own PR. Apparently that was wrong. Brett was the one to actually make the decision to do it and turned it on, so I don’t know if he knew that it didn’t allow people to self-approve or not. The impetus to do this was to make sure that all changes went through the PR process and folks didn’t directly push to `master`. </div><div class=""><br class=""></div><div class="">So our choices at this time are:</div><div class=""><br class=""></div><div class="">1) Leave it requiring a review from someone else with write or admin permissions on the repository, which will continue to require a PR.</div><div class="">2) Turn it off, but turn on requiring status checks which will still effectively require a PR (there is one way around this, but it is so convoluted nobody would be able to do it by accident, and things still get tested anyways).</div><div class="">3) Turn them both off, and just tell people not to push to `master` directly and always go through the PR process.</div><div class=""><br class=""></div><div class="">Personally I think that (2) is a good option if our test suite is stable on Travis now. We *want* to make core contributors to generally go through the same process as non-core contributors in order to better expose pain points introduced by our process so we can find them and fix them. Although arguably reviewer bandwidth is a pain point in our process I think that it might be special enough to just switch to the required status check instead.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 5:39 PM, Barry Warsaw <<a href="mailto:barry@python.org" class="">barry@python.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I submitted PR#138 on bpo-22807. I got a nice review from a community member<br class="">and made a small change. All checks have passed.<br class=""><br class="">But now I'm stuck and I'm impatient. ;)<br class=""><br class="">The change is small enough and I'm happy with it, and I could patiently wait<br class="">for another core dev to approve it, but in the likely case that no one else is<br class="">interested in the bug, I'd like to be able to self-approve and accept it.<br class="">This of course is described as my right in the devguide, along with the<br class="">responsibility to watch the buildbots and revert the change if there are any<br class="">problems with it.<br class=""><br class="">But it seems like I cannot do that through the GH UI. Right now I'm seeing<br class=""><br class="">(X) Review required<br class="">(✓) All checks have passed<br class="">(X) Merge is blocked<br class=""><br class="">There seems to be no way to self-approve the PR. If I go to 'Files changed'<br class="">tab and click on 'Review changes', both Approve and Request changes is<br class="">dimmed. I can only comment on my own PR.<br class=""><br class="">I can understand why we might want to prohibit self-approvals, but that's also<br class="">a regression in the permissions and rights of core developers. I also think<br class="">it's counterproductive since without that I might have to go begging for a<br class="">review approval before the branch can land.<br class=""><br class="">Is this intentional or an oversight?<br class=""><br class="">(As an owner of the project, I took a quick look at the project settings and<br class="">couldn't find a control for this, but I know other GH projects I contribute to<br class="">support self-approval.)<br class=""><br class="">Cheers,<br class="">-Barry<br class=""><br class="">_______________________________________________<br class="">core-workflow mailing list<br class=""><a href="mailto:core-workflow@python.org" class="">core-workflow@python.org</a><br class="">https://mail.python.org/mailman/listinfo/core-workflow<br class="">This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct</div></div></blockquote></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class="">—<br class="">Donald Stufft<br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>