Open Source Comes to Campus/Curriculum/Saturday: Difference between revisions

From OpenHatch wiki
Content added Content deleted
imported>Paulproteus
imported>Paulproteus
 
(5 intermediate revisions by the same user not shown)
Line 3: Line 3:
== The command line, packages, and dependencies ==
== The command line, packages, and dependencies ==


* [[/CLI]]
'''Pre-requisites''': Have some Linuxy distro and a terminal open, or Terminal on a Mac, or GitBash on Windows.

'''Learning objectives''': Have a general understanding of what paths mean (/usr /usr/bin /home etc.). Understand the purpose and basic use of package management tools. Understand how to "cd" and "ls" around in a terminal. Have familiarity with passing arguments to CLI programs (e.g., tar). Preferably, understand that a text terminal can display "graphical" (e.g. via ncurses) programs. Understand enough history of the command line to know it came "first", before GUIs. Have enough understanding of the command line to succeed at the rest of the day's activities. Become familiar with different ways of quitting command-line programs.

'''Group discussion'''

* Use a photo of teletypes connected to a serious UNIX server to explain what a "terminal" means.
* Ask people what their experiences with the command line have been so far. (If necessary, skip pieces of the discussion.)
* With a diagram of a directory hierarchy, discuss different paths like /home and /usr.
* Explain the concept of "PATH". Point out that "." is usually not in the path by default.
* Split the screen into half Nautilus, half Terminal, and show how they are different views of the same thing.
* Explain that programs like "apt-get" install software, and to demonstrate this, use apt-get on the presentation machine to install something. Demonstrate where the resulting files went with dpkg -L. (Try to include a surprise /usr/sbin program.) Try executing a binary that got installed, and point out its location. Use apt-get remove to remove it. Point out that "yum" and "port" are similar tools.

'''Individual work'''

* Have students go through the "tar" training mission, which shows them mkdir and moving files around and tar.
* It would be nice to have a training mission called "Six ways to quit" that showed you ^C, ^D, q (for less), :q (for vi-like), ^X (for pico-like), C-x C-c (for emacs-like)


'''Assessment elements'''

* The "tar" training mission includes elements of running programs.
* The "Six ways to quit" mission includes its own assessment.

'''Possible problems'''

* Some students might already be extremely familiar with this material. It'd be nice to have some "extra credit".


== 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.

The command line, packages, and dependencies

Communicating as a user: finding the community and getting help

Ethics and history of open source; and economics and licensing that support it

Getting, modifying, and verifying open source software (getting code; local patching)

Project organization (bug trackers; git format-patch; github; people's roles in a project)

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