On Oct 31, 2014, at 12:10, Andrea Faulds <a...@ajf.me> wrote: > >> On 30 Oct 2014, at 21:57, John Bafford <jbaff...@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.
I think that GitHub PRs that reference an RFC need to be tagged as such, if for no other reason than to mark them as triaged, so that it’s clear that no label means only one thing (“hasn’t been triaged yet”). We’ll get into trouble if it ever becomes unclear why something is tagged/not tagged the way it is. Having separate labels for the RFC’s status (rfc-draft, rfc-proposed, rfc-accepted, rfc-declined) would make it pretty easy to see what the state of things are, and shouldn’t be too much extra effort to keep updated; RFCs don’t change state all that frequently. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
