Skip to content
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

Create gradations in who joins scenario migrations #1362

Open
noracato opened this issue Sep 28, 2023 · 4 comments
Open

Create gradations in who joins scenario migrations #1362

noracato opened this issue Sep 28, 2023 · 4 comments
Assignees
Labels
compatibility Pinned Will never be marked as stale or auto-closed.

Comments

@noracato
Copy link
Member

Currently we migrate scenarios under the following criteria: either they have keep_compatible set to true, or they have to be created within the last month. However, we find that some users do not want their scenarios to join every migration, but only the really necessary ones. Hence we can think about creating a gradation in compatibility settings.

We can classify all migrations under the two following concepts:

necessary
Renaming of sliders, changing of units

helpful
Approximation of new slider value based on scenario after changes in modelling

Instead of having only the options true or false for keep_compatible we could offer three options instead. A consequence is that scenario owners are more aware of compatibility options, and thus we should remove the '1 month old' migration criterium when we implement this.

@noracato noracato self-assigned this Sep 28, 2023
@mabijkerk
Copy link
Member

A consequence is that scenario owners are more aware of compatibility options, and thus we should remove the '1 month old' migration criterium when we implement this.

One question @noracato. Shouldn't we discuss removing the '1 month migration criterium' anyway? Even without picking up this issue and possibly quintel/etmodel#4146. Is this something to discuss in the teammeeting?

@thomas-qah
Copy link
Contributor

A possible addition to this idea could be to split the keep_compatible flag into two:

  • keep_compatible: True/False turns the necessary option on or off.
  • adjust_to_new_modeling: True/False turns the helpful option on or off. This can only be changed if keep_compatible is true.

Copy link

github-actions bot commented Dec 3, 2023

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.

@github-actions github-actions bot added the Stale Issue had no activity for 60 days and will be, or has been, closed. label Dec 3, 2023
@mabijkerk mabijkerk removed the Stale Issue had no activity for 60 days and will be, or has been, closed. label Dec 8, 2023
Copy link

github-actions bot commented Feb 7, 2024

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.

@github-actions github-actions bot added the Stale Issue had no activity for 60 days and will be, or has been, closed. label Feb 7, 2024
@mabijkerk mabijkerk added Pinned Will never be marked as stale or auto-closed. and removed Stale Issue had no activity for 60 days and will be, or has been, closed. labels Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Pinned Will never be marked as stale or auto-closed.
Projects
None yet
Development

No branches or pull requests

3 participants