Posts that are fedora-ish
Anyone who’s heard me talk about Teaching Open Source portions of my research will soon gather that I’m a fanatic about metacognition. If our designers and engineers and writers and developers and contributors don’t know themselves and how they think, ampoule how can they work with others? Here’s an actionable summary of a little (ok, 20 pages) paper called “Designing Technology to Support Reflection, written for FOSS projects and other distributed online communities where learning takes place. The paper was written in 1999, when open source was still a baby, the internet had just begun taking hold, and MOOCs were light years away, so I’ve updated the examples to be more familiar to us 13 years later.
The paper outlines “…four ways that technology can provide powerful scaffolding for… [a] combination of both individual and collaborative reflection… [for] actively monitoring, evaluating, and modifying one’s thinking and comparing it to both expert models and peers.” (That last quote was an incredibly hacked-up and shortened version of the abstract, by the way – and the start of the paper is a lovely lit review on why metacognition matters for performance; if you are at all interested in these topics, I recommend reading at least the first 3 pages.)
The four ways:
- process displays
- process prompts
- process models
- a forum for reflective social discourse
Process displays are basically debuggers; they show learners where they are in a process (which may be new, complex, and confusing to see, let alone do the first time). Firebug can be thought of as a process display, albeit not one specifically designed for education; Hackasaurus is a bit closer. Bret Victor’s piece on Learnable Programming is a great example of how an even richer system might be designed. Also, pretty much anything that supports portfolio creation can be used as a process display — wikis, blogs, etc.
Process prompts are attention-grabbers that bring the focus of learners to appropriate bits of a process while it’s in motion. You can think of the specific question-prompts of a bug reporting form as a process prompt; if we took that one step farther and had an option to replace the big blank textbox with a “novice” display that walked them through steps for reporting a bug (“What were you trying to do?” “What specifically did you type/click?” “What happened next?” “What did you expect to happen instead?” etc.) that would be an upgrade. Checklists are a very simple sort of process prompt; for instance, see Mediawiki’s guide to conducting a code review.
Process models are maps of expert thought processes, the “stuff” that experts know and act on but don’t always articulate because they’re taking it for granted. Mo Duffy does a great job of this when describing her work on GNOME and Fedora, and I don’t even need to look that far — her two most recent blog posts walk you through some of her thinking about bootloader UI design and wallpaper development, respectively. Now, this is more a think-out-loud than a true generalized process map; such a thing looks more like Fedora Infrastructure’s “what to do when there’s a system outage” document. Armed with this, even a novice sysadmin like me can see how masters like Kevin Fenzi and his crew keep their cool and manage the ship even in the midst of a maelstrom (although actually doing it is another thing).
Reflective social discourse is about getting more eyeballs on a problem to make it shallower — hearing multiple voices on a topic, getting feedback from many different angles. (This is where the paper most shows its age; there’s almost an undercurrent of awe in describing how several computers could be connected through a fileserver! and students could write notes commenting on the work of their peers!) Nowadays, there’s the obvious collection of tools specifically made for dialog: blogs, microblogs, Planet blog aggregators, chatrooms of all sorts. But there are others more subtly embedded in our practice. Public bugtrackers and code reviews are all about reflective social discourse — I’ve learned plenty by reading extended comment threads on closed tickets. And while this isn’t a technology-supported option per se, conferences and in-person events are another form of this — present your idea to a bunch of friends and have them help you make it stronger.
The article closes with a plea for systems thinking. Won’t someone, somewhere, start designing learning technology that incorporates all four of these in one? And we are — look at any of the dashboards being created for things like EdX or Khan Academy, and you’ll find all four aspects. But now you know what they’re doing.
Here’s the paper, for those of you inclined to chase down the full text. Have fun!
Lin, X. D., Hmelo, C. E., Kinzer, C. K., & Secules, T. J. (1999). Designing technology to support reflection. Educational Technology Research & Development 47(3), 43-62.
I’m cranking out my portfolio right now, look so I’ll just paste in a quick variant of the email I sent some friends.
This is long, no rx but very worth reading: Learnable Programming. Think about it in the context of:
- Learning and teaching introductory programming
- Learning and teaching other technical classes that are code-related: digital signal processing, cheap system dynamics.
- Designing environments and languages for programming, especially when programming is “not the point” (as for an intro electronics or robotics course where the code is incidental to the final project)
- Implications for MOOCS and massively distributed teaching systems in general.
Don’t blindly agree with it right away. I don’t agree with everything; it’s useful in some contexts and not others, etc. But it is a thoughtful, insightful, well-written piece that’s worth looking at to see how someone thinks well about a difficult topic, and communicates it clearly.
Thanks to Diana Kimball for the post that led me to this article, as well as for her insightful thoughts on taking a CS class at long last as an MBA student.
If I asked a random FOSS community member whether they’d like more people to use the software (or content, surgeon or hardware, or whatever) they work on, I’m pretty sure most people would squint at me funny and say some variant of “yes” or (if they’re blunter) “duh.” And also I think most of us acknowledge accessibility is a Good Thing That Can Help With That — possibly a good thing we don’t have resources to implement, but a good thing nonetheless — and applaud efforts like GNOME’s that are directly working on making “FOSS things” more accessible to the less-privileged (most commonly thought of as “the disabled,” but really extensible to just about everyone). This is called Universal Design, and it is…
“…the design of products and environments usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.” –Robert Mace (emphasis mine)
Now, we create things, but we also create experiences — and one of those experiences is the experience of becoming one of us, a contributing member of the project community (which I believe most FOSS contributors would also like more of in their projects). Our communities are an environments. What would it look like to expand our thinking from “accessibility of product is good!” to “accessibility to contribution process is good!”? I’ve been reading about Universal Design for Learning, an adaptation of Universal Design geared towards the design of learning experiences, and it’s got some heuristics that might be useful to consider. I’ve adapted the list below is from Sheryl Burgstahler’s Universal Design: Principles, Process, and Applications.
- Equitable. The community is useful and marketable to people with diverse abilities. For example, a project that specifically calls for help with documentation, art, testing, etc. and other things beyond code and system administration. It’s made clear that interest and willingness to learn are the most important things, not a PhD in CS — come in and we’ll teach you much of what you need to know to get started helping out.
- Flexibility. The community accommodates a wide range of individual preferences and abilities. Mailing lists where language minorities can converse in their native tongue. Holding in-person getting-started events to bootstrap folks who are nervous about getting the etiquette of online communication wrong.
- Simple and Intuitive. How to start participating in the community is easy to understand, regardless of the newcomer’s experience, knowledge, language skills, or current domain of expertise. Having suggested default settings in “how to join this team” instructions, the same way most installers nowdays have a recommended default setup that advanced or adventurous folks can change.
- Perceptible Information. The community communicates necessary information effectively to the contributor, regardless of ambient conditions or the user’s sensory abilities. A common example in most communities is “if it’s not on public mailing list X, it didn’t happen” — phone calls, hallway conversations, and even (in some cases) IRC meetings should be captured somewhere everyone can look at them.
- Tolerance for Error. The community culture minimizes hazards and the adverse consequences of accidental or unintended actions. A safe place for newcomers to ask even the “silliest” questions — a place that’s actually maintained and responded-to by respected, established community figures instead of becoming a ghetto of ignorance. A cultural habit of encouraging and applauding genuinely curious attempts that go wrong instead of responding with a “how could you be so stupid as to try X?” tone. The practice of teaching newcomers how their actions can be made reversible — the notion that you can revert wiki pages, roll back code in a version control system, etc. and that this is No Big Deal. Being bold often requires the confidence that you won’t irreversibly screw anything up.
- Minimal Activation Energy (originally “Low Physical Effort” for things like automatic door openers). The community’s processes can be used efficiently and comfortably, and with a minimum of fatigue. Integrated logins across a project’s infrastructure. Not making people sign into 4 different accounts and make 20 mouse-clicks in order to vote for a board. The option to subscribe to notifications of one’s choosing.
- Space for in-person participation. At in-person gatherings, size and space is provided for approach, reach, manipulation, and participation by community members of many sizes, postures, and mobility considerations — including the ability to be there in person at all. Live collaborative notetaking during meetings, childcare at conferences, choosing wheelchair-accessible buildings for events whenever possible, projecting IRC channels into a live space so remote members can have a visible voice.
Food for thought. And by the way, these are all things that new contributors (including classes of students looking for a project) can evaluate and improve upon for their favorite FOSS project — doing these things would be providing an extremely useful helping hand to many places.
I found this howto particularly relevant for FOSS people who care about making their projects and communities stronger and their products more usable. A few of the many gems:
- Nobody is born knowing this stuff. You’ve forgotten what it’s like to be a beginner.
- A computer is a means to an end. The person you’re helping probably cares mostly about the end. This is reasonable. Their knowledge of the computer is grounded in what they can do and see — “when I do this, practitioner it does that”. They need to develop a deeper understanding, salve but this can only happen slowly — and not through abstract theory but through the real, concrete situations they encounter in their work.
- Beginners face a language problem: they can’t ask questions because they don’t know what the words mean, they can’t know what the words mean until they can successfully use the system, and they can’t successfully use the system because they can’t ask questions.
- You are the voice of authority. Your words can wound. By the time they ask you for help, they’ve probably tried several things. As a result, their computer might be in a strange state. This is natural. They might be afraid that you’re going to blame them for the problem.
- Your primary goal is not to solve their problem. Your primary goal is to help them become one notch more capable of solving their problem on their own. So it’s okay if they take notes.
- Most user interfaces are terrible. When people make mistakes it’s usually the fault of the interface. You’ve forgotten how many ways you’ve learned to adapt to bad interfaces.
- Attend to the symbolism of the interaction. Try to squat down so your eyes are just below the level of theirs. When they’re looking at the computer, look at the computer. When they’re looking at you, look back at them.
- Try not to ask yes-or-no questions. Nobody wants to look foolish, so their answer is likely to be a guess. “Did you attach to the file server?” will get you less information than “What did you do after you turned the computer on?”.
- Explain your thinking. Don’t make it mysterious. If something is true, show them how they can see it’s true. When you don’t know, say “I don’t know”. When you’re guessing, say “let’s try … because …”. Resist the temptation to appear all-knowing. Help them learn to think the problem through.
- Whenever they start to blame themselves, respond by blaming the computer. Then keep on blaming the computer, no matter how many times it takes, in a calm, authoritative tone of voice. If you need to show off, show off your ability to criticize bad design. When they get nailed by a false assumption about the computer’s behavior, tell them their assumption was reasonable. Tell yourself that it was reasonable.
- Take a long-term view. Who do users in this community get help from? If you focus on building that person’s skills, the skills will diffuse to everyone else.
One of the things I tried out as part of my independent study on open access this semester was the idea of reverse-engineering a publication. This isn’t about hacking code; it’s about hacking copyright. And as it turns out, salve it doesn’t work.
Here’s the setup: imagine you’re a researcher and you’ve written a great paper that’s published in a prestigious journal. You beam with pride! Life is fantastic. And then you find out about the open access citation advantage, realize your publisher allows archiving of preprints, and think that life is about to get even better.
There’s just one problem. You can’t find your preprint version (the final edited version you send to the publisher, usually a plain Word or LaTeX document). You only have the final copy PDF with all the branding and pretty-print formatting on it – the version that got published in the journal. Somehow, in the frenzy of hard drive clean-up that accompanied your “I am done with this paper forever!” project completion celebration, you… you lost the file.
But wait… the final print version is identical to the text you sent in, right? All the publisher did was add formatting. So if you could just grab the text from the final print version and throw it back into a Word document, that would be identical to the preprint, and you could post that. A preprint is just the end publisher content there without the end publisher formatting. Right?
Wrong. The problem here isn’t technical, it’s legal. I actually took a print pdf and “reverse engineered” it into a LibreOffice document, and it looked fantastic — I did the process by hand, but it would be easily automatable, so the software portion of the problem is trivial. I talked with Donna Ferullo, Purdue’s copyright librarian, and the copyright portion of the problem is, unfortunately, a blocker bug. The crux of it the matter is that we don’t know what value the publisher added before printing. Okay, this probably is “not much other than formatting,” but still… it’s legal grey. So we hit a hard wall on that, but at least we learned something.
I promised to write something up about this since I don’t think the reverse-engineering idea has been broached before, and it’s at least good for others to know that it’s a dead-end — so here it is.
Aaaand now that all the transcripts are in and somewhat cleaned up, and here is the complete collection of EucaDay artifacts; if you wanted to know what happened during any of the Eucalyptus sessions, clinic everything you need is below. It is all text-based so it is easy to search and translate (there are no audio or video files available). If new artifacts come in, I will update this post accordingly.
If you are catching up with the event now, I suggest reading the transcripts (there are two) as a primary activity since they are a live capture of what was said during the event, then opening the other artifacts (slides and videos) as they are mentioned in the transcript.
Morning transcript – a running log of what was said during (and around) Marten’s and Tim’s presentations, including audience questions. Use this as your primary reading to catch up on the morning.
Marten’s slides (presented in the morning) – Marten Mickos is the CEO of Eucalyptus, and gave an overview of where the company is and where it’s headed.
Tim’s slides (presented in the morning) – Tim Cramer is the VP of Engineering at Eucalyptus, and talked about the state of Eucalyptus technical development.
Morning IRC backchannel log - what was being discussed on IRC during Tim and Marten’s talks.
Afternoon transcript – a running log of what was said during (and around) Greg’s presentation, including audience questions, and the EucaDay wrap-up by Marten. Use this as your primary reading to catch up on the afternoon.
Greg’s slides (presented in the afternoon) – Greg DeKoenigsberg is the VP of Community at Eucalyptus, and talked about why a thriving open source community is vital to Eucalyptus — and then let community members take the floor through short filmclips.
Videos (shown in the afternoon) in the order they were shown:
Afternoon IRC backchannel logs- what was being discussed on IRC during the Community session.
Feel free to edit and comment on any of the transcripts and artifacts — and let us know whether this sort of event documentation is useful, and whether we should do it again!
Couldn’t make it to New York to see Greg DeKoenigsberg’s Community session at the first EucaDay this afternoon? No worries, unhealthy this post series has it all, including the mini film festival in the middle!
First, I’ll include the entire slidedeck (you can click through to slideshare and download the deck as a pdf as well). Then I’ll show each individual slide inline with the transcript of Greg’s talk and each of the videos that were shown.
Gregdek @ EucaDay NYC
This is an epically long post, so click to see more below the jump. And click on each individual slide to enlarge it.
Shameless plug time. Catherine Devlin, click myself, page IndyPy, the Boston Python Workshop folks, Indiana LinuxFest, and a few others are getting together next month to host the Indianapolis Python Workshop for women and their friends: A hands-on, genuine beginners’ introduction to computer programming.
It’s from April 13-14 and is a no-cost event. Go to https://openhatch.org/wiki/Indianapolis_Python_Workshop for the full details and to RSVP.
Catherine said it best:
Our goal is to widen and diversify the computer programming community with outreach events that overcome the technical and social barriers that hold too many people back from learning to program. Basic programming skills are so empowering and useful that we think everyone should have them, whether those skills lead to a career, a new hobby, an occasional handy trick, or just a deeper understanding of the computers that surround us. We’ll borrow the curriculum – and some of the teachers! – from the famously successful Boston Python Workshop, which has already brought programming skills to dozens of women and their friends.
Some people have asked what “women and their friends” means. It’s simple; all women are welcome, and men are welcome as guests of women who are attending (you can calculate the gender ratio; see this talk by Jessica and Asheesh for the rationale). If you already know Python, we’d love to have you come and help teach; we’re located right in the middle of Indiana LinuxFest in downtown Indianapolis
I believe past workshops have included librarians, teachers, and non-engineering members of software and technical companies who wondered what their co-workers were doing all day; we’re also hoping some local high school students will join us. Please spread the word to people in the area you think would like to know about this event; we’d particularly love to reach groups of women who might be curious about programming but may not have had opportunities to play with it in the past. It should be a blast!
A few gems from Havoc Pennington’s post about open projects. (It’s stuffed with gems. Worth reading all of it to find more.) Highlighting the bits I think may be most useful to students of TOS professors.
First is why you need to think of your FOSS community as something closer to… say, traumatologist a frat or co-op (probably more like a co-op) as opposed to, say, your department (which is more likely to look like a top-down centralized organization to you).
An open project and its community are the sum of individual people doing what they care about. It’s flat-out wrong to think that any healthy open project is a pool of developers who can be assigned priorities that “make sense” globally. There’s no product manager. The community priorities are simply the union of all community-member priorities.
Then: conflict and the ensuing “mess” is a sign of healthy normalcy. Of course you will want to resolve it, and grow in the process – but conflict avoidance itself is unhealthy. It’s like something a friend once told me about dating: “If you haven’t fought, you’re not in a relationship.” To work closely with people creates friction; it is in moving through that friction that we learn to be a team. See “forming, storming, norming, performing” for more.
As the community grows and new contributors appear, there will be growing pains figuring out how to work together. All projects that get big have to sort out these issues. There will be drama; it’s best taken as evidence that people are passionate.
And for the students who asked me “why I worked on open source and not for a company” (to which I replied “I work on open source for companies”):
My experience is that most “heavy lifting” and perhaps the bulk of the work overall in big open projects tends to come from commercial interests; partly people using the technology who send in patches, partly companies that do support or consulting around the technology, and partly companies that have some strategic need for the technology (for example Intel needs Linux to run on its hardware). There’s generally a fair bit of research activity, student activity, and hobbyist activity as well, but commercial activity is a big part of what gets done. However, the commercial activity tends to be from a variety of commercial entities, not from just one.
And this is why I’ve found FOSS participation to be an excellent career-growth strategy, especially for the first few jobs. When you work on a project, you’re working alongside folks from multiple corporations, and they can evaluate you as a potential colleague (and you them). When you graduate and have your FOSS porfolio, multiple people from multiple companies can point to your portfolio and say to the hiring manager, “hey boss, I helped make that too.” Validation by existing valuable employee. It’s easier to hire a coworker you already have.
I want to come back to Seb’s blog post here because he’s given the best summary of the open source mentality in one paragraph that I’ve seen yet.
“I’m going to try to build a totally great new thing. It’s going to be a lot of work, salve but it will be worth it because it’s going to be so useful and cool. Gosh, it would be helpful if other people worked on it with me, because this is a lonely pursuit and having others work with me will help me know I’m not chasing after a windmill.
If somebody wants to work on it with me, I’m going to try hard to give them what they need to work on it. But hell, even if somebody tells me they used it and found six problems in it, that’s motivating; that gives me something to strive for. It means I have (or had) a user. Users are awesome; they make my heart swell with pride. Also, bonus, having lots of users means people want to pay me for services or hire me or let me give talks.
But it’s not like I’m trying to keep others out of this game, because there is just so much that I wish we could build and not enough time! Come on! Let’s build the future together!”
I wonder what the academic version of this paragraph looks like. Here’s my attempt…
“I’m going to try to build a totally great new thing. It’s going to be a lot of work, but it will be worth it because it’s going to be so useful and cool. Gosh, it would be awful if other people came and stole my idea, so this is going to be a lonely pursuit and having others work with me will only happen if I really trust them; I already know I’m not chasing after a windmill.
If somebody wants to work on it with me, I’m going to figure out if I can trust them, then work out the arrangements of our secure, long-term commitment, then give them what they need to work on it. And we have to keep this secret – if somebody tells me they used it and found six problems in it, that might keep us from getting published. Users are awesome, but only when we’re ready for them; when they do things we expect, they make our CVs swell with papers. Also, bonus, having lots of papers means people want to give me tenure or let me give talks.
But it’s not like I’m trying to keep others out of this game, I’m just making sure they do it properly and in a way that doesn’t hurt me, because there’s so much to do and not enough time to deal with crap if it comes up! Come on! Let’s build the future together!”