Management of PRs, issues, and threads
Egor Panfilov
multicolor.mood at gmail.com
Thu Sep 8 10:22:14 EDT 2016
Hi everyone!
Remember me hyping around with the GitHub bot idea?
Here it is:
- in the source code: https://github.com/facebook/mention-bot
- in
action: https://github.com/tensorflow/tensorflow/pull/4239#issuecomment-245180925
Just putting it here to bookmark. If someone of you will decide to play
with it, I'm all ears to hear the feedback.
I'll most likely give it a try in the coming weeks.
Regards,
Egor
вторник, 23 августа 2016 г., 0:26:52 UTC+3 пользователь 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20160908/7d00872c/attachment.html>
More information about the scikit-image
mailing list