I have no specific comments on the what/how, other than to say I'm strongly in favour of some kind of system being implemented and tried out, as I currently rely on manual processes that are inefficient and make it easy to miss PRs which need looking at.
On Thu, 2 Feb 2023 at 18:16, Andrew Lamb <al...@influxdata.com> wrote: > A process that we use in arrow-rs / arrow-datafusion, which is less > precise but seems to be working well enough at the moment, is : > > 1. Mark PRs that have received feedback and need more work prior to merge > from `Ready to Review` back to `Draft` > 2. Ask the author to set it back to "ready to review" when it is ready for > the next round of review > > Andrew > > > On Thu, Feb 2, 2023 at 4:17 AM Antoine Pitrou <anto...@python.org> wrote: > > > > > Hi Raul, > > > > Since I'm the one who proposed that we reuse CPython's existing workflow > > infrastructure, it follows logically that I'm in favour :-) > > > > I'm a CPython core developer myself (though inactive lately), I will add > > that this workflow is really easing the work of reviewing PRs, as it > > makes obvious whether a PR is needing attention from a committer. > > > > Once we start working with it, we may decide to make adjustments to > > better fit our expectations, but I think we can start with the > > unmodified workflow scheme. > > > > Regards > > > > Antoine. > > > > > > Le 01/02/2023 à 15:34, Raúl Cumplido a écrit : > > > Hi, > > > > > > I would like to start working on some automation for our PRs and issues > > > workflows. > > > > > > I've heard, and have experienced, the frustration of spending a lot of > > time > > > on our issue tracker and our PRs to follow up on their status. > > > It is very hard to keep track of which PRs and issues are waiting for > > user > > > feedback, have gone stale or are pending maintainer/committer action. > > > This means users frequently get no timely response, all the while we > > > regularly spend time on GH to look for PRs / issues needing action from > > us. > > > As a first step we should probably tackle PRs, once PRs are tackled and > > we > > > are satisfied with the solution, we can try to devise a similar one for > > GH > > > issues. > > > > > > An example of a great improvement is the CODEOWNERS addition [1]. This > > > allows us to use filters like `is:pr is:open user-review-requested:@me > ` > > [2] > > > which will show PRs that have requested a review from us. This does not > > > solve the problem of what are the PRs waiting for second review, > > > waiting for changes, etcetera. > > > > > > I don't think we have to reinvent the wheel, CPython has something that > > > works well and can easily be adapted/tweaked. > > > They use a GitHub bot (bedevere) with the following state machine: > > > https://github.com/python/bedevere#pr-state-machine > > > > > > PRs have one label of the following workflow labels, depending of the > > state: > > > - `Awaiting review` > > > - `Awaiting core review` > > > - `Awaiting changes` > > > - `Awaiting change review` > > > - `Awaiting merge` > > > > > > I would like to propose adding a GitHub bot to our repo that triggers > on > > PR > > > changes / comments implementing a similar workflow than the one on the > > > CPython repository. > > > > > > I am going to start working on it and I would love to hear feedback > about > > > that workflow. I have also created an issue on the Repo [3]. > > > > > > Kind regards, > > > Raúl > > > > > > [1] https://github.com/apache/arrow/pull/33622 > > > [2] > > > > > > https://github.com/apache/arrow/pulls?q=is%3Apr+is%3Aopen+user-review-requested%3A%40me+ > > > [3] https://github.com/apache/arrow/issues/33977 > > > > > >
