If it is technically possible, I want it to be optimized automatically on a regular basis.
For example,
Dae said he’s not planning to implement automatic optimization any time soon, but a pop-up with a reminder might be implemented.
This is not an issue I have particularly strong feelings on. As long as the message will not result in an increase in confusion/support requests, I’d be happy to accept a PR. The user may see the message when they have existing parameters, or when they’re currently using the defaults, so it should make sense in both contexts. I’d suggest a variant of @vaibhav’s suggestion: “The FSRS parameters are currently optimal.” Does that work for people?
I posted the survey on Reddit and Discord, here are the results so far:
Here are the results after one day. Interestingly, in this survey, the opinions are much more skewed towards adding a message compared to my original poll. But there is no consensus on the best wording. I’ll leave that to you.
I have a slight preference to the wording I suggested above, as perhaps is no surprise 
. The green suggestion is my favourite of the options you listed, but I prefer “currently” to “already” as it implies that it will change in the future, and “parameters for … review history” sounds slightly strange to me, as the parameters are for scheduling, not just for the review history.
Are people happy with my suggestion, or would they prefer to see it tweaked / something else used instead?
Parameters are used for scheduling, but they are optimal (well, close to optimal) for a given review history. The meaning is ever so slightly different. Though I probably shouldn’t comment on such nuances since I’m not a native English speaker.
It seems to be good enough.
I’m quite conflicted on this.
I work with optimization problems from time to time and it’s very rare for an optimization algorithm to conclusively determine that it has definitively found the optimal parameters. The messaging asserts optimality without providing evidence to support its claim.
The fact that the optimizer fails to find better parameter values does not imply that the previous ones are optimal, and even if it does find better parameters, it does not guarantee that they are optimal.
What I suggest is introducing modality: might, could, should, would, seem to, looks like…Thus, instead of “The FSRS parameters are currently optimal” we have something like “It looks like the FSRS parameters are currently optimal” or “The FSRS parameters seem to be currently optimal”.
I was thinking “already” would be better but now I think using “currently” can be the better option.
I would say “current review history” can be a bit confusing. If additional info must be added, it should just be that optimization is supposed to be done every one or two months. Something similar to that effect.
“The FSRS parameters currently appear to be optimal.”?
That sounds pretty good to me.
Maybe add “therefore they were not changed”?
It seems a bit superfluous to me, but I’m not a typical user - do others think it would make things much clearer?
The expectation while optimizing is a change in parameters. If parameters are currently optimal, I do not think anyone would need clarification that this means there was no change in parameters. That is my opinion. I just realised this though, why anki is showing the parameters in deck options? If it can be a source of confusion (as Expertium believes) should that not be just removed? I mean it’s not like people are getting the parameters from an outside source. If there is a reason to keep it, then we can always have that box to enter parameters of our own without actually having to see the parameters after optimization or the default ones of FSRS for that matter.
Advanced users want to see them, and some users may want to copy in values from the Python optimizer or the old FSRS system.
My post with difficulty graphs was a mistake. One of the m2a decks does have a 7% RMSE, but it’s a small one (621 reviews) and not the one I posted about, and each of them fits the m2a preset better than their parent presets (I forgot to enter “deck:current -is:suspended” when evaluating).
If it was an m2a deck that didn’t fit its own preset well, that was solved by optimizing with all m2a decks from all priorities.
