Hackfests, Designfests, and Writingfests: The Role of Intense Periods of Face-to-Face Collaboration in International Research Teams

As the authors of this paper have become increasingly active in
international, interdisciplinary, collaborative research projects,
we have progressively adopted a growing range of online
tools to help manage the activities. We’ve used Basecamp for
task assignment, Meeting Wizard for scheduling conference
calls, project listserves for discussion, and research wikis for
archiving the results. We have SVN for software versioning,
and Jira for tracking and prioritizing programming tasks. Our
websites provide a public face, with project rationales, contact
information, and repositories for research presentations and
articles. We also try whenever possible to provide online
prototypes, so that our readers have the opportunity to try
our interface experiments for themselves, with appropriate
warnings that things might be held together on the back end
with duct tape, and participant agreements for those occasions
when we hope to capture log records of what they are doing.
All of the online tools we use contribute to our productivity.
However, we have also become increasingly convinced of the
benefi ts of periodic face-to-face working sessions, where we
gather from the twelve-winded sky to focus our attention
on the project. In the words of Scott Ambler, “have team,
will travel.” The value of such face-to-face meetings is well
understood by distance educators (e.g. Davis and Fill 2007),
who see such focused time as a signifi cant factor in student
learning. We have been speculatively trying variations of our
working sessions, such as choice of location, numbers of
participants, types of work, and other logistical details like
meals and entertainment. Over the past three years, we have
held fourteen such events. They have involved a number of
participants ranging from as few as two to as many as fi fteen.
Nine of the events were dedicated to writing and designing;
three were used for programming and designing; one was
devoted just to programming, and another to just designing.
Our goal in this paper is to provide the insights we’ve gained
from these variations for the benefi t of other researchers
who are interested in trying their own project-oriented work
fests.
Digital Humanities 2008 _____________________________________________________________________________
_____________________________________________________________________________
17
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
Digital Humanities 2008 _____________________________________________________________________________
_____________________________________________________________________________
18
science, not related to our group, who holds hackfests at his
cottage, where the graduate students take turns doing the
cooking. We would hesitate to recommend this approach, since
there would be lost time for the cook that could be more
productively used on the project. At our most recent event,
we hired a caterer. This strategy also worked well because it
removed the added stress of fi nding, three times a day, a good
place to feed everyone. In terms of sleeping accommodations,
we have tended to provide one room per participant, since
the additional stress of living with a roommate seems an
unnecessary potential burden to introduce; private rooms can
also be a space to individually unwind away from what may be
an unusually concentrated period of time with the same group
of colleagues.
Work Rooms
The situated environment of work is very important. We have
worked in the common areas of cluster housing, in the lounges
of hotels, in boardrooms, in university labs, and on one occasion
in a rustic lodge. We hesitate to say it, because there were
problems with the internet connectivity and task assignment,
but our four days in the rustic lodge were probably the most
successful so far. We were in rural Alberta, but there was a
nearby pond, a place for ultimate Frisbee games, and there
were fi re pits, hot tubs, and wood chopping that we could
amuse ourselves with during breaks. There is a value value in
having varied forms of entertainment and leisure, which can
provide mental breaks. We prefer if possible to have a mix
of physical activities and pure entertainment (music, movies),
although it is important to be sensitive to different tastes.
Pair Programming
Even when there are a dozen participants, it is normally the
case that we end up working in smaller groups of 2, 3, or 4. The
dynamics of the group and the task can indicate the appropriate
group size. We have also recently tried pair programming,
where two programmers both work on the same computer. It
seems to be a useful approach, and we intend to do more of
it. However, the type of activity that can be paired-up seems
to depend on the nature of the participants’ discipline and
typical work approach. For example, we have found that two
designers work well together on concept planning and paper
prototypes, but they need divided tasks, and two computers,
when it comes to creating a digital sketch.
Wrapping-up
We think that if participants feel, at the end of the hackfest,
that the project has moved forward and their time was well
spent, they tend to continue progressing on the project. We
have tried a few different methods to create that sense of
conclusion and, therefore, satisfaction. At Kramer pond, for
example, we concluded the hackfest by a show-andtell of
tasks accomplished during the event, and an agreement about
the next steps participants would take upon returning home.
We have also tried to end a hackfest with a conference paper
submission. This strategy has had mixed results – about half of
the intended papers managed to reach the submission stage.
Documentation
Increasingly, we have focused a portion of our hackfest energy on
documenting the event. We have used image posting sites, such
as fl ickr.com, wiki posts, and video recording. Documentation
serves as a reminder of agreed-upon and accomplished tasks,
fosters a sense of satisfaction with the activity, and maintains a
record of successes (and failures) emergent from the activity.
Future Directions
Although there are costs associated with hackfesting, we feel
that the benefi ts so far have been tremendous. Projects typically
take a quantum leap forward around the momentum that can
be gained at a hackfest. We need to learn more about ramping
up, and we are also interested in better documentation of the
events themselves, perhaps in the form of videography.
References
Ambler, Scott. 2002. “Bridging the Distance.” http://www.ddj.
com/article/printableArticle.jhtml?articleID=184414899&dep
t_url=/architect/
Davis, Hugh, and Karen Fill. 2007. Embedding Blended
Learning in a University’s Teaching Culture: Experiences and
Refl ections. British Journal of Educational Technology, 38/5, pp.
817-828.