The statuses depend on the development processes that we are working on. And I imitate the following statuses (specified for the cases of bug tracking) cf. https://bugs.freedesktop.org/page.cgi?id=fields.html#status Statuses for other development processes are as simple as you wrote; The default statuses on Redmine/ProjectChilly are fine to me. IMO, I think we should mention statuses + trackers + roles as a combination when speaking to development processes. By the way, please recommend me a good book on Redmine. (2011/02/17 0:30), Eric Davis wrote: Do your Issue Statuses help or hurt your workflow? Issue Statuses are used in Redmine to create a workflow for issues. In an optimized setup, the issues will move through the different statuses as they are worked on. The Issue Statuses I use for Little Stream Software have been optimized to be as simple as possible for single person business but also communicate where the issue is at to my clients. * Proposed - Someone has an idea for some work but isn't sure about it yet. * New/Approved - Both my client and I like the idea and agree on the budgets. * In Progress - I'm actively working on the issue. * Resolved - I've finished the issue and am waiting for client to sign off on it. (i.e. ready to be tested). * Closed - My client agrees the work is complete. I also use two issue statuses for when exceptions occur: * Declined - one of us decides the issue isn't needed but we want to document the conversation (instead of deleting the issue). * Feedback - someone has a question about the issue that prevents us from working on it This same workflow works for my Open Source plugins but in that case I act as the client and project manager. What issue statuses do you use? What have you found helpful?