Approach for defaults in LiSP

[fnetX]

We should keep the old as the default, for compatibility reasons.

Originally posted by @FrancescoCeruti in #266 (comment)

Just creating a new issue, because I have a general objection to this behaviour. If software always keeps the existing behaviour as the "default", a future variant of the software might appear confusing to new users, because all workflows are only working the way it was working in the early days.

It is hard for end users to discover that a certain behaviour is actually configurable to the demand.

I propose:

• When defaults could be changed, we conduct some sort of discussion on whether the old or new style is preferable for the majority of the users. Backward compatibility is kept in mind, but the software not influenced by the personal preferences of only a few individuals
• There is a system for migrating old showfiles to preserve the behaviour there. This could mean: If a value is absent in an old showfile, a custom (potentially different) value is used, because the showfile might just be older. New showfiles always save explicit settings to avoid any doubt.

Backward compatibility is important, but the UX for newcomers is, too. Due to the nature of LiSP development, many design choices are heavily influenced by few opinions. If we want to make the software future-proof, decisions should take these multiple aspects into consideration.

[FrancescoCeruti]

Generally speaking LiSP have broken backward compatibility many times, so you can be sure it's not a general direction :)

I agree with this points:

• we should push all the values to the show-files, this will allow us to change defaults without changing how existing show behave (or at last it give us a chance)
• we need a way to migrate show-files between versions

That said, I value the opinion of everyone that want to contribute, and many changes have been introduced to address users requests,
obviously major contributors are more likely to influence the direction more than others.
As of right now I don't think we need a major change in terms of decision making, a major involvement and an a stronger community are probably thing we need more, unfortunately, tasks I'm not well versed at.

[fnetX]

In order to make a software a community effort, you do not only need to accept patches by users or implement their features, but also conduct some kind of research into what makes the software appealing to users and what could be sane defaults to attract them.

This sounds marketing-ish, but I'm particularly interested in finding good defaults for the software. So when someone proposes a new behaviour which is hidden behind a checkbox, I think we should do a quick chat via Matrix/Gitter or an issue to gather some opinions by users. Eventually, we will find out that most users found the past behaviour "always very confusing", so we should use the opportunity to update it or make it more intuitive. Maybe we find out that most users prefer the past behaviour, so the proposed behaviour is made optional.

But I think we should take the time to talk about this. Good software is not only about coding, taking the time to chat with some users is usually worth the value.

My 2cent on this.

[FrancescoCeruti]

Sure, increasing users involvement in some decisions will likely be beneficial.

I'll try to take this into consideration :)

puts the 2 cents into the piggy bank 🪙🐖

[FrancescoCeruti]

Quick update on this

2d1e86e and 3c0ec1d, address some of what has been discussed here, pushing all values into the show files, plus, app and plugins versions are now saved into the show files.