I'll be heading to SCALE early tomorrow morning. I had previously been accepted as a speaker last year but couldn't make it due to travel constraints. So I'm even more looking forward to attending the conference. In fact, I'll be talking Saturday afternoon about the experiences we've been having with our POSSE workshop that introduces faculty to open source projects (Saturday, 4:30pm, Bel Air room, details here).

Similarly, I will be giving a short but intense introduction to the workshop itself on Sunday. If you've been trying to get involved in an open source project of your choice but haven't found the right path yet, we'll be there to help. In particular, we'll try to bridge cultural norms that can differ from project to project. If you're interested, swing by (Sunday, 11:30am, Bel Air room, details here).

I'm also very much looking forward to SCALE on a personal level. A lot of my friends and former colleagues are apparently going, so it's going to be good to catch up. That being said, the schedule also looks fabulous and I'll try to make it to some sessions (watch out for #scale10x on Twitter). See you there!

Earlier, word spread quickly that Wikipedia was going to go dark today (January 18), leaving millions of students without access to their favorite research resource. Soon thereafter, rumours surfaced describing ways to "circumvent" the blackout which a variety of websites simulate as part of the ongoing protest against the SOPA and PIPA bills. At opensource.com, Ruth Suehle has been actively capturing website that express their opposition to said bills. So head over there, check out the currently (at the time of writing) 66 screenshots and let us know if there are any other sites you came across: http://opensource.com/life/12/1/january-18-captured-sopa-blackout-gallery

I've recently had the pleasure of watching Senna, The Company Men and Beginners, in less than 48 hours. All of them are good movies, but two of them were particularly well done. Here's why.

Senna

I started out with Senna the night before my flight back home. It's a documentary that portrays, well, Ayrton Senna. The movie maps archive video material from his races and family tapes with audio commentary from his friends, competitors, colleagues and relatives. In the beginning, I was a little sceptica, as I felt the movie was starting a little slow: it introduced Senna as a driver, referred back to his go-karting experience and his Brazilian origin. However, that feeling went away soon enough. Looking back, I'd argue that it's the focus on Senna, the person as a whole, that made the movie appear so very appealing to me. After all, his passion was racing. I didn't find any obvious unnecessary speculations or overstatements in it -- the movie simply told his story. But it did so in a way, that permitted the audience to become emotionally closer to the happenings on the screen. Certainly, there no surprises. The story had been told many times before. But for somebody, like myself, who had been interested in Formula One racing at younger ages (in the times of Michael Schumacher and Mika Häkkinen) but never followed up beyond watching a race every now and then, it was intriguing. The movie provided interesting background knowledge that I was previously unaware of; yet, it also introduced the people I had come across and heard about. Roger Ebert reviewed the movie, giving it a mixed rating. He writes: "Senna is a documentary that does the job it sets out to do. I wish it had tried for more." Yes, maybe it only achieves what it set out to do; but there's only so much to say. The rest is history. And it tells it in the most powerful way I've seen over the past year.

The Company Men

When considered going to the movies over the summer, I was looking at The Company Men. To be very clear: I'm glad I didn't. It's not a bad movie. It's just not a great one. Maybe it was the fact that I watched it in an airport terminal when my Swiss Air Lines flight had been delayed, but I simply wasn't impressed. There've been a couple of movies on the recent recession and its impacts on society (very much in a way Brothers tackles the Iraq War), but The Company Men is certainly the one that convers the topic right head on. Ben Affleck, Chris Cooper and Tommy Lee Jones all work for the fictional company GTX, when the risk of a takeover leads to closure of multiple business lines that affect all three of them. In short, they are layed off one after another. When I watched the trailer, I felt that it wasn't clear that all three of them worked for the same company. I went into the movie expecting a set of episodes of people dealing with suddenly becoming unemployed. And to some extent, that's what the movie does. Yet, it spends too much time on it. Bobby Walker, played by Affleck, is the first to go. And boy, it takes him a long time to accept his new situation. In one of the stronger parts of the movie, he tells his son that he can't drive him. His son leaves obviously disappointed; and so Bobby follows him, encouraging to play Xbox instead. That's when his wife, played by a very strong Rosemarie DeWitt who returns from another major performance in Rachel Getting Married, tells him that his son had returned the Xbox. He didn't feel like they could afford it anymore. And so the movie keeps on going. There are surprisingly few surprises. And the few of them that are, didn't leave me feeling that I cared. The people themselves are somewhat likable, but it's probably that directory Wells didn't spend a whole lot of time introducing me to them; that is, except for letting me watch them deal with their situation. For example, I wish that he took more time to effectively show the conflict between Tommy Lee Jones and his boss, Craig T. Nelson. There's another strong scene in there, when the HR department is going through a list of people to lay off and Gene, represented by Jones, points out that apparently he had falsely assumed that the company was shooting for higher standards than just the question "is it legal?". Again, it's a good movie. And I have to commend it for dealing with a complicated topic. But in this case, I think Roger Ebert's comment on Senna fits much rather: "I wish it had tried for more."

Beginners

Finally, I had the opportunity of watching Beginners on my flight to Zurich. Since it was a red-eye, I was originally planning on sleeping, but I had wanted to watch Beginners for a while, and so I went for it. Beginners tells the story of Oliver, played by Ewan McGregor, who is reflecting on his relationship with his parents (in particular, his dad, who is brilliantly delivered by Christopher Plummer), as well as his girlfriends and his dog. Simply put, it's a film that makes its points so very subtly, making it magnificient. On multiple occasions, I didn't start laughing out loudly. I smiled silently. And it didn't even take much: the simple use of a piece of piano music got me to smile. Think 500 Days of Summer, yet much less hectic, almost in a Woody Allen style. Then again, like aforementioned movie, Beginners isn't a love story. It's so much more. I was amazed by its simplicity. I suggest you check it out.

Yesterday, I went to visit Michael Jonas and Mihaela Sabin, both POSSE alumni, at UNH in Manchester. They are working on getting a seminar series with speakers from a variety of backgrounds going and so I was the first one talking on getting involved in open source communities (see publications).

I find it fascinating to see the differences, both in the student body and the culture at the different schools I've been visiting. UNH was clearly on the smaller side of schools, but it had a very interesting feel to it.

Joanie Diggs was also at the event -- Michael had introduced us when I previously went out for a lunch conversation. After my talk, both of us were given the tour of the school and ended up talking more about different ways of immersing students in open source projects as part of their classroom experience in Michael's office. Watch the TOS list for more!

So this is it. AHSE 2199 assignment number 8. Why my blog post starts with such cryptical numbers? Well, this is a special assignment in the way that I get to choose (to some extent) the deliverable for my Teaching & Learning class. But let's start at the beginning: this semester, I'm taking a class that focuses on undergraduate STEM education as part of my arts, humanities and social studies requirement at Olin. And for this class, I'll even have to create a teaching portfolio as our final deliverable! Aside from that, we've worked on our teaching philosophy statements, exercised a deep-dive into the field of cognition and analyzed several different teaching techniques. And now here we are, looking at student experiences. As you probably figured, these differ from student to student and from class to class.

Now there has been some research conducted on why that is. For example, Linda Nilson portrayed in 1997 in a chapter of her book Teaching at Its Best a number of different frameworks to look at students' learning styles. (Nilson, 1997) One of these frameworks is Kolb's "model of the learning cycle and learning styles", in which he derives a set of styles, called the "accommodator" who relies on concrete experience, the personally and emotionally involved "diverger", the conceptualization-preferring "converger", and the "assimilator" who excels at organization and synthesis. (Kolb, 1984) I won't go into too much more detail explaining each of these, since you can read the paper yourself. However, there shall be one exception: our professor challenged us to identify our preferred learning style -- "preferred" since there are so many factors influencing this and it can be quite hard to narrow it down.

So let's talk about myself for a little bit and put the cards on the table. The description of an assimilator describes that type of learner as somebody who "combine[s] abstract conceptualization and reflective observation into a style that excels at organization and synthesis" as well as the fact that they "specialize in integrating large quantities of data into a concise, logical framework, from [which] they extrapolate theories and generalizations". (Nilson, 1997) So far, so good. But does that really sound like me? Well, I've been doing release engineering since I was 16. Wikipedia describes release engineering as "a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components". (Wikipedia, 2011) Wow, that's a lot of stuff. And to be honest, I do like it. I enjoy being able to pull several complex moving systems together, keep track of their schedule and integrate them all together into a final product. For example, that's what I was doing as the release engineer of Sugar on a Stick that concluded components from Fedora (the operating system layer), Sugar (the desktop environment) and various Activities (the applications that run on top of the learning environment). And guess what? -- Their respective developers weren't necessarily talking to each other!

But that's only one part of my case. Prepare yourself for a shocking revelation! For some inexplicable reason, I also enjoy researching highly-complex travel bookings that require me to pull multiple sets of data together and explore various possible options to hit the cheapest price-tag. While that might sound less exciting compared to release engineering to the average reader, it's something I hadn't noticed before. In a similar, albeit separate vein, assimilators apparently also appreciate "instructor demonstrations and modeling of problem-solving methods" (Nilson, 1997). This comes to no surprise: I personally find well-prepared lectures in which the instructor provides a walk-through for a certain problem just as exciting as project-based team-work approaches. That being said (and to add a grain of salt here), I wouldn't describe myself as a full "assimilator". Nevertheless, It appears to be the style that I can identify with the most, which is why I've decided to not modify that choice following the conversation in class. In the next paragraphs, I'll add a grain of salt, as well as describe my choice of deliverable.

In particular, there are indications that I appreciate problem-solving and particularly cognitive apprenticeship models that enable and support direct interactions with mentors and instructors (who can but don't necessarily have to be the same person). This last point has been especially shaped by some of the readings from my Teaching & Learning class. In my initial teaching philosophy statement, I wrote: "I work towards enabling my students to bridge the classroom and the real world." (Dziallas, 2011) I fostered this belief through personal experiences in the world of software development communities, where strong mentors proved to be an invaluable and incredibly supportive resource to me. One of them later wrote that he had originally assumed that I was a teacher: "he was passionately involved in solving a problem that was important to him". (LinuxQuestions, 2009) This passion is what I believe I need to facilitate for my students. Granted, not everyone is intrinsically motivated, but there are ways of increasing that chance. One of the papers I found tremendously helpful was John Seely Brown's situated cognition and cognitive apprenticeship (Brown, 1989). Taking "Just Plain Folks" (because that's what we all are) and turning them into actual practitioners -- through apprenticeship models -- is something I strongly believe in.

And this brings me to the form of my deliverable: internet access for the masses has enabled the formation of communities that have proven to be incredibly powerful. Clay Shirky argues in his book Cognitive Surplus that we're now learning how to use our free time in more meaningful ways, by communicating and collaborating in an open environment where the simple click on a button labeled "publish" can be enough to make a contribution. (Shirky, 2010) This goes hand in hand with Etienne Wenger's framework of communities of practice that are all around us, in which people share a certain passion or concern and interact on the basis of this belief. (Wenger, 1996) One of the things that enable these communities is the ability to communicate freely, both in public and private channels. And as previously mentioned, this is something that I experienced myself and that shaped my way of learning thoroughly, through my time in the different open source communities. And that's why I'm writing this assignment as a blog post, opening it for the community out there, to take it and comment away!

But before I diverge too much, let's talk about my own classroom experience in college, here at Olin. It's funny; one of the classes I enjoyed the most is Modeling & Simulation in my first semester. The class revolves around mathematical and physical problems, but introduces the student how to abstract unnecessary information away and create a model for a given phenomenon, which can then be converted into an actual simulation using, for example, MATLAB. Do you notice something? It includes conceptualizing complex real-world systems, analyzing them and using the logical framework of computer science to create a deliverable in form of graphs or even papers supporting a certain claim. If you go back a couple of paragraphs, you'll notice that most of these aspects meet the assimilator's learning style. On the other hand, another one of my classes, Design Nature, left me desiring change after the first few weeks. I had a particularly hard time in this class, since there wasn't a lot of scaffolding being provided through my instructor and it dealt with topics I either hadn't seen before or knew I wasn't great at, inducing a sort of anxiety. This was a very open-ended class, walking students through a full design-process -- first individually, then in teams. Later on (especially after the first half of the semester), I learned to appreciate the class though and I do believe that I learned a lot of lessons, both on the design and teamwork side of things.

Elaine Seymour authored an article called "the learning experience in SME majors" in 1997 that provides interesting insights in the perspective college students are taking on their curriculum. For example, a student writes: "In my first engineering class, we were required to do 18 programs and three different languages over the semester. We were given algorithms to use for each program and just one week to complete each of them. [...] We were just expected to know so much that, if someone wasn't willing to explain it to you, then you couldn't do the programs." (Seymour, 1997) This perspective seems to be much more than a single voice -- rather, it represents a pattern of students calling out on so-called weed-out classes that don't necessarily relate to just about anything. Introducing three different programming languages can very well be useful, for example in a course on programming languages that details the differences between each of them. But why would it be, in an entry-level engineering course? Luckily, I didn't have any comparable experiences, but I feel it's very much worth highlighting that a lot of students do. Unnecessarily so.

Another paper by Carroll Seron provides an overview of different student voices at Olin and Smith College, as well as MIT. An Olin student wrote: "The fact that the faculty respects and trusts us is also a big plus. [...] We can work better in groups and learn team work skills this way, which helps when team projects are assigned." (Seron, 2008) This position is obviously contrary to the previous point made. It's something that I appreciate and value as part of the Olin experience, even back when I described it for the first time. (Dziallas, 2009) Being able to interact with faculty and students alike on a level that supports every single member of the community is a strong part in fostering collaboration. When asked to comment on a blog post for the admissions blog at Olin, I wrote: "Yes, go and meet people. They are amazing (it's generally a safe assumption that most people at Olin are amazing [for one reason or another])." (Rowley, 2011) I stand by this statement; however, I realize that it's not always possible at all schools to create an atmosphere similar to the very unique one we have at Olin. But especially in those cases where it's not possible at a school-level, I feel that it's part of the instructors task to provide a framework that students can leverage to create a safe learning environment for each other. Again, this isn't always easy -- particularly when even single courses have the size of Olin's entire student population (we're looking at a number around 350 here). But it's at least worth considering, since every single step can go a long way in making one more student comfortable in the classroom.

This way of improving the academic experience for students is unique, but it's not related to different learning styles. This doesn't mean that they don't need to be considered -- rather the opposite: faculty need to carefully consider their choices of pedagogical techniques and if possible provide alternative frameworks (for example, explicitly pointing out textbooks related to the course, even if purchasing them isn't a requirement). In a similar vein, I believe that interacting with students as often as possible can prevent disappointing experiences. Even if an instructor doesn't meet all learning styles at the same time (which they rarely, if ever, will), showing students that their feedback, opinions and thoughts are valued and considered and that they are taken seriously can help create a satisfying learning experience for all involved parties. And that's probably the one advice I'd give.

Links

• Wikipedia: http://en.wikipedia.org/wiki/Release_engineering
• LinuxQuestions: http://www.linuxquestions.org/questions/interviews-28/interview-with-greg-dek...
• Sebastian Dziallas: http://blog.sdziallas.com/why-i-like-olin
• Brett Rowley: http://brettrowley.blogspot.com/2011/08/5-things-freshmen-should-know-about.html

References

• Nilson, Linda. "Teaching to Different Styles." In Teaching at Its Best, Bolton: Anker Publishing Company, 1997, 79-86.
• Kolb, A. and Kolb, D. "Learning Styles and Learning Spaces." In Academy of Management Learning & Education, 2005, Vol. 4, No. 2, 193- 212.
• Brown, A. S., Collins, A., and Duguid, P. "Situated Cognition and the Culture of Learning." In Educational Researcher, 1989, 18, No. 1, 32-41. 
• Shirky, Clay. "Cognitive Surplus: Creativity and Generosity in a Connected Age" New York: Penguin Press, 2010.
• Wenger, E. et al. "Communities of Practice: Learning, Meaning and Identity." Cambridge: Cambridge University Press, 1998.
• Seymour, E. and Hewitt, N. "The Learning Experience in S.M.E. Majors." In Talking about Leaving: Why Undergraduates Leave the Sciences, Boulder: Westview Press, 1997, 88-177.
• Seron, C. and Silbey, S. "A Day in the Life: Inventing Engineers." Seron and Silbey, American Sociological Association, 2005.

When I spent some time going around North Carolina over the past couple of days visiting POSSE professors, I had a realization: we encourage professors to be productively lost (see here), to go out and feel immersed in a community, admit that they can't solve all of the problems themselves and act more as a facilitator in the classroom that helps identify to ask the right questions in the right place online.

This is admittedly a big step. But there's more to it: it's not just sufficient to be interested in open source in general. There needs to be some tangible goal. Participating in open source communities, as Greg puts it, needs to be rewarding. And here's the interesting part: I have come to believe that this applies to the students ("participating in open source communities means that your work will be publicly available, so you can point future employers to it") as well as to the instructor.

Think about Heidi Ellis and Matt Jadud. Heidi has been working on the HFOSS -- the H stands for humanitarian. Her students have been successfully contributing to Caribou, the GNOME onscreen keyboard and are now on-track looking at Cheese and others. Matt spent time introducing students to a variety of parts of the Fedora project. For his interface design class, he called out for projects in a blog post, which was picked up by Mo just a day later.

We have seen many successful contributions through classrooms to open source projects like these. But one thing the instructors had in common was that they were excited about the prospect of having students contribute to this or that project. Mel made an interesting analogy just now: "you don't see you're interested in 'learning languages' -- you're learning one specific language".

So, I'm curious: what are the projects you've been looking at -- and why? Is there something we can do to help? Let us know!

Through my visits to POSSE professors over the past couple of days I realized that one thing that is undeniably helpful is a variety of suggestions for open source related assignments. Lucky, that we worked on creating precisely something like that at an NSF-sponsored workshop at Western New England University in Springfield back in May. Clif Kussmaul suggested a project along the lines of 50 Ways to be a FOSSer. So if you're for some inspiration on how to put your students to work in open source communities, check it out: http://xcitegroup.org/softhum/doku.php?id=f:50ways

And make sure to send suggestions to the TOS mailing list!

In a similar vein as my previous post, this one relates to the second half of my trip to North Carolina, where I visited POSSE cohort members Richard Ilson and Rajeev Agrawal. So I'm writing this from the Red Hat office in Raleigh, where I'll be working from for the rest of the day after a notoriously early wake-up to return my rental car.

Anyway. Yesterday, I spent the morning chatting with Greg and then drove off in the afternoon to Greensboro to visit Rajeev's class at NCAT and teach a little workshop. To my surprise, they had already looked at open source communities and done a little dive-in as part of their homework assignments which was actually based on some of the Teaching Open Source materials! I decided to challenge them to think about projects they actually cared about getting involved in more and gave some examples why that could be useful, even outside the classroom.

Later that day, Rajeev and I talked about infrastructure. He's having his students blog regularly, and so he's interested in using a planet for his class. I can vaguely remember that there are different versions of planets in Fedora, but the one I recall is planetplanet. Is that a good enough choice to run with? Does anybody have straight-forward installation & setup instructions that we could pass on to his IT department?

This is the first part of a series of posts recounting experiences from visiting faculty throughout the semester. Right now, I'm sitting in Peet's coffee shop in the library of UNC Charlotte. I took a 5am flight this morning from Boston down here and made it almost perfectly in time for Richard Ilson's software engineering class, where I proceeded to talk about my experiences as a release engineer in open source communities. Put differently, I gave a talk that resembled the one that I previously gave at LinuxCon 2010 (slides) and spend the rest of the class doing Q & A. Some of the students had even heard of OLPC and Sugar on a Stick! I tried to articulate steps to get involved in open source communities and will give a similar presentation in about an hour for the second section of Richard's class. Afterwards, we'll spend some time chatting about possibilities and ways to immerse his (somewhat large class; overall his two sections have about 80 students) in open source projects. That's it for now, more tomorrow.

Now that we're almost half-way into the semester, I think it's time for some oberservations. But first, where are we now? As I previously said, we worked on packaging io and got it in fact to compile. I sent my students off asking them to finish packaging; not without a warning that the process of getting everything into shape can be quite time-consuming.

However, I found an email to the class mailing list saying that they were done. I was impressed. Today, we had the first meeting since, where we talked about a questions they had with regard to the .spec file.

Well, the obvious next step is to submit the package for review in Fedora. And while I'll be at FIE next week, it's their task to work through the review process and identify a community they would be interested in getting involved in themselves. So consider this a little call for reviewers (actually, sponsors) on my part.

Lastly, I said there were going to be observations, right? Well, I find it really interesting how to work with people of different knowledge levels. And surprisingly, this is not only the case in large classes, but also in very small ones. As previously mentioned, I have three students who all come with different preconceptions and previous experiences. I'd like them to work together locally, as well as interact with the community.

Hence, I didn't want them to be working by themselves. But I was also trying to find a way of putting everyone on fair standing when it came to contributing to an assignment. So for packaging io, I decided they would start out in class and finish after class (they met in person for that). But the most important part was that they would start pondering the spec file in etherpad, which enabled them to work on the same goal while addressing different parts that would still be visible to everybody.