At the DMLT meeting today, there was a request for a way to indicate in JIRA that a ticket is of particular urgency, and that a fix is critical in unblocking a major commissioning activity, for example. I have therefore added an Urgent? yes/no slider to DM stories and bugs (something I have frankly been wanting to do for a long time) and we will see if it has the desired effect.
You can stop reading here if you have better things to do.
I think @swinbank may have expressed some scepticism that such a simple indicator is sufficient for expressing the complexity of the situation that folks at the telescope are operating in, so I am going to take this opportunity to inflict on you some rather extensive prior experience with such a scheme and why I feel it works better in practice than a more sophisticated scheme.
For background, when I first arrived at UKIRT, the Urgent flag in the ticketing system had a particularly explicit purpose: it was tantamount to a request for (then applicable) overtime. It meant that the filer (typically the telescope operator or support scientist on shift) had determined that a ticket was so necessary to protect telescope time (our primary metric) that an engineer should be paid to work out of hours (nights, weekends, holidays) to address the problem. Eventually the employment model changed, and out of hours support became “best efforts basis”, but the urgent boolean still remained in the same use - it was a request for urgent attention, and most of us (and certainly all our managers) had notification flags to make us aware of such tickets immediately.
Here is my mini-FAQ on why this system is highly effective in practice.
Urgent Y/N is too simple to capture relative priorities.
This is an understandable first response: we love categorising things, and this scheme seems too coarse. But actually prioritising things into “critical, super important and shouldn’t wait, super important but can wait, important but sufficiently annoying that sooner is better than later” etc etc is in itself (1) not a critical activity (2) not best done by the filers. You are never going to get a field in a JIRA ticket be an effective substitute for a team lead’s judgement on scheduling; also developers are humans, not robots that work serially on one task until it is done then start the next irrespective of context. The intent of the Urgent flag is not categorisation or scheduling, but communication: a clear unambiguous signal that some is desperately needed to look at a problem because the sky time plan is in serious jeopardy otherwise
People will disagree about what it means
As a telescope, both in commissioning and in operations, time that could be used observing (good weather night-time for this telescope) is our scarcest resource. Hence, things that stop the telescope dead (or seriously risk doing so) are the most critical faults, as are faults that threaten the resources for doing so (eg a super-critical security risk that threatens the availability of computers needed for observing).
People will abuse the Urgent flag
Again, people are not robots programmable by JIRA. If we got a ticket that was marked as Urgent that was not, we simply pushed back with an explanation of why (misunderstanding? an available workaround? a variation in the observing strategy? we can easily fix that in the data reduction?) mean that it is reasonable to leave responding to the ticket till Monday. If a person is so self-absorbed because they are filing Urgent tickets on a Sunday and ringing you at home because they can’t LaTeX their paper (cough random example that has totally never happened to me cough) that person needs talking to, not a more sophisticated JIRA workflow.
Process is to phone people out of hours
No problem. Marking a ticket as urgent makes it easier for the person you just called to find it.
Hey I get bored on weekends and cruise JIRA for stuff to do
If you have insomnia and are looking to be useful, picking up random JIRA tickets on the basis of a priority field strikes me as in ineffective use of your time. If I was up there I’d say get on Slack and ask me if there’s something you could do that would be particularly useful right now.
This does not help the commissioning team organise its work
It’s not intended as such.
What if there are 3 urgent faults? Which one is more important
If the telescope is dead in the water because of 3 faults all of which are your problem then (1) something has gone seriously wrong (2) does it really matter which one you fix first? Even if we used a wide ranged priority field, I would argue having an explicit urgent flag in addition to that is useful regardless.
If anyone has stories of how their previous telescope dealt with such issues, I am certainly interested in hearing them! Meanwhile enjoy your Urgent slider and use it responsibly.