William:
> where the programming effort to fix the funded bug will come from.
That's a very good que... - er, a good example of a reactionary and
blasphemous anti-bug question. I luvv buggs and perish the thought of
losing even a single precious one.
Actually we don't need to presume too much; the Mothership almost
certainly has some bug plans already in the works for the near future.
I'd bet on that.
But since my daily work often involves LC bugs, they are never
outta-sight, outta-mind. And there are more than a few. A good healthy
population indeed. It's not invisible. I'm knee-deep among the
(wonderful, blessed, amazing) bugs almost every single day in my job.
Can't help noticing when they pile up - and they have. Objectively, we
have to admit that the bugs are just as big a part of "what's happening"
here as any other news.
So here are a few other questions to ponder, and none of these are aimed
at you William; those are very good thoughts and I'm just adding a few
more as food for thought. I also think Richmond's bug-funding plans are
great. And other efforts.
1. Where do bugs actually come from? Do they spontaneously come into
existence, or do they originate from causes and events? ...
2. And therefore, if there isn't time to FIX them, then how is there
time to CREATE them in the first place?
Where does THAT time come from? Because yes, bugs are created, so often
people don't realize that, and it takes actual time and effort to create
bugs. Even though they may be very unconscious actions or omissions, yet
they were ultimately the product/result of intentional actions and
habits. Thus any techniques to reduce their creation in the first place
would be ... of course, would be a holocaust against bugs and something
I abhor as a dedicated bug-lover. But any profession including coding
can be done by two people for the same cost, yet have different results.
People can learn to improve habits and approaches.
3. Are there any other prerequisites to fixing bugs besides $$$ and
coders? Well, you sorta have to know they exist before you can fix them.
They have to be discovered, reciped, reported. Ironically some people
consider bug talk "negative" - especially if they don't stop to consider
what leads to the bug-fixing process. Someone has to notice it, or test
thoroughly and discover it, pin down, recipe, report. And usually that
simply doesn't happen by, well, keeping one's mind completely off bugs
and focusing entirely on the non-bug stuff. Quite the reverse!
4. Are there legitimate reasons for customers being sorta busy too, and
having their own financial responsibilities? In other words, should we
all devote ourselves largely to volunteer bugfixing, or to volunteer
recruiting for paid bugfixing? Working around bugs certainly can keep a
body busy. And (ever since LC 7) so can reporting bugs - LC 7 bugs are
still being reported, by the way. Too many bugs also reduce customer
efficiency. Oh yes, and then there's the original work itself, the thing
one was doing before confronting the bugs. I mention this because some
people who previously repeated the mantra "if you see it, report it" are
starting to say "do you want to just gripe, or actually do something
about it yourself!"
It's convincing, with "positive" spin - and I like the focus on
accomplishment. But unfortunately the mantra also comes at the expense
of some truth, implying that complainers may be lazy and motivated by
negativity while they twiddle thumbs and gripe rather than act. I supect
that many "complainers" - or in more unbiased and less negative terms,
"attention raisers" - are busy with a full plate and speak up while
taking a breather, about the relevant matters they've been dealing with
in LC, before diving right back in.
5. Finally, perhaps most importantly, is it simply unthinkable for the
creator of a subscription-style annual fee product to actually fix the
bugs of that product all by themselves? Should a subscribing customer be
able to have reasonable expectations of bug fixes, or is that completely
on the shoulders of the paying customer to pay for or perhaps DIY?
IMPORTANT NOTE - I'm not saying that this applies to LC themselves.
They've always fixed many bugs; they've more than proven their
responsible and dedicated habit of doing so, and no doubt that will
continue as usual. In fact, they just said as much, the way I read it.
I'm very confident of that, perhaps more so than anyone else here.
No, I'm asking this customer vs bug fix question to respond to these
community memes - there is currently a push by some to shift bug
responsibility to the customer, with very assertive arguments. The
effort to solve problems actively is useful, but the accompanying mantra
overlooks that not everyone at all times has free time, energy, and
money for such efforts.
A customer is actually doing a company a service by bringing attention
to a problem; an information asset. Customers need to understand that
features and fixes can take time, and releases can take time. But if the
"positivity" school of thought gets out of hand and discourages true
feedback, the result may be damage due to reduced awareness. Plus the
positivity mantra seems to be ironically characterized by labeling
everything and everyone else negative. Which is it again? :D
My concern for LC bugs is a reduction in "net" bugs over time and in any
given "final" version, especially some care during new product and
feature sprints, because without limiting the rate of introducing bugs,
it may be even more difficult to tackle them, even with extra efforts.
They can't sustainably be introduced faster than they can be fixed.
Also, standalones for end-users are built with a particular LC version.
Too often a new final version (compared to the previous final version)
fixes one or two problems relevant to a project while adding one or two
more, also relevant. Despite the multiple meanings of stable which we
know, there still is a need for getting closer to final version = pretty
reliable, with few bugs.
Those are the more serious questions behind my light-hearted bug-hugging
post.
> In that vein, perhaps a system of bidding for bug fixes on
> the “auction block” could be developed.
That would be a smart addition. I do think that paying for bug fixes for
a SUBSCRIPTION product should be an addition, and not a substitute for
company bug fixes - and I'm not implying that LC Ltd is moving away from
that. Just responding to some community memes.
As usual I didn't really have the time to comment here again, and going
in depth like this might even tempt a certain person famous for lengthy
posts (see the archives) to accuse me of a lengthy post. :D But I felt
that the memes and assumptions needed some balancing out. Ideas are
important! Some things are worth speaking up about.
This represents a break from work that includes doing precisely one of
the tasks necessary to help this bug problem - I've been finding and
reporting a big bodacious boatload of beautiful bouncing beastly bugs.
God bless 'em. All kinds of bugs. Plenty left, if you need some. ;) It's
interesting and fun work, I actually enjoy pinning down bugs, but when I
find too many for too long, I worry a bit.
I'm outta here again, back to coding and bug reporting! Take care. Nice
seeing everyone. And don't forget to hug a bug today, or else....
JJS:
> As long as you pay then everything gets fixed,
> even new tires and maintenance..
Yep! Very true point.
More often than you would suppose, a fix is worth extra payment,
especially for a much-needed quick fix or extra feature that enables a
product release.
BUT those are special cases. A punctual annual subscription model very
strongly implies some level of included maintenance. Once again, I'm
100% sure that LC believes in this principle too, no slur on them; just
generally discussing a topic that's already being discussed.
Meanwhile, from a variety of comments lately it's clear that people are
noticing the bugs. Hang in there people! Good things are coming....
Best wishes,
Curry K.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
