Welcome to the HOWTO on managing PHP bugs via bugs.php.net. PHP is a large project with many bugs being submitted daily. Bug topics range from the PHP website itself, various PHP extensions, PEAR, etc. This document is for all PHP developers using the bug system. Because there are so many members using the system it's important we act in a consistent manner. This HOWTO is created to solve this.
If you're going to edit a bug be sure that you know the topic. Don't make assumptions. If you've read the bug carefully and think of a solution or related questions, post your answer/comments. If you know of the solution, solve and close the bug.
Never change a status if you're not sure. If you close a bug because you think it's not really a bug and in fact it is, this makes the bug system useless and doesn't benefit anyone. Never close a bug because it's too old, unless your name is Jani. If a bug is in "feedback" status it will close automatically if the bug reporter doesn't answer after two weeks.
If you want to view a bug report, enter the bug id into the url like so (with 20406 being an example):
Which redirects to:
At that point you'll see a set of options. Because you're a developer you will choose the developer option which will then put you here:
There are a set of quickfix options each of which will both insert text into the bug report and change the bug status. Please understand what text and status will be used and only choose a quickfix option if an appropriate quickfix exists. Choosing a quickfix that's not 100% correct will confuse and sometimes irritate the reporter. The following table lists them (see also quick-fix-desc.php):
If no quickfix is available you will manually choose the new status and write some feedback. Select the best status that corresponds to the bug. Here are descriptions for each status:
Sometimes you'll also want to reclassify a bug. For example, a reporter marks a bug as Apache2 related when really it's a MySQL bug. Just change the category but be 100% sure it's related to the new category. Another example would be changing the type to a documentation bug. If you're changing it to a documentation bug it will help the documentation team if you add specific information that is to be documented including what version the changes will take place.
Also note that all bugs are sent to various mailing lists with email@example.com being the default (most go here). Here's a list:
Reclassifying will immediatly change which mailing list is used. If you reclassify a bug and don't leave a comment then no email is sent to the mailing list. So, be sure to leave a comment.
If everyone maintains the bug system in a consistent manner then PHP will be better for it. Also, bug reporters will not get their feelings hurt through miscommunication (e.g. a wrong quickfix or bogus status) Thank you for reading this HOWTO and helping make PHP better.