Building A Better Bug Report

A common exchange in the previous length thread deals with the proper place to enter bug reports. Here it is:

http://www.adobe.com/go/wish

Now that I have posted this information, I will revert to the previous policy of unceremoniously deleting bug reports that are posted as comments to any blog entries.

Let’s look at those fields on the bug report form:

  • Name and email– you may not like to surrender this information but if we can’t reproduce your bug report and we can’t follow up with you for more information about your unique configuration, we have no choice but to dismiss your bug report.
  • Product name: Please be sure to select “Flash Player” so it gets routed to the right place; not “Flash Lite Player” and certainly not plain “Flash”.
  • Remember to select Browser; you can safely disregard web and app server and database fields.
  • The correct OS is also important to select for proper handling.

We’re always particularly interested in crash bugs, especially ones that bring down the browser every time. Obviously, these don’t happen with our many configurations in-house (not even with Firefox 2, which I’m currently using on my Gentoo dev box) or we would fix them before the Player got out the door.

Nuvola_apps_bug.png

14 Responses to Building A Better Bug Report

  1. andrew says:

    No arguments here, Mike.I’ve got to tell ya though, that Adobe bug reporting system leaves alot to be desired. Atleast from a bug reporter’s point of view (I have no clue what it looks like on your end).Something that doesn’t feel quite so much like dropping pebbles down a well may make the process more inviting for bug reporters.Cheers,A.

  2. Josh Tynjala says:

    While the bug report/wish form looks a little impersonal, it’s the best way to let Adobe know what you think. I’ve spoken to Adobe employees in person, and if I have a good idea, they tell me to send it to the wish form too because it has a big impact on future features and determining the importance of bugs.

  3. Shish says:

    Have you taken the 1000(?) character limit off the description box? It makes it really hard to post stack traces, or any other useful info, with that in place :-/

  4. Tink says:

    I use the report form the other day and found it very pro-active. Someone was in touch with me within the day.Usability eise (the title here is ‘Building A Better Bug Report’) the field where you enter your comment could be bigger. Its surrounded by whitespace, but just a little TextArea in the middle. It makes it very difficult to read what you are writting. Use some of that whitespace and make it wider and higher.

  5. RQ says:

    A question: I’ve reported a few gflashplayer problems to the beta site after the final version was released (found the link in my browser history). Should I re-report them to a wish form, or may I expect those to still be reviewed? [ Try re-reporting them, please. -Mike M. ]

  6. 三洋伺服 says:

    Something that doesn’t feel quite so much like dropping pebbles down a well may make the process more inviting for bug reporters

  7. ArmEagle says:

    Even though that form might work very well, I’d prefer to see the current list of issues (ie mozilla’s bugzilla). I dont like to submit issues that might already be known.So, any chance we’ll get a link to ‘known issues’? [ “WMODE.” That accounts for about 97% of the current known issues. -Mike M. ]

  8. Kostas says:

    Speaking about bugs, there is an issue about [……..] should I submit a bug report? [ Yes. -Mike M. ]

  9. ArmEagle says:

    Hmm, Mike M. Maybe it is because it’s late here.. But I totally didn’t get your comment.. :PIf it’s just me, just leave it like that.. but well..(ie no need to post this as comment)

  10. Trisha Parks says:

    sometimes I do bug report especially if the bug keeps coming back…

  11. Carnildo says:

    Speaking of the infamous WMODE issue: is this something that needs to be fixed in the plugin? The browser? Both? Neither? [ A bit of both. -Mike M. ]

  12. Glen says:

    pcm.compress {type ladspaslave.pcm “plughw:0,0”;path “/usr/lib/ladspa”;plugins [{label dysonCompressoutput {controls [ 0.0 0.1 1.0 1.0 ]}}]}pcm.pcompress {type plugslave.pcm “compress”;}Above is my ~/.asoundrc.I’m trying to normalize volume of flash9.How do I make flash9 to use pcm.compress?I see some files in ~/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys.Is there a way to edit those force flash9 to use pcm.compress?For now, I changed pcm.compress to pcm.!default. So, the volume of flash9 is normalized. But i want only flash9, not other applications, to use that slave.

  13. csant says:

    I might have missed this in other online documentation – but where is the mms.cfg file that the Flash 9 Security whitepaper mentions, to be found on a Linux system? Or does Linux have other means of system-wide configuration of the Flash Player?

  14. DavidB says:

    Hi, I submitted a bug report about a week ago, including my e-mail address and all. But I did not even get a receipt confirmation, or a bug number, or anything. How can I track the status of my bug report?