Are non-committers able to add/remove tags to PRs? Sounds like a good way to increase visibility/searchability of PRs needing review, but it would only work if everyone is authorized to modify tags.
Neal On Sun, Mar 7, 2021 at 12:24 PM Wes McKinney <wesmck...@gmail.com> wrote: > This sounds like a nice idea as long as the bot doesn't generate too > much potentially spurious info (i.e. the "needs improvement" label > when it perhaps need not). > > Note that the Spark community set up a pretty handy PR dashboard > > https://spark-prs.appspot.com > > It's open source: https://github.com/databricks/spark-pr-dashboard > > Frankly I think we are getting to (and probably well past) the point > that scrolling through > 100 PRs in GitHub is not a good use of > reviewer time, so creating some kind of "semantic layer" on top of the > PR review queue (like what the Spark folks did) would help a great > deal. So rather than trying to work entirely within the GitHub > platform (which is not designed for the needs of large projects with > this many PRs), something more structured and useful could be created. > If you look at the Spark dashboard, that is 10x more helpful than > browsing GitHub is right now, whether there are issue labels or not. > > On Sat, Mar 6, 2021 at 10:41 PM Weston Pace <weston.p...@gmail.com> wrote: > > > > Since we're on the topic of improving the workflow I had a proposal to > > consider. Right now the review process is pretty ad-hoc which is fine > > but can be a bit tricky to keep track of. > > > > I think it could be improved with a bot to label PRs. The labels would > be... > > > > state: failing tests - Any PR starts in this state until either all > > tests pass or the submitter could say something like "please review" > > to bypass (e.g. in case an intermittent or unrelated test failed since > > non-committers are not able to rerun jobs). Add something to > > developer docs FAQ about this bypass. > > > > state: needs review - Once all tests pass a PR would move into this > state. > > > > state: needs improvement - If someone makes a review with the > > "comment" or "request changes" action the PR moves into this state. > > To clear this state the user must click "re-request review". Add > > something to developer docs FAQ about this since it may be > > unintuitive. > > > > That's it. I'd be happy to create the bot if the community thinks it > > is a good idea. None of this would be required or authoritative. > > It's merely a label to help for tracking purposes. Reviewers could > > presumably use the tags to create some kind of dashboard showing which > > PRs need review and which have been waiting for review the longest. > > Even without that, it would serve to make it clear to the submitter > > and the reviewers where the action is. > > > > -Weston Pace >
