Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89951
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=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
In-Reply-To: <CAEYWF=7LiYDJ1-YU=QYzWsXBewMy_AxZgp=SOqaLRGs5UuawNg@mail.gmail.com>
Date: Fri, 1 Jan 2016 14:53:55 -0500
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <15D9C342-0BF3-4476-8473-A82E858781E3@zort.net>
References: <CAEYWF=7LiYDJ1-YU=QYzWsXBewMy_AxZgp=SOqaLRGs5UuawNg@mail.gmail.com>
To: bishop@php.net
Subject: Re: [RFC] GitHub Pull Requests Triage Team
From: jbafford@zort.net (John Bafford)

Hi Bishop,

> On Jan 1, 2016, at 13:28, Bishop Bettini <bishop@php.net> wrote:
>=20
> Hi, and happy New Year!
>=20
> Now that the big push for PHP 7 is done, I'd like to revive earlier =
discussions on the GitHub PR triage team RFC.
>=20

Thanks for poking me about this. When I originally proposed the PR =
triage team after Zendcon 2014, I expected to have some free time to =
actually take charge of that proposed team. That free time unfortunately =
didn=E2=80=99t actually materialize until now, though. (Also, I have two =
other RFCs I=E2=80=99ll be proposing shortly.)

If people are interested in the PR triage team actually being a thing, =
then I=E2=80=99m happy to organize the effort and we can go through the =
PR backlog in an organized fashion and figure out what=E2=80=99s =
actually there.

I think when I brought this up before, the major open discussion point =
before the thread died was what period of time constituted long enough =
for closing a waiting-on-submitter PR. 2 weeks is probably too short, =
but it seemed a reasonable minimum and something had to go into the RFC. =
I think 4 weeks is probably a better place to start.

There was also some discussion on integration with bugs.php.net, and =
https://qa.php.net/pulls/ was mentioned, which seemed to be working =
until I started poking at it to see what it did, and now it=E2=80=99s =
not displaying anything. (oops!)

Also, there was the thought that it didn=E2=80=99t actually require an =
approved RFC to do, just people actually doing the work. (Which is =
probably true, but I created the RFC so as to have some ground rules for =
what said team=E2=80=99s responsibility would be.)


> A year ago, there were 180 open PR.  Today there are 281.  Most new PR =
are labelled and better organized, but many dead/defunct/zombie/unloved =
PR remain. I'm not aware of any process to handle those dead PR, and =
this RFC seemed to address that problem with its three-part objectives:
> 	=E2=80=A2 label PR appropriately,
> 	=E2=80=A2 send a weekly "action list" summarizing pending PR, =
and
> 	=E2=80=A2 ensure PR submitters keep their PR up to date, or =
close PR accordingly.
> As I read the RFC, the team will not merge PR or hold RM =
responsibilities. Instead, the team facilitates PR merging by keeping =
the PR list organized and ready to act upon.

As written, that=E2=80=99s correct, though one of the follow-on =
proposals I intended to make after the team actually got established and =
was shown to be actually helping would be to ask for permission to merge =
trivial and obviously correct PRs (e.g. typo fixes or new/improved =
tests) since there=E2=80=99d be low risk of problems and allowing for a =
fast turn-around trivial things like that might help make it easier to =
include new people in the project, since those are the sort of =
low-hanging fruit that new devs often start with.


> Thoughts?
>=20
> Thanks,
> bishop

-John