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.
Thanks,
-John
Big +1 for me. This is good a idea to make contributors' work easier.
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.Thanks,
-John
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.
Slightly off-topic, but how about the same thing for bugs.php.net and
patches?
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.Thanks,
-John
On 31.10.2014 09:58, Peter Cowburn wrote:> On 30 October 2014 21:57,
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.Slightly off-topic, but how about the same thing for bugs.php.net and
patches?
This implies that on bugs and with PRs it's the same issue.
My cautious guess is that permissions to merge PRs on GitHub (which not
all developers can do) are not the main reason that stuff doesn't get
merged.
Whereas on the bug tracker, afaik everyone with a php.net account can
triage, edit, assign, etc bugs. And still there are open ones.
So, if it's only a permissions issue and people are active hindered to
get stuff done, go ahead and propose changes. If it just feels like
stuff doesn't get done... maybe no one's around to do it.
~Florian
On Fri, Oct 31, 2014 at 3:13 PM, Florian Anderiasch ml@anderiasch.de
wrote:
On 31.10.2014 09:58, Peter Cowburn wrote:> On 30 October 2014 21:57,
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.Slightly off-topic, but how about the same thing for bugs.php.net and
patches?This implies that on bugs and with PRs it's the same issue.
My cautious guess is that permissions to merge PRs on GitHub (which not
all developers can do) are not the main reason that stuff doesn't get
merged.
when qa.php.net is not dead, anybody with a php.net account is allowed to
comment/close github PRs.
for merging them, you are still required to have the appropriate karma to
be able to push it to git.php.net.
Whereas on the bug tracker, afaik everyone with a php.net account can
triage, edit, assign, etc bugs. And still there are open ones.
I think that from the who can do what perspective those two are similar,
anybody can help to review/debug and propose a improvements/solution or
close the bogus reports/PRs, but at the end of the day, only those with
approrpiate karma can merge the PR/patch for the fix.
So, if it's only a permissions issue and people are active hindered to
get stuff done, go ahead and propose changes. If it just feels like
stuff doesn't get done... maybe no one's around to do it.
personally I think that we lack people for both triaging/reviewing and
merging/pushing the changes.
So anybody willing to look into bugs/PRs are more than welcome, and even if
he/she don't have the knowledge or karma to fix/merge the issue, it will
already make it easier for those who do to do the last step.
ps: if you need help for getting something looked at, org merged, feel free
to ping the RMs and/or complain on internals@, because it is easy for us to
miss things because of the already huge backlog of open bugs/PRs. I
personally think that we should make some drastic measures to bring down
the open bugs/feature requests to a managable level (see
http://www.joelonsoftware.com/items/2012/07/09.html) as currently we have
all the bugs/features reported since 1999.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Fri, Oct 31, 2014 at 3:13 PM, Florian Anderiasch ml@anderiasch.de
wrote:On 31.10.2014 09:58, Peter Cowburn wrote:> On 30 October 2014 21:57,
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.Slightly off-topic, but how about the same thing for bugs.php.net and
patches?This implies that on bugs and with PRs it's the same issue.
My cautious guess is that permissions to merge PRs on GitHub (which not
all developers can do) are not the main reason that stuff doesn't get
merged.when qa.php.net is not dead, anybody with a php.net account is allowed to
comment/close github PRs.
for merging them, you are still required to have the appropriate karma to
be able to push it to git.php.net.Whereas on the bug tracker, afaik everyone with a php.net account can
triage, edit, assign, etc bugs. And still there are open ones.I think that from the who can do what perspective those two are similar,
anybody can help to review/debug and propose a improvements/solution or
close the bogus reports/PRs, but at the end of the day, only those with
approrpiate karma can merge the PR/patch for the fix.
I think what’s on bugs.php.net and what’s in a GitHub PR are largely two very different things, requiring two separate skill sets.
bugs.php.net is a bug and feature request database, and is a primary interface for users of PHP to ask for things. While you can provide a patch or a GitHub PR with an entry, the triage process for the bug database is likely to revolve around attempting to reproduce or confirm problems, de-duping, and then eventually getting someone to actually fix the bug or implement the feature.
A PR in GitHub, on the other hand, comes with (presumably working) code, so it jumps to the end of the line: validation that the code is correct and (in the case of new features, which should have an accompanying RFC) is the sort of thing we want in PHP.
I agree that there needs to be a triage team for bugs (there are 5,219 open bugs in the db since 1999, a large number of which I’m guessing are actually dups, invalid, already fixed, or wontfix), and while it’s also an important job, it’s also outside the scope of the problem I’m trying to solve (actual written code that could go in, but is languishing instead). I’d like to get the GitHub triaging set up first since in theory all the PRs are actionable, and if we want to set up a formal triage team/process for bugs, we can discuss how best to manage that without biting off too much at one time. (PR triaging can realistically be done by one person; but going through the bugs backlog really is going to require a several person team, and probably one that collectively has experience with the entire PHP feature set.)
So, if it's only a permissions issue and people are active hindered to
get stuff done, go ahead and propose changes. If it just feels like
stuff doesn't get done... maybe no one's around to do it.personally I think that we lack people for both triaging/reviewing and
merging/pushing the changes.
So anybody willing to look into bugs/PRs are more than welcome, and even if
he/she don't have the knowledge or karma to fix/merge the issue, it will
already make it easier for those who do to do the last step.
Yes, this exactly. And I’m envisioning that at some point, the GitHub PR Triage Team would also have the karma to commit the simple, non-controversial items, which would allow the more senior devs to focus on the larger/controversial/more important items.
ps: if you need help for getting something looked at, org merged, feel free
to ping the RMs and/or complain on internals@, because it is easy for us to
miss things because of the already huge backlog of open bugs/PRs. I
personally think that we should make some drastic measures to bring down
the open bugs/feature requests to a managable level (see
http://www.joelonsoftware.com/items/2012/07/09.html) as currently we have
all the bugs/features reported since 1999.
We can avoid declaring bankruptcy on the PRs since there’s relatively few of them, and getting a triage team off the ground will help us from ever having to do that. I don’t know that we should declare bug bankruptcy, but if we do, we should first figure out how we’re going to go forward to make sure we never have such a huge backlog again.
But I also think that dealing with the bugs situation is a separate discussion. Let’s get GitHub PR triage going first, and we can apply any lessons we learn to the other problems.
-John
Hi!
Slightly off-topic, but how about the same thing for bugs.php.net and
patches?
I'd say this would be excellent - somebody contributing time to triage
the bugs on bugs.php.net and separating "I made a typo but I'm sure it's
PHP's fault" from "I discovered a major case of broken but nobody knows
about it", giving suitable feedback for the former and raising profile
of the latter on internals - that would be awesome. I think that would
also have more people that have knowledge to fix bugs but only have
limited to spend on them be able to contribute much more efficiently.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
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.
I've read the proposal, and the idea of labeling the PRs and having
reports looks good. The only thing I would be more careful about is
closing the requests - 2 weeks sounds a bit too aggressive, I'd chose
something like a month. Inactive pull does not consume any resources,
and it's much better to have a pull lie around for some time and be
picked up when somebody has time to look at it than to bury it and lose
a contribution.
Many PRs also get stuck in limbo because they either need some minor
modification that the original author does not provide because he either
lost interest or unaware of the need, or need somebody interested to
push the discussion forward. In the former case, it would be nice for
someone to make the minor change, which is mostly the question of time
investment. In the latter, it's more the question of need - does
somebody need this change enough? Closing such requests would be ok
provided it'd be easy to resurrect them in case somebody gets interested.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
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.
Glad to see this, the pull request situation is really getting out of hand.
I’d like to make a small request, though. For RFCs, there should be a distinction between RFCs that haven’t yet passed, which have pull requests mainly for code review purposes, and RFCs that have passed, which are waiting to be merged. Actually, it might be best to generally ignore RFC pull requests. For those that haven’t yet passed, they just want someone to look at the code. For those that have, if the author has commit access, they don’t need someone else to merge it, and the request is probably sticking around because the patch isn’t yet fixed. The exception is pull requests for accepted RFCs by authors who lack commit access: for these, someone will need to go and merge them.
Andrea Faulds
http://ajf.me/
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.
Glad to see this, the pull request situation is really getting out of hand.
Ditto on this as well. We also need a better way of managing other PHP repository (e.g. PECL extensions) PRs. I was just talking to Rasmus, Hannes and Ferenc about this today, and it appears the https://qa.php.net/pulls https://qa.php.net/pulls has been down for some time.
I’d like to make a small request, though. For RFCs, there should be a distinction between RFCs that haven’t yet passed, which have pull requests mainly for code review purposes, and RFCs that have passed, which are waiting to be merged. Actually, it might be best to generally ignore RFC pull requests. For those that haven’t yet passed, they just want someone to look at the code. For those that have, if the author has commit access, they don’t need someone else to merge it, and the request is probably sticking around because the patch isn’t yet fixed. The exception is pull requests for accepted RFCs by authors who lack commit access: for these, someone will need to go and merge them.
Andrea Faulds
http://ajf.me/
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.
Glad to see this, the pull request situation is really getting out of hand.
I’d like to make a small request, though. For RFCs, there should be a distinction between RFCs that haven’t yet passed, which have pull requests mainly for code review purposes, and RFCs that have passed, which are waiting to be merged. Actually, it might be best to generally ignore RFC pull requests. For those that haven’t yet passed, they just want someone to look at the code. For those that have, if the author has commit access, they don’t need someone else to merge it, and the request is probably sticking around because the patch isn’t yet fixed. The exception is pull requests for accepted RFCs by authors who lack commit access: for these, someone will need to go and merge them.
I think that GitHub PRs that reference an RFC need to be tagged as such, if for no other reason than to mark them as triaged, so that it’s clear that no label means only one thing (“hasn’t been triaged yet”). We’ll get into trouble if it ever becomes unclear why something is tagged/not tagged the way it is.
Having separate labels for the RFC’s status (rfc-draft, rfc-proposed, rfc-accepted, rfc-declined) would make it pretty easy to see what the state of things are, and shouldn’t be too much extra effort to keep updated; RFCs don’t change state all that frequently.
-John
Hi,
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,
Pierre
Hi,
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
It depends on the type of discussion - PR discussions can be an opportunity for code review and discussing the minutiae of the implementation, which don't really warrant forwarding to a wider audience. If the discussion becomes about the merit or impact of the change itself, then a discussion on Internals might make sense. The same is true of bug discussions; having every comment on every bug flood the list wouldn't make sense, but some should probably be forwarded here to get a wider audience.
I don't know what the volume in this case would be, though. If there were several posts popping up on Internals every day about someone misplacing a curly brace, I would definitely think it was noise; if it were a few threads a week, mostly discussing the actual substance of changes, I'd be fine with it.
Hi,
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
listIt depends on the type of discussion - PR discussions can be an opportunity for code review and discussing the minutiae of the implementation, which don't really warrant forwarding to a wider audience. If the discussion becomes about the merit or impact of the change itself, then a discussion on Internals might make sense. The same is true of bug discussions; having every comment on every bug flood the list wouldn't make sense, but some should probably be forwarded here to get a wider audience.
I don't know what the volume in this case would be, though. If there were several posts popping up on Internals every day about someone misplacing a curly brace, I would definitely think it was noise; if it were a few threads a week, mostly discussing the actual substance of changes, I'd be fine with it.
I would expect that, at the least, there would be an uptick in discussion just as a result of weekly PR summary making the pending PRs more visible. My guess is that there might be a lot of discussion and/or noise initially as we get the current backlog (185 PRs currently open) whittled down to something more manageable, so it might take a few months after the RFC is adopted for the true nature of the volume increase (if any) to become apparent.
-John
Hey:
Hi,
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
Pierre
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
Hi,
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
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.
I think we should work on the integration of bugs.php.net (b.p.n) and
PRs. A PR either is a bug fix or a feature request, both are handled at
b.p.n. I once created an initial implementation of such an feature in
hope somebody would pick it up and extend it (see "Pull Requests" in
i.e. https://bugs.php.net/bug.php?id=1&edit=2) meanwhile GitHub added
Webhooks (https://developer.github.com/webhooks/) which should allow to
automatically update b.p.n from PR changes.
The second issue is that we're doing a bad job at handling bug reports,
(https://bugs.php.net/stats.php) there are only very few guys who go
through reports and handle those. This simply is a lot of work affecting
areas which reviewers probably don't really know. For helping there when
doesn't have to be a code contributor i.e. requinix afaik never proposed
a patch (sorry if I missed it!) but does a very good job answering to
bug reports.
I'd also like if we could investigate which triage fields in the bug
tracker make sense, right now we basically either reject a bug or assign
it to an extension maintainer, hoping they find the time to look into
it. Marking things as "trivial" as you suggest or some other criteria
might help there to get other (new?) contributors to look into it.
I won't like spreading this even more. PRs, RFC wiki, b.p.n, internals
are quite a few official channels (aside from inofficial like IRC) and
we should consolidate them instead of improving all individually ...
johannes
On Mon, Nov 10, 2014 at 9:40 AM, Johannes Schlüter
johannes@schlueters.de wrote:
The second issue is that we're doing a bad job at handling bug reports,
(https://bugs.php.net/stats.php) there are only very few guys who go
through reports and handle those. This simply is a lot of work affecting
areas which reviewers probably don't really know. For helping there when
doesn't have to be a code contributor i.e. requinix afaik never proposed
a patch (sorry if I missed it!) but does a very good job answering to
bug reports.
Thanks. While I know C fairly well and don't have a problem reading
the PHP source, I wouldn't trust myself to write a patch for anything
more than a trivial fix :(
And I figure there are a decent number of people like me too: they may
not be able to contribute to the source but they have been working
with PHP for years, know it well, and would be able to help triage
bugs. The main problem that I've heard is that it's not easy to figure
out what they can do without a php.net account; I generally tell them
that they can ask for more details or backtraces when needed, test on
their own systems, make documentation patches in the DOE, even trudge
through the old bug reports if they're really bored (I don't mind the
few clicks to close bugs if someone else spends the time to find
them!).
-Damian/requinix
Damian Wadley wrote:
I don't mind the few clicks to close bugs if someone else spends the
time to find them!.
Thanks -- that makes it more encouraging to use
https://bugs.php.net/random. :)
If you have some time, you may have a look at the following:
https://bugs.php.net/bug.php?id=52895
https://bugs.php.net/bug.php?id=52287
--
Christoph M. Becker
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.
Hi,
I like the label idea, it will help having a nice overall look on the PRs.
When I myself find some time, I mainly browse through bugs.php.net and
fix things and close issues.
Everything is matter of time and knowledge.
Having people with time to review PRs, and knowledge about internals
code and the PR code quality, is pretty hard to find.
Like Tyrael said, one could always ping an RM to finally merge the PR,
or even review it.
We (as RMs) have already been pinged back in time by people pushing
their PR. This is normal situation, I think everyone is responsible of
his own PR, nd responsible of pushing it into the final step. But as
we all volunteer into the PHP project, it may sometimes be hard to
find time for. Not bad, a PR is obviously never lost until cleaned.
PS : our merging strategy as well is not easy to get, knowing some PRs
may conflict while merge into the diverging master code.
Julien.P
Hi!
I like the label idea, it will help having a nice overall look on the PRs.
When I myself find some time, I mainly browse through bugs.php.net and
fix things and close issues.
As an experiment, I went and added a bunch of labels to github:
RFC - for RFC PRs
bugfix - for fixes associated with bugs
enhancement - for PRs that improve something that is not a bug, but not
big enough to be RFC
quickfix - small fixes like typos, etc. which can be reasonably merged
by anyone after quick review
tests - test-only PRs, these can also be usually merged as soon as they
pass, since the more tests the better :)
Please tell if you think we need more labels. Don't need too many of
them but I think it'd help if someone having half an hour to contribute
would be able to go to PRs, choose quickfix or typo labels and merge
away without trying to read through gigantic RFC patches.