View source

You do not have permission to edit this page, for the following reason:

You can view and copy the source of this page:

== 50 Ways to be a FOSSer == This page lists a variety of possible activities or assignments that involve Free & Open Source Software. Most of these were brainstormed at a workshop by a group of faculty involved in FOSS. Since then, the list has been expanded and organized into topic areas. == To Do == * 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 == Glossary == 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 something useful to FOSS project - what, how useful * unreviewed (doc) vs. reviewed (code) contribution == 50 Ways by Category == 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 === Introduction === * Read recent article(s) and { answer questions | summarize | critique | present material }. ** e.g. product reviews, culture of writing software, use within some environment, etc. ** sites: opensource.com,teachingopensource.org ** print: Linux Journal, Linux Magazine * Write an article about a topic related to FOSS and submit to a FOSS news blog/web site. ** Good blogs/sites for publication? * Write a { review | tutorial | comparison } of { a | several } FOSS. ** Good blogs/sites for publication? * Write an article on “what I wish I knew” - about FOSS; before starting a project or course. * Add a personal project blog to an appropriate planet (blog aggregator). * Interview a FOSS user and find out why they use FOSS, benefits/drawbacks, etc. * 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. * Interview a FOSS contributor to find out how they got involved, their role(s), their background, etc. * Shadow a FOSS contributor over time to see what they do, & summarize. * Create a lecture that provides a tour of the application domain landscape of FOSS. ** 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 ** Video it, Keep it short & modular for remixing. ** Create a list of wanted topics, get community to contribute. ** See examples from entrepreneurship education ** http://www.prendismo.com/collection/ (was Cornell eClips) ** http://ecorner.stanford.edu/ * FOSS scavenger hunt: Study a FOSS to answer a set of questions (overview about project and product features) ** Could also look at a forge (# of projects, what application domains, what languages, # added recently) === FOSS History === * Research the history of a FOSS & summarize. ** When did it start? How many releases? How many users? ** Reading history on the site, talk to people involved, etc. * Review an archived discussion of a { chat | thread | forum | list } over a { day | week | month } and { summarize | categorize | reflect on } the content. ** e.g. developer list, support list, * Study a completed defect or feature proposal, and create a concise summary, including details, people involved & their roles, steps taken. === Use & Evaluate === * Search forge(s) or the Internet for FOSS that interests you. * Use & evaluate a FOSS that has been installed. * Download, install, use, & evaluate FOSS. ** http://piratenpad.de/softhum-workshop-analysis * Read review(s) of FOSS, then download a "good" one, based on different criteria ** e.g. community, features, ease of maintenance * Evaluate how good a FOSS would be to { use | contribute to} based on: ** Size, maturity, level of activity, size of community, etc. ** Features described in documentation or demos. ** How easy it is to set up for use: e.g., download, install, customize, apply updates. * Compare and contrast 2+ FOSS to determine which to { use | contribute to }. ** criteria from instructor, student, or target user * Install (help others install) one or more FOSS and/or FOSS plugins. * Install PortableApps on a flash drive, along with several portable FOSS for later use. ** http://portableapps.com * Install FOSS operating system on a flash drive. ** http://www.pendrivelinux.com/ ** http://unetbootin.sourceforge.net/ === Communication & Tools === * Choose, investigate, and report on a forge. //what is the motivation or LO?// * View newest FOSS on a forge, then see how many new FOSS are created in a { day | week }. * Choose a (FOSS) RSS client, subscribe to RSS feeds for FOSS, read, and summarize. ** RSS clients: Google Reader, RSSOwl ** RSS feeds: any planet (feed aggregator), FOSS * Define IRC, determine why IRC is an appropriate means of communication within a community - what are the benefits, drawbacks? * 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. * Study IRC meetings: lurk; participate; write minutes or summary; plan agenda; run meeting. ** http://foss2serve.org/index.php/Connect_with_the_Community_(Activity) * 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). * Ask, comment on, answer, respond to question (on web forum, mailing list, IRC). * Study the social norms of communication within a FOSS community. (i.e. how to ask questions, respond, etc.) * Become familiar with public/private keys. //what is the motivation or LO?// ** Generate public and private keys for use with SSH. ** Install public key on remote server for passwordless access via SSH. ** Exchange public keys with another student. ** Use exchanged keys to send signs and/or encrypted messages. ** Sign another student's public key ** Get your public key signed by another student. * Sign a Contributors License Agreement (CLA) for a FOSS. //what is the motivation or LO?// ** see http://en.wikipedia.org/wiki/Contributor_License_Agreement * [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 // * [meta] Learn a tool, and teach others how to use it. * [meta] Learn that a text editor is a text editor, regardless of what it is. //how to do this?// * [meta] Learn how to choose a set of tools to use for a FOSS. === Culture, Intellectual Property === See: http://piratenpad.de/softhum-workshop-template-culture * Research how a FOSS is organized, summarize findings, & reflect. ** How many people are employed, who is employed, how they get paid. ** Business model - how is the project funded, who is in charge, etc. * Select a FOSS, identify primary contributors (no more than 10), find their educational and work experiences, and summarize. * Understand why a major company (like IBM for example) contributes to FOSS. ** What are the market pressures involved from an economic point of view? * Study software licensing (in general) and then discuss FOSS intellectual property issues. ** Why is it OK to download & install some software but not other? ** Why would developers give up their rights? * Compare & contrast 2+ FOSS licenses (e.g. in a matrix). === Philosophy / Politics === * Study why people choose to use FOSS as opposed to other software. * Read "Little Brother" (by Cory Doctorow) //what is the motivation or LO?// * Study the international influence in FOSS projects, both as contributors and consumers. ** cultural perspectives – freedom from multinationals companies (e.g. China, India) * Study cultural/policy implications of CC, GPL, etc. ** Implications for pre-health, pre-law, etc. * Explore implications of philosophy/culture of FOSS for public policy. ** Uber database of FOSS public policy decisions. Linked from Mel's blog. === Privacy / Security === * Evaluate security for a FOSS: how many intrusions, severity, etc. ** Compare with commercial products, industry practices * Write privacy policy //need more detail// * Develop security guidelines //need more detail// * Write about implications of software choice for security. //need more detail// ** Diaspora (Facebook clone) and problems w.r.t. privacy/security ** FOSS DBs, etc. (OpenMRS) -- issues, privacy, etc. === Advocacy === * Organize & conduct a { installation festival | tutorial session } for a { FOSS | feature }. * { Observe | participate in | support | organize } a hackathon. * Raise money or other resources for an open source project. * [meta] Promote a project of interest using multiple tools/channels. //other examples?// === Documentation === * Review a page and summarize problems found. ** for existing pages, or proposed changes/additions by other students * Find & improve a page that could benefit from editing / rewriting / improvement. ** Find references (to other pages or resources) and add them (with appropriate links). * Find a "stub" page and expand it with research and related references. * Create a new page with appropriate research & related references. * “Garden” a site or other documentation – prune, restructure, etc. ** Instructor could clone or create a sandbox area for this. ** Major restructuring might require advance planning. * Test documentation (e.g. installation instructions) and summarize problems found. ** [http://www.foss2serve.org/index.php/Test_Installation_Instructions] * Rewrite & simplify installation instructions for typical (non-technical) computer users. * Write concise and helpful instructions to install and configure FOSS on a specific system. ** Specify version or date when install instructions become obsolete. * Create or update a glossary or vocabulary list for a FOSS. * Translate a page to a different language using { automated tools | expert knowledge }. * Convert written docs to video docs. * Convert video docs to written docs. * Develop UML diagram from an existing project. (argouml) ** Generate and review JavaDoc. ** http://www.foss2serve.org/index.php/UML_a_project === Visual Design === * Create a storyboard or paper prototype, evaluate with users, revise, & summarize. ** Clif has paper prototyping references, workshop slides, etc. * Create instructional comics. * Create a font or icon set. * [meta] Become a design ninja //expand / clarify - how does a student do this?// === Quality & Testing === * In teams, students generate test sets for given code and an understanding of the codes purpose, and test that code. ** see http://piratenpad.de/softhum-workshop-template-testsets * 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). ** see http://piratenpad.de/softhum-workshop-write-feature-description * 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). ** Create a new defect report from mailing list or personal experience. ** Find a "bad" report and make it a "good" report. ** http://foss2serve.org/index.php/Writing_a_bug_report * Brainstorm list of possible enhancements for project, choose a few to document (see above). * Evaluate usability of a specified { feature | screen } and summarize results & conclusions (in tracker or wiki). ** using formal guidelines or rubric ** using heuristic evaluation http://en.wikipedia.org/wiki/Heuristic_evaluation * Role play / evaluate from other (non-student) perspectives. * Test documentation. ** Evaluate (and improve) installation instructions. * Verify (and fix) development environment. * Develop an { automated test suite | repeatable test script }, contribute code, summarize results. * Test (perhaps a project that does JUnit testing). ** Trace the execution of some piece of code. === Specification and Design === * Explore a new feature for an existing project ** Discuss how it might be implemented ** Show actual code and implementation * Identify data structures used in a project. * Study code & docs, diagram system architecture, evaluate, summarize. ** using guidelines supplied by instructor === Coding & Style === * Given coding standard & sample code, list the changes needed for code to meet standard. * Given sample code, infer and document coding standard. * Analyze existing code to understand what it does and how it works. * Reformat, document, & refactor existing (others') code to make it more readable & consistent. * Analyze the sequence of function calls that produces a specified { feature | page | screen }. ** http://piratenpad.de/softhum-workshop-analysis * Identify examples of a given { coding construct | data structure | pattern } in a FOSS. ** could provide teachers with examples to use in other courses * Given specification & code, provide an itemized list of tasks and describe how each was met. * Given a problem and 2+ solutions to a problem, compare, summarize, & present. ** naming conventions, coding style, efficiency, etc... * Given a problem, find 2+ solutions (to same or similar problem) and summarize the differences between the solutions. * Determine how well a { FOSS | component } meets its specifications. * Develop a code walkthrough ** In teams of 2-3, students walk through working, uncommented code to determine its purpose. ** Deliverables: A brief summary (1-2 paragraphs) describing the purpose of the code. ** Could be senior level assignment, where students are asked to understand a complicated segement of code from a larger project. CS1-2: students are given a partial implementation of a class as to determine what a specific method does. ** http://piratenpad.de/softhum-workshop-template-walkthrough ** http://foss2serve.org/index.php/Document_code_with_meaningful_comments * Given a comment, defect, or feature request, study & fix it, and submit as patch. ** FOSS with plugins may be easier for this: ** Drupal (e.g. shopping cart), Firefox, GreaseMonkey, Moodle ** wiki formatting plugins * Develop UML diagram(s) for a FOSS. ** FOSS UML tool: http://argouml.tigris.org/ ** PC Clements, & DL Parnas. 1986. “A rational design process: How and why to fake it.” IEEE Transactions on Software Engineering 12 (2): 251-257. * Find/study examples of well & poorly written code - style wise (layout, variable names) ** Look at coding standard for an open source project (Java, Python) ** Reformat code, rename variables, etc. (possibly commit back depending on project) * Add comments to a piece of code that has no or poor comments. ** http://foss2serve.org/index.php/Document_code_with_meaningful_comments === Product Packaging and Distribution === * Configure FOSS according to given criteria or specification. ** What are good examples of configurable FOSS - Drupal, wiki, ** design & create a custom distribution ** Share custom distribution with the FOSS community. * Maintain a build host. //needs more detail// * Understand and identify installation and IT support needs. //needs more detail// [[Category:Reference]]

Return to 50 Ways to be a FOSSer.