HOWTO plan a POSSE

From Teaching Open Source

Jump to: navigation, search

This page is a DRAFT under active construction. Please join in the effort on writing our HOWTO plan a POSSE guide!

INTRO GOES HERE

Setting expectations with the students in advance is important. Following the thinking in the Pioneer analogy, students need to understand that the current state of FLOSS is more like a frontier town turning slowly in to a city. Other thoughts on this are gathered in Preparing students for their POSSE.

Contents

[edit] Meta: How this page is being made

We've started sprinting on this page in IRC; feel free to edit/join in anytime (no regularly scheduled sprints yet) - here are the logs from the first one: and [http://meetbot.fedoraproject.org/teachingopensource-posse/2009-11-10/teachingopensource-posse.2009-11-10-15.27.log.html log

[edit] Sponsorship

This is a draft/strawman. We're still tossing around ideas - feel free to comment - but this seems to be working out so far.

The general idea is that POSSEs (right now) are a partnership between Red Hat and another party, which we'll call the POSSE Partner. This can be a university, an open source project, another company, etc, but it's probably a university.

1. Red Hat handles curriculum: we figure out instructors and pay for all instructor-related expenses (travel, lodging, stipends).

2. Red Hat handles swag and the grand end-of-week dinner with local open source community members.

2. POSSE Partner handles hosting logistics: a location with wifi and some machines/VMs to play with for the week, and the mixer the night before POSSE week starts (which should include some light refreshments - soda, cheese, and crackers are great).

3. POSSE Partner and Red Hat will do joint marketing of the event - the two groups are likely to be able to reach different audiences.

4. Attendees handle travel/housing/food themselves (though the idea is that POSSEs will be local, so this should be a non-issue). Red Hat and POSSE Partner' will be able to help out with some local logistics, and depending on surplus budget, might also be able to help subsidize some of these costs, but don't count on it.

[edit] Deadlines

POSSE start date Approval needed by Funding quarter
Before May 15, 2010 ASAP - ask Mchua for case-by-case discussion March 1, 2010
May 15, 2010 - June 1, 2010 Feb 15, 2010 March 1, 2010
June 2, 2010 - Sep 1, 2010 March 1, 2010 June 1, 2010
Sep 2, 2010 - Dec 1, 2010 June 1, 2010 Sep 1, 2010
Dec 2, 2010 - March 1, 2010 Sep 1, 2010 Dec 1, 2010
After Dec 2, 2010 Deadline not set yet, but no earlier than Dec 1, 2010 TBA

[edit] Timeline

  • 3 months before: fill roles, determine date/location
  • 2 months before: open registration
  • 2 weeks before: Registration cutoff
  • 1 week before: IRC class meeting

[edit] Logistics

[edit] roles to fill

  • physical logistics (including attendee logistical wranglin')
  • virtual logistics (infrastructure, testing course materials)
  • PR/marketing/recruiting and documentation
  • teaching (including volunteer/guest instructor recruitment and wranglin' as well as course material creation)

[edit] Registration

  • Should cut off 2 weeks before the event, hard stop.
  • set up a central place for collecting applications
    • everyone should be able to see everyone else's app
    • and comment on it
    • and instructor comments on it
    • maybe require people to do their app via a git checkin
    • and submit their app by posting on a Planet "look at this git repo"
    • and defend their app via IRC?

[edit] How to apply

[edit] How to choose who comes

  • rolling admissions until all seats are full
  • people encouraged to revise and resubmit applications as many times as they like (should we even encourage people to get rejected the first time to get the FAIL FASTER vibe early on?)

[edit] Once admitted

  • join the mailing list
  • create a blog and get it on Planet; blog future assignments
  • attend a pre-class meeting on IRC (wherein we do the IRC/make-a-user-page assignment)
  • do something with git

[edit] Assignments

  • two parts: deliverable and reflection (which is more important varies by assignment - sometimes you're there to learn the skill, sometimes you're there to try and then figure out what didn't work)

[edit] Infrastructure and resources

[edit] Pre-POSSE communication exercises

One of the most important lessons we teach in POSSE is communication in the style of open source projects. The majority of open source projects use similar tools to communicate, and in POSSE we will use these same tools. Before visiting POSSE, your students should perform the following exercises.

[edit] IRC Exercise

Step One: Download and install an IRC client. We recommend ChatZilla for Firefox. From your Firefox browser install ChatZilla now.

Step Two: Start ChatZilla. You can find it under Tools / ChatZilla in the Firefox menu bar.

Step Three: Select "freenode" from the list of servers. Alternately, go to the ChatZilla command window (next to your username, bottom of the screen) and type /connect irc.freenode.net

Step Four: Type /join #teachingopensource-posse into the command window.

Step Five: You are connected! Say "Hello", or anything you like, into the command window, and it will show up on screen -- and on the screen of everyone else who is connected. If someone is there, they might say hello back!

FIXME: Get screenshots of the IRC window that don't show my own personal desktop. Doh.

[edit] Mailing List Exercise

[edit] Blog Exercise

[edit] Lab Setup

Any POSSE must be run in a lab that provides, for each student:

  • Desktops or laptops running either the latest version of Fedora, or the latest POSSE remix
  • Ports 22, 80, 6667, and 443 open to the world

[edit] Tracking Our Professors

How do we do this?

[edit] Branding

Anyone in the world can take the content that is taught in POSSE and repurpose it for their own needs. But one of the goals of POSSE is to build a community of POSSE graduates who want to become POSSE instructors in future years. This is fundamental to the growth of POSSE, and to the branding of POSSE.

[edit] The POSSE Pledge

In order to call your bootcamp a POSSE, we require that at least one of the instructors and/or lead organizers of the bootcamp has made the POSSE Pledge.

And in order to make the POSSE Pledge, you need to first attend a POSSE yourself.

FIXME: We need to get more specific about WHEN and HOW a person makes the POSSE Pledge, since having that list be honest and true is very important. There is a difference between someone who went through POSSE and someone who has made the POSSE pledge, and that is OK.

[edit] Specific branding requirements

Any bootcamp wishing to call itself a POSSE must:

  • Have an instructor/organizer who has made the POSSE pledge in a leadership role (see above).
  • Have a home page that is integrated with the other POSSE pages on teachingopensource.org.
  • Have a mailing list on teachingopensource.org.
  • Be active in the #teachingopensource-posse channel on Freenode IRC.

[edit] Instructor requirements

Strawman: To be a POSSE Instructor, you need to teach a POSSE with a POSSE Instructor, who can then approve you to be a POSSE Instructor solo. (This needs work, obviously...)

[edit] Public Relations

FIXME:

  • Blogging is critical.
  • Reach out to local press.
  • If you're at a university, get the student newspaper involved.
  • Make sure that you are integrated into the larger global POSSE messaging and purpose.

[edit] Documentation and followup

A key requirement of a POSSE event is to document, as you proceed, with maximum automatic logging and capture of information. At the same time, there is deep value in editing the wiki pages as the class proceeds, especially if the students can be convinced to do the writing/editing/note taking on the wiki.

Even where information that is documented in the class is a duplicate of what another class captured, the process of capturing the documentation is as important as the actual content captured.

An English idiom for this is, "Half of the journey is the getting there." In other words, the actual travel is an equal part of the goal as the getting to the destination.

[edit] In advance: tools

  • You need an IRC channel where all students and external participants will be during the POSSE. Bonus if you can get the students there in advance, and keep them there following the session.
  • This IRC channel must run a meeting bot (zodbot) and a translation bot (transbot). The transbot is only needed if there are going to be any potential language barriers, either between students or with instructors and external contributors to the class.
  • If using Fedora, have an image ready with the packages preinstalled. (We should provide a template kickstart file - TODO: link to POSSE Remix.)

[edit] In advance: Instructor documenting

[edit] In advance: Student documenting

  • Setup blog

[edit] During: Instructor documenting

  • Keep and update a wiki page that captures what you have learned from the students about the shortcomings of this POSSE and the POSSE model in general. These notes are key for iteratively improving POSSE.

[edit] During: Student documenting

  • Keep notes for daily blog post.
    • Facts and personal observations; not a full recount required. Overview of material and some personal thoughts.
  • Help the instructors and fellow students keep notes on the wiki, where possible.
    • For example, have a section of notes in Posse APAC - Nov 2009 for each block of instruction time. Rotate with other students who is responsible for writing in that section for each block.
    • Use IRC to interact with other students. For example, if you are keeping your own notes and you write down something that is not in the wiki page, share the notes with the student who is responsible for that block's wiki section, or just add the notes yourself after the section is done.
      • Having one person do the writing during the session works best. Other students can add their own session notes to the same section afterward. This prevents in-class frustration with simultaneous editing of a single wiki page.

[edit] Where to put and find content

[edit] Raw docs section content to work from

The below are random notes that were grabbed from IRC and are being used to construct the above content on documenting a POSSE.

Documentation and Followup: HOWTO capture the events and output of a POSSE with minimal pain and minimal extraneous cruft (get zodbot in a channel this way, get people started blogging with these sample prompts if needed, etc).

"$these_people should spend $this_amt_of_time on $these_days documenting $this_stuff"

(so more automated ways of doccing stuff == good, and a notion of what's important to keep how up to date == really helpful, because I don't know)

we have blogs, theoretically, which take a really long time to set up, and right now all the posts are manually collected, http://teachingopensource.org/index.php/POSSE_Blogs

08:10 < mchua> http://eunisim.blogspot.com 08:10 < mchua> http://sst.unisim.edu.sg/sites/osom 08:10 < mchua> http://jaricsng.wordpress.com 08:10 < mchua> http://tiraths.wordpress.com 08:10 < mchua> http://xcliu.wordpress.com 08:10 < mchua> http://rchiun.wordpress.com 08:10 < mchua> http://lsystem.wordpress.com


and we have stuff like http://teachingopensource.org/index.php/POSSE_APAC_Planning and logs from those

trying to think of what students can't easily do...

  • plannin docs
  • followup docs
  • summary of everything the other students said docs (though we could assign those as a rotating thing)
  • and we need good examples of student-written docs (hence my motivation for collecting blog posts)
  • and non-students should still

your first deliverable is to tell me what my deliverable for mon and tues should look like, and how I should keep up with weds (and what I need to farm out)


(i.e. "this exercise was poorly designed because we didn't have clear instructions" vs "this exercise showed us how to come up with a list of clear instructions after exploring through something that didn't have them")

Retrieved from "http://teachingopensource.org/index.php/HOWTO_plan_a_POSSE"