Logging repairs made outside of events

James et al.,

Is it possible to log ad-hoc repairs to the fixometer that are not attached to an event, (but possibly only to a fixer or group)? If so how? If not is this something under consideration please?

Thanks
Divya
ooo-xxx

Hi Divya,

This has come up a few times before and you can see the previous discussion on Github.

The tl;dr: is that this is something we’d like to support, especially if it would motivate repairers to use Restarters.net more. However, it’s not been on our list of priorities yet and we still have some questions about how it would work (especially when it comes to the veracity of data added).

Feel free to add this as a feature request here: #restarters-dev:feature-requests and we can resume these conversations :slight_smile:

1 Like

Posting a related question here from @Rosalie_Heens


Given that these repairs do happen at events and are part of a wider scheme, I’d be less worried about the veracity of data collected than when repairs are made outside of events by individual repairers. Although as you say, Rosalie, these events aren’t designed for participatory community repair but more like training sessions or repair service.

From a data-collection standpoint, I think it would make sense to facilitate this, particularly as it could offer the repairers a double benefit: improving repair skills and contributing to the movement’s data assets. The downside would be that we’d have to start changing the way we talk about the data we all collect - i.e. no longer ‘collected at community repair events’.

Would be interesting to hear from the rest of the @Staff-team on this one

1 Like

I agree that data from events such as the ones described by @Rosalie_Heens makes perfect sense for inclusion. They’re still events organised by a group. They might well be an opportunity for volunteers to get involved with documenting and contributing more detail data about a repair they’re doing. The way we describe this would have to change to data about activities by community repair groups (or something similar).

These could be logged already, using the current system, but without announcing the events if they’re not public (so, posting them after an event take place). However, if the goal is to promote them to volunteers, an alternative solution might be needed.

@Divya_Pujara makes some good points in his post on github (link above). Repairs done by groups in ad-hoc situations, such as makerspaces and schools, are similar to what Rosalie mentions. Repairs done by individuals on their own are quite different: in the sense that the social element at the heart of community repair wouldn’t be there anymore.

1 Like

Dag Ugo en James,

Bedankt voor jullie reacties.

Zelf denk ik dat het de vrijwilligers zeker kan motiveren om de fixometer, wiki en platform te leren kennen en gebruiken. Deze vrijwilligers doen, naast dit project, ook ‘gewone’ Repair Café’s, open voor het publiek. Er is dus veel kans dat ze de fixometer nadien ook gaan gebruiken voor die community repair activiteiten.

1 Like

This is an interesting discussion, albeit an old one! As a newly established Repair Café operating in a community makerspace similar issues to @Rosalie_Heens are being raised here.

1 - Logging Repairs Performed By Members of a Makerspace
There’s discussion in our makerspace about how to log repairs carried out independently of Repair CafĂ© events (makerspace is open 24x7, Repair CafĂ© is once per month) I’m thinking of adopting this procedure (which incorporates ideas culled from discussions seen here on restarters):

  • at the beginning of a month we create an event in the fixometer called “In House Repairs” dated the last day of the previous month. Repairs carried by members of the makerspace during the previous month are logged against that event. How does that sound?

2 - Permissions for Logging Repairs
I notice that it’s possible to have more than one person in the group assigned as a host. So am I right in thinking that if someone volunteers to do data entry then all I need to do is to assign them as a host?

Hi @David_Marks !

1 - Logging Repairs Performed By Members of a Makerspace

What is the nature of the repairs being done? Is this people working together on repairs in the makerspace - someone working together with the owner of the device?

am I right in thinking that if someone volunteers to do data entry then all I need to do is to assign them as a host?

That’s correct, yes - as a host they will be able to perform the data entry for events.

Neil wrote

What is the nature of the repairs being done? Is this people working together on repairs in the makerspace - someone working together with the owner of the device? <<
Could be all sorts, recent examples include:

  • someone gifted an electric lawnmower to a member because it “smelt of burning and was smoking”. 2 members worked together to strip it down and identify and remove a mouse nest that was blocking air vents and had started to smoke. Tested and works OK, but would probably benefit from a comutator clean and new brushes.
  • cordless drill donated to makerspace to go into a community tool library, a member tested it and t works but needs a replacement battery. Another member intends to re-cell the battery.

And so on. It sounds like criteria for work that’s loggable on the repair monitor should include more than one person being present and there is a transfer of skills or knowledge - am I on the right track?

It’s a great question. Generally, yes at present, we refer to the data collected in the Fixometer and upstream at the Open Repair Alliance as having come from ‘community repair’, implying working together, skills and knowledge transfer. So for those cases where it’s an individual working on something themselves, it doesn’t really fit.

Always good to discuss example what this means though, would be interested in @Staff-team take on this, as it’s a nuanced question!

This has been a long standing topic of interest and I’d like to contribute the following to the debate.

  1. In the case of a ‘fixer’ working on the repair of an item alone; In my opinion that item ought to be logable on the fixometer. If the entry will contain important intelligence and transferable learnings on the repair of such items that will be of use to future fixers. Whilst there was no skills and knowledge transfer on such an occasion from the fixer to a member of the public (ostensibly the owner of the item) there may have been skills and knowledge learned by the Fixer which by recording will also be skills and knowledge later transferable to other fixers who can look up if anyone else has attempted repair of such an item before. This could be as simple as a weblink to data or a repair guide for that item or it could be a full writeup on how a problem was solved and the experience gained when other information was lacking on the internet. In many cases this could include intelligence gained even when the repair was not successful.
    In my experience there is always some form of skills share or knowledge transfer and learning occurring where novice repairers are concerned and often even when very experienced repairs are involved. That knowledge transfers might be from the internet to the fixer rather than the fixer to the owner. Or fas should be encouraged expert knowledge from the experienced fixer to the Fixometer and then onward to future fixers.

  2. What of the case where, a repair is done independently by the fixer on behalf of the owner because of some practicality, e.g. drop of and pick up repairs done over the pandemic? Or repairs at interactive repair events which need to be completed ‘offline’ after the event when the owner is not there?

  3. I would advocate that fixers and not just hosts be enabled to enter data to the fixometer and be easily enabled to do followups by being able to refer directly to a case either by the fixers name or case number. This is especially helpful to enable live entry of data to the fixometer whilst the repair is being done helping prevent subsequent loss of data and acquired knowledge and intelligence rather than less useful data by an uninvolved host or data entry volunteer who can only meaningfully contribute what the item was and if a repair was successful or not. It also prevents duplicate entry and consistent tracking of items which are repaired at more than one sitting or by more than one Fixer at different times. Or if the item come back subsequently due to the fault occurring again or another cascade fault having occurred. This will also be of use when repairs are done adhoc and not at a specific repair event e.g. by members of a makerspace or as in my case at Leicester Hackspace. Often such repairs (at least in my case) do still involve knowledge transfer to the owner but are essentially orphaned repairs not associated with any specific event. I.e. without need for an event to be timetabled advertised, set up and await approval with a host or data entry volunteer involved, just for a single or couple items to be repaired and logged.

In my own case alone the above in combination represents hundreds of repairs that have gone unlogged over the last few years either at Leicester Fixers, Leicester Hackspace or by giving repair advice online.

ooo-xxx