Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86415
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.19 as permitted sender)
Message-ID: <55665077.6040004@gmx.de>
Date: Thu, 28 May 2015 01:17:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Anatol Belski <anatol.php@belski.net>, 
 'Internals' <internals@lists.php.net>
References: <063f01d09881$2bbf12d0$833d3870$@belski.net>
In-Reply-To: <063f01d09881$2bbf12d0$833d3870$@belski.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: Pull request labels handling
From: cmbecker69@gmx.de (Christoph Becker)

Anatol Belski wrote:

> the PRs on github are already being labeled. Multiple labels are possible.
> However the github ACLs lack on granularity
> https://help.github.com/articles/permission-levels-for-an-organization-repos
> itory/ . Due to that, while being a useful feature, labeling is only
> available for project admins or alike. Now with PHP7 such labeling becomes
> probably even more sense as we'll need to handle BC breaks and other
> situations which would need more testing and care. So the amount of work to
> evaluate and review PRs will grow while the "work team" probably not.
> 
> To improve this, here's an idea originally coming from Ferenc. And it is
> simple - the labeling feature could be integrated with our systems using the
> github API. That would allow to achieve more granularity on who is allowed
> to label. AFAIR there was already some people willing to do labeling, so
> that were a great possibility to build such a team. Such pre evaluating and
> labeling could possibly prevent some awkward situations, help to sort out
> potential issues and BC breaches.
> 
> Thus asking for opinions. As it stands completely open - does this idea
> sound eligible, how can it be integrated, who is yet up for the pre
> evaluation/labeling job? Or any other propositions.

In my humble opinion it would be great if it's feasible.  There is also
the related "GitHub Pull Requests Triage Team" RFC[1] – maybe it's worth
to revive it, but it appears to me all this can be done without an
(approved) RFC.

[1] <https://wiki.php.net/rfc/github-pr>

-- 
Christoph M. Becker