One option is to close the PR if it's not ready, since I think the author of the PR can reopen it. That solves the issue that the author of the PR can't touch the labels.
On Fri, Sep 2, 2016 at 1:55 PM, Aaron Meurer <[email protected]> wrote: > It seems several similar tools already exist. https://about.pullapprove.com/ > and https://lgtm.co/ are two that were pointed out to me. They both seem > more focused on making sure a review happens before merging, which I'm less > worried about. My main concern is seeing which PRs are ready for review. > > Aaron Meurer > > On Thu, Sep 1, 2016 at 4:21 PM, Isuru Fernando <[email protected]> wrote: >> >> See https://github.com/isuruf/symengine/pull/19 for a demo. >> >> Code is here, https://github.com/isuruf/sympy-pr-webapp >> >> Isuru Fernando >> >> On Fri, Sep 2, 2016 at 12:58 AM, Aaron Meurer <[email protected]> wrote: >>> >>> Yes, that's the question. >>> >>> You need some kind of webapp that runs somewhere to trigger the status. >>> Perhaps as a UI you could reuse the existing label system, where setting a >>> label triggers the app to set the status. Or maybe the webapp has a page >>> that you can go to for each commit to trigger the status (the default status >>> could be set as green, to give a link). And yes, you need some way to invert >>> the status for a given commit, in case it's decided that no changes are in >>> fact needed. >>> >>> Honestly, it would be better if GitHub implemented the sign-off UI >>> directly. The most elegant (from a reviewer's point of view) solution I can >>> think of is a browser extension that puts a simple "Sign off / Needs more >>> work" button on each PR. But then reviewers have to install the extension... >>> >>> Aaron Meurer >>> >>> On Thu, Sep 1, 2016 at 3:17 PM, Isuru Fernando <[email protected]> wrote: >>>> >>>> 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 <[email protected]> >>>> 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 [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> 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. >>>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> 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. >>> >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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%3D6%2BFwknyQVq%3Dj2rgxvTQo8pEqqFGSwLh12svo5nKhNZgNQ%40mail.gmail.com. >>> >>> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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%2B01voPhn8dOE-%3D%2B6%2BG0LwN2z3A5tZuGsuQ5pGPGgP2Lea93Mw%40mail.gmail.com. >> >> 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 [email protected]. > To post to this group, send email to [email protected]. > 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%3D6LVac3rkYiVVDTdtk7RyESQqa2cA2fsLK7FKsd7oVzrgQ%40mail.gmail.com. > > 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 [email protected]. To post to this group, send email to [email protected]. 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/CADDwiVArxrT1F%3DH4EZ%2B754mF8cxrAOOxMwU5gJ6w971hn0Qi%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
