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:
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.
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.