Is such documentation helpfulness?
http://www.mantishub.com/docs/issue_management.html#issue-lifecycle

[Whoa: blast from the past.]

Mantis is flexible so that you can set it up with a number of different life cycle models. I'm guessing, for example, that most small development teams don't need as many states as that document lists (our certainly didn't). However, each team has to agree on how to handle its Mantis installation's life cycle states, and it isn't trivial to figure this out when you're new to Mantis.

Here's what I wrote up for my team when I originally started using Mantis:

http://suitable.com/docs/mantisbt.html

The "Issue life cycle" section is what I was referring to here. There are lots of ways to use issue trackers, and you can't really expect a new user to come up with a plan all on their own. Plus, the needs of the specific group guide the life cycle choice in complex ways. Ideally, you'd have three different examples of life cycles, with some details on how someone would set up Mantis appropriately:

• Simplest life cycle, with "New", "Assigned" and "Closed"

• Moderately complex life cycle, with "New", "Assigned", "Resolved", "Feedback" and "Closed"

• The extended dance remix life cycle, with everything on that Mantishub document you cited

For each scenario, give why it would work for a specific group and why it might not. You might also add some notes on variations:

• The Resolved->Closed transition can be used for different things: that the QC Department has determined that this bug was indeed fixed, or that the fix has been in the field and nobody's complained about it.

• The Acknowledged state might be useful in some circumstances, but excessive in others (give examples)

In summary, Mantis is no good unless the local users agree on how to use it. Anything you can do to help the local promoter clearly document how it will be used will help get Mantis installed more often.