This is really important: You're not the end user of this product. These types of models are not built for laypeople to access them. You're an end user of a product that may use and process this data, but the CRPS scorecard, for example, should mean nothing to you. This is specifically addressing an under-dispersion problem in traditional ensemble models, due to a limited number (~50) and limited set of perturbed initial conditions (and the fact that those perturbations do very poorly at capturing true uncertainty).
Again, you, as an end user, don't need to know any of that. The CRPS scorecard is a very specific measure of error. I don't expect them to reveal the technical details of the model, but an industry expert instantly knows what WeatherBench[1] is, the code it runs, the data it uses, and how that CRPS scorecard was generated.
By having better dispersed ensemble forecasts, we can more quickly address observation gaps that may be needed to better solidify certain patterns or outcomes, which will lead to more accurate deterministic forecasts (aka the ones you get on your phone). These are a piece of the puzzle, though, and not one that you will ever actually encounter as a layperson.
They're all easily solvable problems. The issue, as GP mentioned, is that the pennies are just stopping without the thought through these problems and planning for the solutions. This was done via a social media post, not a well thought out transition like Canada had.
Like with most things, it depends! Maybe it's a default value; maybe it's a null; maybe it's a special value that triggers a workflow on insert. I'm an evangelist for RDBMSes, and they can do so much, so let them help you!
Maybe you have a state column that's derived that you cannot move to another step in the workflow until all nulls are filled in, but you've let the UI save what data it knows about and move on. It totally depends on what the user is doing and why we're skipping steps/data.
In my experience, the software development profession could spend a long, long time doing some self-reflection about this one. It's eloquently stated, and something a lot of developers could learn. Too many times, I've seen overly restrictive inputs cause users to hate and distrust the software. Ironically, overly restrictive inputs cause users to think that the software doesn't properly understand the domain, which is the root of mistrust.
We should be very liberal with accepted inputs. I call them "Fuck It Buttons." There are lots of cases where you want a "Fuck It" button to just go around all the data entry and get an answer or move on with minimum info. Warn that the data isn't complete and we're using defaults, and don't just make output look the same as a complete workflow, but let them go through, nonetheless. Health care is just one example, but "Fuck It" comes up in every industry.
This is the UI/UX equivalent of knowing which hills to die on.
Again, you, as an end user, don't need to know any of that. The CRPS scorecard is a very specific measure of error. I don't expect them to reveal the technical details of the model, but an industry expert instantly knows what WeatherBench[1] is, the code it runs, the data it uses, and how that CRPS scorecard was generated.
By having better dispersed ensemble forecasts, we can more quickly address observation gaps that may be needed to better solidify certain patterns or outcomes, which will lead to more accurate deterministic forecasts (aka the ones you get on your phone). These are a piece of the puzzle, though, and not one that you will ever actually encounter as a layperson.
[1]: https://sites.research.google/gr/weatherbench/