Congratulations to Andrea Hickerson of RIT and Karl Wurst of Worcester State University, who joined the ranks of our 2011 POSSE cohort this week (http://teachingopensource.org/index.php/POSSE_2011_applicants#Accepted) - we're looking forward to seeing you in Raleigh this July, Andrea and Karl!
If you haven't yet applied for this summer's cohort, check out the application at http://teachingopensource.org/index.php/POSSE#Apply - we now have 10 seats left. (If you plan on applying but haven't finished your application yet, please let me know - I'm more than happy to talk with folks about their applications, and so forth.) We have two new applications finished and available for review at http://teachingopensource.org/index.php/POSSE_2011_applicants#Open_for_community_review - Mihaela Sabin from the University of New Hampshire and Rajeev Agrawal from North Carolina A & T State University. My comments are below - would love to hear thoughts from others as well. Mihaela Sabin (http://teachingopensource.org/index.php/POSSE_2011_applicants#Mihaela_Sabin): * When is the course being taught? (Fall? Spring? Both?) Would be good to know. :) * It's nice to note that the broader program that Mihaela's teaching her class within is designed based on the ACM Information Technology Model Curriculum - might be worth figuring out what parts of that curriculum the FOSS-ification of this class addresses well. * Fascinating student body - a lot of older commuters working full-time. This could be a challenge because there's going to be a lot of time constraints on students that may make it harder to ramp them up into new tools and a new culture, but once they do, messy real-world applications are where FOSS practices make a huge difference; you can hardly do distributed collaboration without being conscious of "release early release often" pushing, constant communication, and so forth - these students are likely to appreciate the dramatically fast results that FOSS communities can generate. It sounds like the thrust of the course is having students use FOSS to create and deploy dynamic web applications. There seems to be a focus on working for an actual customer - whether that's an internal meta-goal in creating and maintaining the school's infrastructure for open source participation (a nice dogfooding opportunity) or an external service learning goal with local partners. I wonder if there's a nice opportunity here to kill two birds with one stone - if the class picks *one* piece of infrastructure that a number of TOS schools would love to see improved, implements fixes on it that will specifically make that piece of software (Trac? Mediawiki? etc?) much easier for schools, students, and classes easier to use and deploy, tries it out themselves, and then turns around and (probably the following semester or school year) works with UNH's IT department to deploy it for other classes, and possibly other local TOS professors to deploy it experimentally in theirs... you've got a development project working with a major FOSS upstream to serve local consumers of that project's software. Karl's Software Development class and Kristina's NLP class (among others, I'm sure) are running during the spring semester, both not too far from UNH (decent roadtrip or let's-all-meet-at-a-local-conference distance). Possibly an ambitious target here that will take a couple more years than I'm thinking, but that's one possible Big Awesome Milestone. Also, I think this is the first time I've seen specific requests for a POSSE to address source business models and commercialization around open source class projects - I'll have to think about who from Red Hat to pull in on that (it may have to be a follow-up session, depending on how much time we have). This is *probably* not going to come to full fruition by Summer 2012 - it takes a while to build an ecosystem - but it's a great ambitious goal to work towards. I'd like to hear some thoughts/suggestions on more concrete projects this class could do - I'm trying to envision where they're going to fit within the TOS ecosystem and it's still a little fuzzy to me - but I'm inclined to say that if we get that sort of feedback and discussion this week, this should be a +1 yes. There's definitely potential we can tap here. Rajeev Agrawal (http://teachingopensource.org/index.php/POSSE_2011_applicants#Rajeev_Agrawal): This is a great conversation-starter; I've got a bunch of questions on this one and would like to work with Rajeev to flesh it out more so we get an idea of what he's thinking about in terms of applying FOSS community participation and "the open source way" to his class. Let me try to bring out a few key points... I believe this is the first graduate class we've had at a POSSE, which is great - I think it'll work out just fine, since "project management" tends to fit nicely into learning-FOSS regardless of the level of the students involved - though I'd like clarification on what "appropriate to 700-level" means. What are the expectations in regards to difficulty, speed, etc. of material for that (as compared to an undergraduate class, perhaps a senior capstone or senior-level release engineering course?) Is the difference that they'll already "know programming, databases and have exposure to Unix/Linux" - or is there something else? (Pardon my ignorance here; I'm not familiar with the differences between designing an undergraduate and graduate level course.) "This is currently taught online using Blackboard" - does that mean the entire course is taught online (i.e. no classroom meetings), or does it meet in person, with Blackboard as a hub for materials? Either way, I'm a little concerned about Blackboard and how the data sharing for this class is set up - will open source community members and guests be able to see the class's discussions, schedule, student work (the rough, messy, raw, ongoing stuff - not just the finished products, when it's too late for us to help much) and all the things we'll need to actually be able to give the class a hand? I don't feel like I have a strong vision for what the goals of incorporating open source into this class are yet - and that's okay, because the entire design of this application process is structured so we can *start* these conversations and help professors figure out what sorts of options might exist for where they'd like to go. So thank you, Rajeev, for being bold enough to step out and open up your class and your ideas to us - let's see if we can get more specific than "using open source project management... concepts" by Summer 2012. Let's take a look at what some of the other successful applicants have envisioned for their classes by the end of the school year: * Students habitually using version control for all their projects, even after the course ends and they're not required to * More non-majors taking CS electives, attracted by the energy of the course and the stories of their friends * Students started an open source club so peer mentoring can happen outside of class * A school-wide blog planet keeping a pulse on FOSS development on campus (see http://zenit.senecac.on.ca/~chris.tyler/planet/ and http://foss.rit.edu/planet/ for examples) * Students putting together a computer kiosk in the hallway to showcase their projects * Students volunteering for local community organizations to solve their problems with their FOSS skills * Course materials being tested by faculty teaching NLP at other schools What sorts of concrete outcomes can you see resulting from your students' participation in FOSS, Rajeev? (TOS folks, help with brainstoming here would be awesome.) Some thoughts to get you started (most around Fedora, since that's where I hang out): * Students cleaned up and improved all 20 accepted feature proposals for the Fedora 16 release, including helping multiple software engineering classes of other TOS professors to ready their feature documentation for acceptance (all got in). * Students created a dependency chart for GNOME's major upstreams and downstreams, then reached out to all these upstream and downstream communties to see how it could be made easier to keep track of GNOME's changes, schedule slips, and so forth - this outreach was featured in the latest GNOME Journal. * Students coordinated Fedora's presence at POSSCON 2012 - handling resource management, material creation and volunteer scheduling, figuring out shipping logistics, funding, collaboration and cost-sharing with other booths at the event... all without meeting a single one of their collaborators in person prior to the event, thanks to the skilled setup and usage of distributed collaboration tools. The processes they set up and the software tools they used and tweaked to support this event deployment were so successful that other Ambassador groups have since adopted them for conferences around the world... One thing that may be a tough compromise to make is just sheer time tradeoffs. You mentioned that this is currently a "theoretical course based on PMBOK guide of Project Management institute" - which is awesome. The class already fills the entire semester with theoretical material, and I bet the PMBOK is thick enough that there's *still* stuff you don't get to cover even with that. Now, other profs here on the TOS list might have ideas on how to deal with this, but I think that if you're going to introduce FOSS project participation as a big part of this class... that's going to take a lot of time, and it's got to come from somewhere. What's going to get cut? This is a pretty big shift - FOSS or not, introducing real-world projects into a currently 100% theoretical class is a huge exciting deal, and I'd love to hear more about the sort of time breakdown, weekly class cycle, evaluation methods, etc. you're thinking about to make the new format work. Probably a good question to start with is the one ME Jones brought up at SIGCSE - what are your course objectives? Do you want to... * Teach students a given number of theoretical concepts and test their book-knowledge of these concepts at the end - FOSS participation makes it more likely they'll be able to memorize all the theory * Give students a successful project completion experience ("we started out with goals and met them") - which might mean a much more scaffolded and simplified project to make sure they don't get hit with overwhelmingness or deadline panic? * Give students the experience of deadline panic, schedule slippage, ambiguous specs, etc. - knowing that this sort of "failure" is educational but also painful and unpredictable... and better experienced in school than on the job? Here, theoretical concepts might be applicable as ways to *understand* the real-world mess that's happening - "why was this meeting a struggle while the last one ran so well, why was this gantt chart not useful, why did this feature spec's clarity help these engineers complete it twice as fast?" Let's start from there and see where we can get. :) _______________________________________________ tos mailing list tos@teachingopensource.org http://teachingopensource.org/mailman/listinfo/tos
