What does bug reviewed mean?

Does switching a bug report from needs to be reviewed to reviewed mean “we don’t care”?, “we’re not interested in your business”?, “we couldn’t recreate the bug so you must be nuts”?, or could it possibly mean “we care and are working on it”?

Can’t speak for anyone else, but I’d like to know if my bug is being taken seriously at all …

Can anyone explain the need to change the IDE? The new one doesn’t even respond to key presses on the keyboard.

Who else finds they frequently have to press a key multiple times to get it to react?

It just means that someone @Xojo has reviewed the case.

Speaking seriously, and maybe to John’s point, I don’t think a report should be marked “Reviewed” without an explanation accompanying it. Otherwise it just feels like you’ve been left high and dry.

IMO BUG reports should never have status of reviewed. It should be either “Verified”, “Information Required” , “Not Reproducible” or “Not a Bug”. Maybe another category such as “Assigned to Specialist For Futher review” is needed

Reviewed just means it was not looked at enough to assign one of the other statuses and does seem like limbo.

The explanation is… Someone at Xojo has looked at the case. It’s impractical to put a personalized message on every case.

Why? What is the point of an indeterminate review? That is how they appear to many people.

To me reviewed means limbo. As Karen said above - if you reviewed it what is the conclusion? She pretty much summed up the responses. A simple status change would alleviate quite a bit of frustration for the concerned users.

Reviewed is exactly a simple status change. It is an automated change triggered when the first engineer views the case.

The alternative would be to not change the status. But I’d assume staying in “Needs Review” for a long time would feel worse.

Reviewed simply means the case has been seen. There is no conclusion to be made. An engineer has not yet had time to verify the case. I mean, what should the engineer say in this scenario?

Reviewed means Limbo. Other systems always tracks responsibilities after a review. No task is left without someone taking care, and time for that task is tracked, like:

#23423 Needs review - 2013-2-5 13:25”->“Being reviewed by Frank Paul 2013-2-5 13:28”->“Closed by Frank Paul - 2013-2-5 13:29, Reason: xxxx” (Finished - Total time: 0 month(s), 0 days, 0 hours, 4 minutes)

#23424 Needs review - 2013-2-5 13:25”->“Being reviewed by Frank Paul 2013-2-5 13:29”->“Assigned Engineer Walter Bishop” (Open task - at 2013-7-29 9:30 - Elapsed Time: 5 month(s), 21 days, 15 hours, 39 minutes)

So, there are “reviewers”, those people knows or potentially knows who can handle that task. As the first filter, they can close the task, send to a specialized engineer for a deeper review, or send rightely to a engineer to take care of it. No one simple task is maintained in the limbo waiting the requester to die or close the doors. The business administration can check responsibilities and priorities, and interfere.

Engineers can take actions or send/reassign the task to other engineers.

Each Engineer will have a pile of work shown on his console.
When this pile keeps growing, it’s time for the administration to get more engineers, helpers and interns.

[quote=23126:@Thom McGrath]Reviewed is exactly a simple status change. It is an automated change triggered when the first engineer views the case.
[/quote]

And often stays there a long time (sometimes a VERY VERY long time) because it has been ‘handled’…

A reviewer needs to decide on an appropriate next step. Without that it is worst than nothing… I know when i see a bug report of mine set to reviewed instead of something else I just sigh…

The whole point of reviewing something is to decide on a next step…

[quote]
An engineer has not yet had time to verify the case. I mean, what should the engineer say in this scenario?[/quote]

They have not done anything meaningful with it at that point as far as we know… I think many feel that Reviewed is status that means the bug is less likely to be addressed/evaluated than when it’s status is “needs review”. I know I do.

I know you can’t speak to it now but is there an internal folder for BUG reports that have have been “reviewed” that has an internal priority to be dealt with HIGHER than reports that “need review” ? If not, then it truly is limbo and a problem with quality management.

Please understand that our engineers are not just sitting around, waiting for the next bug report to come in. We all have other responsibilities, new feature development, etc. to work on.

Also, not all cases are verifiable. When you create a case, the more information you supply, the better the chance that it can be moved to a status of “verified”, meaning that we can reproduce your bug, because without that there’s little chance that we can fix it. The best cases we get are the ones that have a stripped down sample project that ONLY shows the bug, a clear set of instructions of how to reproduce the problem, a description of what you expected to happen, and a description of the machine you were running xojo on at the time, including OS, OS version, memory, Xojo version.

You’d be surprised how many people write “I ran into this bug” and include a screenshot of the exception dialog, and then get upset when we close the case as not reproducible.

One last thing. There are a mountain of bug reports to wade through. I would be extremely helpful to us if our users would go through their bug cases and see if they are still reproducible in the latest version of Xojo once in a while. It’s not uncommon for us to spend time on bugs only to find out it was already fixed somewhere along the way (because there are so many duplicates). This takes valuable time away from fixing the bugs that do exist.

I think what people really want to know is what happens next? What logic do you use to go back and re-review reviewed bug reports? For example, I have quite a few bug reports/feature requests in the Reviewed status, some in the verified status, for a few years now. How do you decide to go back and act on any of them?

I’ve done this, but nothing seems to happen, for example, on Jun 12, I commented on feedback://showreport?report_id=19677 saying “Xojo IDE performs this task, it can be closed as implemented” … It is still in the reviewed status.

I’ll ignore the truisms. If the reviewer needs more info or find inconsistencies on the requests, he must contact the requester asking for more data (writing a line in the system and pressing “Needs more info”, or something).

It’s completely ok to close unreproducible problems, as it’s ok too users to reopen cases and add more data and samples.

Limbo is unacceptable. Transfer of responsibility for the user, about the status of a task, is unacceptable.

A task, at the top level, have 3 states: Not started, Being take care by X and the current status is Y, Closed by reason Z.

If one task, is long time open, the manager must check with assigned resource why. If the engineer BELIEVES (almost unacceptable) that X thing could be already fixed by another engineer), he can send the task to the Test Team for verification. They will test and: 1. Close it as Fixed, or 2. Return the findings to the assigned engineer for fixing.

Xojo engineers seems overloaded and needing more resources like the basics not specialized reviewers/testers and maybe some helper engineers for distributed tasks.

The problem with the ideal world of having the clear roles, flows and teams, is that this jumps from the technical part to the business field, where we need to check other things like cash flow to make decisions on growing to make things better as it should be. And about this part, I must sit, wait and hope for the best. But sometimes we need a bit of ranting to people remember that things must get better in some areas. :wink:

There are steps you do not see. For example, I might have seen a bug that I know is William’s. When I viewed it, it became Reviewed. That’s what you see. What you don’t see is me assigning it to William.

Reviewed is not limbo.

The times I’ve just taken a few hours to sit down and wade through the latest bugs coming in tells me that Greg is prone to the understatement. Many reports read like “I ran into this. Your problem.” Well, it’s not their problem. It’s your bug that is getting in the way of what you are doing. Take some ownership of it. Put your marketing hat on, or start knitting one if you don’t have one yet. Make them want to fix it because it’s either fun or easy or rewarding to fix.

Rick, please don’t take this the wrong way, but you’d last about 20 minutes managing the kind of engineers who can work together in a distributed group and put the time and dedication the Xojo guys put in. Basically, that’s the time it would take to surreptitiously hook your Skype account up to 8 instances of Eliza.

But this, in of itself, takes valuable time away from some other task. It would be a lot more efficient for everyone if all of the necessary info were there in the first place.

No. We users, don’t create bugs, so, there aren’t our bugs. We can find them and report. Some bugs I could report just don’t affect me, but affects other people, and, as a bug, affects Xojo as a product. In the role of bug reporter probably I’ll not babysitting bug fixes ( good for the sanity of Xojo engineers :slight_smile: ). It’s more like a “report and forget” unless additional data are requested. I must believe that the professionals will take care of it, not push them to the limbo bin and after 2 years guilt us of not taking caring of them. In other systems, this way of interpreting bug reporting/fixing is simply impossible.

You are absolutely RIGHT!
You, as a high level engineer, shouldn’t be doing this! You shouldn’t be on the front line unless necessary. You should be in the second line. SOMEONE, trained as a tester, should be doing the FIRST review, closing improper reports, requesting more data, and when the case is solid then assign the case for the proper people. You will always have solid reports and feature requests unless the reviewers have doubts and send the case right to you for your judgment/analysis . This part of the job of first analysis, filtering, adding comments and data, and sending the case to the proper teams/resources/engineers, should be the task of other people, while you are concentrated in fixing, development, and emptying your task queue as your other colleagues. Some manager at Xojo would check how bad the fixing work is, how the piles of work per engineer are evolving and request more people when some engineers are getting overloaded, etc. :slight_smile:

That said, I know Xojo is not Microsoft. Task management, as I told, not losing reports, fixes and feature requests, is simple. It’s tested and works, BUT probably needs more money to be implemented than the current model, because I feel Xojo would need more people. And as I told, when the technical part touches the business part, I can’t comment anymore.

My point of view was already exposed, I don’t intend to extend this topic. :wink:

If you’re coming at it from the perspective of assigning blame to the right place, you’re 100% correct. If you’re coming at this from the perspective of using Xojo as a tool to make your own excellent products, you’re 100% incorrect.

I like to think that I get a lot of MY important bugs fixed because I put some effort into making them easier to verify and fix than is typical. It’s a lot like good UI design philosophy. It starts with respecting your end user. Or, it’s like being kind to the girl or guy at Subway who architects my sandwich. Often results in avocado or a cookie and no charge on the receipt. Similarly, respect the guy who has to make sense out of your report. It’s generally a pretty crappy task that nobody wakes up hoping to spend their day doing.

[quote=23180:@Brad Hutchings]
I like to think that I get a lot of MY important bugs fixed because I put some effort into making them easier to verify and fix than is typical. It’s a lot like good UI design philosophy. It starts with respecting your end user. Or, it’s like being kind to the girl or guy at Subway who architects my sandwich. Often results in avocado or a cookie and no charge on the receipt. Similarly, respect the guy who has to make sense out of your report. It’s generally a pretty crappy task that nobody wakes up hoping to spend their day doing.[/quote]

GIGO applies 100%
We have a couple shared folders that just make me cringe when I go through the reports as there are hundreds of reports with nothing more than “its broken” and a stack trace
I’d guess I sent out 100 “please add steps to the case” in the last few days

[quote=23189:@Norman Palardy]GIGO applies 100%
We have a couple shared folders that just make me cringe when I go through the reports as there are hundreds of reports with nothing more than “its broken” and a stack trace
I’d guess I sent out 100 “please add steps to the case” in the last few days
[/quote]

Read that 100 times, Rick. They are repeatedly brutally honest with everyone about this stuff, and still, incessant “my bug didn’t get fixed” (note the “my” when it’s convenient to feel slighted), “if only I were in charge, all this would work like Mussolini’s trains”, blah, blah, blah from the peanut gallery.

Rick, do you know what would happen if more developers took a professional approach to this stuff and treated Xojo as a “partner” rather than an adversary? Lots more things would get fixed, because there would be a lot less frustration and a lot better low-level communication. And yeah, I’m in a ranty mood this weekend.