POSSE curriculum

From Teaching Open Source

Jump to: navigation, search
Note.png
This is still a work in progress! Readings need to be filled in and materials created, the prework and followup sections need to be written, and everything needs to be checked for sanity - but I think it's far along enough to release this as a somewhat useful draft that shows (as clearly as I can express) what we're thinking. If you're interested in the immediately previous incarnation of this curriculum, check out the whiteboard picture I drew last week or the IRC log from today while I was sprinting. Mel Chua 23:57, 15 September 2010 (UTC) {{{2}}}

(Short URL for this page: http://bit.ly/POSSECurriculum )

Schedule[edit]

Theme: Open Source Development and Teaching
Day: Monday Tuesday Wednesday Thursday Friday
9-10am Reading group: What is Open Source? What Open Source is about; intro to the Fedora project; our teaching model; learning plan for the week Reading group: FOSS project case studies' What are the different types and characteristics of project communities out ther for your students to contribute to? Reading group: POSSE Alumni blog reflections What have past POSSE professors thought during the week, and what have they gone on to do in their classrooms? Reading group: Handling flames and forks What do disagreements look like in open source, and how can we help our students cope with a sometimes unpredictably blunt world? Curriculum workshopping, part 3
10-11am Opening session Version control and build systems tool walkthrough Patches, pastebin, tickets, bots - and how to love your infrastructure team Reproducibility test - in the classroom Project presentations
11am-Noon Distributed Collaboration Fedora Classroom Learning IRC and collaborative text editing alongside Fedora contributors. Your first local commit, part 1 - picking a project and getting the code Finding a project - and keeping the scope sane Curriculum workshopping, part 2 Reflection and closing session
Noon-1pm Lunch and debrief in reading groups Lunch Lunch Lunch and curricular example discussion in reading groups
1pm-2pm IRC /wiki lab Working with colleagues exclusively online Your first local commit, part 2 - building a local instance Curriculum workshopping, part 1 Bus/Raptor proofing - leveraging project teams to future-proof your work
2pm-3pm Finding things out with information-hunting and question-asking strategies Documentation Manpages, documentation teams, and their workflows: how to find and conribute to them Picking pertinent problems - articulating your work in a way the community cares about Reproducibility test - remote
3pm-3:30pm Blogging and reflection Blogging and reflection Blogging and reflection Blogging and reflection
Evening Celebration dinner with local community members

Prework[edit]

Note.png
This section needs to be filled in more. Right now it's mostly random notes. Mel Chua 23:55, 15 September 2010 (UTC) {{{2}}}

Account creation: Everyone should get set up on the following.

Rough notes for things the instructors need to think about:

  • account creation
  • blog setup --> Planet
  • IRC exercise
  • travel logistics
  • onsite network setup
  • tool (remix) distribution
  • collect profiles (from applications)
  • reading distribution
  • schedule distribution

Monday[edit]

The basics[edit]

Theme: "Open"

Big idea: The ability to be "productively lost" in a FOSS project cannot be obtained through sheer increase in technical skill alone; the ability to communicate within a project's culture is a crucial skill.

Skill: Learn how to use the communication tools the community uses.

Learning objectives[edit]

The FOSSisms and practices/tools along the way are all aimed at achieving the day's learning objectives; FOSSisms and practices/tools may be adapted, added, and discarded along the way in order to get participants to achieve the learning objectives, but this is what we think will be useful ahead of time. Learning objectives are assessed via the day's #Deliverables.

Participants will...

  1. Independently find and engage with a FOSS community member in realtime to accomplish a task.
  2. Document and summarize that interaction in persistent public media.

FOSSisms we'll cover along the way

  • Productively Lost
  • You pay for teaching with documentation.
  • If it's not public, it didn't happen.
  • Radical Transparency

Practices and tools we'll use

  • IRC
  • mailing lists
  • wikis
  • blogging
  • Planet
  • information search strategies
  • FOSS project missions
  • the anatomy of a FOSS project
  • what makes a good question in the FOSS community context?

Deliverables[edit]

These deliverables are all meant to be formative assessments of the day's #Learning objectives.

TOS user page: Make a user page on the http://teachingopensource.org wiki. The catch is that you cannot edit your own user page and you cannot talk with people in person about it; you must get others to edit it for you via talking with them on IRC . We'll do this exercise during class and should finish it then, but if you want to polish your user page in the evening, you can do so. The deliverable consists of two things: the URL to your completed user page and the URL to the user page of the person you worked with.

Send a chat log to a mailing list: During class, we'll be helping you figure out a task to do and the questions you need answered to carry out that task, and helping you engage in a conversation with a remote community member to get the information you need(because we probably won't know the answers to your questions, but someone out there will).

POSSE participants may team up for the same conversation with the same person, but everyone must speak and engage and ask questions and respond to the community member. Lurking in everyone else's conversation is great, but you've got to speak up yourself or it doesn't count. ;-)

Your homework (which you may need to do after class depending on how much time your conversation takes) is to use that conversation and your chat log from it as a way to introduce yourself to the mailing list of your project's community. We'll look at sample list introductions during class. The deliverable in this case is the URL to the mailing list archive version of your introduction email to the list.

Blog post reflection: A blog post reflecting on the day; this blog post must hit the Planet aggregators for both Planet TOS and the Planet for whatever FOSS community you're working in this week, and include links to all your deliverables for the day (this is how you "turn stuff in." You'll get this same assignment every day this week. We'll have some time to start our blog posts at the end of the workshop today, but you'll likely have to finish this in the evening (after you've had time to reflect on the day over dinner).

Other things we'll be doing today[edit]

  • Reading group: the history of FOSS, FOSS licensing
  • Introductions - who's here, why are you here? (hand out profiles attendees submitted ahead of time, do project poster drawings)
  • Intro to the specific project you'll be working within for the week
  • List out the group's personal learning objectives for the week
  • Reflection cards
  • Blogging time at the end

Resources[edit]

Reading group readings

Past deployments of this unit[edit]

Tuesday[edit]

The basics[edit]

Theme: "Source"

Big idea: To work with an open source community, you have to be comfortable working with source code, whether that is code, images, documentation, or something else.

Skill: Learn how to use the collaborative version control and build tools your community uses.

Learning objectives[edit]

The FOSSisms and practices/tools along the way are all aimed at achieving the day's learning objectives; FOSSisms and practices/tools may be adapted, added, and discarded along the way in order to get participants to achieve the learning objectives, but this is what we think will be useful ahead of time. Learning objectives are assessed via the day's #Deliverables.

Participants will...

  1. Find and evaluate activity in a FOSS project in your area of interest.
  2. Download and install the code needed for that project's development/contribution environment, using external resources (including realtime communication) to supplement and improve external documentation.
  3. Make and test a local commit.

FOSSisms we'll cover along the way

  • Ask forgiveness, not permission.
  • Branches are free.
  • Keep a history.
  • Begin with the finishing touches. (Also known as: don't reinvent the wheel, stand on the shoulders of giants, and scope a small project first.)
  • It's not what you know, it's what you want to learn. (You're already good enough to contribute to FOSS.)

Practices and tools we'll use

  • basic text editors
  • revision control
  • build systems
  • manpages and other forms of provided/formal docs
  • documentation team workflows

Deliverables[edit]

These deliverables are all meant to be formative assessments of the day's #Learning objectives.

Local commit: Make a visible modification to a running instance of your open source project on your machine. If you're working on code, this might be a bugfix that you've gotten to run locally; if you're working on design, this might be a UI change running in your application; if you're working on documentation, this might be a Publican-rebuilt instance of the install manual with a section you wrote added in - we'll help you scope out a realistic first fix.

Note that this commit may not be what you work on for the rest of the week - we're trying to learn the mechanics of making a local change, and it doesn't really matter what that change is. Tomorrow we'll be picking our projects for the remainder of the week, and your project/problem choice will be important then, but right now you're just trying to learn the mechanics of how to make a change at all.

Your deliverable here is some form of documentation on your blog post reflection (your second deliverable, below) of what you did and how you did it. This is pretty free-form, but screenshots are your friend! You don't have to write reproduction instructions yet (you'll do this tomorrow if you choose to continue with your fix today), but reproducibility is not a bad thing to think about.

Blog post reflection: A blog post reflecting on the day; this blog post must hit the Planet aggregators for both Planet TOS and the Planet for whatever FOSS community you're working in this week, and include links to all your deliverables for the day (this is how you "turn stuff in." You'll get this same assignment every day this week. We'll have some time to start our blog posts at the end of the workshop today, but you'll likely have to finish this in the evening (after you've had time to reflect on the day over dinner).

Other things we'll be doing today[edit]

  • Reading group: FOSS project case studies
  • Blogging time at the end

Resources[edit]

Reading group readings

  • FOSS project case studies (need to find these!)

Past deployments of this unit[edit]

Wednesday[edit]

The basics[edit]

Theme: "Development"

Big idea: The small local changes we make can become part of a big difference if we know how to move our work upstream.

Skill: Making our work findable and reproducible by others.

Learning objectives[edit]

The FOSSisms and practices/tools along the way are all aimed at achieving the day's learning objectives; FOSSisms and practices/tools may be adapted, added, and discarded along the way in order to get participants to achieve the learning objectives, but this is what we think will be useful ahead of time. Learning objectives are assessed via the day's #Deliverables.

Participants will...

  1. Find and scope a task of interest to the FOSS community you're working within.
  2. Announce and share your progress/needs to others via public channels.

FOSSisms we'll cover along the way

  • Release early, release often.
  • Show me the code.
  • With enough eyeballs, all bugs are shallow.
  • Being Present

Practices and tools we'll use

  • issue trackers
  • pastebin
  • patches
  • infrastructure team workflows
  • IRC logging bots

Deliverables[edit]

These deliverables are all meant to be formative assessments of the day's #Learning objectives.

First patch, release 0.1: You are working towards your first upstream contribution, possibly based on the local change you made yesterday, or perhaps on a different problem entirely. The first part to this is picking the right problem. By the end of Thursday - yes, Thursday - you're going to be wrapping up your project and trying to persuade other people to pick up on your work. This will be much easier if you're working on a problem that other people care about solving and are willing to build upon your efforts for - or more likely, if you choose to help on a problem that other people are already working on, and build upon their efforts on it so they can integrate your contributions into their ongoing development. So put some consideration into your problem choice, and consult with community members online to see if it's something they're eager to help you with. "What can I do in the next 3 days to help you?" are magic words to any member of the open source community.

Now that you've picked the right problem, scope out a first guess at a realistic amount of work (your first guess will almost always be wrong, but it's easier for people to help edit an inaccurate guess than it is for them to tell you what to do from scratch) and plunge in. See how far you get before you're stuck. When you get stuck, don't bang your head against the wall. After trying the resources you know about to figure it out on your own, ask the community. We'll cover how to do this in class, and we'll also repeatedly come around to help you with this.

Towards the end of the day, step back and see where you're at. Perhaps you got the code to work, or you didn't quite, but you should aim to know exactly where you're stuck and what sort of help you need. Now the question is how to get other people to use your improved code, or the buggy code you found that you'd like them to check out and hopefully fix. In short, you'd like them to unstick you. This is the final deliverable you will be making.

This deliverable can be thought of as making and putting out reproduction instructions for your patch - or whatever contribution you're trying to push upstream. Where are you, what have you done, and how can someone else get to the same place? (And why should they care?) You're putting your reproduction instructions out tonight so people have some time to see them (get your work "on their radar," so to speak) and it'll be easier for you to find and work with community members on your patch in realtime tomorrow.

As usual, you'll hand in this assignment by blogging about the URLs to the things you've created in upstream resources. Some things you might consider:

  • An open ticket with your commentary/work/patches linked into it
  • A patchfile
  • A screenshot/screencast of your working version (you can cite your post from yesterday)
  • A link to a running sandbox instance of your code
  • A wiki page with HOWTO instructions on how to use what you've just made
  • Mailing list post archives where you're discussing your work and asking questions about how to get unstuck on the next step you're heading towards
  • IRC logs of discussions you've had with community members about your project

Remember, the communication is just as important as the code. When we say "show me the code," we do need the code - but we also need to be shown that code in such a way that we'll understand how to use it!

Blog post reflection: A blog post reflecting on the day; this blog post must hit the Planet aggregators for both Planet TOS and the Planet for whatever FOSS community you're working in this week, and include links to all your deliverables for the day (this is how you "turn stuff in." You'll get this same assignment every day this week. We'll have some time to start our blog posts at the end of the workshop today, but you'll likely have to finish this in the evening (after you've had time to reflect on the day over dinner).

Other things we'll be doing today[edit]

  • Reading group
  • Project Workshopping, session 1
  • Blogging time at the end

Resources[edit]

Reading group readings

  • POSSE alumni blog reflections (need to select from POSSE Blogs, can change for each POSSE depending on focus/interest)

Past deployments of this unit[edit]

Thursday[edit]

The basics[edit]

Theme: And (development, continued)

Big idea: Our work isn't done until it can live without us.

Skill: Letting go.

Learning objectives[edit]

The FOSSisms and practices/tools along the way are all aimed at achieving the day's learning objectives; FOSSisms and practices/tools may be adapted, added, and discarded along the way in order to get participants to achieve the learning objectives, but this is what we think will be useful ahead of time. Learning objectives are assessed via the day's #Deliverables.

Participants will...

  1. Get someone remote to reproduce and test their work.
  2. Cleanly wrap a project.

FOSSisms we'll cover along the way

  • Bus/Raptor proofing
  • The easier your project is to fork, the less you'll be impacted by forks.

Practices and tools we'll use

  • Advanced wiki usage (templates, etc)
  • Marketing team workflows
  • QA team workflows
  • i18n team workflows
  • Release cycles
  • Events and hackathons

Deliverables[edit]

These deliverables are all meant to be formative assessments of the day's #Learning objectives.

Project wrap-up: Do what you have to do to make it possible for someone to pick up on the work you started this week. If possible, try and persuade a specific community member to do something with the work you're doing - this may be hard, but it's ultimately what you're aiming for. (This will be easier if you chose a problem to work on that the community is interested in at the beginning of the week.) Do this even if you plan to continue the work yourself - it's good to tie up loose ends and make your work easy for others to pick up at any point, no matter what. Sometimes you'll be surprised by others stepping in to help out.

By this point in time you should have a clear enough idea of your project and the community to be able to ask people how to wrap things up, but one good practice we'd recommend is to get someone remote to read your wrap-up and comment on it, even if they're not going to pick up on your project. Ask them what parts are missing, what would make it easier for someone else to find this and continue with it later. As usual, document what you're doing on your blog.

Blog post reflection: A blog post reflecting on the day; this blog post must hit the Planet aggregators for both Planet TOS and the Planet for whatever FOSS community you're working in this week, and include links to all your deliverables for the day (this is how you "turn stuff in." You'll get this same assignment every day this week. We'll have some time to start our blog posts at the end of the workshop today, but you'll likely have to finish this in the evening (after you've had time to reflect on the day over dinner).

Other things we'll be doing today[edit]

  • Reading group
  • Project Workshopping, section 2
  • Compiling a "diff list" of the FOSS and academic worlds
  • Looking at student work examples
  • Looking at curricular examples
  • Blogging time at the end

Resources[edit]

Reading group readings

  • Handling flames and forks

Other resources

  • Student work examples
  • FOSS/academia diff list

Past deployments of this unit[edit]

Friday[edit]

The basics[edit]

Theme: Teaching

Big idea: It's possible to bridge the academic and open source worlds and bring the things you've learned this week into your teaching - we just need to be a little deliberate about it.

Skill: Joining the community of practice of people teaching open source community participation in an academic context - the Teaching Open Source community.

Learning objectives[edit]

The FOSSisms and practices/tools along the way are all aimed at achieving the day's learning objectives; FOSSisms and practices/tools may be adapted, added, and discarded along the way in order to get participants to achieve the learning objectives, but this is what we think will be useful ahead of time. Learning objectives are assessed via the day's #Deliverables.

Participants will...

  1. Make plans for the future, which may include modifying existing or planned course to include the FOSS practices you've learned this week, advocating for resources and infrastructure from various sources (institutional, grant-based, FOSS community based, industry), organizing a presence for your institution at a FOSS or academic event, or others.
  2. Share your efforts and ideas with TOS and FOSS communities.

FOSSisms we'll cover along the way

  • It's okay for people to be disappointed, but not okay for them to be surprised.
  • Being Present - and opportunistic.
  • Being pleasantly surprised.

Practices and tools we'll use

  • events
  • hackfests
  • funding/infrastructure sources
  • Legitimate Peripheral Participation
  • Zone of Proximal Development
  • scaffolding - and how to explain it to others
  • The nitty-gritty of teaching open source
    • What's hard about it?
    • How to schedule it?
    • Feedback, grading, and evaluation
    • How to explain academia to FOSS community members

Deliverables[edit]

These deliverables are all meant to be formative assessments of the day's #Learning objectives.

A place for FOSS efforts at your institution: Have a home for your web that answers the question "if I'm interested in what's happening in the FOSS world at this school, where do I go to find that out?" In its simplest form, this looks like a wiki page on the TOS wiki with some notes on your institution and the sorts of things you do and can support. If you're attending the workshop with your colleagues, you should all work together on the same deliverable. If your institution already has a gathering place for FOSS presence, add to it! We will spend an hour in-class working on it today, during which you should be able to start and finish everything; however, if you'd like to start earlier or continue your work later, that's more than welcome.

What's Next? We'd like to hear your thoughts on how this workshop has influenced what you might be doing with your teaching in the next 2-5 years. Concrete ideas for student engagement are ideal - how could you work this into courses you're teaching, how could you support student projects, are there other faculty members in your institution - or others, including people you've met at this workshop - who you want to reach out to and collaborate with, events that would make good milestones to collaborate on things (for instance, "why don't we do a workshop at SIGCSE?") and so forth.

These aren't commitments - we're just exploring options together, brainstorming, and seeing where people are headed so we can figure out how we can help each other. (If your ideas rely on things like infrastructure, equipment availability, hackathon funding, community members with specific expertise available to participate with your class in a certain way - write those down. The most important thing you can bring is a wish list; you might think of this deliverable as a proposal for resources and support.)

You don't have to blog this deliverable, unlike the others. We encourage you to share what you can in your final public blog post; if there are things you can't share publicly, try posting them to your POSSE session's mailing list, or simply bring them for discussion during the last day.

Blog post reflection: Your final public reflection. What are your plans? What have you learned? What was surprising? What did you think of the experience overall? We'll give you some time to write this during the session, but it's and ask that you post it by the end of the weekend

Other things we'll be doing today[edit]

  • Reading group
  • Review our list of objectives from the start of the week
  • Common infrastructure, Spins, and the TOS Textbook
  • Discussion on the Teaching Open Source community, its projects, and upcoming events
  • Figuring out where we want to go from here
  • Workshop feedback
  • Blogging time at the end

Resources[edit]

Reading group readings

  • Curricular examples

Other resources

Past deployments of this unit[edit]

Followup[edit]

Note.png
This section needs to be filled in. I'm not sure what goes here yet, we haven't thought very deeply about what followup should look like. Mel Chua 23:54, 15 September 2010 (UTC) {{{2}}}

Sebastian Dziallas and I are working on a set of POSSE modules in order to see if the curriculum can be delivered remotely. Mel Chua 18:42, 8 January 2011 (UTC)

Day Template[edit]

Note.png
This is the template that's common to each day of the curriculum. {{{2}}}

The basics[edit]

Theme: One-word theme

Big idea: One-sentence takeaway from the day. What should participants internalize, if there's nothing else they get from the day?

Skill: What's the crucial skill they need to learn to grasp the big idea?

Learning objectives[edit]

The FOSSisms and practices/tools along the way are all aimed at achieving the day's learning objectives; FOSSisms and practices/tools may be adapted, added, and discarded along the way in order to get participants to achieve the learning objectives, but this is what we think will be useful ahead of time. Learning objectives are assessed via the day's #Deliverables.

Participants will...

  1. Learning objective
  2. Learning objective

FOSSisms we'll cover along the way

  • FOSSism
  • FOSSism

Practices and tools we'll use

  • practice
  • practice
  • tool
  • tool

Deliverables[edit]

These deliverables are all meant to be formative assessments of the day's #Learning objectives.

Deliverable name: Instructions go here.

Blog post reflection: A blog post reflecting on the day; this blog post must hit the Planet aggregators for both Planet TOS and the Planet for whatever FOSS community you're working in this week, and include links to all your deliverables for the day (this is how you "turn stuff in." You'll get this same assignment every day this week. We'll have some time to start our blog posts at the end of the workshop today, but you'll likely have to finish this in the evening (after you've had time to reflect on the day over dinner).

Other things we'll be doing today[edit]

  • Reading group
  • Other topic
  • Other topic
  • Blogging time at the end

Resources[edit]

Reading group readings

  • reading
  • reading
  • other resource
  • other resource

Past deployments of this unit[edit]

  • Link to specific POSSE day summary
  • Link to specific POSSE day summary