+1 to Mel's call that POSSE ROI, Cause and Effect formulas need to be determined as well as a clear set of expectations for what happens after a POSSE. IMHO this is a good old hockey stick shaped geometric curve kinda thing. Curricular process of some sort needs to be factored in along the lines of POSSE + 6-12 = a seminar elective course attended by a small number of students and if that is successful seminar course + 6-12 months = formal course proposal and formal course on the books that may get 20-30 students in. Once successful another course is added etc,etc, etc. Greg and Heidi, Faculty Materials on what and to what end? +1 to Max about core. Below is a response I sent to the "Can Haz" discussion that either died somewhere in the e-mail system or I missed it being posted. Much of it discussed core and variation along Max's point so I've pasted it in below. I'm also sending this via two different email addresses so I can see which one actually hits. +1 to Mel and Sebastian on "cultural indoctrination," something that is echoed somewhat in the longer piece below. _______________________________________ So, in my pov, Karlie and everyone else is right. To a certain extent anyway.It comes down to the goals and purpose of POSSE. What are the outcomes? What do we want the POSSE grad to look like/be able to do? This is important because it addresses the points Karlie brings up. It also brings up a common tension in technical education, or any education really. If I want every POSSE grad to be able to install and configure stuff on their own? Is that a goal? If so where does it come into the curriculum? Do I want to risk sacrificing some other learning (in my compressed 4.5 days) I'm going to put forward by emphasizing hand building stuff they can get by starting projects on Fedora hosted? Or by asking their technology support staff to do it for them before they start class so they can spend their time working with their students on development? These questions become more crucial as we look at these "one day posse" kinds of things that I've been seeing Karsten e-mail about. So here's my take as someone who teaches some TOS courses and has been through a POSSE. POSSE is first and foremost about indoctrination, process and modeling community tools and behavior. It should teach only as much technology as it needs to support these goals. It caters (in the most part) to either people who are already well versed in computing and technology in general or who are non-technologists interested in learning about open source to teach about/become contributors in other skill areas. In the POSSE I attended this was generally the case. There was a core dump of the different tools, (wikis, blogs, trace, etc) This was appropriate (though I did have suggestions for pacing the introduction of each tool, account and use rather than the blitzkrieg batch we got ;-> ) I think this is right and still needs to be the first three days. I think, at that point, you have choices that should be dictated by the session and the audience. Got a ton of CS profs who've been doing Unix since it was written and want to offer a class that's gonna teach those skills? Rock on, though those guys are likely to be able to figure it out own their own. Wanna spend the last day and a half on fixing bugs in something because you've got the profs who can do it? Excellent. Gotta bunch of liberal arts and English profs interested in Open Source because of Open Tools and Open content? Do something else. Really, it goes back to the curricular goals for POSSE and the fact that eventually there will be many flavors. I believe (and we're already seeing) that POSSE is going to evolve into a brand (and maybe loose and "S" to become Professors Open Source Experience) that does the following... 1. First and foremost introduces professors to what Open Source is, what it does, how people work in it and how to get started by giving them Dave's community assignment and teaches them how to blog and wiki. (Day 1 of a long POSSE or the POSE one day introductory workshop for conferences) 2. Second, has them working with GIT, Trac etc (or equivalents, maybe the college or conference is big on subversion) Day two of a long POSSE or the foundation for the POSE workshop "Open Source, moving from the sidelines to the playing field." etc, etc etc. There's this model from the game industry, Miyamoto's pyramid. I actually use it for just about everything cuz it works so well. It speaks to modular development. A lousy, Jacobs generated attached. The idea is that the top triangle and the column beneath it represents the core gameplay/functionality/content of what you produce. You get the the triangle core right first (and continuously refine it as the other parts get developed when appropriate) and then start adding the secondary level down. then the third, then the fourth. So, that at anytime you have to stop, the core gameplay and content and those most closely related are always the best they can be. If there was a master POSSE curriculum that was designed this way, with daily modules in mind, then it's easier to peel one-day workshops off that meet the needs of the audience and replace the bottom row/final day or two of teaching to differentiate content for your audience. There are other models and visuals of course, Shrek says Ogres have Layers :-) In some ways this is emerging organically and some of us are thinking about this. Working of a model like this can help address the shorter posses and the content issues Karlie brings up. Hope this helps |
pyramid.odg
Description: application/vnd.oasis.opendocument.graphics
Stephen Jacobs Associate Professor, Interactive Games and Media DIrector, Lab for Technological Literacy Visiting Scholar,International Center for the History of Electronic Games Rochester Institute of Technology What follows is a required public service announcement from my university ;-)152 Lomb Memorial Drive Bldg 70 Rochester, NY 14623 s...@mail.rit.edu 585-475-7803 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information. On Jan 12, 2011, at 8:26 AM, <tos-requ...@teachingopensource.org> <tos-requ...@teachingopensource.org> wrote: [TOS] Infrastructure Team: Can haz? |
DIrector, Lab for Technological Literacy Visiting Scholar,International Center for the History of Electronic Games Rochester Institute of Technology 152 Lomb Memorial Drive Bldg 70 Rochester, NY 14623 itprofjac...@gmail.com 585-475-7803 |
_______________________________________________ tos mailing list tos@teachingopensource.org http://teachingopensource.org/mailman/listinfo/tos
