Not logged inOpenClonk Forum
Up Topic Using the bugtracker

This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.

Post Reply
In Response to Newton
This is a short guide that should help understanding our workflow in the bugtracker. If everyone adheres to this guide, we will have a much better overview over the open bugs. I know that currently many bugs are not set correctly but lets work towards changing that in the future.

Setting the right bug status


To provide a better overview over the open bugs, here are the explanations of the bug statuses how we use them:

New
Incoming ticket. The Product Version field is filled in to indicate in which release the bug occurred. Leave empty and instead mention it in the description for some development version.

Feedback
We are awaiting some reply or additional information from the reporter or from some particular developer. Currently no action required from the (other) developers.

Acknowledged
Can be reproduced, the problem is clarified.

Confirmed
Enough information is supplied to just begin working on the bug: the cause of the bug and a way how to solve it is clear. For feature requests: Yes, will be done.

Assigned
Assignee is currently working on it or the assignee reserved himself an unimportant todo-like task. In both cases, the ticket is irrelevant for any other developers. If you know that X had been working on feature Y and this is a Y-related bug, do not assign it to him. Instead, you can put him on the list of users monitoring this issue to inform him about (updates) of this bug.S

Resolved
Done. The Fixed in Version field is filled in to indicate in which release it will be solved. There is an overview on the changelog page.

Closed
Issues that are resolved and tested to be resolved. Issues that were resolved for a published release can be assumed closed.

Importance


Developers (not reporters, please) can use the priority field to be able sort the bugs by importance. Here are some examples / rough descriptions of different priorities:

None
A nice-to-have feature or minor tweak that on the other hand needs quite some amount of work to resolve. These should be displayed at the end of the list as these are often not even bugs but suggestions how to make the game better.

Low
Minor issues that do not influence the game experience or issues that occur rarely for few people / under weird conditions. Features that make the game better.

Normal
Any other issues.

High
Issues that screw up the game experience: Crashes, problems with starting OpenClonk or working with C4DT, the website, etc. altogether.

Urgent
This priority is reserved for issues that are worse than a crashes. What is worse than a crash? Only something that is keeping us developers from working on it, e.g. blockers in the development environment. Or, let's say we want to release and discover that the build system is not working. Or that one particular issue is causing the release not to work correctly. Stuff like that.

Immediate
We don't use this category.

Must be resolved until


If one issue should be resolved before a certain version is released, regardless of it's priority, use the field Target Version. Issues that are tagged with a target version are displayed on the roadmap page. Thus, the bugtracker can be used to include tickets for features that should turn up in version X, not only bugs.

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill