Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78542
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAEZPtU6PA1=jNPcQB5n4m1gYvfxBh_5MsEPHmvD_gAS8hHDyWA@mail.gmail.com>
References: <EB032A39-EB24-4BBE-A2D3-14BF63809873@zort.net> <CAEZPtU6PA1=jNPcQB5n4m1gYvfxBh_5MsEPHmvD_gAS8hHDyWA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Sat, 01 Nov 2014 12:28:07 +0000
To: PHP internals <internals@lists.php.net>
Message-ID: <BC8401DB-143C-4E0A-AE0D-6153AB4F7424@gmail.com>
Subject: Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team
From: rowan.collins@gmail.com (Rowan Collins)

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.