Posts that are olpc-ish
I thought this was a great point from last week’s discussion that deserved a shout-out:
“Remember however that some (high level scripting) software will effectively become learning materials - any code the students are asked to edit - and should be treated as learning materials.” –Joe
One of my personal favorite things about the XO being open-source is that the entire machine, and all the software on it, turns into a 3.2lb green box full of learning materials. The increasingly blurring line between Activities and Content Bundles (regarding how they’re treated in software) is a good example of this.
Now, about bounties, and solving the problem of how to get people to do things that aren’t glamorous (such as “make gforge work”)…
Listening in on Doc Searls in the #berkman backchannel last week made me think again about why bounties have not been historically useful with OSS development. Doc brought up that a lot of open-source work is done by geeks scratching their own itches, and that bribing somebody to scratch an itch they don’t have doesn’t really work.
But that’s the point of bounties. They are supposed to move the itch. Now the itch you have to scratch is not “I want to fix this for myself,” but “I don’t have that reward, I’d like to have it.” Rewards can be financial, status recognition, or some good thing happening to someone else you care about (”I fixed this problem for my friend/a child in a 3rd world country.”)
But that doesn’t seem to be happening - I come across bounty site after bounty site for OSS with no recent activity. Maybe there is one I’m missing that’s prolific and alive, but there doesn’t seem to be a dedicated bounty site that gets good results across multiple OSS projects - most work on a project, bounty or not, seems to be done by hackers already within their communities…
…and this, I think, is what the bounty sites are missing.
One emotion often associated with OSS communities is their sense of independence and grassroots-driven-ness; the sense that they built their own identity and are centralized in their own (online) location. So I can see a centralized bounty system falling flat with NIH syndrome, unless it’s offered as something each project can incorporate/control inside their own systems. (Can you imagine Trac existing only as a “we’ll host it for you” service, rather than having projects install, manage, and configure their own installations and write plugins for them? Scratch your own itch mentality is there.)
I talked about emotion earlier. Emotion is important.
If bounty sites fail because they don’t have bugs that hackers want to fix, because it’s not an itch they want to scratch, we have to think about what makes people think bugs are important for them to fix. Debasis Pradhan has a good answer: it’s emotion. You spot a bug by the emotional reaction you have to it. Frustration. Surprise. Rage against the machine.
So maybe one issue with bounty sites is that they treat OSS development as a purely economic activity without emotions as a motivational driver in that market.
All right. So what might be good requirements for a solution to the set of problems bounty sites are trying to solve?
- It must create emotional attachments between hackers and the bugs you want them to fix. Make it really their itch to scratch; don’t pay them to scratch an itch they don’t feel. (”Why would I scratch my behind for no apparent reason? I don’t care if you’re going to pay me for it. That’s absurd.”)
- It must consider community identity, and work on building the identities of the communities it serves, rather than creating its own centralized brand.
What else? And then - of course - the question: “How does this apply to OLPC?”
Monday, October 6th, 2008 | olpc | 1 Comment »
Mitchell Charity, a long-time OLPC volunteer, recently posted some interesting thoughts on our development community. I quote:
This wiki should be replaced. Groups of pages need to be owned by individual people. Only they can write to them. If you wish to contribute, you should email them patches. If you wish to create your own pages, you should fill out a form, and email it to the wiki administrator. What? You what? You think this profoundly misguided? Disastrous? Sure to stop wiki development dead in its tracks? Certain to dissipate and prevent formation of a wiki development community? Well, yes. Of course. That’s exactly what it’s done for the activity development community.
Seth asked for specific descriptions of what Mitchell would like to see. He responded “gforge.” I’m curious what others have to say about Mitchell’s description of the volunteer development situation as well as the proposed toolfix.
Here’s how I’d phrase the question as it stands: How can we optimize a system - technical and social - that gives us the largest and most varied pool of stable, volunteer-maintained, open-source, kid-hackable educational Activities possible? Gforge, workshops, bounties, documentation, toolchains, access… through any means possible, how would you maximize the number of Activites that meet the above criteria?*
Secondary: There are always reasons why things are the way they are. The question is whether those reasons and tradeoffs, deliberate or happenstance, still make sense given the current situation and the (always) limited resources available. Is this what we should be optimizing for, and how high-priority compared to other goals should this optimization be to whom?
*Note: I wanted to post a link to Walter’s criteria for good Activities here, but couldn’t find it - does anybody know the URL?
Sunday, September 28th, 2008 | olpc | 5 Comments »
My desktop background at work. (And on my personal laptop as well.) Every child needs their own velociraptor!
We now have a howto on memory leak testing - many thanks to Tomeu for taking the time to sit with me through my first memory leak test case. If you’re curious how hungry various actions in Sugar are, take a look. We have some memory leak bugs like #8394 that need test cases and testing, too, if you want to lend a hand.
I also started a section for test setups, which are shorthand references for actions that we do across many tests. It’s annoying to have to retype “first, take a USB stick…” or “if you don’t have this installed, wget this file…” dozens of times over, so we say things like “set up for a smoke test” and give a link to general smoke test setup instructions. This section is a stub right now; what other things should go in here?
Got some slightly confusing battery test results from yesterday’s run. Most of them performed as expected, but a couple had logs that terminated when the battery wasn’t even halfway discharged. I’ve also got a setup trying to reproduce #7893, which, if fixed, will be a triumph because it means your Neighborhood view will actually reflect the things present in your Neighborhood (instead of having Activities from no-longer-present XOs hanging out like the Ghost of Christmas Past). Fingers crossed.
For the record, according to our current test case management system, we have the following coverage…
- Test cases we know should exist (i.e. stubs OR cases created): 59
- Test cases actually written (i.e. cases, not stubs): 51
- Test cases run: 25 (42.4% of test cases that should exist)
- Test cases run and passed: 18 (72% of test cases run, 30.5% of test cases that should exist)
- Test cases run and failed: 10 (40% of test cases run, 17% of test cases that should exist)
- Test cases run with both passes and fails: 3
Clearly we need better test case coverage… and a better way of showing testing coverage, progress, results, and all that jazz. This is what we’ve got now. Suggestions? Ideas?
Friday, September 19th, 2008 | olpc | 2 Comments »
There is an exodus of interns. Brian Jordan left for Rwanda this morning; Dan Drake is already in Ethiopia. Both are helping out at pilots. We are demanding stories and pictures upon their return.
While doing upgrade testing, I found what might be an interesting bug; it still needs some chasing down and reproduction (and honestly, my bug report could be better). The test was to check whether Activity sessions started before an upgrade could be resumed after that upgrade (so far it looks like the answer is yes for core Activities, which is great). The bug isn’t in that; it’s in what happens when you don’t have the proper Activity to resume a session with.
One upgrade from 656 (what shipped with G1G1 machines) to 760 (current release candidate) ended up with no core Activities in Sugar. Of course, without Activities to run them in, the sessions couldn’t resume. They showed up as generic file icons in the Journal instead and you couldn’t do anything with them.
When the Activities were reinstalled, the old sessions still showed up as generic file icons in the Journal (instead of having the proper Activity icon next to them), but they could now be resumed. The curious bit is that when you resumed one of those sessions, you ended up with two separate Journal entries - one with a recent timestamp and the correct Activity icon by it, the other with the file icon and an old, unchanged timestamp. It was as if you’d created a new session that happened to have old data, and the old session hadn’t been touched at all.
Weird. Now to chase this down and reproduce it…
While automating what used to be a manual test (running a logging script beats the heck out of getting up every few minutes to see if a battery has died), I also learned something about OHM today, thanks to Richard. (Warning: Acronym alert. I’ve tried to link to relevant wiki pages when possible.) When there’s output to the VT, OHM won’t suspend the XO (and the battery will run down way, way faster).
In today’s case, it meant that if I ran olpc-pwr-log (the battery monitoring script, and a useful tool to know about) in the VT, the XO wouldn’t suspend; if I ran olpc-pwr-log in the Terminal activity, the XO (and the script) would suspend (but thanks to wireless, it would wake up frequently enough to give us some battery drainage data, which was enough). Since we were trying to drain the batteries as fast as possible (Richard needed drained batteries to test the multi-battery charger), we ran the script in the VT.
Phew. A lot of testing stuff going down tomorrow, so tomorrow’s post will be far more interesting, I promise.
Wednesday, September 17th, 2008 | olpc | No Comments »
Whee! As of today, have a desktop and it’s pretty much set up to be usable. This took far too much time (I probably need some sort of proprietary ethernet driver). Seth and Henry are wonderfully, wonderfully patient people…
On the testing front, I’m in the middle of upgrade testing for data integrity - this is something you can do at home with your XO and give us feedback on. Basically, we’re interested in finding out whether you can upgrade from your current build (make sure to tell us what build that is!) to 8.2-860 (the current release candidate) and whether saved Activity sessions you have from before the upgrade still work with the upgraded build and Activities. I’m just testing Write, Record, TurtleArt, eToys, and Browse, but maybe your favorite Activity isn’t on that list and you want to make sure it’ll still work post-upgrade - well, here’s a good excuse to find out now.
Frances and I are working on splitting up smoke test procedures so we have smoke tests unique to each release, since every build has a slightly different feature set. We’ll let you know when we’re all set on this - one thing that would be helpful to know is whether the current level of detail is easy enough for newbies to follow. In other words, can you get through the current smoke test instructions without getting confused or having to ask someone questions? If not, why not? Please let us know!
Tuesday, September 16th, 2008 | olpc | No Comments »
Yesterday (September 15) was my first day as a full-time QA/Support engineer at OLPC. It’s good to be back at 1cc with everyone again! I’m going to start logging non-internal things in this blog as well so others can follow along; let me know if there’s a way I can be more transparent, because in my mind, if anyone’s ever confused (or more confused than I am, anyway) about what I’m doing, that is a bug I need to fix.
Much of the first day was consumed by things like paperwork and setting up my desktop. I had a lot of catch-up reading and meetings to do, and met a lot of new people who had come on board this summer. This included Reuben Caron, my compatriot in system-level support, who has set me to reading through old RT tickets trying to get a feel for what kind of large-scale deployment problems are coming up.
A bit of explanation: what do we mean by system-level support? Well, the XO was designed to work in packs; communities of XOs, if you will. Many G1G1 donors and volunteers have only seen XOs in small numbers; ones, twos, maybe a few dozen together at a conference for a few hours. Country deployments have dozens, hundreds, thousands of XOs. When you have those numbers, you get issues of infrastructure (power, networking, activation) and scale that don’t come up at the individual machine level - for instance, what happens when you try to get 300 XOs connected to a school server? (This would imply that you have 300 XOs and a school server, first of all…)
More on system support as it comes along; Reuben and I will be looking for ways to involve the community in systems support. The first challenge is that most community members don’t have access to a system to work, test, or develop with; ideas on how to change that or get around it are very welcome.
Another part of what I’m doing is QA/testing. Right now we’re running tests in preparation for the 8.2.0 release - you can actually help with this if you have an XO and some free time. The current candidate is 8.2-760. Kim made a draft test plan right before I started, and we need to generate test cases that will cover all the features available in the new release.
One example of a test case - and the one I ran the afternoon of my first day - is the 20 XO XS collaboration persistence test, which connects 20 XOs to a school server (XS) access point (AP), gets them collaborating on a number of Activities, and sees how well that collaboration stays up over the course of multiple hours. We’re happy to report that this test passed (this time, at least) - 760 seems to show improved collaboration stability over previous builds. Sweet!
I know this is a test that not many people outside of 1cc will be able to replicate and verify; in later posts (and later days), I’ll try to start putting out things I’ve done that you, too, can do at home to help out. And probably some things I haven’t done - things I can’t do myself, but which still need to happen, with the community’s help - if you’ll allow me to request a hand from you once in a while.
And the morning and the evening were the first day.
Tuesday, September 16th, 2008 | olpc | No Comments »
The first OLPC Grassroots Bootcamp ran last week at Boston at OLPC
headquarters - thanks to all who attended, presented, and participated
and helped us build community infrastructures, share best practices for
grassroots movements, compile a list of Grassroots problems to work on, flesh out a Volunteering process, flesh out the role of a Community ambassador
(or ambassadors), and - of course, the smaller moments… playing
soccer, eating copious quantities of pizza, filling wall-to-wall
whiteboards multiple times over with notes ranging from technical
specifications to a request for parfaits, and just getting to know
people from all walks of life and all corners of the world.
You can view notes and transcripts from each day at http://wiki.laptop.org/go/Grassroots_bootcamp/Results.
Got notes from the bootcamp?
If you attended the bootcamp, took photos, have notes, project
files, or any other things from the past week, please post them on the
wiki so all can see - a good place to put these is http://wiki.laptop.org/go/Grassroots_bootcamp/Results. We’re particularly in need of notes from Thursday.
Feedback - please help us improve!
If you’re looking through the things we’ve posted and have
suggestions for how we can clean up, clarify, and provide context
behind some of the notes to make them more useful to others, please
post them to the feedback page, http://wiki.laptop.org/go/Grassroots_bootcamp/Feedback
(or reply to me via email) and we’ll do our best. There were plenty of
bugs in the bootcamp process, as this was a rough first round - so
feedback and suggestions for how to make a better bootcamp will be
enthusiastically welcomed.
Interested in running your own?
Speaking of future bootcamps: One of the goals for this prototype
bootcamp was to come up with a framework and resources such that other
groups could run their own (better! localized!) grassroots training
bootcamps in the future. Are there any groups out there interested in
running/hosting a bootcamp of their own (preferably this summer)? We
need some locations to help us figure out what resources we need to
make available to help non-Bostonian bootcamps run, so please let us
know if this something you’d be interested in helping us work out. It’s
much easier to build resources if you have someone particular in mind
you’re building them for, after all. See http://wiki.laptop.org/go/Grassroots_bootcamp/Feedback#I.27m_interested_in_running_my_own_bootcamp.
Cheers and thanks to all!
-Mel and the bootcamp crew
Monday, June 16th, 2008 | olpc | No Comments »
Technology was the focus of the last day of our 4-day grassroots bootcamp, kicking off with a school server (XS) installation walkthrough led by Ankur Verma, Dan Drake, and Chris Carrick. Disassembly, repair centers and repair kits, how to write funding proposals, and more were covered in side conversations throughout the afternoon…
Unfortunately, we don’t yet have documentation for these, since most attendees had to leave Thursday afternoon or evening, but we’re working on it and will post them on the wiki page - that’s http://wiki.laptop.org/go/Grassroots_bootcamp/Results - when they’re done. (There is a minimal transcript of the start of the XS installation session up there right now.)
A recap of the entire bootcamp will be coming in just a moment.
Monday, June 16th, 2008 | olpc | No Comments »
Bootcamp day 3 is done!*
See: http://wiki.laptop.org/go/Grassroots_bootcamp/Results
Highlights include:
- Feedback from Tuesday’s classroom roleplay - next round, we need to find a way to actually work with kids during the bootcamp. This time around was tough because of end-of-school-year scheduling and during-the-day bootcamp timing.
- Pre-luncheon guests Kim Quirk (VP of Software and Support) and Joe Feinstein (OLPC’s new QA head honcho) came in to talk about how to get involved in the upcoming surge of community testing.
- Guest speaker Josh Gay from the FSF gave a lunch presentation on “Designing for Participation” - the cycle of defining projects and goals in such a way that it makes it easy for volunteers to get involved.
- Seth Woodworth and SJ Klein led a discussion on “community APIs” and what OLPC’s community can do to facilitate itself.
Full notes and transcripts from the day (super-helpful, with much more detail - most of these transcripts are quite good, thanks to our volunteers!) are available at http://wiki.laptop.org/go/Grassroots_bootcamp/Results/wednesday_transcript.
Cheers!
*yes, these notes are getting sent out somewhat belatedly - most of the bootcampers (myself included) are also recovering from the aftermath of the Grassroots Jam, http://wiki.laptop.org/go/Grassroots_Jam.
Monday, June 16th, 2008 | olpc | No Comments »
OLPC grassroots bootcamp, Day 1 - done. Representatives from 5 out of 7 continents (how can we get a visitor from Antarctica in this week? I’m sure we can find somebody from Australia…) were present today along with plenty of brainstorming and great pizza.
I’ve already done a long, long update at the link above, so read on to find out what kinds of grassroots community infrastructures we worked on - the train’s coming, so I’ve got to run (or else sleep on the office floor again).
Monday, June 9th, 2008 | olpc | 1 Comment »
