This Friday and Saturday the SpotOn London Conference will take place at the British Library in London. I am very excited, as I have come to this conference since the first one in 2008, and have helped organize the event since 2009. The conference is about science communication in the broadest sense, and has three strands that focus on science communication, science policy and tools. Equally important as the sessions are of course the many highly engaging informal discussions of the 250 participants that take place between and after the sessions.

Presenting from SpotOn London 2012 hackathon. One of the projects in 2012 was a collaborative commenting system. Picture from Flickr, taken by Lou Woodley.
Presenting from SpotOn London 2012 hackathon. One of the projects in 2012 was a collaborative commenting system. Picture from Flickr, taken by Lou Woodley.

SpotOn London sessions are also more conversations than presentations, as they usually have 2-4 panelists with ample time for discussion with the audience. I will take part in two panels:

I will summarize my thoughts regarding the altmetrics session in another post, but want to talk about the first session in more detail. According to the English Wikipedia

A hackathon (also known as a hack day, hackfest or codefest) is an event in which computer programmers and others involved in software development, including graphic designers, interface designers and project managers, collaborate intensively on software projects.

Wikimedia Hackathon Berlin June 2012. Largest hackathon I have attended so far with 100 people. Photo by Gulliaume Paumier, CC-BY license.
Wikimedia Hackathon Berlin June 2012. Largest hackathon I have attended so far with 100 people. Photo by Gulliaume Paumier, CC-BY license.

It is too bad that we will have no hackathon at year’s SpotOn London for logistical reasons, but the session is a great opportunity to reflect on the value of science hackdays. It is clear that hackdays for scientific software have become popular, with almost too many opportunities to participate.

What I like

  • Do stuff. And have plenty of time to do stuff instead sessions in short intervals
  • Hackdays let you do great team work
  • Learn about other interesting projects and meet people doing cool work
ALM 2012 hackathon. Brainstorming board from anti-gaming group.
ALM 2012 hackathon. Brainstorming board from anti-gaming group.
#hack4ac. Our team working on PLOS Author Contributions.
#hack4ac. Our team working on PLOS Author Contributions.

What I don’t like

  • Hackdays are very much targeted at intermediate to advanced software developers, and it is sometimes not easy for beginners to participate
  • Too much time spent setting up stuff
  • Some of the work done at hackdays can be better done in virtual collaborations over weeks or months
  • Not many projects make it beyond the hackday and actually turn into a useable product. One example where this is not true are the visualizations started at the ALM 2012 hackathon that were implemented by OJS in 2013 (see article for more), and of course ImpactStory that started at a hackathon at the Beyond Impact conference in May 2011.
ALM 2012 hackathon. Sparkline visualization implemented by OJS based on work at the workshop.
ALM 2012 hackathon. Sparkline visualization implemented by OJS based on work at the workshop.

Some of the challenges

  • Coming up with projects where progress can be made in a day or two
  • Technology: WiFi access, access to servers for code deployment, collaboration tools, etc.
  • Come up with a good unifying theme, so that the various projects during the hackday relate to each other. The theme at #hack4ac was to demonstrate the value of the CC-BY license within academia.

Some ideas to improve science hackdays

  • Go beyond software development. We recently tried a data challenge using Altmetrics data, and at a hackathon between IGSN, DataCite, PANGAEA and ORCID in July we focussed on a high-level discussion of technical issues. There is a continuum towards the BarCamp format, although I don’t like to drift too much from doing to talking. A good example of a workshop open to everyone and not just software developers is the SpotOn London workshop this Saturday on Wikipedia Editing run by Brian Kelly and Toni Sant.
  • Meet before and after the hackathon. This can be done online, but it helps to focus on what can be achieved in the limited time available for a hackathon, and to follow up on projects that have just been started. But a hackathon is also a great opportunity to meet new people and new ideas, so meeting afterwards is more important than before.
  • Involve remote people. A lot of the fun of hackdays comes from sitting around a table and doing something together. But sometimes this is not possible for everyone, so think about remote participation where it makes sense.

Next: What is holding us back?

Last Friday and Saturday the 6th SpotOn London conference tool place at the British Library. I had a great time with many interesting sessions and good conversations both in and between sessions. But I might be biased, since I helped organize the event, and in particular did help put the sessions for the Tools strand together.

blog comments powered by Disqus