@Weston: Adding a system to figure out when PRs are waiting for review
would really help me personally. I spend non trivial time trying to make
sure we don't miss any Rust PRs that come in and it gets challenging to
filter out the ones that are WIP.
Having a bot add some labels would be great.
@Neil: Prior to being a committer I could not change labels on PRs, so I
don't think it is possible. Perhaps the bot could add the labels on their
behalf based on comments ("bot this is ready for review" or something)
On Sun, Mar 7, 2021 at 10:28 PM Neal Richardson <neal.p.richard...@gmail.com>
wrote:
> 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
> >
>
