Is this an emergency?¶
In order to better serve our users, we prioritise our work, primarily on the basis of information that you provide us when submitting your requests for help. But this leads to a problem, which is that requestors develop a tendency to slightly overstate the urgency of their request, in the hope that it will be processed more quickly. Everyone does this, even us!
The end-state of this situation isn’t pretty. Soon everything is “urgent” or “an emergency,” which has several problems:
- real emergencies get missed
- system administrators are constantly interrupt-driven, and are unable to effectively manage their workload
- any work which is not “urgent” takes a disproportionately long time to be processed
So, we need a way to define what an emergency is. This is difficult to do for the Open Knowledge Foundation given the varied nature of our work. As such, we’re going to provide two lists which help explain what is, and isn’t, an “emergency”.
It might be an emergency if...¶
We distinguish between the following situations:
- “code red”
- Situations which are currently preventing our users from using services which we are reasonably expected to provide them, or which are stopping our staff from conducting their business.
- “code yellow”
- Any situation which, if not addressed, could lead to a “code red”.
- Any unscheduled outage or breakage of any public-facing system is an emergency.
- Any unscheduled outage or breakage of any system that is critical for you to do your job is an emergency.
Here are a few emergencies:
- a public website hosted by us is unavailable, unresponsive, or broken
- a mailing list is unusable, or emails aren’t reaching members
- you can’t get to your work email
- hackers or spammers have taken control of one of our web properties
- a project partner or funder has unilaterally changed the circumstances surrounding a project such that our deadlines have changed in a way that we have no control over, and thus requests for changes to sysadmin-controlled systems need to be processed faster than usual 
It’s probably not an emergency if...¶
We don’t want to be seen as BOFHs, but the cardinal rule here is:
Poor planning on your part does not automatically constitute an emergency on mine.
That means that you should not second-guess the system administrators’ workload. Please trust that we prioritise work such that everyone is happiest over the long run.
Here are a few plausible situations in which flagging a request as “urgent” is not usually acceptable:
- you or your project team failed to identify all the dependencies of launching your new project, and now it needs launching “urgently” with support from the sysadmin team 
- you want something done, and used to be able to do it yourself, but now it’s looked after by the sysadmin team
- it’s Friday afternoon, and you just remembered something you promised someone by Monday that needs sysadmin intervention
- you are a senior staff member, so your request is more important and should be processed more quickly than others
Ultimately, we want to provide the best possible service to our users, just as you do. We will of course still be happy to bend the rules for you every once in a while. We are all human, and we’re happy to help you with an “avoidable emergency” every once in a while. Just please try hard not to make a habit of it: remember the story of the Boy Who Cried Wolf.
|||Please note that the critical feature here is that there is no way you could reasonably have been expected to know the situation was going to change. A similar situation in which the change of deadline comes from within your project team is not comparable.|
|||It’s worth reminding you that we’re always happy to consult at an early stage on what things might need to happen with our involvement to make your project a success! Email email@example.com with your questions.|