LiveCode Forums.

It's Christmas and one thing on my wishlist is for LiveCode to use UserVoice (or similar), where its userbase can vote for features/bugfixes important for them.

What do you think?

Merry Christmas!
Tom

Well, I think you can already set up a poll, right here in the forums, to have people vote for whatever you can think of

When you start a new thread, you just click on the create poll, and post your question along with possible choices and whatnot. Anyone that is a forum member can respond directly, which is far more likely than having to pay some outside company that almost no one using this software is likely to go sign up for or pay an ongoing fee for, including the company itself.

Of course, we could also setup a poll to see who would like to cover the tab to have some outside company do what you can do right here for free

tomsve wrote: ↑

Sun Dec 15, 2019 11:24 pm

It's Christmas and one thing on my wishlist is for LiveCode to use UserVoice (or similar), where its userbase can vote for features/bugfixes important for them.

What do you think?

Merry Christmas!
Tom

Merry Christmas, Tom.

There are two issues here: the role of these forums in the feature request/bug fix process, and voting on bugs.

These forums predate the creation of the official bug database: https://quality.livecode.com/

Originally, this was a good place to post bug reports and feature requests. But now that we have an official place for that which integrates with the team's workflow, these forums are better suited to exploring options for requests to refine an enhancement suggestion before submission to the DB, or in the case of bugs for seeking confirmation on a recipe or other details before submitting a bug report to the DB.

As Bogs pointed out, you can use polls here, and sometimes that can be useful for gauging interest. But these user-to-user support forums are only infrequently visited by the core development team, so any information here can be useful for community efforts but not likely to be seen by the engine team.

As for voting, we used to do that, but like so many things that seem like a good idea in the moment, voting turned out to be more of a sociological revelation than technical or economic, so they ultimately proved of limited value for assessing priorities, in some cases even counterproductive.

A more detailed discussion on this was held on the Use LiveCode discussion list in October - here's my summary of lessons learned form the voting process:
http://lists.runrev.com/pipermail/use-l ... 56502.html

This is how Cloudways are doing it; http://feedback.cloudways.com/

I just like the transparency of what is planned/started/completed regarding user requested stuff.

You’re right - Maybe it’s possible to use the polls here for it. Never tried it, yet.

Tom

The link I provided includes a note at the bottom for an organic form of voting still very much in place in the LiveCode bug DB.

an organic form of voting

Wow! Can we throw it on the compost heap after we've finished with it?

Err . . . sorry, not possible to resist that one.

But these user-to-user support forums are only infrequently visited by the core development team, so any information here can be useful for community efforts but not likely to be seen by the engine team.

Unless of course something is pretty important, and should be seen by the team, it can be linked to in the official BR / FR in the quality DB. This is something I have done when I see something I think important (or can be explained better by those longer in the game).

From Tom's pov, where he is looking to give direct feedback on the importance of a particular bug or feature, he *could* gauge the interest of members on the forum through a poll, and then go to the DB and explain his pov, linking to the thread in the particular bug or feature comments section.

This serves 2 purposes, he'd automatically be added to the list by commenting (showing an addition of interested parties per RG's link), and at least one person on the team would then know there is an existing thread pertaining directly to the issue listed.

A few things I would point out about this method though, would be -
. you have to be pretty good at searching the bug db, otherwise you'd be creating a million additional reports creating a lot of extra work for all involved
. you'd have to gauge (to some degree) whether there is genuine interest, or just supportive voting as mentioned in Richard's link
. I wouldn't suggest using this method to, say, introduce the thought that the 4th pixel in the letter 'z' should obviously be Chartreuse!

features/bugfixes

I don't think it is sensible to conflate features with bugfixes.

Presumably . . .

By features we mean new things that are not currently present in the language and/or IDE.

By bugfixes we things that are present in the language and/or IDE that do not work as they should.

Too late, that is the way it is stated in the first post

Besides that, many consider them to be one and the same, by reasoning that the 'feature' should have been included from the start, therefore 'fixing' an existing bug caused by oversight.

If one creates a poll for voting then please put the bugreport nr with it for convenience.
I have a few and will add them soon.

richmond62 wrote: ↑

Mon Dec 16, 2019 11:46 am

features/bugfixes

I don't think it is sensible to conflate features with bugfixes.

Presumably . . .

By features we mean new things that are not currently present in the language and/or IDE.

By bugfixes we things that are present in the language and/or IDE that do not work as they should.

Thank you.. I'm aware of the difference. The team is too.

While they are of course different, together they represent the work of maintaining software.

Accordingly, Bugzilla (and many similar systems) provide a single place to log both, with a flag set by the submitter to differentiate.

So I did not "conflate"' them for any nefarious reason or to suggest they are somehow not different things.

I used "features/bugfixes" only for the sake of completeness, because Bugzilla handles them both.

bogs wrote: ↑

Mon Dec 16, 2019 12:11 pm

Too late, that is the way it is stated in the first post

Besides that, many consider them to be one and the same, by reasoning that the 'feature' should have been included from the start, therefore 'fixing' an existing bug caused by oversight.

While people may have their own subjective view of all sorts of things, the software engineering definition the team uses is that if a request relates to a feature already in the software it is classified as a bug, and if not already in the software it is an enhancement request.

From time to time we may see the team adjust that flag for a report as best fits their understanding and workflow, but in general that simple definition applies.

bogs wrote: ↑

Mon Dec 16, 2019 10:53 am

But these user-to-user support forums are only infrequently visited by the core development team, so any information here can be useful for community efforts but not likely to be seen by the engine team.

Unless of course something is pretty important, and should be seen by the team, it can be linked to in the official BR / FR in the quality DB. This is something I have done when I see something I think important (or can be explained better by those longer in the game).

Of course. On the rare occasion that something comes up here that's critically important to the team, one of the moderators will send an email to support AT livecode.com to draw their attention to it.

But you'll also recall that I frequently suggest that people with truly critical needs that can only be addressed by the company use that address themselves. If something is critical, it's critical.

From Tom's pov, where he is looking to give direct feedback on the importance of a particular bug or feature, he *could* gauge the interest of members on the forum through a poll, and then go to the DB and explain his pov, linking to the thread in the particular bug or feature comments section.

This serves 2 purposes, he'd automatically be added to the list by commenting (showing an addition of interested parties per RG's link), and at least one person on the team would then know there is an existing thread pertaining directly to the issue listed.

To clarify, anyone can add themselves to the CC list of a bug by just clicking "Save Changes" while logged in. It isn't necessary to add a comment to be added to a report's CC list.

A few things I would point out about this method though, would be -
. you have to be pretty good at searching the bug db, otherwise you'd be creating a million additional reports creating a lot of extra work for all involved

I've been impressed with Bugzilla's ability to suggest relevant existing reports when creating a new one. If it's something pervasive I may do a search first, but BZ's suggestions are so good that I often find letting it do that search for me while I type the description is sufficient to find related issues.

And the worst that could happen is a duplicate report. During the course of reviewing the bug, and during periodic review of outstanding issues, duplicates are found and merged. The makers of BZ understand that this is common in any large software project, and have made merging easy.

tomsve wrote: ↑

Mon Dec 16, 2019 1:19 am

I just like the transparency of what is planned/started/completed regarding user requested stuff.

Have you explored LC's Quality Control Center? Powered by Bugzilla, the search feature is very comprehensive, allowing anyone to explore reported issues with as much or as little granularity as most usages would need:
https://quality.livecode.com/query.cgi

As a central location providing a two-way public interface for communicating with the team and shaping the maintenance workflow in specific actionable terms, it's worth spending some time with.

Polls in a user-to-user forum can also be useful, and I look forward to seeing yours.

Thank you.. I'm aware of the difference. The team is too.

Gosh, really? Don't be daft! I never doubted that either you, FourthWorld, or "the team"
were unaware of the difference.

They were, however, conflated by the OP: whether they were aware of the difference or not.