Professional Documents
Culture Documents
ABSTRACT
Scientific software;
qualitative methods.
hackathons;
multiple-case
study;
OBC
PDV
RPG
ID
Team(s)
Role
P1
Seven Bridges
P2
ADAM
P3
Arvados, CloudBioLinux
P4
Arvados
P5
Khmer, Galaxy
P6
Arvados
P7
ADAM
P8
P9
P10
P11
TangeloHub, GISCube
P12
D, O
P13
P14
P15
P16
Community website
D-U,
O
P17
Community website
D-U
P18
P19
P20
Simulation
P21
Simulation
P22
P23
D, O
D
D-U
D-U
U
Preparation
Idea Brainstorming
Building Solutions
Figure 3. Average number of source-code commits (left) and discussions (right) per day two weeks before, during, and after
each hackathon. For PDV and RPG we show unique comments posted to the GitHub issue tracker. In contrast, because OBC
participants used a shared Google Document, we show unique edits to that document extracted from the revision history.
Figure 4. Two different knowledge sharing practices: bootcamps (left), and watching others code (right).
Knowledge Exchanged
Bootcamps
Tool
demonstrations
Watching others
code
-Data structures
-Programming conventions and
practices
Round robin
discussions
explicit, it's very implicit within the data set. So that was
one thing that fall that was kind of a shortcoming that
we've managed to address now (P12)
A knowledge sharing practice that we observed only at
RPG was the bootcamp, an interactive tutorial designed to
get participants up to speed on a particular technology or
codebase. Unlike OBC where all participants were
developers and unlike PDV where domain scientists were
not necessarily expected to write code, all RPG participants
were expected to collaboratively write and share software.
Yet because of the spectrum of users to developers, the
organizers anticipated that some participants would not
have much familiarity with popular tools for software
development (P16). As a result, the organizer of RPG ran a
bootcamp where the topic was GitHub. Participants sat
around the organizer with their laptops and the organizer
projected his laptop on a screen. The organizer went
through the basics of setting up a Git repository,
transferring it to GitHub, and then adding files to the
repository. Participants followed along on their computers.
Anyone with questions would shout out, and either the
organizer or someone else with experience would answer
the question, sometimes coming around to the askers
screen to examine the issue (Figure 4, left). The close
proximity of bootcamps to other teams allowed the team
members to move freely in and out, depending on their
interest and expertise in the topic (P17, P18, P19, P22).
Bootcamps and tool demonstrations are similar in that they
both teach how to download, install, configure and use
software, but there are important differences between them.
Bootcampus focus on well-known tools that have gained
widespread adoption (e.g., GitHub, R), teaching broad skills
that will benefit most participants as they work. As a result
they are typically held before teams start work. In contrast,
tool demonstrations focus on tools developed within
research labs to do specialized analyses. They are thus
likely of interest to fewer scientists and occur within teams.
They often use specific datasets and use cases that scientists
provide during brainstorming activities in the preparation
stage. Scientists need these resources to do their work. As a
result, during tool demonstrations, scientists learn about
Teams often have a good idea about what the next steps are
regarding their tasks because there are naturally some
objectives that are incomplete and feedback that needs to be
addressed. For instance, developers who give
demonstrations of their tools can incorporate feedback
given to them about important use cases (P11, P12, P15).
OBC and RPG participants seemed quite motivated to
continue working on hackathon tasks.
For these
participants there were obvious motivations to continue the
work. OBC participants had selected tasks that they knew
would provide value to users. These included fixing
reported bugs and implementing features requested by
potential customers (P1, P2, P7). To do their work, RPG
participants need tools. Making these tools interoperate
more effectively, e.g., readily use the output of one tool as
Multiple developers expressed a desire to meet users faceto-face at future events to facilitate this process as well as
describe their projects roadmap going forward (P2, P7,
P12, P14, P18), though we do not have much evidence for
whether this actually happened. An exception was that in a
follow-up e-mail to us two months after the hackathon, P12
mentioned that at a recent research conference, he met with
some data archive managers to whom he had demonstrated
his tool. The data managers were still using his tool, and he
was able to obtain additional feedback. Using feedback he
received there, he was able to add more features to the tool.
Maintenance of Social Ties
Execution
Follow-through
Knowledge Sharing
1. Research profiles
2. Datasets & tools
3. Use, configure, install software
4. Construct workflows
5. User needs
6. Programming conventions & practices
7. Data structures
Technical Work
1. Brainstorming tasks
2. Building solutions
Community Building
1. Establishing ties
2. Maintaining ties
Table 3. Summary timeline of hackathon outcomes and component activities. We use ovals rather than straight lines to indicate
that start and end times and extent of overlap with other activities are approximations.
DISCUSSION
1.
2.
http://www.creativeworkslondon.org.uk/wpcontent/uploads/2013/11/Digital-Innovation-TheHackathon-Phenomenon1.pdf
3.
4.
5.
6.
7.
8.
9.