This is because users do not turn on verbose logging? but you'd ask them to provide logs at any rate, so might as well they turn on the verbose logging, no?

You can see the request here
https://indilib.org/forum/general/6167-for-those-with-focus-issues.html?start=96
from dmsummers on 5/4/2020.

This is not something I want users to send me--if someone was asking for my help, I'd ask for the full debug logs.
This is something for them to diagnose with or recreate the focus plots on their own.

He's just saying it's something he thinks would be useful, and he'd rather not get all the stuff that comes with debug logs.
Of course, he could also access it in the debug log if this wasn't submitted.
I did not move all the info, just the initial focus configuration, and the final plot details and summary info, so there's not much added to the log.
Anyway, your call.

Ok thanks for sharing the post. While it might help this user specifically, these statements are inherently debug and not info, so I think they should remain as is.

Jasem, I'd like to respectfully disagree with you on both your assertions and ask you to reconsider. Given that a plot method has already been created by another user, it shows that I'm not the only user who would envision plotting the summary. There is a big difference between debugging and performance monitoring/analysis. I'm suggesting that the summary info is perfectly in step with what INFO level should support. While the other focus algorithms are inconsistent in what/how INFO summary data is provided (a generalized problem probably needing to be addressed separately), they do provide INFO summary data consistent with this request (focuser position, HFR). I submitted the request when I saw that Hy's algorithm wasn't consistent with INFO data from the other algorithms. It's true that I can turn on debug to get the summary, but it shouldn't be true that if users want to monitor performance post-run, they should need to turn on debug. Hopefully after you reconsider the difference between debugging and performance monitoring/analysis, you'll agree. Cheers, Doug

Is this information useful for non-developers?

I'd say yes, it would be useful for folks trying to tweak their focus parameters. I think is common among non-developers.

Absolutely! Developers debug until their algorithms actually work. Users are not developers. They presume algorithms work and just monitor/analyze performance for tuning purposes. These use cases are very fundamentally different. No user wants to wade through tons of debug to get summary data they need for performance analysis. Another analysis example illustrates the point. I use PHD2 not because I don't like the internal guider, but because there's a post analysis tool (logViewer) that can show how guiding performed (and whether I need to tune or not). That's not debugging. The first rule of performance assessment/improvement is measurement. Without the summary measurements, it's hard to improve. I suggest the vision for INFO level should be to support performance assessment and aid users in tuning/improvement. Cheers, Doug