Re: [RFC] GitHub Pull Requests Triage Team
| From: | John Bafford | Date: | Sat, 01 Nov 2014 18:35:16 +0000 |
| Subject: | Re: [RFC] GitHub Pull Requests Triage Team | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78550@lists.php.net to get a copy of this message | ||
On Nov 1, 2014, at 10:27, Xinchen Hui <laruence@php.net> wrote:
> Hey:
>
> On Sat, Nov 1, 2014 at 7:53 PM, Pierre Joye <pierre.php@gmail.com> wrote:
>> Hi,
>>
>> On Oct 31, 2014 4:57 AM, "John Bafford" <jbafford@zort.net> wrote:
>>>
>>> Hi,
>>>
>>> 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.
>>>
>>> https://wiki.php.net/rfc/github-pr
>>>
>>> PHP’s 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’t 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.
>>
>> As much as I like the idea I never understood why we do not have them here.
>>
>> Given that many PRs have discussions, it should show up on internals.
>>
>> PS: yes we have a PR list. Which did not work as expected. PRs and
>> discussions in them should not be considered as noises to the internals list
>> Cheers,
> Maybe we should create some tags , like "minor", "critical", "need
> verify" etc..
>
> for minors, anyone have time can merge it. (like typo fix).
>
> thanks
At the moment, I would be wary of trying to do too much at the start. Having a process and team in
place for getting the PRs triaged is more important than also rating PRs for severity. Once we get
this going and see how it’s helping the overall workflow, we can better consider the best ways to
expand from there.
Adding severity labels is certainly something that we can do in the future. I do note, though, that
bugs.php.net does not appear to have a severity rating; tickets are only tracked according to
bug/feature/docs/security, and the RFC currently has labels for the first three of those. I think if
we’re going to start adding additional labels that go beyond triage, we’d want to coordinate
that with bugs.php.net, and that’s getting to be outside of the scope of this RFC.
Also: would we even want to add a label for security? If I’m remembering correctly, PHP has a
separate (and initially closed) process for tracking security issues, so we may not want to
advertise that a PR is security related until after there’s an official announcement. (I think
this also means that PRs through GitHub are not likely to be security related. But I’m open to
comments/suggestions on the matter.)
-John