PHP RFC: Migrating to GitHub Issues

• Date: 2021-11-01
• Author: Nikita Popov nikic@php.net
• Status: Draft

This RFC proposes to use GitHub Issues on the PHP repository in place of our own bugs.php.net bug tracker.

Currently GitHub issues are already used for documentation issues, as well as website issues on the respective repositories. This RFC expands usage to the PHP implementation itself.

The primary motivation for this change is that bugs.php.net has many known issues and is not actively maintained.

TODO

The issue tracker on GitHub will be located on the php/php-src repository. Using a custom issue configuration, creating an issue will display three possible options:

Bug reports and feature requests are filed on GitHub with custom issue forms. Security issues point to bugs.php.net instead, because GitHub currently does not support private issue reports. Additionally, we could add a fourth option for general questions that points to our support page.

If the “bug report” option is chosen, the following form is displayed:

It requires an issue title, description and PHP version, and optionally accepts the used operating system. The description suggests (but does not require) to provide a script with actual and expected output. Additionally, the labels “bug” and “Status: Needs Triage” are automatically applied.

The corresponding form for feature requests only accepts an issue title and description, as PHP version and operating system are usually not relevant in this case. The labels “feature” and “Status: Needs Triage” are automatically applied.

Issues labeled with “Status: Needs Triage” should be reviewed by a member of the php-src team to check whether they are valid (at first glance) and properly categorize them. When the issue is triaged, the “Status: Needs Triage” label is removed and replaced by one or more categorization labels. There are three sets of these:

• “Extension: ext_name” correspond to bundled PHP extensions. For most extension-related issues, just adding the label for the corresponding extension is sufficient, e.g. “Extension: curl” for curl-related issues.
• “SAPI: sapi_name” correspond to bundled SAPIs. These should be added if the issue directly related to the SAPI, e.g. “SAPI: fpm” should be used for FPM-related bugs. It should not be added if the reporter just happens to use this SAPI, but there is otherwise no direct relation.
• “Category: category_name” exists for categories that correspond either to a subset of an extension (e.g. “Category: JIT”) or represent cross-cutting concerns (e.g. “Category: Build System”). These might be applied in addition to or in place of an extension label.

The full set of initially proposed labels is given in the following, but additional labels can easily be added after the fact:

• Extension: bcmath
• Extension: bz2
• Extension: calendar
• Extension: com_dotnet
• Extension: ctype
• Extension: curl
• Extension: date
• Extension: dba
• Extension: dom
• Extension: enchant
• Extension: exif
• Extension: ffi
• Extension: fileinfo
• Extension: filter
• Extension: ftp
• Extension: gd
• Extension: gettext
• Extension: gmp
• Extension: hash
• Extension: iconv
• Extension: imap
• Extension: intl
• Extension: json
• Extension: ldap
• Extension: libxml
• Extension: mbstring
• Extension: mysqli
• Extension: mysqlnd
• Extension: oci8
• Extension: odbc
• Extension: opcache
• Extension: openssl
• Extension: pcntl
• Extension: pcre
• Extension: pdo (core)
• Extension: pdo_dblib
• Extension: pdo_firebird
• Extension: pdo_mysql
• Extension: pdo_oci
• Extension: pdo_odbc
• Extension: pdo_pgsql
• Extension: pdo_sqlite
• Extension: pgsql
• Extension: phar
• Extension: posix
• Extension: pspell
• Extension: readline
• Extension: reflection
• Extension: session
• Extension: shmop
• Extension: simplexml
• Extension: snmp
• Extension: soap
• Extension: sockets
• Extension: sodium
• Extension: spl
• Extension: sqlite3
• Extension: standard
• Extension: sysvmsg
• Extension: sysvsem
• Extension: sysvshm
• Extension: tidy
• Extension: tokenizer
• Extension: xml
• Extension: xmlreader
• Extension: xmlwriter
• Extension: xsl
• Extension: zend_test
• Extension: zip
• Extension: zlib

• SAPI: apache2handler
• SAPI: cgi
• SAPI: cli
• SAPI: cli_server
• SAPI: embed
• SAPI: fpm
• SAPI: fuzzer
• SAPI: litespeed
• SAPI: phpdbg

• Category: Arrays
• Category: Build System
• Category: Engine
• Category: Filesystem
• Category: JIT
• Category: Math
• Category: Streams
• Category: Strings
• Category: Windows

In addition to the categorization labels, a number of status labels can be used:

• Status: Needs Triage. As discussed above, this is the starting state for all new issues. The label is removed after triage by a team member.
• Status: Needs Feedback. This label can be placed if additional feedback from the reporter has been requested. The label is automatically removed if a comment is added (using a GH Actions workflow that runs on issue comment creation). If no comment is added within 14 days, the issue is automatically closed by the close-issues-after-no-reply action. TODO Needs some more work.