Image conversion still broken

Igor Couto igor at pixelmedia.com.au
Fri Aug 1 07:36:01 EDT 2003


Dear Kevin,

Thank you and the RunRev team for all your hard work in keeping 
up-to-date with all the emails, and in maintaining a good rhythm in 
clearing the bug reports off the database!

On Tuesday, July 29, 2003, at 03:44  AM, Kevin Miller wrote:

> Sorry if our responses on Bugzilla are sometimeis a
> little bit terse, but because we have opened the database up to 
> everyone, it
> means that we get a really wide range of reports including duplicates 
> and
> reports that aren't really bugs.

Being one who has actually filed bogus and duplicate reports myself, 
let me make a suggestion that will make the RunRev team's life 
TREMENDOUSLY easier in the future. In my own experience, the reason why 
I filed every report that ended up being a duplicate was not for lack 
of doing a search in the database beforehand. The problem is that, BY 
DEFAULT, the query pages only returns results that include "new", 
"assigned" and "reopened" results. It purposely excludes "resolved", 
"closed", "verified" and "unconfirmed" reports.

Most users, like me, find the entire Bugzilla interface a bit daunting. 
If all I want to do is find out whether someone has reported the 'clear 
all breakpoints' bug for the debugger, I don't want to have to click on 
a dozen different choices (hey, half of them don't even make any sense 
to me). All I (used to) do was simply type in the words in the 
'summary' field, and hit 'search'. Bingo. It looked like no one had 
reported it before. So, being the kind soul that I am, I would report 
it (again...).  What you guys need to do is to change the DEFAULT to 
INCLUDE RESOLVED, VERIFIED, CLOSED and UNCONFIRMED reports, as well!

Believe me: as bug reporters, we want to be taken seriously. No one 
wants to be seen as a 'dummy' or a whiner who is reporting the same bug 
for the 3rd or 4th time!...

Second suggestion: I'm not a member of the Revolution development team. 
I have absolutely no idea whatsoever what the terms under the 
'Resolution' and 'Severity' category mean. I've been caught already a 
couple of times, reporting a bug that I thought was "critical" (because 
it meant that the particular feature of the program was made unusable), 
simply to be told that I had categorised it wrongly. We want to help, 
and we CAN do that by categorising the bugs properly for you, when we 
report it. However, unless you let us know what these categories mean, 
we'll just have to keep on guessing, giving it our best shot, and then 
keep on being told off!!!  ;-P

the links on the query page that supposedly take us to a page where 
explanation is given on each categories, does not clarify anything, as 
the explanations of the terms given there do not have the same meaning 
as the ones adopted by the Rev team. I once reported a bug as a 
'blocker', because it blocked development and testing, but was told 
that 'blockers' are supposed to be bugs that crash Revolution.

So, my suggestion is: PUT A GUIDELINE at the top of the search page 
(and the new bug report page) indicating what the categories mean. We 
all love Revolution, and we want to help you. Show us how to do it 
properly, how to do it in a way that is helpful to your team. We want 
to do it right, too!

Kind Regards,

--
Igor de Oliveira Couto
----------------------------------
igor at pixelmedia.com.au
----------------------------------




More information about the use-livecode mailing list