Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89949
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.52 as permitted sender)
MIME-Version: 1.0
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
Date: Fri, 1 Jan 2016 13:28:58 -0500
Message-ID: <CAEYWF=7LiYDJ1-YU=QYzWsXBewMy_AxZgp=SOqaLRGs5UuawNg@mail.gmail.com>
To: john@bafford.com
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1146ed8c90ebd5052849f3b1
Subject: [RFC] GitHub Pull Requests Triage Team
From: bishop@php.net (Bishop Bettini)

--001a1146ed8c90ebd5052849f3b1
Content-Type: text/plain; charset=UTF-8

Hi, and happy New Year!

Now that the big push for PHP 7 is done, I'd like to revive earlier
discussions
<http://grokbase.com/t/php/php-internals/14ay38dsx6/rfc-github-pull-requests-triage-team>
on the *GitHub PR triage team* RFC <https://wiki.php.net/rfc/github-pr>.

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:

   1. label PR appropriately,
   2. send a weekly "action list" summarizing pending PR, and
   3. 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
<https://wiki.php.net/rfc/releaseprocess>. Instead, the team facilitates PR
merging by keeping the PR list organized and ready to act upon.

Thoughts?

Thanks,
bishop

--001a1146ed8c90ebd5052849f3b1--