[TOS] POSSE mini + remote modules - first format draft, feedback requested

Mel Chua mel at redhat.com
Sat Jan 8 20:07:56 UTC 2011


Over the past year of POSSE, we've constantly gotten asked "so, can you 
do this remotely?" We thought about what we'd need to do to make POSSE 
more remote and flexible (since professors are often under severe time 
and budget crunches) without compromising the quality of the experience. 
This is what Sebastian and I have been working on for the past few days, 
and we'd like feedback.

What we've done is to split the existing curriculum into a one-day 
one-day in-person kickoff session (~5 hours of instruction), and then 
require a (remote) curriculum comprised of bite-sized modules. Note that 
each module is capped at 5 hours of student work (usually around 2 hours 
of (IRC-based) instruction + 3 hours of exploratory "homework"), for a 
total of 25 hours for the core modules + 10 hours for electives (a 
minimum of 2 required). Attendees finish with a "capstone" of attendance 
at a conference with a significant TOS presence (SIGCSE, FIE, OSCON). 
Total time required: 40 hours + conference. It'll take more than a week 
- maybe it'll even take a year - but this might be more flexible and 
manageable for academics.

We've listed the modules along with short course descriptions at 
http://teachingopensource.org/index.php/POSSE_modules#Elective_modules.

Page text below for your convenience, but feel free to edit directly. 
Our main questions to you: does this resonate with you? Are the course 
descriptions what you'd consider important, and do they sound like ones 
you'd like to take? (Which ones sound particularly good, and which ones 
don't excite you at all? Are we missing any?)

We're experimenting with the current draft in Doha this week, so a lot 
of changes will happen in the next few days, and we'll keep you posted.

Thanks,

--M & S

---

== Introduction ==

As an experiment in an alternative delivery of the [[POSSE curriculum]], 
we're experimenting with delivering a one-day on-site [[POSSE mini]] 
intensive, requiring attendees to participate in a number of 
remote-participation modules afterwards, and then (possibly) ending with 
an in-person workshop at an existing open source or academic conference 
to present one's work in order to be certified as a [[POSSE alumni]].

== POSSE 001 - POSSE intensive ==

'''Attendance required.'''

''Curriculum writeup coming shortly; this is a one-day intensive focused 
on "the open source way" paradigm shifts and basic communication skills 
necessary to participate in the core modules.''

== Core modules ==

'''All core modules must be completed.''' Modules are open to members of 
the public and to interested faculty who have not been to a POSSE 
intensive, but only modules completed after attendance at a POSSE 
intensive will count towards graduation. Students of POSSE professors 
are also welcome to attend these modules.

=== POSSE 002 - The first 15 minutes: how to approach a new project ===

The class will select any open source project the instructors are 
unfamiliar with, whereupon the instructors will do an on-the-spot 
[http://blog.melchua.com/2010/10/08/possesa-fri-5-minutes-of-improvisation/ 
walkthrough] of how they'd get started as a new contributor to that 
community. Then participants will take their turn.

=== POSSE 003 - Release early, release often: feature and release 
processes ===

What is a release cycle, how is it useful, and how do I make it do work 
for me? We'll take an existing feature proposal from an open source 
community and improve it, then discuss how this feature will become 
reality and how you can bring your own ideas through the same process.

=== POSSE 004 - Upstreaming: Version control and the commit cycle ===

We will cover the checkout-build-modify-commit cycle using the popular 
git version control system. Participants will learn how to use git (no 
prior experience with version control is required) to submit a simple 
patch to a live open source repository.

=== POSSE 005 - Trackers and tickets ===

How do open source communities keep track of what needs to be done and 
who is doing what without top-down oversight? How can new contributors 
find bite-sized projects to work on? We will show you 
[http://wiki.sugarlabs.org/go/BugSquad/Bug_Report how to use ticket 
trackers] as a way to interact with upstream developers, taking you 
through the lifecycle of a ticket. Tickets are also not necessarily well 
categorized or clearly written, so we'll introduce strategies successful 
contributors use to deal with and buffer that ambiguity.

=== POSSE 006 - How to be lazy: marketing, recruitment, blogging, and 
building momentum ===

A successful open source project will be able to continue even after the 
original contributors have moved on. How do you make your contributions 
and run your projects in a way that maximizes the chance that other 
people can and will pick up on them? We will show you the art of making 
other people excited about doing your work for free.

== Elective modules ==

'''At least two elective modules must be completed.''' Modules are open 
to members of the public and to interested faculty who have not been to 
a POSSE intensive, but only modules completed after attendance at a 
POSSE intensive will count towards graduation. Students of POSSE 
professors are also welcome to attend these modules.

=== POSSE 011 - Remixability: Licensing and IP ===

What open source licenses are available, how do you choose one, and what 
university IP restrictions might you need to keep in mind when starting 
to work with projects that require open licensing?

=== POSSE 012 - Deploying with your local community: QA, support, and 
town-gown relations ===

How to be an interface between an open source project and a local 
client. Ideal for schools that already have a local social service 
requirement that involves students consulting with nearby organizations 
to implement a technical solution to one of their problems.

=== POSSE 013 - Getting your code used: packaging and distribution ===

What is a package management system, and how can it make it dramatically 
easier for others to find and use your code? How does code get into the 
lists of "official" software for various large-scale open source 
projects such as Fedora, Ubuntu, Mozilla (Firefox plugins), etc?

=== POSSE 014 - Distributed team dynamics: timezones, language, culture, 
and running excellent meetings ===

You've never met your team in person, none of them speak the same 
language natively, and any meeting time you choose is at 3am in the time 
zone of a crucial contributor. These things are actually advantages - 
we'll show you why.

=== POSSE 015 - Documentation: working within and with technical writing 
teams ===

User manuals, guidebooks, manpages, installation guides, and more. This 
course is for people interested in contributing to technical writing 
within an open source project, as well as for non-designers who want to 
learn how to take advantage of writing talent for their projects. We 
will also cover translation workflows.

=== POSSE 016 - Design and graphics: working within and with 
interface/design teams ===

Based on Mo Duffy's 
[http://opensource.com/education/10/4/introducing-open-source-middle-school 
design curriculum for middle school students], we will survey basic open 
source graphic tools and talk about how look, feel, and branding get 
designed "the open source way." This course is for people interested in 
contributing to the design team of an open source project, as well as 
for non-designers who want to learn how to take advantage of design 
talent for their projects.

=== POSSE 017 - Infrastructure: working within and with project sysadmin 
teams ===

Did you know that you can get free server space, computing power, 
bandwidth, mailing lists, and more from the infrastructure teams of open 
source projects you contribute to? We'll show you what resources are 
available and how to access them. For those who are interested in 
contributing as a sysadmin, we'll get you started with your project's 
infrastructure team - or show you how to start one.

=== POSSE 018 - Back to school: assignments, grading, and other 
classroom strategies ===

Learning how to contribute to an open source community is all well and 
good, but how do you make this experience fit into a classroom context? 
We'll cover assignment development (including sharing existing homework 
assignments from professors who are already teaching open source 
participation to their students), classroom management and grading, 
student motivation, expectation-setting and course evaluations, how to 
sync semester and release cycles, and field questions about how guiding 
your students through a world that's impossible to predict actually 
works in practice.

=== POSSE 019 - Attending events ===

Open source events sometimes look very different from the academic 
conferences you may be used to. Learn how to get the most out of the 
next open source event you attend. We'll cover what a typical hackathon 
and unconference experience looks like, and compile a list of specific 
recommendations for engaging with other attendees based on the 
event-attending goals of participants and upcoming events they may be 
going to. We'll also discuss hosting an open source event on your own 
campus, and what it takes to pull one together; it's often less work 
than you think.

== POSSE 007: Final workshop ==

The design for this is tentative.

Definite:
* Half or full day (minimum 5 hours of instruction)
* In conjunction with an existing open source or academic event with 
significant TOS presence, whether that's part of the official program or 
as a separate and independent event immediately adjoining.
** OSCON
** FIE
** SIGCSE
* Attendance at the accompanying conference will be required as part of 
the workshop experience.
* Post-event graduation dinner.

Tentative:

* Trial run at/before OSCON (July) 2011 in Portland, Oregon, USA
* The remainder of the curriculum design. Should attendees present the 
work they've done throughout the modules they've completed, share course 
plans, etc?
* How do we decide whether people "pass" (how strict should the criteria 
be?)



More information about the tos mailing list