<div class="gmail_quote">On Mon, Aug 23, 2010 at 7:03 AM, Matthew Jadud <<a href="mailto:mjadud@allegheny.edu">mjadud@allegheny.edu</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On Sun, Aug 22, 2010 at 21:47, Luis Ibanez <<a href="mailto:luis.ibanez@kitware.com">luis.ibanez@kitware.com</a>> wrote: > I would appreciate your comments regarding > form and content, particularly to make sure > that it matches the style and tone of previous > posts. </div>Hi Luis, I would encourage you to present the steps or approaches that are now being taken to improve the course. Specifically, you break out pedagogic problems that have been experienced all the way through the third iteration of the course, but you did not offer any indication that steps are being taken to address these problems. Expanding the article in that way would improve it in my eyes. That was the largest recommendation I would make; anything smaller was eclipsed by my desire to see how the challenges were being addressed. Cheers, Matt </blockquote><div>------------------------------------ Hi Matt, Thanks a lot for taking a look at the article. I agree with you in that addressing the pedagogic problem is of great importance. The challenge here is simply that we have no clear answers, and we were actually hoping to gather words of wisdom from readers of the article (and members of this list). Let me elaborate here on what our conundrum has been. Here are the two things that we are finding most difficult: 1) Ensuring that students get a full exposure to the experience of participating in an open source project. (community participation, meritocratic governance, peer-production, agile development, code-review...) 2) Motivating the students by using an approach that is essentially compatible with the "open source way" (as opposed to the traditional authority-oriented approach of teacher-student, driven by grades). Item (2) implies that we don't want students doing work just because they want their grades. We were hoping for honest and authentic motivation. Which, I admit, is probably too naive, but, on the other hand, it is an essential part of open source work: "do it for the joy of coding or because we believe in the importance and relevance of the work, not because our boss told us to do so". In the same way that we know that money is a poor motivator for intellectual work, we think that grades are a poor motivator for authentic learning. </div></div> Our stubbornness with item (2), have actually made more difficult to address item (1). In other words, we could have delivered "a standard experience" in item (1) by forcing students to do uniform homework on a fictitious software project under the "motivating" force of getting their grades. That will solve item (1),... but at the price of betraying the essence of the open-source-way. I think that giving up on item (2) will be a sad way of bringing open source to young minds. E.g. share with the community, because "otherwise you will fail this class". This will become a "dead" sort of open source practice, driven by recipe and attachment to formula and ritual. The students graduating from such class will be weak defenders of the open-source-way. I'll be interested in hearing ideas on how generate authentic motivation in the classroom, and how to steer such motivation into community-oriented activities through which we could teach open source, by "being" open source. I will appreciate your advice, Thanks Luis