Posts that are olpc-ish

Call for ideas: help design a “Gender/Race/Class” class on “interrupting the discourse that perpetuates inequity”

Our “Gender/Race/Class in engineering education” class has an “open topic” period that I’ve volunteered to help design… which means I’m going to Ask The Internet for help. (Hi!)

Based on our class discussion just now, we are interested in tackling this question: How do we interrupt the discourse that perpetuates inequity in engineering education? (Subquestions: who has access to this discourse as a listener? A speaker? What is that access based on — gender, race, class… age? geography? language? disability? intersections of any subset of that? What strategies do we have for doing this dialogue-interrupting work in professional and personal contexts?)

The course will be Monday, November 18, which is 2 weeks from now. We’re mostly PhD students in engineering education (technical backgrounds, social science research interests, lots of future engineering professors who care deeply about teaching). We have 3 hours in class, plus the ability to ask people to read a reasonable amount (<100 pages, English) before class. I’d love to hear thoughts, especially half-baked ones, on:

  • “learning objective” suggestions — in other words, what do we want to learn during the course of the 3 hours? (Can be fact-based, skill-based, emotion-based, perspective-expanding-based…)
  • “assessment” suggestions — given those learning objectives, how will we tell (at the end of the 3 hours) whether we’ve learned them, and how well? Does not need to be a test; could be questions for reflection on our own, etc.
  • Reading suggestions — scholarly or not. (For instance, Alice Pawley has offered to let us read her CAREER proposal on feminist engineering — a short, highly competitive grant for junior scholars whose committee was probably not used to getting “feminist” proposals.)
  • Activity suggestions — discussions, games to play, short bits of theatre to act out and/or improvise upon, provocative question prompts, etc…

Potential inspiration: our guiding question/framing about “interrupting discourse” came from a discussion on “how do we talk to people about this?” and an interest in intersectionality, especially with disability/access. I’m personally curious about the history of opening these dialogues in STEM: who (tenured? white? male? western?) started the conversations about women in physics, minority races in computing, wheelchair-accessible chemistry labs, etc — and when, and how, and what were the responses?

Comment away! I will post readings (or reading notes, if readings are not freely available), discussion questions/guidelines, and a story of what happened in the class once we run it — basically, whatever I can do to make the experience we’re creating here available and reusable by more people.

If a broke grad student can do it, you can too: donate to @adainitiative and patch the open world to be better for EVERYONE.

TL;DR – if my work in open source has helped you in some way, please donate to the Ada Initiative, which supports women in open technology and culture. Not convinced yet? Here’s why I donated.

There’s a world out there to patch. I love the universe of open technology and culture where I’ve built much of my career and friendships. It’s a wonderful world that can be wide and welcoming — but it also has horrific bug reports of sexual abuse and gender discrimination, along with many more that haven’t been reported out of fear and shame. I’ve lived a few not-so-good stories myself; some I’ve told, some I haven’t. What saddens me most, though, isn’t the bad stories that have happened; it’s the good ones that never will — stories of women and men working together to hack the universe in marvelous ways. If we want to see these stories happen, we’ve got to make a world where they can happen, a world where it’s safe for them to happen. Don’t WONTFIX that ticket; do something. When you care about something, you want to make it better.

We change the world with millions of tiny patches. I’m a grad student; money is tight, and my $64 contribution represents half a month of groceries. I was initially ashamed of my “tiny” contribution, even if it’s a nontrivial one for me. Then I remembered: our world of open technology and culture is built one patch, one line, one edit at a time — and that’s precisely why it’s powerful. It brings billions of tiny, ordinary moments together to transform the world. If we teach it for our code, we can preach it for our giving. If you’d buy me a drink, or treat an open source newcomer to dinner, send that $3-$20 to the Ada Initiative tonight.

Someone’s got to integrate these patches into a whole… and it’d be nice if they didn’t burn out in the process. Honestly? I support the Ada Initiative because it does this work so I don’t have to. I’m young and energetic, but I’m often wiped out just being a woman in open technology and culture. It’s not just physical and mental exhaustion; it’s emotional and psychological, which is worse. And being an activist is harder still. Do I agree with everything the Ada Initiative says or does? Nope. But it’s a job I want done, and I don’t want the job. This is why we hire maintainers for Free Software; we give them the gift of bandwidth so they can help us contribute more for a project with less effort by supporting and connecting our patches with the bigger picture. Val and Mary are good maintainers for feminism in our open universe — and I’d like more. After all, it’s a big world out there that we’ve got to work on.

The last day of their fund drive is tomorrow. (I’m coming late to the game; summer travel + school year start + RSI = no internet for Mel.) But it wasn’t too late for me to throw in my $64 patch this morning — and it’s not too late for you to contribute your patch today. If my work in open technology and culture has touched, helped, or inspired you in some way, please help me pay it forward and create a supportive, welcoming environment for everyone in the open world.

Tracking fellow FOSS-to-academia migrants

First: I’m working on a list of FOSS hackers who’ve gone back to school to study FOSS in some way; do you know of any? Please let me know in the comments. They needn’t be coders; designers, documenters, etc. are also totally welcome, as are contributors to open content and hardware projects — for instance, a very active Wikipedian who goes to graduate school to study the collaboration practices of Wikipedia.)

Now then.

Seb Benthall’s post about academic vs open culture reminded me that I’d like to track my fellow FOSS-to-academia migrants somewhere. Seb and myself are members of a fairly short tradition that includes folks like Martin Krafft (Debian developer to CS/Sociology PhD) and Mako Hill (Debian developer and Ubuntu hacker to interdisciplinary PhD student and Berkman Center researcher).

If you think about it, there’s no way the tradition can be anything like short. Undergraduate degrees tend to focus on “study to be able to do” for a broad area rather than a more focused “study of” a particular topic, so I’m mainly looking at grad students and those who’ve gotten their graduate degrees. To enter graduate school, you typically need an undergraduate degree — which means you’re likely at least in your early twenties. That’s how old the Free Software and Open Source movements are themselves.

It’s not that we’re the first generation of grad students to grow up in FOSS culture — that distinction belongs to people now in their mid-thirties to early forties, who were college-aged in the mid-90′s when the FOSS world was ramping up for the firs time. But we’re the first ones to enter grad school at a time when FOSS culture was widespread enough to be considered a legitimate topic of study by open-minded advisors; in a prior day, we might have studied CS, math, education, or any number of things with “proper” topics as our primary research focus, with open source remaining a devoted side hobby mostly separate from our “real academic work.”

It’s a good time and place in history to be. Plenty of opportunities to find and make — and we’re hackers, so we’re used to finding and making our own way through a chaotic world. Perfect.

1st draft of lit review on the open source way and education: please rip to shreds.

I finished my first lit review today. Or rather, I should say “I finished the first dot release of the pre-alpha version of my first lit review today,” because I look at this and know that it’s nowhere near where I want it. Then again, “where I want it to be” is at the start of my dissertation about… oh, 3-5 years from now. All things considered, it’s not bad for someone’s first real attempt at independently scouting out scholarly sources.

From the introduction:

This is a preliminary and extremely incomplete literature review surveying the current academic scholarship on open source and education. It can be summarized in three words: there’s not much. I’ll begin… by discussing what I am not looking at… I am not looking at the use of open source software in educational contexts… open source as an IT solution. Nor am I looking at open source with a focus on content licensing… open source as an information access solution.

Instead, I am concerned with an analysis of what sorts of practices and processes for learning are exhibited in open source communities themselves and how these practices might be made transferable back to the classroom. In other words, I see open source as a way of operating learning communities: radically cross-functional, collaboratively constructed realtime transparency.

Aaaaand here’s the whole dang thing, below. Why push now? Well, after a certain point, I decided to stop agonizing over it and release early and often because hey, maybe what I need are some other eyeballs to kick me out of the mental ruts I’ve gotten into. Also, I finished writing it and turned it in 20 minutes ago (which may explain why the quality of the writing degrades considerably in the last 3 paragraphs). It’s been a rough week. Month. Semester, really.

Literature review: the open source way and education (alpha)

Essentially, I spent my entire first semester of grad school finding that nobody’s really done research on my topic of choice (engineering education happening in open source communities) before – which is both awesome (because that means I get to do it) and depressing (because WHY AM I ALL BY MYSELF OUT HERE I DON’T KNOW WHAT I’M DOING). And now I’m standing here unsure of what to do next; I want to read some of these more deeply, talk about them with people, have folks tell me where I’m wrong and why, get into debates over a bunch of these ideas, throw them off the wall, bounce them off other people’s heads…

And so I fling this out to you, my friends. Thoughts? I apologize that this is not in comic book form – it was a little harder to get away with that for a lit review… but I’ll keep trying.

Is there a lazyweb fix for the paradox of localization?

Via Sumana, a post by Amir Elisha Aharoni on the paradox of localization:

who don’t know English strongly prefer to use software in a language
they know… People who do know
English often prefer to use software in English even if it is available
in their native language. The two most frequent explanations for that
is that the translation is bad and that people who want to use computers
should learn English anyway. The problem is that for various reasons
lots of people will never learn English even if it would be mandatory in
schools and useful for business. They will have to suffer the bad
translations and will have no way to fix it.

So this is the paradox – to fix localization bugs, someone must
notice them, and to notice them, more people who know English must use
localized software, but people who know English rarely use localized
software… Even people
who know English well should use software in their language… especially
if it’s translated badly, because they are the only ones who can report
bugs in the translation or fix the bugs themselves…

I am glad to say that i convinced most people to whom i spoke about
it at Wikimania to at least try to use Firefox in their native language
and taught them where to report bugs about it. I also challenged them to
write at least one article in the Wikipedia in their own language, such
as Hindi, Telugu or Kannada – as useful as the English Wikipedia is to
the world, Telugu Wikipedia is much more useful who speak Telugu, but no

My comment,
summarized: can the software be hacked to make this easy for
multilingual users to contribute to? Imagine being asked to opt-in for occasionally
having the application start up in (or switch into) another language
you know — for instance, “every 25th time you log into this website,
you’ll see it in Hindi” — with a reminder shown during those
language-switching times thanking you for aiding with translation
quality and giving you a direct link to report translation problems?

Because sometimes the problem is just a little too much friction;
switching the language of an application takes 5 too many mouse-clicks
to be thoughtlessly easy, and the vast majority of users don’t wake up
in the morning and think “you know, I could contribute to the localization of the software on my computer!” The lazier people can be and still help you, the more likely they’ll be to do it.

Which applications, or which types of applications, would be easiest to do this with?

Please take the Ada Initiative’s 5-minute census

Passing on a message from the Ada Initiative, a group doing what I personally believe to be incredibly important work on gender representation in free and open source software, content, and culture – precisely the things the Fedora Project is working towards the rapid advancement of. The survey really does take less than 5 minutes; regardless of your gender, please give it a shot!

Take the Ada Initiative Census

The Ada Initiative is a newly-formed organisation which aims to support and promote women in open technology and culture. We’ve just launched our first annual census — a broad survey of open technology and culture participants — to find out more about what projects and communities people are involved in, and how they feel about women’s inclusion and representation in the field.

We use the term “open technology and culture” to refer to a wide range of activities and communities based around free/open licenses, and other forms of open, decentralised, and grassroots participation in technology and related fields. This includes:

Open source/free software
Open source hardware
Open geodata and maps
Open government
Open data
Open standards and formats
Open educational initiatives (open access journals, open source curricula, etc)
Open/decentralised social networking (including Diaspora, StatusNet, etc)
Creative Commons and free culture
Wikipedia and other wikis
Open crisis response and humanitarian projects
Barcamps and unconferences
Online/digital activism
Remix/mashup culture
Transformative works fandom, including fan fiction, fan art, and fan vidding
Maker/DIY community
Hacker spaces

If you’re involved in any of the above areas, we’d like to get to know who you are, what you’re working on, and your thoughts on how women are doing in your community. We welcome participation by people of any gender, although we are particularly interested in women’s responses.

The survey only takes about five minutes, and can be found at

What FOSS communities can look like from the outside

I found this mailing list conversation snippet to be very insightful, and wanted to share it.

Scott: “Open to critique” isn’t quite the same as “responsive to critique”. From an outside perspective, it seems that frequently SugarLabs is just not listening to people who offer contrary opinions.  This is better than flaming them, but maybe not as good as it could be. For an end-of-year report, I’d like to see instances enumerated where SugarLabs actually internalized some outside critique and responded in a positive way — some concrete change made to the UI, or Sugar, or to process.  That would be more convincing that simply stating, “we are now open to critique”.
Bernie: We’re definitely intimidating to non-technical people. At least, this is what I sensed at the Realness Summit. OLE also seems to be doing a better job at connecting with educators. I’m not completely sure what corrective actions should be. We might need to do some work on the  wiki, maybe add web forums, which non-geeks tend to prefer…

Scott: I suspect that the answer to this problem does not involve installing additional software.

Later in the day, Jeff and I were having this conversation on #teachingopensource.

Jeff: Is IRC really a barrier to entry?  maybe I have simply been using it too long, but it seems immediately recognizable to me. I think one barrier might be the attitudes that crop up.  Even with emoticons, sometimes it’s hard to discern intent.  Hard enough in email, but sometimes devastating in real time.

Mel: Actually, yes. I had a really, really hard time figuring out IRC. First, figuring out that it existed and I had to use it. Then how to get it, how to set the software up. Then what the heck networks and channels and whatnot were – and why channels? my IM paradigm was “you have a buddy list and you ping people individually.” So “chatrooms are the default!” wasn’t hard to understand once I realized it, but it took a while to realize because I wasn’t looking for it.

And then “oh man, who are all these people? I am nervous about pinging them, will they yell at me?” And then all the /commands I had to remember. It was so bewildering and terrifying and new and it was being used as a way to present new information to me at the same time, sort of like… taking your first calculus class in… Mandarin, if you’ve also just started studying Mandarin as a foreign language. You can’t concentrate much on the calculus because you’re going “zomg it’s in CHINESE.”

It’s hard to remember how hard things can be, especially when you’re surrounded by a community of people who are the ones who self-selected and made it past that hardness. By definition, if you’ve gotten into FOSS, the current participation mechanisms worked for you… so why fix them?

Because we want others to join us.

POSSE Worcester: Wednesday

The email I sent my team today as a “what did Mel do?” update:

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:

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.”

POSSE professors in Sugar-land for the next 2 weeks

Some of you may have noticed some new faces around the Sugar community – we (Walter Bender, Peter Robinson, and I) are hanging out with a group of professors (mostly from the Worcester area) who are in town this week for POSSE (Professors’ Open Source Summer Experience), a workshop for learning how to get their students involved contributing to open source projects. (In this case, Sugar, with Fedora as a dev platform.)

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.)

The history of the SoaS Mirabelle release: learning from the past

With yet another (Fedora and SoaS) release cycle coming up, one of the things we can do to prepare for the future is to look at the past and try to learn from both the intentional and inadvertent things we’ve done before. With that in mind, the Sugar on a Stick team has put together a release history for v.3 Mirabelle, recapping the main decisions/events and rationale of the past 6 months.

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

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!