Re: Give a bug a hug
It would help if Brian, Panos, Trevor (anybody who has got a setup ready to compile) created an idiots guide(s) as to what compilers to install, any land mines to cross any tricks that they have learnt etc because what seems to happen with me , I start something which doesn't put food on the table, spend 3 or 4 hours fighting non existent documentation - leave it for another day then probably have to start from scratch again when I've forgotten what i'd learnt, or deleted 35G of Visual strudio that i'd installed . Maybe a simpler (morons guide) version - an overview of the ide and understand (and modify ) it as a starter. Lagi On Fri, 11 Oct 2019 at 18:02, Heather Laine via use-livecode < use-livecode@lists.runrev.com> wrote: > For what its worth, I think this is the way to go. A totally community run > initiative, with a bounty on bug fixes. Someone or several someones outside > of the LiveCode team would need to take responsibility for setting up a > structure. We'd love to see bugs being fixed, by members of the community. > It's kind of the reason behind Open Source. There are plenty of bugs that > would be suitable, which don't require deep dives into the engine. Pull > requests arrive in the usual manner and get approved or fed back on in the > normal scheme of things by our team. If this could be encouraged by a > bounty on fixes, funded by the community, run by the community and entirely > outside of LiveCode Ltd.'s scope, what's not to like? Our overstretched > resources would be augmented by a community team, and the dual nature of > the licensing would bear fruit in a new and productive manner. I like it. > > Over to you. > > Best Regards, > > Heather > > > Heather Laine > Customer Services Manager > LiveCode Ltd > www.livecode.com > > > > > On 10 Oct 2019, at 22:17, Mike Kerner via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > wow, i managed to mute this conversation. fail. > > @paul, that's exactly why we ponied up, too, as an insurance policy. we > > have been burned by numerous organizations either abandoning their > software > > work product or disappearing. thankfully, for most of our > mission-critical > > stuff, we have, own, and maintain the source. > > @Sean, I'm not generally thinking of the underlying engine for the bounty > > program, I'm thinking of pieces in LCS/LCB. In those cases, the PR > doesn't > > get submitted to the LC repo until whatever step it was further down. > > There isn't any reason why private repos can't be used to manage this > > process, especially with submodules. The patrons would have access to > the > > repo, no one else would. > > As for the conversation about the unfinished projects that all of us > ponied > > up for on a promise, I 100% agree, which is why the funds are escrowed. > > The developer proposing a solution doesn't get paid until the patch is > > tested and approved by the patrons of the patch. > > > > On Wed, Oct 9, 2019 at 11:02 AM Bob Sneidar via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > >> +1 Richard. I got onboard with what user to be Runtime Revolution (I > think > >> it was version 2!) Where livecode is today is orders of magnitude more > than > >> it was when it first started. There was no datagrid. No way to display > >> tabular data apart from a very simple table field. No arrays. Difficult > and > >> confusing database APIs. No mobile support. The list goes on. > >> > >> LC is like a really good girlfriend. She isn't everything I ever wanted, > >> but she's good enough for me. :-) > >> > >> Bob S > >> > >> > >>> On Oct 8, 2019, at 19:49 , Richard Gaskin via use-livecode < > >> use-livecode@lists.runrev.com> wrote: > >>> > >>> Pi Digital wrote: > >>> > > On 8 Oct 2019, at 21:42, Richard Gaskin wrote: > > > > And here is a May 2016 update: > > > > > >> > https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/ > > > > > > A small number of people keep going round and round on this a large > > number of times. > > > > How many times will the same conversation happen before more recent > > information is absorbed? > > An excellent article. Which part was you pointing to in reference to > Lagi’s question about older campaigns funded that have still not met > the core? > >>> > >>> There's a section in the middle listing off the accomplishments since > >> the Kickstarter, and some of the discussion goes into how much of that > was > >> paid for out-of-pocket. > >>> > >>> > And which part do you refer to when asserting that absorption of info > is needed to reduce the same conversations recursion rate? > >>> > >>> The portion of Lagi's post I had originally quoted in my reply: > >>> > >>> This is what I was talking about being treated like mushrooms > >>> - no communication as to what the future holds.- rough timescales > >>> as to when new or reassigned resources will be
Re: Give a bug a hug
agree On Fri, Oct 11, 2019 at 3:15 PM hh via use-livecode < use-livecode@lists.runrev.com> wrote: > This is a wonderful project. > > Should be limited to bugs that are NOT regressions. > And instead extended by feature requests. > > ___ > 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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ 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
Re: Give a bug a hug
This is a wonderful project. Should be limited to bugs that are NOT regressions. And instead extended by feature requests. ___ 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
Re: Give a bug a hug
For what its worth, I think this is the way to go. A totally community run initiative, with a bounty on bug fixes. Someone or several someones outside of the LiveCode team would need to take responsibility for setting up a structure. We'd love to see bugs being fixed, by members of the community. It's kind of the reason behind Open Source. There are plenty of bugs that would be suitable, which don't require deep dives into the engine. Pull requests arrive in the usual manner and get approved or fed back on in the normal scheme of things by our team. If this could be encouraged by a bounty on fixes, funded by the community, run by the community and entirely outside of LiveCode Ltd.'s scope, what's not to like? Our overstretched resources would be augmented by a community team, and the dual nature of the licensing would bear fruit in a new and productive manner. I like it. Over to you. Best Regards, Heather Heather Laine Customer Services Manager LiveCode Ltd www.livecode.com > On 10 Oct 2019, at 22:17, Mike Kerner via use-livecode > wrote: > > wow, i managed to mute this conversation. fail. > @paul, that's exactly why we ponied up, too, as an insurance policy. we > have been burned by numerous organizations either abandoning their software > work product or disappearing. thankfully, for most of our mission-critical > stuff, we have, own, and maintain the source. > @Sean, I'm not generally thinking of the underlying engine for the bounty > program, I'm thinking of pieces in LCS/LCB. In those cases, the PR doesn't > get submitted to the LC repo until whatever step it was further down. > There isn't any reason why private repos can't be used to manage this > process, especially with submodules. The patrons would have access to the > repo, no one else would. > As for the conversation about the unfinished projects that all of us ponied > up for on a promise, I 100% agree, which is why the funds are escrowed. > The developer proposing a solution doesn't get paid until the patch is > tested and approved by the patrons of the patch. > > On Wed, Oct 9, 2019 at 11:02 AM Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> +1 Richard. I got onboard with what user to be Runtime Revolution (I think >> it was version 2!) Where livecode is today is orders of magnitude more than >> it was when it first started. There was no datagrid. No way to display >> tabular data apart from a very simple table field. No arrays. Difficult and >> confusing database APIs. No mobile support. The list goes on. >> >> LC is like a really good girlfriend. She isn't everything I ever wanted, >> but she's good enough for me. :-) >> >> Bob S >> >> >>> On Oct 8, 2019, at 19:49 , Richard Gaskin via use-livecode < >> use-livecode@lists.runrev.com> wrote: >>> >>> Pi Digital wrote: >>> > On 8 Oct 2019, at 21:42, Richard Gaskin wrote: > > And here is a May 2016 update: > > >> https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/ > > > A small number of people keep going round and round on this a large > number of times. > > How many times will the same conversation happen before more recent > information is absorbed? An excellent article. Which part was you pointing to in reference to Lagi’s question about older campaigns funded that have still not met the core? >>> >>> There's a section in the middle listing off the accomplishments since >> the Kickstarter, and some of the discussion goes into how much of that was >> paid for out-of-pocket. >>> >>> And which part do you refer to when asserting that absorption of info is needed to reduce the same conversations recursion rate? >>> >>> The portion of Lagi's post I had originally quoted in my reply: >>> >>> This is what I was talking about being treated like mushrooms >>> - no communication as to what the future holds.- rough timescales >>> as to when new or reassigned resources will be implemented - what >>> is the intention with sqlite, 2d physics, Audio >>> >>> He's one of about three people who keep going back to the Kickstarter >> list as some form of eternal damnation against the team, and he knows that >> I know that he's read comments here and in the forums from Kevin and other >> team members that have discussed all of that over and over and over and >> over again. >>> >>> How many times does Kevin need to post a mea culpa about being among the >> 80% of software project leaders that underestimated cost? Apparently half >> a dozen isn't enough. >>> >>> In summary: Most of the list was delivered, most of the remainder is in >> the DB as feature requests to be completed as resources permit. >>> >>> >>> Kevin, Heather, Mark and others have been very forthcoming here about >> what the company is working on, at least to the degree that this community >> allows. But there's not much allowance granted: >>> >>>
Re: Give a bug a hug
wow, i managed to mute this conversation. fail. @paul, that's exactly why we ponied up, too, as an insurance policy. we have been burned by numerous organizations either abandoning their software work product or disappearing. thankfully, for most of our mission-critical stuff, we have, own, and maintain the source. @Sean, I'm not generally thinking of the underlying engine for the bounty program, I'm thinking of pieces in LCS/LCB. In those cases, the PR doesn't get submitted to the LC repo until whatever step it was further down. There isn't any reason why private repos can't be used to manage this process, especially with submodules. The patrons would have access to the repo, no one else would. As for the conversation about the unfinished projects that all of us ponied up for on a promise, I 100% agree, which is why the funds are escrowed. The developer proposing a solution doesn't get paid until the patch is tested and approved by the patrons of the patch. On Wed, Oct 9, 2019 at 11:02 AM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > +1 Richard. I got onboard with what user to be Runtime Revolution (I think > it was version 2!) Where livecode is today is orders of magnitude more than > it was when it first started. There was no datagrid. No way to display > tabular data apart from a very simple table field. No arrays. Difficult and > confusing database APIs. No mobile support. The list goes on. > > LC is like a really good girlfriend. She isn't everything I ever wanted, > but she's good enough for me. :-) > > Bob S > > > > On Oct 8, 2019, at 19:49 , Richard Gaskin via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Pi Digital wrote: > > > > >> On 8 Oct 2019, at 21:42, Richard Gaskin wrote: > > >> > > >> And here is a May 2016 update: > > >> > > >> > https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/ > > >> > > >> > > >> A small number of people keep going round and round on this a large > > >> number of times. > > >> > > >> How many times will the same conversation happen before more recent > > >> information is absorbed? > > > > > > An excellent article. Which part was you pointing to in reference to > > > Lagi’s question about older campaigns funded that have still not met > > > the core? > > > > There's a section in the middle listing off the accomplishments since > the Kickstarter, and some of the discussion goes into how much of that was > paid for out-of-pocket. > > > > > > > And which part do you refer to when asserting that absorption of info > > > is needed to reduce the same conversations recursion rate? > > > > The portion of Lagi's post I had originally quoted in my reply: > > > >This is what I was talking about being treated like mushrooms > >- no communication as to what the future holds.- rough timescales > >as to when new or reassigned resources will be implemented - what > >is the intention with sqlite, 2d physics, Audio > > > > He's one of about three people who keep going back to the Kickstarter > list as some form of eternal damnation against the team, and he knows that > I know that he's read comments here and in the forums from Kevin and other > team members that have discussed all of that over and over and over and > over again. > > > > How many times does Kevin need to post a mea culpa about being among the > 80% of software project leaders that underestimated cost? Apparently half > a dozen isn't enough. > > > > In summary: Most of the list was delivered, most of the remainder is in > the DB as feature requests to be completed as resources permit. > > > > > > Kevin, Heather, Mark and others have been very forthcoming here about > what the company is working on, at least to the degree that this community > allows. But there's not much allowance granted: > > > > As they've explained many times, they've joined the majority of > companies less willing to offer loose projections about delivery times > precisely because of things like this. If they give a projected deadline > and circumstances change, it will become a dominant and repeated theme > among a very small but very vocal minority. This isn't unique to LC; their > previous candor was a distinction. Now they operate like everyone else, > because the moment they dare to discuss anything not already in the can > they expose themselves to a continuation of this same tediousness that > every other company figured out how to avoid by keeping cards close. > > > > Wanna know what Apple's working on for 2020? Good luck. > > > > -- > > Richard Gaskin > > Fourth World Systems > > Software Design and Development for the Desktop, Mobile, and the Web > > > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to
Re: Give a bug a hug
I think i miss some understanding from my part. Sqlite is supported and working ok right. So what's this with this library? Then second, Heather said that things now in FM will flow back into lc. Pi Digital via use-livecode schreef op 9 oktober 2019 14:53:16 CEST: >Can you provide the full link to the SQLite feature that was funded? > >Sean Cole >Pi Digital Prod Ltd > >> On 9 Oct 2019, at 13:47, Richard Gaskin via use-livecode > wrote: >> >> https://github.com/livecode/livecode >___ >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 -- Verstuurd vanaf mijn Android apparaat met K-9 Mail. ___ 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
Re: Give a bug a hug
+1 Richard. I got onboard with what user to be Runtime Revolution (I think it was version 2!) Where livecode is today is orders of magnitude more than it was when it first started. There was no datagrid. No way to display tabular data apart from a very simple table field. No arrays. Difficult and confusing database APIs. No mobile support. The list goes on. LC is like a really good girlfriend. She isn't everything I ever wanted, but she's good enough for me. :-) Bob S > On Oct 8, 2019, at 19:49 , Richard Gaskin via use-livecode > wrote: > > Pi Digital wrote: > > >> On 8 Oct 2019, at 21:42, Richard Gaskin wrote: > >> > >> And here is a May 2016 update: > >> > >> https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/ > >> > >> > >> A small number of people keep going round and round on this a large > >> number of times. > >> > >> How many times will the same conversation happen before more recent > >> information is absorbed? > > > > An excellent article. Which part was you pointing to in reference to > > Lagi’s question about older campaigns funded that have still not met > > the core? > > There's a section in the middle listing off the accomplishments since the > Kickstarter, and some of the discussion goes into how much of that was paid > for out-of-pocket. > > > > And which part do you refer to when asserting that absorption of info > > is needed to reduce the same conversations recursion rate? > > The portion of Lagi's post I had originally quoted in my reply: > >This is what I was talking about being treated like mushrooms >- no communication as to what the future holds.- rough timescales >as to when new or reassigned resources will be implemented - what >is the intention with sqlite, 2d physics, Audio > > He's one of about three people who keep going back to the Kickstarter list as > some form of eternal damnation against the team, and he knows that I know > that he's read comments here and in the forums from Kevin and other team > members that have discussed all of that over and over and over and over again. > > How many times does Kevin need to post a mea culpa about being among the 80% > of software project leaders that underestimated cost? Apparently half a > dozen isn't enough. > > In summary: Most of the list was delivered, most of the remainder is in the > DB as feature requests to be completed as resources permit. > > > Kevin, Heather, Mark and others have been very forthcoming here about what > the company is working on, at least to the degree that this community allows. > But there's not much allowance granted: > > As they've explained many times, they've joined the majority of companies > less willing to offer loose projections about delivery times precisely > because of things like this. If they give a projected deadline and > circumstances change, it will become a dominant and repeated theme among a > very small but very vocal minority. This isn't unique to LC; their previous > candor was a distinction. Now they operate like everyone else, because the > moment they dare to discuss anything not already in the can they expose > themselves to a continuation of this same tediousness that every other > company figured out how to avoid by keeping cards close. > > Wanna know what Apple's working on for 2020? Good luck. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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 ___ 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
Re: Give a bug a hug
Can you provide the full link to the SQLite feature that was funded? Sean Cole Pi Digital Prod Ltd > On 9 Oct 2019, at 13:47, Richard Gaskin via use-livecode > wrote: > > https://github.com/livecode/livecode ___ 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
Re: Give a bug a hug
Lagi Pittas - > I don't want to get into a Slanging match and I would never make it > personal. but we were never even given a basic system to enhance - > I Quote > > "Finally, remember, that this will all be open source code, built and > included in the community edition – you will be able to take it, adapt > it and help improve it!" https://github.com/livecode/livecode -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
Hi Richard, I don't want to get into a Slanging match and I would never make it personal. but we were never even given a basic system to enhance - I Quote "Finally, remember, that this will all be open source code, built and included in the community edition – you will be able to take it, adapt it and help improve it!" Now as you says let's move on Sincere Regards Lagi On Wed, 9 Oct 2019 at 13:29, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Lagi Pittas wrote: > > > I did absorb that - nearly 3 years ago - QED. > > It's three years more recent than the old list you keep raising. > > > > My major itch is the crowdfunding SPECIFICALLY for Sqlite > > Thank you! Specifics are the only way things can become actionable. > > What needs to be done with SqLite? > > > > with a manual and all that. > > What should be considered within the scope of the manual? LC itself is > pretty well documented these days, as is SqLite. What gap should we fill? > > SqLite is very popular in our community. I suspect it will not be hard > to gather resources for a docs project like this once we define what it > should cover. > > > > I respect your opinions but if 2016 is the latest "main update", > > then we have a difference of opinion on what good communication is. > > Yes, your reference to old materials being less than desirable is noted, > which is why the fixation on a list twice as old is mystifying. > > This mystery deepens considering the many discussions here and in the > forums about the Kickstarter list in which you were a participant. This > has been covered, every several months, with the latest round being just > a few months ago. I'm done repeating that conversation. > > Moving forward... > > Let's define specific actionable needs, and see what resources are > needed to put them into place. > > As an external, SqLite is particularly well suited for a wider range of > people to update. And as a popular component, we should be able to find > the resources to enhance it. > > If you would please describe what needs to be done in terms of > functionality and docs, let's make it so. > > > > I still think LC has more to recommend it than Xojo, B4X, HAX, > > Python... > > We have that in common, and I hope we always do. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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 > ___ 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
Re: Give a bug a hug
I'm less than convinced by the crowdfunding ideas that have been mentioned so far. But there is something that is important to understand: 1. All Kickstarter campaigns are 'all-or-nothing.' From the Kickstarter FAQ: "No one will be charged for a pledge towards a project unless it reaches its funding goal." 2. Indiegogo campaigns are EITHER 'flexible funding' (the money is taken whether or not the goal was reached) OR 'fixed funding' (the same as Kickstarter). Whether or not a crowdfunding angle is a good idea is a different issue. I just wanted to clarify the point about campaign goals and funding levels. 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
Re: Give a bug a hug
Lagi Pittas wrote: > I did absorb that - nearly 3 years ago - QED. It's three years more recent than the old list you keep raising. > My major itch is the crowdfunding SPECIFICALLY for Sqlite Thank you! Specifics are the only way things can become actionable. What needs to be done with SqLite? > with a manual and all that. What should be considered within the scope of the manual? LC itself is pretty well documented these days, as is SqLite. What gap should we fill? SqLite is very popular in our community. I suspect it will not be hard to gather resources for a docs project like this once we define what it should cover. > I respect your opinions but if 2016 is the latest "main update", > then we have a difference of opinion on what good communication is. Yes, your reference to old materials being less than desirable is noted, which is why the fixation on a list twice as old is mystifying. This mystery deepens considering the many discussions here and in the forums about the Kickstarter list in which you were a participant. This has been covered, every several months, with the latest round being just a few months ago. I'm done repeating that conversation. Moving forward... Let's define specific actionable needs, and see what resources are needed to put them into place. As an external, SqLite is particularly well suited for a wider range of people to update. And as a popular component, we should be able to find the resources to enhance it. If you would please describe what needs to be done in terms of functionality and docs, let's make it so. > I still think LC has more to recommend it than Xojo, B4X, HAX, > Python... We have that in common, and I hope we always do. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
Now I'm a little peeved. Richard said "He's one of about three people who keep going back to the Kickstarter list as some form of eternal damnation against the team, " Forget about the kickstarter - I will say it one more time There was crowd funding for a new Sqlite library with a timescale of 3 months (lets assume i'm wrong - 6 months - whose counting) running at the same time as that "update" of 2016. Even if they were a year late that would be understandable but producing nothing at all smacks of taking from Peter to pay Paul (there I said it). Richard I understand that LC for FM is what they are betting the farm on and I agree with them - I am just asking for some transparency - resources allocated. I'm not stupid to think that a small team can do everything promised but would 1 person allocated to finishing off all the other stuff be too much too ask? Lagi On Wed, 9 Oct 2019 at 03:57, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Pi Digital wrote: > > >> On 8 Oct 2019, at 21:42, Richard Gaskin wrote: > >> > >> And here is a May 2016 update: > >> > >> > > https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/ > >> > >> > >> A small number of people keep going round and round on this a large > >> number of times. > >> > >> How many times will the same conversation happen before more recent > >> information is absorbed? > > > > An excellent article. Which part was you pointing to in reference to > > Lagi’s question about older campaigns funded that have still not met > > the core? > > There's a section in the middle listing off the accomplishments since > the Kickstarter, and some of the discussion goes into how much of that > was paid for out-of-pocket. > > > > And which part do you refer to when asserting that absorption of info > > is needed to reduce the same conversations recursion rate? > > The portion of Lagi's post I had originally quoted in my reply: > > This is what I was talking about being treated like mushrooms > - no communication as to what the future holds.- rough timescales > as to when new or reassigned resources will be implemented - what > is the intention with sqlite, 2d physics, Audio > > He's one of about three people who keep going back to the Kickstarter > list as some form of eternal damnation against the team, and he knows > that I know that he's read comments here and in the forums from Kevin > and other team members that have discussed all of that over and over and > over and over again. > > How many times does Kevin need to post a mea culpa about being among the > 80% of software project leaders that underestimated cost? Apparently > half a dozen isn't enough. > > In summary: Most of the list was delivered, most of the remainder is in > the DB as feature requests to be completed as resources permit. > > > Kevin, Heather, Mark and others have been very forthcoming here about > what the company is working on, at least to the degree that this > community allows. But there's not much allowance granted: > > As they've explained many times, they've joined the majority of > companies less willing to offer loose projections about delivery times > precisely because of things like this. If they give a projected > deadline and circumstances change, it will become a dominant and > repeated theme among a very small but very vocal minority. This isn't > unique to LC; their previous candor was a distinction. Now they operate > like everyone else, because the moment they dare to discuss anything not > already in the can they expose themselves to a continuation of this same > tediousness that every other company figured out how to avoid by keeping > cards close. > > Wanna know what Apple's working on for 2020? Good luck. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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 > ___ 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
Re: Give a bug a hug
Dear Richard, I did absorb that - nearly 3 years ago - QED. My major itch is the crowdfunding SPECIFICALLY for Sqlite , with a manual and all that. I have gone round and round in this, NOT as often as I should, but only when a thread gets my back up. By the way I have 4 drafts I haven't sent (and Probably) won't for the last two threads because I know it would incense some people , nothing personal or ad homonym but facts. Problem is facts these days are how you perceive them rather than what they are - twas ever thus. I respect your opinions but if 2016 is the latest "main update", then we have a difference of opinion on what good communication is. I'm asking simple questions and getting "fuzzy" or no answers. - and I don't like that. I still think LC has more to recommend it than Xojo, B4X, HAX, Python (shouldn't even be compared), Purebasic etc Lazarus/Freepascal is definitely is totally cross platform and totally open source but I like LC better even though I was an Apple UCSD Pascal, Turbo Pascal and Delphi user in my youf. Regards Lagi On Tue, 8 Oct 2019 at 21:43, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Lagi Pittas wrote: > > > This is what I was talking about being treated like mushrooms - no > > communication as to what the future holds.- rough timescales > > as to when new or reassigned resources will be implemented - what > > is the intention with sqlite, 2d physics, Audio > > > > here is a 2014 update ... > > > > https://livecode.com/the-present-and-future-livecode/ > > And here is a May 2016 update: > > > https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/ > > > A small number of people keep going round and round on this a large > number of times. > > How many times will the same conversation happen before more recent > information is absorbed? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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 > ___ 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
Re: Give a bug a hug
Pi Digital wrote: >> On 8 Oct 2019, at 21:42, Richard Gaskin wrote: >> >> And here is a May 2016 update: >> >> https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/ >> >> >> A small number of people keep going round and round on this a large >> number of times. >> >> How many times will the same conversation happen before more recent >> information is absorbed? > > An excellent article. Which part was you pointing to in reference to > Lagi’s question about older campaigns funded that have still not met > the core? There's a section in the middle listing off the accomplishments since the Kickstarter, and some of the discussion goes into how much of that was paid for out-of-pocket. > And which part do you refer to when asserting that absorption of info > is needed to reduce the same conversations recursion rate? The portion of Lagi's post I had originally quoted in my reply: This is what I was talking about being treated like mushrooms - no communication as to what the future holds.- rough timescales as to when new or reassigned resources will be implemented - what is the intention with sqlite, 2d physics, Audio He's one of about three people who keep going back to the Kickstarter list as some form of eternal damnation against the team, and he knows that I know that he's read comments here and in the forums from Kevin and other team members that have discussed all of that over and over and over and over again. How many times does Kevin need to post a mea culpa about being among the 80% of software project leaders that underestimated cost? Apparently half a dozen isn't enough. In summary: Most of the list was delivered, most of the remainder is in the DB as feature requests to be completed as resources permit. Kevin, Heather, Mark and others have been very forthcoming here about what the company is working on, at least to the degree that this community allows. But there's not much allowance granted: As they've explained many times, they've joined the majority of companies less willing to offer loose projections about delivery times precisely because of things like this. If they give a projected deadline and circumstances change, it will become a dominant and repeated theme among a very small but very vocal minority. This isn't unique to LC; their previous candor was a distinction. Now they operate like everyone else, because the moment they dare to discuss anything not already in the can they expose themselves to a continuation of this same tediousness that every other company figured out how to avoid by keeping cards close. Wanna know what Apple's working on for 2020? Good luck. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
> On 8 Oct 2019, at 21:42, Richard Gaskin via use-livecode > wrote: > > And here is a May 2016 update: > > https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/ > > > A small number of people keep going round and round on this a large number of > times. > > How many times will the same conversation happen before more recent > information is absorbed? An excellent article. Which part was you pointing to in reference to Lagi’s question about older campaigns funded that have still not met the core? And which part do you refer to when asserting that absorption of info is needed to reduce the same conversations recursion rate? Note: I’m not inferring any kind of ill intent on LCs part. Just seeking clarification on up to date stances as a 2016 discussion is itself 3yrs old now. Sean Cole Pi Digital Prod Ltd ___ 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
Re: Give a bug a hug
Lagi Pittas wrote: > This is what I was talking about being treated like mushrooms - no > communication as to what the future holds.- rough timescales > as to when new or reassigned resources will be implemented - what > is the intention with sqlite, 2d physics, Audio > > here is a 2014 update ... > > https://livecode.com/the-present-and-future-livecode/ And here is a May 2016 update: https://livecode.com/trevor-devore-interviews-kevin-mark-on-infinite-livecode/ A small number of people keep going round and round on this a large number of times. How many times will the same conversation happen before more recent information is absorbed? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
On 10/8/2019 12:42 PM, Richard Gaskin via use-livecode wrote: Pi Digital wrote: > Forgive me for saying but, except the bounty idea, wasn’t this the > whole point of it going open source - so that the community would > fix bugs themselves! Personally, I try to avoid making claims about other people's internal motivations. Since I'm not them, such information is unknowable to me. I find it better to focus instead on what can be observed. Researchware (me) backed LiveCode's open source effort not because I ever expected to fix any bugs myself. I viewed the investment as corporate insurance. Both of our two commercial applications are developed in LiveCode. IF (and I hope it NEVER happens), something happened to LiveCode AND it went out of business AND no one else picked up support for the language, I wanted access to the LC source to be able to continue to develop our apps under LC rather than be forced to try to port them to some other language. Richard is right. People likely sponsored the open source effort for a wide variety of reasons. ___ 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
Re: Give a bug a hug
Pi Digital wrote: > Forgive me for saying but, except the bounty idea, wasn’t this the > whole point of it going open source - so that the community would > fix bugs themselves! Personally, I try to avoid making claims about other people's internal motivations. Since I'm not them, such information is unknowable to me. I find it better to focus instead on what can be observed. Maybe it's just a byproduct of having an audience in which such a large segment got started decades ago, in a time when dev tools were mostly proprietary, but I find the limited familiarity with what's happening in the world outside of LC may contribute to these frequent kvetchfests. In this second decade of the 21st century, with very few exceptions nearly all infrastructure and dev tools are open source. See the list of languages on the TIOBE list, and you can count on one hand the few that remain there which are proprietary. In this modern world, most devs won't even look at a dev tool unless they know they can have access to its source. That doesn't matter to consumers, which is why proprietary apps continue to thrive in consumer segments. But devs demand open source. So looking at this clear preference in the dev world, the choice to move LC to open source seems far less sinister than your presumption implies: Without open source, any dev tool is at serious risk of becoming inviable. What may seem exotic to those more familiar with closed-source tools is just how things work in open source. User contributions, bug bounties - none of this is contentious in communities experienced in open source process. And to be clear, in terms of actual usage LC is very much an open source project: More than 3/4 of its users are using the GPL-governed Community Edition. I wrote this yesterday, and I have no reason to mislead you, so please consider it as a key to understanding LC's place in the modern world: From an early-90s perspective, we can think of LC as a proprietary product that offers an open source option for evangelism. But in terms of actual usage in the here-and-now, LC is more accurately an open source project in which a subset of the development costs are subsidized by an optional proprietary license. New world, new ways -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
Hi All, If I can interject here. WHEN they have decided that they can add new resources (it used to be people but now we are all commodities) or reassign said resources to the LC branch rather than nearly all to the LC for FM branch. If LCFM becomes the cash cow then bugs will surely be fixed quicker and be inserted into the poor peasants branch (us with indy and business licences). The only problem with that is that the said bug to do with the native text field not working might never be fixed because it isn't a problem for the "Cash Cow" Branch. This could also mean that previously funded stuff (i'm beginning to sound like a broken clock - sqlite framework) might again still have less priority. This is what I was talking about being treated like mushrooms - no communication as to what the future holds.- rough timescales as to when new or reassigned resources will be implemented - what is the intention with sqlite, 2d physics, Audio here is a 2014 update ... https://livecode.com/the-present-and-future-livecode/ Open Language: With the core refactoring almost complete (LiveCode 7.0) we’ve started to turn our attention to the final aspect of this project which is to open up the language for extension by anyone. We have been prototyping for quite some time now and plans are in place to move this project forward at a rapid pace once LiveCode 7.0 is released. We will complete network, socket and database libraries with easy to use English like syntax as part of the development and testing of this feature. This is currently slated as one half of our next major release, currently imaginatively named “8.0”. Physics Engine Incorporate Box2D into LiveCode along with an animation loop feature. Network / Sockets Use new open language feature to implement Database Use new open language feature to implement. To my knowledge (I am willing/hoping to be wrong) not one of these has been implemented and I don't know if database included the Sqlite framework which had its own crowdfunding over 3 years ago and a 3 month implementation schedule. Open language was what got me to "bite the bullet" and move over to Livecode in the first place Is Open Language dead Mark? https://www.youtube.com/watch?v=KQveng3Wxz8 Regards Lagi On Tue, 8 Oct 2019 at 16:07, Pi Digital via use-livecode < use-livecode@lists.runrev.com> wrote: > > On 8 Oct 2019, at 14:52, Mike Kerner via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > • insert delay while patrons enjoy the benefit of financing the fix > > > How does this bit work. If the PR has been submitted, how will others > benefit unless a build is released? Who would be responsible for that > considering it’s complexity. > > Another thought is, who do you suppose has the necessary skills to do this > when it comes to coding in c++? Can we get a show of hands? (My hand is > down for this one) > > If it’s coded in LCS, how will you submit the PR considering LC do not > accept binaries. You have to write out all of your script changes long form > for them to review in person by hand/eye. > > Forgive me for saying but, except the bounty idea, wasn’t this the whole > point of it going open source - so that the community would fix bugs > themselves! Paid incentives may still not be enough seeing as the > majority are LC coders and not C++. You need people with the necessary > skills. > > Otherwise, a nice idea. > > Also, If two happen to work on the fix and submit pretty close to each > other (rare, I know) that may raise an interesting situation regarding the > split of bounty. But I’m sure would be sorted amicably. > > Sean Cole > Pi Digital Prod Ltd > ___ > 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 > ___ 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
Re: Give a bug a hug
Terry Judd wrote: > On 8/10/19, 4:34 pm, J. Landman Gay wrote: > >> I think the politicking was a big factor in killing the voting >> system. I remember many times when people would post to the list, >> urging others to cast a vote for an issue so it would rise to >> the top. Those voters may never have seen the bug but it sounded >> important and they had a vote or two to spare. > > I feel like there are plenty of ways that a point system that avoids > some of these issues with the previous one could be implemented - > fewer total votes per person, single votes per bug only... Already in place - from my post: There remains at least one element which could loosely be seen as a sort of voting: a bug's CC list. Usually an address will wind up there after that person has experienced the bug, searched the DB for it, and found that it had been reported. When that happens organically, the number of people subscribing to a bug can be a useful addition that, with the other details of the report, help the team evaluate priority. And being a single value per user, it's a single signal rather than a conflation of two different signals as the old form with multiple votes did, so it's more immediately clear what it's signifying. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
Pi Digital wrote: > If it’s coded in LCS, how will you submit the PR considering LC do not > accept binaries. With very few exceptions these days, most stacks throughout the IDE were rewritten as script-only stacks specifically to facilitate collaborative development. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
Small point on LCS... most things can probably be fixed by editing behavior scripts and not binary files. If a binary file needs to be updated, you can write a script to transform the binary and submit it (then a core team member can review and apply the change). I’ll agree that feature adds that make big changes to binary stacks will be a challenge for the community to submit. The above was more for small tweaks to binary UI files. Thanks, Brian On Oct 8, 2019, 11:08 AM -0400, Pi Digital via use-livecode , wrote: > > On 8 Oct 2019, at 14:52, Mike Kerner via use-livecode > > wrote: > > > > • insert delay while patrons enjoy the benefit of financing the fix > > > How does this bit work. If the PR has been submitted, how will others benefit > unless a build is released? Who would be responsible for that considering > it’s complexity. > > Another thought is, who do you suppose has the necessary skills to do this > when it comes to coding in c++? Can we get a show of hands? (My hand is down > for this one) > > If it’s coded in LCS, how will you submit the PR considering LC do not accept > binaries. You have to write out all of your script changes long form for them > to review in person by hand/eye. > > Forgive me for saying but, except the bounty idea, wasn’t this the whole > point of it going open source - so that the community would fix bugs > themselves! Paid incentives may still not be enough seeing as the > majority are LC coders and not C++. You need people with the necessary skills. > > Otherwise, a nice idea. > > Also, If two happen to work on the fix and submit pretty close to each other > (rare, I know) that may raise an interesting situation regarding the split of > bounty. But I’m sure would be sorted amicably. > > Sean Cole > Pi Digital Prod Ltd > ___ > 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 ___ 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
Re: Give a bug a hug
> On 8 Oct 2019, at 14:52, Mike Kerner via use-livecode > wrote: > > • insert delay while patrons enjoy the benefit of financing the fix How does this bit work. If the PR has been submitted, how will others benefit unless a build is released? Who would be responsible for that considering it’s complexity. Another thought is, who do you suppose has the necessary skills to do this when it comes to coding in c++? Can we get a show of hands? (My hand is down for this one) If it’s coded in LCS, how will you submit the PR considering LC do not accept binaries. You have to write out all of your script changes long form for them to review in person by hand/eye. Forgive me for saying but, except the bounty idea, wasn’t this the whole point of it going open source - so that the community would fix bugs themselves! Paid incentives may still not be enough seeing as the majority are LC coders and not C++. You need people with the necessary skills. Otherwise, a nice idea. Also, If two happen to work on the fix and submit pretty close to each other (rare, I know) that may raise an interesting situation regarding the split of bounty. But I’m sure would be sorted amicably. Sean Cole Pi Digital Prod Ltd ___ 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
Re: Give a bug a hug
i am so not being clear about this. i hate it when no one else understands what i'm not saying. i am not proposing a system that is either administered by LC or where LC is involved in the work. what i am proposing is that all of us control this process. it's our money, right? We propose the bounty, we control the bounty, and we pay the bounty. We don't care who collects the bounty (if LC grabs all of it then go LC), as long as the damn bug gets fixed, or the feature gets added, etc. If I was designing this thing, it might look like this _mikey's_crazy-dumb_bounty_program_ (v. 0.0.0.0.0.1) for the sake of this thing, "bugs" and "features" and everything else are the same. • bugs are nominated • in parallel estimates are submitted to fix a bug (both in terms of an ETA and a cost) and patrons put up coin either as pledges or better yet in escrow to finance fixing the bug, and include how long they're willing to have their funds tied up waiting. the estimates and the pledges stay under wraps. as of the bid-open date, all the estimators will know is if their estimate has been exceeded with the pledged (escrowed) funds. all the patrons know is that there are n estimates (which may be an integer or may be a range) that can be funded with the amount that has been escrowed. • the blackout period begins, set by a consensus of the estimators and the pledges and agreed to by both groups. at this point anyone on either side can pull out, and we reassess. all estimators that are under the pledge total get first crack at submitting a fix and collecting the bounty (their bid). if the time expires and no fix is submitted/passes initial tests, then the bug is opened up to anyone, and the escrowed amount is revealed. • if someone does not submit a fix, patrons can choose to remove funds, apply them to a different bug, or let funds ride until the bug is funded and someone decides to fix it. • if no fix is submitted, but someone comes along a year from now and says "hey, I can fix that for x", the original patrons are notified and given the opportunity to get back in. • if fix is accepted, patrons get access to it, and even though nobody cares, get their name put on it and in it • insert delay for patrons to test and report issues and for developer to fix • developer gets paid • insert delay while patrons enjoy the benefit of financing the fix • the fix is submitted as a PR to the rest of the world who didn't pony up for the fix ___ 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
Re: Give a bug a hug
On 8.10.19 11:35, Richmond wrote: "the severity of a bug be determined by the team" Presumably by "the team" you mean LiveCode Central? Somewhere in this discussion there was the idea that, perhaps, "the team" already had so much on their plate that both determining the severity of bugs and sorting them out were handled by people outwith "the team." Ouch: sorry: ". . . sorting them out BE handled by people . . ." Subjunctive woes! On 8.10.19 9:39, Mark Wieder via use-livecode wrote: On 10/7/19 10:13 PM, Richard Gaskin via use-livecode wrote: > I had extensive discussion about the Bugzilla voting system with Kevin, Mark Waddingham, and others there at LiveCode Ltd., in response to the reactions many members of our community (including yours truly) expressed when the voting was removed from the bug DB. > > What I learned was that although it seems like a good idea, in practice it winds up being a less useful indicator of the "importance" of a bug than one might intuitively think. > > In dry terms, one of the issues with it is that it conflates two very different signals: one for the severity of a bug to the individual experiencing it, and another for the number of people affected by the bug. Well, yes and no. But that's why I was suggesting that the severity of a bug be determined by the team, and not by a bug report's popularity. The CC field is somewhat useful, but nobody ever removes themselves from the field (is that even possible?), and stale votes can skew the benefits of the quantitative effects. Earlier I avoided commenting on the politicking and grandstanding issues concerning voting. There are interesting arguments around democracy and power in the Federalist Papers. For a voting framework we could do worse than adopt Scott Raney's proxyfor.me. ___ 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
Re: Give a bug a hug
"the severity of a bug be determined by the team" Presumably by "the team" you mean LiveCode Central? Somewhere in this discussion there was the idea that, perhaps, "the team" already had so much on their plate that both determining the severity of bugs and sorting them out were handled by people outwith "the team." On 8.10.19 9:39, Mark Wieder via use-livecode wrote: On 10/7/19 10:13 PM, Richard Gaskin via use-livecode wrote: > I had extensive discussion about the Bugzilla voting system with Kevin, Mark Waddingham, and others there at LiveCode Ltd., in response to the reactions many members of our community (including yours truly) expressed when the voting was removed from the bug DB. > > What I learned was that although it seems like a good idea, in practice it winds up being a less useful indicator of the "importance" of a bug than one might intuitively think. > > In dry terms, one of the issues with it is that it conflates two very different signals: one for the severity of a bug to the individual experiencing it, and another for the number of people affected by the bug. Well, yes and no. But that's why I was suggesting that the severity of a bug be determined by the team, and not by a bug report's popularity. The CC field is somewhat useful, but nobody ever removes themselves from the field (is that even possible?), and stale votes can skew the benefits of the quantitative effects. Earlier I avoided commenting on the politicking and grandstanding issues concerning voting. There are interesting arguments around democracy and power in the Federalist Papers. For a voting framework we could do worse than adopt Scott Raney's proxyfor.me. ___ 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
Re: Give a bug a hug
OK: I really need to clarify what I wrote there . . . "if that were the case . . ." What I meant is that, as far as I can see (pace Microsoft, Apple, et al), software developers release versions "into the wild" knowing that the chances of them being 100% bug-free is practically nil, and relying on end-users to spot those bugs and report back. Many long years ago (about 18) I worked on a CD about Music genres for Scottish schools, and my boss said he could not be bothered with beta testing because it would cost too much money. When the final thing (A Runtime Revolution standalone) had been burnt to disk he (my boss) found it contained one insignificant bug: he wasted an awful lot of time ranting at me. When he then decided to take me to court (!) he consulted a lawyer who laughed in his face and stated that a whole CD's worth of software with only 1 bug was nothing short of a miracle. What the chap should have done is come back to me with details of the bug so it could have been sorted out. What he actually did (!) was dump all the CDs and go to another company in Edinburgh who "re-did" the whole thing with MacroMedia Director that ended up crashing computers. Obviously, as his wife told me, a rather slow learner. Of course, of course, of course things would have been better had there been no bugs . . . Now there are companies who "jump on bugs" just as soon as end-users report them, and there are those who don't: and most software developers probably fall somewhere in between. "Sharing the burden" depends whether or not you want to buy into the Open Source story or the Commercial one: The Open Source story is based on a view of the world where everyone is into caring-and-sharing in a big hearted sort of way and is prepared to "pay" for 'free' software by pitching into to do stuff such as fixing bugs. The Commercial story is based on a world view where customers pay and developers deliver, and customers have all sorts of rights of redress if they don't get what they have paid for. The slight problem is that LiveCode is currently taking part in both stories simultaneously, and it seems that none of the end-users are completely convinced of the validity of either story. On 7.10.19 23:45, Bob Sneidar via use-livecode wrote: On Oct 7, 2019, at 13:42 , Richmond via use-livecode wrote: 1. people feel that the company responsible for producing some software should bear full responsibility for fixing bugs. Mind you, if that were the case I don't think there would be anyone developing any software anywhere at all. Really? What other software company shares the burden of bug fixing with it's clientele? Bob S ___ 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 ___ 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
Re: Give a bug a hug
On 10/7/19 10:13 PM, Richard Gaskin via use-livecode wrote: > I had extensive discussion about the Bugzilla voting system with Kevin, Mark Waddingham, and others there at LiveCode Ltd., in response to the reactions many members of our community (including yours truly) expressed when the voting was removed from the bug DB. > > What I learned was that although it seems like a good idea, in practice it winds up being a less useful indicator of the "importance" of a bug than one might intuitively think. > > In dry terms, one of the issues with it is that it conflates two very different signals: one for the severity of a bug to the individual experiencing it, and another for the number of people affected by the bug. Well, yes and no. But that's why I was suggesting that the severity of a bug be determined by the team, and not by a bug report's popularity. The CC field is somewhat useful, but nobody ever removes themselves from the field (is that even possible?), and stale votes can skew the benefits of the quantitative effects. Earlier I avoided commenting on the politicking and grandstanding issues concerning voting. There are interesting arguments around democracy and power in the Federalist Papers. For a voting framework we could do worse than adopt Scott Raney's proxyfor.me. -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Give a bug a hug
I feel like there are plenty of ways that a point system that avoids some of these issues with the previous one could be implemented - fewer total votes per person, single votes per bug only, no or reduced value votes for community users, forced re-allocation of votes on a regular basis... Yep, comments are a useful measure too - give them a value as well, maybe even allow someone who has used up all their votes to 'mine' some new ones that way - I reckon it shows they are engaged and contributing. Terry... On 8/10/19, 4:34 pm, "use-livecode on behalf of J. Landman Gay via use-livecode" wrote: I think the politicking was a big factor in killing the voting system. I remember many times when people would post to the list, urging others to cast a vote for an issue so it would rise to the top. Those voters may never have seen the bug but it sounded important and they had a vote or two to spare. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On October 8, 2019 12:15:23 AM Richard Gaskin via use-livecode wrote: > Terry Judd wrote: > > > I'd totally forgotten about the Bugzilla voting system. I liked that > > approach as well and agree that bringing it back could help both us > > and LC to prioritise fixes. > > Voting is one of those things that has a certain ring of rightness about > it (who doesn't love democracy?), and it's technically easy to do - so > why not? > > It turns out that people are much more complicated than the systems we > create. :) > > I had extensive discussion about the Bugzilla voting system with Kevin, > Mark Waddingham, and others there at LiveCode Ltd., in response to the > reactions many members of our community (including yours truly) > expressed when the voting was removed from the bug DB. > > What I learned was that although it seems like a good idea, in practice > it winds up being a less useful indicator of the "importance" of a bug > than one might intuitively think. > > In dry terms, one of the issues with it is that it conflates two very > different signals: one for the severity of a bug to the individual > experiencing it, and another for the number of people affected by the bug. > > In practice, these are some of how it played out: > > If I happen to feel a bug is super important, but five others think it's > merely worth reporting but isn't shutting down their work, my single > five-vote click doubles the number of votes. What does that mean? > > We know it doesn't mean ten people find it unimportant. And it doesn't > mean that two people find it extremely important. > > To fully understand exactly what a given tally score means requires > looking at the vote distribution, and also at the individual voters and > the details of their comments in the report. > > So if I feel like casting five votes against it there's no way to know > whether I'm actually having an urgent need, or just having a mood to > make a point about the age of the report, or any number of things. I > might have also contributed a comment or example which could explain my > intention, or no further information at all. > > And from time to time we may have a bug that's really critical, but so > far seen by fewer people. Such a report may have far fewer votes than > one that has little harmful effect but has been seen more frequently. > > And then there are the times one of us will get particularly incensed > about a pet issue (some of you may recall times I've done this myself), > and we rant about it here and encourage votes for the pet issue. I'm > sure some of those votes were people who actually experienced the issue, > but I'm equally sure some of those were just friendly people being > supportive, and not votes that would have arrived there organically > without the politicking. > > Give it some time and each of us can imagine other scenarios that muddy > the clarity of that vote signal. > > By the time a developer working on the bug looks at the various aspects > relevant to understanding what the vote tally really means, there's > enough familiarity with the details that an assessment of priority can > be made just as easily without it. > > > There remains at least one element which could loosely be seen as a sort > of voting: a bug's CC list. > > Usually an address will wind up there after that person has experienced > the bug, searched the DB for it, and found that it had been reported. > When that happens organically, the number of people subscribing to a bug > can be a useful addition that, with the other details of the report, > help the team evaluate priority. > >
Re: Give a bug a hug
I think the politicking was a big factor in killing the voting system. I remember many times when people would post to the list, urging others to cast a vote for an issue so it would rise to the top. Those voters may never have seen the bug but it sounded important and they had a vote or two to spare. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On October 8, 2019 12:15:23 AM Richard Gaskin via use-livecode wrote: Terry Judd wrote: > I'd totally forgotten about the Bugzilla voting system. I liked that > approach as well and agree that bringing it back could help both us > and LC to prioritise fixes. Voting is one of those things that has a certain ring of rightness about it (who doesn't love democracy?), and it's technically easy to do - so why not? It turns out that people are much more complicated than the systems we create. :) I had extensive discussion about the Bugzilla voting system with Kevin, Mark Waddingham, and others there at LiveCode Ltd., in response to the reactions many members of our community (including yours truly) expressed when the voting was removed from the bug DB. What I learned was that although it seems like a good idea, in practice it winds up being a less useful indicator of the "importance" of a bug than one might intuitively think. In dry terms, one of the issues with it is that it conflates two very different signals: one for the severity of a bug to the individual experiencing it, and another for the number of people affected by the bug. In practice, these are some of how it played out: If I happen to feel a bug is super important, but five others think it's merely worth reporting but isn't shutting down their work, my single five-vote click doubles the number of votes. What does that mean? We know it doesn't mean ten people find it unimportant. And it doesn't mean that two people find it extremely important. To fully understand exactly what a given tally score means requires looking at the vote distribution, and also at the individual voters and the details of their comments in the report. So if I feel like casting five votes against it there's no way to know whether I'm actually having an urgent need, or just having a mood to make a point about the age of the report, or any number of things. I might have also contributed a comment or example which could explain my intention, or no further information at all. And from time to time we may have a bug that's really critical, but so far seen by fewer people. Such a report may have far fewer votes than one that has little harmful effect but has been seen more frequently. And then there are the times one of us will get particularly incensed about a pet issue (some of you may recall times I've done this myself), and we rant about it here and encourage votes for the pet issue. I'm sure some of those votes were people who actually experienced the issue, but I'm equally sure some of those were just friendly people being supportive, and not votes that would have arrived there organically without the politicking. Give it some time and each of us can imagine other scenarios that muddy the clarity of that vote signal. By the time a developer working on the bug looks at the various aspects relevant to understanding what the vote tally really means, there's enough familiarity with the details that an assessment of priority can be made just as easily without it. There remains at least one element which could loosely be seen as a sort of voting: a bug's CC list. Usually an address will wind up there after that person has experienced the bug, searched the DB for it, and found that it had been reported. When that happens organically, the number of people subscribing to a bug can be a useful addition that, with the other details of the report, help the team evaluate priority. And being a single value per user, it's a single signal rather than a conflation of two different signals as the old form with multiple votes did, so it's more immediately clear what it's signifying. -- Richard Gaskin LiveCode Community Liaison ___ 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 ___ 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
Re: Give a bug a hug
Terry Judd wrote: > I'd totally forgotten about the Bugzilla voting system. I liked that > approach as well and agree that bringing it back could help both us > and LC to prioritise fixes. Voting is one of those things that has a certain ring of rightness about it (who doesn't love democracy?), and it's technically easy to do - so why not? It turns out that people are much more complicated than the systems we create. :) I had extensive discussion about the Bugzilla voting system with Kevin, Mark Waddingham, and others there at LiveCode Ltd., in response to the reactions many members of our community (including yours truly) expressed when the voting was removed from the bug DB. What I learned was that although it seems like a good idea, in practice it winds up being a less useful indicator of the "importance" of a bug than one might intuitively think. In dry terms, one of the issues with it is that it conflates two very different signals: one for the severity of a bug to the individual experiencing it, and another for the number of people affected by the bug. In practice, these are some of how it played out: If I happen to feel a bug is super important, but five others think it's merely worth reporting but isn't shutting down their work, my single five-vote click doubles the number of votes. What does that mean? We know it doesn't mean ten people find it unimportant. And it doesn't mean that two people find it extremely important. To fully understand exactly what a given tally score means requires looking at the vote distribution, and also at the individual voters and the details of their comments in the report. So if I feel like casting five votes against it there's no way to know whether I'm actually having an urgent need, or just having a mood to make a point about the age of the report, or any number of things. I might have also contributed a comment or example which could explain my intention, or no further information at all. And from time to time we may have a bug that's really critical, but so far seen by fewer people. Such a report may have far fewer votes than one that has little harmful effect but has been seen more frequently. And then there are the times one of us will get particularly incensed about a pet issue (some of you may recall times I've done this myself), and we rant about it here and encourage votes for the pet issue. I'm sure some of those votes were people who actually experienced the issue, but I'm equally sure some of those were just friendly people being supportive, and not votes that would have arrived there organically without the politicking. Give it some time and each of us can imagine other scenarios that muddy the clarity of that vote signal. By the time a developer working on the bug looks at the various aspects relevant to understanding what the vote tally really means, there's enough familiarity with the details that an assessment of priority can be made just as easily without it. There remains at least one element which could loosely be seen as a sort of voting: a bug's CC list. Usually an address will wind up there after that person has experienced the bug, searched the DB for it, and found that it had been reported. When that happens organically, the number of people subscribing to a bug can be a useful addition that, with the other details of the report, help the team evaluate priority. And being a single value per user, it's a single signal rather than a conflation of two different signals as the old form with multiple votes did, so it's more immediately clear what it's signifying. -- Richard Gaskin LiveCode Community Liaison ___ 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
Re: Give a bug a hug
On 8/10/19, 11:02 am, "use-livecode on behalf of Mark Wieder via use-livecode" wrote: Back in the old days LC/RR had a voting system on bugzilla. You had five votes you could allocate to bug reports, and this gave an indication of how many people were affected by a given bug. Since you have a limited number of votes, you get to select your Top Five - if a bug no longer affects you as much you can rescind that vote and allocate it to another report. I think reinstating this would be part of the solution. But there's another quantitative ranking which has to come from the team, and that involves both bug severity and urgency/priority. I think with those three vectors of information (and perhaps a fourth, an estimate of the amount of work required to address the bug; although I've always hated to have to estimate that and end up being wildly optimistic) it might be possible to have a reasonable estimate of what it would take to get a given bug fixed. I'd totally forgotten about the Bugzilla voting system. I liked that approach as well and agree that bringing it back could help both us and LC to prioritise fixes. I like your other suggestions as well. Hopefully the additional workload (for LC) to implement them would be manageable though and wouldn't place unnecessary additional strain on their bug fixing efforts ;) Terry... ___ 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
Re: Give a bug a hug
On 10/7/19 4:31 PM, Terry Judd via use-livecode wrote: These seem to be bounties for finding critical (mostly security-related) bugs rather than fixing them - hard to see large tech companies outsourcing their security fixes. You'd have to separate proprietary from FOSS products here. One of the primary drivers of open-source software is that the innards are there for you to poke around in and fix. It's a community effort based on making the product better for everyone. If you find a bug, submit a patch that fixes it. That becomes part of the core and everybody's happy. A reason that security bugs are reported often on proprietary software is that they're relatively easy to spot without having access to the source code. But this is more on the level of "here's the symptom, here's what you should do to fix it, now it's up to you to fix". We already have an established system for reporting bugs, and LC are actively attending to fixing some/most of them. The problem (real or perceived) seems to be that either some bugs are left unattended for too long, or appear to attract such a low priority that they are effectively abandoned. Maybe a bounty system could work if LC were prepared to tag bugs all bugs with a priority level, with each level having an estimated fix time associated with it. This would provide us (as potential clients of bounty hunters) with a semi-objective indication of whether it was worth stumping up some cash for a quick fix or simply waiting for LC to act. More work for LC though, tagging bugs and updating those tags fairly regularly. Back in the old days LC/RR had a voting system on bugzilla. You had five votes you could allocate to bug reports, and this gave an indication of how many people were affected by a given bug. Since you have a limited number of votes, you get to select your Top Five - if a bug no longer affects you as much you can rescind that vote and allocate it to another report. I think reinstating this would be part of the solution. But there's another quantitative ranking which has to come from the team, and that involves both bug severity and urgency/priority. I think with those three vectors of information (and perhaps a fourth, an estimate of the amount of work required to address the bug; although I've always hated to have to estimate that and end up being wildly optimistic) it might be possible to have a reasonable estimate of what it would take to get a given bug fixed. My two centavos for the day. -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Give a bug a hug
Terry Judd wrote: > These seem to be bounties for finding critical (mostly security- > related) bugs rather than fixing them - hard to see large tech > companies outsourcing their security fixes. Yes, probably not the best examples. I could dig up others, but sometimes I feel like there would still be some way to pick it apart, and I'm not interested in spending my afternoon chasing sea lions. The bottom line is the bottom line: the cost of work needed to support the feature set across the full range of supported platforms AND also attempt to be the only player with a million-line code base that's bug-free is greater than the revenue from the slender of subset of people who subsidize that work through proprietary licensing. We can ask for anything, but wishing alone doesn't make it so. The other day I stood on my roof and demanded an end to world hunger. When I got down the ladder I was still in a world where half of humanity goes to bed hungry every day. So instead I carry snacks on my bike, and when I'm out I give an apple or an orange to homeless people I meet. I'm not able to solve the global problem, but I can help alleviate it locally. A sizable percentage of LC's bugs are in the IDE, written in the same language we all use. Any of us could fix them, given the time. And there's the rub: "given the time". Time constraints are a key factor with most human endeavors. Engine fixes will require something more, C++ skills not common in our scripting community. The company pays for most of those, and once in a while folks in the community will pay for a fix or a feature here and there. Everyone does what they can to have what they want. It's not the most exotic notion in the world for people who want something to gather resources needed to have it. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
These seem to be bounties for finding critical (mostly security-related) bugs rather than fixing them - hard to see large tech companies outsourcing their security fixes. We already have an established system for reporting bugs, and LC are actively attending to fixing some/most of them. The problem (real or perceived) seems to be that either some bugs are left unattended for too long, or appear to attract such a low priority that they are effectively abandoned. Maybe a bounty system could work if LC were prepared to tag bugs all bugs with a priority level, with each level having an estimated fix time associated with it. This would provide us (as potential clients of bounty hunters) with a semi-objective indication of whether it was worth stumping up some cash for a quick fix or simply waiting for LC to act. More work for LC though, tagging bugs and updating those tags fairly regularly. Terry... On 8/10/19, 9:57 am, "use-livecode on behalf of Richard Gaskin via use-livecode" wrote: Bob Sneidar wrote: > What other software company shares the burden of bug fixing with > it's clientele? Bug bounties are pretty common. https://www.guru99.com/bug-bounty-programs.html https://gadgets.ndtv.com/internet/features/bug-bounty-hunters-and-the-companies-that-pay-them-820636 https://gadgets.ndtv.com/internet/features/bug-bounty-hunters-and-the-companies-that-pay-them-820636 -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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 ___ 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
Re: Give a bug a hug
Bob Sneidar wrote: >> On Oct 7, 2019, at 15:56 , Richard Gaskin wrote: >> >> Bug bounties are pretty common. > > Interesting, but these are professional developers, right? Not common > end users. LiveCode is a developer tool. We use it to make software for end-users. A lot of discussion around LC's business is based around the world of software that was prevalent when most of us got started. Back in the '90s most development tools were proprietary, and open source was just getting started. Indeed, in the first half of the '90s there were very few viable open source projects. Nearly everything, even dev tools, were proprietary. That world is gone. In the 21st century, while proprietary software still thrives in consumer segments, infrastructure and dev tools are predominantly open source. LiveCode is no exception: More than 3/4 of its users are using the GPL-governed Community Edition. From an early-90s perspective, we can think of LC as a proprietary product that offers an open source option for evangelism. But in terms of actual usage in the here-and-now, LC is more accurately an open source project in which a subset of the development costs are subsidized by an optional proprietary license. New world, new ways -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
Interesting, but these are professional developers, right? Not common end users. I'm just taken aback by the notion that no one would ever develop software again if they had to fix all the bugs themselves. Bob S > On Oct 7, 2019, at 15:56 , Richard Gaskin via use-livecode > wrote: > > Bob Sneidar wrote: > > > What other software company shares the burden of bug fixing with > > it's clientele? > > > Bug bounties are pretty common. ___ 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
Re: Give a bug a hug
Bob Sneidar wrote: > What other software company shares the burden of bug fixing with > it's clientele? Bug bounties are pretty common. https://www.guru99.com/bug-bounty-programs.html https://gadgets.ndtv.com/internet/features/bug-bounty-hunters-and-the-companies-that-pay-them-820636 https://gadgets.ndtv.com/internet/features/bug-bounty-hunters-and-the-companies-that-pay-them-820636 -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Give a bug a hug
Huh? I'm suggesting that this be taken the direction of a bounty. ___ 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
Re: Give a bug a hug
> On Oct 7, 2019, at 13:42 , Richmond via use-livecode > wrote: > > 1. people feel that the company responsible for producing some software > should bear full > responsibility for fixing bugs. > > Mind you, if that were the case I don't think there would be anyone > developing any software anywhere at all. Really? What other software company shares the burden of bug fixing with it's clientele? Bob S ___ 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
Re: Give a bug a hug
Cripes . . . this is turning out to be a right can of worms . . . and, obviously, there is an awful lot of reluctance to sponsor/donate for bug fixes. Let me attempt to summarise so far: 1. people feel that the company responsible for producing some software should bear full responsibility for fixing bugs. Mind you, if that were the case I don't think there would be anyone developing any software anywhere at all. 2. People feel that "another: KickStarter 'thing' for bugfixes might end up as a blackhole swallowing their moolah with no guarantee of getting what they have stumped up their hard earned bucks for. Well . . . Yes . . . I can see both those points of view as perfectly valid . . . But the simple fact is, like it or not, LiveCode has got some long-standing bugs that at least some people feel are show-stoppers, and the people at LiveCode Central do not seem to be able to do much about them: Why? Well; here are a few possible reasons: 1. They have "bitten of more than they can chew" insofar that they have committed themselves to such a lot of work in terms of continuing development they just don't have the time or resources to get down to the bugs. [This is why I suggested that LiveCode Central might like to consider taking a period "off" their continuing development to retrench and devote that period of time to attacking those bugs - this, of course, presupposes they all have sufficient funds to put food in their fridges.] 2. They are undermanned. 3. They are underfunded. 4. They expected more "outside help" after they set up their Open Source version. And #2, #3 and #4 might be sides of the same coin. And if "We" don't do something about those bugs they may languish there forever. Now an idea, which may be about as bonkers as most of my other ideas, is this: Over on the bug-reporting system (or linked to it) have a system where a price is attached to "the head" of the most pernicious bugs. Individuals would be then welcome to donate funds to specific bugs, and once the price has been raised other individuals would be welcome to attempt to fix the bug, for which, if they can properly demonstrate they have fixed it, they get the bounty. There would, of necessity, need to be an overseer of this whole project. On 7.10.19 23:02, Mark Wieder via use-livecode wrote: On 10/7/19 7:57 AM, Mike Kerner via use-livecode wrote: there isn't any reason why bug bounties have to all go to the mothership. you're (for lack of a better word) kickstarting a bug fix. it's a bounty. it should go to the person who delivers the fix, the bounty hunter. Um, no. You'd be giving money to someone in the hopes that enough others will also do the same to reach the goal required to attempt to fix the bug. But you're charged whether or not the goal is reached. And whether or not the bug actually gets fixed. It's a bad fit, and the only way I'd ever put money into this kind of scheme is once enough other fools have done so and the goal has been met *and* I think there's a reasonable chance the bug might get fixed in a timely manner. Look at the number of folks who complain about not having feature x from the LC Kickstarter campaign, where there was explicitly no guarantee of features actually appearing. Now extrapolate to a campaign where you end up paying into a scheme whether or not anything actually materializes. ___ 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
Re: Give a bug a hug
On 10/7/19 7:57 AM, Mike Kerner via use-livecode wrote: there isn't any reason why bug bounties have to all go to the mothership. you're (for lack of a better word) kickstarting a bug fix. it's a bounty. it should go to the person who delivers the fix, the bounty hunter. Um, no. You'd be giving money to someone in the hopes that enough others will also do the same to reach the goal required to attempt to fix the bug. But you're charged whether or not the goal is reached. And whether or not the bug actually gets fixed. It's a bad fit, and the only way I'd ever put money into this kind of scheme is once enough other fools have done so and the goal has been met *and* I think there's a reasonable chance the bug might get fixed in a timely manner. Look at the number of folks who complain about not having feature x from the LC Kickstarter campaign, where there was explicitly no guarantee of features actually appearing. Now extrapolate to a campaign where you end up paying into a scheme whether or not anything actually materializes. -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Give a bug a hug
> On Oct 5, 2019, at 16:10 , Mark Wieder via use-livecode > wrote: > > Happily most of the efforts I've helped fund on Kickstarter have reached > conclusions (the Deathstar never got completely funded). So they say... ___ 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
Re: Give a bug a hug
there isn't any reason why bug bounties have to all go to the mothership. you're (for lack of a better word) kickstarting a bug fix. it's a bounty. it should go to the person who delivers the fix, the bounty hunter. ___ 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
Re: Give a bug a hug
On 6.10.19 2:19, Curry Kenworthy via use-livecode wrote: Because yes, bugs are created Indeed they are: this is all something to do with the law of unintended consequences, the double-effect argument and so on. I certainly DON'T believe in people at LiveCode central deliberately creating bugs. Consider for a moment how complicated a beast LiveCode is, and realise how inter-connected so much of it is . . . . . . I suffer from chronic back-pain, and I could have an operation to sort it out, even supposing I escape the 40% chance of ending up in a wheel-chair, there will be all sorts of side-effects . . . in fact my favourite orthopaedic surgeon (who is taller than me and also suffers from chronic back-pain) spent a "pleasant" couple of hours totting up the negative consequences of getting rid of the excruciating pain that hits us both once every one to two months and deciding it just wasn't worth it. There is even the distinct possibility that sorting out certain particularly pernicious bugs in LiveCode could give rise to more bugs. ___ 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
Re: Give a bug a hug
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
Re: Give a bug a hug
On 10/5/19 12:27 PM, Richmond via use-livecode wrote: Well, well, well . . . out of the smoke a phoenix arises . . . I am in contact "with those who know what they are doing" with a mind to try to set up an "adopt a bug" scheme. But the real b*gger is how on earth to do some sort of triage on outstanding bugs and find out which ones: 1. Are sortable-outable. and of those: 2. Which ones actually justify time, money and effort. It may be even more complicated than that, and I would think very deeply about this before jumping in. Kickstarter facilitates raising money for a given project, but they're very upfront about the fact that any given project may or may not materialize - you're funding the effort, not the finished product. Nonetheless, people get upset when they've funded a project that doesn't reach completion, or even ones that take much longer than originally expected. Happily most of the efforts I've helped fund on Kickstarter have reached conclusions (the Deathstar never got completely funded). With Indiegogo you're taking that paradigm even one step farther, because people will be paying to have bugs fixed whether or not they actually end up getting fixed. And part of that depends on raising the goal you're going to set for fixing a certain bug. So let's say you end up raising 75% of your goal for bug x. On Kickstarter nobody would be charged because you haven't met your goal. On Indiegogo everybody who paid to get the bug fixed would be charged what they pledged, but now you're left with not enough money to fund getting the bug fixed. And you've got everyone upset that you've taken their money and still not fixed that bug. So what's the way out? *YOU* put up the money to get the bug fixed, then set up an Indiegogo page to get paid back. Not a pretty sight. -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Give a bug a hug
I find this whole idea rather strange, although i understand where it is coming from. But, for example when i buy a car and it has bugs (in the warranty period) it gets fixed for free. Even if the car is out of warranty then some are called back to fix a safety item, also for free. If it is out of warranty, you have to pay.(like you don't pay anymore for LC subscription) You can also compare your LC subscription with a (company/private) lease car. As long as you pay then everything gets fixed, even new tires and maintenance. For things to be fixed more quickly in the Community version or new wanted features i can imagine to have it fixed more quickly by funding it. So maybe i can sell my software and if it has bugs, well..you have to pay more to get it fixed. I really doubt if you can find people (except for some LC hardliners) who will pay to solve bugs. People pay for products, not bugs. Op 5-10-2019 om 21:27 schreef Richmond via use-livecode: Well, well, well . . . out of the smoke a phoenix arises . . . I am in contact "with those who know what they are doing" with a mind to try to set up an "adopt a bug" scheme. But the real b*gger is how on earth to do some sort of triage on outstanding bugs and find out which ones: 1. Are sortable-outable. and of those: 2. Which ones actually justify time, money and effort. Once that has been done (not simple at all), I'm in favour of running an Indiegogo or similar fund-raiser to get funds to sort out bugs, with support badges rather like the one for the Fund-Raiser. I think it is an important idea to have either individual sponsors or groups of them to support specific bugs so that there will not be any complaints about promises not being honoured. Your questions are painful and pertinent. Possibly, just possibly, LiveCode could offer internships to students from universities in Edinburgh and round about: but whether those students would have the depth of understanding of how LiveCode's underpinnings work to do any good is another problem. The idea of an "auction block" could work in 2 ways: 1. Donors would bid to support fixing a specific bug. 2. Would-be bug fixers would bid for the job of fixing the bug. Just as long as the whole thing doesn't end up like a slave market in Jamaica. On 5.10.19 20:31, prothero--- via use-livecode wrote: Folks, The donations to fix specific bugs is a notable idea. But what comes to mind is where the programming effort to fix the funded bug will come from. Presumably, you are thinking it will come from mothership staff programmers. I don’t know, but suspect the staff programmers are already busily working on tasks supporting existing efforts. Suppose bugfix A, funded by donations, takes 40hrs to fix. This 40 hrs will take 40 hrs from somewhere else. So, my basic question is: can the time management strategies of the mothership accommodate these special bugfix jobs? Also, if staff already allot significant time to bugfix efforts, perhaps community votes for highest priority bugs would be effective. On the other hand, if a high priority bugfix can be funded by a client with a special need and the capability of funding it fully (I think that already happens), that’s also to the good. I guess what I’m saying is that, if you want the mothership to do the fixing, they should be giving input on what might also work for them. Alternatively, maybe there are programmers in the LC community who have the skills to tackle some of the bugs and will, if they are supported financially. In that vein, perhaps a system of bidding for bug fixes on the “auction block” could be developed. Payment would be made after tests confirmed the solution, and it could be incorporated into future LC versions. Those are just some thoughts, maybe useful, maybe not. Best to all, Bill William Prothero http://es.earthednet.org On Oct 5, 2019, at 9:56 AM, Curry Kenworthy via use-livecode wrote: I have a very humble proposal to move things forward in more positive manner, and entirely eliminate ALL negativity. ___ 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 ___ 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 ___ 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
Re: Give a bug a hug
Well, well, well . . . out of the smoke a phoenix arises . . . I am in contact "with those who know what they are doing" with a mind to try to set up an "adopt a bug" scheme. But the real b*gger is how on earth to do some sort of triage on outstanding bugs and find out which ones: 1. Are sortable-outable. and of those: 2. Which ones actually justify time, money and effort. Once that has been done (not simple at all), I'm in favour of running an Indiegogo or similar fund-raiser to get funds to sort out bugs, with support badges rather like the one for the Fund-Raiser. I think it is an important idea to have either individual sponsors or groups of them to support specific bugs so that there will not be any complaints about promises not being honoured. Your questions are painful and pertinent. Possibly, just possibly, LiveCode could offer internships to students from universities in Edinburgh and round about: but whether those students would have the depth of understanding of how LiveCode's underpinnings work to do any good is another problem. The idea of an "auction block" could work in 2 ways: 1. Donors would bid to support fixing a specific bug. 2. Would-be bug fixers would bid for the job of fixing the bug. Just as long as the whole thing doesn't end up like a slave market in Jamaica. On 5.10.19 20:31, prothero--- via use-livecode wrote: Folks, The donations to fix specific bugs is a notable idea. But what comes to mind is where the programming effort to fix the funded bug will come from. Presumably, you are thinking it will come from mothership staff programmers. I don’t know, but suspect the staff programmers are already busily working on tasks supporting existing efforts. Suppose bugfix A, funded by donations, takes 40hrs to fix. This 40 hrs will take 40 hrs from somewhere else. So, my basic question is: can the time management strategies of the mothership accommodate these special bugfix jobs? Also, if staff already allot significant time to bugfix efforts, perhaps community votes for highest priority bugs would be effective. On the other hand, if a high priority bugfix can be funded by a client with a special need and the capability of funding it fully (I think that already happens), that’s also to the good. I guess what I’m saying is that, if you want the mothership to do the fixing, they should be giving input on what might also work for them. Alternatively, maybe there are programmers in the LC community who have the skills to tackle some of the bugs and will, if they are supported financially. In that vein, perhaps a system of bidding for bug fixes on the “auction block” could be developed. Payment would be made after tests confirmed the solution, and it could be incorporated into future LC versions. Those are just some thoughts, maybe useful, maybe not. Best to all, Bill William Prothero http://es.earthednet.org On Oct 5, 2019, at 9:56 AM, Curry Kenworthy via use-livecode wrote: I have a very humble proposal to move things forward in more positive manner, and entirely eliminate ALL negativity. ___ 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 ___ 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
Re: Give a bug a hug
Folks, The donations to fix specific bugs is a notable idea. But what comes to mind is where the programming effort to fix the funded bug will come from. Presumably, you are thinking it will come from mothership staff programmers. I don’t know, but suspect the staff programmers are already busily working on tasks supporting existing efforts. Suppose bugfix A, funded by donations, takes 40hrs to fix. This 40 hrs will take 40 hrs from somewhere else. So, my basic question is: can the time management strategies of the mothership accommodate these special bugfix jobs? Also, if staff already allot significant time to bugfix efforts, perhaps community votes for highest priority bugs would be effective. On the other hand, if a high priority bugfix can be funded by a client with a special need and the capability of funding it fully (I think that already happens), that’s also to the good. I guess what I’m saying is that, if you want the mothership to do the fixing, they should be giving input on what might also work for them. Alternatively, maybe there are programmers in the LC community who have the skills to tackle some of the bugs and will, if they are supported financially. In that vein, perhaps a system of bidding for bug fixes on the “auction block” could be developed. Payment would be made after tests confirmed the solution, and it could be incorporated into future LC versions. Those are just some thoughts, maybe useful, maybe not. Best to all, Bill William Prothero http://es.earthednet.org > On Oct 5, 2019, at 9:56 AM, Curry Kenworthy via use-livecode > wrote: > > > I have a very humble proposal to move things forward in more positive manner, > and entirely eliminate ALL negativity. > ___ 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
