Posts that are fedora-ish

Liveblogging RIT’s FOSS projects class: initial questions for community spelunking

Stephen Jacobs (SJ) and I are co-teaching “Project in FOSS Development” at RIT this semester, which basically means “hey students, want to get course credit for contributing to a FOSS project?” The class is centered around 5 project sprints of two weeks each. The first 3 weeks of class are preparing for the sprint periods; the week before spring break is a pause to reflect on how sprints are going. Otherwise, class efforts will be centered around executing project work… (aka “getting stuff done”).

From the syllabus (

This course is a studio-centric experience designed to immerse students in the praxis of FOSS (Free and Open Source Software) communities. Notice that we focus on praxis, which is a conscious enactment of practice deeply informed by theory. In other words, it’s important to be practitioners who can think about their shared practice.

Notice also that we talk about the praxis of FOSS communities, which includes but is not limited to software development — ways of communicating, collaborating, designing, testing, marketing, budgeting, meeting, etc. are just as much a part of FOSS (and software engineering) praxis as writing code. You will be creating FOSS software, and you will be engaging with the rhythms, relationships, and routines of an established FOSS community with a complex set of sociotechnical dynamics that exist independently of yours. It is our hope that this course will help you navigate the kinds of delightfully messy, large-scale, long-term projects that you will encounter out in the real world.

I’ll be liveblogging the class, as one does. Right now, students are working on their project proposals, which is a big messy task that involves spelunking into existing FOSS communities, figuring out what’s up, and thinking about what’s possible to accomplish during the course of the semester. During our last class, we collaboratively brainstormed a list of starter questions we want to find out while doing that initial community spelunking. I was impressed by how much the students were already thinking about sociotechnical dynamics (instead of just starting to myopically look at the code in isolation), which makes me super happy.

Here’s what we came up with, in thematic clusters.  You can think of these as guiding questions for a spelunking quickstart such as (basically, if you only had a few minutes to get a sense of whether you wanted to contribute to a FOSS project, what questions would be the highest-priority ones to ask)?

  1. What are we gathering around?
  2. What are the goals and the roadmap to get there?
  3. What’s the purpose of the project? Do they have use cases?
  4. Why should I want to contribute?
  5. How do I find people and information and ask for help?
  6. How do they communicate? Do they have forums, chatrooms, mailing lists, etc. and how can I start lurking?
  7. Who’s leading it and who’s working on it?
  8. What is the governance/leadership structure? How do decisions get made, and how fast?
  9. Do they have local meetups and/or online ones I could attend?
  10. How complete are the docs?  Where do I go and what do I Google if the thing I want isn’t in the docs?
  11. How thoughtful have people been about the contributor experience (and do I want to have that contributor experience?)
  12. Do they have a code of conduct? How good is it?
  13. Do they have contributor guidelines?
  14. How well do they Onboard?
  15. How can I help and what skills do I need? (Can these questions be answered easily?)
  16. What does the code activity look like?
  17. What’s the infrastructure?
  18. What is the license? (Make sure it’s actually a FOSS project.)
  19. What and when was the last commit to a core repo?
  20. What/when was the latest release and how is it working?

Want more inclusivity at your conference? Add childcare.

Providing conference childcare isn’t difficult or expensive, and it makes a huge difference for parents of young children who might want to come. If your community wants to (visibly!) support work-life balance and family obligations — which, by the way, still disproportionately impact women — I urge you to look into providing event childcare. I don’t have kids myself — but a lot of my friends do, and someday I might. I’ve seen too many talented colleagues silently drop out of the conference scene and fade out of the community because they needed to choose between logistics for the family they loved and logistics for the work they loved — and there are simple things we can do to make it easier for them to stay.

A good number of conferences have already started offering free or low-cost childcare on-site, and Above All Human is one of them. (Above All Human also used a Code of Conduct, another simple way to shift conference culture towards inclusivity and diversity.)

I talked with Scott Handsaker, one of the conference organizers, to ask how they set it up. It was easy. There was an existing daycare facility nearby, so trained staff, equipment, space, and insurance were all taken care of. All Scott had to do was negotiate the price, which ended up being $30 per child. Out of 1,000 people in attendance, roughly 10-15 used childcare, for a total price tag of $300-$450 per day.

The resulting slew of publicity was tremendous. Scott mentioned they were late in organizing childcare — too late to advertise it on the conference website — so they only had a little time to message via email and social media. Even so, childcare was the #1 thing people tweeted about leading up to the conference. (“This [twitter search] nowhere near captures the volume of tweets or the sentiment,” Scott wrote.) In fact, that’s how I found out about Above All Human in the first place — a former classmate raving about childcare on social media. This is the sort of exposure you want for your event, brand, and community. Financing conference childcare was snapped up by Slack as a low-cost, high-impact, high-visibility corporate sponsorship opportunity.

If your conference location doesn’t have childcare on-site, talk with nearby childcare providers or a local college with an education/teacher-training program. You’re looking for care providers with training in early childhood education or some similarly related field, medical knowledge (CPR/AED etc), and enough experience to take care of insurance and logistics, which often involves negotiating directly with the hotel or other conference location about space and setup.

Some conferences have written documentation on their childcare setup. GovHack wrote a behind the scenes look at childcare for their conference, and YOW stands as a good example of how to promote it.

Right now, determined conference committee members can pull something together for their own event by taking advantage of resources like these, as well as tapping into the informal network of conference organizers who’ve coordinated childcare in the past. However, that network can be hard to find — so as more and more events attempt to do this, we can share notes and work to make it easier. A great next step would be to compile more writeups about the childcare-at-conferences process and to list events that have had it and are willing to talk with other events who are interested. Eventually, we could create a series of templates and guides for how to email daycare providers, how to advertise, what insurance to secure, and so forth. If you know of existing resources or efforts, please let me know and I’ll add them to this post.

Edit: Reader-provided resources so far…

  • David Nelson Adamec noted that PyCon, a major programming language conference, provides childcare: “I like that they call out “Company X is our childcare sponsor”, making it a cool thing to be and encouraging others to follow suit,” says David. He also noted that has more general tips for organizers.
  • Sara Melnick noted that SIGCSE, a major CS education conference (academic) provides a kids’ camp, almost like a parallel conference for children:
  • Bonnie Tesch submitted MoMiCon, an academic gathering deliberately designed as a conference format experiment designed for mothers with young children. Some very cool design ideas here.
  • Anne Lucietto noted that childcare isn’t the only need — sometimes adult care is needed as well.
  • Peter Barszczewski noted that the same setup applies to hackathons.

On the relative openness of text/document formats: .txt and .csv

My friend and research colleague Todd Fernandez writes: I know the ODF (Open Document Format) is generally the preferred format from an open documents standpoint. My question is whether you [and other Free/Libre groups] would consider .txt files in Unicode and .csv (comma-separated value) data files considered equivalently open?

First of all, disinfection I can’t answer for FSF or other groups — so what you’re getting is the Mel answer to “are .txt and .csv files open?” This email reply is getting so long that I’ll turn it into a blog post.

The Mel answer is “yes.” I consider .txt files in Unicode and .csv to be “open.” In fact, remedy I personally prefer to use them over ODF, which I’m rarely able to open with the software pre-installed on most computers I encounter.

In the paragraphs that follow, I’ll get into more detail behind my reasoning. To define “open” and “free,” I’ll loosely use the Open Source Definition (OSD) and the Free Software Definition, noting that these were created for software and need to be adapted for a discussion on file formats.

In discussing these file formats, I’ll cover .txt first, since .csv builds on top of .txt. The file extension”.txt” can mean a lot of things, and each of those things has different levels of open-ness (from a more legal-ish open standards standpoint, see definitions above) and accessibility (from a “how many people are able to read/write them on their computers with their current software” standpoint). I personally care about both.


You asked specifically about Unicode, but “.txt” can also mean ASCII, which is/was an American-developed standard for text information. I’ll start here, since ASCII was where Unicode began (in fact, ASCII’s 128 characters are Unicode’s first 128 characters).

ANSI X3.4-1968 is the document describing this encoding. It is a standard that’s widely used and published, lots of programs can access it, and you can use it in your programs without too much effort and without licensing costs (as far as I can tell; I can’t easily find the exact legal status). Basically, if I translate the Open Source Definition from software to file formats, I can’t find evidence that ANSI X3.4-1968 itself contradicts any of its criteria. I know this is different than proving that it absolutely meets all these criteria, but this is good enough for me.


As an interesting side note: ASCII is an ANSI standard (American National Standards Institute, hence the ANSI- prefix on its standards document). ANSI’s definition of “open” is about “do stakeholders have access to the consensus decisionmaking process that forms the standards?” and “are licensing fees and getting permission to use the standard at a reasonable and not overly burdensome level?” rather than “are there no licensing fees and permissions needed at all?” The latter corresponds to part of the 4 requrements for “freedom” according to the FSF, so it’s possible for something to be “open” according to ANSI but not “free” according to the FSF.

It would be interesting to go through and do a more rigorous look on whether ASCII’s legal/licensing criteria meets the Four Freedoms. I’m not a lawyer, but I’d be interested in what a lawyer would say.


“.txt” can also mean UTF, or Unicode Transformation Format; this is what your email asked about. The “A” in ASCII stands for “American,” and “American” in this case meant “monolingual,” meaning that if you wanted to type something outside ASCII’s 128-character, heavily-biased-towards-American-English set, you were flat out of luck. Unicode took the first 128 characters of ASCII, then… kept on going. Unicode is a more internationally-savvy superset of and successor to ASCII.

UTF-8 and UTF-16 are two Unicode variants in common use. The numbers refer to the number of bits per character, which you can think of as “UTF-16 has more letters in its gigantic international meta-alphabet than UTF-8.” UTF standards are developed by the Unicode Consortium, which I keep mistakenly typing as the “Unicorn Consortium” (which would be kinda awesome).

Unicode’s copyright permissions language seem very, very similar to the 4 requirements of the FSF for freedom. Since ASCII is a subset of Unicode, this makes me even more comfortable saying that ASCII is also “open.” However, I am not a lawyer, nor am I using “open” in a legally rigorous sense here — remember, I am a non-legally-trained engineer going “yeah, I don’t see anything that contradicts the definitions made for Open and Free software, if we were to translate it to file-formats-land.”


CSV is a format that’s layered atop plaintext (ASCII, UTF, whatever). In other words, you use plaintext to write a CSV document. CSV itself is not formally specified, which means it’s a free-for-all, and… you can use it for whatever, because you’re pretty much making it up. It’s just that you’re just making it up in the same way lots of other people have made it up.

Then again, “official standards” are just a group of people who have made things up and have agreed to stamp the label of “official” on their work; it’s still a social construct that depends on how many other people agree with them. (I can make something an “official” standard according to Mel, but if nobody else agrees with me, my standard is useless.)

Anyway, I’m not sure if that qualifies CSV as “open,” but it’s certainly not “closed.” To me, CSV is just as open as whatever underlying plaintext (.txt) format it’s using. But again, I’m not a lawyer, don’t work for the FSF, etc. This is just one hacker’s opinion, and I’d love to hear what others think.

On the diversity-readiness of STEM environments: “It’s almost as if I could only enter the makerspace as a janitor.”

My thoughts from an online discussion with other female Olin engineers on this NYT article on “how to attract female enginers, women’s health “, edited for context. In particular, we brought up the (well-worn) claim that women don’t want to “just focus on the tech stuff” and want to “do sociotechnical/humanitarian work that makes a difference in the world.”

I’ve built my career as a “technical community person” who “thinks beyond the technology,” and as a teacher and researcher of learning environments — so this may come as a surprise to people who know and have worked with me. But if my teenage self had had her way, I would have VASTLY preferred to “just focus on the tech stuff.”

As a kid, I wanted to choose the privilege of being oblivious and keeping my head down and immersing myself into the beauty — the sheer beauty! — and joy of STEM for STEM’s sake. I didn’t become an ECE to work on educational computers or hearing aids or anything like that. As my friend (and former roommate) Kristen Dorsey said, “I just geek out about nerdy stuff, OK?”

But I couldn’t “just geek out about nerdy stuff.” The environments where I was trying to “learn about nerdy stuff” were sociotechnically broken in a way that made it hard for me (as a disabled minority woman, among other things) to join in. If I wanted to even start being part of the technical community, I had to start by fixing the technical community — patching the roof and fixing the plumbing, so to speak — before I could even walk inside and start to live there. And when I patched the leaking roof, I patched the roof for everyone, and other people who needed non-leaky roofs to be in the community could now… be in the community as well!

For instance, I got really, really good at facilitating meetings because it was the only way I had to make meetings accessible to me — when other people facilitated meetings, they’d often forget I need to lipread, so… I just quietly started leading them myself, and ended up making meetings work better for everyone. And I found that when I drifted towards “humanitarian” projects, the people there were much more conscious of sociotechnical things and more likely to have already-healthy environments, so I would have less leaky roofs to patch, and less resistance when I tried to patch the roofs — and people actually recognized and valued roof-patching labor instead of looking down on me for not writing code full-time.

After a while of patching roofs and unclogging toilets and plastering the rotten drywall, I got a reputation in industry for being really, really good at open-source software/hardware (technical) community facilitation. It’s almost as if I could only enter the makerspace as a janitor. And part of me resented that, but never said so. But, I told myself, at least I was in the building. And I saw that my “janitorial” work made it possible for other people to enter the building and do the things they wanted to do — which were often the things I wanted to do, too! — and so I thought: okay. That’s okay. At least somebody gets to do it. I can see my gift to the community doing so much good, that I will give up my desire to learn and do the technical things — so I let my own STEM learning slide. I am good at “community work,” and I did come to genuinely love it, over time.

But if I had the choice, I would have never gone into “community work.” I would have chosen — if I had the choice — to focus on “shiny tech stuff” that… didn’t save the world at all. If my teenage self had had her way, I would not do community-facilitation-anything, I would not be thoughtful about women or minorities or disabilities or any underprivileged group in engineering… I would be oblivious to all my privilege. I’d be a kernel hacker, or an embedded geek, or something “hardcore technical,” Because I could be.

But I didn’t have the wherewithal (or the desire) to shovel all the stuff out of the way that I would have to do in order to do that. If you think of “caring/environmental labor” as a sort of tax some people have to pay in order to get to “learning/doing technical things,” my tax rate has always just been too frickin’ high.

So I have been “the full-time community person who is ridiculously good at tech stuff that she no longer gets to do,” instead of “the technical person who understands and listens to and cares about inclusion and community.” Because I cannot not patch a leaky roof. But I have always wondered what I might have grown up into, if I had learned STEM in an environment that was ready for me — without me having to fix it first.

Unlock challenge: raise $1024 for The Ada Initiative, support women in open tech/culture, and unlock more open-licensed “programming learning styles” material!

Last year, shop I wrote a post asking people to donate to the Ada Initiative and support women in open technology and culture. I said:

We change the world with millions of tiny patches… 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. –August 30, 2013

Why do we need to do this? Well, being a woman in open technology and culture is like riding a bike on a street made for cars, where rain and dirt get kicked into your face, and you are constantly, painfully aware that if you have any sort of collision with a car… the car will win. Yes, this is happening in our world, to our friends and to our colleagues; it’s happened to me personally more times than I care to remember. The farther you are from the straight white male difficulty setting, the rougher the terrain becomes.

And quite honestly, we’re busy. I’m busy. You’re busy. This isn’t our job — we have so many other things to do. I mean, we’re all:

  • remixing music
  • playing with code
  • writing science fiction
  • co-authoring open content articles
  • redesigning user interfaces
  • <insert your favorite open technology and culture activity here>

And guess what? There are so many people who want to join us. So many people who want to help us do all this work, but don’t, because they know that work — the good work — is likely to come with a lot of really, really awful stuff, like this sampling of incidents since last year (trigger warning: EVERYTHING).

The less time women spend dealing with that stuff, the more time they have to help us with our work. And the more people will want to help us with our work. I mean, would you want to accept a job description that included the item “must put up with demeaning harassment and sexual jokes at any time, with no warning, up to 40+ hours per week”?

Making our world a good environment for all sorts of people is, in fact, our job — or at least part of it. The folks at the Ada Initiative have made supporting women in open tech/culture their entire job — supporting it, supporting people who support it, and basically being the equivalent of code maintainers… except instead of code, the patches they’re watching and pushing and nudging are about diversity, inclusion, hospitality, and just plain ol’ recognition of the dignity of human beings.

They want to support you. With better conference environments, training workshops and materials, and really awesome stickers, among many other things. (Did you know that the Ada Initiative was one of the first woman-focused tech organizations to actually say the word “feminism”?)

So please, donate and support them, so they can support you — and me, and all of us — in supporting women in open tech/culture.

Now, my own contribution is a bit… sparse, financially. I’m a grad student earning less than $800 a month, and I’m waiting for my paycheck to come in so I can contribute just a few dollars — but every little bit helps. And there’s another way I can help out: I can bribe you, dear readers, to donate.

Remember that “active vs reflective” learning styles post I wrote in August? Well, there are 3 more: sensing/intuitive, visual/verbal, and global/sequential. I’ve got them all transcribed here and ready to go. And if we reach $1024 in donations to the Ada Initiative under the Learning Styles campaign within the next week, I will release them under a creative-commons license.

What’s more: the first 3 people who donate $128 or more to this campaign and email me their receipt will get a free 1-hour Skype call with me to discuss their personal programming learning styles, and will be featured as case studies on one of those three posts (I’ll link to your website and everything).

Donate to the “learning styles” campaign for The Ada Initiative now!

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, disorder please donate to the Ada Initiative, viagra dosage 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, salve 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.

EduPsych for Python Hackers 2.0: revised, expanded, updated

EduPsych for Python Hackers 2.0 is about to go live in Toronto in 45 minutes, troche which means it’s time to upload slides! Questions, comments, etc. welcome as usual. This is an expanded, revised version of the previous EduPsych-For-Hackers talks I’ve given, so if you’ve seen both, I’m curious what you think of the changes.

Also: my parents will be in the audience for the first time (since I started speaking over half a decade ago), so they get a special call-out on slide 29.

Ok, off to hyperventilate!

PyCon Toronto 2013: EduPsych Theory for Python Hackers 2.0 from Mel Chua

Video (subtitled!) and transcript for 2013 PyCon talk, “EduPsych Theory for Python Hackers”

The video for my 2013 PyCon talk, pfizer “EduPsych Theory for Python Hackers, adiposity “ is up. It’s 27 minutes and 56 seconds long, and you can view the subtitled version

(Disclaimer: I’m transcribing my own talk about a week after having given it, but I am deaf, so I’m typing this out through a combination of residual hearing, remembering what I said last Thursday, lipreading myself in the video, and reading slide content. It’s probably 98% accurate; patches welcome on Universal Subtitles.)

EduPsych theory for Python Hackers: slides and an extended Q&A with further-readings

I recently delivered a talk at PyCon called EduPsych theory for Python Hackers: a whirlwind overview.

Description: I’ve taken two years of graduate courses in engineering education. I save you $50k in tuition and hundreds of hours of reading and give you the short version for Pythonistas who care about education and outreach.

The slides for my talk are below; video will be coming soon at this location (it’s not up yet, illness but I’ll update this blog when it is). [Edit: it's up!]

EduPsych Theory for Python Hackers: A Whirlwind Overview from Mel Chua

After the talk, page I was asked where to go for more information about the Dreyfus Model for Skill Acquisition and how to counteract the phenomenon that people at the more experienced levels don’t remember what it was like at the less experienced levels. The Dreyfus brothers wrote several things about their model; the most often-cited is the book Mind Over Machine. It’s a good book, visit this but their ideas about skill acquisition evolved as they wrote about it — so if that’s what you’re focused on, I would look to their most recent 2008 essay on mastery (doc) for a description (also, it’s freely available online). Here we find some clues as to why experts often forget how to teach novices.

The first clue is the notion that an “immediate intuitive response… characterizes expertise.” You no longer think about the decisions you’re making, you just do — and if pressed to explain why you did what you did, it’s difficult; you can’t describe rules you didn’t use. It just “feels right.” That’s really the gist of it; unless they’re very conscious of their actions, it’s easy for experts to forget that not everyone can “read” the surrounding context as fluently as they do.

The literature on situated cognition and cognitive apprenticeship describes this a bit more fully. Brown, Collins, and Duguid’s paper “Situated Cognition and the Culture of Learning” talks about (on page 37) how many times, practitioners won’t be able to even execute their normal work outside of context; they won’t be able to remember or describe things when they’re standing outside their workplace (it’s so much easier for me to type a new Python program off the top of my head than to stand in the center of a room and recite it out loud). That’s because our mental representations are embedded in the context of our workspace (fancy word: “indexical representations”). In the “history” portion of my presentation, I talked about how (according to one paradigm, anyway) learning is situated — but by the same paradigm, once you’ve learned knowledge, the knowledge stays situated too!

Going along (this is from p. 34 of the same paper), when we transfer an authentic, situated task into the classroom and transform it into a sterile, context-less thing, we create problems for both learners and teachers (if the teachers are experts). The experts don’t have the context they rely on to navigate their tasks intuitively; they’re stuck with rulesets they no longer use. The novices, on the other hand, don’t get the chance to learn how to navigate the richness of a real-world context. When we do this, we usually say we’re “cutting out the noise,” but that “noise” is actually a large part of the point; people need to be learning in context. This is like handing someone a Wikipedia page on A Midsummer Night’s Dream and saying “I’ve just saved you so much time — now that you’ve read the plot, you don’t need to go see the play!”

Several counter-actions to this are possible. First, just being aware of this phenomena — having the Dreyfus stages as a tool with which to think about your own skill level and the skill level of your students — is tremendously helpful. Donald Schoen describes this sort of thing as knowing-in-action and reflection-in-action, ideas that are themselves useful to read about; his essay “Knowing­ in ­action: The new scholarship requires a new epistemology” is a good starting point, especially pages 29-32 (from “Turning the Problem on its Head” until you reach “Project Athena at MIT”).

Now you’ve got experts teaching in the context they’re skilled at navigating, aware that they see the world differently than their students, and reflecting on their actions as they go along (or at least that’s what you’re trying to have, anyway). So how do you teach — what strategies do you use to structure and design experiences in the classroom? For this, I’ve found the framework of cognitive apprenticeships a useful one. “Cognitive Apprenticeship: Making Thinking Visible” is a good starter and has teaching examples embedded within it.

To bring this all together in an example that really happened during PyCon: let’s say I’m Aleta Dunne, the maintainer of planeteria, and I meet someone named Mel Chua at PyCon, and she’s interested in poking around the code and maybe submitting a patch. 

  1. The first thing I’ll do is to stay in this context. I’m going to take Mel to the actual code instead of trying to talk about it only abstractly and from a distance.
  2. Second, I’ll think about where I fall on the Dreyfus scale here… perhaps I don’t feel like I’m an expert yet, but maybe I’m proficient.
  3. Then I’ll think about where my “student” falls… hrm, this Mel person is pretty new to this particular codebase, but she seems to have seen some code before. She can’t yet prioritize what chunks of code are important here, though — that’s a sign that she might be an advanced beginner.
  4. Aha. As a proficient person, I can prioritize what’s important — and as an advanced beginner, Mel can’t yet. So prioritizing problems is something I will probably need to scaffold her on as we progress. (For those who saw the talk: Aleta is thinking about bringing “prioritization” into Mel’s zone of proximal development, because Mel can’t do it without Aleta — yet — but perhaps Mel can do it with Aleta’s help.)
  5. Let me start prioritizing tasks and reflect-in-action to figure out what I am doing — the underlying rules I’m using. Why do I think this ticket might be a good one to work on compared to the other tickets I can see? Okay — now… can I explain a bit of that logic to Mel and see if I can help her walk through a similar thinking process for a second ticket?
  6. …and so forth. It’s not a perfect example, but you start getting the idea (I hope) of how these tools-to-think-with can blend into your actions in a teaching-learning-doing space.

There are benefits to this for the expert-teacher’s performance as well. Further on in that paper by the Dreyfus brothers I linked to earlier, they go on to speculate that for experts in a state of flow, “all of the brain’s activity is focused solely on performance so nothing new is learned” (emphasis mine). Therefore, to move towards mastery, they say that…

“It appears that the future master must be willing and able, in certain situations, to override the perspective that as an expert performer he intuitively experiences. The budding master forsakes the available “appropriate perspective” with its learned accompanying action and deliberatively chooses a new one. This new perspective lacks an accompanying action, so that too must be chosen, as it was when the expert was only a proficient performer. This of course risks regression in performance and is generally done during rehearsal or practice sessions.”

In other words, to answer the question original question directly:

  1. Experts can teach better by backing out of their instincts and deliberately stepping into different patterns with awareness, bringing their students along for the ride.
  2. This is difficult to do (and experts don’t do this often) because it often makes them perform worse and look dumber.
  3. Therefore, to teach better, get over the fear of looking dumb — and when you do that, you’re on the track to mastery.

RAT: Wherein Mel finally defines, describes, and backs up what the heck the praxis of radical transparency is, sort of.

One of many posts on my Readiness Assessment. As a reminder of the ground rules, drugs this is a solo assessment, so while I’m allowed to think out loud on my blog, I can’t ask for or get (intellectual) help. Cookies and emotional support are, however, welcome.

I am now up to 28 pages without figures (probably in the mid-thirties with them), and argh, my cross-disciplinary citations are weak. I don’t think I’ll have time to shore them up before submitting my RAT, but it’s something to talk with Robin about afterwards.

The more time I spend in academia, the more signs I see that the scholarly work of research and teaching are domains I could really build a home in and settle into. I have this sort of feeling. And the more time I spend in academia, the more signs I see that my practice is the practice of open communities. I need to freakin’ articulate WHAT THAT IS, though. So.

Radical transparency refers to the cultural practices used by healthy open communities (Free/Libre and open source software, open content, and open hardware projects) to expose their work in as close to realtime as possible and in a way that makes it possible for others to freely and non-destructively experiment with it.

I can work with that. It’s not perfect, but… I can work with it. I need to unpack that phrase. I think I’m going to have to cite Raymond. Also, good lord a lot of this is philosophical and not empirical — I’m so thankful for the dissertations of all those folks from the last blog post.

Okay. Breaking it down.

…cultural practices…

Radical transparency is a praxis (that’s a fancy word, by the way, that means specific scholarly things that I should unpack more but don’t have the time or energy to read about right now — it’s sort of like “action-practice, practice-that-makes-changes,” go read the wikipedia page) that has been adopted across various domains (for instance, the production of encyclopedias, operating systems, web browsers, and so forth) by communities of practice as part of their practice. A community of practice, a notion first articulated by sociologists Jean Lave and Etienne Wenger (1991), consists of a community of people who share a common practice within a domain of knowledge (Wenger, McDermott, & Snyder, 2002).

Exploring all the possible permutations for domains, communities, and practices gets complicated quickly. Multiple communities of practice may exist for a given domain; BSD, Linux, OSX, and Windows are all situated within the domain of operating systems development, but the former two are radically transparent whereas the latter two do not. Not all communities that utilize radical transparency are successful, as Mako Hill’s research (2012) on failed online enyclopedia projects shows (and plenty of communities without radical transparency do just fine, as Apple, Inc. demonstrates).

Furthermore, the use of radical trasparency as a praxis does not necessarily mean the presence of a community; Krishnamurthy’s (2002) looked at the 100 most active mature projects on Sourceforge, a popular open source project host, and found the most common team size was… 1. To further complicate matters, not all projects that claim to be open actually implement radical transparency; Phil Marsosudiro coined the term fauxpen to refer to projects that talk the talk but fail to walk the walk (Searls, 2009).

…used by healthy open communities…

Before we run into a quandary of boundary articulation, I’ll offer up a phrase specifically created to make it easier for us to discuss this phenomenon. Since the phrase radically transparent community of practice is somewhat awkward, we’ll use the term open community as a shorthand to refer to any community that utilizes the praxis of radical transparency as part of their practice, regardless of how they self-identify. For our purposes, if it walks like a duck and swims like a duck and quacks like a duck, we’re going to call it a duck (Heim, 2007).

Successful open communities are fascinating ducks. They’re actually more like platypi – strange hybrids that make researcher after researcher exclaim what the heck is that and how is it alive? What are the economic dynamics of these communities (Lerner & Tirole, 2002; Lakhani & Wolf, 2005; Lerner, Pathak, & Tirole, 2006)? Why would people join (von Krogh, Spaeth, & Lakhani, 2003), work in (Hars & Ou, 2002), and help colleagues in such a group? (Lakhani & Von Hippel, 2003) How can such an unorthodox arrangement possibly be successful? (Bonaccorsi & Rossi, 2003)

Against that sort of backdrop, one of the biggest early triumphs of open communities has simply been to prove the possibility of their existence to a sometimes-skeptical academic and corporate audience. Every successful project stands as a living, thriving example of what the dynamics and output of a radically transparent community in their domain could look like.

…to expose their work in as close to realtime as possible…

So what do these communities look like – or more to the point, what exactly does this praxis of radical transparency entail? One key cultural can be summed up as if it ain’t public, it don’t count. Coleman’s (2010) ethnography of hacker conferences described the „validity and importance of such public discourse,“ noting that even small conversations at in-person gatherings would consistently reference and center around publicly-archived conversations. A related pattern, release early, release often, ensures the frequent presence of a contributor’s voice in these highly-valued public conversations; realtime exposure thus carries a clear benefit to the individual. Linus’s Law, (Raymond, 1999) is sometimes cited as a benefit of this behavior to the larger community: enough eyeballs make all bugs shallow – an argument fascinatingly similar to engineering education conversations about the importance of cross-disciplinary collaboration (Adams, Mann, Forin, & Jordan, 2009; Borrego & Newswander, 2008) both in terms of the rhetoric employed and the amount of philosophical work backed up by empirical evidence (alas, not enough).

The desire to get one’s work in front of more eyeballs motivates radical transparency practitioners to target each of their contributions towards the open community where it will benefit the most people, a pattern called pushing to upstream that inadvertently benefits component reuse and quality control (Aberdour, 2007). Ellis, Hislop, Chua, and Dziallas (2011) note that making something publicly and easily available does not necessarily imply widely advertising it, a distinction that preserves a reasonable signal-to-noise ratio. Multiple empirical studies by Elliott (2007) confirmed that when contributions are „pushed upstream,“ the contributions themselves are used as „stigmergic cues to negotiate contributions“ and the „upstreams“ become workspaces that served as boundary objects that removed barriers to participation.

Participation is often solo and asynchronous, as Howison’s ethnographies of variouso pen source projects (2008) revealed. However, they are done „in company“; Howison uses the phrase „Alone Together“ as his title. Efimova’s ethnography of blogging knowledge workers (2009) explored how these asychronous conversations became an indirectly enabling network that supported the sense-making of participants who were able to embrace the „transparency and fragmentation of [their] work“ that the process entailed.

The stigmergic nature of collaboration means that, at any given time, a contributor is likely to be creating a new whole by adding one small part to the top of an existing stack of components, leading to Robinson’s Maxim of begin with the finishing touches (Karlie Robinson, personal communication, 2009).
This pattern is also a sign of respect for oneself and other contributors. As Eric Raymond’s „How to Become a Hacker“ manifesto puts it, „No problem should ever have to be solved twice… Creative brains are a valuable, limited resource. They shouldn’t be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there… it’s almost a moral duty for you to share information, solve problems and then give the solutions away just so other hackers can solve new problems instead of having to perpetually re-address old ones.“ (Raymond, 2012) Again, this stance of default to open (another common phrasing) is largely motivated by philosophy, with practical consequences following from this philosophical stance.

…makes it possible for others to freely… experiment with it…

The philosophical roots of radical transparency can be traced back to the Free Software Definition, first written in 1986 by Richard Stallman, who continues to maintain it today (2012). As the title implies, the original document is about software, which does a user’s computing and is composed of source code; I have adapted the text below to refer to artifacts that serve a purpose to the user and are made of components of some sort, so here are the Four Freedoms in their generalized form:

The freedom to use the artifacts for any purpose.

The freedom to study how the artifacts work, and change it so it serves your purposes as you wish. Access to the components that comprise the artifact is a precondition for this.

The freedom to redistribute copies so you can help your neighbor.

The freedom to distribute copies of your modified version to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the components that comprise the artifact is a precondition for this.

Huh, I think I’m almost done. Last part: “nondestructively.”

I think I want to put something in here about how forking and commit access and peer review and version control lower the cost of a “mistake,” and cheaper mistakes mean we’re less worried about who comes in the door. My desire to nap for half an hour before heading to class outweighs the desire to write that at the moment, though. BEDTIME. I can’t break my string of no-allnighters from 2006, can I? (I mean, I can, but I don’t want to.)