Mel Chua: Hacker. Writer. Researcher. Teacher. Human jumper cable.

My research proposal (draft) as a comic book page

Robin asked me to try drawing what I was thinking. Here’s what happened. It peters out at the end where I start waving my hands around and going “I, I, I need to study this post-structuralism thing in Ohio in the spring,” but I’m actually fairly happy with everything up to the last two frames as something that might be understandable by folks from pretty much any discipline and from outside academia. (Maybe I need to explain radical transparency more?)

Anyhow. I wonder if the NSF would accept a (better) variant of this as one of the two pages of my fellowship research proposal, or if they’d just look at me funny.

research sketches: cross-disciplinary collaboration wtih radical transparency

Wednesday, September 12th, 2012 | engineering edu, olin, teaching open source | 3 Comments »

Think about Universal Design for FOSS community experiences, not just products.

If I asked a random FOSS community member whether they’d like more people to use the software (or content, 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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

Saturday, September 1st, 2012 | fedora, teaching open source | No Comments »

Research statement draft, aka “my contribution to eating the elephant”: radical transparency and discourse exposure during cross-disciplinary course design

Current draft of my research statement, such as it is. Obviously, I’m exploring ideas here; this isn’t the final format for submission anywhere. As always, patches welcome.

Disclaimer: This is being written for folks in academia. For people from the hacker world reading this and going “but Mel, what about the FOSS?” just think about how damn hard it is for FOSS to talk with academia (and vice versa) for things like Teaching Open Source — we need to tackle eating the elephant a small bite at a time. Right now, I still have a large plate that I’m trying to turn into a small bite (a bite labeled “dissertation”). But the plate is that I’m trying to figure out how to get academia to be more transparent about teaching so that it’s easier for those outside the academy (like most Free Culture projects, be they software, hardware, content, or whatever) to co-design learning environments and co-teach in them. Other people are eating different bits of the elephant; if you’re keen on helping us, either on one of our plates or by dishing up a new one of your own, I’m happy to help you pick up a fork.

Big Idea: Radical transparency practices of discourse exposure can lower barriers to all sorts of other serendipitous collaborations and types of work in engineering education — it is the grease that makes everyone’s engineering education wheels turn better.

Specific Population I Want To Look At Right Now: Cross-disciplinary undergrad/grad course design teams with engineering members. This means (0) groups of 2 or more faculty members who (1) come from different disciplines, at least one of which is engineering and at least one of which is not, and (2) are designing an undergrad or grad-level course that bridges those worlds that (3) they will be co-teaching in the future.

Why these people? Well, (0) faculty are established domain “experts,” so they have a known context of solid ground in their discipline’s community of practice as a starting point, plus at least some teaching experience helping others into that community of practice and the reflective processes that come with that. Cross-disciplinary faculty teams are thus (1) made of experts helping other people unpack a type of expertise that’s unfamiliar to them. They’re typically doing this for (2) adult learners who’ve already been in, or will very soon be in, “the real world” of work/industry, and they are (3) designing and preparing themselves to be a teaching team — they are invested in this prepwork and build a very, very solid, concrete, context-specific thing because they’re the ones carrying it beyond into the next term.

And why the moment of course design? Courses are a context where faculty are consciously and deliberately helping newcomers become aware of and fluent in their discipline’s community of practice. Looking at faculty during the process of course design lets us see their metacognition and reflection on that process in the calm before the storm of MUST GRADE NOW NOW NOW. It’s about the anticipation and preparation for that storm, which gives us a chance to peer at preconceptions (about the scaffolding needed for their students’ cognitive apprenticeships) far more easily. And awareness of and the ability to communicate and handle these preconceptions in ourselves and others is one key skill in a successful cross-disciplinary team member that’s often underdeveloped in STEM folks. (This last sentence has half a question-mark hanging over it; it’s from my vague recollection of some of Robin’s research, which I need to read more closely — I could be wrong on that.)

Some concepts from prior research that come from this section, and how familiar I am with the literature:

• expert practice, because faculty are experts and this may help explain how they think about their fields and how they got so good (spottily familiar — I’ve read a few papers, but don’t feel like I have a good big-picture grasp of Everything That’s Ever Been Done here. I don’t need a lot of depth here, so I feel like I can set a short sprint and do a time-bounded crawl and be okay.)
• dreyfus model of skill acquisition, and what it has to say about the blind spots of people with expertise (almost there; I’ve written about this, but need to re-read the paper deeply; ideally I’d like to find other things about expert-blind-spots as well, but this is bounded and reviwing it won’t take too long.)
• cross-disciplinary communication (big blind spot — I should do a bibliography-crawl through Robin’s stuff.)
• cognitive apprenticeships within communities of practice, which I did my big term paper on for Dr. Evangelou’s class in the spring. (I feel quite comfortable with this literature.)
• the design process (decent enough, and getting stronger through readings from Robin’s class this term)
• good course design practices (decent enough, thanks to CAP with Ruth and Karl last spring)

So that’s the context. What I want to do in that context is to look at the practice of radical transparency — what’s already happening, what additional techniques would be possible to implement and what sort of resources that would take, and the effects of it, both good and bad. I believe that if and when we practice transparency and constantl keep accessibility in mind, we’ll start seeing more and more serendipitous benefits and possibilities — the soil becomes richer, the fruit becomes lower-hanging, not just for us but for everyone in our ecosystem — and our ecosystem will be larger than we’ve ever expected.

And when I say “access,” don’t think about it in the sense of “for the disabled,” think about it more broadly, in the sense of “for the less-privileged.” And think about that more broadly than the “usual” cases of race, gender, class; we want to think about people who are less able to access your domain right now, for any reason. It could be a visual impairment. It could be that English isn’t their first language. It could be that they commute 3 hours each way to get to campus and are only here 2 days a week because their family and job are in another city, it could be that other people in their discipline have a low opinion of yours, or that they worry about stepping into new waters non-anonymously because their “stupid” novice questions will give others a chance to say “see, people-like-them aren’t very intelligent,” or that they aren’t sure what their families will think.

More concepts from prior research from this bit:

• radical transparency (I am at a loss here for what exactly this means and what literature would help ground me; I know I know things about this, but I haven’t solidified them into concreteness I can explain and back up with citations, and would benefit from being forced to explain and unpack this repeatedly.)
• accidental learning (vaguely familiar with concept, but need to read more on this and actually make annotated bibliography this time; this is bounded and shouldn’t take long)
• social learning and self-efficacy (vaguely familiar with concept, but would like to do a more thorough sweep through Bandura and related work; again, bounded and shouldn’t take long)
• access and privilege (vaguely familiar with concept, NOT bounded. I could build a bibliography and deep-dive forever if I had infinite time, but since I don’t, I’m not sure this is the most important thing to go deep on. I suspect I’ll be able to pick more of this up in the spring with Dr. Lather at OSU as part of her class on feminist and poststructural qualitative research methods.)

Finally, research methods. How do I want to go about doing this? I know I like (0) qualitative research that is (1) extremely small-scale — 1-5 subjects, meaning that I’m likely to produce narratives and case studies, and (2) uses a blend of ethnography and repeated active interviews both individually and in groups, with people making and/or modifying artifacts during sessions to help with their communication/design process. I know I intuitively incline towards a (3) weird, boundary-blurring, post-structuralist paradigm that seems to bewilder post-positivist thinkers (alas, most STEM folks are post-positivist but don’t know it), and that an important part of that post-structuralism for me is the notion of (4) radically transparent research, which may or may not be a new idea (but is new to me, and is emerging in the academic strains within the Free Culture movement I’m part of).

The final batch of landmark concepts for those methods in academia:

• grounded theory (I’m comfortable doing and explaining this to other people, though I don’t have — or need — a broad grasp of the history of the method and so forth.)
• small-scale research (case studies, narratives — again, comfortable reading and producing these, but by no means an expert on case studies, just a practitioner.)
• ethnography (same as above)
• active interviews (same as above)
• post-structuralism as a paradigm for qualitative research (I’ve been told I have a deep intuition for it, but that knack runs so deep I’m still struggling to become aware of what it is; I only know it’s “different from what everyone else is doing.” Again, Dr. Lather’s class on feminist and poststructural qualitative research methods will help greatly with this in the spring.)
• radically transparent research and research techniques being developed on the boundaries of Free Culture (I know and know of many people from the open source/content world doing research on that world and doing interesting things that really push out into methodological experimentation; research on Wikipedia, research on large Free Software projects, research in a world where people’s expectations of anonymity and confidentiality are reversed. I have not done a systematic lit review on this, and should deep-dive into it sometime; I’m not sure if that time is now.)

I feel like I should add a section here about my prior experiences and how they prepare me to engage on this topic, but maybe that’s the personal statement; in any case, this document is already longer than I’d like.

Friday, August 31st, 2012 | engineering edu, olin, teaching open source | No Comments »

How to help someone use a computer

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, it does that”. They need to develop a deeper understanding, 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.

Tuesday, August 21st, 2012 | fedora, teaching open source | 2 Comments »

Meta Be Bold: a roadmap to the project

1. I would first look at my first research journal, which contains a brief orientation to the project followed by the raw data (an interview, an observation, and a document) and brief memos about each of the three.
2. I would then take some time to sift through the current etherpad document where the talk is being written and commented upon and form my own judgments before going on to blog posts that compose most of the second research journal.
3. Having prepared in this way, I would read about the first-generation coding scheme used in this project, then the three themes that emerged: buddy boundary work, improvising multitasked physicality, and publicly performed symbiosis.
4. The link for the last theme also contains thoughts about the past and future of the project; I might consider those separately from the themes themselves.
5. Finally, I would go back to the keynote etherpad and start leaving suggestions and comments there that might be useful for Sumana’s keynote.

Everything is licensed CC-BY-SA, so have fun exploring. It’s a rough, freewheeling romp; we’re still in the “play!” phase and never quite moved out of it (or needed to) during the 2.5 weeks of the project, so there are plenty of opportunities for future polish if people wish to pick them up. Let us know what you think!

Thursday, June 7th, 2012 | engineering edu, teaching open source | No Comments »

Meta Be Bold: the theme of publicly performed symbiosis, and the past and (potential) future of the project

I will tie the final theme in Meta Be Bold, “publicly performed symbiosis,” into a discussion of this project’s past and its potential future. The two relevant codes here are:

Performance: Sections illustrative of the signalling of roles (for instance, through the use of lingo) and/or the effects of constantly working and speaking in a public space as opposed to a private one.

Effect: Sections illustrative of the impact of this mini-project on any of the individual people who’ve touched or been touched by it.

This blog post is a public performance during which I’m gradually stepping down the scaffolding of working you through my analysis and theme-creation process. If you want more on scaffolding, you can choose to go off on exploring that thread — for instance, reading page 5 of this paper on cognitive apprenticeships – or you can continue on the path of reading this blog post. Or both, or neither. Let’s recap where we’ve come from, because it’s been a crazy ride.

What has the process been? Here’s one way of looking at it.

1. A homework assignment of doing a mini-research project for Advanced Qualitative Research Methods in Education was given to Mel.
2. Sumana was contacted, and logistics for doing data collection were set up.
3. Data was collected (an interview, an observation, and a document, although these labels were somewhat arbitrarily given to each piece of data because that’s what the assignment asked for). A memo was written for each.
4. The data was reviewed, discussed, and analyzed by a research group of graduate students in the class.
5. Themes emerged from the data and were written down in the blog posts preceding this one.
6. These steps were written out in the passive voice, as is a common practice in the academic writing world (alas).

What’s happened to the people?

This project has affected (albeit in tiny ways) multiple people who’ve come in contact with it. Here are a few examples.

• Sumana now has an outline of her talk written, and potentially more eyes to help her fill it in and reflect upon it before she delivers the keynote towards the end of this month, including an audience that would probably otherwise not have encountered her work (graduate students in engineering education and communications). She’s also been at least somewhat amused (“I laughed aloud in glee several times”) by watching herself be analyzed, which makes me smile.
• I (Mel) fulfilled a course (and graduation) requirement and got some practice trying out her “sea legs” for her unorthodox research process and mentality. I’ve now got a (more) complete and digestible example of radically transparent research to show people, and a better understanding of how my technique needs to mature (short version: a lot).
• My research group is thoroughly confused. I say this with a grin — I like my research group and am thankful for their willingness to experiment! This seems to have affected their thinking about their own future research (“This was a very interesting interview and it really has made me rethink potential interview formats and styles”) though it’s too early to tell what sorts of effects these interactions will ripple out to have.

Where might we go next?

I can only speak for myself; other people can take this information different places (it’s all licenced CC-BY-SA).

If I were continuing this as a research project, I’d be actively getting responses to these blog posts I’ve just made and asking people to help with the next pass through the data (which now includes all the analysis I’ve just done). We’d probably end up concentrating on a second iteration of the codes, since so many codes overlapped into themes; perhaps we’d take the themes as our second set of codes and see where things landed if we used that for our next pass. We’d also probably do a literature review, which I didn’t have time to do for such a short project. I would personally want to pause and look at our methodology; what are we doing, what have we been doing, and is there anything we want to change about our process? I would also probably try to lead the creation of a more formal write-up more positioned within and towards the academic space for the next iteration of this project, as this version of the writeup (in the form of blog posts) is very much done within the space of the online FOSS world, with FOSS community members as its audience.

This would be the tip of the tip of the iceberg; I’d say that as a “research project,” it feels about 3% “publication-done” to me right now, where “publication-done” is “something I’d be happy submitting to scholarly journals in my academic field. In order to do that, we’d have to pass it through IRB, I would likely be going back to Sumana multiple times and talk with her about writing participant memos…

However, I’m not continuing this as a research project (for now), and that’s not the type of “done” I’m looking for. I wanted to pass a class; I hope I’ve accomplished that. Now I want to help with the second kind of “done” I care about, which is helping Sumana with her keynote; once she delivers it, that will be a second type of finishing.

Therefore, I will consider these blog posts as my “product” — for the time being. And I will now ask: Sumana, what’s the most helpful thing we can do to lend a hand with your keynote? After I print, staple, and hand in these blog posts for my homework assignment, your talk is the next step I care about on this right now.

The last post will be a simple index of all of these posts and artifacts in the series.

Thursday, June 7th, 2012 | engineering edu, teaching open source | 2 Comments »

Meta Be Bold: the theme of improvising multitasked physicality

1. Physicality: Sections illustrative of the impact of distributedness and/or co-location on interactions, including the simulation of physical presence in order to compensate for its absence.
2. Parallels: Originally a subset of Physicality called (the equally non-descriptive) “links and attention,” this code refers to the multithreaded nature of attention that online interaction affords, and appears largely in the use of hyperlinks throughout the various documents.
3. Nowness: This code refers to a sense of immediacy and a high consciousness of temporality, likely caused by the knowledge that, with unplanned online interactions, being with someone else is an opportunity to be seized. The prevalence of improvisation falls partly under this code, but is also related to the co-creation code.

The uniting theme is improvised multitasked physicality. I must thank Joi-Lynn Mondisa here for convincing me of the importance of explaining this theme, since it’s something I take for granted after spending so much time online myself. To paraphrase Sumana at 17:32 in our “interview” transcript: “I was thinking that I needed something INNOVATIVE AND NEW AND EXCITING to say, but that is not what a research writeup is for; the subject should be nearly boring to the writer and new to the audience.”

I shall describe a few examples from “the data” that fall under this theme, and let you decide for yourself how you’d have coded them. (Note how I’m using quotes around “the data” after our discussion about boundary work? I want to keep pointing out that we’re choosing to call it “data,” that the notion of what’s “data” and what isn’t is also a social construct.)

• The heavy use of emoticons for social lubrication during points of clarification that could potentially lead to tiny bits of tension, even if we know each other well. Example: 17:04 in the transcript.
• Simultaneous conversation threads during the conversation in IRC, sometimes delineated by naming your conversation’s recipient before saying a phrase during times the intended destination of the phrase can be ambiguous (see the bottom of page 14 of the first journal entry for a brief discussion).
• Simultaneous “conversation threads” during in-person data analysis amongst my research group in class. In the “buddy boundary work” post, I discussed how “while Patricia and I were engrossed in face-to-face conversation, Joi dove into the etherpad and started making notes… we periodically jumped back and forth between in-person dialogue and taking notes in the etherpad as our own fancy struck us.”
• The generation of the document (a photo of Sumana’s usual workspace, which is also her living room), which is done “in the background” during the end of our IRC conversation, around 17:38 on page 13 of the first journal.)
• The interweaving of multiple attention-threads that show up in the “observation,” which is Sumana’s etherpad writing while she’s sitting in Berlin. She’s writing a document, but she’s also pausing to talk with people who walk by her in the hotel lobby… but she’s also poking back into the chatroom of the document and noting, to anyone who may be watching online, that she is having (or has just had) waved to someone walking by in-person. (Biella Coleman’s paper, “Hacking In-Person: The Ritual Character of Conferences and the Distillation of a Life-World,”  has a great and far more thorough depiction of this sort of virtual/physical duality during a hacker event similar to the one Sumana was at during the time of the “observation.”)

Now to a discussion of the theme. First, working online, we don’t have physical cues to communicate with, so we devise virtual cues that serve many of the same functions. For instance, Joi asked about the purpose of writing in parentheses (which you can see here, as well as in 16:49 on page 5 of the first journal.) In this context, parentheses serve as “asides” — the same function that cupping one’s hand to one’s mouth, leaning over, and saying something sotto voce would serve in an in-person conversation. She also noted the “representation of physical movement through writing” (such as  “mchua nods”) and wondered whether it was “important to portray a visual representation even in online communication.”

I don’t think so, or at least I wouldn’t phrase it that way. The intent is not to replace or duplicate physical cues, but to create a shared sense of presence. Physical presence is something we all have experience with, and we are sitting in a physical location even when we “are” online, so physicality is something we’ll frequently analogize or refer to or seemingly simulate because it builds a common understanding amongst us of what’s going on. This is the “physicality” part of “improvising multitasked physicality.”

Now the “multitasking” part. The absence of physicality leads to different options for multitasking than are present in the physical world. Text chat is often simultaneous broadcast, which is very much like playing in a jazz ensemble. You’re playing, but you’re also simultaneously listening to and reacting to others. You seldom wait in a strict turn-taking procedure; you’re frequently queuing up a response, typing what you want to say, while the other person spews their own text onto the screen. We almost need to do this, or it would take forever to communicate; most people talk far faster than they type, so online text conversations have adapted to become even more synchronous than realtime audio speech. In the digital world that FOSS culture often inhabits, politeness is not exhibited by waiting for your turn to speak or act; your waiting is invisible. Instead, politeness is not letting somebody else block on a response they need from you. They don’t care what else you’re doing so long as they get what they need at the time they need it.

Finally, the “improvising” part: in order to be polite according to this definition of “not blocking others,” madcap improvisation often takes place. I mentioned in the code description that “with unplanned online interactions, being with someone else is an opportunity to be seized.” Once you slip into the online world of FOSS, no matter where you “are” at any given moment, you’re always looking for ways to get what you need right that moment, and ways to give others what they need right that moment.

Let’s bring this all together with an example that might seem counterintuitive at first, and we’ll start it with a question: if politeness in the FOSS world is about not blocking others in the immediate present, why is there such an emphasis on leaving traces behind? For this, I’d like to go back to the interview data at 17:10 on page 8 of the first journal. You don’t have to go back and look there directly, though — the basic thing we are are seeing is a use of links as optional side-routes to follow either in parallel (during the conversation itself) or at some later point in time. Here is my blow-by-blow:

Thursday, June 7th, 2012 | engineering edu, teaching open source | 1 Comment »

Meta Be Bold: the theme of buddy boundary work

Now we start getting into the themes of the Meta Be Bold project. I am trying to show both my final product and a look “under the hood” at the process of obtaining them — something that gives a new meaning to the FOSS maxim “show me the code,” which usually refers to the display of (programming) source code but refers here to a process used in the social sciences (see the coding scheme post for more explanation). Here are the first two codes we’ll look at, along with some samples of material marked with them, followed by a discussion of the theme that intertwines them.

Co-creation (code): Sections illustrative of the relationship between myself (Mel) and Sumana, especially ones that show the manner in which we co-created the process of and the meaning in this mini-project.

Here’s an example of data that got marked with this code: a snippet from the interview transcript showing some co-creation initiated from my direction.

17:16 < mchua> (mind if I tell you what I have in mind for the rest of the
process, and then you can tweak it to be as useful to Sumana-keynote-generation
as possible?)
17:16 < sumanah> OK!
17:17 < christiek> yay

Another portion that got marked with this code: action initiated from Sumana’s. Both samples here show a back-and-forth exchange.

17:22 < sumanah> I can just start a git project on my own and then let you clone
it, actually
17:22 < sumanah> ah, true
17:22 < mchua> but if you’re gonna be on a plane then git makes sense
17:22 < sumanah> yeah
17:23 < mchua> your call; this is your keynote first, my research project Nth
17:23 < sumanah> I shall do git

Also falling under this code, in part are the nature of the interactions with my research group, the traces of which are visible in the etherpad document we worked in.

Boundaries (code): What’s data, what’s “administrative” talk? Who’s a participant, who’s a researcher? Places where the “usual” research lines grow fuzzy. This code could just as well be called “deconstructionism” or “poststructuralism.”

The last example for the “co-creation” code is also marked with the “boundaries” code because the action happening could be construed in various ways depending on where you draw the boundaries. Sumana and I are clearly negotiating the procedures of the study here.

The etherpad also stands as a living example of this code writ large. My research group for class (Joi-Lynn Mondisa, Patricia Gettings, and Soumitro Sen) jumped directly into the “data” etherpad, becoming part of the conversations and participants in the project itself. It was interesting to watch how quickly people picked up on the self-directed culture of FOSS we’d been trying to make allowances for throughout the whole project; while Patricia and I were engrossed in face-to-face conversation, Joi dove into the etherpad and started making notes around line 112 (where it says “Definitely evidence of a co-created “product” between Mel and Sumana in their exchanges.”) I soon caught on that she was writing there, and we periodically jumped back and forth between in-person dialogue and taking notes in the etherpad as our own fancy struck us.

Buddy boundary work is the theme that intertwines between the two codes, which ended up being not particularly separable. That inseparability is, by the way, a good indication that I’d need to rework my codes if I were to proceed with a second pass at this study. I’m learning the limitations of my first draft of codes, the same way programmers learn the limits of their first technical prototypes by throwing things up against the wall to see what sticks.

Buddy boundary work, so far, refers to a couple of things:

First, we’re working in a world where titles and roles are de-emphasized and rather arbitrary: what matters is what you do. Is Sumana a researcher or a participant, or both? How about my research group? It’s hard to affix the label “researcher” to one and “participant” to another, isn’t it? My conclusion is that role labels in the world of this little project (which we’ve deliberately constructed to be very FOSS-style in culture) do not constrain activity; you are, in any given moment, whatever you decide to participate  in for that moment. Research is what researchers do; therefore, if you’re doing “research,” then you’re a “researcher.” This speaks both to the flat hierarchy and the notion of collaboration-among-equals (“buddy”) and the constant dance of negotiating and renegotiating roles in that collaboration (“boundary work”).

Because the question of “what (fixed) role does this person play in this project?” is a non-question in this project, the labels for activities themselves also start shifting around. For instance, when my research group jumps into the etherpad, are we analyzing data or creating it? When Sumana and I negotiate document generation during what I called the “interview,” is that conversation data, or the administrative work necessary before collecting the data? The answer I’d give to both questions is “yes,” because the question of “what is it?” is not the primary thing that matters here.  We’re seeing the futility of trying to cleanly separate and divide this sort of activity into discrete buckets; there isn’t a perfect platonic schemata waiting out there. Rather, we all take what we’re given, what we make, and what we give each other (“buddy”) and use it in ways that make sense to us in our chosen context at a given moment (“boundary work”).

My first research journal itself is actually a great example of buddy-boundary-work as well. Why did I call the IRC conversation an “interview” instead of an “observation” (which I well could have)? Why did I call the etherpad document an “observation” instaead of a “document”? Why did I call the IRC conversation, the etherpad document, and the picture “data” and the rest “memos”? Pure and simple: I needed to turn in a homework assignment that required me to have an interview, an observation, and a document, and one memo for each, so I found things that would make-do in each of those boxes, and I turned them in. That’s all. I could have shuffled them around another way. Other people could use this material some other way: this blog post, for instance, is my “analysis” but might turn into someone else’s “data.”

This last one isn’t very well substantiated by the data, but is a hunch I find hints of and would chase down if I were to take this project farther: there is a sort of simultaneous grand dreaming with self-deprecating humility that I suspect is typical of FOSS community leaders (and perhaps a certain type of leaders in general). We are both dirt and stardust, ashes and sunlight. This sort of mindset gives us permission to play by giving us a mentality of abundance rather than scarcity: if you think of something, why not try it? What’s the worst that could happen, what’s the best that could be? We constantly work and rework roles because we are equals among equals (“buddy”) and can do it, and because those roles simultaneously do-not-matter and are vital (“boundary work”).

So, sunlight-and-ashes: stop thinking so hard at trying to categorize things from the beginning; go with the flow. This ties into our next theme, which talks about improvisation… we’ll get there in a moment.

Thursday, June 7th, 2012 | engineering edu, teaching open source | 1 Comment »

Meta Be Bold: A tiny, tiny coding scheme’s first draft

I find a lovely irony in frequently referring to Wikipedia articles to give background context to “both groups” (academia and FOSS) that this mini-project bridges, since Sumana works for the Wikimedia foundation.

Let’s look at “coding.” Coding is an interesting word. In the FOSS world, it refers to generating (or fixing) lines of Python or C or PHP or some other technical language-du-jour. In the qualitative research portion of the academic world, it refers to the process of tagging materials (such as fieldnotes or interview transcripts) with common occurrences or themes you’re finding in the data.

Another way to explain it: what qualitative researchers call “codes,” most FOSS people and non-FOSS internet users would call “tags.” In both worlds, “coding” (whichever variant you’re using) is a tool for analysis, for helping you make more sense of the world by working around the limitations of the human brain’s limited capacity to analytically examine large amounts of information all at once — the limits of our mental RAM, as it were.

Here is an initial list of codes for this project. We’ll look at themes emerging from and intertwining with these codes over the next few posts.

1. Co-creation: Sections illustrative of the relationship between myself (Mel) and Sumana, especially ones that show the manner in which we co-created the process of and the meaning in this mini-project.
2. Boundaries: What’s data, what’s “administrative” talk? Who’s a participant, who’s a researcher? Places where the “usual” research lines grow fuzzy. This code could just as well be called “deconstructionism” or “poststructuralism.”
3. Performance: Sections illustrative of the signalling of roles (for instance, through the use of lingo) and/or the effects of constantly working and speaking in a public space as opposed to a private one.
4. Physicality: Sections illustrative of the impact of distributedness and/or co-location on interactions, including the simulation of physical presence in order to compensate for its absence.
5. Parallels: Originally a subset of Physicality called (the equally non-descriptive) “links and attention,” this code refers to the multithreaded nature of attention that online interaction affords, and appears largely in the use of hyperlinks throughout the various documents.
6. Nowness: This code refers to a sense of immediacy and a high consciousness of temporality, likely caused by the knowledge that, with unplanned online interactions, being with someone else is an opportunity to be seized. The prevalence of improvisation falls partly under this code, but is also related to the co-creation code.
7. Effect: Sections illustrative of the impact of this mini-project on any of the individual people who’ve touched or been touched by it. (This code ended up being applied to Sumana a lot, but we’ve also done interesting things to the brains of my small in-class research group.)

Thursday, June 7th, 2012 | engineering edu, teaching open source | 3 Comments »

Meta Be Bold – the first research journal

Sumana Harihareswara let me document her awesomeness (the creation of a keynote for Open Source Bridge) for a mini-research project for a qualitative methods class. The keynote is titled “Be Bold,” hence this mini-research project’s name: “Meta Be Bold.”

This document is my first research journal (1 out of 2) and contains raw data (with Sumana’s consent) along with brief informal memos on that data. You can also view the etherpad document mentioned in the journal directly online — it now includes comments from my research group from class (as of this writing on June 6, 2012) which are not annotated and may not be coherent. Still, if you’re curious what graduate school looks like behind the scenes, it might be interesting to poke around. Feel free to ask questions in the comments; I’ll answer them all.

It’s not meant to be polished, there are plenty of holes and gaps, etc; this was done for a summer class, so I only had a few days during which to do the work. Also, this was a research methods class, so the point was to get through the exercise of collecting and analyzing data, not to linger and do it perfectly.  I’m still struggling with the tension between the FOSS culture of release-early-release-often and the high degree of polish most academic writing is expected to have, and you’ll likely hear that in my writing.

All right. Enough prefaces and disclaimers. Here you go.

Meta Be Bold – research journal 1

Over the next 10 hours, I’ll be doing a lot of cleanup and more posts on this blog; the aggregation of those posts will then serve as my second research journal (due tomorrow morning, so I’ve got to hustle). I will endeavour to do a wrap-up posting at the end that will serve as a guide and index to everything, so if you’re pressed for time but interested in this, wait ’till the final post, which should come before 9am EST on Thursday, June 7, 2012.

Wednesday, June 6th, 2012 | engineering edu, teaching open source | 2 Comments »