Missions pedagogy

From OpenHatch wiki
Jump to navigation Jump to search

This is a page about improving or modifying OpenHatch.

We call that "Hacking OpenHatch," and there is a whole category of pages about that.


About this page[edit]

This is a summary of the pedagogy requirements and goals of OpenHatch training missions.

The missions do not all conform to this yet, but if we can agree on how they should work, in terms of teaching style, then we can adjust them to be like that.

You can think of it as similar to other projects' "Human Interface Guidelines" documents, and to Debian Policy.

Thanks to Mel Chua for working with Asheesh Laroia and other people on this document!

A training mission should fill all three elements of the curricular triangle[edit]

If you have an idea for a mission, you probably have these things in mind already -- this is just a more structured way of thinking about it, to help you figure out whether your mission will accomplish its pedagogical goals.

The three elements are:

Learning objective: What you want people to learn through completing your mission. These usually take the following format: "By the end of the mission, the learner should be able to... (action verb) (remainder of phrase)" (More on writing good learning objectives.) An example learning objective would be "By the end of the mission, the learner should be able to send a private message to another user on an IRC channel." You should list your learning objectives at the beginning and at the end of each mission.

Activity: What people will do in order to accomplish the learning objective of your mission. For instance, "Learners will practice sending private messages to an IRC bot asking about its favorite pancake recipe."

Assessment: How you'll be able to tell whether learners have achieved the learning objective or not. For instance, "The IRC bot will check to see if the learner has sent it at least 3 private messages."

In missions, "activity" and "assessment" may be part of the same action -- but they don't have to be. For instance, you could have an activity that consists of reading wiki page editing tutorials and making initial test edits in a sandbox before moving to an assessment that asks you to make a specific edit to a specific page. (In a more familiar school setting, the "activity" might happen during a class session, and the "assessment" would be a homework assignment, project, or exam.)

A training mission should have a plot[edit]

The Subversion mission is a good example of this. Every step you take in the mission is aimed at helping your character complete steps in a plot.

The tar mission, for example, is bad at this; it simply asks you to do things. The things may be fun, but there is no over-arching story arc.

All missions should have a plot.

A training mission should have a "Quick reference" at the end[edit]

After someone at the Desktop Summit went through our git training mission, she wanted a quick way to review what she learned. (refs: issue535)

All missions should have a "Quick reference" at the end, in which someone who went through the mission can review what they learned without having to re-do the mission.

A training mission step should have hints whose level of detail is configurable by the user[edit]

Right now, the level of "hints" varies wildly between mission steps. Sometimes we tell you exactly what command to type; sometimes we don't give you much advice. Sometimes we tell you to look at a separate page called "Hints." (refs: issue459)

It's okay if parts are blocked so long as there is a "See anyway"[edit]

Some training missions require the user go through the steps in a particular order. It is okay if the UI prevents the user from skipping to a page that he/she can't use so long as there is a link that lets the user preview what the page would look like (even if slightly broken).