Hi Mel, On Fri, Apr 23, 2010 at 09:18, Mel Chua <[email protected]> wrote: > It means we have a lot of work to do in terms of finding Activities in an > appropriate stage (and getting them there), and making sure people from > Sugar Labs will be around to help on various kinds of tasks that week (and > that it's clear who to ask for what kind of help). But a lot of this will be > happening in any case for SoaS development; POSSE just encourages it to > happen faster, and makes sure that new resources get tested before POSSE > starts. > > Does that make more sense / address your concerns? I definitely want to make > sure we design the curriculum with a reasonable scope.
I guess so. The activities we did were 1. Common across all participants, meaning 2. We could help each-other, 3. They were of known scope (there was a known solution in advance that the instructors could help us with), 4. We could, as a group, talk about the process itself as we figured it out, and 5. We could, as a group, then relate that concrete activity to teaching/learning/etc in our contexts. With your activities, they will not be common across participants (meaning we'll have no common context), meaning we can't easily help each-other without learning about the new problem (although pairs may help with this), you might not know the scope of the problems (not having solutions in hand), we might not be able to discuss common practice, and we will then be trying to establish what of each different exercise was transferable to our specific institutional context. I'm not saying that this is a bad idea; I'm just pointing out that the curriculum for the first POSSE had very clear exercises of known scope with clear solutions. It clearly demonstrated to me, as a member of the faculty, that I could (in just a few hours) check out a million+ line codebase, edit it, build it, and see my changes. It also demonstrated packaging, which let me see that there is low-hanging fruit that students can get involved in (likewise with our exploration of bug tracking, which we didn't actually engage in so much as have a discussion about). The take-away was that there were things we could do that got our students into the periphery of the projects. Further, the workshop instructors were 100% certain their activities would "just work." (Or, nearly so -- Dave, for example, wasn't worried about us encountering anything too wacky in building Firefox, especially since most of the instructions involved copy-pasting commands into a terminal. Likewise with Chris/Ian being able to field any question we had about packaging.) If I instead had an experience where I spent two days not achieving anything in a project, I'd be unhappy, and have felt 1. that it was a waste of my time, and 2. that there was no way I'd do these kinds of things with my students. So, I would suggest this: 1. Do just *one* project from Sugar. 2. Script the entire thing. Have it solved in advance. It is OK if there is a "gotcha," but you had best discover it in advance so that you can help the participants. 2b. Involve the community if you like/if the timing really will work out well, but that becomes a big point of possible failure given your tight timeframe. 3. Have clear points of reflection that you want to discuss afterwards, either about the mechanics, the process, or otherwise. Debriefing is where the exciting thinking happens. 4. Have clear paths for further exploration from the project you engaged in: for example, where can more bugs like this be found?, what make good student projects in this space?, and so on. The goal, in my opinion, shouldn't be to have lots of meaningful contributions to SoaS. It should be to introduce the faculty to the process and that it can be done successfully, even in a small amount of time. Failure (on their part) in this context will not be a good sell. (Basically, if I can't figure a tool/process/problem out quickly, I worry about how long it will take 30 students, etc.) Keep pushing back. I personally would make my mantra "CONSTRAIN CONSTRAIN CONSTRAIN," so that your participants can engage quickly, be successful, and then figure out how these things fit into their institutional/educational context. Cheers, Matt _______________________________________________ tos mailing list [email protected] http://teachingopensource.org/mailman/listinfo/tos
