Open Source Comes to Campus/Curriculum/Saturday/Project organization

Pre-requisites: ?

Learning objectives: Understand the question of who makes tarballs. Be able to, given an arbitrary project, decide where to send a patch. Be able to contribute to discussions on bug trackers. Understand the patch submission process.

Group discussion


 * Case studies of different open source projects, and their structure
 * Goal: Help you get a sense of how projects evolve, at a high level, and help you have a sense of what size a project is.
 * First example: Subtantial + organic: Apache (a fork!)
 * Second example: Smallish + organic: GNOME-Do
 * Third example: Enormous + inorganic at start: Mozilla
 * Fourth example: Enormous + organic to the core: Debian
 * Fifth example: Tiny, organic: http://sourceforge.net/projects/gstm/


 * Brief discussion of different roles a person / job descriptions that are possible within a project, and what skills they need; preferably painting a picture by using a specific person in a specific project each time. Emphasize different communication media that different people mostly use.
 * Documentation author
 * Artwork contributor
 * Code contributor
 * Code reviewer
 * Bug submitter
 * Security reviewer
 * Bug manager (AKA triager)
 * Security contact
 * Publicity person (e.g., blogger, or release-notes author or conference-goer) http://osdir.com/ml/dev-httpd/1995-03/msg00598.html
 * Release manager
 * User supporter


 * Quick introduction to "normal" (AKA decentralized) VCSs, vs. old-style centralized ones
 * In git and friends, anyone can "commit"
 * Anyone can push their work anywhere
 * Centralized ones are like this but more restricted.


 * What do project maintainers think of small, first-time patches?

Individual work

 * https://openhatch.org/missions/git
 * Examine one of a few amusing bugs (randomly assigned to different students) and explain the bug to the student next to you
 * If you need help understanding the bug, talk to a teacher who will explain it.
 * Examine one snapshotted bug in a project, and explain what further work is needed to push the patch along. (Example: Fx bug where on Windows 7, all the bug needed was someone to fix its coding style https://bugzilla.mozilla.org/show_bug.cgi?id=520943 .)
 * Read https://lkml.org/lkml/2004/12/20/255 for Linus's take
 * Read this bug, in which OpenOffice won't print on Tuesdays: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161
 * Can you explain why, based on the conversation in the bug?

Assessment elements


 * Students make sure the other student's github pull request is right.
 * Optional: Make there be a github training mission.
 * Students explain to one-another what work is required on a bug.

Possible problems



http://groups.google.com/group/comp.infosystems.www.servers.unix/browse_thread/thread/18010e2198b9df45/1c163dc8aa4d442d