Closed hmpf closed 3 years ago
I've been reading up on severity vs. priority in ITIL. They are separate concerns. Severity is how bad a problem is for a specific system (boxDown vs. linkDown say), and should be possible to be generated by the input converter. Priority is how important something is to fix, and is set by a person. So we could have a system to auto-set priority, while severity is handled by the converter.
I've been reading up on severity vs. priority in ITIL. They are separate concerns. Severity is how bad a problem is for a specific system (boxDown vs. linkDown say), and should be possible to be generated by the input converter. Priority is how important something is to fix, and is set by a person. So we could have a system to auto-set priority, while severity is handled by the converter.
So, this issue also says: We need a priority attribute on Incidents as well?
If Argus should concern itself with priorities at all, I think external agents would be the way to go to assign priorities, since I'm guessing priority policies would be entirely dependent on the organization using Argus
I think we're back to the definition of severity vs. priority again, what can be set automatically and what must be decided on by a human. If a human gives something a pri/sev of x, an agent could look for similar incidents that match and also mark them.
Priority may not be needed, as it is 'saksbehandling' and therefore not in Argus' scope of responsibility.
Some problems are more important than others. If Very Important Switch has trouble, that needs a higher severity than Not Very Important Switch for the same kind of trouble. The converter inputting incidents cannot know the end-user's priorities, so there needs to be a way to mark some incidents as more important than others. This way, the next time something resembling that incident happens, it is automatically flagged correctly.