Bug management/Bug report life cycle

This page describes the life of a bug report. If a bug report was marked as RESOLVED or VERIFIED and it turns out that this was incorrect, the bug can be changed to the status REOPENED, which is basically the same as UNCONFIRMED or NEW.
 * When a bug is first reported, it is given UNCONFIRMED or NEW status.
 * The status is changed to NEW when it has been verified that is indeed a MediaWiki or Wikimedia bug and when it can be reproduced.
 * Once a developer has started to work on a bug, the status ASSIGNED is set. The "Assigned to" field should mention a specific developer.
 * If an initial patch for a bug has been put into the Gerrit code review tool, the status PATCH_TO_REVIEW is automatically set.
 * When a report has been solved it is given RESOLVED status. This can mean:
 * RESOLVED FIXED when a code change that fixes the reported problem has been merged in Gerrit. This does not mean that the fix is immediately available on a Wikimedia website as it can take up to two weeks.
 * RESOLVED WONTFIX when the reported problem is a valid bug affecting the MediaWiki core or WMF wikis that it has been decided, by those with authority over the matter, should not be fixed.
 * RESOLVED WORKSFORME when the problem can not be reproduced or when missing information has not been provided
 * RESOLVED INVALID when the problem is not a bug, or when it is a change that is outside the power of the MediaWiki development community or WMF to make. For example, bugs proposing changes to third-party software are INVALID. Likewise, "change $wgNofollowLinks on Wikinfo" would be INVALID because that change can only be made by the system administrators of Wikinfo, which is not a WMF wiki.
 * RESOLVED DUPLICATE when the problem has been reported before, no matter if the previous report has been already resolved or not.
 * Optionally the status VERIFIED is set if a QA tester or the reporter checked that the after the fix has been deployed.