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
People learn skills by practicing them. That's the reason we run tutorials at the hackathons. 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"

 * kinetic
 * verbal
 * auditory

There are many learning styles. Most 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 for All Learning Styles

 * inductive
 * expressive
 * deductive
 * prediction

Practical Examples: The Practice Zone
"Students"/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 taking 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
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).

"Be Bold" and Ask for Feedback Before Your Audience Leaves
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 really 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 or simply ask people to email you with their feedback right then and there. Follow up with an email to participants, including links to and ensuing on-wiki discussions.