Event Ideas

There are a ton of different types of events you can do in your Study Group. The most popular tend to be code-alongs, but don't be shy to add some variety with other, more open ended events, like the ones below - or come up with something completely new and different! The only rule is to try and include as many people as possible.

Work-Along

A hands-on guided tour of a piece of code, tool, or other skill.

Work-alongs are perhaps the most popular Study Group activities, where a demo leader plugs their laptop into a projector and shows how they use a particular piece of code, tool or other skill in their research, while everyone else follows along on their own machines. These are great opportunities to help your community discover new tools and see novel solutions to common problems, and a chance for the demo leader to practice teaching and presenting in a participatory, hands on class. A few tips for a good work-along:

• Keep it short. An hour is plenty long enough; more than this, and it becomes too much to absorb all at once.
• Keep it simple. That hour will go by really fast for the demo leader - sixty minutes is really only enough time to cover a few introductory ideas. Remember, there's no final exam; if people walk away with a successful first couple of steps on the topic, that's all they need to get started and learn more in future.
• Keep beginners on board. This means explicitly illustrating every step, and going slow enough for participants to copy down everything you're doing - so that everyone can follow along.
• No slides. Slides are boring. The presenter should live-demo all their examples, while everyone else follows along on their own machines.
• Give people challenge problems. If you're the presenter, don't talk the whole time - take a couple of breaks to let your students try their new skills on a challenge problem or mini-project. This also gives you the chance to answer questions, and make sure no one gets lost.
• Keep it real. Try and illustrate how you actually use the tool in your research; this way, everyone will understand not only how to use it, but why it's valuable in real practice.
• Encourage non-experts to lead. It is absolutely not required to know everything about a package or skill to lead a demo on it. Always invite participants to lead a future session, and remind them that it's more interesting and more authentic to see how they use the tool in question, than to see a more esoteric perspective.
• Post the lesson notes. It takes some work to prepare the notes for a lesson - instead of letting them disappear afterwards, put them in a GitHub repository and share them back with the community. See this example - lesson notes in a README.md file and extra data or examples alongside it in the repo is all that's needed. Once those are up, include a link from your Study Group's '/lessons' directory (like this), and let the Science Lab know so we can point to them from our collection of Study Group Lessons. If you're not comfortable with Markdown or GitHub, feel free to ask the Science Lab for help!

WIth that in mind, if you're thinking of running a code-along for your Study Group, open an issue in their repository descibing what you want to teach, and the organzers will help you book rooms & schedule the event.

Coworking Session

An open session to work on projects and ask each other questions.

Co-working sessions are a great way to get stuff done and discover new coding techniques. Get your Study Group together for a couple of hours to all sit down and work on their latest coding projects - and encourage everyone to ask each other questions when they get stuck, show off their work and talk to each other about what they're doing. To have a great co-working session, try these tips:

• Welcome beginners. Make sure everyone knows new coders are very welcome, and that it's okay to ask any question you like. Also, make sure the more experienced coders in the group know how to make newcomers feel welcome; treating anything like it's trivial is offputting for people just starting out. There is no such thing as a 'stupid question' in a Study Group.
• Do lightning intros. At the start of the session, go around the room and have everyone call out tweet-length descriptions of what sort of tools and language they're working in that day - and encourage people using similar tools to chat and work together.
• Have a demo party. At the end of the session, give people a chance to show off what they're working on to the group - these should be really quick demos, meant to give people just a flavor of what people are doing - and start conversations afterwards.

A variant on the coworking session is the strategy circle - invite people to describe a problem they're having, and then open the floor for suggestions on what kind of packages, tools or strategies they could try out to solve their problem. After everyone has had a turn to describe their problem and get some suggestions, open the time up to experiment with those new ideas and get help in open conversations with the group.

Hacky Hour

A pub night or cafe meeting for researchers who code.

A Hacky Hour is a great, informal way to open things up and encourage community members to meet one another, discuss new ideas, and build the social ties that help strengthen any community. They're also some of the easiest events to organize, since all that's required is an open cafe or pub! A few ideas on making a great Hacky Hour:

• Encourage lots of connections. Any time someone wants to meet to chat about a code project, needs help with a bug, or wants to find out more about what's happening in your community, invite them to Hacky Hour, so they can meet the community and find out first hand. Keep an eye out for people who might have some projects or interests in common, and help make connections.
• Choose the right venue. A pub or cafe at or near your institution, a little before the busy hours is best (3 or 4 PM Friday). This makes it convenient for everyone to get there and get a seat, and when it's a bit quieter, it's easier for people to have conversations and maybe even hack on a bug or two! When the weather is good, patios are great for this.
• Get together at a different time than your usual meetings. Hacky Hour's main purpose is to make your group available to newcomers who want to ask questions and meet people casually before coming to a more organized session; having a hacky hour outside your usual times will give new and differnent people the chance to come say hi.
• Make it obvious. Make sure it's easy for newcomers to identify who the Hacky Hour group is at the venue; funny hats can go a long way.

Coding Lightning Demos

An open house of short tool demos.

A lightning demo is a short demo of a tool or piece of code, meant to make a quick introduction to an audience so they can decide if they're interested in learning more. Get a whole bunch of these together, and you have a Lightning Demo Party or Lightning Demo Series! Try these tips for your first round of lightning demos:

Demo Party

In a lightning demo party, lots of people get together in a science-fair type setting to mingle and get a glimpse of new tools and techniques they might like to dig into more in future.

• Aim for 8-10 demos. This is enough for there to be some substantial variety at the party, but small enough that it won't take hours for people to check out all the demos.
• 5 minutes max. Ask presenters to keep the demos short; there's plenty to see, and if there's lots of interest in one area, invite the presenter to lead a code-along at a future meetup.
• Include some research context. Getting the presenters to add a quick comment on how they use their demo in their research will help motivate the tools, and communicate to everyone what their research applications are.
• It's a party! Set your presenters up in a big horseshoe pattern so people can circulate, and consider serving snacks or drinks if feasible. Setting the scene this way will help encourage people to talk amongst themselves and brainstorm about how they're going to use all these cool new ideas.

Demo Series

In a lightning demo series, presenters give a series of short demos to an audience, like a series of mini-work-alongs. This is a great opportunity for new speakers to give presenting at Study Group a try; like the party format, encourage speakers to always add some research context so people know where and how the ideas presented are being used.

• Aim for about 4 demos. Switching between potentially wildly different ideas in a lecture format can get exhausting for the audience after more than an hour, so keep it tight - if you have more presenters than that, consider party-style, above!
• 15 minutes max. These lightning demos can be a bit longer, since the audience will be seated in this format.