Book of Abstracts - phase 14 - elektroninen.indd - Oulu

Digital Humanities 2008
_____________________________________________________________________________
Types of Work
It is important that these not be meetings. No one expects
to get work done at a meeting, not in the sense of writing a
paper, designing a system, or programming, so the expectations
are at odds with the goal of the exercise. Meetings typically
carry a lot of connotative baggage, not least of which is
ineffi ciency and frustration, as expressed by the educational
videos with John Cleese entitled “Meetings, Bloody Meetings.”
Humanists are rarely trained in conducting meetings effi ciently
and productively, and it shows. By emphasizing to all the
participants that the goal is to work productively together in
the same room, we can hit the ground running and get a lot
accomplished in a short period of time. We have in almost
every case combined people who are working on different
kinds of tasks. In the two instances where we had only a single
task (programming and designing, respectively) we had a sense
of accomplishing much less. It is diffi cult in some ways to verify
this perception, but the energy levels of participants in both
cases seemed lower. Our interpretation would be, not that
there is competition per se between different disciplines, but
that it is harder to judge how much another disciplinary group
is accomplishing, and that uncertainty helps to keep people
motivated.
Location, Location, Location
There are many temptations to locate the events in places
that will be convenient. We have found that in this instance it is
better to avoid temptation if possible. For example, if there are
fi ve participants and three are from the same city, why not hold
the event in that city? It reduces costs, in particular for travel
and accommodations, and the participants can also serve as
hosts for their out-of-town colleagues. In practice, however, we
have found that holding a hackfest in some of the participant’s
hometown, lowers the hackfest’s productivity level. The
biggest obstacle is the local demands on the attention of the
resident participants. We have found that local participants are
constantly on call for work and domestic commitments, which
means they tend to absent themselves from the event. One
local host for a comparatively large number of participants is
less problematic, since the periodic absence of one participant
is not as critical a factor in maintaining the momentum of
the entire group, but for small groups it can be signifi cant.
An alternative is therefore to transport the participants to
a pleasant working location, provided that the attractions
of the location are not so powerful as to be distracting. We
are all familiar with conferences in exotic locations where
participants have diffi culty focusing on the conference because
the beach is calling. Given this mixture of considerations, our
current guideline is therefore to use a location no closer than
an hour’s travel from some cluster of the participants, so that
both the overall travel costs and local demands for time can
be reduced.
Participants
In general, the participants on our research projects know what
they are doing. In fact, many of them are eager to get going on
tasks that have fallen behind due to the other demands on
their time. So in general, it has not been necessary to provide
a large administrative overhead in terms of controlling and
monitoring their activities during the event. Given the nature
of interdisciplinary collaboration, too much attempt to
control is counter-productive in any case. However, the nature
of task assignment during a hackfest is a matter that may
require some fi nesse. We have made errors where we had
someone working on an assignment that was not the kind of
assignment they could tackle with enthusiasm. In these cases,
a little preliminary consultation with the individual participant
would have made a big improvement. This consultation could
have occurred either before the hackfest or even upon arrival,
but it was a misstep not to have it early. In terms of numbers
of participants, it appears that you need enough people to
generate momentum. Two or three is not enough, although
four seems to be. Our largest group so far has been fi fteen,
which is somewhat large to co-ordinate, and they end up
working anyway in smaller groups of 2-5, but a larger group
also makes the event more dynamic and can provide greater
opportunities for cross-disciplinary consultation.
Our hackfests are set up according to a fl at organizational
structure. All participants are treated as equals and decisions
are, as much as possible, based on consensus. Even when
planning a hackfest, we consult with all invited participants
on potential locations, duration, and objectives. In rare cases
where leadership is required during the event, it is clear to
everyone that the overriding structure is based on equality.
For mid-sized groups, we fi nd that it is useful to have a “rover”
or two, who constantly moves between the different groups
and tries to identify potential problems and opportunities for
bridging group efforts.
A further point related to participants is to, whenever possible,
consider the past, present, and future of the project. It is too
easy to focus on what needs to be done immediately and to
only include those who are currently active in the project.
However, we have found that including previous participants
– even if they are not currently active on the project – helps
to remind the team of some of the institutional history,
providing some context for past decisions and the current
situation. Similarly, a hackfest is an excellent opportunity to
recruit prospective new colleagues in an intense and enjoyable
training experience.
Meals and Accommodations
We want these events to be highlights for people on the
projects, so it is important that the meals and accommodations
be the best that we can reasonably afford. Eating, snacking,
and coffee breaks provide time for discussions and developing
social capital, both of which are signifi cant for the success of
a research project. We have a senior colleague in computing
_____________________________________________________________________________
17