Open Source Comes to Campus/Curriculum/Saturday: Difference between revisions
Content added Content deleted
imported>Paulproteus |
imported>Paulproteus |
||
| Line 19: | Line 19: | ||
== Project organization (bug trackers; git format-patch; github; people's roles in a project) == |
== Project organization (bug trackers; git format-patch; github; people's roles in a project) == |
||
* [[/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. |
|||
'''Group discussion''' |
|||
* 5 min: Briefly discuss different decision-making structures within a project |
|||
** "Benevolent dictator", as within Linux |
|||
** Decentralized do-ocracy, as within Debian |
|||
* 10 min: Discuss different roles (aka job descriptions) 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''' |
|||
* ? |
|||
Latest revision as of 22:29, 23 February 2012
Note well: This is just a draft; work in progress.