Bug submissions, Feature requests and Voting

Igor Couto igor at pixelmedia.com.au
Fri Sep 19 08:13:01 EDT 2003


Hey,  Jan!

On Friday, September 19, 2003, at 10:11  PM, Jan Schenkel wrote:

> I figured I'd better put in my two eurocents' worth
> before the end of the discussion this time ;-)
>
> Frankly, I think voting on bugs is a _bad_ idea.

I agree totally!

However, rather than appearing to be trying to teach people how to run 
their business, I took the approach of 'rolling with the punches', and 
just tried to use the provided strategy as best as I could...

Despite all the tremendous effort put in by the RunRev development team 
- and the fantastic work they have managed to carry out so far - I am 
afraid to admit also that, IMHO, Bugzilla simply does not work for the 
Revolution market... Bug-reporting systems that are perceived as 
complicated or cumbersome to use simply do not work - the information 
that is gathered simply isn't statistically representative of the true 
population (the users). And, obviously, a 'voting' system  that has to 
be used from INSIDE such a system would work even less - whatever 
information it is supposed to be gathering about the population may 
be...

Good bug reporting systems should be BUILT INTO the application. They 
have to be at the user's fingertips, to be acted upon AS THE BUG 
HAPPENS. They should be *extremely* intuitive, easy enough for even the 
novice user to operate - the LAST thing you want is for your users to 
see your bug reporting system as even more confusing and buggy than yor 
application. This should not be such a hard objective to achieve with 
Revolution...

What revolution needs is a plug-in that IS the bug reporting system, to 
be shipped with the program. I seem to have seen that someone (was it 
Ken Ray?) who is developing a Rev-like interface to Bugzilla. Something 
along those lines would be much more suited to this kind of application.

Bug reporting systems should also be EASILY searchable (and Bugzilla 
isn't), and it should help novices file reports that are appropriate - 
ie, directed at the appropriate area, using the correct jargon, etc. If 
that doesn't happen, then information is misfiled, you get enormous 
amounts of duplicate or closely related bugs, and searching the 
database becomes increasingly ineffective.

If the amount of information needed to complete even a simple bug 
report is too extensive, then the whole process should be broken down 
into easy steps, and users should perhaps be 'prompted along' with a 
series of dialogues, in a step1, step2, step3 kind of way - Bugzilla's 
options just seem too overwhelming.

As far as collecting feedback and general usage information from users, 
that could also be done from inside the application itself as well. 
User feedback can be asked unobtrusively, during a few different times 
in the development process. Users could be given the option of 
providing feedback to RunRev on registration, on upgrading, or even as 
an optional step when performing a distribution build. That type of 
feedback, of course, should be completely separate and appear to the 
user to have NOTHING to do with bug-reporting...

Anyway, just thought I'd let you know that I totally agree with you!

Cheers,

--
Igor de Oliveira Couto
----------------------------------
----------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3266 bytes
Desc: not available
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20030919/c2f76e27/attachment.bin>


More information about the use-livecode mailing list