Bug tracker usage
From VCMI Project Wiki
Bug tracker usage
VCMI maintains bug tracker at [1]. All developers should be registered here and get proper access rights (can be granted by Tow or Warmonger).
Issue workflow
Typical workflow can be described with this table:
-> New | Once issue is reported it will be in "new" status. Note that for some categories issue will be automatically assigned to a specific developer |
---|---|
New -> Assigned | Developer who is interested in resolving this issue (or started working on it) should assign issue to himself |
Assigned -> Feedback | If information supplied by reported is incomplete its status should be changed to feedback for clarification |
Feedback -> Assigned | Once original reporter responds to an issue Mantis will automatically change its status back to resolved. Othervice (if clarification came from somebody else) this should be done manually |
Assigned -> Resolved | Once issue is resolved and fix has entered main repository (vcmi/develop on github) it should be marked as resolved by developer, "fixed in version" field changed to next release codename "0.next" and confirmation message should contain link to git commit fixing this issue. |
Resolved -> Closed | After reporter confirms that issue is resolved its status should be changed to closed. |
<any> -> Closed | If issue is won't be resolved by VCMI Team (rejected features, duplicates, user faults, etc) it should be marked as closed. |
Note on confirmed/acknowledged status: their usage is not clearly defined and usually used to:
- Acknowledged is used to indicate valid issues that won't be fixed soon ("I can confirm this but can't fix it in near future because ...")
- Confirmed is used to indicate that developer knows origin of a bug (usually used for issues with random reproducibility)