Capturing additional useful information about repairs

Hi Restarters,

As more of you get involved in accessing and contributing data about the devices we see at Restart Parties, we’d like your feedback to make the tool more useful and precise.

A bit of context:

  • Our new platform will make it easier for all Restarters to access and search for data of repairs that occurred at previous Restart Parties, for example to search for a category of device, and see recurrent faults, and ways in which they’ve been addressed.

  • The data we collect and share can contribute to change the way products will have to be designed in the future. Policy makers tell us that it would help to have more details about spare parts use; barriers to repairability; availability of repair information

We would like to improve the data we collect by adding the additional proposed information below. We’d like your feedback and thoughts, including about:

  • any additional info (or option) we should consider
  • is this feasible or possibly a bit too much information to ask?

Thanks! :slight_smile:

For all repairs:

  • URL of useful repair information used
  • Whether it’s manufacturer or third party

For Fixed and Repairable devices:

  • Did it require a spare part? (with options: from manufacturer/from third party/not needed)

For End-of-life devices:

  • What were the barriers to repairing it? Multiple choice or drop-down question with the following options to choose from:
  1. spare parts not available
  2. spare parts too expensive
  3. no way to open the product
  4. repair information not available
  5. lack of equipment

cc @Dave - I remember you had some ideas around spare parts you mentioned before - I wonder what your thoughts are?

It’d be great to hear feedback on this from other Restarters as well, especially if you’re already collecting data at events @James_Diamond @ssebti @Marie_Lefebvre @Sophia_Flucker @Steve_Cook

@ugo I’ll come back to this thread soon. We have no planned restart parties before september so the review of the tool falls currently down our priorities. I’ll pick it up again, particularly if we have to modify our paper scroll to record repair events. Actually? Do you have any scroll handy that we could copy which reflect the fixometer tool? This will help me see at first glance what is the tool about without having to dissect the interface to develop my own scroll tool. Then I can feedback later about the usability of the interface.

Thanks in advance :wink:

Thanks @Marie_Lefebvre. Based on your experience running Restart Parties, do you think it’s reasonable to collect a little more detail on spare parts and experienced barriers to repair at your events?

Good point about having an updated scroll “template” reflecting the information we collect, even though for more elaborate problem descriptions, it might be easier for Restarters to contribute directly online, rather than capturing everything on paper. We’ll brainstorm about this with @Ellie @james.

@ugo, it is difficult to answer whether it will be reasonable or not. I know I will get used to it if the question is well-formulated and I understand why it is asked and how the data will beused. I am not sure everyone will be thorough in providing information about the spare parts they have used to repair the items or in sharing specifically the barriers to repair during the event. we tend to collect the barriers onto our scroll if the item was unsuccessful but not when we have successfully repaired the item.

About the scroll, if it is not a scroll, it will be good to have a mind map of the questions being asked on the fixometer so when talking with both the participants and the restarters, they can get an overview of the tool and the purpose of the event without having to go into the interface to understand what we are trying to achieve and what is required of them. I use the scroll when I am registering people as a mean to introduce them to the process of the events and its purpose. In other word I frame their thinking so when they finished the repair, they can provide me with the answer I am looking for…

Thanks @Marie_Lefebvre

Very good point, we’ll try to be as clear as possible

Obviously most of these fields will be optional, and they only apply to cases where spare parts were indeed used or needed

the part about barriers is relevant specifically for unsuccessful repairs, this will give an easier place to cluster them, rather than getting mixed in the problem statement. We hope that Restarters might be able to also help hosts by contributing information about a repair, which wouldn’t necessarily fit in the paper scroll and might benefit other Restarters performing a similar repair in the future (ie. a link to a useful repair guide)

1 Like

The suggestions proposed seem ok to me.

May be worth reviewing categories of devices. There are some items for which no category exists, e.g. blender (hand / jug etc.), there seem to be at least two every party I host. Also coffee machines / grinders. Also I’m not sure what the definition is of a large / medium / small laptop.

Sometimes an item turns out not to be broken. Either the fault can’t be recreated or the owner needs advice about how to use it - could be new category. So no fix as such but potentially extends life in use.

Sophia

Thanks for the feedback, @Sophia_Flucker

We currently use “Small Kitchen Item” to cover products including blenders and coffee machines, alongside other small electricals used in the kitchen. We are considering adding Irons and Watches as future new categories, as they’re quite common and not effectively captured by any existing category

Thanks, we need to make this clearer. Most of the laptops we see are “Medium”, with screen size between 13"-15". Large means laptops with screen size greater than 15" (including large MacBook Pros and generally gaming laptops). “Small” laptops include old netbooks (which used to have very small screens) and more recent ultrabooks with small screens, such as MacBook Air 11" and similar

We normally count these as “Fixed”, explaining in the problem description whether the “fix” involved explaining the participant how to make the most of the device.

relating to the discussion of per-item entries e.g.


would we consider (possibly via an API) only having unique to the fixometer entries and
having other details at e.g. ifixit…

I’m particular interested in looking at “tools (and methods?)” used for all three categories (but if its a fix, with the aid of a well made existing guide/ teardown) maybe this is self-explanatory…). This does go into the realm of more Restarter/attendee participation…)

…(hoarder/ ten-acious optimist warning!!): Can the barriers to repair be moved into the other category: surely End of life should just be for dangerous, really horrible and/or extremely smashed up :stuck_out_tongue_winking_eye: items and there should be a barrier to accessing it (Did you really try? :stuck_out_tongue_winking_eye: ) So "fixed, repairable & not-repairable this time (+barriers) and :closed_lock_with_key: end of life?

There is another category of information that would be useful to capture to improve our toolkit: what tool(s) we were missing to attempt/effect the repair.

For example at the just passed Hackney event we couldn’t attempt to fix two toasters (including one which had been diagnosed by @Ten in Tooting as needing a diode that the owner had brought along) as both needed a smaller triangular screwdriver bit than we had. I don’t believe this was captured so if the toasters (of two different brands) come again it will be pot luck if someone has the right bit when we could possibly purchase the tools we found would have been useful to add to the group(s)'s toolkit.

That’s a very good point. I suggest an ongoing thread on Tools, to suggest specific tools that were missing and should be considered by Restarters. It’s always going to be hard to have all tools at all events, but sharing key missing ones can help us revise a recommended list of basic (and not so basic ones). As for the barrier of “lack of equipment” for end-of-life, hopefully people will provide additional information on what was missing there too when logging the data