Re: [RFC] GitHub Pull Requests Triage Team

On 1 November 2014 11:53:11 GMT, Pierre Joye <pierre.php@gmail.com> wrote: >Hi, > >On Oct 31, 2014 4:57 AM, "John Bafford" <jbafford@zort.net> wrote: >> >> Hi, >> >> 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. > >As much as I like the idea I never understood why we do not have them >here. > >Given that many PRs have discussions, it should show up on internals. > >PS: yes we have a PR list. Which did not work as expected. PRs and >discussions in them should not be considered as noises to the internals >list It depends on the type of discussion - PR discussions can be an opportunity for code review and discussing the minutiae of the implementation, which don't really warrant forwarding to a wider audience. If the discussion becomes about the merit or impact of the change itself, then a discussion on Internals might make sense. The same is true of bug discussions; having every comment on every bug flood the list wouldn't make sense, but some should probably be forwarded here to get a wider audience. I don't know what the volume in this case would be, though. If there were several posts popping up on Internals every day about someone misplacing a curly brace, I would definitely think it was noise; if it were a few threads a week, mostly discussing the actual substance of changes, I'd be fine with it.