Management of PRs, issues, and threads

[Juan Nunez-Iglesias]

Hi everyone,

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!).

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20160822/e9d3651b/attachment.html>