Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78549
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zort.net designates 96.241.205.2 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <BF854E26-4029-4E36-AB2E-4C990C954286@ajf.me>
Date: Sat, 1 Nov 2014 14:07:51 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <879FE3FB-7FD3-49B8-BC37-AE2A07DF47CD@zort.net>
References: <EB032A39-EB24-4BBE-A2D3-14BF63809873@zort.net> <BF854E26-4029-4E36-AB2E-4C990C954286@ajf.me>
To: Andrea Faulds <ajf@ajf.me>
Subject: Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team
From: jbafford@zort.net (John Bafford)


On Oct 31, 2014, at 12:10, Andrea Faulds <ajf@ajf.me> wrote:

>=20
>> 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.
>>=20
>> https://wiki.php.net/rfc/github-pr
>>=20
>> PHP=92s 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=92t 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.
>=20
> Glad to see this, the pull request situation is really getting out of =
hand.
>=20
> I=92d like to make a small request, though. For RFCs, there should be =
a distinction between RFCs that haven=92t 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=92t yet passed, they just =
want someone to look at the code. For those that have, if the author has =
commit access, they don=92t need someone else to merge it, and the =
request is probably sticking around because the patch isn=92t 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=92s =
clear that no label means only one thing (=93hasn=92t been triaged =
yet=94). We=92ll get into trouble if it ever becomes unclear why =
something is tagged/not tagged the way it is.

Having separate labels for the RFC=92s status (rfc-draft, rfc-proposed, =
rfc-accepted, rfc-declined) would make it pretty easy to see what the =
state of things are, and shouldn=92t be too much extra effort to keep =
updated; RFCs don=92t change state all that frequently.

-John=