rfc:github_issues

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
rfc:github_issues [2021/11/02 11:34] nikicrfc:github_issues [2021/11/02 14:10] nikic
Line 2: Line 2:
   * Date: 2021-11-01   * Date: 2021-11-01
   * Author: Nikita Popov <nikic@php.net>   * Author: Nikita Popov <nikic@php.net>
-  * Status: Draft+  * Status: Under Discussion
  
 ===== Introduction ===== ===== Introduction =====
Line 214: Line 214:
   * Reporting documentation problems. (Already disabled.)   * Reporting documentation problems. (Already disabled.)
   * Reporting non-security issues against PHP.   * Reporting non-security issues against PHP.
 +
 +===== Alternatives =====
 +
 +The switch to GitHub issues has two primary disadvantages:
 +
 +  * It binds the PHP project more firmly to the GitHub platform. We already host our repositories there and make use of pull request, but this would take additional functionality "out of our control". Of course, that is also kind of the point: We are bad at maintaining critical infrastructure ourselves and would rather someone else took care of it. Someone for whom it is part of their core business, rather than just a necessary annoyance.
 +  * GitHub issues is not a particularly sophisticated issue tracker solution. While it offers many useful features that bugs.php.net does not, it is also less customizable. For example, there is no support for custom metadata on issues beyond standard features like labels or milestones (though there probably [[https://github.com/github/roadmap/issues/277|will be]] in the future).
 +
 +The three possibilities going forward are essentially:
 +
 +  * Keep using bugs.php.net, but invest significant effort into improving it. I expect that at a minimum we would have to require account registration to use bugs.php.net (for reporting or commenting).
 +  * Migrate to GitHub issues as proposed by this RFC.
 +  * Migrate to a different issue tracking solution.
 +
 +Of course, the suggestion to use GitHub issues in particular is not an accident:
 +
 +  * We already host repositories there and use pull requests (and use it for documentation issues). Having everything on platform allows everything to integrate smoothly. Cross-references work everywhere out of the box. Other platforms will likely not be able to offer the same level of integration.
 +  * GitHub has become the industry standard for open-source projects. Anyone with involvement in open-source is very likely to have an account there and be familiar with the main workflows. Using a different platform will likely require people to create a new account, learn the quirks of yet another issue tracker and have one more place to check for progress on reported issues.
 +
 +The requirement for an alternative would be that a) it is hosted (i.e. the PHP project does not need to maintain infrastructure for it), b) has good GitHub integration and c) is "sufficiently better" than GitHub issues to make it worth using a separate product. As PHP does not have a particularly sophisticated issue tracking workflow, I'm doubtful that the tradeoff will be worthwhile. The biggest "advantage" of using a separate product is likely that it will make reporting bugs significantly harder for the casual user, which might make low-quality submissions less likely.
rfc/github_issues.txt · Last modified: 2021/12/04 14:22 by nikic