PHP: rfc:github-pr

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== PHP RFC: GitHub Pull Requests Triage Team ======
  * Version: 1.0
  * Date: 2014-10-30
  * Author: John Bafford, john@bafford.com
  * Status: Under Discussion
  * First Published at: http://wiki.php.net/rfc/github-pr

===== Introduction =====
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.


===== Proposal =====
A small team should be put together to:

1) Regularly triage the pull requests posted to GitHub by labeling them appropriately. All pull requests should be inspected and labelled.

Each PR may have one or more labels, as relevant:
  * rfc
  * bug (fixes a bug; preferably with a pointer to the relevant bugs.php.net entry)
  * feature-request (a feature request that does not have an RFC)
  * tests
  * docs (documentation)
  * trivial (typo fixes, whitespace fixes, etc)
  * misc (stuff that has been triaged, but does not clearly fall into any category)

Applying labels will require write access to the GitHub repository. (This implies that whomever has access to do this will have to be trusted to not change the GitHub repository, so as not to break the mirroring tools, or introduce changes to the GitHub repository other people might clone and use.)


2) On a weekly basis, an email should be sent to internals with a summary of PRs. This, in combination of triaged PRs, should make it easier to determine which PRs should be looked at in more detail and pulled into PHP.


3) Pending PRs that have been waiting on a response from the submitter for over two weeks should be closed. (The submitter may always re-open a PR, but it’s their responsibility to be responsive to requests from the maintainers.)


The team should consist of 2 - 3 people who can, on a regular basis, implement the proposal. I’m volunteering to lead the team, and I am happy to work with whomever else wants to help. In any case, there should be more than one person responsible to cover unavailability and provide for a means to more easily facilitate transition when team members step down.


===== RFC Impact =====
This RFC only concerns process; PHP itself is unchanged. Thus, there are no backward-incompatible changes, a proposed version for implementation, or affected features, SAPIs, extensions, opcache, constants, or php.ini defaults.


===== Open Issues =====
(No open issues at this time.)


===== Future Scope =====
There are a number of automated processes the PR triage team could use which may help, such as (but not necessarily limited to):
  * automatically closing idle PRs
  * noting when a travis test is failing and alerting the submitter to take corrective action


===== Proposed Voting Choices =====
This RFC does not suggest a language change, so a 50%+1 majority is required for passage.


===== Implementation =====
This RFC could serve as its own documentation, or alternatively, we could produce a document that might be better described as documentation, rather than this proposal.


===== References =====
(No external references at this time.)


===== Rejected Features =====
(No rejected features at this time.)
Page Tools
