POSSE is a bootcamp sponsored by Red Hat designed to immerse computer science instructors in open source projects, with the commitment that each participating instructor bring their classes into open source project participation over the next school year. More details on the program are available at http://teachingopensource.org/POSSE.
Contents
Join us!
There is no cost to attend a POSSE, though attendees are responsible for their own travel, lodging, and expenses. Apply today – it just takes 1 email, 10 questions, and less than 30 minutes.
More information for attendees (directions, hotel recommendations, parking/transport logistics, etc) is available at the POSSE South Africa attendees page.
Resources
- A boardroom with movable tables and chairs for the event
- A projector
- A wifi AP (attendees would have to come with their laptops/netbooks)
Press
Watch this space during POSSE week for coverage by the media.
Blogs
Watch this space during POSSE week for blog posts by POSSE participants and instructors!
Jan Wildeboer – day 1: http://jan.wildeboer.net/2010/10/possesa-posse-south-africa-day-1/
Grant Hearn – the week: http://wilhelmrudolf.wordpress.com/
Follow the POSSE
There are a number of spaces where POSSE participants interact aside from the physical location – IT Dept@CPUT, Cape Town Campus.
- Wiki: this POSSE is using the TeachingOpenSource wiki space. Please feel free to edit any of these pages. If you’re creating new pages, please prefix the page title with “POSSE South Africa.”
- IRC: The channel on Freenode will be used for POSSE-specific IRC communication. Participants are encouraged to join the larger TeachingOpenSource community in the #teachingopensource as well.
- Mailing list: Join the teaching open source mailing list for discussion and ongoing session notes.
- Identi.ca/Twitter We are using the hashtag #possesa for our dents and tweets, http://identi.ca/tag/possesa and http://twitter.com/search?q=%23possesa
- Photos: If you’re taking photos of the event, please post them here! Antoine’s photos
Event information
Sponsor
Dates
October 3-8, 2010
Location
The venue is the Department of Information Technology, Cape Peninsula University of Technology, Cape Town Campus.
Instructors
- Mel Chua, Red Hat
- Jan Wildeboer , Red Hat
- Pierros Papadeas, Fedora
Participants
Professors
- Michael Adeyeye, CPUT
- Boniface Kabaso, CPUT
- Kruben Naidoo, CPUT
- Grant Hearn, University of Western Cape, South Africa
- Michael Graaf, University of Cape Town
- Olutayo Boymbode, University of Cape Town
Guests
We also had a number of guests from the open-source community dropping by throughout the week.
- Antoine van Gelder, 7 degrees
- Stefano Rivera, Wiki
- Michael Graaf, University of Cape Town
Attendees for this POSSE are still being selected – if you’re interested, please apply!
Posters
These are self introductory posters drawn by each participant. Sweet!
|
 Michael Adeyeye |
 Grant Hearn |
 Jan Wildeboer |
 Mel Chua |
 Pierros Papadeas |
|
 Michael Graaf |
 Boniface Kabaso |
 Tayo Boyinbode |
Syllabus
Schedule
| 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 |
Monday
Monday basics
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.
Monday learning objectives
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…
- Independently find and engage with a FOSS community member in realtime to accomplish a task.
- 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?
Monday activities
- 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
Monday deliverables
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).
Monday readings
Monday’s reading load is more theoretical and historical than the rest of the week. It’s also heavier than the rest of the week, since you’ll have multiple days beforehand to look through the material.
- What is Free Software
- The Free Software definition
- The Open Source definition
- The Wikipedia page on Open Source
- The Cathedral and the Bazaar (also known as “catb”). We recommend the following sections:
Monday resources
To be posted as we go along throughout the day.
From the Fedora Classroom session
- Fedora Classroom session advertisement and follow-up posts
- minutes and full log, generated by Zodbot
- http://piratepad.net/possesa (an instance of etherpad)
- Fedora Classroom
Monday output
Tuesday
Tuesday basics
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.
Tuesday learning objectives
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…
- Find and evaluate activity in a FOSS project in your area of interest.
- 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.
- 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
Tuesday activities
- Reading group: FOSS project case studies
- Blogging time at the end
Tuesday deliverables
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).
Tuesday readings
Tuesday resources
To be posted as we go along throughout the day.
- Community characterization worksheet
Tuesday output
Wednesday
Wednesday basics
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.
Wednesday learning objectives
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…
- Find and scope a task of interest to the FOSS community you’re working within.
- 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
Wednesday deliverables
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).
Wednesday activities
- Reading group
- Project Workshopping, session 1
- Blogging time at the end
Wednesday resources
To be filled in as the day goes by.
Wednesday readings
These are blog posts by past POSSE participants.
- Karl Wurst, Worcester State College: post on Day 2, getting source
- Mihaela Sabin, University of new Hampshire, on starting her project
- Dave Shein, RIT, on the feeling of being stuck
- Michael Riordan, RIT, on communication
- Mel Chua, Red Hat, on non-code contributions
- Al Biles, RIT, showing off the patch his team contributed
- Matt Jadud, Allegheny College, on tracking community, student blogging, and how open source can tie into faculty evaluations. Matt went on to guide 40 first-year students into open source the next year, and is now teaching an interaction design course with the Fedora Design team.
- Christian Jacobsen on packaging and confusion; Christian and Matt have also open-sourced their research on parallel programming languages, with great results.
Wednesday output
Thursday
The basics
Theme: And (development, continued)
Big idea: Our work isn’t done until it can live without us.
Skill: Letting go.
Learning objectives
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…
- Get someone remote to reproduce and test their work.
- 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
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
- 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
Reading group readings
- Handling flames and forks
Other resources
- Student work examples
- FOSS/academia diff list
Past deployments of this unit
Friday
The basics
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
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…
- 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.
- 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
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
- 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
Reading group readings
- Curricular examples
Other resources
Past deployments of this unit
Planning
Anyone is welcome to help organize and plan this POSSE. Please see POSSE South Africa Planning for details.
Category: