In the Spring 2017 semester, a few of my colleagues and I organized an undergraduate hackathon focused entirely on a collection of digitized student newspapers from each of the Five Colleges of Ohio, dating back to 1856. The Five Colleges of Ohio is a consortium of five private liberal arts colleges including Denison University, Kenyon College, Oberlin College, Ohio Wesleyan University, and the College of Wooster. In the end, it was truly an inspiring and surprising experience, but it’s worth noting that as easy as it might be to say “Let’s do a hackathon!”, it’s much harder to pull off. It’s a lot of work.

During the planning process, we scoured the Internet and journal literature for information about how to plan a hackathon. We found tons of information. There is really no shortage of articles, white papers, and blog posts with advice and guidelines for organizing hackathons, many of which I’ve cited below. Unfortunately, none of these laid out a roadmap that felt quite right for the type of hackathon we had in mind. This post is an attempt to share the context of our particular hackathon, the process of planning the event, and some reflections on the experience for others who might find themselves at the helm of a hackathon planning committee.

First, a little context…

Background

The libraries from the Five Colleges of Ohio have been engaged in an active digital scholarship program for over eight years. Over these eight years, we’ve collaborated on two generous consecutive grants from the Andrew W. Mellon Foundation, the first of which sought to digitize collections from the libraries’ rich archives and special collections. These collections were then integrated into courses in partnership with colleagues from the faculty and our educational technology groups. This grant resulted in over forty digitized collections, one of which was the joint student newspaper collection.

The second grant reversed this approach, seeking first to encourage faculty with ideas about incorporating digital collections, tools, or methodologies into courses to share those ideas with the libraries and their partners in ed tech. The libraries then helped to support the development of those ideas into real projects through funding, consultation, technical expertise, and project management.

Most of the digital projects developed under the latter grant have been institution-specific. They were conceived, developed, and used by members of their own respective campus communities. As we neared the conclusion of this grant (or so we thought – we later requested and received a two year extension of the term), we aimed to develop a truly collaborative consortial project that would bring together representatives from all five campuses around a common project.

Enter the Five Colleges of Ohio Student Newspaper Collection.

The student newspaper collection represents some unique opportunities and some daunting challenges. It spans 160 years and contains over 170,000 pages of newspapers. It’s a highly used collection as reported by our archivists and special collections librarians who often consult the collection or direct patrons to it for historical information about our campuses. It’s currently housed in a CONTENTdm repository, but our users’ experiences with search and retrieval in the collection have been hit or miss, giving rise to questions about the usefulness and quality of the underlying data.

Given the scale of the collection, the libraries outsourced its digitization to a third party which scanned the papers and extracted the full text using optical character recognition (OCR) software, but due to the additional costs, we did not opt for article segmentation and OCR correction of the papers which would have clearly delineated the individual articles in the full text. Instead, the resulting text reads across the page, across columns, across articles, resulting in a single text block for each individual page, regardless of the document’s structure. Having the full-text makes keyword searching possible (which was the original goal), but it poses challenges to computational techniques like sentiment analysis that seek to identify attitude (positive or negative, for example) based on the words surrounding a term. In our case, the words surrounding a term might be from entirely different articles and therefore not related contextually. The OCR’d text is also uncorrected, containing many malformed terms.

To address these challenges, we inquired with a handful of digitization vendors about the costs of re-OCRing the collection and segmenting the articles. The costs were reasonable given the work involved but prohibitive for us, especially since we did not have a clear sense of how much of a return on such an investment we could reasonably expect. To help identify uses of the collection and to understand what could be accomplished with the data in its current state, a member of our Ohio Five Digital Collaborations Group, a team of librarians representing the digital initiatives units at each college, suggested opening the collection to students to see what they might do with it. From there, we envisioned a hackathon as a possible format for engaging with the collection, involving a collaborative group of students working directly with the collection and a group of helpful librarians, faculty, and technologists to help direct and guide students as they asked questions of the data. It was at this point that someone uttered the words “Let’s do a hackathon!”, and the project was born.

Framing an Academic Hackathon as an Opportunity for Learning and Experimentation

The term hackathon can invoke images of pizza-fueled all-nighters where bloodshot eyes pour over hastily written code slapped together in 24 hours with the hope of taking home some sort of high priced tech toy or monetary prize. This image is, of course, at odds with the type of rigor and critical thinking the academy seeks to instill in students of the liberal arts. We suspected that we might encounter some skepticism from our campus communities and really weren’t sure if students would be interested, so we first vetted the idea with members of the computer science departments on each campus. From this vetting, we learned a few things early on:

• Nearly all of the faculty thought it was a great idea but were unable to volunteer their time to help organize the event.
• The event should have a theme or some sort of structure to help students identify a focus and a realistic project so they don’t leave disappointed in what they were able to accomplish in a short time.
• Students should be supervised or mentored by faculty to help them identify ideas, approaches, and to help when they get stuck.
• Short hackathons (24-48 hours) are great for investigating solutions but not for developing finished projects.

These early findings helped tremendously to frame the hackathon as a mentored experience that would focus on textual analysis of the newspapers in which students would apply newly learned skills, technologies, or techniques to explore the dataset.

With this input from the faculty and a slightly clearer scope for the event, we convinced our library directors of the merit of the event, developed a proposed budget, and secured funding from the then current digital scholarship grant under which the hackathon would be conducted.

Planning the Hackathon

I hesitate to suggest an optimal timeframe to allow for planning to take place because it’s largely dependent on the scope of the event, the state of the data with which participants would be asked to work, the people involved, the geography of the anticipated participants, and many other factors that may influence the velocity with which the planning group is able to move things along. Once we began in earnest to plan our event, it took about six months, but with a larger planning group and more experience, it could have come together much more quickly.

Purpose and Scope
Most people have heard of hackathons. They carry a bit of a negative connotation in some circles and are generally thought of as male-dominated, competitive, and stressful events. It’s not safe to assume that proposing a hackathon is going to be an easy sell to colleagues and administrators. Some may wish to apply a more neutral label to the event like “workshop”, “unconference”, or “codefest” to combat this image and convey something that may be more in line with the intended outcome. We chose to stick with the therm hackathon, but were we to conduct another event like this, I believe we’d experiment with other names.

More important than the name, though, is the purpose of the event. We developed a Statement of Purpose to articulate our view of the intended learning outcomes for students, the basic conceptual overview, and some examples from other educational institutions to help contextualize this event in an academic environment. We used this statement to communicate the idea to our administrators and potential collaborators as we sought partners to help organize the event. This exercise of drafting a statement of purpose was also useful in narrowing the scope in our own minds so that as we began to have conversations with potential collaborators, we could speak with one voice about what it was were trying to accomplish.

The Budget
Our original budget changed as our organizational model changed. It’s significant that we were working with students on five different campuses that are spread out geographically with driving distances between them ranging from 40 minutes to two hours. Our initial plan budgeted for a hotel ballroom and several guest rooms to serve as a common headquarters for the event and several breakout rooms for group work. It also included a small amount for faculty stipends, librarian stipends, and student stipends. This changed completely when we decided to host the event in the library on one of our campuses, invite mentors from outside our campuses, and scrap the stipends for students.

The total amount budgeted for the event was $16,500. We spent $12,456.54. The majority of our expenses went to procuring mentors, food, and incentives. In retrospect, we could have budgeted less for incentives and more on either food or mentors. Incentives seemed to be much less important to the students who participated in the event than we anticipated. In fact, they seemed to perceive the prizes and participation gifts as unexpected surprises.

Planning Group
Once we’d obtained buy-in from our colleagues and administrators, I put a call out to the members of our consortial team of digital initiatives librarians and educational technologists asking for volunteers to help plan and organize the hackathon. From that call, I received responses from three people: Debra Andreadis (Deputy Director of the Denison University Libraries), Jacob Heil (Digital Scholarship Librarian and Director of Wooster’s Collaborative Research Environment – CoRE), and Jon Breitenbucher (Director of Educational Technology for the College of Wooster). We setup a project in a shared Basecamp site to serve as a home base for online communication and planning documents, and we scheduled a 30 minute bi-weekly standup meeting beginning in September 2016 and ending a week before the hackathon in March 2017.

It’s important that members of the planning group understand that planning an event like this is a commitment. Like many of our colleagues, we were working on many initiatives simultaneously with lots of competing priorities, and I suspect all of us underestimated the amount of coordination it would take to pull this off. In retrospect, it would have been helpful to have a few more folks on the committee, or simply allocate more dedicated time to planning this event for those serving on the committee.

Location, Date, and Time
Without a location, date, and time, the event isn’t real. There’s no sense of when or where it will happen so it’s difficult to communicate about it in a way that sounds like anything but ideas about something that might happen. In our case, we decided to host the hackathon in the College of Wooster Library, specifically in a central space the college calls their Collaborative Research Environment (CoRE). It really was an ideal space with a large central hub where we could conduct workshops, serve food, and have discussions while also providing lots of smaller breakout spaces for group work and, of course, sleeping.

While it’s a topic for another piece, I think there’s an opportunity here with a hackathon like this to model different uses of the library out in the open for all to see, namely as a collaborative space where people from different backgrounds experiment with data, technology, and information to create new knowledge. The central space in Wooster’s CoRE is a large glass room through which nearly all activity is visible from the entrance and main lobby. That visibility can impact our perception of what the library is and the purposes it serves. Like I said, though, it’s something another piece…

The date of the event is important. Are there competing events on campus? Exams? Final papers due? Other academic milestones that might impact a student’s interest or willingness to participate? We settled on March 31 as the date for the event. There were no big campus events, Wooster’s Independent Study projects were due the week prior, and it fell outside the spring break periods for all five colleges. Still, though, we encountered students who had registered for the hackathon but ultimately did not attend due to stress or other projects on the horizon. There will never be a perfect time, but it should be strategically scheduled around other events on the academic calendar.

Web Presence
We created a website to serve as the home base for information about the hackathon. We also created a Code of Conduct, a Registration Form, and a Facebook Group, all of which were linked from the website. The website itself was created using a simple HTML5 template and hosted by Reclaim Hosting on the same server we use to host the website for the Five Colleges of Ohio. For the URL, we wanted something simple and easy to share so we created a subdomain of our ohio5.org domain called https://hackoh5.ohio5.org.

We felt it was important to develop a code of conduct and share it both on the website and then emphasize it again in our communications before and during the event. We discovered the Hack Code of Conduct project which provides customizable language and branding that allows organizers to tailor their page for their own particular event or audience. This allowed us to simply link to the code from the main website.

In developing a registration form, we aimed to frame the questions to be as inclusive and welcoming as possible, recognizing that students may be coming to the website and the registration form from different social, cultural, racial, and economic backgrounds, not to mention different levels of knowledge and technical ability. We asked students to specify their preferred pronouns, any dietary restrictions, technical skills, previous experiences with hackathons, and an open ended question asking for any information that might help us accommodate them and make the hackathon a positive experience.

Our intention with creating the Facebook Group was to begin to encourage students and mentors to introduce themselves to other attendees, share early project ideas, or perhaps begin to form teams around those ideas. We didn’t have much success here, and we can only speculate that perhaps they were intimidated to be the first one to share, or perhaps they were just too busy with other projects to bother with engaging with the hackathon before they had to.

Data Preparation
In retrospect, we were naive about the scale of the data we had and the formats in which we had originally planned to share that data with the students. The full dataset was available in multiple formats:

• A single 1.5 GB XML file exported from CONTENTdm
• An open API through which calls can be made to retrieve page images, full-text, conduct searches, etc.
• Replicated on multiple physical hard drives we planned to distribute during the event.

The single XML file was so large and contained so much textual data and XML markup that it took approximately eight minutes for the file to open in a text editor like Sublime Text. Similarly, the files on the physical hard drives, which included one folder each for the thousands of images and xml files, took anywhere from 30 seconds to one minute to fully expand so the user could simply see the contents of those folders. The CONTENTdm API performance was fine for queries of individual pages, images or keywords, but we were a bit concerned about what may happen if we suddenly unleashed twenty students to issue simultaneous requests on the API to pull down all the data. The data simply was not optimized to perform any sort of analysis or exploration through computational methods.

Luckily, one of our mentors, Terry Reese from The Ohio State University Libraries, had taken some time in the days leading up to the hackathon to develop a pair of applications written in C# to better prepare the data. These applications parsed through the data, grouping it into nested directories by college and then by issues. Each issue was represented by a JSON file written in the IIIF Presentation Specification which allowed not only for easier parsing but also a new opportunity to experiment with tools like the Universal Viewer or Mirador to compare and annotate the content in the collection.

We developed a HackOH5 Resources Guide for the participants that explained how and where to access the data in these different formats, example API calls, and a list of tutorials related to textual analysis and text processing. We shared this ahead of time with the participants so they could begin to experiment with the data before arriving at the hackathon.

Mentors and Partners
We learned through our early discussions with faculty, our colleagues in educational technology, and from students who participated in other hackathons that mentors would be a key component in providing structure, support, and technical expertise to the student participants. We found it quite challenging to recruit qualified mentors, and in retrospect, it’s a pretty big ask so it’s really no surprise. We were asking potential mentors to give up an entire weekend, stay up all night, and participate in something we’ve never done before with unknown outcomes.

We started with emails to the computer science faculty and information technology departments at all five colleges. From these emails, we were able to recruit two faculty members from Denison University, Jessen Havill and Tom Bressoud, who were just then spinning up a Data Analytics major at the college and were very interested in the type of interdisciplinary opportunities the hackathon presented. Another faculty member offered to participate as a judge at the conclusion of the hackathon. Aside from those two responses, it was largely radio silence. I did receive one additional reply from a computer science professor who strongly encouraged me to explore other ways of engaging students, writing that he was philosophically opposed to hackathons, that they tended to cultivate and encourage bad habits in software engineering. This response reflected the broader, negative perception of hackathons that we struggled to combat in our communications about our intent.

Since we were unsuccessful recruiting mentors from our own faculty, we decided to broaden our pool by reaching out to computer science departments at several research universities and technical institutes nearby, seeking graduate students or professors. Again, radio silence.

Finally, we decided to shift gears and think more carefully about who would make the best mentor, given our data and our theme. We decided to tap into our network of digital humanities practitioners both within and outside the state with experience working with textual analysis at the type of scale were were dealing with and familiarity with the types of humanities-based research questions and methods practiced in the digital humanities. We ended up with an excellent panel of six mentors:

• Thomas Bressoud, Associate Professor of Computer Science, Denison University
• Scott Enderle, Digital Humanities Specialist, University of Pennsylvania Libraries
• Jessen Havill, Professor of Computer Science, Denison University
• Terry Reese, Head of Digital Initiatives, The Ohio State University
• Bryan Tarpley, Lead Software Applications Developer, Initiative for Digital Humanities, Media, and Culture, Texas A&M University
• Brandon Walsh, Mellon Digital Humanities Fellow and Assistant Professor of English, Washington and Lee University

We developed a memorandum of understanding which outlined the agreement between us and our mentors. It may seem like overkill, and perhaps a little off-putting to some, but if nothing else, it really helps to communicate clearly to each mentor what the expectations are on both sides and helps to align everyone with a common understanding of what the goals are for the event.

We held one video conference call with all the mentors about one month before the hackathon so that everyone had a chance to meet each other, to review our intended schedule, workshops we were asking them to lead, and the general expectations for mentors.

It might be surprising (it was to us) how many other people on campus need to be involved in the planning. Here are some of the folks we ended up speaking to:

• Information Technology: We reached out to the Wooster IT department to confirm whether or not there would be any planned maintenance or downtime scheduled that could impact network performance during the hours of our hackathon. We also requested guest accounts for the campus wifi network which offered better performance over the more open guest account.
• Public Safety: Since students would be spending the entire night in the library, we wanted to be sure we had some input from the public safety office to ensure that escorts would be available in the case of students needing to walk across campus to their vehicles at night. We also arranged to get swipe access cards for each student so they could come and go from the building during off-hours. The office also provided parking passes for those with vehicles. We distributed both the parking pass and swipe access cards when students signed in at the registration desk.
• Student Affairs Office: As we were wrangling with questions about how to transport students, where they might sleep for the night, how to feed them, and how we could ensure their safe return home, it struck us that these were likely not the first time event organizers have encountered these questions. We reached out to the Student Affairs office to see if perhaps the hackathon might be something they’d be interested in helping to organize or at least help to promote. Our conversation there was useful in that it allowed us to communicate what we were doing, but unfortunately, the folks in that office were not interested in pitching in with any time or resources.
• Transportation: We offered to provide transportation for any students who did not have a means of getting to the College of Wooster. This required some coordination with the students, but ultimately, we were able to arrange for one van to shuttle students from Denison and Kenyon to Wooster and back.
• Risk Managers: Since there was an overnight component to this student event, especially since transportation was involved, we thought it wise to reach out to the risk managers at each institution to inquire about whether or not we’d need students to sign a waiver. The risk managers were initially stymied by the fact that students would be sleeping overnight in the library, but once they understood what we were doing, they decided waivers wouldn’t be required.
• Food Services: We found it easiest to work with the food services unit on campus to arrange for preparation and delivery of all but one meal. This releived us from having to pickup and transport food all over campus. We made an effort to provide healthy food options, including soups and salads, granola bars, and fresh fruit, but we did also provide energy drinks to help fuel the evening activity.
• Campus Lodging: Initially, we were not planning to provide alternative accommodations for students, but a few students raised some safety concerns about spending the night in the library. We opted to reserve two rooms at the Wooster Inn, a campus hotel within walking distance of the library, and several of the students opted to share those rooms. We also needed to arrange for a separate hotel room for two students who spent the night in the library but were not comfortable driving back to their home campus after a sleepless night the previous evening. These are important safety concerns that should be considered but can be difficult to coordinate.
• Judges: In our case, because the event was framed as a competition, we recruited three judges to evaluate the projects and select the winners. We developed a [rubric] that the judges used to evaluate the projects. We attempt to recruit judges with different roles and from different backgrounds at their institutions. Our judges consisted of one computer science professor, an educational technologist, and a digital scholarship librarian. Our judges were asked to select first and second place winners, which means two of the four teams were left without recognition for all the work they poured into their projects. A different approach is needed here to assess the projects and provide ample recognition and encouragement to the participants.
• Student Organizations or Clubs: While there were not students on the planning committee, we did talk to students to help inform our planning, and they were also helpful in getting the word out to other students and clubs.

Communication
This is an area where we could have done a better job. Our communication plan consisted of the following elements:

• We designed a print flyer and distributed that to members of the digital initiatives units at each library to share with their campuses.
• We also drafted an email template for our colleagues in those same digital initiatives units to communicate with their faculty, students, and fellow librarians.
• We sent and drafted emails to the IT and Computer Science departments at each college, encouraging each to share information about the event with students or student workers.
• In a few rare cases, we publicized the event through library social media channels.

I sensed that the message was not as widely distributed as we would have liked, and I think that’s partly due to a reluctance among colleagues and administrators to promote something something that has an uncertain outcome. For all the reasons that give hackathons a bad reputation, some may have been reluctant to put their name on an experiment which, frankly, could have blown up in our faces. I believe others may have felt they just didn’t understand the event and felt unsure about who the audience was. Perhaps this is something that, through more inclusive branding and clearer communication, we could have addressed. It’s helpful, though, to have the experience of hosting and conducting an event like this because it provides a context and an example to which we can refer colleagues who may have questions about the purpose and intent of future hackathons.

Workshops
Workshops can serve multiple purposes. For those with technical skills and ability, a workshop can be helpful to get up and running with a new language, technology, or method that may be relevant to the theme of a hackathon. However, workshops can also be an important and useful way to include those without strong technical background, to make the experience much more about learning than building, and equipping participants with enough knowledge to contribute to a team or project.

The process of selecting workshop topics is largely dependent on the theme of the hackathon. In our case, since we knew we would be working collaboratively with a large textual dataset housed in a CONTENTdm repository, we opted for workshops on working with digital text, the basics of the CONTENTdm API, and working collaboratively in GitHub. Initially, we had intended for each of our six mentors to lead a 30-60 minute workshop, but with such a short period of time (24 hours) and a relatively small set of participants, six workshops seemed like overkill and perhaps a bit distracting. We suspected that the students would just want to get started on their projects, and that suspicion was confirmed during the event. After our third and final workshop, the students were eager to get coding, and at that point our mentors transitioned from lecturers to coaches in smaller focused sessions.

Incentives and Prizes
Hackathons, at least the type of hackathons that aim to encourage creativity and learning, do not need expensive prizes or incentives to recruit students to participate or reward them for their efforts. The students who attended HackOH5 were not expecting prizes, never asked about prizes, and frankly, they seemed surprised and delighted when we offered them a small portable battery pack as a gift when they signed in at the registration desk. They came because they were interested in the challenge and because the event somehow resonated with them. It helped that perhaps we were asking them to mine a collection of student writing authored by students that had come before them in the 160 years leading up to this event. It’s possible that this made the challenge and the event more relevant to their own lives as students in the Ohio Five.

That said, we did discover that if the prizes or incentives we offered exceeded $100 in value that our accounting office would be required to report that value as income and therefore required us to obtain signed W-9 forms from the students. This requirement led to some awkward moments for the winners of the hackathon in which we asked them to sign the paperwork before receiving their awards. We awarded Bose headphones to the first place team members and a FitBit Charge to the the team members in second place.

There’s also the question of whether a hackathon designed to be optimized for learning should be competitive at all. Ours was, but in retrospect, we wondered whether or not the competitive nature of the event may have been at odds with our goals of stimulating creativity, learning, and collaboration. Teams may have been less likely to walk around and explore what others were working on, the stress of getting something completed in time to submit to the judges may have stifled creativity, and perhaps most importantly, competition by definition is exclusionary and adversarial, and this could have been working against our efforts to cultivate an inclusive and welcoming event. Any alternative approach would have to include a different means of providing feedback or assessing the students’ work and the outcomes of the event.

Two-Week Plan
As the event approached, the stress levels were rising, but because of all of the planning we had done beforehand, things started to fall into place. For the days leading up to the hackathon, we developed a short list of activities that needed to happen.

Two Weeks Out:

• Placed the catering order with Wooster’s food services office. We planned to offer coffee & cookies the first night, a breakfast in the morning, a lunch, another coffee & snack break in the afternoon, and then a dinner to be served before the judges announced their decisions on the final projects. We also supplemented these meals with other snacks, fruit, and beverages throughout the event.
• Sent an email to all registered participants (students and mentors) that included a reminder about the event and logistical information such as:
  • When and where the hackathon was happening
  • Directions to the library
  • Information on how to access the data ahead of time and begin experimenting with it
  • A list of suggested personal items to bring, such as laptops, chargers, pillows, sleeping bags, necessary toiletries, etc.
  • Pointers on where to sleep in the building for those spending the night, including floor maps of the building
  • Information about who and what would be there and what to expect when they arrived
  • Contact information for any questions
  • Confirmed transportation needs with students and reserved a shuttle for those needing a ride to the event
• Ordered conference badge holders

One Week Out:

• Confirmed catering order
• Confirmed shuttle/transportation
• Confirmed that our equipment needs (projectors, white boards, extension cords, power strips, etc.) were covered
• Confirmed wifi access for all participants if guest wifi credentails were created
• Emailed all students again with a second reminder
• Created copies of all data on six physical hard drives to distribute at the event
• Designed and printed name tags for each student and mentor to place inside badge holders
• Designed and printed signs to post on the rooms we had reserved for the event. These were public spaces so we wanted to avoid students not participating in the hackathon from wandering in unawares.
• Setup a Slack channel to use for communication with participants during the event

Day of Logistics:

• Sent a final reminder to all students repeating details about the location, time, parking, and what to expect when they arrive.
• Purchased the snacks and beverages that supplemented the larger meals.
• Setup a sign-in table in a visible area near the entrance, and one member of our planning group manned that table as the students arrived.
• Kicked off the event with some introductory remarks from the organizers, logistical information such as restroom locations and how to join the Slack channel, and then we went around the room and introduced ourselves one by one.
• Kept everyone informed of planned activities through the Slack channel as they happened. This included workshop start times, food arrivals, and reminders about locations to sleep in the library.

Post-Hackathon Follow Up:

• Sent a message to all participants following the event, thanking them again for their contributions and asking them to submit a brief feedback form to gather input on their experiences with the event.
• Wrote up a summary of the event to share with colleagues in the libraries, and posted it on the website. In our case, this summary manifested in video form and was posted to the hackathon website. It took some time to put this together so it was not shared until two months after the hackathon. Ideally, a short summary should be shared within soon after the event to help tell the story of the event to colleagues and administrators who, by this time, are likely eager to hear about the outcome.

The Hackathon in Hindsight

[TBD]

---

Planning Documents Cited:
Hackathon Statement of Purpose
HackOH5 2017 Budget
HackOH5 Resources Guide
HackOH5 Memorandum of Understanding for Mentors
HackOH5 Evaluation Criteria for Judges
HackOH5 Print Flyer
Email Template for Librarians to Promote the Event
Email Template for Seeking Participants from the CS and IT Departments
Post-Hackathon Feedback Form

Further Reading:
#HackFSM: Bootstrapping a Library Hackathon in Eight Short Weeks
So You Think You Want to Run a Hackathon? Think Again: A Case Study on Smart Event Organizing for #civictech
Hack the Library: Organizing Adelphia University Library’s First Hackathon
Alameda County Apps Challenge 2012: Hackathon #1 Getting Started, Lessons Learned and Everything in Between
How to Run a Successful Hackathon
Health Hackathon Handbook