[TOS] FW: TOS speaker on issue tracker

Wed Feb 22 13:39:48 UTC 2012

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 <mihaela.sabin at unh.edu> 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: tos-bounces at teachingopensource.org [mailto:tos-bounces at teachingopensource.org] On Behalf Of Mel Chua
> Sent: Saturday, February 18, 2012 11:51 PM
> To: tos at teachingopensource.org
> 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
> tos at teachingopensource.org
> http://lists.teachingopensource.org/mailman/listinfo/tos
> _______________________________________________
> tos mailing list
> tos at teachingopensource.org
> http://lists.teachingopensource.org/mailman/listinfo/tos