Categorisation of problems/faults

[neil]

Just wanted to pick up a train of thought started by @Panda on Open Data Day:

@Panda

I wonder if some of the fault types are the most useful. E.g., ‘Liquid damage - Needs new keyboard’ that fits under a ‘keyboard’ fault, however to classify the type of problems that happen, I’d find ‘liquid damage’ more useful, with keyboard replacement as a solution.

[neil]

It’s a really good point… The fault types that we took from the IDC report are really just ‘parts’ - i.e. they record which part had a problem. But with no indication of specifically what the problem with that part was, nor what caused it.

I guess you could think about the problem in various ways, e.g.:

• What part has the problem?
• What specifically is the problem with that part?
• What caused it?

e.g. “dropped it, screen broken”

• What part has the problem? Screen
• What specifically is the problem with that part? Cracked
• What caused it? Dropped it

I suppose in the case of “Liquid damage - Needs new keyboard” it would be something like:

• What part has the problem? Keyboard
• What specifically is the problem with that part? Liquid damage
• What caused it? Spilled liquid on it

From a “barriers to repair/availability of spare parts” perspective, it’s useful to know which part had the problem. From a “finding similar repair attempts to the one I’m working on”, knowing specifically what the problem was is also useful (e.g. I’ve got a keyboard with liquid damage, what’s a possible solution?).

Knowing what caused it is perhaps interesting but less useful.

[neil]

(Just a side note we always have to think about it from two potential points of tension - what is most useful for data analysis; and what is easiest from a data collection point of view. The sweet spot is when those two align!)

[Janet]

As someone engaged in trying to run and event and collect the data, I’m often most interested in capturing information on the potential cause of the problem as this is immediately helpful to fixers. It also gets participants in the mindset of helping to troubleshoot and get involved from the outset. I try to record this if possible, as well as the part/s affected.

From a data analysis POV, I think understanding what causes people to need repairs is important because it can inform design decisions - particularly conversations about the trade-offs between durability and repairability.