Re: [RFC] GitHub Pull Requests Triage Team

> On 30 Oct 2014, at 21:57, John Bafford <jbafford@zort.net> wrote: > I would like to propose the creation of a team to triage the pull requests on GitHub, to help > ensure that the pull requests are handled in a timely manner. I am also volunteering to lead such a > team, should the RFC be approved. > > https://wiki.php.net/rfc/github-pr > > PHP’s GitHub repository has over 180 open pull requests. Many of these are bug fixes or new > tests that should be incorporated into PHP, but have not been because the PRs aren’t being > regularly monitored. As a result, the large number of open pull requests may also be discouraging > contributions, as potential contributors may see that pull requests are not being acted on and > decline to submit changes. Glad to see this, the pull request situation is really getting out of hand. I’d like to make a small request, though. For RFCs, there should be a distinction between RFCs that haven’t yet passed, which have pull requests mainly for code review purposes, and RFCs that have passed, which are waiting to be merged. Actually, it might be best to generally ignore RFC pull requests. For those that haven’t yet passed, they just want someone to look at the code. For those that have, if the author has commit access, they don’t need someone else to merge it, and the request is probably sticking around because the patch isn’t yet fixed. The exception is pull requests for accepted RFCs by authors who lack commit access: for these, someone will need to go and merge them. -- Andrea Faulds http://ajf.me/