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