On Fri, Jan 1, 2016 at 2:53 PM, John Bafford <jbaff...@zort.net> wrote:
> > > On Jan 1, 2016, at 13:28, Bishop Bettini <bis...@php.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. > There was also some discussion on integration with bugs.php.net, and > https://qa.php.net/pulls/ was mentioned, which seemed to be working until > I started poking at it to see what it did, and now it’s not displaying > anything. (oops!) > I think this is a valuable conversation to have, but not in the context of this RFC. Specifically, bugs.php.net is front-side support, while GitHub PR is back-side integration. There's a huge gap between the two, in terms of what information is being gathered, analyzed, and worked. Yes, bugs and pulls can be related, but in the vast majority of cases they are not. (Ie, most reports are closed as won't fix <https://bugs.php.net/stats.php>.) Also, there was the thought that it didn’t actually require an approved RFC > to do, just people actually doing the work. (Which is probably true, but I > created the RFC so as to have some ground rules for what said team’s > responsibility would be.) > Because we're volunteers whose efforts are separated in time and space, I think an RFC document helps keep the mission focused even as the team evolves. Besides, there was an RFC <https://wiki.php.net/rfc/releaseprocess> for the release process, which had a similar goal: to bring order to chaos. > As written, that’s correct, though one of the follow-on proposals I > intended to make after the team actually got established and was shown to > be actually helping would be to ask for permission to merge trivial and > obviously correct PRs (e.g. typo fixes or new/improved tests) since there’d > be low risk of problems and allowing for a fast turn-around trivial things > like that might help make it easier to include new people in the project, > since those are the sort of low-hanging fruit that new devs often start > with. > Seems to me the speed by which RM/Owners accept trivial PR is one measure of the PR team's effectiveness. Concept: Team tags the PR as trivial. Team sends out a well-crafted summary email highlighting these low hanging fruit. RM/Owners accept. If the PR queue is small, the PR team is tagging well, then the acceptance lag should be small.
