Latest Posts

Changes in TriagingBugs

Editor Comment

added information about the official tags


Revision Differences of Revision 2

#Triaging (working with) bugs ¶

This section will describe how to triage bugs, or in other words help out with bug reports. This is in a nutshell the process of checking if a reported bug is reproducible (i.e. following a set of instructions will always demonstrate the issue), adding extra information, changing status or adding tags etc. The purpose of triaging bugs is to help the developers and make it easier for them to fix the problem. All you need to get started is to register on launchpad, where the Widelands bug tracker is. ¶

###Note ¶
Please note that this can be considered work in progress, so more information may be added, edited or split out if it makes sense to create a new page. ¶


##How you can help ¶

To contribute with bug triaging, there are some fairly easy things you can do. This will mostly consist of confirming or improving bug reports. For some options you need to be a member of the Widelands dev team, but most actions are available to anyone. ¶

##Confirming bugs ¶

This is perhaps one of the most important element about bugs; the current status. When looking at various bugs, you can see that they have different statuses. Common statuses are: ¶

New (all bugs reported will initally have this status. This means these bugs may not even have been looked at by someone other than the reporter!) ¶

Confirmed (someone other than the reporter is having the same problem) ¶

In Progress (someone is working on this) ¶

Fix Commited (the issue have been fixed in trunk/development version of Widelands) ¶

Fix Released (the issue has been fixed in an official Widelands release) ¶

(there are also other statuses) ¶

When a bug is reported, the status defaults to new. Currently, this means only the reporter is known to experience this problem. It is not sure what is causing it nor if others are affected by it. A bug is considered confirmed if more than one person is experiencing the same problem. To confirm a bug, read through the description of the bug and see if you can reproduce the problem. Most good bug reports leaves instructions for how to trigger the problem. For instance: ¶
1. Start the game. ¶

2. Click the button marked "New game" ¶

3. The game crashed. ¶

All you need to do is follow the instructions, and see if you have the same result. If you do, you can mark the bug as confirmed. You can do this by clicking the yellow exclamation mark next to the current status and select "Confirmed" from the list. As always when you change status, you should leave a message stating why you changed it. In this case, something like "By following your instructions, the game crashed here as well." should be sufficient. You can also add additional information such as which operating system you are running, in case the crash is limited to certain platforms or post error messages if you saw any.


##Tags ¶

Tags are a nice way to mark bug reports which covers the same area. By having some way to collect all the bugs affecting, for instance the editor it gets easier to find these bugs later on. This can be a developer who wants to work on the editor and want to know what needs to be done, when you want to reference an older bug in discussion because it deals with the same issue, or if you want to mark a new bug as a duplicate of an older one. ¶

Widelands has some official tags which should be used, and some unoffical ones in addition. You can see the current tags for a bug report just beneath the bug description (above the first comment). To add a new comment, click on the yellow exclamation mark and type in the tag you want to add. If you want to add more than one, add a space between them, for instance "crash editor" which will make it available for people searching for crash and editor, while "crasheditor" would only be found by people searching for that exact phrase. ¶

Most of the tags are straight-forward and easy to understand. Below are a list of the tags and a short description for each. Note that there may be some overlap between the different tags, and more than one may be relevant for a particular report. ¶

###Official Widelands bug tags ¶
atlanteans - affects the Atlantean tribe, buildings or workers ¶

balancing - deals with balance issue, issues which may give one tribe an advantage over the others ¶

barbarians - affects the Barbarian tribe, buildings or workers ¶

buildsystem - related to the compilation and build process of Widelands ¶

campaign - affects one of the campaing maps ¶

cmake - issues related to building Widelands with cmake. See also buildsystem ¶

computerplayer - problems with the computerplayer, anything affecting the AI players. ¶

crash - this bug makes Widelands crash. Anything that triggers a crash should be marked with this. ¶

descriptions - ¶

economy - dealing with the economy and wares ¶

editor - any issues related to the map editor ¶

empire - affects the Empire tribe, buildings or workers ¶

gamedata - ¶

gameplay - ¶

graphic - anything visual such as workers, buildings, immovables ¶

internationalization - ¶

locales - ¶

lua - anything related to lua scripts/scripting ¶

military - issues with soldiers, combat or anything military-related ¶

multiplayer - bugs which occured or are only triggered when playing multiplayer ¶

network - ¶

performance - ¶

savegame - anything dealing with saving and loading games OR bugs where a savegame have been attached to demonstrate a bug ¶

scenario - ¶

scons - ¶

statistics - ¶

ui - short for User Interface, covers anything the user interacts with such as buttons and menus ¶

windows - ¶

worker -