zonemaster
Change WARNING to DEVIATION
Purpose
The current use of WARNING in Zonemaster is for a situation that is problably less sever than the general concept of what WARNING stands for. See "Severity Level Definitions".
This PR proposes that WARNING is replaced by DEVIATION.
If this proposal, the change must be implemented in many places.
How to test this PR
This is a document change only, but it must be generally implemented and tested.
It is a good idea to change the WARNING tag to something less severe. Thinking about DEVIATION, is this because mainly messages with this level would be standard deviation? Did you think of any other words? I made a search for synonyms of "deviation":
| aberration | deviance | discrepancy | divergency | irregularity | variance |
| abnormality | deviancy | disparity | diversion | nonconformity | variation |
| alteration | difference | divagation | fluctuation | straying | |
| anomaly | digression | divergence | inconsistency | transgression | |
I asked to a native American at IIS and he was negative to use DEVIATION instead of WARNING since that is unexpected for levels.
Another option is to move everything INFO and above one step, but what should current INFO be called. I do not think that DEBUG is friendly for the general user.
Or, if INFO is kept as is, NOTICE label is moved to today's WARNING, WARNING to ERROR, ERROR to CRITICAL
What happens with messages tagged NOTICE today? -- We could retag some of them as INFO and others as the new NOTICE.
We would then have four levels for the general user: INFO, NOTICE, WARNING and ERROR.
I asked to a native American at IIS and he was negative to use DEVIATION instead of WARNING since that is unexpected for levels.
I feel this way too. There is a fairly standardized set of severity levels and I don't think we should be too creative with them.
Another option is to move everything INFO and above one step, but what should current INFO be called. I do not think that DEBUG is friendly for the general user.
As a user the only time I need to look at the messages at the current INFO level is when I'm surprised by the Zonemaster results and I want to figure out what false assumptions I'm making.
If this category of messages was called DEBUG that would be perfectly user friendly. In fact it might be more user friendly than labeling them with INFO. Having lots of noisy messages labelled INFO could give the impression that those messages are somehow informative or enlightening in normal circumstances, potentially causing less technical users to feel stupid when they shouldn't.
(I have more thoughts on this but so far this is all I managed to put words on.)
I asked to a native American at IIS and he was negative to use DEVIATION instead of WARNING since that is unexpected for levels.
I feel this way too. There is a fairly standardized set of severity levels and I don't think we should be too creative with them.
I think I agree too.
As a user the only time I need to look at the messages at the current INFO level is when I'm surprised by the Zonemaster results and I want to figure out what false assumptions I'm making.
Yes, there are too many INFO messages just stating what is expected when there is nothing to say.
If this category of messages was called DEBUG that would be perfectly user friendly.
Yes, for the technical community, but not for the general community, but I guess that would be fine if we decide that those messages are not shown in the GUI anymore.
In fact it might be more user friendly than labeling them with INFO. Having lots of noisy messages labelled INFO could give the impression that those messages are somehow informative or enlightening in normal circumstances, potentially causing less technical users to feel stupid when they shouldn't.
If a domain is just fine does Zonemaster really have to say anything about it?
If a domain is just fine does Zonemaster really have to say anything about it?
Most of the time, I would say no. But there is one case I think is important where it's a good idea to actually make at least some basic data and/or intermediate results available. This is when you're surprised by a test result and it isn't obvious how Zonemaster came to this conclusion. In this case an advanced user likely wants to investigate to figure out where your assumptions are wrong.
As a user the only time I need to look at the messages at the current INFO level is when I'm surprised by the Zonemaster results and I want to figure out what false assumptions I'm making.
Yes, there are too many INFO messages just stating what is expected when there is nothing to say.
If this category of messages was called DEBUG that would be perfectly user friendly.
Yes, for the technical community, but not for the general community, but I guess that would be fine if we decide that those messages are not shown in the GUI anymore.
Yeah, we shouldn't show lots of basic data and intermediate results by default, that's not helpful to anyone. I agree that this information is seldom useful but sometimes you do need it as a technical user. If Zonemaster doesn't provide it you'll find Zonemaster unhelpful and I don't think we want that. If we instead hide it by default (perhaps behind a DEBUG button), then nobody will look at it unless they need it or they're curious.
I should note that debugging can mean different things depending on the audience. For developers of a tool it means figuring out what's wrong w.r.t. the tool. For users it means figuring out what's wrong w.r.t. their zone. Since we show these messages to the users I think we should to take the user perspective.
I agree that GUI shouldn't provide tool debugging messages. But upon request the GUI should be able provide messages that allow users to scrutinize a result and their understanding of it.
Or, if INFO is kept as is, NOTICE label is moved to today's WARNING, WARNING to ERROR, ERROR to CRITICAL
This would mean collapsing the messages currently labeled ERROR and CRITICAL into a single severity. Today the CRITICAL severity serves two purposes: 1) the presence of a CRITICAL message tells the user that the test suite was aborted early, and 2) the message labeled CRITICAL tells the user why the test suite was aborted.
If we collapse the ERROR and CRITICAL tags into a single severity we need to add a new mechanism to achieve the first purpose. This is really important. The second purpose is relatively less important but I still think it's a good idea to serve it.