| Both sides previous revisionPrevious revision | Next revisionBoth sides next revision |
| rfc:github_issues [2021/11/02 09:46] – nikic | rfc:github_issues [2021/11/02 11:34] – nikic |
|---|
| ===== Motivation ===== | ===== Motivation ===== |
| |
| The primary motivation for this change is that bugs.php.net has many known deficiencies and is not actively maintained. | The primary motivation for this change is that bugs.php.net has many known deficiencies and is not actively maintained. Some of the main problems are: |
| |
| TODO | * **Maintenance**: bugs.php.net is essentially unmaintained. Making it fit for continued usage would require implementation effort beyond simple cosmetic changes. It must be emphasized that this is not just a matter of finding a motivated person to implement changes, it also requires someone to review them and to perform any necessary infrastructure updates, such as database migrations. There is generally very little interest in these things and it can take a lot of time to get things done. |
| | * **Stability**: For years now, bugs.php.net regularly hangs or slows down to unusable levels. We "fix" this with a server restart, but nobody has found the motivation to find out what the actual problem is. |
| | * **Spam**: We receive a lot of link spam. While comments are nominally captcha-protected, the captcha is very weak. On normal days, it is necessary to delete a handful of spam comments. On bad days, a mass deletion in the database is necessary. A better captcha and/or a ban on links to domains other than php.net, github.com and 3v4l.org might address this. |
| | * **Hostile comments**: Because there is no account requirement, bugs.php.net has effectively no moderation capabilities and suffers from hostile user comments. A particularly well-known quantity is Reindl Harald, who regularly insults bug reporters in comments, damaging the reputation of the PHP project. |
| | * **Impersonation**: Apart from ''@php.net'' accounts, bug reporters and comments can specify an arbitrary email, ownership of which is not validated. This makes it trivial to impersonate another person. This capability is also used for hostile comments. On a related note, reporters are sometimes unhappy with the fact that bugs.php.net displays their email address in plain text. |
| | * **Accessibility**: Nowadays, most open-source projects manage issues on GitHub and users will look there first. Submitting an issue on a home-grown bugtracker comes with additional friction to learn a new bug reporting workflow and its associated quirks (and bugs.php.net is on the quirkier side there). |
| | * **Management of reported bugs**: For bug reporters without a php.net account, managing their reported bugs is very inconvenient. Editing a bug requires a per-bug password, and you can't easily track all the bugs you have reported. |
| | * **Mentions**: It's not possible to mention another php.net team member on bugs.php.net. The only way to ask someones opinion on an issue is to assign it to them, and there can only be one assignee. |
| | * **Moving issues**: We are currently in an in-between state where implementation bugs are on bugs.php.net, while documentation bugs are on GitHub. It is common that an issue originally reported as an implementation bug turns out to be a documentation problem. We currently cannot easily transfer such an issue to GitHub. It is valuable to have the issues for all sub-projects on one platform to allow this kind of seamless movement. (Of course, this problem did not exist before documentation started using GitHub issues.) |
| | * **References**: We already host our source code repositories on GitHub and make heavy use of pull requests there. Hosting issues on the same platform makes it easier to cross-reference issues, pull requests and commits. While commits closing a bug are automatically linked from bugs.php.net other references (e.g. from pull requests) are not visible on bugs.php.net unless they are manually added. |
| | * **Labels**: Bugs only support specifying a single package, there is no capability to apply multiple labels. For example, we have no way to mark beginner-friendly issues (the "probably easy" label on GitHub). |
| | * **Check boxes**: bugs.php.net does not support check boxes, or edits to the bug description. This makes it impossible to use bugs.php.net for tracking issues, which consist of multiple sub-tasks. |
| |
| ===== Proposal ===== | ===== Proposal ===== |
| * Reporting documentation problems. (Already disabled.) | * Reporting documentation problems. (Already disabled.) |
| * Reporting non-security issues against PHP. | * Reporting non-security issues against PHP. |
| |
| Some effort will still have to go into maintaining bugs.php.net. In particular, as comment spam is a major problem for us and comments will continue to be supported, we will have to add stronger spam protection there. As this will be legacy system we can degrade user experience though, e.g. by using reCaptcha. | |