Any control over priority?

[deady 0]

So browsing the bug tracker I come across:

http://bugs.armed-assault.net/view.php?id=2487

This is mostly one guy putting in his request for a new inventory system - but he has marked it as High Priority with Major severity.

With the current cheat and hacker situation (of which I could find no report that is classed high priority or above) is this really helping the devs?

I posted this here instead of on the report itself to avoid an argument in the BTS.

And this? http://bugs.armed-assault.net/view.php?id=2687

Major?

[.kju 3245]

Both issues corrected.

Right now priority and severity can be set by anyone i guess.

(Administrator here over at the CBTS, so i can do anything )

Both serve no real purpose right now as far as i can tell.

Definition "purpose":

any way which helps BI making this BTS more useful.

It's part of a more general discussion about the BTS.

I try to get it started by posting tomorrow in the according thread.

[ACF 0]

Q, could you please explain why this issue:

http://bugs.armed-assault.net/view.php?id=2337

has been downgraded to a feature request - again?

I can't really dispute a lowering of the the severity; after all, it's obviously not a major issue for many people. However, this isn't a new feature I'm asking for, it's a feature present in OFP that has been degraded in ArmA.

I'm pleased to see some updates to the BTS but it would be better if there were a few words of explanation for some of these mod changes.

[.kju 3245]

Hello, ACF

Thanks for talking the time to bring up this one.

First problem here is that i only read the description.

It doesn't mention that it worked by in OFP, right?

So for me it seemed like a feature request.

However if you add this info to the ticket, i agree that

it is actually a bug.

Overall personally i find the description much too detailed.

The description should be simple and short.

The detailed part is meant to be in the "Additional Information"

section.

A general problem here is also the steps to reproduce.

The BTS admins, like me, made the impression that adding a

sample mission is enough. Yet we still need these 5-10 steps in

the "Steps To Reproduce" description.

Otherwise BI cannot see how many effort is involved to review

the test mission. Just adding one doesn't tell a word about the

effort and time needed to see the issue.

In that case, a small sample video might help, but it is obvious

what you mean anyway i think. Still the easier you make it for

BI, the more likely you will see it changed / fixed.

We need to rework the overall handling of the BTS in various

ways. More on that in the following days.

[ACF 0]

Thank you, Q, for your reply.

I agree that the information in 2337 could be rearranged, the problem is that there is no option for the author to edit the issue as far as I can see. Are the BTS admins able to edit the issues? I don't see a problem with this as long as there's some feedback to the author to make sure the point isn't lost.

Personally, I don't think 2337 is really a 'bug' - ArmA unit behaviours have been designed and configured that way (for reasons I fail to understand). Then again, it's not a feature request because I believe that the engine can already do what is required. Against the benchmark of OFP, it's simply a configuration 'error'. My problem is that I have a little knowledge - I can make a reasonable guess at the problem but I'm not clever enough to actually solve it. If 2337 can be re-presented in a way that makes it more likely to get assessed then please PM me and I'll see what I can do to help.

My assumption was that the BTS admins would be acting as some sort of filter between the community and BIS, performing triage on the issues:

- Bugs: bits of the engine that are broken;

- Tweaks: things that the engine can do but configurations that are wrong or not as good as they could be;

- Features/wishes: things the engine can't do and, realistically, isn't going to do any time soon.

Someone then has to make the decision which bugs/tweaks to fix first on some sort of cost-benefit basis... but maybe it doesn't work like that.

Given all the config tweaking that's going on out there, I'm actually wondering if there's any benefit in having somewhere to submit 'fixes' rather than bugs? Why create problems when we can create solutions? People could post their clever config snippets with a brief descriptions of their effects, advantages and disadvantages. A knowledgable dev could then make a judgement as to its worth and choose to use it or not. So much work is already being done to 'fix' ArmA but it's probably being done many times over in dozens of 'ultimate realism mods'. Surely it would be better to try to channel that effort back into vanilla ArmA?

[.kju 3245]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">the problem is that there is no option for the author to

edit the issue as far as I can see. Are the BTS admins able to

edit the issues? I don't see a problem with this as long as there's

some feedback to the author to make sure the point isn't lost.

Congratz you have been promoted to updater.

(therefore you are now able to update existing issues)

By default anyone can just open issues and add notes.

I think the "problem" with being able to update issues is that one

is able to edit any issue's description. This might not be the best

default setting for everyone. We will have to discuss this. It's on

my list.

Quote[/b] ]My assumption was that the BTS admins would be

acting as some sort of filter between the community and BIS,

performing triage on the issues:

To some point it is like this. Yet this area needs much improvement.

The specific problem here is that, apart from my person, the

other two have almost no modding knowledge. Therefore cannot

jugde this. Engine knowledge is only present for BI itself.

So yes, the BTS admins are meant to filter the issues.

It is done right now on another level (quality of report, relation

etc), yet there is much room for improvement here.

Also more admins would be necessary, even if there are quite a

few people actively taking part at the BTS as well.

Thanks to you guys!

Overall we need a discussion with BI about the BTS itself.

There will be some progress on this topic today.

Quote[/b] ]Given all the config tweaking that's going on out there,

I'm actually wondering if there's any benefit in having

somewhere to submit 'fixes' rather than bugs? Why create

problems when we can create solutions? People could post their

clever config snippets with a brief descriptions of their effects,

advantages and disadvantages. A knowledgable dev could then

make a judgement as to its worth and choose to use it or not.

So much work is already being done to 'fix' ArmA but it's

probably being done many times over in dozens of 'ultimate

realism mods'. Surely it would be better to try to channel that

effort back into vanilla ArmA?

Excellent suggestion ACF.

Actually this idea is active work in progress of realization.

[ACF 0]

I've just dipped into the 'Voting - Ticket System' thread and formed the opinion that a bug that's been labelled as a 'metabug' is never going to be addressed, let alone resolved, however much extra work is put into it.

I can see the logic of this in terms of filtering out woolly, vague and non-specific reports. I further see how it relates to the importance Q attaches to 'steps to reproduce'. The problem I see at the moment is that the metabug label is very hard to remove.

Using 2337 as an example (again), the amount of waffling I've done to substantiate the problem seems to have obscured the point that it's [probably] a consequence of one identifiable bit of the config (where anim groups are mapped to behaviours). It was never meant as a generic 'everything about the AI is rubbish' report. Maybe the initial report deserved its metabug flag but the report has been refined a lot since. It's also an issue where it is, perhaps, easier to define the cause than the symptom.

In summary, I'm proposing that 2337 to be changed to metabug = no because it is a specific config issue. Even with my new 'updater' powers I can't change it!

As for all the other metabugs out there, I do think other reporters ought to have a chance to review and revise their reports to lose the metabug labels. I recognise that it would be a lot of work because reports develop in the notes. I don't know what the options are for granting permissions to update one's own posts and requesting a metabug status review.

Incidentally - and by no means the point of this post - the 'solution submission' approach would avoid the metabug issue because the fixes would be specific, the only judgement would be whether they are good or bad.

[.kju 3245]

Hello, ACF

Quote[/b] ]I've just dipped into the 'Voting - Ticket System' thread and formed the opinion that a bug that's been labelled as a 'metabug' is never going to be addressed, let alone resolved, however much extra work is put into it.

I can see the logic of this in terms of filtering out woolly, vague and non-specific reports. I further see how it relates to the importance Q attaches to 'steps to reproduce'. The problem I see at the moment is that the metabug label is very hard to remove.

Yes. You are right, maybe we even have to remove the metabugs completely.

You can check my ~ 11200 characters reponse and thoughts in that topic.

(I talk about metabugs at the very end)

Good thoughts and reasoning here mate!

2337 is changed to metabug = no, i think in this case it was

a fault even to the current/old concept anyway. Not sure why

boecko made it one.

We will see how we will proceed with metabugs in general.

Most likely most issue will have the metabug status removed.

The rest gets closed and made stickies as a summary of similar

issues (with their description etc all removed).

[xxbbcc 6]

I'd say keep the metabugs - they're very useful in seeing which issues are related, without adding such relationships to every single issue in a set of related ones.

I also agree with Suma, that votes on metabugs should be ignored, as metabugs are not bugs - they're simply helper tools to collect a set of actual bugs under one umbrella.

One thought on reproduction steps: while I consider them very important (I'm an engineer, too), with the scale of Arma and the unpredictability of the AI (which is of course a basic property of any AI to an external observer), it's sometimes extremely hard to reproduce a problem, especially for a user.

For example, when I report AI problems, I know very well that something is wrong, but it's extremely hard to reproduce the steps that led to the problem. I cannot reproduce a situation, when I get shot through a building, for example (although it did happen multiple times), but it's not an overly common situation. So the only thing I can do is to report the location/environment and generic conditions in the game, but nothing more.

So the expectiation to receive as clear repro steps as one would get with a piece of business software is a bit extreme, in my opinion.