From Teaching Open Source

Other things that should be here:

21:21:00 < alolita> As quaid and I were discussing earlier - we need to work on

                   a planning document to add details about what we need to do 
                   - we also need to create a proposal document - as an 
                   invitation to each college / dept of computer science or 
                   MIS to get profs to participate in the program. We need a 
                   sponsorship document - with our guidelines and what we can 
                   do

21:21:13 < mchua> alolita: from my side, I think the first thing on your end is

                 to figure out dates and locations, so we can figure out 
                 scheduling - and from our side working out the 
                 RHT-sponsorship-question-mark? stuff quaid mentioned, and 
                 seeing what kind of resources we can put towards that so we 
                 know what else we need to fill in.

Contents 1 roles to fill 2 Registration 2.1 How to apply 2.2 How to choose who comes 2.3 Once admitted 3 Assignments 4 Infrastructure and resources 4.1 Pre-POSSE communication exercises 4.1.1 IRC Exercise 4.1.2 Mailing List Exercise 4.1.3 Blog Exercise 4.2 Lab Setup 4.3 Tracking Our Professors 5 Branding 5.1 The POSSE Pledge 5.2 Specific branding requirements 5.3 Instructor requirements 6 Public Relations 7 Documentation and followup 7.1 In advance: tools 7.2 In advance: Instructor documenting 7.3 In advance: Student documenting 7.4 During: Instructor documenting 7.5 During: Student documenting 7.6 Where to put and find content 7.7 Raw docs section content to work from 7.8 template long explanation email

[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

• why I want to come
• what I want to get from POSSE
• what I think I will contribute to the classroom
• http://teachingopensource.org/index.php/POSSE_Pre-event_Survey

[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

• Begin a page for the specific POSSE, e.g. http://teachingopensource.org/index.php/POSSE_APAC_-_Nov_2009.
  • Include links to any planning information and useful content for the instructors and students.

[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

• Meetbot logs at http://meetbot.fedoraproject.org/teachingopensource-posse/
  • E.g. logs for the first POSSE APAC are at: http://meetbot.fedoraproject.org/teachingopensource-posse/, http://meetbot.fedoraproject.org/teachingopensource-posse/-zh, and http://meetbot.fedoraproject.org/fedora-websites .

[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")

[edit] template long explanation email

For future reference.

Hi! You're getting this email because you expressed interest in the upcoming Professors Open Source Summer Experience (POSSE) at RIT. I'll give a quick recap for folks who weren't at Friday's session, introduce the teachingopensource.org (TOS) community for folks who'd like to get a preview now, then explain how to apply for this summer's session.

Quick recap

POSSE is a weeklong bootcamp for professors (from any discipline) looking to get their students (in any discipline) involved in open source projects. Being able to dive in and be "productively lost" in the design, writing, coding, art, testing, marketing, infrastructure, etc. of a large-scale, real-world distributed project is a great skillset to have, but it can be a daunting one to figure out how to teach - which is where POSSE comes in.

Participants spend a week of intensive participation in selected open source projects, led by professors with experience in teaching open source development, in partnership with community members who have deep experience and insight. We will be spending the week immersed in a software community (in this case, the Fedora Project, http://fedoraproject.org), but professors from any discipline are welcome - although everyone will be exposed to code, we'll be working with individual participants to find the mode of contribution that works best for their subject. By the end of the session, participants should have a much better understanding of the workings of open source projects, and a strong network of contacts to lean on as they begin to bring students into the open source world.

More information is available at http://teachingopensource.org/index.php/POSSE - we're still preparing for the big publicity push, so be forewarned that the pages there are going to be rough for the next week or two - but basic data should be there.

The exact curriculum itself is highly improvisational - such is the nature of participating in an open source community - but the general outline looks something like this:

• Monday: How do I communicate with people? (IRC, wikis, mailing lists, cultural norms, where to find projects and how to choose a good one)
• Tuesday: Now that I can talk to people, how do I find the things they're working on and what I can help with? (Version control, setting up a build environment, ticket trackers)
• Wednesday: How do I commit my contributions back upstream? (making patches, packaging, the review process, release cycles)
• Thursday: Wednesday, continued.
• Friday: How can I bring what I've learned back into my teaching?

Get involved

If you can't wait for the summer to talk with other professors interested in these sorts of topics, join the Teaching Open Source (TOS) community (http://teachingopensource.org) - this is as simple as signing up for the mailing list and introducing yourself: http://teachingopensource.org/index.php/TeachingOpenSource_Mailing_List

There you'll hear people talking about experiences in their classrooms, collaborating on conference panel proposals on teaching open source, asking for advice on good tools to use, and so forth. We also blog at http://teachingopensource.org/index.php/Planet, which you can join here: http://teachingopensource.org/index.php/Planet_Feed_List.

As a bonus, you'll see all the conversations on POSSE planning and design go by, and get a sneak preview of what's coming up this summer (and why your bootcamp will end up with the design it has). We believe in radical transparency, so all the POSSE planning meeting transcripts, notes, discussions, decisions, etc. are out in the open, mistakes and all, so that anyone can see how a POSSE is put together.

Finally...

If you have any questions, please email me! Questions about POSSE, about teaching open source, about specific projects, about anything open-source related you might be interested in - my inbox is open 24/7, and if I can't answer a question, I'll connect you to an open source community member who can. (I've gotten a few such questions already, and they're great.)

--Mel