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 or suggestion is valid, but any fix of the reported problem or implementation of the suggestion would be barred from approval by the project's Developers/Maintainers (or product managers, if existing).
 * RESOLVED WORKSFORME when the problem can not be reproduced, when missing information has not been provided, or when an acceptable workaround exists to achieve a similar outcome as requested.
 * RESOLVED INVALID when the problem is not a bug, or when it is a change that is outside the power of MediaWiki development. For example, bugs proposing changes to third-party software or third-party website settings are INVALID, as well as requests contrary to legal or contractual obligations.
 * 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 confirmed the fix after it had been deployed.