Posts that are olpc-ish
Thanks to Joshua Gay of cK-12 for his help in crafting this posting!
Help us spread the joy of education to children all over the world by becoming a Social Media Warrior. At OLPC, we have the tools, the educational materials, and learning resources to help transform the lives of millions all over the world. To do so, we need thousands of volunteers to understand what we have and what we are capable of doing for the lives of children everywhere - and we need three of you to help us get the word out to them using the social networking and media sharing sites that pervade our lives.
Video Ninja
- We’ll hand you the keys to our YouTube, dailymotion, flickr-video, and myspace-tv accounts; work with our marketing team and branch out to other video networks at your discretion.
- Promote videos from media.laptop.org, olpc.tv, and other sources, including training resources for volunteers and staff in third-world deployments.
- Track down celebrity speakers for original source material and permission to use it.
Facebook Rockstar and Myspace Maven
More details (including how to apply) can be found at the new OLPC blog.
Thursday, November 13th, 2008 | olpc | 1 Comment »
One Velociraptor Per Child’s mission is to increase the Darwinian fitness of the world’s poorest children by providing each child with a rugged, low-cost, low-energy, internet-enabled velociraptor with content designed for collaborative, practical, self-empowered survival.
“It’s an education project, not a genetic engineering project.” — Dr. Ian Malcolm
You can show your support for global paleontology here, and then join the effort to change the world… here.
(update: Digg it!)
Sunday, November 2nd, 2008 | olpc | 5 Comments »
Just for fun, an icon draft for the testing community is below, since it’s been a while since I busted out the Inkscape and I needed to take a break somehow tonight. Edits/counterideas welcome; the source is here. I’m just getting this party started; I don’t actually have icon design skills myself.
On a more serious note, a number of volunteers have expressed interest in learning testing along with me, so I’m hoping to make the community test group a great place for newbies to learn about QA. More details in the original testing mailing list post here. If you’re interested, have ideas on how we can do this, or (best of all) willing to teach something you know, please let me know, either through a comment on this post or by directly responding to the testing mailing list.
Tomorrow’s blog post will be in response to all the great feedback I’ve gotten on this week’s posts so far. Thanks for the thoughts and helps, everybody - please keep them coming!
Thursday, October 16th, 2008 | olpc | 3 Comments »
C. Scott Ananian gave his much-anticipated talk and demo of next-gen Journal design ideas today. Ed McNierny filmed (files still transferring), Brian Jordan recorded (mp3) (ogg), and I transcribed. If you can, please read and edit the transcript while you’re listening to the recording - just dump the text into an editor and follow along, filling in/correcting gaps I missed.
Scott posted slides up afterwards (odp) (pdf), as well as the freakin’ awesome dogfoodable code he demoed (journal2) (pinot). (Warning: code not for the faint of heart, or intended for general consumption at this point.) Video should be up soon and will be posted here when it is up.
Help cleaning up / preparing meeting/presentation notes, transcripts, and suchnot is always welcome - there are many things at 1cc we can make more transparent, and sometimes the reason for radio silence is that we simply lack the humanpower to prepare and push the notes out to the public.
For those who want more transparency: what information would you like to know, and what help can you offer in preparing/publishing it? (Note that not all information can be shared - I’m glad our root passwords are not public record.) My personal belief is that we can and should share more than what we do right now, but there is quite a ways to go before transparency-by-default becomes easier than privacy-by-default, and hence stands a chance of becoming the norm.
Edit: Scott posted slides and code! Edited links… yay Scott!
Wednesday, October 15th, 2008 | olpc | No Comments »
Today a friend at Google gave me a brief crash course overview of their spiffy workflow system. (If there is one thing Google does well, it’s Build Systems That Ease Thinking Friction. This does not make things easy; it enables you to do things that are hard.) Some of the key parts of the system that I’ll get back to later is that (1) it’s easy to build code, and (2) it’s easy to write automated test cases for your code - all worthy goals that we should aim to improve on as well.
Another part of Google’s workflow is their code review system. The way my friend described it, there’s this constant loop of feedback and revision happening with code - imagine something going around and around in a positively improving cycle - and when it’s ripe and ready, someone with privs can pluck it from that cycle and make it a commit (as opposed to a linear “go forward… get stuck here… if it doesn’t work discard it out of the waterfall completely” system).
Theoretically, all dev teams do some form of this. Google has a toolset to make it as painless as possible, thanks to a guy named Guido. You can see Van Rossum’s presentation on the system and his slides from the talk. There’s an open source version, too. It’s not the only tool that does this, and I’m not the first one to think of it as a potential plus for the OLPC community.
It sounds like what might have happened when this was briefly mentioned last time (note that there are no follow-ups to Sayamindu’s email in the last link) was that it was a little tricky to get the prior version of Review Board working with our git repos, and it got lost in the “aieeee release!” rush because the “Talk About Patches On The Mailing List, comment inline” methodology worked Well Enough.
I worry that the latter doesn’t scale, though, and that its inability to scale keeps us from scaling (rather than the “oh, when traffic gets high enough, we’ll put in the tools to handle it” methodology I usually agree with, this may be one place we have to build to handle capacity as a prerequisite for getting that capacity). I don’t know for sure. This entire post is a lot of speculation based on talking briefly with a very small number of people.
Three questions, then:
- Why don’t we do this now? Is there some reason or some happening that I’m missing? Or is it just “because we haven’t tried it in a way that works yet” (and what are the potential hard parts about doing so)?
- Do you think this might be helpful (and how)? Even a quick yes/no vote in the comments here would help as a fast sanity check.
- Would anyone be interested in playing with this with me? I’m thinking of a 2-hour sprint next week to try to choose, set up, configure, and try out something like this. If it works, great. If it doesn’t work, we’ll publish why, we learned something, and we had fun. Comment here and I’ll email you to set up a sprint time.
(Thanks for all the public and private conversations people have sent me on these blog posts so far by the way - I’m learning a lot by posting my OLPC braindumps here, and the conversations I’ve had with people who agree, disagree, point out that I’m reinventing the wheel, flaws in my reasoning, and so on - these are a large part of what teaches me how to Do Stuff Better.)
Tuesday, October 14th, 2008 | olpc | 3 Comments »
Okay. How can we learn from this? (Ignore, if you like, who and what the campaign is for - my point is that we should learn from their tactics whether or not we agree with their cause.)
“We decided in terms of timeline that [our organizers] would not be measured by the amount of voter contacts they made in the summer—but instead by the number of volunteers that they were recruiting, training and testing. It was much more an infrastructure focus. So there would be no calls from Chicago saying, ‘Why haven’t you made more calls?!’ Instead there would be calls saying, ‘Where are your neighborhood team volunteers?’ Or, if the numbers seemed high, ‘Are they real?’ It was a whole shift in mentality that was really, really good.”
Also, see:
“Rather than say we have X leadership roles to fill, we’re creating leadership roles for as many leaders as we have. So we have people in charge of whatever they ARE. We are saying, ‘What’s your social network?’ We say, ‘OK, you’re The Balcony Coordinator—your job is to go party at Balcony [a local bar] every weekend—like you do anyways—but now wear a Barack Obama button—and bring voter reg forms.’ Or, ‘Hey, you work at Brunos—when you go out on deliveries—as long as it’s OK with your boss—ask people if they’re registered. You’re going to be our, um, pizza coordinator.’ “
Thanks to Sumana for the link!
Sunday, October 12th, 2008 | olpc | No Comments »
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 | 2 Comments »
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 »
