On Mon, Jan 4, 2016 at 3:26 PM, Adam Harvey <ahar...@php.net> wrote: > On 1 January 2016 at 12:12, Bishop Bettini <bis...@php.net> wrote: > > On Fri, Jan 1, 2016 at 2:53 PM, John Bafford <jbaff...@zort.net> wrote: > >> I think when I brought this up before, the major open discussion point > >> before the thread died was what period of time constituted long enough > for > >> closing a waiting-on-submitter PR. 2 weeks is probably too short, but it > >> seemed a reasonable minimum and something had to go into the RFC. I > think 4 > >> weeks is probably a better place to start. > >> > > > > Warn at 2 weeks, close at 4? There's no real harm in closing it > unmerged: > > the submitter can always resubmit. > > This is a contribution from the cheap seats, since I don't have time > to actually help, but I'm not a big fan of auto-closing contributions > (at least until the branch is literally closed for bug fixes). I'm > worried that it'll send a message that we don't really care about > getting outside contributions, which is obviously not the case. > > What's the argument for auto-closing? Our stable branches are actually > pretty stable, so fixes and small features aren't generally going to > have merge issues that fast. >
To be clear, I would not support robo-closing. If a PR merge is failing, or if the devs need clarification from the PR submitter, or there's any other reason holding up the merge, and the submitter hasn't replied/commented for 2 weeks: ping him. - "Hey, this merge is failing. Can you take a look?" - "There's some open questions here that are holding the merge back. Can you respond to So and So about Such and Such?" So another two weeks pass and still crickets. At that point, we send a friendly message that we want the contribution, but we have to keep moving forward: - "Hey, we want to merge your changes, but the build needs to pass before we can do that. Please take a look and get back to us." - "Seems like you're on an extended AFK. Get back to us and we'll pick up where we left off. Thanks!"
