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?