├── README.md ├── docs └── img │ └── Workshop-Abstract-Example-v2.png └── labs ├── lab-template.md ├── workshop-setup.md └── workshop-wrapup.md /README.md: -------------------------------------------------------------------------------- 1 | # Workshop Title 2 | An easy to follow template for running workshops. 3 | 4 | It can be hard to know what makes a good workshop. How do you design a workshop in a way that makes it easy for users to follow along and provides natural checkpoints so that everyone is one the same page? We can design labs (or discrete learning points) to take into account how people learn and how workshops are generally taught. 5 | 6 | Another issue is collecting feedback about the workshop. Was the workshop useful? Was it everything it promised to be? What else should I have included? The easiest way to answer that is by running surveys and making them an OPTIONAL step in the workshop. 7 | 8 | In this workshop, you'll will: 9 | * Learn how to setup a workshop to maximize participant's engagement and learning. 10 | * Learn how to design labs with checkpoints, to ensure everyone has learned the key points. 11 | * Learn how to unobstrusively collect feedback from attendees so that you can create even better content for them. 12 | * Learn how to smoothly run a workshop by yourself, with potentially 100s of attendees, by following this template. 13 | 14 | > **Note:** The first section of your github workshop is the 'abstract'. It tells users the benefits of running through your workshop and provided any additional resources they may need, if your workshop isn't for them. Often times I'll even include a link to a video or picture emphasising this point. 15 | 16 | Here's an example: 17 | > ![](./docs/img/Workshop-Abstract-Example-v2.png) 18 | 19 | Lastly, the biggest factor determining if a workshop will be successful is preparation. Before you run the workshop, run through it a few times (using the same setup a user would). Most of my bad workshops came down to lack of preparation. Although preparation is important, I won't be talking about it in this workshop. 20 | 21 | ## Labs 22 | 23 | 1. [Workshop Setup](labs/workshop-setup.md) 24 | 1. [Lab 1](labs/lab-template.md) 25 | 1. [Lab 2](labs/lab-template.md) 26 | 1. [Lab N](labs/lab-template.md) 27 | 1. [Workshop Wrap Up](labs/workshop-wrapup.md) 28 | 29 | > **NOTE:** Setting up labs this way makes it really easy for a workshop presenter to say, "Everyone, we're going to run through the Workshop Setup now." Then, after explaining the lab, and while everyone else is running through it, you can go around and help atttendees that need additional help. 30 | 31 | ## What Next? 32 | 33 | If this lab was too advanced, you might want to check out: 34 | * Link to pre-requisite content 35 | 36 | If this lab was too simple or you completed it (like a boss): 37 | * Link to follow-up content 38 | 39 | > **Note:** Have a discrete place for pointing users to if this lab isn't for them OR for once they've completed it. 40 | 41 | ## Resources 42 | 43 | * Kelsey Hightower's [Kubernetes 101 Workshop](https://github.com/kelseyhightower/craft-kubernetes-workshop) is the best example I've seen of this format. 44 | -------------------------------------------------------------------------------- /docs/img/Workshop-Abstract-Example-v2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/askcarter/workshop-template/d3055402b939b7ef16320bb833798ea5b1010181/docs/img/Workshop-Abstract-Example-v2.png -------------------------------------------------------------------------------- /labs/lab-template.md: -------------------------------------------------------------------------------- 1 | # Lab Name 2 | In this Lab, we'll talk about how to structure a Lab to make it easy for someone to learn from. 3 | 4 | I try to present the information in Problem - Solution - Example format. 5 | 6 | I generally break down labs into 20 minutes of material. I'll present on the topic for 5-10 minutes and then I'll have attendes run through the Lab on their own for 10-15 minutes. 7 | Afterwards, I'll present myself running through the lab, so that attendees can follow along and so that I can provide additional insights into the Solution / Example. 8 | 9 | If I'm short on time or have some reason not to put the Problem and Solution information onto a github page, then I'll just have the Example on the githbub page and explain the Problem and Solution via slides. 10 | Either way, the critical information is always being displayed in the proper order. 11 | 12 | > **Note:** This is just my template for doing this. Sometimes it will be necessary to break this template up into separate sections, based on the size of each individual section. That's OK! 13 | 14 | ## Problem 15 | 16 | Maximizing engagement and learning is difficult. 17 | 18 | Luckily there are a few small tweaks to how presenters commonly present information that can make this process much simpler. 19 | In fact, one of the big mistakes presenters make -- because they have so much knowledge on the subject -- is jumping right into a problem's solution or explaining a feature. 20 | 21 | The problem with this is that you have to meet the audience we're they are at. As the presenter, you have ton of knowledge around (and context for) the solution. 22 | But, the people that are attending your workshop? They come from wildly different work backgrounds. 23 | In order to mitigate that, start by explaining the WHY the solution came to be, first. This gets everyone on the same page, so that maximal learning can take place. 24 | 25 | Start with making sure your attendee's understand the Problem, before trying to provide a Solution for it. 26 | 27 | > **Note:** Why should we start with a Problem? 28 | > 29 | > To educate the viewer. Stating the Problem clearly, sets the stage for the Solution we're providing, later. In order to persuade them to try our Solution, the viewer has has to understand what is being solved. 30 | > 31 | > Make sense? If not, no worries; 32 | > I'll leave the explanation to a much smarter person: 33 | > 34 | > "Convincing others that a problem is significant is an essential step. 35 | > 36 | > When a problem appears insignificant, almost every solution will seem too expensive. But for a significant problem, there are usually many solutions of reasonable cost. When we disagree about whether to adopt a particular solution, we're often actually disagreeing about the significance of the problem being solved. 37 | > 38 | > The lesson here is that it is difficult but essential to describe the significance of a problem in a way that someone working in a different environment can understand. 39 | > 40 | > The clearest way to do that is by showing how the problem affects real programs and real production systems." 41 | > -rsc, https://blog.golang.org/toward-go2 42 | 43 | ## Solution 44 | Once we've set the stage, by introducing a Problem, we'll show the users a Solution to that problem. 45 | 46 | ## Example 47 | Once the user has seen the Solution, we'll use a hands-on example to make it vivid and real. 48 | 49 | These are steps the user should be running on their own. 50 | 51 | Lab -> Presenting with Charisma 52 | Problem -> Stage Fright. It's hard to present well, because nerves make you clam up. 53 | Solution -> Reframe anxiety as excitement, because physiologically they appear the same. 54 | Example -> Step by step through an exercise for reframing anxiety as excitement. 55 | 56 | # Wrap Up 57 | In the wrap up, I'll put a small recap of what the attendee accomplished. 58 | 59 | Then I'll ask ssk additional, bonus questions to check understanding. 60 | * How would you do X? 61 | * Why did we do Y, in the example? 62 | 63 | Finally, I'll leave a little information to lead the user towards whatever interesting topic they'll be learning in the next Lab. 64 | -------------------------------------------------------------------------------- /labs/workshop-setup.md: -------------------------------------------------------------------------------- 1 | # Workshop Setup 2 | 3 | Setting up the workshop is the hardest part. I generally run through all setup steps together to make sure everyone reaches the same starting point. 4 | 5 | My goal in the setup is to get everyone to the SAME starting point. This is easiest to do if I can use a 6 | 7 | > **Note:** By workshop setup, I'm referring to any setup that the attendee has to do -- during workshop time -- to complete the rest of the workshop. 8 | 9 | For tech workshops, I like to set variables to make the rest of the workshop easier. The goal is to make the rest of the workshop as easy as possible. 10 | 11 | ## Pre-Workshop Survey 12 | 13 | Collecting feedback should become an automatic part of running a workshop. We do that by building in pre- and post- workshop surveys. 14 | 15 | Pre-workshop surveys should ask the following questions: 16 | * [Hopes and Dreams] What are you hoping to get out of the workshop? 17 | * [Fishing Holes] What container technologies have you used, if any? 18 | * [Pains and Fears] What problems have you run into with your current solutions? 19 | 20 | > **NOTE:** To make using survey data easier, you can link a survey with a pre-filled "Event" field. You can also add a few simple demographic questions, too. For example, I'll often ask about an attendee's company size or what their job title is. 21 | 22 | [Click here to see an example pre-workshop survey.](https://goo.gl/forms/MDXRp3OJdMySL1ql1) 23 | 24 | 25 | There are a few major goals of the pre-workshop survey: 26 | 1. **Collect data on attendee's goals and expectations.** This helps you determine if you're positioning (the abstract, the title) are correct. 27 | 1. **Tailor the workshop to attendees.** After the survey look at the "Hopes and Dreams" questions and address which will be addressed in the workshop and which won't. 28 | 29 | ## What Next 30 | Next, it's time to run your first Lab -- or, in this case, it's time to check out the Lab Template. 31 | -------------------------------------------------------------------------------- /labs/workshop-wrapup.md: -------------------------------------------------------------------------------- 1 | # Workshop Wrap Up 2 | 3 | OK, so you've knocked out most of your workshop. 4 | 5 | All that's left is wrap up. Here's what need to do. 6 | 7 | ## Recap 8 | 9 | It's important to let the attendee know everything that he or she learned in the workshop. That's pretty simple so I won't say antyhing else about it. 10 | 11 | ## Post Workshop Survey 12 | 13 | Collecting feedback should become an automatic part of running a workshop. We do that by building in pre- and post- workshop surveys. 14 | 15 | Post-workshop surveys should ask the following questions: 16 | * Rate the workshop from 1 to 5 17 | * Would you recommend this workshop to a friend or co-worker? Why? 18 | * What could have been better? What would you have liked to see more of? 19 | * If you have any questions, please leave your contact info and a description here. 20 | 21 | There are a few major goals of the post-workshop survey: 22 | * **Collect data on attendee's workshop experience.** This helps you improve the content and delivery of the workshop material. 23 | * **Get follow-up information.** Workshops are great because they make it easy to get invited to run workshops for specific customers, on site. Let people know that they can request that from you, in your survey. 24 | 25 | > **NOTE:** You will get a lot fewer post-survey responses than pre-survey responses. This is to be expected. 26 | 27 | [Click here to see an example Post-Workshop Survey](https://goo.gl/forms/cXVsurpjpHCu0wQp1). 28 | 29 | ## What's Next? 30 | 31 | Here's it's time to point your workshop attendees to new information and value. I generally point them to a landing page with additional resources about the workshop. [Click here to see an example](http://www.kubetalk.com/welcome-gophercon-2017/). 32 | 33 | --------------------------------------------------------------------------------