hair-pulling frustration
Richmond
richmondmathewson at gmail.com
Tue Nov 11 16:26:16 EST 2014
On 11/11/14 23:16, Richard Gaskin wrote:
> 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?
>
How about a series of T-shirts with insects all over them and the
LiveCode logo: and the words, "I've helped squash X bugs." where 'X' is
a number?
Fairly childish, but fun and effective!
Richmond.
More information about the use-livecode
mailing list