[](https://hackmd.io/dUYWLDDISnOwjEVAwdZKJg)

[](https://creativecommons.org/licenses/by/4.0/)   This content is licensed CC BY.

# Meetings That Matter

**Organizing unsessions, idea jams and hackathons for scientists**

## Contents

[TOC]

## Introduction

This is a short but opinionated guide to organizing scientific meetings that matter. If you're fed up with sleepy symposiums, weary workshops, or the feeling of despair at having to give — or, worse, listen to! — a talk at 4:30 on the last afternoon of the conference, we're here to help.

To be clear, if you're here:

- to organize a meeting "like the last one but with more varieties of tea, a lot of people complained about that", or
- to generate revenue from the event as your primary objective, or
- because you work for an organization that organizes meetings for scientists but you yourself would never go to such a meeting...

...you should probably read a different book.

If you're a scientist that wants to change the world, or at least how your corner of your discipline gets science done, this book is for you.

## How this book is organized

There are two parts: Part 1 gives the big picture. Part 2 is about the details _around_ the event; the meta. Part 3 is a detail-filled run-down of the various kinds of event you can organize.

---

# PART 1: The big picture

## Rules

You are not allowed to break these rules. (That's the thing with rules!)

1. No keynotes.
1. No PowerPoint.
1. No panel discussions.
1. No 'pass-the-mic' group discussions.
1. No 'words from our sponsor' or paid slots.

## Principles

There are a few principles at work here. If you don't agree with all of them, no worries — adapt the advice to your own principles. If you don't agree with any of them, you're probably not going to like any of the advice that stems from them.

- There are no experts, there is only expertise. The difference is that expertise can live in unexpected places.
- Meetings with no tangible outcomes might as well not have happened. The last thing the world needs is another so-called workshop.
- People do their best work outside their comfort zone, drinking awesome tea/coffee in awesome surroundings.
- Professional relationships depend on trust, which you can only build by facilitating co-work on problems of mutual fascination. Other type of 'networking' are more properly called 'socializing' — necessary but insufficient.
- Cliques, clubs and celebrities are not conducive to good science.
- Hands and voices are worth 10 times, maybe 20 times, ears and eyeballs.

## What does it mean 'to matter'?

- **There is at least one tangible product** that you can point to at the end and say, "We did that." What sort of thing? Some software. The outline of a paper. A poster. A video. Some new wiki pages. A list of 'unsolved problems'.
- **It is open and 'in the now'.** Whatever it is — make sure others can see it and make use of it, ideally the day after the event. Ideally, it's interesting and/or useful and people who weren't there think so too. Don't hide it from them.
- **People voluntarily talk about or write about the event,** and share its contents. They are proud to have been there. They wear the T-shirt. They want to return, and bring a friend. They are inspired to organize events of their own.

---

# PART 2: The meta

## Who is coming?

- Try to avoid creating a private club, or the impression of one. Instead, aim for open and diverse participation.
- Do not worry about being inundated. (You soon may wish you had this problem.)
- Invite the people you want to be there. Forget about who 'should' be there.
- Beware of creating an echo chamber. If you can, invite a few people who probably shouldn't be there.
- Ask people to share the event with colleagues or on social media if you want to cast the net wider without inviting everyone yourself. Make sharing easy.
- Don't worry about who comes. One of the core ideas of Open Space Technology meetings is: "The people that come are the right people."
- Make an effort to talk about the people that come as 'participants' (active), not 'attendees' (passive). Impress on them the right and responsibility to create positive outcomes.

## Inviting people

Very rough rule of thumb: I usually get about a 50% response rate to emails, and about 80% of the respondents are positive. About 50% of positivists actually show up.

## Charging people

If the event is free, about 50% to 80% of the people who sign up don't come. If you charge a small amount, you'll still have about 10% to 25% no shows. Charge more, and everyone will come... but you will have to handle cancellations, etc.

Some things I've found:

- If you charge more than a few bucks/quid, people will ask for discounts.
- If there are discounts, some people will try to claim them even if they are not entitled to.
- The more you charge, the more entitle people feel (and are?) to complain.

## Where is it?

[I would rewrite this segment to focus around fully and partially virtual (distributed) events.]

Your remarkable event should happen somewhere remarkable. Remarkable places include: coworking spaces, awesome hotels, meeting rooms in pubs or restaurants, meeting rooms at museums or galleries, castles, a rented Airbnb house. People should walk in and spontaneously grin.

Non-remarkable places include: your university or company's conference facility, any chain hotel of any kind, anywhere with grey or beige office furniture and/or white ceiling tiles and/or fluorescent lighting. You know.

Ideally you want to be able to configure the space in different ways. Having access to multiple rooms is convenient, and may be essential, depending on what you want to try to do.

Avoid spaces with theatre-style seating at all costs; it's very hard to do anything remotely interactive with them. Go for cabaret-style instead: separate tables with 4 to 8 chairs per table (4–5 is the goal for most activities).

Things to think about: relatively easy to get to (tell people how!), Wi-Fi obviously, whiteboards or lots of very large paper + pens, easy access to basic facilities like tea/coffee, toilets and so on. Proximity to catering options can be helpful (e.g. when running around looking for taco joints to feed 20 hungry scientists).

## Any other logistics?

I have not yet figured out how to get sponsorships at the level I'd like. It's hard work — expect to send quite a few emails and get a lot of 'no's. Understandably, at least above a level of about $1000, people want to know what they are getting for their money.

If you can offer financial or other support to people who may not otherwise be able to come, do it. E.g. help people share an Airbnb, or offer small travel bursaries; some people might even be prepared to add a little to their bill to support someone else. A little can go a long way, and you'll make a friend for life.

## Registration

Eventbrite is a great platform for signups. It's free for free events. You can see who's coming, send and schedule group emails, etc. It even sends them a reminder 48 hours before. There are a huge number of options for selling tickets (different levels, early bird, late tickets, etc). And you can make a pretty URL for your event.

## The schedule

I'm sorry about this but your conference app sucks. I don't think I've seen any that are any better than Sched https://sched.org/.

It's a good idea to post a physical schedule in various locations around a venue, or in various channels for online events. Make it super-easy for people to find things they want to be part of.

## Code of conduct

We all want welcoming, respectful, friendly spaces, but responsible communities need safe ways to report misbehaviour. Even small public events should consider adopting a Code of Conduct; for large ones it's a must. There are open-access codes of conduct that you can adopt. For example, the Software Underground CoC that Agile uses came from the Contributor Covenant. You can read it at https://swu.ng/conduct. Another example is the Conference Code of Conduct.

Having a code of conduct means:

- Telling people to read it ahead of the event.
- Summarizing it (the core message) and pointing to it at the event.
- Having at least two (unrelated) contacts at the event.
- Enforcing the Code by dealing with issues when they come up (or, better yet, before).

## Swag and gifts

If you are giving swag or 'thank you' rewards, do not, under any circumstances, order naff corporate gifts from a naff catalog. Engraved paperweights, rubbish pens that break, nasty mugs, embroidered fleece from a sweatshop — just stop it. No-one ever said, "These conference bags are awesome! I needed another one too. And look at all these lovely logos."

And do not, ever, give people USB drives. They are horribly insecure and a pest. (You know about the Internet, right? You can, like, put files there.)

That doesn't mean you can't give people a pen. Of course you can. But take the trouble to find a Japanese 0.4 mm fibre-tip with archive-quality ink, and tell people why you bothered. (For example, maybe it's because you give a damn about their work.)

Once you get used to the idea that people don't actually want another inflatable globe with your logo slapped on it (unless it's a globe of the geological map of Venus, in which case please proceed), I promise that you will get excited coming up with thoughtful and cool stuff will thrill people — an awesome book, pieces of meteorite, a Raspberry Pi Zero, or a nicely designed and unique memento.

Some things I've given away:

- 52 Things books. If you're organizing a conference in geoscience and would like to give some away, get in touch: [e-mail] — I'd love to help.
- Scout Books notebooks http://scoutbooks.com/ (from $200 for 50). Tip: pay a designer for a custom design.
- Sticker Mule https://www.stickermule.com/ (from about $50 for 50). Tip: pay a designer!
- T-shirts (sourced locally; usually about $20 each). Tip: pay a designer!

More ideas: https://twitter.com/Helena_LB/status/1005068063459430401

---

# PART 3: What actually goes on?

There's so much possibility, it's hard to narrow it down. Start by forgetting about the following: talks in dark rooms, panel discussions, fireside chats (gag), poster sessions. Wait... am I describing every scientific conference...?

No! There are good things going on in the world of geoscience already: core conferences, debates, hackathons and wikithons, field trips (but those can be bad too). Do more of those.

There's lots going on in other domains too: skill shares, lightning talks or PechaKucha, office hours, birds-of-a-feather, unconference or Open Space Technology, knowledge cafés, and so on. Read about these things, or go to conferences where they happen (many of them are happening at tech conferences). We need more of these things.

- Talks (but not the kind you're used to)
- Lightning talks
- Unsessions
- Birds-of-a-feather and meet-ups
- Tutorials
- Office hours
- Hackthons
- Sprints
- Games

You might be wondering why 'Panels' or 'Discussions' aren't on this list. I've certainly seen plenty of these at conferences. But they aren't on this list because in my opinion they usually do not work.

## Why don't panels work?

I'm going to ignore 'Discussions' (e.g. where people pass a mic around to have their say, then spend the rest of the time trying to get the mic back but not getting it and so forgetting what they wanted to say but it doesn't matter because nothing's being captured anyway) because my advice is simple: don't do them.

The main reason panels don't work is that the facilitation is really hard. Unless you have a charismatic professional broadcaster on your team, your panel is going to be boring and frsutrating to listen to.

Panels are also absolutely perfect for perpetuating selection bias, as the ever-present 'manel' shows. They are another example of the kind of celebrity culture we want our events to get away from.

A rule of thumb: if your event involves a small number of people sitting on a stage in better chairs than the audience, then you need to rethink.

## Hosting talks

Talks are such a well-established component of scientific communication that it's tempting to think they are essential. But think about some of their downsides:

- It's a lot of preparation for 20 minutes of content.
- A lot of people hate giving talks.
- Talks are especially hard for people speaking a second language.
- It's mostly just a bunch of bad PowerPoint.
- If you don't record them... did they really happen?
- There's often no time for questions, let alone discussion.
- Sorry, but they are often really boring. Ask the people at the back checking email and looking at their schedules.

How can we make talks awesome again? I think a good presentation has several, maybe most or all, of the following components:

- More than one person speaking.
- A lack of slides with bullet points on them.
- Drawing on a whiteboard.
- Audience interaction (e.g. via Mentimeter).
- Live demonstration (e.g. software, website, GIS session, or even a physical experiment on video).
- Live coding.
- Interaction with a wider audience (e.g. via Slack).
- A physical or digital take-away (e.g. a cheatsheet, invitation, etc.).
- No overt or abject marketing.

If you must have talks, bite the bullet and let people plug in their own laptops — at least in some sessions. Yes, in a physical meeting this can be a hassle — allow for it. For example, you could let the speaker share their screen with a host laptop via a Zoom session.

Along with marketing, consider banning PowerPoint; it's really the only way to get some people out of their day-to-day. (If you think all good things can be squeezed into PowerPoint, you need to get out more.)

If you give talk slots to sponsors, expect them to be terrible. (They are always terrible.) My advice is never to do this. People's attention is precious; if your sponsors take the time to make people care about their offerings (by engaging with people and being awesome and generous and useful) then people will find them easily enough.

No matter what you're up to, you do not need 13 parallel sessions of talks with 1.5 km between the most distant events (if you think I'm joking, you haven't been to the George R Brown Convention Centre in Houston, Texas).

## Lightning talks

How we managed the sessions at Transform 2020.

## Facilitating an unsession

First things first: if you're facilitating, you're not participating. Sorry about that, but it's impossible.

Now, the good news about facilitating unsessions is that you don't have to bully people into sending their abstracts, and then feel obliged to actually read the dreadful things.

Give people permission to do awesome things and think audacious thoughts. Usually this only requires one sentence: "You can do awesome things and think audacious thoughts here." I'm serious: you just have to tell professionals this, and they will jump in and get on with it.

Get people into conversations that matter by provoking them with lofty and/or profound questions. Arrange them (in the room, or in Zoom's breakout rooms, for example) in groups of no more than 6. Have them report back occasionally and very briefly.

Be on guard against the time-suck of you-know-who professor types lecturing the room with their wisdom — let them contribute the way everyone else does: in conversation with their peers.

Remind people what they already know: good conversation involves everyone, hears every view, and keeps moving along. It doesn't dwell, people don't lecture, others don't clam up. The group can usually do this on their own — but you can help:

- Plant people at each table who gently nudge the conversation along.
- Visit the tables during conversation time and help them keep it moving.
- Announce to the room when they should move the conversation, say every 5 minutes or so.

You can do whatever you want. Play games. Mix people up. Mix topics up. Introduce weird constraints ("Solve this problem with $100. You folks solve it with $1 billion. Solve it like Google. Now solve it like Microsoft."). Push people outside their comfort zone sometimes (but not all the time).

Document everything. Ideally pay a graphic recorder or graphic facilitator (what's this?). They will blow you away with their presence.

Pay a photographer: you will not have time to take photos. Encourage participants to take photos too, and post them on social media. Show the world what you're up to. If you can make a professional quality movie, do it — these cost money, but are well worth it in my view — a couple of hours of footage and no more than a 3 minute product.

Feed and water people well and regularly. Bad coffee is not allowed. Tea that tastes like bad coffee is even more not allowed (in the US, this corrosive coffee-tea is usually served lukewarm and with — gag — cream).

Delight people with your choices of snack or meals. Give them something to talk about, something to remember.

### Tasks for the table hosts

- Keep the conversation going
- Help ensure everyone at the table is heard
- Make sure the ideas are captured on stickies
- Report back to the group a few times, or make sure someone is happy to do this
- Help people interpret the ranking process
- Fill out the ‘sketchpad’ for capturing approaches to solutions

### Vibe

We find it helpful to transmit a few conceptual points, either ahead of time or at the start of the event, to help frame everything. Several of these are borrowed, or just outright stolen, from other sources. Repeat them often to whoever seems to need to hear it (e.g., hosting conference organizers, who are probably terrified, or at least skeptical, of whatever you are trying to do).

For example:

- This is an experiment.
- Failure is an option, it’s just the least desirable one.
- Conversely, perfection is the least likely.
- Conferences are too one-way, too passive. We want more action.
- We want open, honest conversations about our industry, and our technical challenges.
- Bring your most courageous, opinionated, candid self.
- The stuff you’re scared to mention, or you’d only talk about over a beer? Bring that.
- The minute you think you’re right, you’ve checked out of the conversation.
- Listen with an open, generous mind.
- Whoever shows up are the right people. (This is one of the tenets of Open Space Technology.)
- What happens is the only thing that could have happened. (This is another.)
- There is no finish line.
- What we are doing is not required (or intended) to be definitive.
- The design is ambitious.
- It will move fast.

## Birds-of-a-feather and meet-ups

BOFs and Meet-ups, e.g. at SciPy.

## Tutorials

Tutorials at Tranform.

## Office hours

How this worked at STRATA.

## Hackathons and sprints

See PART 4: Hackathons.

## Games

E.g. SEG.

---

# PART 4: Hackathons

So you've decided to organize a hackathon. Good idea! Hackathons are a fantastic way for organizations to explore new territory without a lot of cost, time, or risk. Some of the outcomes of hackathons we've experienced include:

- By collaborating around real problems, the participants build real connections with their peers, based on mutual trust and respect.
- Deeper digital skills and intuition, resulting from having to think quickly and creatively about how to apply technology to real-world business problems.
- Very rapid prototyping. At the end of two days, you have 10 new prototypes; in time, most will be discarded, but some will be remarkable.
- An immediate and profound raising of digital aspirations for everyone, from the organizers and participants to the organization at large. Public displays of awesomeness push everyone to reach a little further.

## Principles

We propose adopting a set of principles, to help guide planning the event. Without underlying principles, it can be hard to discriminate between helpful and unhelpful patterns.

These are the principles that guide our own events:

- Allow people to choose to experience these patterns — or not. Let the early adopters come early. Let skeptics take their time to be convinced, and listen to their questions. If your event is part of a digital transformation effort, this light touch approach is more effective, and more fun, than a 'roll out'.
- Let people bring the problems. In general, smart, engaged professionals know what the big problems are. They can't wait to work on them, if they only had permission, time, and resources. Don't try to control this stage, it will put people off.
- Show don't tell. Find ways for early adopters to show what they've experienced to the rest of the community or organization. For example, hold a demo party at the end of a hackathon, or make one of the deliverables of an unsession a brief article for the company magazine.
- Attack large problems with constraints. Big problems are hard to solve, so don't look for solutions. Instead ask: what can I do now for free? Then, what if I had a week? A month? What if I had a team? Do one thing at a time.
- Be as bold and audacious as you dare. Surprise people. People like to be surprised. They also do better work when they're outside their comfort zone. Rule of thumb: if you're not nervous about the outcomes, you're not reaching far enough.
- As you iterate over your digital transformation experiments, other principles will become necessary to adopt, and some of those you started with may become less useful. Adapt!

## The big picture

Over the six years we've been organizing hackathons, we've established the following:

- Give yourself at least 6 weeks to organize a small event (up to 20 people), three to four months for a large one (60+ people).
- Ideally, have a team of about two to three people to organize.
- The main costs are the venue, prizes, catering, photo/video, and swag.
- Line up some known and respected judges, whose opinions the participants will care about.
- Get momentum early, even before details are known (e.g. the exact venue location can be confirmed 2 weeks before the event, as long as it doesn't move too far).
- Making it a contest encourages people to converge on solutions they can demo (as opposed to a big collaboration, which might not converge at all)...
- ... but don't make the contest the main point. Keep the prizes small and the atmosphere fun and informal. Avoid cash prizes, and don't rank the prizes.
- If you’re the organizer, you’re not a participant.
- You need a way to form teams and find projects ahead of the event. We use Slack, and it works but it takes some time and energy to nudge people along.

There are several phases to the event:

**Define the parameters.** It might be worth defining some boundaries early on — because you should try to hit those boundaries, not stay away from them. For example, are you prepared to invite people from outside your business unit? What about your business partners and service providers? Your competitors, university students, members of the public? Figure out how bold you dare to be, then be a bit bolder. Aim to raise eyebrows.

**Define a theme.** Hackathons do not have to involve coding, but many do. Perhaps it's up to each team whether they are hacking software, or hardware, or documentation, or scientific manuscripts or illustrations. Or maybe you specify in advance that the products should be apps, or documents, or physical widgets.

Hackathons often involve teams working on their own projects, but there's no reason why everyone cannot hack on the same project, if it's suitably modular. Chapters of a book, modules of a software library, components of a complex system or workflow — lots of projects lend themselves to asynchronous collaboration.

**Do you need to develop skills?** If the focus is on technology, a 1- or 2-day short course can help get everyone's skills up to speed. Beginners will need help getting their environment running, and learning about version control and team coding. And even experienced programmers may never have built a mobile or web application.

**Project discovery.** Unless you have very specific technical goals (in which case this might be a 'sprint', not a hackathon), you will need a process for discovering projects. Professionals care about their work and they know what the salient problems are — so crowdsourcing projects tends to work well. There are ways to sift and prioritize large numbers of ideas (lack of ideas will not be a problem). This process needs 4 to 8 hours.

**Two days of hacking.** The hackathon itself should be at least two days. Less is not really an option. We've never done three days, but it could work. In our public 2-day events, things tend not to get going before the middle of the first day, as people sort out teams — so people lose some time early on. With a project discovery day and/or bootcamp, we can avoid this lost time. We also cram the demos into the end of day 2 — a demo day will avoid this too.

**Demo day.** This is a really exciting part of the event for everyone, especially for the people who have built the world's buggiest software. So invite lots of people, make an event out of it, and allow time for the participants' passion to come through. Although the demos tend to be short, they take time — for 4-minute demos, allow at least 10 minutes per team.

**Judging and prizes.** There is some debate about the wisdom of competitive hacking. There is evidence that it can be a turn-off to some would-be participants, especially women. So we try to keep it very low-key — informal, low-key judging, no large prizes, prizes for everyone. We tend towards recognition and respect for everyone rather than just naming a few winners. The judges, by the way, are always blown away.

**Review.** If time allows, a review at the end of the event is a good way to wrap it up. Perhaps the teams even write their own summaries and 'what next' pieces. If you can gather some lessons learned now, you will be thankful later. Commit to the next event so people can start getting excited about it.

## Format

There are other types of mass collaboration event. For example:

**Sprint:** a coding session focused on improving an existing tool or library, rather than on creating lots of new things. Great for open source project.

**Content-a-thon:** for example, a wikithon, in which lots of wiki authors spend time together creating or improving content in a corporate wiki or knowledge base. In other settings, people might get together to write a paper, or create a new game.

**Data challenge:** an event in which teams compete to improve some score on a machine learning task. Requires quite a bit of pre-work defining the task, finding data, and building some computing infrastructure.

**Idea jam:** a brainstorming event. People are very opinionated about these (maximum numbers, who to invite, and so on), but in my experience you can make almost any scenario work.

**Design charette:** teams set out to design something. It's most interesting if the teams work on related things (or different aspects of the same thing).

We have always run 'pure' hackathons. Our events tend to focus on ideas, workflows, apps, user experience, and social aspects. So there's more emphasis on 'useful and interesting' than 'correct and performant', if that makes sense.

## Theme

The idea is to constrain the project space a little bit, otherwise teams might have trouble focusing their ideas. That said, the theme can be rather broad. Examples of themes we're used in the past:

- Seismic resolution
- Machine learning (always popular!)
- Visualization
- Uncertainty

It's probably best to avoid getting too narrow; one hackathon we participated in had a narrow focus and sure enough most of the solutions were variations on the same idea.

## Inviting people

Our approach to inviting people is to be as open and welcoming as possible to anyone that is interested in participating. By all means limit the event to a particular business unit if you need to. However, attempts to control the skills or backgrounds of the people who come will, we think, be counterproductive. Skills are not easily described, and besides people do not evaluate their own skills in consistent ways, so there's really no way to control the mix without being unduly selective.

If you have serious doubts about the depth of coding skills among the scientific community, then it might pay to be a little strategic about actively engaging some developers when you announce the event.

Bottom line: don't worry about engineering a good mix of people. In our experience, this happens naturally anyway.

## Marketing the event

Recently, as awareness of and interest in hackathons has grown in the subsurface community, it has not been difficult to get 20 or 30 people to an event. Getting 50 or 60 people to an event may require a little effort, however, spread over a couple of months. We have used the following strategies in the past:

- Writing directly to known researchers in the country or countries you are targeting. If they seem open to the idea, you can follow up by mailing posters and postcards to them, to put up or distribute at their institutions. Be careful here about just writing to 'the same old people', especially if the people you first think of all look like you!
- If your event is associated with another, for example a meeting or conference, then they may be happy to cross-market your event.
- Your corporate magazine and/or newsletter will likely want to cover the event, and might be able to advertise it ahead of time.
- Some external news outlets are interested in hackathons too, especially local news. Recently, the local TV channel covered an event in Norway with an angle on jobs and skill development in the workforce.
- Blogs and social media are another good way to spread news, especially if you can give time to engaging with people around the event, answering questions, etc.

## Projects

Some teams come with an idea for a project, but many people are looking for ideas on day 0 or the first morning. I usually maintain a 'project pool' of ideas in the lead-up to the hackathon, e.g. on Tricider.com or, lately, on events.agilescientific.com. I like having a way for people to vote on ideas, to help sort them a bit.

We have never tried any kind of preselection or engineering of teams, projects, or whatever. I think people appreciate the freedom of choice they have in deciding what to work on at the event itself.

A couple of things about teams:

- We've tried teams of 4, 5, and 6 and we think 5 or 6 is ideal. Teams of 4 tend not to get as much done as teams of 6, but of course it depends on the people involved (teams of 2 have done well more than once). We've had — against our will — teams of 7 and 8, but these rarely do well.
- Teams of colleagues tend not to do as well as teams of mostly strangers.
- All-coder teams, especially professional developers, tend not to do as well as mixed teams or even teams with only one or two coders.
- The good news is that just telling people all this tends to encourage them to find a good mix on their own, so don't do anything drastic to force the situation. A little social engineering should suffice.

## Data

Depending on your event, data might not be as big an issue as you might think — you can run a successful event without much data at all. Whatever you need, you can probably find something from open sources, or generate synthetic data. However, if you have specific projects you would like to challenge teams to address, or if there is an 'easy' dataset to provide — especially an integrated one (logs + core, say, or seismic + production), it could be interesting.

A word about open data: it's imperative. I recommend strongly discouraging anyone from sharing data without an explicit and fully open licence attached to it. Once it's out, it's out.

In short, providing data has never been a big issue for us. More than once someone has gone to a lot of trouble putting a dataset together, only for no-one to use it.

## Mentors

It can be very helpful to have visitors, especially scientists (e.g. geologists, geophysicists) or coders who could not come to the event. These people can listen to the projects and the teams' progress, and give feedback. It's not necessary that they are present all the time, but it's good if they can be there for day 0 (if you do one), and on day 1. On day 2 the teams are more focused on their demos and may not have time for being mentored. Do also invite mentors to the demos of course.

## Introducing the event

The host's task is to overcome the uncertainty everyone will be feeling and get the energy level in the room up. Some things to cover:

- Welcome everyone and introduce yourself and one or two key members of the organizing team. Tell them how excited you are to have everyone in the room.
- Get any housekeeping items out of the way: emergency exits, bathrooms, stationery supplies, that sort of thing.
- Break things up a bit with an occasional poll ('Who has been to a hackathon before?') or appeal for questions.
- Set out the plan for the whole event very briefly, then the plan for the current phase (usually, the first part is the team-forming and project-finding part).
- If there are people that the teams need to know, e.g. mentors, get them to introduce themselves.
- If there's anyone that wants to add anything (sponsors, etc.) now is a good time. Ask them to be very brief.

## Settling on teams and projects

Figuring out how people are going to spend the hackathon is the most important task for the host. Once you have a physical space, Wi-Fi, coffee, and a roomful of people, most of the rest of the event will look after itself. But some gentle shepherding of people before the hacking starts will help ensure a fun and productive hackathon for everyone.

There are two keys to getting things done in a timely way: have an absolute deadline (and tell people what it is!), and make it clear that the participants themselves are figuring their teams and projects out. Those people who have come with project ideas will be highly motivated to find a team and define their project, so you mostly just have to get out of their way and do what you can to support them.

We have used three models for this phase:

- Morning of day 1. For small events, up to about 20 participants and about 5 teams, you can probably get away with spontaneous self-organization on the first morning. It will likely take at least 90 minutes, so ask people to arrive on time and don't waste any time getting into it, even before everyone is there.
- Evening of day 0. For larger events, up to 60 participants and 12 teams, it's not a bad idea to carve out a bit more time and get everything done the day before the hacking starts. It's especially fun if you can find a cool venue and ply people with food and drink to help get things going.
- Day 0 daytime. If getting together in the evening is not an option, then you can get together during the day. And if there is time, you can expand the session to include some other components, such as project brainstorming, project planning, hackathon advice, training, or socializing.

Once you have a space and some time, you can get into what I call the 'project bazaar'. The idea is to create an atmosphere a little like a marketplace, where project owners have stalls and other participants wander around finding something that interests them. Here's how we do this:

- Ahead of time, connect people on social media, so they can start brainstorming, forming teams, and discussing data. Slack or Yammer are great for this.
- At the event, ask people to step forward with their project ideas. It's not a bad idea to prepare a couple of people for this, so you're not met with silence. Keep one or two projects in your back pocket, just in case (but don't force them on people if you don't need them).
- If this results in too few projects, pull out your back-up projects. If there still aren't enough, you can try brainstorming on the spot (difficult), or you can send people off to tables in small groups to come up with some new projects. Ask for one or two projects per table, no more. After 20 to 30 minutes, they can report back and you can use some process to filter or select the ones you need (e.g. with dotmocracy).
- In general, you'd like to end up with as many projects as there are teams, perhaps with one or two extra. You might need to merge or split projects later.
- Make sure people know how many people are allowed in a team, and how long they have to sort themselves out. Be strict about these things.
- Give a table and ideally also a whiteboard to each team leader and get them to start describing their project to interested people. Tell everyone else to go to the table or tables that interest them.
- Get people to mingle, move around, ask questions, draw things, and chat to each other about their skills and the things that interest them.
- Help connect people with teams, and vice versa. Try not to pigeonhole people: they might want to try something new at the hackathon.
- There are often a couple of people left at the end; you might just have to put them into a project.

Eventually, the chaos should start to settle down and people will start to coagulate into teams. Then they are ready to start coding!

## Coding

This will 90% happen on it own. A few bits of advice while the coding is underway:

- Visit the teams regularly, but keep your engagements with them short. Offer help, but try not to lecture them. Just make sure they know what kind of help they can ask for, and from whom.
- Make sure the teams know about the mentors, if any. But don't let the mentors pester the teams unduly.
- Keep them updated on the schedule or other plans with announcements about twice a day. It might be best to go around and visit them individually.
- When it's time to go, give people some warning. It can be hard to shut things down. Be firm when you have to be.
- Keep everyone fed and watered. Take snacks around occasionally.
- Take photos (make sure people know how to opt out of this if they want to).
- Take copious notes on the teams, what they are called, who is in them, and what they are working on. It is very hard to piece all this together afterwards.
- Check in often with the other mentors and organizers. Maybe keep a board of who is helping which teams, and what each team is working on. If the mentors are connected and talking, they are more likely to get good advice to the teams quickly.

## Intellectual property

I don't have a lot to say about intellectual property right now. We've thought about it quite a bit, but it's hard to give advice that fits generally. In general, I'd say this:

- Do not make any attempt to claim IP for people's contributions. Let teams own their IP.
- Make teams aware that, while they might not care about IP now, if their idea takes off, they might. So they should talk about it in their team ahead of the hackathon.
- One way to level the playing field, as it were, for team members is to make the project open source. That way, anyone who wants to run with it later, can do so.
- These articles are worth reading, but maybe not taking advice from:
- https://www.wired.com/2013/07/your-friendly-neighborhood-hackathon-might-not-be-so-open-after-all/
- https://hbr.org/2013/06/who-owns-hackathon-inventions
- https://business.agorize.com/en/blog/the-pitfalls-of-hackathons-and-intellectual-property-and-how-to-avoid-them/

## Demo advice

At about 12 or 1 pm on day 2, we ask the teams to come and describe their demo, or even do a dry run, to one or two mentors. We usually do two parallel sessions, so we can get through everyone in a reasonable time. Avoid using people who might act as judges later, because they should be judged on the final product.

To organize this, find two quiet rooms. Outside or near each one, put up a sheet with slots every 10 minutes, starting at 12 pm (say). Once everyone has arrived and coding is underway, go around and invite teams to go and sign up. Give them plenty of warning.

At 11 am, you can fill in the rest of the gaps, then tell everyone when and where they are due.

At the appointed time, get them to go over their demo plan. If it takes more than about 6 minutes, shut it down. Give them some feedback about their content, but nothing that can't be easily changed or fixed. Then go over some logistics:

- Code freeze is at 3 pm.
- Demos go in random order shortly after that.
- Go and make sure your laptop works with the projector.
- Aim to only use one laptop, don't try to swap them in and out.
- Aim to have at least two people speak, it looks better than a one-person show.
- It's good to let the judges know a tiny bit about the team: are you all coders? Did you just meet? Are you students? That sort of thing.
- Be clear about what already existed, and what is new. The judges are often unsure.
- What's the problem you're trying to solve? Set up the problem clearly, ideally with some notion of how big a problem it is.
- Get to the point, don't run out of time in the intro.
- You can leave some details for question time. Lead the judges into the questions you want to answer.
- Everyone loves a live demo, if you can manage it... but definitely definitely make some back-up slides of your stuff while it's working.

Be positive, the teams are working hard. With encouragement, they will almost certainly surprise people with what they've done, although they will feel like it's no good. Everyone feels like that!

## Judges

It's nice to have a big group for the demos on day 2 afternoon (ca. 1515 till about 1715) — and some of these people can help with judging. This part is all about having fun seeing the projects and celebrating what the teams have achieved in such a short time. We bring in drinks for the end of each day. If you can find people in your team or elsewhere in your organization who might enjoy being in the audience or helping with the judging, invite them well ahead of the event.

The judges do not need to be very familiar with the projects. I suggest not using people who have been around the entire hackathon, and definitely not anyone who has mentored or helped with the dry-runs.

The goal is 3–5 judges. More than 5 and it takes too long. Ask the judges to arrive well before code freeze, say about 1430 on day 2.

Have the judges introduce themselves before the demos.

## Demos and judging

Teams can do whatever they like in their presentation, but most focus on a demo of some kind.

The demos are usually 4 minutes long, followed by 4 minutes of questions from the judges or the general audience. This means that each team takes about 10 minutes, including a bit of time for changing over. If you have the option of using two portable microphones, give one for the judges to share, and one to the team.

Position someone at the front with a prominently displayed countdown clock on their laptop. Set an audible bell for the end of the 4 minutes. It seems incredibly harsh, but we have found that the best way to enforce timing is to tell the audience to start clapping as soon as the bell sounds. Everyone gets the same treatment!

You can go a little easier on the timing for questions, so as not to interrupt people, but try to make it clear when the questions are over.
The demos go in random order; we use a web app random wheel spinner thing. It's fun.

The judges score each presentation on the following criteria:

- Originality (quality of the idea)
- Execution (quality of the code and product)
- Commercial potential (will it sell?)
- Teamwork (how well the team seems to work together)

Recently we have been asking the audience to also rate the demos. We have found that the numbers of participants tend to diminish as the afternoon goes on, however, so I'm unsure how fair this is. Instead, you can ask people to simply vote for their favourite at the end. We use Mentimeter.com for this. The judges can choose to take the votes into account, or even make a special award.

Find a quiet space for the judges to deliberate. It's not a bad idea to nominate a head judge. This person can also emcee the final awards. It usually takes about half an hour. Make sure the judges know what the prizes are, and their relative value.

## Prizes

We usually aim for 4 prizes in total, where each prize consists of however many people you are allowing in a team. Last year we also did 'goodie bags' for the remaining participants, so everyone left with something. We have never done cash prizes.

We make awards for things in these categories, corresponding to the categories the judges are using for scoring:

- Best Idea
- Best Execution
- Best Commercial potential (or impact, or something like that)
- Best Teamwork and/or Best Presentation
-
There's also the opportunity to add a People's Choice award, if you are capturing audience votes.

In the past, we have avoided using language like 'First place', 'Second place', etc. But the relative value of the prizes, and the order in which they are awarded, communicates something of course.

We tend to look for technology-related prizes, but go for things that people are either unlikely to own, or that they can always use more of, or that they can at least pass on to someone else (ideally young people).

I usually look to spend up to about USD 200 per prize, so about USD 1000 per team. Usually one of the prizes is worth a bit more than the others, and one is worth a bit less.
Prizes we've awarded in the past include the following... first, at the upper end of the price scale (hundreds of dollars):

- Pieces of North Sea slabbed core, framed.
- Samsung Gear VR headsets.
- VR/AR dev kit of some kind; Google used to do Tango.
- NVIDIA Jetson dev kits (provided by NVIDIA).
- Mynt Eye cameras, https://www.mynteye.com/
- Mynt AI cube?
- Speaker array kits - EUR 180 (warning, very geeky)
- DJI Smartphone Gimbal – EUR 200
- High-quality mechanical keyboards, eg Majestouch Tenkeyless Ninja's with brown Cherry switches – EUR 300
- Noise-canceling wireless headphones – EUR 320
- FLIR One Pro – EUR 300 (or EUR 430 for the pro)
- Raspberry Shake – $350
- ANKI Cozmo or Vector - about EUR 280
- Google Coral TPU For inference - USD150
- https://www.intelrealsense.com/lidar-camera-l515/
- Chromebook
- Parallella mini-computers.
- Smart watches, eg Garmin VivoActive, FitBit, Samsung Gear, other Android Wear.

About $100:

- KORG NTS-1 mini-synth kit
- Lock-picking kits, eg Southord (all metal) and Lockmall practice sets.
- Infrared thermal camera

Then in the under $100 range:

- Raspberry Pis or Arduinos plus add-on packs.
- Movidius NCS > https://developer.movidius.com/
- Electronics projects — oscilloscopes, signal generators.
- OBD2 car intelligence kits, plus accessories or books.
- Trackr tags.
- Chromecast.
- Carson digital USB microscope > on Amazon
- Ledger Nano cryptocurrency wallet.
- Books — usually about computing, or Edward Tufte, or 52 Things.

When awarding the prizes, do let everyone know what they are. Alternatively, put them on display at the start. (Personally I like the suspense of keeping them quiet.)

## Swag

As well as the prizes, everyone gets 'swag' — T-shirt, stickers, that sort of thing.

The T-shirts might run to about USD 15 to 20 each, depending on the provider, quantities, shirt quality, design, and the means of production. For example, a local screenprinting service can likely do medium-quality shirts for close to or even less than USD 15. Printing complex or colourful designs in multiple locations on high-quality shirts will of course be more expensive. Recently, we've been using spreadshirt.com for shirts, because the site is easy to use and the outcomes have been quite good.

If you get T-shirts, you will need to get people's sizes, so collect this information at registration time if you can. It's worth offering women's shirts too; it's unlikely to cost extra. If you have to guess sizes, you can do something like 10% small, 35% medium, 40% large, 15% extra large.
I generally try to put a tasteful design on the front, and fairly subtle sponsor logos on the back. Getting vector art from sponsors is usually a bit of a chore, however, be warned.

Water bottles are a nice alternative to T-shirts. Sigg makes an excellent product and it is quite reasonable to get custom printing. It's a little cheaper than shirts, and you don't have sizes to worry about.

People like stickers. We use stickermule.com for stickers, labels, etc. They are easy to work with and very reliable. I've only had two jobs go wrong, in about 30 or so orders.

We've also given away small notebooks in the past; I like scoutbooks.com. They are a little pricey, but a very nice product.

If you haven't prepared designs for printing before, it might be worth getting some input from a designer. Some printing companies will do this for you. In general, you will need to provide pure vector art, with outlined fonts, and you might need to separate colours. If you provide rasters, make sure they have a lot of pixels.

## Bootcamp

On the day before the hackathon, we have sometimes hosted a Python bootcamp. This gives novices a chance to learn some basics, and others a chance to acquire some new skills or sharpen their existing ones. It will be less formal than a 'class', more like a 'skill share'.

It could also be an opportunity for people from your organization to help with the instruction — the more coders around the better, especially anyone with experience in Python, web applications, or mobile applications.

For a bootcamp, you'd ideally have 2 or 3 rooms with space for up to about 12–15 people each room. Then you can have groups of beginner and intermediate programmers in separate spaces.

## Timeline

We have organized events in as little as two months, but it's a much more comfortable experience with four months.
Here's what a typical event looks like:

### 4 months

- Design event structure, choose theme, etc.
- Shortlist venues.
- Design branding, posters, T-shirts, etc.
- Prepare invitations and marketing material.
- Start early invitations, if people have to travel.
- Start looking for sponsors and partners.
- Find mentors and other helpers.
- Start collecting challenges and datasets.

### 2 months

- Book venue, at the latest.
- Start sign-ups, at the latest.
- Invite judges and other visitors.
- Finalize sponsors, etc.
- Finalize challenges and datasets

### 1 month

- Shortlist caterers.
- Organize social event, if any.
- Order swag for delivery to venue.
- Order prizes for delivery to venue.
- Order marketing material.
- Brief mentors.
- Publicize challenges and datasets.

### 2 weeks

- Encourage teams to communicate on Slack.
- Get teams to start forming and signing up.
- Finalize catering plans.
- Send out final instructions, directions, etc to participants.

### Day before

- Ensure you have everything you need at the venue.
- Rush out and get any last minute things.
- Get the space ready if possible.
- Test the PA system and the projector equipment.
- Make sure you can get hold of the owners of the space if you need them.

### During the event

- It's very hard to document the event, but do your best. Take photos.
- At least capture the teams, the members of each team, and what they are working on. You will need this later!
- Keep the place as clean and tidy as you can, the teams will appreciate it.
- Make sure the mentors coordinate a bit on who is helping which teams. Don't let them all bug all the teams. A light touch is required. Err on the side of leaving the teams alone.
- That said, do check on all the teams periodically. It's easy for a quiet team to fly under the radar, then struggle near the end to converge on a demo. It's fine to check in with them during breaks etc, so that you aren't interrupting them.
- On day 2, it's worth doing dry-runs, as described above.
- At the end of the event, ask everyone to leave one or two pieces of feedback on their way out, e.g. on sticky notes. One good thing, one bad thing.
- By all means, follow up with a brief (5 questions max) survey. Usually about half the group respond, so it's probably rather biased.

## After the event

Before the dust settles, and definitely within 2 weeks of the event, capture all of the teams and projects in some fairly robust way. At a minimum, write up a short paragraph about each project, list the team members, include an image or screenshot that represents their work, and point to any apps or repos they have made. (If you don't do this, you will regret it later.)

Solicit feedback from everyone, e.g. with a Google Form. Keep it short, and ask specifically for things you can act on for next time.
If at all possible, follow up with individual participants to get more candid feedback, and to see how the projects are progressing, or not.

## Example structure

With larger groups (more than about 40), it's a good idea to get the projects formed ahead of time, otherwise you risk using up too much time on the morning of day 1. You could do this on a brainstorming day before the event (the day before, or within a week at least). This is what 'day 0' is for.

This is a format we have used, but there are lots of ways to arrange things.

### Day 0, 6 pm to ca. 9 pm

- Welcome teams, mentors and visitors.
- Eat and drink as icebreaker (about 1 hour).
- 'Project Bazaar' to finalize teams and challenges (about 2 hours).

### Day 1, 8 am to ca. 6 pm

- Coding all day.
- Coaching from mentors, as needed.
- Evening social, optional.

### Day 2, 8 am to 3 pm

- Coding.
- Presentation dry-runs from 12 pm (allow 10 minutes per team).
- Judges arrive and are briefed.

### Day 2, 3 pm to 6 pm

- Rearrange the room, if necessary (about 15 minutes).
- Demos, followed by Q&A with judges (about 10 minutes per team).
- Judges' deliberation (ca. 30 minutes).
- Prizes and wrap-up (about 15 minutes).

## Capturing the event

If you can get one or more professional media people to capture the event, you won't regret it. I recommend at least getting a photographer. Videography is quite expensive but very nice to have, especially if you ask them to get interviews.

It's definitely worth capturing the demos on video if at all possible. There's no easy way to do this; the best thing is probably simply videoing the screen and the presenters. Don't expect teams to be able to 'give you their slides' because most of them (hopefully) won't have any, or many. Hackathons are rather ephemeral things, so it's highly likely that the demo will be the only real product of most teams' efforts. Constantly bugging people to give you their stuff after the event is no fun for anyone.

## Finding a space

We believe it pays to find spaces that are a little out of the ordinary. Seek natural light, bold colours, and spaces with a variety of settings (desks, benches, soft furniture, perhaps outdoor seating). Avoid fluorescent lighting, ceiling panels, cubicles, and other things that will remind people of bad corporate offices or beige convention centres.

You should reckon on hosting about 1.4 times the number of participants you expect. So for an event of about 60 participants, you will likely need to host up to about 85 people. This accounts for facilitators, media people, support staff, jurors, and other visitors.

We have found that coworking spaces make excellent venues. They typically meet most of the requirements listed below, and many of them are accustomed to hosting hackathons. There's a good chance they can also connect you to local coders and entrepreneurs.

Here's the list of things we look for in a space:

- At least one table per team, plus 2 more tables for the facilitators and other people to use. Reckon on 6 people per team, so a table should seat 6 comfortably.
- Rectangular tables seem the most convenient, but large rounds are okay too.
- In a large space with multiple tables, 'Cabaret' arrangement is best.
- Make as much space as possible between the tables, given the space available.
- Nooks and adjoined rooms are useful, but avoid spaces in which the teams will be completely separate most of the time.
- Two additional tables at least should be set off for setting out swag, gear, food and other consumables. Ideally there is a separate area or room for food and drink.
- Chairs for everyone at the tables. Note that at the end of the event, we will need to reconfigure the space into 'theatre' style, or use another space for the demos.
- The demo space needs a large and bright HD projector and screen, with at least a couple of options for connecting (HDMI, USB-C, and SVGA should cover it).
- The demo space needs 3 wireless handheld mics, with PA system. Lavalier mics are not that convenient. You can probably do without PA for an event with fewer than about 40 people.
- We always need a lot of power strips, at least one per table, plus duct tape or other means of securing them. We often end up having to buy these, and we usually just leave them at the venue.
- Excellent Wi-Fi with capacity for up to at least 150 devices. We need to see at least 10Mbps (up and down) over Wi-Fi, preferably over 100Mbps down.
- If Ethernet is an option, then we can also bring wireless routers for back-up.
- If the Wi-Fi is dodgy or unknown, bring at least one 4G hotspot per 20 people for back-up. One hotspot per 10 people is even smarter. We have rented from https://www.my-webspot.com/ and they were good.
- At least 1 easel pad per team is very useful, and at least one Post-It pad, plus pens.
- Access to a printer is useful.
- Access to a refrigerator is useful.
- A secure area, container, or room is useful.
- Multiple large garbage and recycling containers, and access to cleaning products, are useful.

## Catering

Buy the best food and drink you can afford. Surprise people — they will notice and they will appreciate it.

Our events are usually one evening ('day 0'), plus two full days. For these, we need:

- Coffee, tea, and water for everyone. Some people also appreciate soft drinks.
- Two snacks per person per day (granola bars, fruit, candy).
- One breakfast per person on day 1 and day 2 (fruit, pastries, bagels, tacos, etc).
- One lunch per person on day 1 and day 2 (sandwiches, pizza, burritos, etc).
- One dinner per person on day 0, if you are starting with the evening event.

At public events we usually offer modest quantities of beer and wine, plus soft drinks, for day 0 evening and day 2 afternoon. This might not be an option for your event.

We also usually host a social gathering on the evening of day 1, to give the participants a chance to mix outside the context of the hacking. Not everyone can come to these, so don't make it an integral part of the event.

## Saying goodbye

The main thing: keep it short!

- Remind everyone of the start of the event: the uncertainty, the hoped-for outcomes, etc. Compare and contrast with how things unfolded.
- Congratulate the teams, and the individuals, again. They've focused and worked hard for 2 or 3 days.
- Encourage them to share the experience with anyone and everyone.
- Talk a bit about options or advice for keeping projects going. Remind them to keep connecting with each other.
- Mention any relevant upcoming events.
- Say goodbye!

---

# PART 5: Online events

In 2020, online events are suddenly the only events. But the last thing the world needs is another webinar. What do these usually look like? Well, not great:

- Totally focused on delivering a talk of some kind, usually either academic or marketing. There's a tendency for the purpose to be rather oriented towards the presenter, not the audience.
- Only avilable to people who sign up, and maybe pay, in advance.
- No shared content, just a lot of slides.
- Questions filtered through a moderator, with insuffienct time for them.
- No chat or other audience interaction.

You can use this list of bugs as a set of goals for your next online event!

## Why go online?

Online events are attractive for many reasons:

- Online events are much more accessible than anything taking place exclusively in meatspace. This accessibility has many dimensions: mobility, geography, and (if you're mindful of it) financial.
- Because of the lower barrier, online events can invite substantially more diversity into the event. So potentially we can invite participation from a much broader audience.
- Online events are cheap and easy to stream to and capture in the cloud, for asynchronous participation.
- Online events are cheap and easy to integrate with technology for mass participation, from chat to collective design and conversation.
- Online events are much cheaper to organize. No venue! No catering!

We've also seen how screen sharing is the ultimate video dongle! Gone are the days of switching laptops on the podium, or limiting presenters to PowerPoint, or other AV annoyances. Just have people share their screens — they can share movies, websites, live code, simulations, a mobile device, or anything they want! Why didn't we think of that ages ago?

## Why not go online?

It's not all fun and games: lots of things are harder to achieve.

- Breaking the ice online is harder than in real life.
- It's harder to 'read' people online, especially if they are not comfortable with having video on, etc.
- It's almost impossible to hand out props or swag or other physical objects.
- Some activities, such as drawing and playing games, are intellectually and socially liberating, but harder to do in a virtual setting.

## We need more experiments

The world is still figuring out what awesome events look like online. They probably are not just digitally transposed physical events — the technology limits too many things and makes lots of new things possible. So the best events will be a completely new experience.

We can explore faster if you share your experiences and experiments with others.

## Tools for online digital meetings

Here are the tools we used for TRANSFORM 2020:

**Slack —** the heart and mind of the Software Underground already lives in our Slack workspace. To make the multiple conversations more manageable, we made channels for all of the sessions and hackathon projects, and this worked well. During the week, 700 active members exchanged about 19,000 messages, about 50% of which were in private chat.

**Zoom —** the Covid-famous video conferencing tool. It worked well for us for the host–presenter meetings in the tutorials and lightning talks, and as the main room for the unsessions and hackathon presentations. We were very worried about Zoom-bombing, and were perhaps over-cautious (some legit people found it hard to enter sessions).

**YouTube —** for the tutorials and lightning talks, we streamed the host–presenter Zoom to YouTube for participants to consume. This has a few big advantages: it eliminates the Zoom-bombing risk, participants can pause and rewind the live stream, and videos go straight to YouTube afterwards. And it’s free!

**OBS Studio —** a fantastic open-source tool that lets you combine images, video feeds, and audio sources into a single stream, which you can send to YouTube (or Twitch or any other streaming service). This is how we streamed the Zoom sessions. It does have a learning curve though, and certainly requires an off-screen ‘director’ to manage it all — and several practice sessions to get the workflow down.

**GitHub —** is indispensable for code-sharing and source control. I think all of the hackathon projects hosted their repos on GitHub. The tool is not intuitive for new programmers though, and wrangling git and GitHub is one of the most requested help topics in our hackathons and courses.

**GroupMap —** a wonderful tool for collaborative brainstorming. It definitely needs a couple of hours to get the hang of what it can do, but for me this was the standout discovery of the event. Its best feature is that you can set up a workflow, like Survey > Brainstorm > Vote > Results and then guide the group through the stages, live.

**Sched and Eventbrite —** for event registration. Both of these tools have their high-points — Sched is really nice for building the event schedule — but the registration process for the event was a bit of a hairball and while these tools are supposed to play nicely together, I never felt comfortable with either of them.

**Printful —** a T-shirt (and other merch) vendor. The advantages are that they print ‘direct to garment’ (i.e. there’s no setup, they just print a shirt when you order one), they take care of fulfilment, and their system works seamlessly (sort of) with Squarespace, our website host. But the system is not that easy to use and I’m thinking of switching to Teespring.

**Hardware —** Microphones were hard to find during the Covid-19 crisis, but we sent Blue Yeti Nano or Blue Snowball Ice USB mics to our instructors. The Yeti Nano is especially nice, with two pickup patterns and a hardware mute button.

**Other —** The organizers and the participants used other tools during the conference, including: Mentimeter, Google Maps, Miro, and HackMD, plus of course Twitter and other social media.

---

# More?

From the blog:

- Are conferences failing you too?
- Ways to experiment with conferences
- Purposeful discussion in geoscience

Other Agile writings:

- Proceedings of an unsession, CSEG Recorder.
- Open collaboration: hackathons and tomorrow’s subsurface software, CSEG Recorder.

From elsewhere:

- Plan and run a great conference, Smashing Magazine.
- How conference organizers can create better attendee experiences, Open Source.
- Coincidentally around the time I wrote this, there was a Twitter convo about it. I completely missed it, but here's the Storify and here's an idea board from it.
https://twitter.com/DrEOChapman/status/1008623305081999365
https://twitter.com/moietymouse/status/1010584931809071104

---

# Acknowledgments

We wrote this book after running scientific events for about 7 years. In the process, we ruthlessly stole good ideas from sources too numerous to remember. The most important ones were:

- Open Space Technology
- World Cafe

Lots of people contributed ideas and energy to the movement. Especially these folks:

- Evan Bianco
- Tim Merry
- David Holmes
- Lauren Shumaker
- Christopher Jackson
- Victoria-Lou Deveze
- Jesper Dramsch
- Brian Romans
- Graham Ganssle
- Brendon Hall
- Filippo Broggini

As well as direct input on event design, the members of The Software Underground have been an integral part of the events we've run since even before it existed.

I would also like to thank the numerous organizations that have sponsored our events over the years. The first cohort of sponsors were really 'out there', and deserve special credit for just wanting to back something interesting in technology:

- OpenGeo Solutions
- Enthought
- dGB Earth Sciences
- Geoteric
- Palladium Consulting (now Expero)
- EMC (then Dell EMC)
- Sandstone Oil & Gas

From 2016 onwards, our events were a little more mainstream. Our sponsors from that phase enabled us to really push and grow these events, bringing the art of geoscience hacking to hundreds of people all over the world:

- Dell Technologies
- Enthought
- Schlumberger
- Shell
- Total E&P
- Wintershall
- Earth Science Analytics
- NVIDIA
- Teradata
- Amazon AWS
- GitHub

David Holmes at EMC and then Dell Technologies gets a special mention for his unwavering support of the weird and geeky.