Bug management/Bug report life cycle

This page describes the life of a bug report (task) in Phabricator.
 * When a bug is first reported, it is given the Open status.
 * Once a specific developer has started to work on a bug, an assignee is set on the report.
 * If an initial patch for a bug has been put into the Gerrit code review tool, the project Patch-For-Review is automatically added to the report (see Gerrit/Commit message guidelines).
 * Closing a report:
 * A report is given the Resolved status 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.
 * A report is given the Declined status 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. This status is also set when there's a consensus that implementing a particular bug report or feature request would be a bad idea. For example, when a report 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 report as declined.
 * A report is given the Invalid status when the problem is not a bug, or when it is a change that is outside the power of the component's developers. 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.
 * A report is given the Duplicate status when the problem has been reported before and has been merged into another report, no matter if the other report has been already resolved or not.
 * Optionally the keyword Verified is set if a QA tester or the reporter confirmed the merged fix in Gerrit after it had been deployed.
 * If a bug report was marked as "resolved" and it turns out that this was incorrect, the report's status can be changed back to Open.
 * If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on, the Stalled status is temporarily given.

Completing bugs
Different teams complete the work on bugs differently, see Phabricator/Project management. Some remove the Patch-For-Review tag when a bug fix is merged, move it to a Done column on a project workboard after QA and product management have reviewed the change, and only change the task status to Resolved when they complete the current "sprint" or when the code is available in production. Others change the bug status to Resolved the moment a bug fix is merged, leaving its tags and workboard column unchanged.