I've been reading so here goes.

I'm thinking about the problem of getting students to look beyond the facts to the meaning of the facts and the reasons we've come to believe they're facts. This makes knowledge transferable to questions with different formats, and avoids the situation of students being able to parrot back what they "know," but not being able to see and use the deeper principle in context. One of my favorite passages from Surely You're Joking, Mr. Feynman illustrates this sort of parrot-learning well:

I often liked to play tricks on people when I was at MIT. One time, in mechanical drawing class, some joker picked up a French curve (a piece of plastic for drawing smooth curves -- a curly, funny-looking thing) and said, "I wonder if the curves on this thing have some special formula?" I thought for a moment and said, "Sure they do. The curves are very special curves. Lemme show ya," and I picked up my French curve and began to turn it slowly. "The French curve is made so that at the lowest point on each curve, no matter how you turn it, the tangent is horizontal."

All the guys in the class were holding their French curve up at different angles, holding their pencil up to it at the lowest point and laying it along, and discovering that, sure enough, the tangent is horizontal. They were all excited by this "discovery" -- even though they had already gone through a certain amount of calculus and had already "learned" that the derivative (tangent) of the minimum (lowest point) of any curve is zero (horizontal). They didn't put two and two together. They didn't even know what they "knew."

I'm not yet sure how to make sure the students do go beyond parrot-learning, but I can think about specific ways to test for beyond-parrot-ability in particular situations, and I suppose that's good enough for now.

Next up: we say that students learn from mistakes; teachers learn a tremendous amount as well. By looking at the sort of errors a student is making, a good instructor can start to gauge the sort of mental picture they've got of how to tackle the problem, and how that differs from the kind of mental picture(s) they ought to have to tackle it, and possibly even where that (incorrect) assumption came from.

Language-learning is particularly good for illustrating this; for instance, someone learning English might stick "-ed" at the end of verbs to make them past-tense, not knowing that many verbs are irregular. It's pretty easy to see where that might come from ("in my limited experience, all past-tense verbs look like their present-tense equivalents with an "-ed" added") and therefore how to fix it (demonstrate counterexamples, but note that the "-ed" rule-of-thumb does work for many verbs and will generally be understandable to native speakers, i.e. "eated" vs "ate.")

UbD talks about focusing and not having "LEARN EVERYTHING" as a learning objective. I'm terrible at this. One of the biggest challenge of trying to make something as big and chaotic as "how to participate in open source communities" teachable is the question of what's actually vital, and what's nice-to-know but survivable-without. Yes, I flinch every time a student team does their regular status reports by uploading a Word document to a wiki -- but then again, I chose to spend my teaching time with them getting them on IRC rather than setting up a blog because I thought the first was more important, so is that report better than no report at all, and should I really block them from forward progress until they have everything perfect? No. Okay. So awkwardness will happen in the beginning, and I should be more ready for that.

Final thought that struck me on this run through the book (although this thought does not come from the book itself): one thing that bothers me about teaching open source is that I sometimes feel like we're overmarketing it. TOS teaches your students basic subjects! Communication skills! Real-world experience! Large codebases! Global contexts! Service learning! It cures cancer, makes dishes dry streak-free, and walks your dog!

Clearly open source can't do everything. I'd like to see more thinking about what the open source way isn't good at; I do believe it's good for things (for instance, non-major classes or large intro courses) that most people might initially think it wouldn't work for, but I also suspect that it may be terrible for some things that we (open source enthusiasts) believe it's wonderful for. For instance, do open source communities really give students useful feedback? All right, under what circumstances and at what effort -- and when is the tradeoff not worth it?

Things to ponder as I head back home for dinner.