EUvsVirus Hackathon Lessons Learned
Random Observation/Comment #661: Remote friendly quarantine hackathons are so hot right now.
Remote Pan-European Hackathon #EUvsVirus
I didn’t think a remote hackathon would be as fun or nearly as productive, but it was actually pretty great. You miss some of the event in-person awkward friend-making moments and whiteboards, but you can make the most out of some productivity tools and hack in sweatpants. I’m definitely interested in doing a few more.
How did it Work?
Slack was the main form of communication and socialization for the event. Yep, that’s 23,581 passionate devs/hackathoners with 400+ organizers. (at)channels were used for #0-announcements providing clear agendas and specific guest webinar links and times. Overall, messages were received with much love (Reached reaction limits on slack).
There were so many slack channels that there needed a #0-channel-directory for the specific categories. You can join channels about information channels, mentors, domains (e.g. health, business continuity, social political cohesion, remote working education, digital finance, other), specific topics within those domains, and regions.
Slack channels can definitely be a distraction, but also note that this is replacing the coffee breaks and event booths. It was an open way to reach out to anyone and ask questions seen by everyone else interested on the same topic — a choose your own rabbit hole and immediately connect to be live added to projects and share your expertise.
To replace the roaming SMEs, people volunteered to be official and unofficial mentors. A mentor was assigned to our team and they joined our calls to make sure we were making good progress.
DevPost was used by the organizers to manage submissions. 22,000 people with standard 5–10 people team sizes means a lot of submissions. I think this is why they clearly indicated 2-min pitch videos.
Our Team’s Tools
Zoom was used within our team to have live syncs. Since we weren’t locked in a room together, we needed to add a bit more structure to our efforts. We spent around 5 hours over the course of the 2 days doing live working sessions.
Miro was the perfect whiteboard replacement and live collaboration tool. We started our brainstorming sessions this way and could have also just kept it as a live kanban board of tasks (moving our stickies from “to do” to “doing” to “done” columns). Ultimately, we spent the most time doing collaborative voting and building of our final deck narrative.
Google Slides was a life saver for live simultaneous edits and research collection. If you know me, you know I make slides for everything.
Userbitapp was great for the Discovery and Research phases when the product was being refined and taking shape around derived insights across multiple sources. I used it for early research collection, idea tagging, insights, personas, journey map, and sitemap building.
Techsmith’s Camtasia Studio is my go-to screen recording and video editing tool. Most of my Confluence pages at work have GIFs showing product features that I’ve created with this tool.
Lessons Learned
- Schedule beginning-of-day and end-of-day calls — Remote weekend hacking means people will also be dealing with home distractions. We touched based on tasks in 5–6 hour work intervals.
- Ask to see who has Corporate Access to Collaboration Tools — We used Zoom, Miro, and Slides for collaboration. We used open source tools where possible. I had a userbitapp and camtasia license. Other team members had promo creator, survey creator, and mock-up tools.
- Don’t forget the Intros and Zoom Chitchat— Spend time learning about each other’s skills, but also get to know each other. Join your scheduled calls early and do a show and tell.
- Ask for Help on Slack — Mentors were assigned, but people were generally super helpful within the domains/topics. This was also the best way for us to grow our hackathon team to these random encounters.
- Network on Slack — Self-introduction channels were friendly, but following the tech messages also shared different available tools and protocols that might apply to your use case.
- Talk to other Teams —Search for similar projects and consider joining efforts (or at least understanding different distinguishing factors)
- Read through the criteria and submission requirements early — Hackathons are structured for Discovery and Product pitch formation. Working backwards from the deliverables helped us with time management and roles/responsibilities
- Consider using Surveys — Writing a simple 5–10 question survey may provide you with a user-specific data point. This was definitely easier to do remotely and with slack.
- Emphasis on Clear Product Value Proposition and Narrative — With a large number of submissions, I imagine the mentors will have stages of filtering criteria before providing deeper review.
- Show your Work — Provide links to additional information and next steps. Consider writing a reflection (like this one!)
Hackathon Template Approach
Pre-Work
- Understand the Domains & Topics
- Have a Use Case in Mind → Mission Statement / Vision
Day 1
- Explore Slack channels to build team and merge ideas
- Agree on Tools — Account setups for source control (github) and collaboration
- Map your Ecosystem — What/Who are the existing solutions? What are their value propositions?
- Document Requirements and Insights — Keep track of insights that might become functional and non-functional requirements
- Deep Dive into a few specific Solutions — What did you like? Would these be competitors? Partners?
- Setup interview meetings with those teams (if possible) — What can you learn from these solutions?
- Leverage Existing APIs and Tools — Open Source Software preferred for solving the problem
- Product Narrative — Where does your product fit in the bigger picture?
- Scope the Build — Work backwards from the demo. Are you showing mock-ups? Integration flows? Consider the happy path user journey.
Day 2
- Revisit Submission Checklist — This should be a Day 1 activity, but it rarely happens that early with so much energy and ambition. By Day 2 you breakdown into reality and scramble to make a presentable strategy and pitch deck with scaled back demos.
- Consider Conducting a user survey — This worked out pretty well and we were able to get some insight from other participants.
- Target State Architecture— Consider all system interactions upstream and downstream to your solution.
- Learn and Build — Whichever your technical deliverable, remember to write some code and read some documentation.
- Refining Presentations and Deliverables — Narrowing down slides into Executive Summary deck, Promo video, Prototype mock-ups
- Next Steps — Recommendations and planning for a follow-through
- Submission / Hand-off — Organize README files and push code. Update links to final versions of your work.
Follow-Up
- Stay in touch with your teammates — Add them on LinkedIn and set up a reminder to ping them in a few months
- Make an Effort to Continue the Project or Open Source it — If it’s a good idea and has potential, then keep building on it. If there’s no business demand or resources, then share it.
- Write a reflection blogpost (like this one!)
What was our Project?
https://www.youtube.com/watch?v=BCQTaF-4SII
Scoping Exercise
Our team wanted to build a tool that would help the world reopen back to a relatively new normal. We chose contact tracing out of these categories indicated from the Harvard “Roadmap to Pandemic Resilience” Paper because it’s the topic we felt our passions, vision, and tech (Ethereum) was most aligned.
Within Contact tracing, almost everyone writes a new mobile app and pitches the new mobile frontend that connects to an existing detection methodology. This was originally our intention, which is why we had created some recommendations on the features and user flows. For this to overlap with our mission of creating privacy-preserving techniques, we decided to use the recommendations as upstream requirements for the usage of our GoTrace APIs.
Across the functional stages of the contact tracing life cycle, we indicated existing solutions and focused on our functional requirement choices.
More specifically, our non-functional requirements across privacy, identification, storage, protocol connectivity, and performance narrowed down the possible solutions.
Our approach honed in on creating additional feature suggestions for an existing live contact tracing app called Coalition (built on Nodle which uses a the whisper protocol).
Our recommendations aim to leverage open source wallet interfaces to reduce the usage of phone number and email addresses for notifications on infection exposure. We also wanted to eventually leverage the verified credentials models for antibodies certificates and incentive models.
There’s potential to contribute to the existing Coalition code or use these sets of principles as recommendations for state/government contact tracing apps to preserve democratic values of personal privacy.
GoTrace links:
- DevPost: https://devpost.com/software/gotrace
- Gitcoin: https://gitcoin.co/grants/736/gotrace
- Github: https://github.com/mara-schmiedt/GoTrace
GoTrace Team Contributors:
Mara Schmiedt, UK ConsenSys
Clemens Wan, US ConsenSys
Collin Myers, US ConsenSys
Andrej Ktitarev, Germany, Deep Work
Frank Bartnitzek, Germany
Volker Küchenhoff, Germany
~See Lemons Love Hackathons
