Life cycle of an issue

Most changes in Drupal software, as well as some changes in Drupal documentation and community policies and procedures, are discussed, decided upon, and enacted through the use of issues, each of which is associated with a particular project. This page provides a summary of the typical phases an issue goes through, although not all issues go through all of these phases. The phases have accompanying changes to various fields on issues, especially the Status field. For background on issues and projects, see the Related content listed at the bottom of this page.

Typical phases of issues

1. The issue is created by a community member, who brings up a concern, reports a bug, or requests a new feature.
2. The issue is triaged by a maintainer of the project the issue is in, or another community member. In the triage step, there may be a request for more information (such as steps needed to reproduce a bug). The issue may be marked as a duplicate of another issue; the maintainer may close it as obsolete, "won't fix", or "works as designed"; the issue may also be moved to a more appropriate project. The version will most likely be changed to the latest development branch of the project.
3. If the issue is still open after triage, there may be a period of discussion about whether or how it should be fixed. This may result in the issue being closed or moved (see the triage step).
4. The next step is usually for a community member or maintainer to propose a fix and change the issue status to Needs review. For software issues, the fix will be in the form of a patch or merge request. For other types of issues, the fix may be a policy change or an edit of a documentation page.
5. Software fixes in most projects will trigger an automated run of the existing automated tests (including coding standards) for the project; if these tests fail, the issue status will be set to Needs work and a new fix will need to be proposed. As a note, typically, software fixes need to be accompanied by updates or additions to automated tests, to ensure that the fix does not regress in the future.
6. Once a fix has been proposed and passed automated testing, the next step is for a community member or maintainer to review and/or test the fix. The reviewer may approve of the fix and change the issue status to Reviewed and tested by the community, or (politely) request changes and change the issue status to Needs work. If the issue status is changed to Needs work, a community member needs to propose a new fix, so this sequence of steps is typically repeated multiple times except for the simplest issues.
7. The next step is a maintainer review of the fix. If the maintainer approves a software fix, they will commit the fix to the software repository and change the issue status to Fixed, or schedule the commit for a later time. The maintainer may also decide that the fix needs more work, and change the issue status to Needs work (in which case, a community member will need to propose a new fix, starting the fix/review cycle again).
8. In some cases, the maintainers may decide that the fix is important enough that it should be backported to an older development version. If the patch applies with no changes to the older version, the maintainer will apply and commit it at the time of the original commit. If the patch needs to be adapted in order to apply, the maintainer can instead change the status to "Patch (to be ported". Then other developers will make a new patch for the older version and review that patch, so that it can be committed by a maintainer. Depending on how difficult this process is (how different the latest and older versions are), this work may be carried out on a separate issue.