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

From OpenHatch wiki
< Open Source Comes to Campus‎ | Curriculum‎ | Saturday
Revision as of 17:05, 24 February 2012 by imported>Paulproteus

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
    • Second example: Smallish + organic: GNOME-Do
    • Third example: Enormous + inorganic at start: Mozilla
    • Fourth example: Enormous + organic to the core: Debian
  • 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
    • 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)
    • Release manager
    • User supporter
  • 5 min: Explain "forking", both hostile and non-hostile
  • 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.

Individual work

  • Have students take some simple-ish code project and modify it to work differently, perhaps with just adding their name to AUTHORS, and push their modded version to Github and submit a pull request.
  • 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.)

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

  • ?
Retrieved from "https://wiki.openhatch.org/wiki/Open_Source_Comes_to_Campus/Curriculum/Saturday/Project_organization?oldid=9190"