Bug List – ArmA: Armed Assault Talk

Bug Tracking System

As there is now "unofficial" bug tracking system running, containing all bugs from this page imported, I think we should consider closing this page and redirecting users to that system (check it at http://bugs.armed-assault.net/view_all_bug_page.php). An alternative could be to having some volunteers doing synchronization for those who prefer reporting bugs here, but I doubt anyone would be willing do that. (Off course, another alternative is the majority of the community may prefer bug tracking being done solely here, which I doubt, but if it is the case, we can reopen the page again and continue as it is now). Please, voice your opinion here. Until we decide, this Wiki bug list is protected and user cannot change it. --Suma 11:10, 14 February 2007 (CET)

I think the tracking system has a stronger implication that an official response will be given to each bug. As it stands, the wiki page is just a list. An official word stating the intention of the public listing/tracking of bugs could help (eg, BI have an internal bug reporting system and this is just a secondary). --Ceeeb 14:15, 14 February 2007 (CET)

As this is a community tracking system, there is no guaranteed response from us (yes, we do have other system we use internally). Its primary purpose is for the community to have a list of known issues, workarounds for them... However, as you can see in the bug history in the tracker, chance of getting response from us are quite high, esp. for fatal or major issues. --Suma 14:27, 14 February 2007 (CET)

Too bad there seems to be no edit feature for bugreports on boeckler.org. thus it's imposible to fix errors (wrong Category etc ) --bdfy

Oh it's there, It's just the access matrix, what prevents that (an Updater can do that). This could be discussed in the notes of the issue. IMHO it's in the responsibility of the assigned person whether the category fits. --Boecko

On the other hand, we can discuss the initial access right of users. --Boecko

I find the new list a lot more confusing especially the priories. But I can live with it. Should I lock the Biki bug list then? hoz

I tried to map the priorities to the BTS-priorities AND to severities. One (with manager access) can changethis on the fly (Filter given priority, "Update Priority" at the bottom of the page. --Boecko

Hoz, Boecko is trying to express that both priorities AND to severities can be configured to ones preferences - the priority descriptions are the defaults values of the mantis. also i think both priorities and severities should only be possible to get changed by the BTS admins - i think one can configure mantis that way.--WGL.Q 20:28, 14 February 2007 (CET)

Now i see - after several reports i became and updater and got edit option.--bdfy

Please, provide repro steps. They may be obvious to you from the bug description, but they often are not. Example of issue I would like to have repro steps for is http://www.boeckler.org/mantis/view.php?id=1914 --Suma 22:10, 14 February 2007 (CET)

OK. So what now? Shall we close the list here, and replace current content of the page with a link to the bug tracker and instructions page {other options are returning to using the Wiki page, or using both) --Suma 11:08, 21 February 2007 (CET)

My biased opinion ;) .. keep the BTS (close this list). There about 20 new registered people in the last week and people seem to have adoped it. There are 49 active users. --Boecko 11:24, 21 February 2007 (CET)

Question is whom do you ask? The community is pretty tiny atm. I personally can only work with a BTS, I had even problems to find your question in this looooooong list. What I can see is that more & more guys with scripting knowledge dropping TTs in the BTS so it seems to be accepted.--INNOCENT&CLUELESS 12:01, 21 February 2007 (CET)

I confirm - bug-tracker is much more comfortable then biki --bdfy

Same for me. I saw some comments on how complicated it was, but for me it's way easier to find what has already been reported, and to report something. Has well has having comments and dev feedback. --Whisper 14:22, 21 February 2007 (CET)

Definitely for closing the Wiki page, and forwarding any bug reports to the BTS. We seem to have just as many contributors/reporters there as we did on the Wiki. So it seems that people are already getting the hang of it.

What about the "wishlist" and the "bug or feature" page though? Should they be integrated into the BTS as well? --Kronzky 17:04, 21 February 2007 (CET)

Feature requests/change requests are in, but hoz closed TT with the reason "more a wish". Hence boecko created a new project called "ArmA features" and I moved the related TT there. The project was private to avoid confusion, I made it now public. The problem is that until now we did not discussed really the TT flow and responsibilities nor agreed on. So if we could agree that the SEVERITY "feature" means that it is not a bug we could use the project "Armed Assault" as usual and I could move the TTs back. We have anyway time since I guess that BI is so busy that they are not really open for resource consuming feature requests for the next weeks. I opened a TT in the project "mantis bts" where we could discuss the treatment of feature requests and close it if we come to an agreement http://bugs.armed-assault.net/view.php?id=1992 .--INNOCENT&CLUELESS 10:28, 22 February 2007 (CET)

Since it seems that we're way past the "point of no return" regarding the BTS system, I've updated the bug page now.

Once we've decided on how to handle requests and bug/feature determinations we should update that paragraph as well. --Kronzky 17:13, 22 February 2007 (CET)

Voices against

This is a little late, but I was not able to participate in the discussion up until this point. I was in the process of preparing a comprehensive argument against. I see that this has gone forward, but I would like to post my unfinished argument for the record (chiefly because I have already spent a lot of time on it). --Plaintiff1 01:38, 15 February 2007 (CET)

I'm not completely sure what this bug tracking system is hoping to achieve beyond an increased level of automation. I'm not entirely convinced that a list for bugs requires such an automation or the resulting increase in complexity and diffusion of community resources. Such a programme would be no more useful than any other list.--Plaintiff1 01:52, 15 February 2007 (CET)

We are not tracking bugs for BIS, but rather, listing what the community perceives as bugs. If I am not mistaken, the discressionary priority we assign the bugs is more or less a way of sorting the information beyond the pragmatic categorical sorting. Without BIS staffers minding the list, these methods of sorting the information is largely arbitrary and are the result of a educated guessing game. This list isn't even usable as a list of bugs: It is more like a collection of reports from beta testers, not a collection of bugs for them to act on. They need processing to actually turn them into bug reports they can use. We are simply throwing down some information that we hope will be useful for BIS and for other community members in their troubleshooting efforts (i.e. to confirm the responsibility of a known bug for a certain problem behaviour).--Plaintiff1 01:52, 15 February 2007 (CET)

As for the community's interests, I think that adding another superfluous protocol to learn in another system on yet another page is like whimisically adding a fifth, suspended, steerable wheel to a concept car- however shiny and feature-laden it is, there isn't a community side need for it. It would just add bulk and complexity to a larger community resource that is only yet finding its legs. The current resource is easy to use, easy to find, easy to interact with, easy to discuss, and easily policed. I think that if this bug list is moved into a bug tracker format that it should be clearly stated that this move is for BIS's benefit and why, as I cannot see any end-of-the-day benefit for the community. We are not trouble shooting, solving or interacting with the bugs in any way other than finding them and listing them.--Plaintiff1 01:52, 15 February 2007 (CET)

Ease of use

The voices of the proponents for a community bug tracker seem by-and-large programmers. These are people who are already familiar with the concept of a bug tracker. Some people express a hesitation to learn the Biki based on their fear of the alien protocol. Let us not lump another level of complexity onto the pile. To use another automotive metaphor, using a tracking program for the bug list is like having a 600 horsepower car. What do you need it for? Only enthusiasts would want such a thing and a small percentage of those would even be able to make use of it. There are features within the bugtracker that simply aren't of any use to the person that this list was designed for- the average community member seeking to share his or her knowledge and experience with BIS.--Plaintiff1 01:38, 15 February 2007 (CET)

As I am programmer, I cannot be unbias on this. However, submitting bugs to Mantis seems much easier that writing them to Wiki. There is plenty of people you never edit Wiki, only browse it. I suppose for them filling web forms (which is what Mantis does) is much easier than getting familiar with the Wiki template syntax to be able to fill in the record. The Wiki Edit feature is far from easy to use, esp. on long pages. --Suma 09:11, 15 February 2007 (CET)

I switched on the simple bug report in mantis (i disabled it before). Try it --Boecko

Out of Plaintiff1 comments I read the fears that 1.) the biggest part of the community would not be able to use mantis and hence would not report bugs because of this and 2.) the maintenance and management of the bugs would cost more time then it safes. To 1.): Someone who is able to speak/write english (if not his mother toungue) is usually able to assemble a telling TT in mantis. For those which are not able to write english it is possible to write the description of the TT in his language, the mantis managers will try to translate into english without loosing the sense of the original TT (we might have problems with mandarin :-) ). Like we did it for WGL there is always the need for the managers to browse the forum as Q created it here for WGL bug reporting: http://ofpc.de/wargames/e107_plugins/forum/forum_viewforum.php?7 to pick up some bug reports out of some discussions. But to keep track if/how/when the bug is fixed - there I do not see any other option then a BTS. So Plaintiff1 is right if he says mainly BI & experienced developers/scripters/addonmakers taking the most benefit in the 1st line - but what is wrong with that, usually they can deliver already a very good pre-analysis of the issue and if they are served all other community members would participate from the more reliable engine and more excellent content in the 2nd line. Btw from experience also weekend gamers where able to drop telling tickets in the WGL BTS bugzilla we used there initially and later in trac and those two are not as user friendly as mantis in my opinion. To 2.) A TT system safes time in the long run by ensuring that no issue is forgotten, several TTs with the same root cause could be mapped together by the developer, developer could send the TT creator a request for further information...Let's try and see what happens during the regression testing of 1.04/1.05 --INNOCENT&CLUELESS 10:17, 15 February 2007 (CET)

To clarify 1, my point is not that people will be unable to learn, it is that they will be [i]unwilling[/i] to learn. Reference this topic for examples of people who are hesitant to learn how to contribute to the biki. The point there is that people are already having to learn very rudimentary wiki markup in order to contribute to the biki. Fastening on this other appendage adds complexity and more learning, and in my experience, community members can be quite lazy. Moreover, we have a number of people who are already learning wiki markup in order to contribute on other pages. They could use that knowledge to contribute here, and the people who learn some wiki markup in order to contribute on the buglist then have the skills to make other contributions to other areas of the biki.

To clarify 2, I'm not saying that programmers will see an added benefit to the BTS. I simply do not see what benefit there could possibly be. You find a bug that has been solved, you mark it as solved no matter what you are using to track them. This could be accomplished quite adequately with a word processor. I'm not saying that the BTS itself is too complicated for people to use, it is that it adds too much complexity to what is essentially a list of items, NOT a dynamic bug tracking environment. Programmers who are familiar with a BTS will undoubtedly see them as useful tools- indespensible tools for tracking bugs between multiple programmers seeking to ameliorate those problems. This is not what we are doing here, though. We are maintaining a list of problems for someone to glance at now and again. Noone here is fixing anything. I've been maintaining the list for some weeks and I must say that I find the wiki perfectly adequate. --Plaintiff1 11:20, 15 February 2007 (CET)

1 seems to me to be a dead-end argument.

Actually, the ability to use the BT builds upon knowledge that has been built through regular websurfing, and little else. In other words, i can't see this as an argument to keep the biki page.

Point 2 - the BT will allow automatically mailing the creator of the TT, as well as any others who has set themselves as interested in a bug, to say that we need more information, to say that this has been solved, etc. We have the ability to pretty much discuss the entire bug. "Adding ones 2c worth" is easier than with a wiki.

One last detail - It's true that the BT can easily take some more manpower than the wiki, but we're on it already. The wiki may be adequate... But this is probably better. --MaHuJa 15:46, 6 March 2007 (CET)

Defining Priority

⚠

Bug priorities To make it easier for BI people to see important bugs, we introduced bug priority templates. Add new bugs with priority 0. Only BigDawgKS, Plaintiff1, the BI staff, and the wiki sysops are allowed to set priorities to values higher than 0.

⚠

BTS - Definitions We need to adjust these levels to the severity options in the new BTS!

How does one define a priority?

Priority immediate

• Any issue that causes a CTD (crash to desktop) during a normal gameplay. CTD using mission or content creation are not considered priority 1, esp. when caused by scripting and it is possible to avoid the CTD by not using the construct triggering it.
• Any issue that prevents the game from loading.
• Any issue that prevents installation of a patch
• Any issue that decreases performance significantly, up to the point of making the game unplayable. (especially if this was working better in previous ver)

Priority urgent

• Issues that prevent MP game play
• Any other issue that causes a CTD, including mission scripting.
• Any issue that prohibits game play as per design
• Issue that prevent the operation of a vehicle/unit/object as designed. (can't get in vehicle, helicopter moves incorrectly)
• Issues that allow cheating. (example: sniper sites allows a person to see through walls)
• Significant performance issues (low fps in situation where decent fps would be expected)

Priority high

• Annoying behavior, such as Repeated voice command.
• Sounds that aren't working as they were designed.
• Collisions in models which affect game play. (such as doors which prevent entry, invisible wall)
• AI not doing as they should/designed. (stuck, not running for cover, etc)
• Mission issues that prevent the completion or playability.
• Scripting commands that do not work as intended and/or at all

Priority normal

• Any issue that causes an in game error (missing paa, missing name)
• Graphical Nuisances (missing textures)
• Annoying collision issues.

Priority low

• Missing sounds which maybe were never intended.
• Spelling errors
• Minor mission issues that don't affect the game play