Can you imagine issues without issue statuses? We can say with confidence that issue tracking is useless without usage of issue statuses. Moreover, the more detailed are issue statuses, the more accurate is the workflow. But too many details can make the tracking process annoying. Therefore, I believe, choosing right issue statuses for your processes is extremely important for having a good experience with Redmine. In fact, this should be one of the first things you configure after deploying Redmine in your organization.

Issue statuses can be managed in Administration | Issue statuses:

There should be the default issue status which is set when a user posts an issue. While in the web issue form, the user can select the initial issue status, such a possibility sometimes does not exist, for example, for issues created with e-mail messages. In this list, the default issue status, which can, of course, be only one, is marked with the checkmark in the Default value column.

Generally, an issue can be open and closed. Redmine can't guess this basic state by the issue status name, so each issue status also has the property indicating if this status closes the issue. In the status list, such issue statuses are marked in the Issue closed column. Redmine can have many statuses, which mark the issue as closed, for example, they can be Closed or Rejected, as on the screenshot, or Won't Fix, Obsolete, Not Confirmed, Fixed, and so on.

And, 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 and ideally, should reflect the completeness of the issue from the initial state (for example, New) till the final state (for example, Closed).

Issue statuses can be edited by clicking on their names. When you do this, the following form appears:

Generally, that's it regarding managing issue statuses. But, definitely not all regarding the issue tracking. As these are issue statuses, which define the life cycle of the issue and produce the workflow. It's just too complicated to be managed along with issue statuses, and therefore, it was placed into the separate administration section.