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:
- label PR appropriately,
- send a weekly "action list" summarizing pending PR, and
- 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
Hi Bishop,
Hi, and happy New Year!
Now that the big push for PHP 7 is done, I'd like to revive earlier discussions on the GitHub PR triage team RFC.
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’t actually materialize until now, though. (Also, I have two other RFCs I’ll be proposing shortly.)
If people are interested in the PR triage team actually being a thing, then I’m happy to organize the effort and we can go through the PR backlog in an organized fashion and figure out what’s 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’s not displaying anything. (oops!)
Also, there was the thought that it didn’t 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’s 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:
• label PR appropriately,
• send a weekly "action list" summarizing pending PR, and
• 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’s 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’d 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?
Thanks,
bishop
-John
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.
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’s not displaying
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’t 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’s
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’s 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’d
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.
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.
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.Warn at 2 weeks, close at 4? There's no real harm in closing it unmerged:
the submitter can always resubmit.
This is a contribution from the cheap seats, since I don't have time
to actually help, but I'm not a big fan of auto-closing contributions
(at least until the branch is literally closed for bug fixes). I'm
worried that it'll send a message that we don't really care about
getting outside contributions, which is obviously not the case.
What's the argument for auto-closing? Our stable branches are actually
pretty stable, so fixes and small features aren't generally going to
have merge issues that fast.
Adam, who misses the days when he could read every new bug and comment.
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.Warn at 2 weeks, close at 4? There's no real harm in closing it
unmerged:
the submitter can always resubmit.This is a contribution from the cheap seats, since I don't have time
to actually help, but I'm not a big fan of auto-closing contributions
(at least until the branch is literally closed for bug fixes). I'm
worried that it'll send a message that we don't really care about
getting outside contributions, which is obviously not the case.What's the argument for auto-closing? Our stable branches are actually
pretty stable, so fixes and small features aren't generally going to
have merge issues that fast.
To be clear, I would not support robo-closing. If a PR merge is failing,
or if the devs need clarification from the PR submitter, or there's any
other reason holding up the merge, and the submitter hasn't
replied/commented for 2 weeks: ping him.
- "Hey, this merge is failing. Can you take a look?"
- "There's some open questions here that are holding the merge back. Can
you respond to So and So about Such and Such?"
So another two weeks pass and still crickets. At that point, we send a
friendly message that we want the contribution, but we have to keep moving
forward:
- "Hey, we want to merge your changes, but the build needs to pass
before we can do that. Please take a look and get back to us." - "Seems like you're on an extended AFK. Get back to us and we'll pick
up where we left off. Thanks!"
Hi!
Warn at 2 weeks, close at 4? There's no real harm in closing it unmerged:
the submitter can always resubmit.
That sounds way too short. I mean if we did process all worthy pulls in
matter of days, then fine (but see below) but we are very far from that.
And when we take a long time to get to it, we should allow some leeway
for them to respond too. So I'd say a year-old stale pull is might be
too old, but 1 month seems to be too soon. Somewhere between those
should be the optimal point :)
And I think RFC pulls should have longer time. Of course, people should
rather work in their private forks, but some people feel more
comfortable collaborating in pulls, and some RFC pulls take way longer
than 4 weeks, and people may take breaks and come back. Having a handful
of long-lived open pulls is not too much trouble.
--
Stas Malyshev
smalyshev@gmail.com
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.
... and we don't have the issue with GitHub only, but also with
bugs.php.net. But frankly I don't see the need for the RFC. This simply
needs people to do the work. Anybody can leave comments and pester
committers. Everybody with php.net account additionally can close bus
and prs and assign bug issues.
Even if there is an RFC those volunteers are needed and could run away
any time.
So if you have the spare time simply start! Be brave!
johannes
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.... and we don't have the issue with GitHub only, but also with
bugs.php.net. But frankly I don't see the need for the RFC. This simply
needs people to do the work. Anybody can leave comments and pester
committers. Everybody with php.net account additionally can close bus
and prs and assign bug issues.Even if there is an RFC those volunteers are needed and could run away
any time.So if you have the spare time simply start! Be brave!
I think the particular advantage of having an RFC (or if not an RFC, a document somewhere describing the contents of the RFC) is so that there’s a framework for the PHP project saying, “this is a desired thing we’d like to have as part of our normal process”, and in the event the people working on it step aside from lack of time, it provides a much easier way of getting someone else to pick up the mantle, since there’s already a document written describing what we want to have happen.
At the least, this is a request for comments, even if it doesn’t actually require a vote, and there didn’t really seem to be a better place to put the document at the time.
johannes
On Fri, Jan 1, 2016 at 9:20 PM, Johannes Schlüter
johannes@schlueters.de wrote:
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.... and we don't have the issue with GitHub only, but also with
bugs.php.net. But frankly I don't see the need for the RFC. This simply
needs people to do the work. Anybody can leave comments and pester
committers. Everybody with php.net account additionally can close bus
and prs and assign bug issues.Even if there is an RFC those volunteers are needed and could run away
any time.So if you have the spare time simply start! Be brave!
Haha, same thoughts here.
Anyone with @php.net account and git rights can do the job.
This is just like any other contribution.
Julien.Pauli