hair-pulling frustration

[Richard Gaskin]

Richmond wrote:

> On 11/11/14 21:55, Richard Gaskin wrote:
>> I agree, which is why it benefits no one more than ourselves to test
>> our work with pre-release versions.
> 
> That is, of course, very true.
> 
> Another idea that might not be bad, is to slow down the releases so
> there is more time for testing.

Agreed.  While v7 did have an unusually long test period as it was 
(first test build was release March 19), there are a couple rough edges 
in the "Stable" build that seem the sort of thing that might have been 
handled prior to that designation.


> I would love to do more testing (I do almost none) but do not have
> the time as I have a full work schedule both in terms of my
> teaching duties and my programming ones.

True, we can only afford the time we can afford.  Unicode's not very 
critical for my work, so most of my testing was with v6.7, testing v7 
only on Ubuntu and really only focused on the new Linux-specific 
additions there.

But when a given version has new features that seem useful to us, 
testing is critical to ensure that it'll do what we want to it do when 
the final build comes out.

And testing needn't necessarily be all that deep.  LiveCode has a lot 
going on, arguably more akin to an OS than to any consumer app.  We all 
do different things with it, and no one can guess the exact interaction 
of language elements we'll be using in our own scripts.

So while we can't be expected to test everything, if we only test our 
own apps with new builds that's usually all we need for our own work.  
Collectively, if we call just ensured that new features get implemented 
in ways we need, we'll all have what we want.

Rather than thinking about testing LiveCode, big as it is, it may be 
more helpful to think of it as testing you own app's functionality in 
the sliver of LiveCode that it uses.  Just test your own stuff, and your 
own needs will be addressed.


> Another idea would be to award "brownie points" to anyone who 
> identifies
> and documents a bug, and, after somebody has collected
> enough points they could receive some sort tangible reward.

That's a good idea, and one I know Ben is keenly interested in persuing. 
  In fact, he's brought it up in a couple of our Community meetings, but 
maybe you can help us out with some of the details we've been stuck on:

What sorts of perks would you find motivating, and at what level of 
testing effort or bug report count should they kick in?

-- 
  Richard Gaskin
  LiveCode Community Manager
  richard at livecode.org