1. NEW: status of a bug just inserted into the database.
2. ASSIGNED: when the maintainers accept responsibility for the bug.
3. UNCONFIRMED: the bug is not yet confirmed, but testing is being done to verify it.
4. VERIFIED: the bug is verified but has not been fixed.
5. TOVALIDATE: the bug is sent to QA to verify the fix.
6. NEEDSWORK: the bug is sent back to the maintainer to work on it more (ie. QA did not validate the fix).
7. RESOLVED: when the bug is resolved by the maintainer; can be one of the following states:
1. FIXED: the bug is fixed and the solution is tested.
2. INVALID: the problem described is not a bug.
3. WONTFIX: the bug cannot be fixed for some reason.
8. CLOSED: the bug is closed, with no resolution status (ie. an invalid bug report).
9. REOPENED: the bug has been reopened after it was CLOSED or RESOLVED due to new information

Yes they can. On the bug report page, a field allows the maintainer to reassign the bug to another person.

No. The reporter is only authorized to enter more comments about the bug, like anyone else. Only the assigned maintainer and privileged users are able to modify the bug status.

A bug can be generalized as an error in a piece of software, however it can be more than just that. A bug can be something immediate (ie. a crash), or strange behaviour in a program (ie. it doesn't seem to work correctly) that cannot be fixed through configuration changes. Errors in documentation may also be considered to be a bug.

This system is a means to assist vendors and developers in gathering information related to a problem report. It offers several critical features: Accountability on behalf of developers, a clear path for bug's "lifespan" to travel through the stages necessary for the bug to be fixed, and a central information source for developers to look at when dealing with error reports (rather than multiple sources such as email, web forums, IRC, etc.).

To submit a bug you must first obtain an Anthill account if you do not have one already. This can be done by using the New User Registration form. If you already have an account, be sure that you are logged in.

Search for your problem first! This allows the developers to spend more resources on fixing bugs than Anthill management. By searching, you can see if your problem has already been reported or previously fixed. If you see an open bug dealing with the same problem, you can add yourself to the CC list and add any pertinent comments to the report to assist the developers in resolving the problem. You can search for bugs by using the Query Bugs form.

If your bug is not already in the system, proceed to entering a bug report. You will be asked to choose an appropriate product if more than one product exists in the system. You will also be asked to provide the version of the product this bug pertains to, and a component that it belongs to. Try to be as accurate as possible as that will help the developers to quickly identify the problem so they can spend time fixing it.

You can choose whom to assign the report to. In most cases, the owner of the component, which is selected by default, is the obvious choice. Only re-assign ownership of a bug if you have a real reason to assign it to another developer. You can also select Resolution Priorities and Severities for the bug; the Resolution Priority is how quickly you feel the bug should be addressed. If it is a "show stopper" bug, you might assign it a Resolution Priority of "High" or "Critical", whereas a feature enhancement or smaller bug might have a lower priority. Likewise, a bug that causes data loss may be assigned a Severity of "Critical", while a cosmetic bug may be "Trivial". Please be considerate of the developers and think of your problem in the grand scheme of things; because you feel having new widgets is critical does not mean this will be a priority for developers or others.

Include a brief summary of the bug that easily and quickly identifies the problem, and include a website or other URL to provide more information if one exists (ie. a mailing list archive or other bug tracking system that may discuss the problem). When filling out the initial comments for the bug, be as verbose as you can so that the developers can quickly obtain all of the data they need in order to solve the problem quickly. By not providing as much data as you possibly can, you may be delaying the process to fix the bug; the more information present, the faster the bug can be resolved.