Hacking the APS Convention

It was an unusual sight for a Sunday morning session at the 2019 APS Annual Convention: The stage was empty, and all of the action was on the floor. Attendees had gathered in four groups, sitting around tables with laptops. Each group proceeded to spend the session talking, typing, and accumulating resources with the goal of facilitating best research practices. This was the scene of the first-ever APS hackathon — hopefully the first of many to come.

Hackathons started in the tech industry and have been adopted by the open-science movement, as well — they’re a key feature of the programming at the annual conference of the Society for the Improvement of Psychological Science (SIPS). Hackathons are “sprint-like events in which interested researchers from all career stages collaborate intensively on projects” (en.wikipedia.org/wiki/Hackathon). The main goal of these sessions is working together toward actionable outcomes that can be shared openly. There is an emphasis on horizontal, rather than hierarchical, knowledge transfer, and also on removing barriers to interactions. Hackathons are a fantastic addition to traditional conference sessions because they provide opportunities for direct collaboration and creativity.

Here we describe how we structured the event, the challenges we faced, what we accomplished, and what we learned to make the next one even better.

The APS Annual Convention is a large conference spanning several areas of psychological science. It is attended by undergraduates, full professors, and everyone in between. In addition to the different levels and types of expertise APS attendees bring to the table, they also have a range of experience with hackathons. The goal, therefore, was to provide an egalitarian and inclusive collaborative working space for attendees of all backgrounds, a space where younger attendees would not be intimidated by more senior researchers and those inexperienced with hackathons would feel empowered to make their voices heard.

Our first steps toward inclusion started months before the conference. During several virtual meetings, we carefully considered what topics and projects to work on. We decided to focus on topics that were more effort-based than expertise-based. In other words, the projects would primarily require effort and be accessible to anyone regardless of their knowledge and expertise. At the beginning of the session, we provided background information about how hackathons work and outlined the goals of the session. Finally, we promoted a code of conduct that reinforced norms of inclusivity, and we encouraged attendees of all backgrounds to participate and treat each other with respect.

Additional challenges arose as we were deciding how to structure the session: How could we work efficiently within the time constraints? How could we plan ahead without being authoritarian? Would we have 5 participants or 50? How would we handle the flow of people in and out of the session?

Hackathons usually include time to brainstorm and formulate a project idea to work on. We didn’t have the time for that. To address the time constraints, we built scaffolding into the session. The co-chairs prepared one or two topics that they could facilitate. Our roles during the session were to provide direction and keep our groups working toward creating some output in the given time. Because we didn’t want to dictate to the attendees what they would be working on, we planned to conduct an interest poll to democratically decide which of the prepared topics to work on during the session. The interest poll also addressed our concern about attendance. The number of attendees and their interests determined how many groups we would form.

We knew that there would be some latecomers and some people who would leave the hackathon early. There were other symposia and poster sessions scheduled at the same time as the hackathon, and it was also the last day of the conference. We built in breaks every hour for progress updates, grabbing coffee, and giving people a chance to filter into and out of the session. Whenever new people arrived, a co-chair who was not facilitating a group oriented them to the session.

On the day of the hackathon, the co-chairs introduced their topics, the attendees voted on the topics they were most interested in, and we formed four groups. In true hackathon form, the topics evolved and adapted to the interests of the participants; some groups split up, others merged. By the end of the hackathon, each of the four groups had generated a product. These products are published on OSF at osf.io/c8xbp.

Given the time constraints, some work is bound to be unfinished. One of the groups set a solid foundation for their project and then developed an action plan to complete it after the conference. They handled the remaining work by selecting a point person to keep the project on track and being open about how much time they were willing and able to commit to finishing it.

Three of the products are ready to use, and address different stages of the research process:

1. Are you using preregistration and OSF to manage your projects? Consider using project lifecycle tags, which track the current status of a project: io/ej8k4/.
2. Did you preregister a project, and the project didn’t quite go as planned? This document might help you navigate the process of providing a transparent report of deviations from the preregistration when you are ready to publish your work: io/wvp46.
3. Are you reviewing a paper and want to apply an open science perspective? Here are some resources and a checklist: io/c56jx.

A bonus product from the hackathon is the feedback we collected from the session. We created a feedback survey and received lots of helpful and constructive comments from attendees. Generally, the hackathon was positively received — one person called it the “highlight of [their] conference” — but there is a lot of room for growth and improvement.

A few tips for future organizers: Implementing a loose registration would give organizers some idea of attendance numbers ahead of time, without closing the event to people who didn’t register in advance. Preparticipation, such as doing an online interest poll, could help garner excitement about the topics, and keep attendees informed and engaged leading up to the event. Finally, make sure coffee, tea, and plenty of electrical outlets are in the room to keep attendees and their computers fueled and ready to work.

After the hackathon, a group of us left the convention center to get lunch together. Conversation was lively, despite most of the group having just met for the first time a few hours prior. Hackathons build connections. That’s what is so unique about them, and why they are excellent complements to traditional sessions. Networking at conferences is often a function of who you already know and can reflect and reinforce the hierarchical nature of academia. Hackathons create opportunities for organic networking by turning strangers into coworkers. People who may not have otherwise met are able to engage with each other over shared interests, and when they return home from the conference, they are more connected than they were before.

This first hackathon was a proof of concept, of sorts. We weren’t the only ones to try integrating hackathons with traditional conferences this summer; in June, the Association for Research in Personality incorporated three hackathon sessions with their regular programing. Hackathons are full of potential, and their applications are really only limited by the creativity of the people organizing them and participating. Scholars from all over the world come together to meet in convention centers each year, bringing with them their expertise and enthusiasm. Why not also come together and make something?

Given the feedback, the productivity of the session, and the connections formed, we felt that APS’s first hackathon was a success. We hope these collaborative events continue to gain traction at APS and beyond.