User:Danielle Benoit
- Who am I?: Danielle Benoit
- Email: drop me a line
- Working on: Tutorials project for Berlin Hackathon 2012
Strategies for Running a Fabulous MediaWiki Tutorial
[edit]People learn skills by practicing them. That's the reason we run tutorials at the hackathons. They are now an important part of MediaWiki culture, as mentorship has been since the beginning. The difference between a presentation and a tutorial is practice. Talks, presentations, slide decks are all passive for the audience. Tutorials put people into action.
Learning Styles: About the "Students"
[edit]- kinetic
- verbal
- auditory
There are many learning styles, most of which fall into three categories: hearing something, seeing or doing/touching something. Of these, doing something builds skills the fastest. So how can you teach skills to people with all of these learning styles? Mix it up! Include several types of exercises/hands-on activities in your tutorial.
Developer culture leans toward looking at code. It's a primary activity in dev. But, it's not the best way to learn a skill. Why? If you just show a code snippet and talk about it, tutorial participants are engaged in listening, a passive particpation. They are taking in information, but not using it yet. To learn a skill, people need a chance to actively participate, to practice the skill by doing it.
Teaching Strategies and Exercise Ideas
[edit]Teaching strategies tend to fall into these categories: inductive, expressive, deductive, prediction. Thinking about your topic in terms of each category might give you some exercise/activity ideas. Here are some more:
- Repetition - repeat your most important points/skills at least several times
- Positive reinforcement of specific actions wires that behavior into brain (toss out candy/schwag or praise)
- Break into groups/paris and work on a problem together (have a time limit and way to get their attention again)
- Practice solving a problem in a code snippet, lab, etc.
- Create something that summarizes your tutorial info: infographic, chart, article stub, template, summary doc, help page, guide, cheat sheet, etc.
- Quiz each other, vetting quiz (last one standing wins, game of tag asking questions of each other)
- Report back to whole group about results, observations, etc.
- Ask for their examples, experiences with problems
- Have them teach each other or you
- Brainstorm solutions together
- Predict the results of something after you've demonstrated it once or more
- Question and Answer, but you ask the questions and participants answer (toss schwag to the correct answer).
- Fill-in the blank, complete/improve this example, find the problem/bug, solve this problem, etc.
The Practice Zone
[edit]"Students"/dev tutorial participants are more likely to use what you taught them if they have a specific opportunity to practice it immediately. This can be challenging, depending on the subject you're training people in and the resources at your disposal. So, preparation time is important for creating a practice zone. Preparation for "students" is important, too! If they have a chance to look at the materials and experiment with the "practice zone" before the tutorial, they are more likely to bring good questions and to learn faster during the tutorial.
If you have a Lab, Sandbox or Project they can work in, be sure you publish the URL, path, permissions process, etc. well ahead of time. Nothing is worse than losing 15 minutes of a 45 minute tutorial to get everyone logged in. If there are additional manuals, guides or live help options, be sure they have those links, handles, IRC #s, email lists/addresses, places to find a mentor, etc.
Offering Resources, Encouraging Participation
[edit]Empowering people with ongoing opportunities to engage with the dev community obviously increases the chances that they will contribute code. But, it also strengthens our community and encourages mentorship. Again, if there are additional manuals, guides or live help options, be sure they have the links, handles, IRC #s, email lists/addresses, places to find a mentor, etc. (This is an example of repetition. I want to drive home the message that you should reiterate your most important points - loop, recurse, repeat, repeat.).
"Be Bold" and Ask for Feedback Before Your Audience Leaves
[edit]Why?
- Open communication is part and parcel to the open source world
- You can become a better teacher
- You can develop better relationships with devs who can help with your projects
- You can develop a better tutorial the next time
- It tells devs that their experience matters to you
- It makes devs more likely to say good things about you and your tutorial
- It makes devs more likely to participate in future hacking
- It gives you the chance to learn
- It's just really darn good for the community! So, do it.
You can get quick feedback by asking for a show of hands in response to some key questions. This helps keep communication open and increases the likelihood that your audience walks away feeling good about your tutorial. You can also create a form online to collect anonymous feedback or MediaWiki/Tutorial discussion/talk page or simply ask people to email/msg/talk page you with their feedback right then and there.
Follow Up
[edit]Follow up your tutorial immediately, with a user page notice or email to participants, including links, resources and info about ensuing on-wiki discussions. This helps to keep them involved and may help you with more eyes/hands on a project.