'Community Beta' has lost its way [part 2]

Bernard Devlin revolution at knowledgeworks.plus.com
Tue May 15 05:21:10 EDT 2007


[continued]

I'm disappointed that people are focusing on how many people might  
have been affected by this particular bug, rather than wondering if  
perhaps the bug-squashing process is not going so well for those  
people outside of the Improve list.    Six months into what is being  
trumpeted as the best beta-process Runrev has ever had, should it  
really have taken upwards of 9 actions (and several hours of my  
time), just to get _any_ response to an 18-month-old bug report that  
was clearly receiving no attention?     Meanwhile in this blissful  
silence of non-communication, the Quality Manager is sending out  
emails saying they are "intending to shake out the last bugs prior to  
making this the official, retail version", which is "ready to ship  
[...] unless we find a [..] significant feature failure".   Earth  
calling Bill Marriott: Bug 3196 is a significant feature failure.

And bug 3196 is not the only one.

There are 50 other significant, outstanding, _confirmed_ bugs (i.e.  
those with a status of 'critical' or 'blocker').   It's true that  
Bugzilla lists 324 bugs which have been fixed since January 1st this  
year.  I'm very glad to see that so many bugs have been squashed.   
But by my estimation, a very significant minority of those bug-fixes  
are to do with the incorporation of the ex-Altuit products.  Of  
course, it is great for those users who had not previously bought  
those products, to now have them incorporated into 2.81.   But I  
maintain that it has been a distraction to have grouped the  
incorporation of those products into the Open Community Beta.

I'm not saying I expect every bug to have been fixed.  But I do think  
that this Beta has lost its way when the Quality Partner sends out  
multiple emails about removing the last few bugs and how there are no  
significant "feature failures", when there are still more than 50  
outstanding, confirmed, significant bugs.  Trying to draw his  
attention to one of these critical bugs was a total failure,  
consuming hours of my time.   Once again, it's a case of Runrev  
having no idea about how to set expectations -- all I got was more  
emails telling me how there are no more significant bugs, when  
staring me in the face was a bug, which at at the end of last year I  
had every reason to believe would have been fixed by now.

A few people have written lengthy emails to me in private, saying  
that they are glad that I brought up this issue.  To my surprise they  
are far more dissatisfied with the Community Beta than me, and some  
of them are seriously disenchanted with Revolution in general.  One  
of them has told me that he is part of a group of Rev users who are  
collectively in the process of looking at alternative development  
environments.  They must have their own reasons for not wanting to  
discuss these things on the list any longer.   I hope that my loud  
and dogged stance on this matter will give them some reason to stay  
and speak up.

I'm not saying that the release of 2.8.1 should be held up whilst the  
bug that particularly concerns me is fixed.  But I am saying that  
Runrev need to seriously address the ways in which they consistently  
mislead people -- Linux is coming in 2.7; no, it's coming in the  
2.7.5 beta; no, it's coming in the 2.9 beta; prove you have a bug,  
we'll fix it; there are no more significant feature failures; the  
Altuit products will be available in January 2007; version 2.7.5 will  
be a free update - no, it's version 2.9 that will be free  ....  I  
could go on and on.  I'm a huge fan of Revolution, but I'm frustrated  
by what seems to me to be a very poor management style.  If one sets  
expectations too high, one guarantees disappointment.

At the absolute minimum, there should have been a continually updated  
list showing the fixed bugs and the oustanding bugs, and explaining  
why decisions were made.  If by January I'd known that bug 3196 would  
require a total re-write of the OS X engine (maybe that is what is  
required), and that because of that requirement the bug had to wait  
until there were a group of bugs requiring that level of attention, I  
would have had my expectations properly set.   Such a list might have  
encouraged others to persist in making bug reports, knowing that the  
process was rational and measurable.


Regards

Bernard




More information about the use-livecode mailing list