50 Ways to be a FOSSer

was: http://piratenpad.de/softhum-workshop

• revise/refine list for conciseness & clarity – add links to supporting info, examples, etc.
• put people to review, comment, clarify, vote for tasks they'd use if well documented

The following terms are used below to make the list more concise and avoid duplication.

• Contributor - anyone who contributes to FOSS – code, design, docs, feedback, ideas, etc.
• FOSS - free & open source software. “a FOSS”: a project; “FOSS”: the broader culture.
• Forge - web site containing many FOSS – e.g. Sourceforge
• Lead - anyone who coordinates or directs other contributors
• Planet - blog aggregator for a FOSS or topic

Possible categories / dimensions for tags / taxonomy

• ACM curricular areas & outcomes
• relevant courses
• prereq tools/skills
• time/effort required – for instructor prep, student work, elapsed calendar time
• requires input / effort from FOSS community - how much, what kind
• produces sometime useful to FOSS project - what, how useful
  • unreviewed (doc) vs. reviewed (code) contribution

Notes:

• A FOSS could be specified by instructor, selected from a set of choices, or chosen by student, depending on student experience, time available, etc.
• Documentation tasks could apply to:
  • a FOSS
  • meta sites: http://opensource.com, http://teachingopensource.org,
  • other open content sites: Wikipedia, Instructables, eHow, WikiHow, etc.
• Tasks could be done alone, in pairs, teams, etc.
• Tasks could result in:
  • blog posts, podcasts, vlogs, wiki pages, etc.
  • articles for magazines, newspapers, web sites, etc.
• Results could be:
  • Submitted to instructor for evaluation.
  • Posted or shared for peer review (with other students in course).
  • Presented in class.
  • Discussed in class or online, etc.
• See: http://piratenpad.de/softhum-workshop-template-writing

1. Search forge(s) or the Internet for FOSS that interests you.
2. Use & evaluate a FOSS that has been installed.
3. Download, install, use, & evaluate FOSS.
   1. http://piratenpad.de/softhum-workshop-analysis
4. Read review(s) of FOSS, then download a “good” one, based on different criteria
   1. e.g. community, features, ease of maintenance
5. Evaluate how good a FOSS would be to { use | contribute to} based on:
   1. Size, maturity, level of activity, size of community, etc.
   2. Features described in documentation or demos.
   3. How easy it is to set up for use: e.g., download, install, customize, apply updates.
6. Compare and contrast 2+ FOSS to determine which to { use | contribute to }.
   1. criteria from instructor, student, or target user
7. Install (help others install) one or more FOSS and/or FOSS plugins.
8. Install PortableApps on a flash drive, along with several portable FOSS for later use.
   1. http://portableapps.com
9. Install FOSS operating system on a flash drive.
   1. http://www.pendrivelinux.com/
   2. http://unetbootin.sourceforge.net/

1. Read recent article(s) and { answer questions | summarize | critique | present material }.
   1. e.g. product reviews, culture of writing software, use within some environment, etc.
   2. sites: opensource.com,teachingopensource.org
   3. print: Linux Journal, Linux Magazine
2. Write an article about a topic related to FOSS and submit to a FOSS news blog/web site.
   1. Good blogs/sites for publication?
3. Write a { review | tutorial | comparison } of { a | several } FOSS.
   1. Good blogs/sites for publication?
4. Write an article on “what I wish I knew” - about FOSS; before starting a project or course.
5. Add a personal project blog to an appropriate planet (blog aggregator).

1. Interview a FOSS user and find out why they use FOSS, benefits/drawbacks, etc.
2. Study a FOSS contributor’s activities over time { week | month | semester } to understand the level of engagement and the type of interactions/contributions the person has made.
3. Interview a FOSS contributor to find out how they got involved, their role(s), their background, etc.
4. Shadow a FOSS contributor over time to see what they do, & summarize.

1. Research the history of a FOSS & summarize.
   1. When did it start? How many releases? How many users?
   2. Reading history on the site, talk to people involved, etc.
2. Review an archived discussion of a { chat | thread | forum | list } over a { day | week | month } and { summarize | categorize | reflect on } the content.
   1. e.g. developer list, support list,
3. Study a completed defect or feature proposal, and create a concise summary, including details, people involved & their roles, steps taken.

1. Choose, investigate, and report on a forge. what is the motivation or LO?
2. View newest FOSS on a forge, then see how many new FOSS are created in a { day | week }.
3. Choose a (FOSS) RSS client, subscribe to RSS feeds for FOSS, read, and summarize.
   1. RSS clients: Google Reader, RSSOwl
   2. RSS feeds: any planet (feed aggregator), FOSS
4. Define IRC, determine why IRC is an appropriate means of communication within a community - what are the benefits, drawbacks?
5. Subscribe to an IRC channel, listen to a meeting, write summary of the content of the meeting and any observations about the mode of communication/type of communication.
6. Study IRC meetings: lurk; participate; write minutes or summary; plan agenda; run meeting.
7. Work remotely (using IRC, email, twitter, whatever) with another student to develop profiles for each other. (a web-page about you and your tech skills and interests).
8. Ask, comment on, answer, respond to question (on web forum, mailing list, IRC).
9. Study the social norms of communication within a FOSS community. (i.e. how to ask questions, respond, etc.)
10. Become familiar with public/private keys. what is the motivation or LO?
    1. Generate public and private keys for use with SSH.
    2. Install public key on remote server for passwordless access via SSH.
    3. Exchange public keys with another student.
    4. Use exchanged keys to send signs and/or encrypted messages.
    5. Sign another student's public key.
    6. Get your public key signed by another student.
11. Sign a Contributors License Agreement (CLA) for a FOSS. what is the motivation or LO?
    1. see http://en.wikipedia.org/wiki/Contributor_License_Agreement
12. [meta] Learn to interact with the community by using various tools such as blogs, wiki changesets, ticketing systems, etc. expand to specific tasks with specific tools
13. [meta] Learn a tool, and teach others how to use it.
14. [meta] Learn that a text editor is a text editor, regardless of what it is. how to do this?
15. [meta] Learn how to choose a set of tools to use for a FOSS.

See: http://piratenpad.de/softhum-workshop-template-culture

1. Research how a FOSS is organized, summarize findings, & reflect.
   1. How many people are employed, who is employed, how they get paid.
   2. Business model - how is the project funded, who is in charge, etc.
2. Select a FOSS, identity primary contributors (no more than 10), find their educational and work experiences, and summarize.
3. Understand why a major company (like IBM for example) contributes to FOSS.
   1. What are the market pressures involved from an economic point of view?
   2. Why would a for-profit company give away intellectual property?
4. Study software licensing (in general) and then discuss FOSS intellectual property issues.
   1. Why is it OK to download & install some software but not other?
   2. Why would developers give up their rights?
5. Compare & contrast 2+ FOSS licenses (e.g. in a matrix).

1. Study why people choose to use FOSS as opposed to other software.
2. Read “Little Brother” (by Cory Doctorow) what is the motivation or LO?
3. Study the international influence in FOSS projects, both as contributors and consumers.
   1. cultural perspectives – freedom from multinationals companies (e.g. China, India)
4. Study cultural/policy implications of CC, GPL, etc.
   1. Implications for pre-health, pre-law, etc.
5. Explore implications of philosophy/culture of FOSS for public policy.
   1. Uber database of FOSS public policy decisions. Linked from Mel's blog.

1. Evaluate security for a FOSS: how many intrusions, severity, etc.
   1. Compare with commercial products, industry practices
2. Write privacy policy need more detail
3. Develop security guidelines need more detail
4. Write about implications of software choice for security. need more detail
   1. Diaspora (Facebook clone) and problems w.r.t. privacy/security
   2. FOSS DBs, etc. (OpenMRS) – issues, privacy, etc.

1. Organize & conduct a { installation festival | tutorial session } for a { FOSS | feature }.
2. { Observe | participate in | support | organize } a hackathon.
3. Raise money or other resources for an open source project.
4. [meta] Promote a project of interest using multiple tools/channels. other examples?

1. Review a page and summarize problems found.
   1. for existing pages, or proposed changes/additions by other students
2. Find & improve a page that could benefit from editing / rewriting / improvement.
   1. Find references (to other pages or resources) and add them (with appropriate links).
3. Find a “stub” page and expand it with research and related references.
4. Create a new page with appropriate research & related references.
5. “Garden” a site or other documentation – prune, restructure, etc.
   1. Instructor could clone or create a sandbox area for this.
   2. Major restructuring might require advance planning.
6. Test documentation (e.g. installation instructions) and summarize problems found.
7. Rewrite & simplify installation instructions for typical (non-technical) computer users.
8. Write concise and helpful instructions to install and configure FOSS on a specific system.
   1. Specify version or date when install instructions become obsolete.
9. Create or update a glossary or vocabulary list for a FOSS.
10. Translate a page to a different language using { automated tools | expert knowledge }.
11. Convert written docs to video docs.
12. Convert video docs to written docs.

1. Create a storyboard or paper prototype, evaluate with users, revise, & summarize.
   1. Clif has paper prototyping references, workshop slides, etc.
2. Create instructional comics.
3. Create a font or icon set.
4. [meta] Become a design ninja expand / clarify - how does a student do this?

see http://piratenpad.de/softhum-workshop-template-testsets see http://piratenpad.de/softhum-workshop-write-feature-description

1. Choose a fixed defect or feature, research its history (when & how reported, when & how fixed), and summarize in a 5 min format (in tracker, wiki, blog post, podcast, vlog, etc).
2. Choose an open defect or feature request from { mailing list | tracker | wiki }, verify that it exists, and expand & improve formal report (in tracker or wiki).
   1. Create a new defect report from mailing list or personal experience.
   2. Find a “bad” report and make it a “good” report.
3. Brainstorm list of possible enhancements for project, choose a few to document (see above).
4. Evaluate usability of a specified { feature | screen } and summarize results & conclusions (in tracker or wiki).
   1. using formal guidelines or rubric
   2. using heuristic evaluation http://en.wikipedia.org/wiki/Heuristic_evaluation
5. Role play / evaluate from other (non-student) perspectives.
6. Test documentation.
   1. Evaluate (and improve) installation instructions.
7. Verify (and fix) development environment.
8. Develop an { automated test suite | repeatable test script }, contribute code, summarize results.

1. Given coding standard & sample code, list the changes needed for code to meet standard.
2. Given sample code, infer and document coding standard.
3. Analyze existing code to understand what it does and how it works.
4. Reformat, document, & refactor existing (others') code to make it more readable & consistent.
5. Analyze the sequence of function calls that produces a specified { feature | page | screen }.
   1. http://piratenpad.de/softhum-workshop-analysis
6. Identify examples of a given { coding construct | data structure | pattern } in a FOSS.
   1. could provide teachers with examples to use in other courses
7. Given specification & code, provide an itemized list of tasks and describe how each was met.
8. Given a problem and 2+ solutions to a problem, compare, summarize, & present.
   1. naming conventions, coding style, efficiency, etc…
9. Given a problem, find 2+ solutions (to same or similar problem) and summarize the differences between the solutions.
10. Determine how well a { FOSS | component } meets its specifications.
11. Develop a code walkthrough
    1. http://piratenpad.de/softhum-workshop-template-walkthrough
12. Given a comment, defect, or feature request, study & fix it, and submit as patch.
    1. FOSS with plugins may be easier for this:
       1. Drupal (e.g. shopping cart), Firefox, GreaseMonkey, Moodle
       2. wiki formatting plugins
13. Develop UML diagram(s) for a FOSS.
    1. FOSS UML tool: http://argouml.tigris.org/
14. Study code & docs, diagram system architecture, evaluate, summarize.
    1. using guidelines supplied by instructor
    2. PC Clements, & DL Parnas. 1986. “A rational design process: How and why to fake it.” IEEE Transactions on Software Engineering 12 (2): 251-257.

1. Create a lecture that provides a tour of the application domain landscape of FOSS.
   1. Show market segment leaders (Apache, MySQL), tools (Eclipse, Notepad++), games (game engine), humanitarian, industry specific (e.g., ERP), etc. - this may be a pre/post-scavenger hunt lecture
   2. Video it, Keep it short & modular for remixing.
   3. Create a list of wanted topics, get community to contribute.
   4. See examples from entrepreneurship education
      1. http://www.prendismo.com/collection/ (was Cornell eClips)
      2. http://ecorner.stanford.edu/
2. Configure FOSS according to given criteria or specification.
   1. What are good examples of configurable FOSS - Drupal, wiki,
   2. design & create a custom distribution
   3. Share custom distribution with the FOSS community.
3. Maintain a build host. needs more detail
4. Understand and identify installation and IT support needs. needs more detail

1. FOSS scavenger hunt: Study a FOSS to answer a set of questions (overview about project and product features)
   1. Could also look at a forge (# of projects, what application domains, what languages, # added recently)
2. Find/study examples of well & poorly written code - style wise (layout, variable names)
   1. Look at coding standard for an open source project (Java, Python)
   2. Reformat code, rename variables, etc. (possibly commit back depending on project)
3. Add comments to a piece of code that has no or poor comments.
   1. Generate and review JavaDoc.
4. Test (perhaps a project that does JUnit testing).
5. Trace the execution of some piece of code.

1. A different, more advanced scavenger hunt using different projects.
2. Develop UML diagram from an existing project. (argouml)
3. Explore a new feature for an existing project
   1. Discuss how it might be implemented
   2. Show actual code and implementation
4. Identify data structures used in a project.