Zini wrote:
Edit: As the first component our tracker has been migrated to the new site: http://bugs.openmw.org/
Please register there. The old tracker is officially closed now.
Edited ...
We now have an issue tracker:
http://openmw.com/tracker/view_all_bug_page.php
Currently you need a separate account on Mantis. The forum account won't work.
For now we will use Mantis to track bugs and as a replacement for our previous roadmap page.
What goes not into the tracker:
- feature requests (we have a wiki page and a forum for them)
What goes into the tracker:
- unimplemented features, that are part of Morrowind
- bugs in already implemented features, that are caused by an oversight or a mistake during the implementation
- all kind of regressions
I suggest we use the following guidelines for the various fields in the bug report:
Taken from the mantis manual:
* New - This is the landing status for new issues. Issues stay in this status until they are assigned, acknowledged, confirmed or resolved. The next status can be "acknowledged", "confirmed", "assigned" or "resolved".
* Acknowledged - This status is used by the development team to reflect their agreement to the suggested feature request. Or to agree with what the reporter is suggesting in an issue report, although they didn't yet attempt to reproduce what the reporter is referring to. The next status is typically "assigned" or "confirmed".
* Confirmed - This status is typically used by the development team to mention that they agree with what the reporter is suggesting in the issue and that they have confirmed and reproduced the issue. The next status is typically "assigned".
* Assigned - This status is used to reflect that the issue has been assigned to one of the team members and that such team member is actively working on the issue. The next status is typically "resolved".
* Resolved - This status is used to reflect that the issue has been resolved. An issue can be resolved with one of many resolutions (customizable). For example, an issue can be resolved as "fixed", "duplicate", "won't fix", "no change required", etc. The next statuses are typically "closed" or in case of the issue being re-opened, then it would be "feedback".
* Closed - This status reflects that the issue is completely closed and no further actions are required on it. It also typically hides the issue from the View Issues page. Some teams use "closed" to reflect sign-off by the reporter and others use it to reflect the fact that the fix has been released to customers.
For the Severity field I suggest the following:
* trivial: A papercut-class problem
* minor: A minor annoyance, that can be worked around
* major: A major annoyance, that limits the usefulness/testing-scope of OpenMW
* crash: That should be obvious
* block: Can't release, until this is resolved.