Hi Bishop, > On Jan 1, 2016, at 13:28, Bishop Bettini <bis...@php.net> wrote: > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
