Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89952
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
In-Reply-To: <15D9C342-0BF3-4476-8473-A82E858781E3@zort.net>
References: <CAEYWF=7LiYDJ1-YU=QYzWsXBewMy_AxZgp=SOqaLRGs5UuawNg@mail.gmail.com>
 <15D9C342-0BF3-4476-8473-A82E858781E3@zort.net>
Date: Fri, 1 Jan 2016 15:12:12 -0500
Message-ID: <CAEYWF=6b3iyDkBt7ke=v7LCR22kPPrF+hewm3vz4cPE7+kx70w@mail.gmail.com>
To: John Bafford <jbafford@zort.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b450496bd94bf05284b64fd
Subject: Re: [RFC] GitHub Pull Requests Triage Team
From: bishop@php.net (Bishop Bettini)

--047d7b450496bd94bf05284b64fd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 1, 2016 at 2:53 PM, John Bafford <jbafford@zort.net> wrote:

>
> > On Jan 1, 2016, at 13:28, Bishop Bettini <bishop@php.net> wrote:
>
> 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 fo=
r
> 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.
>

Warn at 2 weeks, close at 4?  There's no real harm in closing it unmerged:
the submitter can always resubmit.


> 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 displ=
aying
> anything. (oops!)
>

I think this is a valuable conversation to have, but not in the context of
this RFC.  Specifically, bugs.php.net is front-side support, while GitHub
PR is back-side integration.  There's a huge gap between the two, in terms
of what information is being gathered, analyzed, and worked.  Yes, bugs and
pulls can be related, but in the vast majority of cases they are not.  (Ie,
most reports are closed as won't fix <https://bugs.php.net/stats.php>.)

Also, there was the thought that it didn=E2=80=99t actually require an appr=
oved 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.)
>

Because we're volunteers whose efforts are separated in time and space, I
think an RFC document helps keep the mission focused even as the team
evolves.  Besides, there was an RFC
<https://wiki.php.net/rfc/releaseprocess> for the release process, which
had a similar goal: to bring order to chaos.


> 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 thing=
s
> 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.
>

Seems to me the speed by which RM/Owners accept trivial PR is one measure
of the PR team's effectiveness.  Concept: Team tags the PR as trivial.
Team sends out a well-crafted summary email highlighting these low hanging
fruit.  RM/Owners accept.  If the PR queue is small, the PR team is tagging
well, then the acceptance lag should be small.

--047d7b450496bd94bf05284b64fd--