Management of PRs, issues, and threads

[Johannes Schönberger]

This should very be interesting in this regard: https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features

> On 12 Sep 2016, at 18:35, Nelle Varoquaux <nelle.varoquaux at gmail.com> wrote:
> 
> Hi scikit-image folks!
> 
> 
>> We've had a couple of community fails on GitHub recently:
>> https://github.com/scikit-image/scikit-image/pull/1474#issuecomment-241283056
>> https://github.com/scikit-image/scikit-image/issues/2080
>> (The last one is missing a presumably-deleted comment where someone outside
>> the project recommended to a potential contributor to just fork the
>> project!).
> 
> Being the person that reported one of those community fails, I'd like
> to say that I've had great experience with the scikit-image community
> overall. Contributors are (usually) very well welcomed, feedback is
> friendly, and we can have discussion and debates about "hot" topics
> (like dropping python2.7) in a friendly and nice environment. I've
> recently contributed to another scientific python project where many
> members of the community were aggressive in their reviews, without
> giving valuable feedback on PRs, so I value scikit-image's (&
> scikit-learn) community even more.
> 
>> That's just the couple I've noticed, I'm sure there are lots more. We
>> definitely have many, many abandoned PRs from >1y, >2y ago.
>> 
>> Obviously, something in our process isn't working. I don't have immediate
>> solutions, but here's a couple of suggestions:
>> 
>> - we need a system to assign core devs to PRs/issues. Currently, it's too
>> easy for all of us to go, "someone else on the team will handle this". We
>> need a fair way to assign a manager to each issue/PR. The assigned dev
>> wouldn't necessarily be responsible for review, but they would be
>> responsible for chasing up other reviewers.
>> 
>> - NEVER close a PR without the explicit consent of the contributor, OR after
>> the contributor has been non-responsive for e.g. 1mo and two pings. In this
>> last situation I would even suggest that we need two core devs to sign off.
> 
> I would not close old PR, for the sake of closing them. If the
> contributor is not interested in finishing the contribution and the
> patch is almost ready, it might be a good way to introduce new
> contributors (/students) to the PR. This can probably be done by an
> "Need contributor" tag + "Easy fix", though I haven't thought more
> about this
> 
>> Other suggestions welcome in this thread. We should try to get a new process
>> hammered out very soon.
>> 
>> I also want to acknowledge @soupault for his triage/labelling work, which is
>> a massive step in the right direction. But we need to follow up his triage
>> with some actual process.
>> 
>> Juan.
>> 
>> --
>> You received this message because you are subscribed to the Google Groups
>> "scikit-image" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to scikit-image+unsubscribe at googlegroups.com.
>> To post to this group, send email to scikit-image at googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/scikit-image/CA%2BJHcKSh-k%2ByM0yBTRzTy%3DZgY7%2BOoEmPkKNA4xUgudeyhCJ5Dw%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 "scikit-image" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe at googlegroups.com.
> To post to this group, send an email to scikit-image at googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CAE-UAvSnKid2zn9bM4%3DdU2mvG96jDg8%2BfTayEOw%3DTA%2BS4u27zg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20160914/55f593c2/attachment.html>