Hi Mihaela, I go through this often. What follows is *not* meant to be harsh, but it is how I distill these thoughts in my own head. And, I talk to myself a lot, so I have been round-and-round this loop a few times. Last time, I won the argument, which was a refreshing change.
(o_0) Humor aside, I go through these thoughts a lot, and I often hear my own fear of change talking back to me. It's hard to overcome/dive in. Here are some ideas, most of which I suspect you already know. The reality: this next offering of the course may not be the right one for this kind of "deep dive." On Wed, Feb 22, 2012 at 07:49, Sabin, Mihaela <[email protected]> wrote: > The choice between stitching together a system without using a development > framework is, primarily, dictated by my lack of familiarity with the > framework. Read: This is safe, for me, as an educator. > Learning outcomes are the same in both cases, plain PHP/MySQL vs Drupal-based > coding. The nature of the activities does not change. Students assume the > same roles, the team has a place for everybody, weekly dynamics in and > outside class unfold in the same way. Read: This looks like everything I know and the students know. Everyone is doing the same thing, everyone is structured in the same groups, and I can claim that I am evaluating something consistently across the classroom. > What's different is that the non-framework version allows me to plan better > the class at the beginning of the semester. Since this is the development I'm > most familiar, it's clearer to me what activities and artifacts to expect > from students and how they fit on the semester's timeline. Read: I've done it my way before, but this looks new. > Last point and the most important. Added to my lack of familiarity is the > students' lack of time and limited self-directedness. Being productively lost > is something that makes them very anxious, and widens the gap between what > they do and what they think they can do. Being productively lost is probably > the most divisive value between my students and me. I would happily delve > into something (No more reading.) Student time management is hard to handle. It requires *more* structure on your part. This is not, however, necessarily antithetical to FOSS participation. In fact, as we've learned, FOSS communities have more, not less structure. They require more, not less, communication. A traditional classroom, organized in a traditional way, can get away with a single page syllabus at the start of the term and start rolling. A FOSS community must check in weekly/monthly, update blogs, tweet, etc. to keep the team/community cohesive. So, one approach to student time management is to make it more explicit and an assessable part of the work. "Are you maintaining a complete log of your time? Did you spend at least 2 hours working with a partner this week? Did you both sign that? Remember, we had an honor pledge that we signed at the start of the term." This is closer to a real-world work experience, in some ways---not the most glorious, but you can encourage them to be explicit and take responsibility for time management, and report how they do. "Productively lost" can be managed, too. > totally new and figure out my way as I go. That approach, however, does not > set a role model that's productive and conducive of learning for my students. > It is the kind of disruption one wants in the classroom because it's > innovative. And I very much like to understand how I'll make it work someday. Don't assess the code, assess the process. Don't assign project-based deliverables, assign deliverables that support the project. For example, require students to write a weekly blog post that details the following: 1. What did you set out to do this week? 2. What did you learn this week? 3. Teach us something.* 4. What are you doing next week. You can have a standard template for the first and last elements. For #1, It could be a small HTML table that has columns for "Task" and "Time." They shouldn't provide a micro-summary, because you as their "manager" don't care about the tiny details. But, they should be able to account for how they spent their time. For #4, it could also be a table, and they could project what they want to do and how long they think it will take. What research/learning is necessary to support the task? Do they expect success, or is this an incremental week? #3 is the clincher. They should write a post that, if a new person coming to the project reads it, they will learn something. Their posts, to receive "A"s, should prepare future contributors. This is hard to do, but they can do it. This semester I'm running "Collaboratory Studio," a group independent study in making. (I don't have a better way to put it.) I basically threw the doors open to my lab and said "Do something cool with your friends." The writing requirements on a week-to-week basis are like those above: http://make.ivism.org/ This is a 1/4 or 1/2 credit opportunity, and is a pilot. Perhaps there should be more "rigor." That said, I've asked student to drop who weren't putting in the time and effort, largely because it showed in their weekly writing. So far, I'm very pleased/proud with the effort. Likewise, I think focusing on grading process is the way to go: 1. Did you triage a bug report, and do it well? Here are examples of "A" triage reports. 2. Did you find and submit a bug? Did you do it well? Here are the grading criteria. Submit a 1-page reflection on the process you went through---what was most challenging? What surprised you most? 3. Did you generate a patch? Your patch should be documented in this week's blog post. As an entire class, you are collaborating to produce the "Busy Student's Guide to Patching," and it should be posted on the wiki. Use Google Docs to write the guide, and share that guide with me---I want to see the edit history, and will be looking to see what contributions each of you made. But, yes, it is easy to suggest these ideas from afar. And, some students might not come out with the "facts" that you would traditionally expect. But, they'll come out with far more process and context for what they learn. Cheers, M > > Mihaela > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Mel Chua > Sent: Saturday, February 18, 2012 11:51 PM > To: [email protected] > Subject: Re: [TOS] TOS speaker on issue tracker > >> The project is a client-based open source application to manage >> donations for non-profits. We use MySQL and PHP. YWCA New Hampshire >> and Greater Manchester Big Brothers Big Sisters are the "clients". >> Only YWCA has time this semester to meet with the students. > > Update on this -- sounds like Mihaela has a speaker, Donald Lobo (who's since > contacted her for logistics) from the CiviCRM community. Lobo also made the > following note, which struck me (and I asked him for permission to repost it > here, and he agreed.) > > Lobo: "I would strongly encourage you to consider using and building on an > existing open source project rather than getting your students to develop a > system from scratch and deploy it with a non-profit. This has quite a few > issues with it, potentially. There are lots of things [in] drupal/civicrm > that your students can build on and extend." > > My first instinct is to agree with Lobo, but I'm coming to realize that not > all faculty feel like they can go this route with their classes... > and I'd like to better understand why. Is there not enough time in the > semester to go into a project? Are there certain learning objectives that > really don't work with open source participation? > > Curious Mel! > > --Mel > _______________________________________________ > tos mailing list > [email protected] > http://lists.teachingopensource.org/mailman/listinfo/tos > _______________________________________________ > tos mailing list > [email protected] > http://lists.teachingopensource.org/mailman/listinfo/tos _______________________________________________ tos mailing list [email protected] http://lists.teachingopensource.org/mailman/listinfo/tos
