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.
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:
- What the hack?! (Friday 10:30 AM, hashtag #solo13hack), with Peter Murray-Rust, Ross Mounce and Helen Jackson
- What’s your number? - Altmetrics session (Saturday 10:30 AM, hashtag #solo13alt), with Marie Boran, David Colquhoun, Jean Liu and Stephen Curry
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.
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
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.
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.