What I Learned Teaching A Smaller Online Open Source Workshop (During A Pandemic)

The year 2020 has forced many former in-person tech events and conferences to go online. As a technologist who regularly speaks and teaches at tech events, I’ve also had to make adjustments. Earlier this year, I taught an online open source workshop that was attended by over 100 people. While that event was successful, I thought I needed to plan a bigger event next time to meet the needs of even more people. Instead, circumstances led me to go in the opposite direction …. to teach a much smaller, hands on online open source workshop. Here’s what I learned not only about teaching workshops online, but specifically about teaching smaller workshops online.

TL;DR 🙂 :

Since my last blog post did a pretty good job of specifically covering how to make online events successful in general, this one will focus more on how to make a smaller, hands on workshop work for your students.

Lesson 10:

When an opportunity comes along, if it’s in line with your goals, even if doesn’t look exactly like what you were expecting, take it. You never know what you will gain from that experience.

Even if it ends up changing some other plans downstream, that’s okay. I had wanted to speak at try!Swift conference ever since I attended on a scholarship several years ago. When Natasha the Robot invited me to speak at try!Swift New York, I was excited. And then of course, the pandemic happened and the in-person conference turned into small, hands on workshops. It wasn’t what I had expected and I didn’t know it at the time, but between this and other opportunities that later came along (including my new job, and speaking at 360iDev, amongst others), I wasn’t going to be able to plan the mega open source event I wanted to for the Women Who Code Colorado chapter later on. But that’s okay, because among the many things I learned / gained from this experience …….

Lesson 9:

Narrowing your open source workshop to a specific programming language will make your workshop more useful to everyone all around, particularly for more intermediate to advanced developers.

Teaching an open source SwiftUI workshop for try!Swift allowed me to focus more on open source as it pertains to iOS, specifically SwiftUI. And there’s nothing like teaching someone to force you to learn a topic yourself.

For my last open source workshop, I gave a talk on the standard Git workflow and then I ended with a hands-on workshop, where I taught the students how to modify a README file. This time for try!Swift, rather than just modifying a generic README, my students got to contribute to an actual iOS project that I built. This was more useful not just to my students, but also to me, as I work as an iOS developer for a living. Preparing for this workshop actually forced me to learn SwiftUI, which hasn’t become mainstream yet, but is becoming more important to learn every year since SwiftUI debuted at WWDC in 2019.

Lesson 8:
You can go deeper into a topic with a smaller group by narrowing your workshop’s focus. Clearly stating scope and pre-requisites to manage expectations will go a long ways towards your workshop’s success. A more narrowly focused workshop also takes less time, fewer volunteers, and less coordination to pull together.

Workshop Description

So, I made the focus of my workshop to be: open source contribution for iOS developers, using the standard Git workflow and SwiftUI. Also, going deeper and more hands-on is easier with a smaller group and requires fewer volunteers and less planning and coordination.

You can try to go deeper with a larger group, for example, helping attendees of all skill levels and programming languages find open source projects suitable for them. But it requires a lot more volunteers, coordination, and planning, especially if you want to address different skill levels & languages, and break off into smaller groups to give people more personal attention. This is great, but logistically, it’s not always feasible to pull off. I had myself and my workshop partner, Marc Aupont , and we scheduled plenty of time to practice running the workshop together, and of course, there was also the time I spent creating the SwiftUI project itself. But to plan a mega open source workshop I was going to hold for Women Who Code Colorado, honestly, after I was done speaking at 360iDev and teaching this workshop, I didn’t have enough time and energy to pull it off in time for Hacktoberfest. But ….

Lesson 7:
Building an iOS project using SwiftUI views was a great way to create an open source project for a lot of potential contributors. Thanks to Steve Lipton for the suggestion.

 

main screen of app

details screen of app

One strength of SwiftUI is you can easily compose a screen or main view, with multiple views. You can do something similar with UIKit, but it’s so much easier to do with SwiftUI. And as a moderator for my workshop, I wanted to give every student the opportunity to write some actual SwiftUI code and me not having to worry about managing merge conflicts. By assigning each student their own issue to work on their own view (by adding modifiers to their SwiftUI view), I was able to easily accomplish that.

Lesson 6:
Working hands on with a real project by following along with the live demo proved useful to students.

Teaching SwiftUI Open Source Workshop

Marc and I ran the workshop with him acting as the model contributor to my project, and me as the moderator. I started the workshop by assigning each student their own issue to work on. Then, Marc and I would perform each step of the standard Git workflow, pause at the end of each step to give students a chance to follow along, and then continue only when everyone has given the “thumbs up” emoji that they completed that step.

Again, running a workshop this way was much easier and doable, with a smaller class. We had only four students! Following along with a live demo proved to be useful to the students, but it also required a partner to play the role of the contributor, hence it was really helpful having Marc there! Also, on a Zoom call, whoever is screensharing can’t see the audience. So having a partner means one of you can act as a moderator when the other one is presenting. This also proved useful, when one of the students didn’t have working audio or video for the entire duration of the workshop and the person acting as the moderator had to keep an eye on the slack channel for the student’s “thumbs up” signal. Speaking of which …..

Lesson 5:

When doing a code along, especially if the group is small enough, take advantage of Zoom’s built in audience emoji’s to do regular check ins. We utilized the thumbs up emoji a lot. 👍

Lesson 4:

Lead with the why!

This was Marc’s suggestion and it went a long ways toward helping people “get it”, I think. For my 1st open source workshop, I gave detailed explanations for how to perform every step of the Git workflow. But looking back, some of the questions that students had were often related to them not understanding why they were doing a particular step. So by Marc and I introducing each step with the “why” helped solidify the concept of the Git workflow a lot better for these students this time.

Lesson 3:
Blink and you’ll miss the Diversity Easter Egg.

It’s now easy to create new Gitub projects with a “main” branch as the default, as that has become the default project creation workflow on Github. But before I taught this workshop, new Github projects were still given the problematic branch “master,” and I wanted to change the default branch of my project to “main” before I taught the workshop. So I followed this blog post to learn how to do that.

It may seem like a small thing, but actions like these can make a big difference in making your event more inclusive and welcoming to all people. I would encourage you to take advantage of opportunities to make your tech events more inclusive whenever you can!

Lesson 2:
There is a place for free events, but when you have more to offer and limited bandwidth / resources with which to deliver it, in order to sustainably continue offering such events, you need to put up a barrier to entry (especially for online events).

Wait ….. what? That doesn’t sound inclusive! You were just talking about making your events more inclusive earlier, you say. Well, let me explain …..

You see, in-person events, even FREE in-person events, have a barrier to entry, namely that you have to physically show up. Online events do not have that barrier, so consider charging an entry fee so that attendees will commit to your event.

That’s why try!Swift charges a fee (as of the writing of this article, it was $40 for two hours of hands on, online instruction, limited to 10 students). Even asking people to apply for a scholarship is a barrier to entry (which you can apply for a try!Swift scholarship if you’re eligible), but it ensures that only people that are serious about your event will attend. So you don’t get a bunch of folks who aren’t serious, draining your energy when you could be helping the people who show up that are serious about learning the topic at hand, and have the pre-requisites to be successful.

If you try to meet everyone’s needs & make the event free, it can be daunting. You will need a lot of runway for planning, and lots of volunteers and coordination to make it work. I already did that earlier in the year, and maybe it was time to do something smaller so I can teach about open source, as it pertains to what I do for a living, and that is, working in iOS.

Lesson 1: Conclusion
If I had tried to teach a bigger open source workshop, I probably would have done the same thing I did before: teach a beginner’s group to modify a README file, while volunteers help more experienced devs look for open source projects. But by going smaller and narrowing the focus of this open source workshop, I got to do something different this time: learn SwiftUI by building a real project for the workshop, and get to know & work with another iOS dev (Marc Aupont) as my workshop partner. It also gave my students the opportunity to work with iOS / SwiftUI code and learn about the standard Git workflow as it applies to open source contributing.