Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Approach for defaults in LiSP #268

Closed
fnetX opened this issue May 25, 2023 · 0 comments
Closed

Approach for defaults in LiSP #268

fnetX opened this issue May 25, 2023 · 0 comments

Comments

@fnetX
Copy link
Contributor

fnetX commented May 25, 2023

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.

Repository owner locked and limited conversation to collaborators May 26, 2023
@FrancescoCeruti FrancescoCeruti converted this issue into discussion #270 May 26, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant