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

From OpenHatch wiki
Content added Content deleted
imported>Paulproteus
imported>Paulproteus
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 ==

Revision as of 22:31, 22 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

(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)

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)

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

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