I think that's great idea, given the large number of open PRs. Implementing this is very easy to do. What's hard is to find the correct workflow.
How do you trigger the red X status? A comment in the PR with a specific message? How do you suggest turning the red X status off when the reviewer's comments are addressed, but no new commits are sent? Isuru Fernando On Thu, Sep 1, 2016 at 10:47 PM, Aaron Meurer <asmeu...@gmail.com> wrote: > One problem with PR reviewing is that it isn't always clear which PRs are > ready to review, and which require more work. > > One solution that has been proposed in the past is these "PR: author's > turn" and "PR: sympy's turn" labels. But the problem is that you can't > change PR labels unless you have push access. So once a PR has a "PR: > author's turn" label, the only way to remove it is if someone with push > access removes it. And aside from that, people aren't diligent enough to > always keep the labels updated. > > But I just noticed that as I go through the PRs list, I generally skip > those PRs that have failing status label (a red X), as that means that some > tests have failed, so there is already some work to do on the author's part > to fix the PR (I also generally skip PRs with WIP, unless I am specifically > interested in them). > > So my idea is to have some kind of "CI service" that lets any PR reviewer > assign a status label to the PR, either a checkmark for "passes review" or > an X for "needs work". The status itself could link to a comment that > points out what needs to be done. That way, any PR that "needs work" will > have a red X, and I can see when going through the list that I can skip it. > > The nice thing about this is that, because the status is only assigned to > the most recent commit, as soon as the PR author pushes a new commit, the > red X status for the "needs work" will go away. > > This could also bring accountability for our "all PRs must be reviewed" > policy. > > Bitbucket actually has this feature built into their PR system, which is > one thing I like about it, but I think it should be possible to do the same > thing with GitHub with a bit of work. > > What do you think? Anyone have any idea how to implement something like > this? Does anyone know if someone already has? > > Aaron Meurer > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at https://groups.google.com/group/sympy. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/sympy/CAKgW%3D6KVtuOF4CNBd2tUKr%2BOQSB0vSWbhkOLnAN19y7iZdW% > 3DPw%40mail.gmail.com > <https://groups.google.com/d/msgid/sympy/CAKgW%3D6KVtuOF4CNBd2tUKr%2BOQSB0vSWbhkOLnAN19y7iZdW%3DPw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CA%2B01voMmV5HYj-5KNFO2HwRGgaKjvq_b0ZN6QmcSkX3iaS7ZqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
