From Teaching Open Source

< RIT

Contents 1 14 August 2009 Workshop notes 1.1 Participants 1.2 Background self evaluation 1.3 FOSS people, practices, & tools 1.4 Expectations 1.5 Mel's thoughts, mostly 2 Potential laboratory exercises

As part of our Boston, Massachusetts field trip we were invited to the Red Hat offices.

Thanks to Karlie and Luke Macken and Mel Chua at Red Hat, we were able to work on ideas for improving the introduction of new students to FOSS communities and vice versa.

[edit] 14 August 2009 Workshop notes

Westford, Massachusetts

[edit] Participants

• Eric Mallon, Sugar Summer Program Co-op,
• G. Tyler Bragdon, Sugar Summer Program Co-op,
• Wesley Dillingham, Sugar Summer Program Co-op.
• Adam Holt, Community Support leader at OLPC,
• Stefan Unterhauser, Volunteer Infrastructure Group leader for OLPC/Sugar,
• Mel Chua, Community intern at Red Hat,
• Karlie Robinson, Sugar Summer Program Steering Team,
• Frederick Grose, Sugar Summer Program Co-op supervisor,
• David Farning, Sugar Labs,

[edit] Background self evaluation

On the opening night of our field trip we held a serious review of our FOSS experiences.

Mel captured notes for 5 ideas to pursue: (reordered below)

1. Rapid initial exposure to FOSS tools and practices,
2. Enough exposure time working within the community with guidance so that one can continue independently outside of class,
3. Apprenticeships with existing project contributors as a more structured way of developing classroom↔community engagement,
4. Clear Expectations (and evaluation criteria),
5. Dedicated environment to nurture social learning.

We organized ourselves to workup concrete ideas for items 1 to 4.

[edit] FOSS people, practices, & tools

The honors seminar was hoping to take advantage of FOSS community members to deliver exposure to our people, practices, and tools during out-of-classroom hours, which the students were to supposed to commit to for the seminar. Our community failed to sufficiently prime the pump for that to happen to any significant extent.

Seizing on our new, face-to-face relationships in Boston, we negotiated and began to execute some plans to offer en plein air sessions with the OLPC - Sugar community.

1. An instructors' assistant, acting as intermediary, would negotiate with a collaborating community team leader to promote active lurking during selected, standing, team meetings (usually on IRC).
   • Assistant would notify team leader and schedule a handful of students to be active lurkers
   • Team overviews, FAQs, and meeting agenda would be distributed
   • Team leader might acknowledge the student lurkers and drop extra beginner task ideas into the discussion for the students.
   • Assistant would monitor discussion and help decode advanced terms and uncommon lingo online or in a side channel in IRC.
   • Students would see real FOSS work en plein air.
   • A large class might be broken into separate sessions of 4 to 6 student lurkers.
   • Students would learn about the teams projects and work style and have the opportunity to participate.
2. We practiced this idea with Adam Holt <CanoeBerry> and the OLPC Contributors Program weekly project review meeting that day at 2 pm.
3. On 18 August 2009, <FGrose> and <wwdillingham> joined <dogi> Stefan Unterhauser in the Volunteer Infrastructure Group meeting.
4. The Sugar Labs BugSquad has a great set of tools to accelerate a new contributor into an active participant.
   • In our work earlier in the week, David Farning pushed our Co-ops to enter bug reports for problems that we encountered, and noted how the community was rallied to sort and resolve the issues.
5. As we negotiate new, assistant↔team leader partnerships, more community meetings can be subject to this sort of infiltration by active lurkers.
6. Subsequent to our workshop, David Farning has proposed a laboratory exercise on smoke testing with a first concrete assignment.
7. Stefan suggested that everyone getting a new XO laptop or Live USB system spend a laboratory session learning how to destroy and restore the operating system.
   • It is important that students lose any fear of damaging a system while experimenting with it.
   • Technical prowess grows from practice that may need to be encouraged with loaner hardware.
8. More ideas for learning FOSS tools are described in the section below.

[edit] Expectations

Mostly raw ideas captured from the whiteboard:

1. Your expectations for what you'll have learned:
   • Open source process,
   • Some Python,
   • How to interact in person and remotely using irc, git, wiki,
   • I expected minimal instruction of pygame + Scratch,
   • How to work in open source projects
2. How you'll know
   • Actual graded feedback of things turned in,
   • I can demonstrate ideas / concept to another person
   • Enough knowledge of Python to work on final game.
   • Ability to talk with community using git, wikis, irc, etc.
3. The most helpful things you learned that weren't planned.
   • Useful contacts,
   • How to let go of the notion that there is a clearly defined goal or endpoint for the project,
   • Joining / following a mailing list,
   • Stuff with GIMP
4. Gripes
   • lack of anything for 3 ??
   • no clear goal,
   • too wiki-focused,
   • There was no time given to critiquing other group's ideas,
   • No formal, anonymous, feedback method to present to the professor during and after the class,
   • By the nature of a class in which the student receives a letter grade from the lecturer, attempting to deviate from what the professor wants produced can be daunting. Perhaps, independent, third-party or consensus grading would be constructive.
   • No Idea what final grade was until I got report card,
   • The limited class time was not used most effectively.

This resulted in the following suggestions for course laboratory elements:

1. PYTHON: More conventional project, “make x.py output $foo”
2. PYGAME: “ “
3. “How to work in OSS” quiz
4. A set-up get repository with 1st commit
5. Wiki userpage IRC lab
6. Blogs on planet (make sure students can speak freely)
7. Install and go through a tutorial program of your choice,
8. Forward a message you posted on list to professor.

[edit] Mel's thoughts, mostly

(from the whiteboard)

As an OSS community member...

1. I'll have learned the amount of effort and guidance to expect for a student I'm mentoring.
2. I can block out a work or meeting milestone schedule for the next term.
3. You need direct exposure to experts in order to watch + grow.
   • code reviews - what feedback to ask for?
   • creating a patch
4. Mentors may not have clear expectations of their students
   • May lack checkpoints to adjust original goals.
   • May set overly ambitious goals due to lack of context.
   • It may be unclear what mentors get out of it.
   • Activities may not match up with my project goals.
5. We need to understand "Who are these students?"
   • What are their passions and skills?
   • How can we help them grow and contribute?
   • What are they learning from my behavior?

[edit] Potential laboratory exercises

(In or outside of class hours)

1. IRC/Wiki first day – good icebreaker as well as teaching irc/wiki. Every student makes their own Wiki userpage, but cannot edit it. They then join an IRC channel and convince others to edit for them.
2. Teaching the git repository to students – first, an instructor shows how to create a repository, set up SSH key on site, etc. Project where someone starts a story or webpage, then each student clones and adds to the story/page.
3. Tic Tac Toe in pygame – create a simple tic tac toe app in the python/pygame.
4. Blog – each student creates and writes on a blog, can be used to communicate about the class, submit certain assignments, and give feedback.
5. Find an open source program that interests you; follow a tutorial; make something; and submit it.
6. Find an open source program, and fix a bug in their ticket system.
7. Join a mailing list and forward a message on it to the professor to show that you have joined. Or join a mailing list and send personal introduction (more then just a "hi").
8. Participate in a community book sprint like Class Acts for OLPC - Sugar deployment
9. Active lurking, as described above, in community meetings
10. Smoke testing hardware and software. (this has made it to week 1 in the syllabus)
11. Wireless networking.