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 (see Gerrit/Commit message guidelines).
 * 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 there's a consensus that implementing a particular bug report or feature request would be a bad idea. For example, when a ticket contradicts a particular project's scope or the principles of the project and fixing would be barred from approval by the project's Developers/Maintainers (or product managers, if existing). Depending on the specifics, a user preference, a global configuration variable, a re-implementation, or forking the code can be alternatives to marking a ticket as resolved/wontfix.
 * 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.