[AS INTENDED] Razbam - Moving genuine bugs to resolved

[Hawkeye_UK]

Dear ED - hopefully Nineline / Bignewy will pick up on this.

As a customer of ED please note once again we are beginning to have issues with Razbam.  Genuine bug reports are getting marked as resolved when they are not correct.

 

AS an example you will note there is an issue with the rose compass of the TGP.  It constantly aligns in relation to the aircraft nose not the position on the ground track (as it should).  This makes it a nightmare for CAS work when operating with ground tac commanders or indeed talking with other flight members. 

 

Apologies for reaching out but its getting to that stage again where they are just trying to reduce the bug schedule without actually resolving.  We even got told that this was as per SME (which is incorrect, its clearly (or hopefully) a communication issue as the current implementation is not how it works in real life).

 

What was the outcome of the internal review following the fractions with the community last year? What is the sign off process now as clearly currently something is broken in the quality and authenticity control process.

 

Please can you discuss within ED and Razbam and report back.  Greatly appreciated just trying to move the development in the right direction.

 

Thread post here 

 

Edited February 19, 2021 by Hawkeye_UK

[Hawkeye_UK]

Guys just to be clear I do not want this thread to turn into a Razbam bashing exercise or a critique of their business model (its been done to death last summer) or time taken for new modules or old ones to be finished.  What i would like is just to raise awareness with ED on the specific issues of community (genuine) bugs being reported and them marked as resolved. 

 

Just trying to pre-empt posts on this thread going forward.

[Flagrum]

There are actually several Bug Reports that are tagged as [future implementation] but moved to "Resolved". I understand "future implementation" as "yes, it is not working right now, but we will make it work some day" and thus it is still an open issue, it is not "resolved".

[Dr Zaius]

Surely then this would be easily fixed by creating different folders for both [Resolved] and [Future Implementation] and separate the categories from one another, unless of course your suggesting there’s something more sinister at play here?

 

I say this because I’ve encountered a level of misunderstanding from Razbam recently that was so frustrating I started to believe it a deliberate ploy to ignore the bug I was trying to report - without a proper understanding of what the issue was my post was marked up as [User Error] and moved to [Resolved] where further dialog all but ceased and only got moving again after both myself and others re-explained the issue over & over and kept calling Razbam out to take another look at it, only then did they finally understand and moved the post from Resolved section and back into the Problems & Bugs.

 

The point then I guess I'm trying to make is that with most things in life some level of perseverance and patience is required, I totally get its super frustrating when you feel ignored an/or misunderstood and know its made worse because ultimately you’re doing this to help them out as much as you want it fixed for yourself.

 

I don’t want to play devil’s advocate but there a lot of factors at play here, however I do believe that lots can be done to improve the situation we’re all in so if getting ED involved is the only way to push for a better product then so be it, will be interesting to see what they make of it all.

 

Good luck!

 

[RAZBAM_ELMO]

Not sure where the confusion is then with my labelling and sorting system. 

 

I removed a couple of comments here that were off topic and not adding to the conversation.

 

A bug has to deal with something that is in or has been implemented. If it is not, then there is no way for it to be a bug. If I leave that FUTURE IMPLEMENTATION in the BUGS section then it constitutes that it is in or its not functioning correctly. By it being in the RESOLVED section, it has been acknowledged and the argument is nullified. Keeping it in the bugs section is just clutter and gets in the way of me seeing what is reported, and what needs attention.

[wowbagger]

Case in point.

[Hawkeye_UK]

19 hours ago, RAZBAM_ELMO said:

Not sure where the confusion is then with my labelling and sorting system. 

 

I removed a couple of comments here that were off topic and not adding to the conversation.

 

A bug has to deal with something that is in or has been implemented. If it is not, then there is no way for it to be a bug. If I leave that FUTURE IMPLEMENTATION in the BUGS section then it constitutes that it is in or its not functioning correctly. By it being in the RESOLVED section, it has been acknowledged and the argument is nullified. Keeping it in the bugs section is just clutter and gets in the way of me seeing what is reported, and what needs attention.

 

Elmo,

 

It is not future implementation - the rose compass is already in the TGP feed to the MFD.  Your statement is incorrect.

 

It has been coded and implemented incorrectly.

 

This is a bug as its already been implemented by using your argument, how can it be resolved and nullified - to say the latter is pure nonsense.  How can this be clutter?

 

If your SME is claiming the the current representation of the data feed is correct - he is mistaken.  I mentioned this as it was stated on one of the threads that it was as per SME.  

 

This need's resolution and i would suggest a review of how you handle bugs.  Be under no illusion that moving issues to resolved was part of the historical problem with the fracture last year.

 

Many thanks.

 

 

 

 

Edited February 7, 2021 by Hawkeye_UK

[RAZBAM_ELMO]

And like I mentioned in both of those. The TPOD was being updated to Gen4 standards. I did not say that the SME found the BEHAVIOUR to be wrong but that everything was in the correct POSITION and ORIENTATION and did mention in both of those that further refinement would occur at a later date when all of the sub systems were implemented for the Gen 4 pod. 

 

Again, its not yet properly implemented because there are more changes and functions being added so when those are added and implemented then the entire system can be refined. I appreciate your concern but how I label, organize and sort will  continue as such. If I have 50% saying do it this way but the other 50% saying no do it the other way then there is no clear indication and my decision is based on RAZBAM's needs to collect and add bugs to our internal tracker ( which happens to be me doing this job at the moment). If you don't like that aI label an incorrect feature or request then that's your opinion and you are entitled to such, but I do everything for a reason. Most probable reason is that its known but not being worked on yet or is not yet tied into the aircrafts systems.

 

So in relation to the N Arrow, it was reported, I was told its not fully implemented yet but will be at a later stage because of its priority in the grand scheme of things. So its a FUTURE IMPLEMENTATION to be worked on at a later stage.

[Fri13]

On 2/7/2021 at 2:12 AM, RAZBAM_ELMO said:

A bug has to deal with something that is in or has been implemented. If it is not, then there is no way for it to be a bug.

 

While you are technically correct that if there is no code, then there can't be a error in the code that makes the code non-working.

But, the bug section is the general one that includes everything from a translation errors, the texture problems, the 3D model errors, the missing features, the wrongly implemented (yet code is working correctly) features etc.

 

That is the BUG in layman language these days.

 

If there is a missing feature that belongs to the aircraft, then it is a bug report and it is not to be moved away until the feature is implemented and users can download it and use it. As long bug exists, bug report belongs to stay in the list of open bugs.

 

On 2/7/2021 at 2:12 AM, RAZBAM_ELMO said:

If I leave that FUTURE IMPLEMENTATION in the BUGS section then it constitutes that it is in or its not functioning correctly.

 

No it doesn't. It just informs that that report is reacted, but it is not yet fixed/implemented/corrected. That is the idea of the whole bug reporting system that if the report is valid, then it stays in "Open Bugs" section, until it is solved and confirmed by the users and only then it is to be moved to "Resolved Bugs".

 

On 2/7/2021 at 2:12 AM, RAZBAM_ELMO said:

By it being in the RESOLVED section, it has been acknowledged and the argument is nullified.

 

How it is nullified? The report is valid, it exists and it has not been fixed?

When the person responsible for managing the bugs moves bug reports that are valid (and unresolved) to resolved directory, it is completely wrong! They are not fixed, they are not usable, they are still missing, they are still wrong what ever the bug report is about. Not until the bug is properly fixed/dealed and the update has been released for the users, only then can the bug be marked as "Resolved" and moved to corresponding category. Until then it is a open bug report, and it is reminder for everyone that it is not yet done.

 

On 2/7/2021 at 2:12 AM, RAZBAM_ELMO said:

Keeping it in the bugs section is just clutter and gets in the way of me seeing what is reported, and what needs attention.

 

Speaking about the clutter:

 

 

Anyways, it is critical and correct that any bug report that is valid (confirmed) and is not fixed, stays in the open bugs section even when the developers has it in their internal To-Do list.

Bugs section is not a information table that is used to "Yes, we acknowledge this, now go away....".

It is about being a public, listing of all the features, errors and mistakes that are to be resolved in the future. You can mark it "Confirmed" instead and then write the reply to the thread that what is the schedule, timetable or future plans, but never move the report out of the bug section until fix is on the users hands and they have confirmed that bug is fixed.

 

Otherwise there happens the same thing as with the last update where the analog clock shows still a ZULU time, even after it was in the update patchnotes marked as "FIXED".

The idea of the closed beta tester group is that every single one of them will go through every single bug report that is to be marked as "FIXED" and every single one is required to confirm all of the listed bugs to be properly fixed. Then that list can be given to you that confirmed bugs are confirmed to be solved so you can gather the addresses for the bugs and be ready to mark them as solved when patch is released by asking bug reporter to confirm that update fixed it.

 

Bug reports management is time consuming task, there is no time to chat in the Discord or Facebook but all the time is suppose to be put on the bug report management here. It is about tight cooperation with the closed-beta testers and get them as well test every bug report that is opened and communicate with the community here that what is bugs state.

It is socializing with the people and work between programmers and the end-users and keep everything tidy and clean, but pushing valid bug reports to "Resolved" is just completely wrong method.

[Hawkeye_UK]

zero response @Fri13.  Couldn't agree more call me cynical but its also a very good way of hiding issues and on appearances for anyone superficially checking the forums be it new customers (as many do prior to purchasing a module) or senior ED management having a quick synopsis of customer feedback/bugs.

 

Strange how Razbam are the only 1/3 party to take this strange approach in "order to cut down on clutter".  It's a total farce to be honest.

[RAZBAM_ELMO]

On 2/9/2021 at 11:03 AM, Fri13 said:

 

While you are technically correct that if there is no code, then there can't be a error in the code that makes the code non-working.

But, the bug section is the general one that includes everything from a translation errors, the texture problems, the 3D model errors, the missing features, the wrongly implemented (yet code is working correctly) features etc.

 

That is the BUG in layman language these days.

 

If there is a missing feature that belongs to the aircraft, then it is a bug report and it is not to be moved away until the feature is implemented and users can download it and use it. As long bug exists, bug report belongs to stay in the list of open bugs.

 

 

No it doesn't. It just informs that that report is reacted, but it is not yet fixed/implemented/corrected. That is the idea of the whole bug reporting system that if the report is valid, then it stays in "Open Bugs" section, until it is solved and confirmed by the users and only then it is to be moved to "Resolved Bugs".

 

 

How it is nullified? The report is valid, it exists and it has not been fixed?

When the person responsible for managing the bugs moves bug reports that are valid (and unresolved) to resolved directory, it is completely wrong! They are not fixed, they are not usable, they are still missing, they are still wrong what ever the bug report is about. Not until the bug is properly fixed/dealed and the update has been released for the users, only then can the bug be marked as "Resolved" and moved to corresponding category. Until then it is a open bug report, and it is reminder for everyone that it is not yet done.

 

 

Speaking about the clutter:

 

 

Anyways, it is critical and correct that any bug report that is valid (confirmed) and is not fixed, stays in the open bugs section even when the developers has it in their internal To-Do list.

Bugs section is not a information table that is used to "Yes, we acknowledge this, now go away....".

It is about being a public, listing of all the features, errors and mistakes that are to be resolved in the future. You can mark it "Confirmed" instead and then write the reply to the thread that what is the schedule, timetable or future plans, but never move the report out of the bug section until fix is on the users hands and they have confirmed that bug is fixed.

 

Otherwise there happens the same thing as with the last update where the analog clock shows still a ZULU time, even after it was in the update patchnotes marked as "FIXED".

The idea of the closed beta tester group is that every single one of them will go through every single bug report that is to be marked as "FIXED" and every single one is required to confirm all of the listed bugs to be properly fixed. Then that list can be given to you that confirmed bugs are confirmed to be solved so you can gather the addresses for the bugs and be ready to mark them as solved when patch is released by asking bug reporter to confirm that update fixed it.

 

Bug reports management is time consuming task, there is no time to chat in the Discord or Facebook but all the time is suppose to be put on the bug report management here. It is about tight cooperation with the closed-beta testers and get them as well test every bug report that is opened and communicate with the community here that what is bugs state.

It is socializing with the people and work between programmers and the end-users and keep everything tidy and clean, but pushing valid bug reports to "Resolved" is just completely wrong method.

Again this is a matter of your opinion and how you feel it should be done while I am the one attending to it. I have made attempts to de-clutter old posts or merge them into one but recieved blow back from people on it so until the majority of active implemented systems bugs are cleared I will not be adjusting or removing any of them and ones that are not yet implemented I will put into the resolved section as I see fit. 

[Fri13]

Just now, RAZBAM_ELMO said:

Again this is a matter of your opinion

 

It is not matter of my opinion. It is matter how the bug reporting is done in the industry so the people can actually keep a valid track of progress.

[RAZBAM_ELMO]

2 hours ago, Fri13 said:

 

It is not matter of my opinion. It is matter how the bug reporting is done in the industry so the people can actually keep a valid track of progress.

there is not a standardized method, each company is free to do things they want. We are our own company. Agin, this is your opinion that it should be done in the usual industry way.

 

For instance, lets have a look at the MiG21 BUGS SECTION

 

 

and now lets compare our MiG-19 bugs section

 

 

To me, that is a nightmare and a half seeing almost over 200 posts in a single thread which could be RESOLVED or REPORTED. As a user with a problem, if I want to find a solution to a bug, would I want to sift through  want to go through 2.2K+ posts to find a solution OR would I not look at the RESOLVED section to see if my problem has been fixed previously or/ then go to the reported section to see if it has already been reported?

 

And from a moderators standpoint. Tracking an active bug vs ongoing conversations off topic how easy do you think it would be for me to find a topic to reference?

 

[tech_op2000]

@RAZBAM_ELMO Hey, since your actively posting here, can you find my bug i accidently posted in the general forums and move it to the appropriate bugs section? 
 

 

[Fri13]

2 hours ago, Hawkeye_UK said:

Couldn't agree more call me cynical but its also a very good way of hiding issues and on appearances for anyone superficially checking the forums be it new customers (as many do prior to purchasing a module) or senior ED management having a quick synopsis of customer feedback/bugs.

 

Did not want to say it so directly.

When a customer comes to forum and is checking the bug section that what features are missing or broken, they can't get a truthful overall picture of the product state.

Then they need to move to "solved bugs" section that is filled with unsolved reports or bug reports that still exist after a patch, among the reports that has been solved.

 

2 hours ago, Hawkeye_UK said:

Strange how Razbam are the only 1/3 party to take this strange approach in "order to cut down on clutter".  It's a total farce to be honest.

 

Not total farce, not yet. But it can happen very easily when communication management is purposely done badly.

[Mr. Big.Biggs]

14 minutes ago, RAZBAM_ELMO said:

there is not a standardized method, each company is free to do things they want. We are our own company. Agin, this is your opinion that it should be done in the usual industry way.

 

For instance, lets have a look at the MiG21 BUGS SECTION

 

 

and now lets compare our MiG-19 bugs section

 

 

To me, that is a nightmare and a half seeing almost over 200 posts in a single thread which could be RESOLVED or REPORTED. As a user with a problem, if I want to find a solution to a bug, would I want to sift through  want to go through 2.2K+ posts to find a solution OR would I not look at the RESOLVED section to see if my problem has been fixed previously or/ then go to the reported section to see if it has already been reported?

 

And from a moderators standpoint. Tracking an active bug vs ongoing conversations off topic how easy do you think it would be for me to find a topic to reference?

 

Dude, it’s your company. Tell him to get lost and get back to running your company. 
Wtf? 40 bucks and people think they are the majority shareholder! Op stated his case, you explained your methods. The rest is on him. What a waist of bandwidth! 

 

[netizensmith]

This entire disagreement can be solved easily and immediately by renaming the "RESOLVED" section to "RESOLVED and FUTURE ENHANCEMENTS". I see @RAZBAM_ELMO's point on this; it's not a bug if it wasn't even supposed to be in the module yet.

[Fri13]

12 minutes ago, RAZBAM_ELMO said:

there is not a standardized method, each company is free to do things they want. We are our own company. Agin, this is your opinion that it should be done in the usual industry way.

 

There is no ISO standard if you so try to go talk about it. But there is a de-factor standard that is based to how to do properly the documentation, reporting and even management.

 

Yes, every business can do how ever they want, but if they go and do it badly, they are to blame only themselves when they get in the trouble.

And Razbam got in the trouble, in big trouble just last autumn. What you were hired to fix.

 

Does it require reviewing again by the ED?

 

12 minutes ago, RAZBAM_ELMO said:

 

For instance, lets have a look at the MiG21 BUGS SECTION

 

 

and now lets compare our MiG-19 bugs section

 

 

To me, that is a nightmare and a half seeing almost over 200 posts in a single thread which could be RESOLVED or REPORTED.

 

Yes, to you it can be a nightmare... For others it is more efficient way and truthful.

 

12 minutes ago, RAZBAM_ELMO said:

As a user with a problem, if I want to find a solution to a bug, would I want to sift through  want to go through 2.2K+ posts to find a solution

 

Hold on.... shift through a 2.2K posts to find a solution?

What argument is that? Really?

 

If you have a problem with the gun sounds disappearing since last update, why would you go to browse bug reports about weapons, avionics, or missions and campaigns?

 

And if someone does have a problem in procedure, that is not a bug report, that is a common discussion "How do I....?" instead "bug". There shouldn't be searching solution for a problem in bug section, it is there to check out that is there problem in the code that developers needs to fix. Not to go searching "Why doesn't my gun work when I have RPM 55% and nozzles angle 82!?!?!?".

 

 

12 minutes ago, RAZBAM_ELMO said:

OR would I not look at the RESOLVED section to see if my problem has been fixed previously or/ then go to the reported section to see if it has already been reported?

 

Why would you look RESOLVED section for a bug report if you want to know is it already reported?

If you have a bug like a gun sight doesn't point where the bullets lands. Why do you go searching "Solved bugs"?

If you have a bug that TPOD compass points completely wrong direction, why would you look "is it already fixed" from "Solved" part when you have it?

 

First thing to do is to update to latest version, check does it still exist. Then if it exist and you want to report the bug, you go to "Open Bugs" listing. There you do quick check that is there a report about it or not. If you don't find something there, then you fill a bug report.

 

There is no reason what so ever to go "Resolved" section to find out is a bug fixed.

 

12 minutes ago, RAZBAM_ELMO said:

And from a moderators standpoint. Tracking an active bug vs ongoing conversations off topic how easy do you think it would be for me to find a topic to reference?

 

That is what the labeling is for.... Why the bug reporting systems has own mechanism to easily keep a track that what is open and what is closed.

When you put a label "Closed" or "Solved" then it means that it is done, completed and it can be moved to "Resolved" section. But before it gets there, it requires that others will confirm that bug is fixed and doesn't exist anymore. That is as well part of the bug reporting that the reporter comes back to check is it fixed and if it is, informs "update XYZ fixed this".

 

When "FUTURE IMPLEMENTATION" tag is put and bug is moved to RESOLVED section, it is away from the open problems in the current version listing.

When you get a bug report, you link it to the internal material if you use such. When the developer has made the fix, it is marked as to be fixed in patch XYZ. When the patch is out, it is checked that is it fixed and if it is confirmed by others who had the bug, then it is marked as fixed and can be moved to RESOLVED section.

 

If you have system where one side is OPEN and then other side with CLOSED, it is wrong to have OPEN mixed with CLOSED.

Instead that, put all to one basket and then simply tag them "OPEN" or "CLOSED" as confirmation. Posts that doesn't have a tag are NEW, unconfirmed ones. Until someone else (anyone else from the community) can as well confirm it, what means should be tagged as "OPEN" until solved.

 

This is your system, [Problems and Bugs] and [Resolved Bugs] and it is same as [OPEN] and [CLOSED].

Why are OPEN reports moved within CLOSED section without fix?

(Why are Unsolved reports moved among Solved?)

 

This is really a very simple To-Do list management.

[  ] Buy Milk

[  ] Print the daily report and map it

[  ] Swap the bathroom light bulb

----------------------

[x] Buy bread

[x] Buy light bulb to bathroom

[x] Change the printer ink cartridge

 

 

What has been done and what has not been done are very easy to see.

Even when something is known that it is to be done in the future, it stays NOT DONE until it is actually done.

If someone ticks "Buy Milk" as DONE because in the future they are going to buy the milk when they go out.... Where does it lead to?

 

The others does it different style by using categories. They keep the CLOSED and OPEN in the same sub-category. But they might not have added tags there that informs is it OPEN or CLOSED.

 

https://forums.eagle.ru/forum/320-bugs/

 

That is fairly easy to as well to look by the tags.

 

REPORTED is very clear explanation that it is acknowledged and waiting.

NEED TRACK REPLAY tells as well very clearly that it is OPEN and requires more information from users.

REPORTER EARLIER is like what? Instead use "DUPLICATE" and link to the original one (all duplicates gets linked to first one)

INVESTIGATING tells clearly that it is OPEN and it is being processed currently, not in some time in the future but currently.

CORRECT AS IS means exactly that how thing is going to be, - NO CHANGE.

FIXED well it can't be said more clearly.

FIXED INTERNALLY well, it as well tells very clearly that it is coming in the next patch or very soon.

W.I.P Meaning it is a long process and under work that requires lots of time.

SOLVED might mean that other solution than developers fixing code was required.

 

But again, ED keeps almost all in one basket. It makes more difficult to go through to find the wanted. Where example Magnitude keeps them categorized so person knows where to look quickly. They just don't use tags there like ED does.

 

One of the problems is that there is no good bug reporting tool used in DCS World, as the web forum is not really for that. It would help everyone a lot if a proper bug reporting platform would be implemented. Far more easier to keep track of everything.

 

Example: https://bugzilla.kernel.org/buglist.cgi?bug_status=__closed__&content=btrfs&no_redirect=1&order=Importance&product=File System&query_format=specific

 

It would as well allow developers to use directly the official bug report platform and be in direct contact with the users and get the direct information.

Person who would be responsible to manage the bug listings would have far easier job with proper bug reporting tools.

 

 

 

[RAZBAM_ELMO]

6 hours ago, tech_op2000 said:

@RAZBAM_ELMO Hey, since your actively posting here, can you find my bug i accidently posted in the general forums and move it to the appropriate bugs section? 
 

 

rog

 

6 hours ago, netizensmith said:

This entire disagreement can be solved easily and immediately by renaming the "RESOLVED" section to "RESOLVED and FUTURE ENHANCEMENTS". I see @RAZBAM_ELMO's point on this; it's not a bug if it wasn't even supposed to be in the module yet.

Some actual logical suggestions. Thankyou, that actually is a great idea and ill get in touch with the wed designers and add Furture Implementations either as a separate sub forum or attach it to the resolved section. Great suggestion.

[RAZBAM_ELMO]

6 hours ago, Fri13 said:

 

There is no ISO standard if you so try to go talk about it. But there is a de-factor standard that is based to how to do properly the documentation, reporting and even management.

 

Yes, every business can do how ever they want, but if they go and do it badly, they are to blame only themselves when they get in the trouble.

And Razbam got in the trouble, in big trouble just last autumn. What you were hired to fix.

 

Does it require reviewing again by the ED?

 

 

Yes, to you it can be a nightmare... For others it is more efficient way and truthful.

 

 

Hold on.... shift through a 2.2K posts to find a solution?

What argument is that? Really?

 

If you have a problem with the gun sounds disappearing since last update, why would you go to browse bug reports about weapons, avionics, or missions and campaigns?

 

And if someone does have a problem in procedure, that is not a bug report, that is a common discussion "How do I....?" instead "bug". There shouldn't be searching solution for a problem in bug section, it is there to check out that is there problem in the code that developers needs to fix. Not to go searching "Why doesn't my gun work when I have RPM 55% and nozzles angle 82!?!?!?".

 

 

 

Why would you look RESOLVED section for a bug report if you want to know is it already reported?

If you have a bug like a gun sight doesn't point where the bullets lands. Why do you go searching "Solved bugs"?

If you have a bug that TPOD compass points completely wrong direction, why would you look "is it already fixed" from "Solved" part when you have it?

 

First thing to do is to update to latest version, check does it still exist. Then if it exist and you want to report the bug, you go to "Open Bugs" listing. There you do quick check that is there a report about it or not. If you don't find something there, then you fill a bug report.

 

There is no reason what so ever to go "Resolved" section to find out is a bug fixed.

 

 

That is what the labeling is for.... Why the bug reporting systems has own mechanism to easily keep a track that what is open and what is closed.

When you put a label "Closed" or "Solved" then it means that it is done, completed and it can be moved to "Resolved" section. But before it gets there, it requires that others will confirm that bug is fixed and doesn't exist anymore. That is as well part of the bug reporting that the reporter comes back to check is it fixed and if it is, informs "update XYZ fixed this".

 

When "FUTURE IMPLEMENTATION" tag is put and bug is moved to RESOLVED section, it is away from the open problems in the current version listing.

When you get a bug report, you link it to the internal material if you use such. When the developer has made the fix, it is marked as to be fixed in patch XYZ. When the patch is out, it is checked that is it fixed and if it is confirmed by others who had the bug, then it is marked as fixed and can be moved to RESOLVED section.

 

If you have system where one side is OPEN and then other side with CLOSED, it is wrong to have OPEN mixed with CLOSED.

Instead that, put all to one basket and then simply tag them "OPEN" or "CLOSED" as confirmation. Posts that doesn't have a tag are NEW, unconfirmed ones. Until someone else (anyone else from the community) can as well confirm it, what means should be tagged as "OPEN" until solved.

 

This is your system, [Problems and Bugs] and [Resolved Bugs] and it is same as [OPEN] and [CLOSED].

Why are OPEN reports moved within CLOSED section without fix?

(Why are Unsolved reports moved among Solved?)

 

This is really a very simple To-Do list management.

[  ] Buy Milk

[  ] Print the daily report and map it

[  ] Swap the bathroom light bulb

----------------------

[x] Buy bread

[x] Buy light bulb to bathroom

[x] Change the printer ink cartridge

 

 

What has been done and what has not been done are very easy to see.

Even when something is known that it is to be done in the future, it stays NOT DONE until it is actually done.

If someone ticks "Buy Milk" as DONE because in the future they are going to buy the milk when they go out.... Where does it lead to?

 

The others does it different style by using categories. They keep the CLOSED and OPEN in the same sub-category. But they might not have added tags there that informs is it OPEN or CLOSED.

 

https://forums.eagle.ru/forum/320-bugs/

 

That is fairly easy to as well to look by the tags.

 

REPORTED is very clear explanation that it is acknowledged and waiting.

NEED TRACK REPLAY tells as well very clearly that it is OPEN and requires more information from users.

REPORTER EARLIER is like what? Instead use "DUPLICATE" and link to the original one (all duplicates gets linked to first one)

INVESTIGATING tells clearly that it is OPEN and it is being processed currently, not in some time in the future but currently.

CORRECT AS IS means exactly that how thing is going to be, - NO CHANGE.

FIXED well it can't be said more clearly.

FIXED INTERNALLY well, it as well tells very clearly that it is coming in the next patch or very soon.

W.I.P Meaning it is a long process and under work that requires lots of time.

SOLVED might mean that other solution than developers fixing code was required.

 

But again, ED keeps almost all in one basket. It makes more difficult to go through to find the wanted. Where example Magnitude keeps them categorized so person knows where to look quickly. They just don't use tags there like ED does.

 

One of the problems is that there is no good bug reporting tool used in DCS World, as the web forum is not really for that. It would help everyone a lot if a proper bug reporting platform would be implemented. Far more easier to keep track of everything.

 

Example: https://bugzilla.kernel.org/buglist.cgi?bug_status=__closed__&content=btrfs&no_redirect=1&order=Importance&product=File System&query_format=specific

 

It would as well allow developers to use directly the official bug report platform and be in direct contact with the users and get the direct information.

Person who would be responsible to manage the bug listings would have far easier job with proper bug reporting tools.

 

 

 

Im not arguing the point with you anymore. Clearly you have your mind made up and are not open to new ideas so its just back and forth at this point which I do not need to entertain. If you don't like how I do things, then tough. I have a system I like working with which helps the devs look into issues more clearly and makes it quite simple for the average user to come through and find a solution or report a bug. You are one person. I have at least 50 PMs from users praising the open concept and new reporting methods so I'm not going to just tailor it to you and how you think it should be done. End of story. AS INTENDED.

 

[Dr Zaius]

On 2/18/2021 at 9:38 PM, RAZBAM_ELMO said:

Im not arguing the point with you anymore. Clearly you have your mind made up and are not open to new ideas so its just back and forth at this point which I do not need to entertain. If you don't like how I do things, then tough. I have a system I like working with which helps the devs look into issues more clearly and makes it quite simple for the average user to come through and find a solution or report a bug. You are one person. I have at least 50 PMs from users praising the open concept and new reporting methods so I'm not going to just tailor it to you and how you think it should be done. End of story. AS INTENDED.

 

 

This argument has pretty much come full circle - you've defended how you go about categorising posts then submitted to creating an additional [Future Implementations] folder that will help separate out the posts that ordinarily would be marked as [Resolved]. I don't mean to blow my own trumpet but I did suggest this a while back!

 

If user opinions are what you hold dear then why not poll the forum to really see how people feel about its current implementation? 

 

On 2/7/2021 at 12:08 AM, Dr Zaius said:

Surely then this would be easily fixed by creating different folders for both [Resolved] and [Future Implementation] and separate the categories from one another, unless of course your suggesting there’s something more sinister at play here?

 

I say this because I’ve encountered a level of misunderstanding from Razbam recently that was so frustrating I started to believe it a deliberate ploy to ignore the bug I was trying to report - without a proper understanding of what the issue was my post was marked up as [User Error] and moved to [Resolved] where further dialog all but ceased and only got moving again after both myself and others re-explained the issue over & over and kept calling Razbam out to take another look at it, only then did they finally understand and moved the post from Resolved section and back into the Problems & Bugs.

 

The point then I guess I'm trying to make is that with most things in life some level of perseverance and patience is required, I totally get its super frustrating when you feel ignored an/or misunderstood and know its made worse because ultimately you’re doing this to help them out as much as you want it fixed for yourself.

 

I don’t want to play devil’s advocate but there a lot of factors at play here, however I do believe that lots can be done to improve the situation we’re all in so if getting ED involved is the only way to push for a better product then so be it, will be interesting to see what they make of it all.

 

Good luck!

 

 

Edited March 5, 2021 by Dr Zaius

[Hawkeye_UK]

I go back to my original post i still fail to see why posts are being marked as resolved when they are not in game.

 

Things that have ALREADY been implemented marking it as Future implementation is an absolute nonsense its its a bug that is highlighted as a way to not fix it.

 

How can you then track what has been resolved (as in physically in game) using this method, you cant!  Or are we going to have them doubly resolved for when they actually do get resolved.

 

What happened to the Razbam bug tracker - i remember after i highlighted last year that it was woefully inept it was removed from their website with a promise that a new one would be introduced - i've yet to see this evidenced.

 

How can anyone keep track of what's outstanding?  I think we should start a new community spreadsheet again to be honest.

 

[Fri13]

12 hours ago, RAZBAM_ELMO said:

Im not arguing the point with you anymore.

 

No you are not arguing about the point, you have not for sometime now.

 

12 hours ago, RAZBAM_ELMO said:

Clearly you have your mind made up and are not open to new ideas so its just back and forth at this point which I do not need to entertain.

 

Seems that You have your mind set up and You are not open for a working systems, so You are just stuck to your method that is inefficient and supports Razbam behavior toward customers. You can not explain your system and even understand why it is flawed and it is not even entertaining, far from it.

 

12 hours ago, RAZBAM_ELMO said:

If you don't like how I do things, then tough.

 

Yes, it is just me.... Just me who has the problems, right?

Problem is, You do not understand the problem, and you do not want to get clearer system.

 

12 hours ago, RAZBAM_ELMO said:

I have a system I like working with which helps the devs look into issues more clearly and makes it quite simple for the average user to come through and find a solution or report a bug.

 

You can like working with what ever you want, but it is not helping people to see that what problem/bug doesn't exist and what does exist.

It is not simple and easy to come here to look hat is a bug and is there a solution when everything is mixed up together without clear information.

 

You can not even explain that why it is clear when you mix "OPEN" and "CLOSED" reports to category "CLOSED", or you mark "OPEN" reports as "CLOSED" when they still exists?

Ah... I already see, the problem is just Me... And Me alone.... Who has this "closed mind" for "new ideas".

 

 

You can think that you have clear system, but when someone is moving notes from TODO and from WIP to DONE category before they are actually DONE, it is just wrong and cause trouble to everyone!

You might even love to do it that way. This thread was not about questioning that do you like to do it that way or not, but why you do it, the reasoning in it. Your opinion or state of feeling doesn't matter.

 

Like lets take a example that how did it manage to slip through a whole testing process that Harrier mechanical clock did not get fixed?

1) Bug report was done about it.

2) Patch was incoming and changelog was announced day before.

3) Patch was released on next day and report was changed to "RESOLVED"

4) Bug still exist and confirmed.

5) Report still exists in RESOLVED.

 

 

How is that possible?

 

I give you few plausible common reasons for it:

 

1) When the developer took the report for TO-DO, they wrote the code but didn't test it and wrote it to changelog as done.

2) The closed beta team that each member task is to go through each and every change that programmers commit to check and validate it is properly done. No one tested it.

3) The report was moved from "Bugs and Problems" category to "Resolved Bugs" category, without any confirmation from closed beta team AND community members making the report that is it actually fixed, only by because it was in changelog.

 

We can invent other answers for that if we want:

 

4) User error

5) AS INTENDED

6) FUTURE IMPLICATION

 

So no reason to go to move it to "Bugs and Problems" section back, as no one has confirmed it. And it is so easy to keep track of these reports that no such thing should happen that report stays in wrong category for three weeks after confirmation...

 

There are members in this community (excluding myself, just so you don't try to argue that I have the problem) who has gone through just fresh bug reports you have marked "RESOLVED" and found them still validly broken. They don't just anymore care to even call you as it doesn't lead anything.

You might have nice time to use your method and your system and all, but it doesn't help anyone as people don't know anymore that what is broken, what is as intended, what is just ignored and hat is what ever it is in the future.

 

12 hours ago, RAZBAM_ELMO said:

You are one person. I have at least 50 PMs from users praising the open concept and new reporting methods so I'm not going to just tailor it to you and how you think it should be done. End of story. AS INTENDED.

 

Yes, I am only one person, this is not 50 vs 1 as you now try to argue and think it is.

I am not even the one who started this thread.

And what does it matter how many Private Messages you have praising You?

 

And if you think that Razbam has a "the open concept" then you are just lying to yourself.

Doesn't ED have the "Open Concept" or Heatblur or any other third party?

 

Tell the developers to start being in this forum and their corresponding module forums that ED offers at the same amount as they spend in Discord chitchatting.

So what are the Razbam plans for next 6, 9 and 12 months (in this forum about Harrier)?

What are the current plans for next update?

What are the plans for update after that?

 

Be open.... You made a claim that you have the open concept....

There is no such openness, there is no willingness, there is no plans or ideas that what to get done.

The hard evidence is the Razbam history. You are part of that now. Your actions adds weight to that.

AS INTENDED.

End of Story!

 

 

[Vakarian]

Is it too much to ask some proper customer service and proper bug management?

Why does it matter how much has anyone spent on any product?

 

Let's think of it this way. How much hours have any single of bug reporter spent trying to reproduce a but? Are you @Mr. Big.Biggs gonna pay my hourly wage? I would rather either play something I enjoy or do something else than bug hunt, but I do it did it because I wanted to improve the module and give my feedback to the devs about what is wrong. When I get treated like this, that's when I stop investing my own time to help someone else. It's either mutual benefit or none.

We have bought a product, enjoy using it up until every effort to improve that module gets met with a stonewall.

Edited February 19, 2021 by Vakarian

[BIGNEWY]

Please keep the discussion civil 

 

thanks