Open Source Comes to Campus/Curriculum/Saturday: Difference between revisions
Content added Content deleted
imported>Paulproteus |
imported>Paulproteus |
||
(3 intermediate revisions by the same user not shown) | |||
Line 7: | Line 7: | ||
== Communicating as a user: finding the community and getting help == |
== Communicating as a user: finding the community and getting help == |
||
* [[/User communication|User communication]] |
|||
'''Pre-requisites''': IRC client installed. Web browser installed. |
|||
'''Learning objectives''': Know about the common real-time-ish communication tools used by projects (IRC, mailing lists (including Google Groups)). Be able to join IRC channels. Have a sense of etiquette on IRC channels and mailing lists. Be able to read mailing list threads and find answers embedded in them. Understand that idling is a good thing, especially when waiting for an answer. Understand how to search pipermail/mailman archives. Understand that most projects have a -users and -devel separation in mailing lists, and know when to use each one. Understand how to find answers to e.g. Ubuntu programs via Googling and finding them on e.g. a StackExchange-type site. Learn about Linux Users Groups and any existing ones in the community. |
|||
(Generally, be able to [http://catb.org/~esr/faqs/smart-questions.html ask questions the smart way].) |
|||
'''Group discussion''' |
|||
* Start by showing a program that doesn't do what you need. Overall idea: where are the humans on the planet who can help? |
|||
* What are mailing lists like? |
|||
** Share a story of getting serious help on a mailing list (e.g. reiserfs+lkml in 2001-ish, or Dovecot, or something else) |
|||
** The list is often just the actual developer |
|||
*** but that person's presence is actually somewhat remarkable |
|||
** Show mailman and Google Groups archives |
|||
** Share a story of excellent humor on a list |
|||
** Explain digest mode |
|||
** Show an example of inline replies |
|||
** Show some mailing list spam, and then explain that you must generally join to post |
|||
* 5 min digression: Debian's OpenSSL patch, or "How this can all go horribly wrong" |
|||
* What happens on IRC? |
|||
** Sometimes fast-moving... |
|||
*** (animated GIF of unreasonably fast channel) |
|||
** User questions |
|||
** Developer discussions |
|||
** Sometimes slow-moving... |
|||
*** screenshot of super slow moving thing |
|||
** Explain existence of separate networks |
|||
* 5 min: How you can help yourself |
|||
** Googling the problem |
|||
** Searching bug trackers for the issue, and discovering workarounds |
|||
** Showing up on IRC and just listening |
|||
* 5 min: General help communities |
|||
** linuxquestions.org |
|||
** Local groups! (LUGs, computer clubs, etc.) |
|||
*** Show an example of people in other countries posting to SF groups |
|||
** The Gentoo and Arch Linux wiki (even though they're supposedly specific) |
|||
** Stack Overflow, and how it influenced Debian and Ubuntu's "ask" community |
|||
* Cultural example: Debian's emphasis on email for development over IRC |
|||
'''Individual work''' |
|||
* (Does not exist yet) IRC training mission, or an equivalent suggested run-through of how to use IRC |
|||
* Rank various email help-request subject lines in quality, and compare with the student next to you |
|||
* Find the website of the local linux users group (e.g. Philadelphia's PLUG) and join the IRC channel for it and say hello |
|||
'''Assessment elements''' |
|||
* The IRC training mission has its own assessment elements. |
|||
* We can idle in the IRC channel of the local LUG |
|||
* Student next to you discusses rankings |
|||
== Ethics and history of open source; and economics and licensing that support it == |
== Ethics and history of open source; and economics and licensing that support it == |
||
* [[/Ethics and history|Ethics and history]] |
|||
(General note: At Penn, the way we structured this was as a conversation between two of the teachers, as a full group.) |
|||
Structure: All students are in one room. Asheesh lectures initially. Teachers talk for a while and answer the questions that students ask. |
|||
* Lecture: |
|||
** Importance of software transparency (example: Skype) |
|||
** Importance of customizability (example: Dance Dance Immolation) |
|||
** History of "free software" movement... |
|||
** ...simultaneous to Linux pioneering a world of actual collaboration |
|||
** History of the "open source" fracture, and how it dominates |
|||
** Explanation of a few different business models around open source, and how the finances work out (individual consulting; huge support organizations like Red Hat; hosting a service like WordPress.com; Debian, where the "center" has no business model) |
|||
* Teachers re-introduce themselves briefly, and explain in 4 minutes or fewer how they initially got involved in contributing (in any way: documentation, code, design, etc.) to an open source project; what their motivations are; and how they are paid (if at all) for open source work. |
|||
** To avoid a catastrophe of slow talking, we might require slides from teachers for this. |
|||
* Student Q&A. |
|||
Assessment: None. |
|||
== Getting, modifying, and verifying open source software (getting code; local patching) == |
== Getting, modifying, and verifying open source software (getting code; local patching) == |
||
* [[/Getting modifying and verifying]] |
|||
'''Pre-requisites''': ? |
|||
'''Learning objectives''': Know how to download a tarball and apply a patch. Understand what a patch file looks like. Understand the idea of "-p0" "-p1" fiddling. Understand how to verify a tarball against a SHA1 checksum, and why it matters. Understand how to use GPG to verify a SHA1SUMS file! Understand the basic idea of version control, and know how to create a patch file against code stored in two common VCSs. |
|||
'''Group discussion''' |
|||
* Question: Where do tarballs come from? |
|||
** Answer: Someone takes a snapshot of a directory. But how did things get in there? |
|||
* Quick overview of a patch file |
|||
* Verifying tarballs |
|||
** Why authenticity is desirable |
|||
*** Example: Linux driver with a uid=0 vs. uid == 0 bug introduced |
|||
** md5sum + sha1sum |
|||
** verifying md5sum + sha1sum lists with gpg |
|||
** Quick introduction to the web of trust |
|||
* Why people use version control |
|||
** You can check if your patch is in the main tree or not |
|||
** It makes it super easy to create patches |
|||
** It is easy to jump between versions |
|||
* Quick mention of packaging systems |
|||
* Quick introduction to installing build dependencies |
|||
'''Individual work''' |
|||
* Have students go through the git training mission. |
|||
* Have students download a few tarballs and identify which ones do not verify. |
|||
'''Assessment elements''' |
|||
* The training missions includes their own assessments. |
|||
'''Possible problems''' |
|||
* ? |
|||
== 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.