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 some guidelines. Crucial part really are 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 the problem is the 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.

Bug Report Form

Bug report must be in the following form (see below).

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 videos 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)

Ok thanks ... some remarks from me:

• Bug Priorities should go in BTS Guidelines since only devs can alter it.
• The Bug Report Form must be adapted:
  • Project name(s): we've got categories
  • Project version: this is a released exe, so the version number is sufficient

I don't understand the meaning of the whole entry ... should it be adapted or is this just a proposal?

--Boecko 17:11, 21 March 2007 (CET)

This was an excerpt from the BI internal way to report bugs. We have to transfer/adapt it for the BTS, to make work easier for the BI devs. --raedor 23:13, 21 March 2007 (CET)

I suggest that boecko, reador, hoz......meeting in a voice chat in a regular manner, at least once per month. This here is to slow to tune the BTS to BI needs in an interactive way. I am pretty sure that much more ideas/demands Maruk/Suma maybe have in mind could be addressed in seconds and maybe agreed with boecko. If it is easy you have the change within minutes, maybe within the voice chat for testing.

To the Priority: The criteria are to much flavored by BI internals so that only a BI employee in the inner circle could set them correctly. In addition they would reflect only the BI point of view for their internal work, not the community demands. Hence I suggest to add another BI Priority Field which is NOT PUBLIC. This field can be set only by BI devs which maybe consider the Community Priority when selecting their own. Just because you know what happens when I find out that a bug I consider as Prio1 is set by BI to lowest Prio :-)

In a kind of MOU we need to ensure BI in a written way that this PRIVATE field(s) are not allowed to make public and knowledge from there must not be used for example in a moaning thread by persons which have access to the private fields like the admin. --INNOCENT&CLUELESS 08:58, 22 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)