• amcewen
• Slides
• 1 comment

Recently I gave a talk at the inaugural Festival of Maintenance. It was a day-long celebration of all things fixing and maintaining, organised in part by DoES Liverpool community members Jackie Pease and Ross Dalziel. It took place down in London, but thanks to help from Matt Croughan and Alex Lennon, it was also live streamed at DoES Liverpool.

My talk was about how we (ab)use Github issue lists to help with communication and management of all the maintenance tasks that need to be done in order to keep the space running. You can read through my slides and the notes of what I planned to say here…

Or if you’d rather watch me (and see what I actually said…) then watch this video.

The talk immediately before mine was from the Guerilla Groundsman, a civic-minded individual who has been fixing up things around Cambridge. As a result, at the end of my talk I briefly mentioned the experiment I’ve been running to take the Somebody Should issue list idea and apply it to all of Liverpool.

Afterword

After the talk there was an interesting discussion on Twitter about whether Github is too geeky a tool and so a barrier to entry for non-software-developers. I didn’t get chance to join the conversation at the time, but figured I’d add some of my thoughts on it here.

I can totally understand that Github isn’t very user-friendly. I’m not especially wedded to Github itself, but I do think the issue list has some big advantages over tools focused more as to-do lists (and I say that as someone who spent a couple of years failing to build a business around a web-based to-do list tool, but thinking lots about it as a result).

We chose Github because a sizeable chunk of the community already had accounts, which reduced one of the barriers to entry during bootstrapping, and we already had some code hosted there. However I think most issue trackers would work – the Labels feature is an important one in the way we organise things (unsurprisingly that—although called “tags”—was a big feature of my to-do list app). Ditto an API for building custom scripts on top of it.

Github is far from perfect, but I think there’s a risk of the perfect being the enemy of the good enough. I also think that we should be applying the same attitude to our software tools that we do to our other tools and enhancing, reworking or replacing them where they don’t suit our particular needs. We’re taking a first step in that to improve the granularity of email notifications.

I also think there’s a balance to strike between making the system easy for non-geeks and helping the non-geeks get to grips with the system. Again, we have a culture of helping people learn how to use tools they’re not familiar with, be that a 3D printer or a hand plane. Software tools shouldn’t be any different. It’s 2018, needing some help and guidance to familiarise yourself with digital tools is fine, refusing to “do digital” is not.