Management of PRs, issues, and threads

[Emmanuelle Gouillart]

Hi Juan,

thanks for bringing these issues to light. How about we tackle the queue
of open PRs from its two ends? That is, for the new PRs we have this
manager system (we still need to decide how to assign them), and at the
same time we go through old PRs to try to unblock or (worst case) close
them?

Best,
Emma

On Mon, Aug 22, 2016 at 02:47:16PM +1000, Juan Nunez-Iglesias wrote:
> 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.