E-mail confirmation when reporting bugs
Wednesday, 25. March 2009, 15:05:38
I know this has been requested by a lot of people, so I am happy to report that you will now receive a confirmation through e-mail when reporting bugs. This should make it easier for you to keep track of reported bugs, and look them up later if you need to add information or refer to the bug report somewhere.
I have pasted the e-mail below, so that you won't have to submit fake bug reports to see what it looks like
All specific details have been replaced by text in angle brackets ("<Text>"). The e-mail is sent from <Bug_ID>@bugs.opera.com to make it easy to reply in order to add another comment to your bug report.If you report Opera Mini bugs, the e-mail will refer to "Opera Mini" instead of just "Opera".
Here is the e-mail (sorry for the horizontal scrolling, but you can press Ctrl+F11 to enable Fit to Width in Opera):
Subject: Reported Opera bug <Bug_ID> From: <Bug_ID>@bugs.opera.com Dear Opera User, This is to acknowledge that we have received your bug report, with the id: <Bug_ID>. You may wish to keep this ID for future reference. All bug reports are read and handled by our staff. However, please note that you will not receive a personal reply to the bug report, unless we need more information to investigate the bug. We are not able to respond to questions and queries through the bug tracking system. To get help with Opera, please visit http://www.opera.com/support/. You can use this e-mail address (or reply to this e-mail) to update your report with more information, such as screenshots, crash logs, code examples, and so on: <Bug_ID>@bugs.opera.com. This is the information you submitted to us: Version: <Version> Build: <Build> Operating system: <OS> Platform: <Platform> Summary: <Summary> URL: <URL> Steps to reproduce =================== <Text> Expected result =============== <Text> Actual result ============= <Text> HTTP_USER_AGENT: <UA_String> HTTP_ACCEPT_LANGUAGE: <Accepted_Languages> PLUGINS: =========== <Installed_Plugins> SCREEN: =========== Resolution: <Resolution> ColorDepth: <Colour_Depth> ========================================================== Thank you for helping us improve Opera! Opera Software http://www.opera.com/
WIDGETIZE
WildEnte # 25. March 2009, 16:16
Tamil # 25. March 2009, 16:32
experttease # 25. March 2009, 18:02
unfortunately this doesn't work when reading this post as a Feed in M2...should I report a bug?!
Very glad to hear this news, from now on I will submit bugs to Opera.
Remco Lanting # 25. March 2009, 18:53
That information was submitted, so it should be in the mail.
Phred # 25. March 2009, 19:00
Steve Pifer # 25. March 2009, 23:33
Once upon a time there was an Englishman called Mart who joined Opera under the alias 'theoddbod' and started writing stories. # 25. March 2009, 23:55
George # 26. March 2009, 00:23
FataL # 26. March 2009, 03:52
Now I just need to find a new bug...
Charles Schloss # 26. March 2009, 05:49
_Grey_ # 26. March 2009, 06:35
Rafał Miłecki # 26. March 2009, 08:20
Phred # 26. March 2009, 08:54
Originally posted by Zajec:
Sad but true.Haavard # 26. March 2009, 09:29
Zajec: Feedback would likely have to be manual due to the highly sensitive data in the BTS (a single mistake could, worst case, lead to a lawsuit and the death of Opera). And that would be extremely resource-intensive, which means that fewer bugs would be handled, and the overall quality might suffer.
And it's a very complicated issue. For example, if a bug needs to be moved to a different category because it affects multiple platforms, projects and customers, should it still be visible to the original reporter? The bug report isn't really a desktop bug report anymore. And what if the bug report is simply a duplicate of another bug report. Should the reporter get updates for that other bug report? Even if it's a bug report for a different platform or project?
As you can see, it could quickly get messy.
Rafał Miłecki # 26. March 2009, 17:44
The only thing I want to know is changing status to RESOLVED or WONTFIX (or however you call it).
What if my bug report is duplicate? Match is as duplicate.
1) If original bug is already fixed, just send me some extremly short mail "Already fixed internally". That would be enoght.
2) If original bug is not yet fixed, make you BTS adding me to list of people interested in state of bug.
Please note I am *not* talking about visibility of data of bug report for any reporter.
P.S.
By original bug I mean the one that I made duplicate report for.
FataL # 26. March 2009, 17:49
Haavard # 26. March 2009, 18:40
Martin Rauscher # 26. March 2009, 22:38
Haavard # 27. March 2009, 08:48
Phred # 27. March 2009, 15:00
Originally posted by haavard:
That information would be very useful. I don't see how that stands to spread the secrets of the bts.Those would be a great emails to receive. We have multiple stages of closed here as I'm sure you do. One is the dev says its fixed and another is after QA confirms. Those steps and two-way communication would be fantastically appreciated. I suspect this is not new/news to you.
Haavard # 27. March 2009, 15:02
Phred # 27. March 2009, 15:08
Originally posted by haavard:
What is your point? My point is if it was closed one of 1,084,056 ways, I would like to know a) that it was closed and b) why/how/the reasoning. There will never be a time that a ticket was closed and i don't want to know which of X reasons it is.Originally posted by haavard:
I have been using jira for years and have been getting emails from jira since day 1 about the status of tickets changing. What is this maintenance nightmare you speak of? What would you be maintaining exactly?Rafał Miłecki # 27. March 2009, 16:53
Does implementing that need one month of single person work? OK, let someone do that. Respect your reporters by doing so.
Haavard # 28. March 2009, 12:14
The maintenance nightmare I am speaking of is the complexity of Opera as a product, and the fact that we are working with many different projects and many different customers. Those customers would not want their bug reports out in the open.
Zajec: There is no "fixed according to..." in our bug tracking system. There is only the status, not who, and why. And doing this would definitely take more than one person for one month. It would probably be a resource-intensive, never-ending project.
It's not a matter of simply flipping a switch. We have a lot of extremely sentitive information in our systems, and one would have to make absolutely sure that there is no room for error.
Phred # 28. March 2009, 19:44
Originally posted by haavard:
Knowing even that the bug was discarded is infinitely more information than what we have now (every positive number is infinitely greater than 0). It would certainly be useful to know why you marked something WONTFIX, but just knowing that it was resolved that way would still be useful. Baby steps. Right now opera's BTS is a black hole. One-way communication. Things go in; noting comes out. Do you understand that? Anything to make it less like that is a plus in my book. As Zajec hinted at, it upsets us (the reporters) that all the communcation is unidirectional.Originally posted by haavard:
This sounds like fear, uncertainty and doubt to me. Jira already has the ability to send emails to reporters about status changes. I personally do not see how complexity of opera as a software and/or organization has anything to do with sharing the status of bug reports. What does extremely sensitive data have to do with the state and resolution of a bug? Even if you had credit card and social security numbers in the bug report, that has absolutely nothing to do with FIXED, DUPLICATE, WONTFIX, CLOSED, INPROGRESS, RESOLVED, VERIFIED, and other states of bugs. If you see this connection, please do share it with us all.Haavard # 29. March 2009, 11:10
And I'm not the one you need to convince about anything. I'm just explaining the problems with the proposed solutions. I wouldn't mind a completely open BTS, but this isn't my company. I'm not in charge, and I don't have to deal with all those business customers and others who also use the same system.