Talk:BTS Instructions

Link on Bugtracker page

I've linked this page on http://bugs.armed-assault.net/main_page.php --Boecko 22:57, 16 February 2007 (CET)

Reporting the way BI can work with

Internal bug format used by BI and a some guidelines. Crucial part really is the repro steps without any "ANY" and "ALL" or "JUST PLAY THE GAME AND YOU SEE". Ideally a simple mission on intro island that instantly shows of the problem is best.

Bug Priorities

Anyone can set priority, however, final decision can be made only by Project Manager, Lead Programmer and QA Lead and they may readjust the priority as needed for the entire project.

Priority 1 (Critical)

Priority 1 is a critical problem that prevents any further progress with the project, all other work must be stoped immediately until this bug is fixed. Crashes and violations of technical requirement on a given platform also are criticial priority 1 problem.

Priority 2 (Very High)

Priority 2 means serious problem that must be fixed as soon as possible even out of order of normal work plans.

Priority 3 (High)

Priority 3 is an important bug that needs to be adressed.

Priority 4 (Normal/Default)

Priority 4 is a bug that would be nice to get fixed but if not the project still can be released. It can be also a design suggestion. This is a default priority so any bug without priority property set by responsible person is considered priority 4 issue. This is default priority because it is easy to set NR filters for this. Therefore for those who use NR filter like "!Close & AssignedTo==Ondra & Priority" to check priorities the topics with no priority property are currently as having the lowest priority possible.

Bug Report Form

Bug report must be in the following form (see below). Bug reports for engine goes only to bistudio.engine.bugs and only proven engine bugs by the leader of each project can be written to engine.bugs area otherwise you should only post it to <project>.bugs section.

Subject of the message should always contain descriptive bug title and body should give the following information:

Project name(s): A list of the projects this bug occurs in. This is obviously not necessary when you post the bug in the .bugs newsgroup of the corresponding project.

Project version: The version number of the project, which can be seen in the project's main menu or in the properties of the exe file. If no version is written, current version for time of report is expected.

Problem description: Short problem overview

Reproduction steps: as exact as possible, not assuming the person looking at the bug report knows any specific details about game environments, units etc.

Never post repro steps using words like Any, Most, ... Always describe one particular scenario.

Good: 1) Place M1A1 on Sara Eg60

Bad: 1) Place any tank anywhere on any island.

Comments: Your theory what could cause the bug or anything else you want to tell the engine team in relation to the bug.

Attachments: - screenshots or vidoes showing the problem - isolated mission for quick reproduction of the problem (recommended, even if it's just a soldier standing on a position)

e.g.:

Bug title

Version: 0.23.5010

Description:
<Description>

Reproduction:
[1] <Step 1>
[2] <Etc.>

 Occurance: 100%

 Comments: Any additional comments you may have for the bug.

--Maruk 14:51, 21 March 2007 (CET)

Severity

What are we going to do with the "Severity" option? Will this be handled as it is now, that regular reporters only file it under a default status, and then a sysop will assign it a priority (that's how I documented it for now)?

And I guess we will have to adjust our current priorities to the new classes. --Kronzky 20:19, 17 February 2007 (CET)

Priorities adjusted. Severity should be adjusted by sysops, as also priority. --raedor 13:46, 9 March 2007 (CET)

shouldn't we integrate the priorities on BTS Guidelines --Boecko 13:00, 12 March 2007 (CET)

We should, yes. ;) --raedor 21:40, 13 March 2007 (CET)

Confirmed

What does "confirmed" realy mean? Some people think it is something like Acknowledged, I think it is when fix is verified and the bug is confirmed to be fixed, therefore the bug is ready to be closed. --Suma 16:38, 19 March 2007 (CET)

That depends how you'll like to use it. There is nice summary here. I quoted it recently:

We use 'acknowledged' to confirm that a new issues has been reviewed and that it is indeed a bug and that it contains enough information to be reproduced/analysed. However, at this time we will not start work on it.

Once we start a new release and the issue needs to be addressed (in this release), its status will change to 'confirmed'. ....

--Boecko 17:03, 19 March 2007 (CET)