E-mail confirmation when reporting bugs

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/
Advertisements

26 thoughts on “E-mail confirmation when reporting bugs

  1. "(sorry for the horizontal scrolling, but you can press Ctrl+F11 to enable Fit to Width in Opera"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.

  2. The "What kind of problem is this?" and "Where is the problem?" fields are missing in the mail.That information was submitted, so it should be in the mail.

  3. Nice to see :up:. Does this also apply to bugs submitted via the Opera Mini bug report form, which is slightly different?

  4. I understand you can't give full access to bug report page to reported (private discussion, parts of code commented) but it's shame you don't give any feedback about resolving bug. I have no idea if bug I reported 2 years ago is still waiting for fixing or did you decided to not fix it.

  5. Originally posted by Zajec:

    it's shame you don't give any feedback about resolving bug. I have no idea if bug I reported 2 years ago is still waiting for fixing or did you decided to not fix it.

    Sad but true.

  6. theoddbod: Yes, it should apply to Opera Mini as well. I actually mention that in the blog post.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.

  7. The only thing I want to know is changing status to RESOLVED or WONTFIX (or however you call it).

    :yes: :up:

    What if my bug report is duplicate? Match is as duplicate and make you BTS adding me to list of reportes of original bug.

    :yes: :up:

  8. haavard: I've meant something else. I don't want to have access to *any* data from bug report. I don't want to know it's priority, don't want to know which source file causes it, who is fixing it, when it will be fixed, to which platform it was assigned, comments you posted, (…).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.

  9. There are unfortunately several possible states for a bug report. And duplication could easily lead to the aforementioned security breach.

  10. "Closed" doesn't really tell you anything. Was it an invalid bug report? Was it a duplicate of some other bug report? Was it fixed? Something else?

  11. Originally posted by haavard:

    "Closed" doesn't really tell you anything. Was it an invalid bug report? Was it a duplicate of some other bug report? Was it fixed? Something else?

    That information would be very useful. I don't see how that stands to spread the secrets of the bts.

    Bug #123 was closed as WONTFIX.Bug #456 was resolved as FIXED.

    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.

  12. As I said, there are even more ways to close a bug. And there are numerous other concerns as well. Definitely not a small task, and it could turn into a maintenance nightmare.

  13. Originally posted by haavard:

    As I said, there are even more ways to close a bug.

    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:

    Definitely not a small task, and it could turn into a maintenance nightmare.

    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?

  14. haavard: I don't know how yous CLOSING is organised, but I don't belive it's not possible to resolve this problem. I'm fine with receiving many emails (like "FIXED according to programmers", "FIXED according to QA", "Report is duplicate, will inform you about state of original") and many others. I just know it's not OK to receive many bug reports and don't give ANY feedback. I don't like way you treat me as reporter.Does implementing that need one month of single person work? OK, let someone do that. Respect your reporters by doing so.

  15. fearphage: Right, you would like to know the reasoning. And the status will not show the reasoning. If it was discarded, you will not know why it wasn't accepted as a bug.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.

  16. Originally posted by haavard:

    Right, you would like to know the reasoning. And the status will not show the reasoning. If it was discarded, you will not know why it wasn't accepted as a bug.

    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:

    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.

    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.

  17. That Jira has the ability to send mail is unrelated to the complexity. I think I have addressed the rest of your comment, so I don't think I need to repeat myself. See my previous comments.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.

Comments are closed.