We can say with confidence that issue tracking is useless without the use of issue statuses. Moreover, the more detailed the issue statuses, the more accurate the workflow. On the other hand, too many details can make the working process annoying. Therefore, I believe that choosing the right issue statuses for your processes is extremely important in order for your users to have a good experience with Redmine. In fact, this should be one of the first things that you configure after having deployed Redmine in your organization.

Issue statuses can be managed using the Issue statuses page of the Administration menu. This page is shown here:

Generally, an issue can be open or closed. Therefore, each issue status has a property that determines whether this status makes an issue closed. In the list that is shown in the preceding screenshot, such issue statuses are marked with a check mark under the Issue closed column. Also, as you can see, Redmine can have several statuses that mark the issue as closed. For example, they can be Closed or Rejected, as in the screenshot, or Won't Fix, Obsolete, Not Confirmed, Fixed, and so on.

Again, the order of issue statuses on this page is important and can be modified using the green arrows under the Sort column. The same order is used in issue forms. Ideally this order should reflect the completeness of the issue from the very initial state (such as New) to the final state (such as Closed).

Issue statuses can be edited by clicking on their names. A new issue status can be added by clicking on the New status link. In both cases, the following form is opened:

Generally, that's all regarding the Issue statuses page, despite the fact that issue statuses are actually what defines the life cycle of the issue and builds the workflow. However, it would be too complicated to manage the workflow along with issue statuses. Therefore, this was moved to a separate page of the Administration menu.