Welcome, POSSCON attendees! This blog post is the virtual home of the talk Sebastian Dziallas and I (Mel Chua) did on Thursday afternoon, titled Curious Artifacts: Making FOSS Materials Make Sense To Learners. Our talk materials were, in large part, created with the audience.

The goal of the talk was to get audience members to actually look at live open source projects and start analyzing how those projects might fit into a high school or college classroom. When you look at a project, what cool things grab you, and what sort of little annoyances irk you? How can we turn them into the sorts of mini-project-opportunities students can tackle, and how do we build materials and scaffolding around those tasks that can be used as scaffolding – worksheets, reading, discussion prompts, homework assignments, grading rubrics?

This is a big job – so the trick was that our POSSCON talk started on Thursday… and was the kickoff to a conversation we continued online. Our intrepid audience volunteer Kevin came up and modeled the beginning of a first-contribution conversation using the original bounty Sebastian posted on Tuesday night, then the crowd split into teams and attacked printouts of FOSS artifacts with red and blue pens and highlighters. And smiley face stickers. Always gotta have the smiley face stickers. The audience critiques are available here (pdf).

Here’s the flyer that was handed out during the talk in lieu of slides (available in pdf and odt format for remixing) to guide participants through some of the tools, terminology, and cultural quirks they’d be encountering as they looked through the material to critique.

One big analogy used throughout the talk was open source as a cultural immersion experience similar to study abroad. This theme was used for the beginning and end. Some key points made:

• Study abroad is not just about taking the same math class in Paris that you could take back in Wisconsin. It’s about the experience of being in Paris – language, culture, transit system, food – math class is almost incidental. It’s the same way for open source. Students need to watch, appreciate, be prepared for, and make time for things outside their course material in order to really benefit from the experience.
• You’ll be in an unfamiliar environment. Simple things will be awkward at first – ordering a glass of water, fixing a simple bug. Keep going – yes, you could order water in English, but you’re in China so you can learn how to do it in Mandarin! It does get much, much easier after the first time or two.
• The point is to get out and experience the culture. Immerse yourself. Don’t just hang out with other expats or foreign students. Whenever possible, bring your students into the real world, real conversations, real materials… the point isn’t memorizing all the Italian verb conjugations perfectly, but to communicate with someone in Italian, no matter how broken. You’ll learn through conversation, so get out there and talk!

If you were at our POSSCON talk and want to add materials – comments, pictures, thoughts, anything – to this post, leave a comment.

Thanks for listening!

–Mel and Sebastian

Some pictures from the talk courtesy of Zenith Chua (thanks, Mom!)

Our brave audience volunteer Kevin explains his critique of Bug #180 in the Fedora QA trac.

An audience review of the Fedora Design team's meeting logs and bounties. I believe smiley face stickers were involved.

Verdict: Sugar on a Stick's websites contain way too many unexplained acronyms. We should do something about that.

Sugar is too hard to download and install. Walter was recently surprised to hear (during an interview) that even “advanced users” (I’m assuming he meant the computer-savvy who were new to Sugar in particular) had difficulty with our installation instructions, so he went and did something about it.

Walter’s new revision draft is meant to be an improvement over the current Downloads page (last edited August 21, 2010).

I offered to try and drum up some testing to see if this is actually an improvement, and what remaining rough edges need to be sanded off. The catch is that most of us can’t help with this directly, since we probably already have Sugar running on our machine and are used to getting around the current install instructions to make it work. Therefore! Here’s what you can do to help.

If you’re a Sugar old-timer and can figure out the new install instructions with no trouble:

Congratulations, you’ve learned how to work around our existing documentation! Find yourself some newcomers and sit down with them and work through instructions below in person – remember to send things to the iaep list so we can all learn from it!

And remember, when they’re looking at the page, don’t say anything – don’t take the keyboard from them, don’t do things for them, don’t interrupt them. They’re doing very important work – the work of telling us exactly where the shortcomings in our documentation are. When they point them out, help them by fixing the documentation together and then allowing them to continue proceeding by themselves.

If you’re new to Sugar or think the install instructions are hard to understand:

You are exactly the kind of person whose help we need. See, most of us have been using Sugar so long we’ve forgotten what it’s like to be a new user puzzled by install instructions – we’ve lost the ability to improve them because we’ve gotten too used to how difficult they are to understand. Here’s what we’d love help with.

1. Check out the proposed redesign for the download/install page.
2. Try to get Sugar running – whatever platform you have, whatever means you’d like to use. Do not ask for help yet, even if you’re getting stuck. We’re trying to find out whether the instructions on that page – and linked from that page – are sufficient to enable folks to get through the installation on their own.
3. If you do get stuck, write down (or take a screenshot and circle) everything you can think of about what’s confusing about the page, what you had to take a guess at, and as much as you can describe about where and why you’re stuck. This is incredibly valuable feedback that only you can give – you’re showing us how our documentation can be improved, pointing out things we don’t realize we ought to fix – until you come along and tell us. (If you manage to make it through to the end, this sort of feedback on how it could have been better is valuable anyway – but you can also skip to step 5).
4. Now that you have these notes written up, take them and send them in an email to the it’s an education project mailing list (iaep at lists dot sugarlabs dot org). If you cc me (mel at sugarlabs dot org) on the email, I’ll make sure your feedback gets looked at and brought to the right people.
5. After you send that email, someone should come along and help you finish the installation. When you have Sugar working on your machine, if you can drop us a line again (on the iaep mailing list, and cc me) so we know you were taken care of and that things are working for you now, we’d very much appreciate knowing that you’re all set.

Thank you!

We spent most of our time on the next big urgent milestone: getting testable Sugar 0.90 images out the door for upstream Sugar QA. This isn’t an official SoaS release, but since SoaS is an easy way to get an instance of Sugar up and running, it’s great for testing, and since we’re going to include the 0.90 release of Sugar anyway, Simon has asked us to include it in our test builds by a certain date so it can be used to test the Sugar environment itself. By “certain date,” I mean that the 0.90 Beta release is this Wednesday; here’s what has to happen preferably before then. (For the Fedora folks in the audience, SoaS is a Fedora Spin.)

1. Simon updates the sugar, sugar-toolkit, sugar-datastore, sugar-presence-service, sugar-artwork, telepathy-gabble and telepathy-salut packages in Fedora to the correct code versions.
2. Mel gets 3 people to test these packages and give them karma in Fedora’s system, which will put them in the stable repositories. I’ll be writing instructions on how to do this shortly.
3. Simon or Peter or someone takes the next daily build and makes sure it boots, then announces the test image.

What this means for you, o reader: if you run Fedora (or can run Fedora in a VM, or can follow written instructions on how to do exactly this), you (yes, you!) can help us with 0.90 testing this week. We’re going to have instructions for this coming out once the code is ready to be tested; it should take less than 2 hours (hopefully less than 1) to do your setup and testing from start to finish, and you won’t need any prior experience. We’ll be using the same test setup for Sugar in the future, too.

The catch is that because we’re under intense time pressure to meet release deadlines, the time between when we can say “we’re ready! We need help!” and when we need the testing finished by is going to be VERY short. So this is a heads-up letting folks know this call is going to be coming.

Stay tuned for more QA news in Sugar land! (dun dun DUNN!)

This blog post written under more sleep deprivation than is probably good for me. I’m going to go to bed now so I’ll be more useful in the morning.

• Local Labs TM applications can’t be found, so we’ll drop this topic until a Local Lab is indeed blocked by lack of TM permission, at which point they should ping SLOBs (via emailing the slobs and iaep lists with their request – doesn’t have to be formal, just needs to be publicly documented somewhere) so we can +1 them. DONE!
• Oo4Kids logo display request got 4 +1s from SLOBs, granted. Added to the list of trademark permissions granted. APPROVED!
• F11+0.88+XO-1.* got permission to use SL infrastructure and get listed on the sidebar. UNBLOCKED!
• Broader question: “What are the rights and responsibilities of a SL project?” (Simple answer, but we need to agree on the same simple answer.) NEXT WEEK! (and hitting the list shortly as a separate thread).
• Question from Kevin Mark: “Who should be the deciding organization for who determines what version of sugar is used in the field?” (Hitting the list shortly as a separate discussion thread, but no action really needed – just a good point to bring up.) The list discussion is here.

What else do people consider the most pressing topics to the future of SL? How are we doing? Are we reaching our goals? (What are they?) These should be the agenda items we discuss.

Basically, SoaS is a Fedora Spin, so we get nightly composes made here (as in, “Fedora automagically builds our .isos for us so we don’t have to”). In order to (we assume) save on disk space, the Fedora servers only store the latest nightly compose – once a new .iso is made, the old one is gone forever, bwahaha!

This is fantastic for developing, but not so much for testing. Expecting testers to keep up with daily builds is a bit much, and it’s putting a burden on people who are downloading them every day (possibly even getting into trouble with their ISP), so we decided to go with a weekly test cycle – each Thursday evening we’d designate the most recent image as the “image under test” and point everyone there. That way, developers would also know exactly what image people were finding bugs in each week.

Problem: in order to (we assume) save on disk space, the Fedora servers only store the latest nightly compose -  once a new .iso is made, the old  one is gone forever, bwahaha! So we need to grab the most recent image – which has a special naming – at that time and pull it down to the Sugar Labs servers so we have the files at http://download.sugarlabs.org/soas/test/ (We’re also storing the old test images so we can go back and forth between them Since the builds do contain their build date in their name, and we can’t predict ahead of time what the build date and time are, we don’t know the exact filename to pull.

So we’re basically looking for a shell script that will:

1. Pull the latest iso and checksum from the SL servers
2. Rename the checksum so it matches the datetime stamp of the iso (the checksum is currently called – rather unhelpfully – “CHECKSUM-i386″).
3. Update the symlinks so that http://download.sugarlabs.org/soas/test/soas-i386-test-latest.iso and http://download.sugarlabs.org/soas/test/soas-i386-test-latest-checksum.sha point to the latest iso and checksum that were just downloaded.

This probably requires some sort of weird wildcard bash-fu that would take me multiple hours to inelegantly figure out, and someone else 5 minutes to write a one-liner to solve.

Can haz halp?

00:18  * mchua has had a great day.
00:19 < mchua> When college professors start high-fiving each other across the classroom like excited kids because they got a button to work on a Sugar Activity, and then head out for ice cream, it is a Good Day.

I’m too behind/tired to be more verbose – turns out it’s difficult to simultaneously teach at and document a POSSE (probably due to that blasted 3 hours of driving per day – will hopefully do better next week). But betwen Friday noon and Sunday at 6 when the RIT one starts, I’ll spew logs from this one.

Theme: “Development”

Big idea: Sometimes, you’ve just got to dive in and work on the code… together.

Skill: Making contributions to an open source project “in the wild.” (In this case, the Measure Activity.)

Full logs:

• Peter Robinson on Spins, Remixes and release management
• Demo of IRC logging bot (zodbot)
• IRC logging bot tutorial, FOSS events, maddog’s talk

Of the three, the notes for the last one are the most interesting – the notes for maddog’s talk are essentially a paraphrased (brief) transcript of his 1.5 hour presentation on “how FOSS teaches you twice.”

They’ve been learning to hack Sugar all week, and are in fact in #sugar at this very moment tinkering away on the Measure Activity. Their feeds haven’t yet been added to Planet Sugar Labs (those requests are still pending), but you can read some of their (great!) reflections so far on Planet TOS.

So if you have a moment, pop in and say hello to:

• Peter Froehlich (Johns Hopkins) – pgf
• Karl Wurst (Worcester State College) – kwurst
• Nadimpalli Mahadev (Fitchburg State College) – Mahadev
• Kristina Striegnitz (Union College, Schenectady, NY) – kis
• Jerry Breecher (Clark University, Worcester MA) – diamond
• Mihaela Sabin (University of New Hampshire) – mihaela
• Gary Pollice (Worcester Polytechnic Institute) – gpollice
• Aparna Mahadev (Worcester State College) – aparna

Next week we’ll have another – slightly larger – batch from RIT doing the same thing, with myself, Chris Tyler, and Luke Macken focusing more on how to make Fedora a better environment for running/deploying/developing Sugar – if you have any thoughts in this direction, please send comments our way! (Things we’ve come up with so far: general Python development stuff, liveusb-creator hacks, SVG rendering working strangely in different recent versions of Fedora… we need to turn this into a proper ticket queue. Ideas welcome! What are the little annoyances you always wanted to fix? We’ll do our best to take them on.)

I’ll write more when I’m slightly closer to full consciousness (need food and a nap first, I think – today was far too early of a wakeup), but in the meantime, here’s what we did on Monday. The remainder of the week will be spent picking a Sugar Activity and championing it as a feature for SoaS v4 by making it meet the Activity (Inclusion) Criteria (in other words, “taking it through the feature process“).

We’ve got some topic suggestions for tomorrow (in addition to the things we were already planning to cover, which are basically “getting code, finding out what bugs others have already found to work on, and sending patches back”), but feel free to add others if you’ve got ideas.

Sugar Labs folks interested in a peek behind the scenes may find it fascinating reading, but we think Fedora folks curious about what the spins process looks like from the “other side” and Teaching Open Source folks looking for examples of reflective learning may also benefit from a quick skim. We had many triumphs and learned many lessons (often the hard way) – some excerpts are below.

On becoming a Fedora Spin

Before SoaS was a spin, it was a Fedora Remix – which means that bit-wise, the product looked the same, but the technical work that needed to happen to generate it was all done manually and without external resources and support, so it happened spasmodically and slowly and with a great number of sleepless nights.

Becoming a Fedora Spin gave us access to Fedora’s engineering, marketing, and QA resources, which dramatically improved the sustainability and scaleability of our release engineering processes. For instance, .iso files stopped being produced by the “Sebastian manually builds them every time” process, and started being automatically generated for testing by Fedora build servers. We gained some instant automation of the infrastructure we need anyway, without any more work or maintenance on our part, so we could focus on things like… making Activities work, the stuff that’s actually unique to Sugar.

The January 8, 2010 SoaS planning meeting led to the decision to apply for spin status. Looking at the January mailing list archives, we didn’t explain the significance of the spin decision very well then, which may have led to communication disconnects down the line that made Activity development and Marketing more difficult. In particular, we did not make it clear enough that we were now tied to the Fedora release cycle, and what that meant.

On accidentally making life difficult for Activity developers

Two of our upstreams (Fedora and ASLO) basically collided when they combined, and didn’t realize that collision was coming, because we didn’t track dependencies between them… part of the problem was that we didn’t know who was responsible for keeping track of that aspect of communication, so everyone assumed it was someone else and nobody did it.

The Activities confusion manifests itself in the small number of “supported” activities in the v3 release. Marketing was then confronted with the sudden removal/noninclusion of activities from the release – again, this is something that could have been prevented with a working feature process.

Major accomplishments this release cycle

• We have a team!
• We have a release schedule!
• We started using the Fedora Spins process and engineering resources, which made release engineering much smoother.
• We started driving communications to public channels – notably the SoaS mailing list – so things are more transparent.
• Multiple people have commit access to each repository that needs to be handled, so there are no single-person bottlenecks remaining.
• We shifted to a time-based release cycle, meaning we had a target release date set early in the process rather than our prior “it seems ready… now-ish?” method.

There’s more available at the full recap – we’re still a pretty fledgling project and new to introducing many of these processes (and still building our scaffolding!) so if you have thoughts/comments/suggestions/advice on how we could improve, please let us know via comments here, the soas mailing list, or pinging pbrobinson (Peter), sdziallas (Sebastian), or mchua (Mel) on IRC (we’re often in #sugar on irc.freenode.net).

Planning for the 4th release (the codename for this release is yet to
be chosen – suggestions for this welcome, too!) begins on Monday, June
7, at our weekly IRC meeting. And of course, if you’re interested in helping with the next release, please join us!

With the impending Tuesday release of SoaS v.3 Mirabelle, and one of the goals of the release to make the project more sustainable (in part by making it easier for new contributors to get involved), we figured that a contributor portal would be a good idea.

Behold the draft: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_Pagerevision (with many photo thanks to Mike Lee!)

The idea is that http://spins.fedoraproject.org/soas/ will be the main “shiny” user page for those who simply want to learn about the
project, download the image, and use it – and that the wiki page at http://wiki.sugarlabs.org/go/Sugar_on_a_Stick will be replaced by this
page revision at the end of tomorrow (Monday) and serve as the main contributors portal, with the two referring to each other.

You may notice that four stubs remain:
* http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_deployment_process
* http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_release_process
* http://wiki.sugarlabs.org/go/How_to_fix_an_Activity_bug
* http://wiki.sugarlabs.org/go/How_to_fix_a_sugar-core_bug

Pointers to resources and/or help filling these out is super-welcome, as is feedback on the idea as a whole. I’ll be looking at feedback and
making the merge when I’m out work tomorrow night; we can of course make edits after that (it is a wiki, after all) but it would be nice
to have something shiny-looking and shippable when the release goes out.

PS: As a reminder, we have our SoaS v.3 “how did we do?” review meeting on Tuesday, June 1st, in #sugar-meeting at 1900 UTC.