Posts that are teaching open source-ish
Shameless plug time. Catherine Devlin, myself, IndyPy, the Boston Python Workshop folks, Indiana LinuxFest, and a few others are getting together next month to host the Indianapolis Python Workshop for women and their friends: A hands-on, genuine beginners’ introduction to computer programming.
It’s from April 13-14 and is a no-cost event. Go to https://openhatch.org/wiki/Indianapolis_Python_Workshop for the full details and to RSVP.
Catherine said it best:
Our goal is to widen and diversify the computer programming community with outreach events that overcome the technical and social barriers that hold too many people back from learning to program. Basic programming skills are so empowering and useful that we think everyone should have them, whether those skills lead to a career, a new hobby, an occasional handy trick, or just a deeper understanding of the computers that surround us. We’ll borrow the curriculum – and some of the teachers! – from the famously successful Boston Python Workshop, which has already brought programming skills to dozens of women and their friends.
Some people have asked what “women and their friends” means. It’s simple; all women are welcome, and men are welcome as guests of women who are attending (you can calculate the gender ratio; see this talk by Jessica and Asheesh for the rationale). If you already know Python, we’d love to have you come and help teach; we’re located right in the middle of Indiana LinuxFest in downtown Indianapolis
I believe past workshops have included librarians, teachers, and non-engineering members of software and technical companies who wondered what their co-workers were doing all day; we’re also hoping some local high school students will join us. Please spread the word to people in the area you think would like to know about this event; we’d particularly love to reach groups of women who might be curious about programming but may not have had opportunities to play with it in the past. It should be a blast!
Thursday, March 29th, 2012 | engineering edu, fedora, olin, sugar, teaching open source | No Comments »
A few gems from Havoc Pennington’s post about open projects. (It’s stuffed with gems. Worth reading all of it to find more.) Highlighting the bits I think may be most useful to students of TOS professors.
First is why you need to think of your FOSS community as something closer to… say, a frat or co-op (probably more like a co-op) as opposed to, say, your department (which is more likely to look like a top-down centralized organization to you).
An open project and its community are the sum of individual people doing what they care about. It’s flat-out wrong to think that any healthy open project is a pool of developers who can be assigned priorities that “make sense” globally. There’s no product manager. The community priorities are simply the union of all community-member priorities.
Then: conflict and the ensuing “mess” is a sign of healthy normalcy. Of course you will want to resolve it, and grow in the process – but conflict avoidance itself is unhealthy. It’s like something a friend once told me about dating: “If you haven’t fought, you’re not in a relationship.” To work closely with people creates friction; it is in moving through that friction that we learn to be a team. See “forming, storming, norming, performing” for more.
As the community grows and new contributors appear, there will be growing pains figuring out how to work together. All projects that get big have to sort out these issues. There will be drama; it’s best taken as evidence that people are passionate.
And for the students who asked me “why I worked on open source and not for a company” (to which I replied “I work on open source for companies”):
My experience is that most “heavy lifting” and perhaps the bulk of the work overall in big open projects tends to come from commercial interests; partly people using the technology who send in patches, partly companies that do support or consulting around the technology, and partly companies that have some strategic need for the technology (for example Intel needs Linux to run on its hardware). There’s generally a fair bit of research activity, student activity, and hobbyist activity as well, but commercial activity is a big part of what gets done. However, the commercial activity tends to be from a variety of commercial entities, not from just one.
And this is why I’ve found FOSS participation to be an excellent career-growth strategy, especially for the first few jobs. When you work on a project, you’re working alongside folks from multiple corporations, and they can evaluate you as a potential colleague (and you them). When you graduate and have your FOSS porfolio, multiple people from multiple companies can point to your portfolio and say to the hiring manager, “hey boss, I helped make that too.” Validation by existing valuable employee. It’s easier to hire a coworker you already have.
Tuesday, March 27th, 2012 | fedora, teaching open source | No Comments »
Because I need to write them up anyway for class, here are the current learning goals for my workshop on academic blogging — read these in the format of “after the workshop, participants will be able to…” — and as always, comments welcome. Thanks to everyone who wrote back to express interest and sign up! I will reply to you all as soon as I get my 2nd paper in tonight!
1. Analyze and evaluate the online scholarly presence of others.
I want you to be able to find, listen to, and take inspiration from messy realtime online conversations on a topic you’re trying to learn about.
This is both an “analyze” (break into parts and detect how the parts relate to each other and an overall structure or purpose) and “evaluate” (make judgements based on criteria and standards) goal based on Anderson & Krathwohl’s 2001 update of Bloom’s Taxonomy. You will be able to critically assess the quality and usefulness (to you and to others) of someone else’s online scholarly presence because you will be able to deconstruct that presence into multiple elements, determine how that person’s scholarly thought flows between them, and choose which one(s) (if any) work best for specific reading purposes.
- This is an enduring and transferable big idea that pushes students out of the classroom to find value elsewhere; if you are not confined to the resources and circles of your own scholarly institution, your world becomes far larger.
- This is a big idea and a core process at the heart of the practice of radically transparent research. In order to contribute to a conversation, we must first be able to consume it; we must be able to survey the ever-changing landscape of the dialogue of others and assess what we think is “good” and what sorts of examples we may want to emulate and become ourselves.
- This is an often-misunderstood topic because of the high degree of irregularity and chaos present in online conversations that usually get abstracted and edited away in the “formal” scholarly conversations we claim to be used to. The truth is that we have informal scholarly conversations all the time; we scribble in our lab journals, debate with our classmates over lunch, go with confusions to our instructors during office hours… and we are, in all likelihood, far more comfortable with those informal conversations than we are with sitting down and writing formal scholarly papers. Nonetheless, the apparent “chaos” and “noise” in online conversations cause some people to dismiss it as “useless chaff” because they don’t know how to rapidly hone in on the parts that will be useful to them at that moment.
- This is a big idea embedded in the activity of daily reading of a self-selected blogroll, which provides an opportunity to exercise the various directed reading skills that enable you to reach this learning objective.
2. Translate their existing daily scholarly activity into public online artifacts.
I want you to have the courage and habit of exposing your daily thinking as it comes out, without polish, in appropriate venues and in a way that facilitates the creation of more polished pieces down the line.
This is an “apply” (carry out a procedure in a given situation) goal based on Anderson & Krathwohl’s 2001 update of Bloom’s Taxonomy. You will be able to recognize when a content-creation situation is one that could be done “in the open,” and go through the process of “opening it up,” which means finding an appropriate venue, checking relevant permissions, uploading the content, adding any needed context, and pointing others to the public conversation.
- This topic is an enduring and transferable one that centers around students making their existing work visible and valuable to others beyond the classroom.
- It is a big idea and a core process at the heart of the practice of becoming a radically transparent researcher; you’re already a researcher, so what we’re adding here is the radical transparency.
- This is a topic that requires a great deal of uncoverage; academic training specifically conditions us to regard the opposite process (“closed by default”) as normal and intuitive, so we will have to specifically examine and deconstruct this conditioning and discuss when and where each behavior is situationally appropriate.
- This is a topic embedded in the activity of “opening up” individual pieces of our own thinking, which often requires the metacognitive skills of sensitivity to and management of one’s own emotions. (Which is a topic we sometimes don’t like to talk about in academia, particulary in STEM disicplines that are supposed to be abstracted from all that… but fear is an emotion, and quite often the thing that blocks us from moving forward, so we’ll have to tackle that to make any progress on this.)
3. Propose collaborations that combine your existing scholarly momentum with that of others you have never met in person
I want you to have the guts to reach out and make direct connections with other people doing the same, even if you may never have met them in “real life.”
This is a “create” (make new things) goal based on Anderson & Krathwohl’s 2001 update of Bloom’s Taxonomy. A “collaboration proposal” may be anything from a reply tweet to an introduction email to a full-out grant co-authorship — all are invitations to engage at some level. In this case, you will be collaging elements of someone else’s online scholarly presence with your own in order to come up with (and possibly support) the proposal you are making, either explicitly (in an actual proposal format) or implicitly (putting out something they can respond to).
- This big idea is one that will endure for the remainder of your scholarly career; as long as you need to collaborate and network with other scholars, it will serve you well. It is also transfereable to non-scholarly and non-career contexts, since you can use the same sorts of techniques to reach out to more people about your hobbies, interests, and even establish closer contact with old friends and family members (think about Facebook; if you’re an avid Facebook user, you’re probably doing this already, and the question is how to transfer those skills in from that context).
- This is also a core process at the heart of being a radically transparent researcher. The reason others are invested in our transformation into a radically transparent researcher is that it becomes easier for them to participate — at any level, including occasional reading or lurking — in our work. For watchers of our research, the increased ability to connect with you is the entire point.
- This topic is frequently misunderstood from two directions: being “too hard” and being “too easy.” It’s tempting to say that reaching out is “just about meeting people,” and that you can “simply introduce yourself and start saying something,” but this ignores an awareness of the factors that make your introductions more likely to be listened to and followed-up on. It’s also tempting to think that launching yourself out there is intimidating and that nobody’s going to pay attention, but in a way, this is“just” about meeting people, and we’ve been doing that all our lives. We’ll need to play with that duality.
- This topic is embedded in several variants on the activity of reaching out and making connections, which is something we all know how to do from early childhood when we first began making friends. It’s just a different context.
Thursday, March 22nd, 2012 | engineering edu, teaching open source | 1 Comment »
I’ve gotten a lot of queries about setting up a web portfolio, etc. lately, so I’ve been hacking on a little workshop series on “web presence for academics.” I’ve turned it into my (CA)Pedagogy project in preparation for a first trial run over Purdue’s 2012 Maymester (May 14-June 8, 2012); if it works it may get folded into the graduate Inquiry class in the fall which is required of all entering students to my department (engineering education).
The workshop will be 4 sessions of 90 minutes each, with up to 2 hours of weekly “homework” assigned after each of the first 3 sessions, though I will scope them so they are minimally completable by most attendees in 1 hour. (I will stick around for an extra hour or two after every session to help those who prefer to get their “homework” done all at once and in person.) There is also pre-work you must do in order to sign up for the workshop, which I estimate will take you 30 minutes to complete. In total, the time commitment is expected be 12.5 hours maximum, 9.5 hours expected, over a 4-week span.
- Session 1 – how do academics use blogging and social media?
- Session 2 – setting up your web presence and making your first post(s)
- Session 3 – using your web presence for citations and networking
- Session 4 – wrap-up
By the end of the workshop, you’ll have a website and a research blog, and you’ll have tapped into the online networks of other academics studying around your topic of interest.
The workshop will be taught in person, but I’m interested in accommodating remotees willing to experiment a bit, either synchronously via attending the in-person sessions remotely, or asynchronously catching up on sessions afterwards; if this sounds like you, please get in touch with me before May 10th, 2012 when you send in your sign-up details.
If you’re interested in participating, email mel at purdue dot edu these 3 things, with a subject line like “Re: your research blogging summer workshop”:
- Name and department
- A 3-sentence summary of your research/study topic(s) or interest(s).
- Links to 5 blogs related to your research/study topic that you find interesting.
You can easily find these by Googling “<topic> blog” – for instance, “sustainable engineering blog” or “middle school teacher blog.” These can be blogs by individuals (academics or not), research groups, departments, organizations, companies — and not every post needs to be about your specific research topic, but the blog’s general theme needs to be about something you find academically interesting. If you’re having trouble finding stuff by searching the web, try http://researchblogging.org/, http://scienceblogs.com/, or the blogs of your professional societies and the things they link to.
Feel free to forward this to others who might be interested – grad students from other departments, faculty, people at other schools. I’ve taught elements of this series at faculty workshops since 2009, so I’m used to the audience — just not the format. I may need to restrict the size/composition of the first group in order to keep things manageable since I’m also working and taking classes at the same time, but I will get everyone who sends the sign-up information in on a second round after the first one’s done, if I end up having to stem the flood in some way.
For those who can’t wait for a preview, my classmate Nikitha is bravely testing out the activities as I come up with them right now, so as I give her (verbal) instructions over the coming weeks I’ll write them into blog posts here as well.
And for those who want to help with the paper I’m supposed to write about the design of all this, any notes you’ve got on why this is interesting to you, or citations pointing to why this is either valuable or difficult for you, would be quite welcome. Some things I’ve already gotten, somewhat paraphrased:
- “I want to get into regular writing as a habit in grad school, and this will give me the accountability I need to get into a rhythm.”
- “I want to expand my research network and connect with projects that I’m interested in, but don’t have a web presence to explain to them what it is that I do.”
- “I keep getting questions from people at conferences about my work and I don’t have a place to refer them to, so I keep answering the same questions over and over.”
- “I want to blog, but I’m afraid I don’t have anything to say.” (I have heard this from everyone ranging from first-year graduate students to senior faculty members considered to be one of the best in their field.)
- “Look at publications on the scholarship of teaching and learning, because they run workshop for practitioners and yours is sort of like that.”
- “Look at curricula aimed at teaching grad students about scholarly communication formats like journal papers and conference posters; this is another format to add to that list.”
Wednesday, March 21st, 2012 | engineering edu, olin, teaching open source | 2 Comments »
Written in response to a 2008 group discussion about how our college (Olin) had become “less risk-taking” over the years. Worth reminding myself about occasionally, and relevant to innovation in education and in open source especially as things that were once new and exciting become established projects and procedures, and as the bright-eyed neophytes who pioneered them become old-timers in their turn.
You don’t wait around for things to become “safe to do” and then gripe that the atmosphere isn’t conducive to risk‐taking, because taking a risk means putting yourself in danger in some way. Experimentation and risk‐taking are two different things ‐ you can experiment without taking risks (is an physics lab experiment really risky?) and you can take risks without experimenting (by this I mean you can do dangerous things that don’t add value/knowledge to anyone’s life; there’s probably a better way to phrase this).
I believe that nobody should feel obligated to take any risks they don’t want to, and that you should know ‐ very clearly ‐ what kind of risks you’re taking on when you get into something (and what kinds of risks may remain unknown). This applies to projects, clubs, classes… and colleges.
The fact that you “can’t” try some things out (more accurately: you can’t try some things out without penalties of varying severity) means that you have the ability to take risks. An alternative way to phrase the “Olin doesn’t encourage risk‐taking” complaints in this thread is to say that “Olin doesn’t make the kind of wild experimentation we want to do less risky and more safe.” What do you want?
Tuesday, March 20th, 2012 | engineering edu, olin, teaching open source | 1 Comment »
Some folks at UNICEF asked me to help them articulate a process for how to make their research projects (usually “is this program we want to do a feasible one?” or “what was the impact of this program we did?” into open content ones. Here’s what I wrote them back.
There are some pretty basic things that a researcher can do to make their work into an open content project. Here are a few.
1. Radical realtime transparency. Release all work in an editable format under a creative commons license as soon as it’s made. I’ll elaborate on each of those points in a bit more detail:
1a. Release all work. This means not just the finished/polished products, but the rough drafts, the incoherent notes, and the random scribblings as well. You can put disclaimers of “these are the rough things” at the top, and you don’t need to do announcements of the release of all your low-level work (except in weekly summaries) but they will let other people dig as far as they could possibly want to go on your activity in the space.
1b. In an editable format. No pdfs — wiki pages, plaintext in a version control repository, something Word (or better yet, .odt) files are marginally acceptable, but force you to become a merging bottleneck; it’s best to get as close as possible to people being able to edit not just the material, but also each other’s edits, themselves.
1c. Under a creative commons license. Use the same license as the final paper. I noticed you chose the CC-BY-SA license, which is good; the key point is to avoid the “noncommercial” and “no derivatives” restrictions, which are the non-open creative commons license variants. Remixability for all purposes is vital.
1d. As soon as it’s made. This means what it sounds like; push it as you do it, not after the fact as “background material” accompanying the finished paper. If you want people to help you along your journey, they need to know as accurately as possible where you are right now.
2. Make work findable. Have a central place where people can easily read the current status of the project in 1 minute or less, and where they can quickly navigate to all the materials you’ve created for it. The specific structure/format isn’t as important as having a clear structure to begin with; pick a schema and stick with it.
3. Make participation as low-barrier as possible. Whenever possible, don’t require logins or account creation. If you must use authentication of some sort, think about what accounts the people you want as collaborators are already likely to have (facebook? twitter/identi.ca? wikipedia? github?) and what platforms they’re already likely to be familiar with (do they know version control? word processing? English?) and in general try to make it possible for someone to go from “stumbled across your project” to “made a contribution” in as few seconds and clicks as possible.
4. Update in a regular rhythm. Weekly is usually good, but for some projects it may make sense to cycle more quickly or slowly. For those who need a rule of thumb, I’ll semi-arbitrarily say that you should have at least 5 updates throughout the life of your project, so a 2-month project might have weekly updates, a 2-week project would have daily updates, a 1-day project might have hourly updates, but a 1-year project might have bimonthly updates (though weekly updates will drive more participation). Pick a schedule, announce it, and stick to it; this is something that should be on the front of your “participation” homepage (from #2, “make work findable”) so that new people coming in know when the “next thing” is coming up that they can jump in on.
5. Reach out in backchannel to bring people to the public space. Email, go to conferences, tweet/dent, blog, sit down at coffee shops, go to marketplaces… go where the people are, and engage with them in their spaces as long as it takes for you to help them feel comfortable coming to yours. Basically, private conversations are necessary, but they’re necessary as a means towards the end of bringing people into a public and collaborative space. It’s like opening a new physical location for something like a bar or a library; you want everyone to end up in your space interacting with each other, so you go out and have individual conversations with them aimed towards getting them there.
Hopefully these are useful as general rules/constructs to follow — glad to help with specific implementation questions as things come up. If the first few projects doing this go well, we can go back over them as case studies and figure out a v.2.0 of the approach based on those experiences, which would be exciting.
One thing I haven’t addressed here (and don’t know the UNICEF practices around) is IRB — since you’re dealing with human subjects, particularly during interviews and site visits/observations, how do you get consent from those people to publish their data (and since so many of the people you work with are children, how do you get consent from their legal guardians as well)? Do you have an internal IRB, or work with IRBs from other institutions? This is much less of a consideration when you’re doing fieldwork only for private/personal knowledge and to inform a project, but if we’re making data public on the internet, that constitutes a form of publishing, and we need to make sure we’re doing the right thing in terms of consent and privacy and making sure people know what that means.
Monday, March 19th, 2012 | engineering edu, olin, teaching open source | 2 Comments »
I’ve been trying to describe my research interests and motivations to a lot of academic folks lately; I’m not particularly satisfied with my ability to articulate things clearly and in an academically-grounded and scholarly-sounding manner yet (it’s easy to do one or the other, but not both!) and so I’m chucking the current version out here. The terminology I’m trying to focus on is “discourse exposure.”
By the way, I had an interesting conversation with Purdue’s IRB just now; I’ll update in a bit…
Engineering is a black box to those outside it – and to some extent, those inside. For those involved in an engineering project, the process of creation involves a rich and delightfully messy discourse, a conversation between teammates and technology, components and constraints. This conversation is situated in a particular context; one cannot learn “engineering conversation” through textbook memorization or reading university brochures any more than one can learn “Italian conversation” through vocabulary memorization or reading tourist guides.
However, for those not already involved in the creative process, that’s the equivalent of what they’re stuck with. The invisibility of “what engineers do” may lead to lower matriculation and transfer rates for undergraduate engineering majors, which leads directly to the graduation of fewer engineers. Furthermore, those who do graduate as engineers have few incentives to encourage or artifacts to support reflection on the nature of their actions and conversations. Rarely do we step back and ask questions such as “Do we unconsciously assume gender roles in our teams?” or “Do we remember that the design we’re praising this week was the one we vehemently
disagreed with last month?”
Open source, hardware, and content communities represent a counterexample to this pattern. By making not just their final outputs but their intermediate revisions, design discussions, technical reviews, and essentially nearly all their conversational and technical artifacts available, freely-licensed, and fully-attributable online, they enable access to legitimate peripheral participation to a higher degree than most engineering projects and classrooms. Many researchers have studied the quality of open source output, the anthropology of open source communities, and the effects of using open source software in classrooms. However, there has been no investigation on the learning that happens in these communities.
What if we could identify the practices of transparent communication in open communities, understand the processes by which these discourse-exposing practices scaffold the learning of novices, and then transfer these practices and processes to undergraduate engineering education? What will happen when engineering educators start allowing ourselves and others to eavesdrop on our “ordinary” conversations, and what are the barriers and benefits to doing so?
The idea of “exposing discourse” in engineering education has implications for issues of access, because non-privileged groups (especially groups already underrepresented in engineering) don’t get exposure to the “language” of engineering before they begin formal studies and are immediately expected to “speak” it fluently. It also touches on the notion of cross-disciplinary work; even within the realm of engineering, engineers from one discipline have little opportunity to “overhear” conversations from another engineering discipline (and thus intuit how to work successfully with those other engineers). Learners with speech/hearing/language disabilities and non-native speakers may also be aided by the capture of transient information in textual or other concrete artifact formats. Finally, there is potential for dialogue on open access and the culture of academia as it relates to transparency, publishing, and attribution.
Thursday, March 8th, 2012 | engineering edu, teaching open source | No Comments »
I want to come back to Seb’s blog post here because he’s given the best summary of the open source mentality in one paragraph that I’ve seen yet.
“I’m going to try to build a totally great new thing. It’s going to be a lot of work, but it will be worth it because it’s going to be so useful and cool. Gosh, it would be helpful if other people worked on it with me, because this is a lonely pursuit and having others work with me will help me know I’m not chasing after a windmill.
If somebody wants to work on it with me, I’m going to try hard to give them what they need to work on it. But hell, even if somebody tells me they used it and found six problems in it, that’s motivating; that gives me something to strive for. It means I have (or had) a user. Users are awesome; they make my heart swell with pride. Also, bonus, having lots of users means people want to pay me for services or hire me or let me give talks.
But it’s not like I’m trying to keep others out of this game, because there is just so much that I wish we could build and not enough time! Come on! Let’s build the future together!”
I wonder what the academic version of this paragraph looks like. Here’s my attempt…
“I’m going to try to build a totally great new thing. It’s going to be a lot of work, but it will be worth it because it’s going to be so useful and cool. Gosh, it would be awful if other people came and stole my idea, so this is going to be a lonely pursuit and having others work with me will only happen if I really trust them; I already know I’m not chasing after a windmill.
If somebody wants to work on it with me, I’m going to figure out if I can trust them, then work out the arrangements of our secure, long-term commitment, then give them what they need to work on it. And we have to keep this secret – if somebody tells me they used it and found six problems in it, that might keep us from getting published. Users are awesome, but only when we’re ready for them; when they do things we expect, they make our CVs swell with papers. Also, bonus, having lots of papers means people want to give me tenure or let me give talks.
But it’s not like I’m trying to keep others out of this game, I’m just making sure they do it properly and in a way that doesn’t hurt me, because there’s so much to do and not enough time to deal with crap if it comes up! Come on! Let’s build the future together!”
Wednesday, March 7th, 2012 | engineering edu, fedora, teaching open source | 9 Comments »
First: I’m working on a list of FOSS hackers who’ve gone back to school to study FOSS in some way; do you know of any? Please let me know in the comments. They needn’t be coders; designers, documenters, etc. are also totally welcome, as are contributors to open content and hardware projects — for instance, a very active Wikipedian who goes to graduate school to study the collaboration practices of Wikipedia.)
Now then.
Seb Benthall’s post about academic vs open culture reminded me that I’d like to track my fellow FOSS-to-academia migrants somewhere. Seb and myself are members of a fairly short tradition that includes folks like Martin Krafft (Debian developer to CS/Sociology PhD) and Mako Hill (Debian developer and Ubuntu hacker to interdisciplinary PhD student and Berkman Center researcher).
If you think about it, there’s no way the tradition can be anything like short. Undergraduate degrees tend to focus on “study to be able to do” for a broad area rather than a more focused “study of” a particular topic, so I’m mainly looking at grad students and those who’ve gotten their graduate degrees. To enter graduate school, you typically need an undergraduate degree — which means you’re likely at least in your early twenties. That’s how old the Free Software and Open Source movements are themselves.
It’s not that we’re the first generation of grad students to grow up in FOSS culture — that distinction belongs to people now in their mid-thirties to early forties, who were college-aged in the mid-90′s when the FOSS world was ramping up for the firs time. But we’re the first ones to enter grad school at a time when FOSS culture was widespread enough to be considered a legitimate topic of study by open-minded advisors; in a prior day, we might have studied CS, math, education, or any number of things with “proper” topics as our primary research focus, with open source remaining a devoted side hobby mostly separate from our “real academic work.”
It’s a good time and place in history to be. Plenty of opportunities to find and make — and we’re hackers, so we’re used to finding and making our own way through a chaotic world. Perfect.
Tuesday, March 6th, 2012 | engineering edu, fedora, olin, olpc, sugar, teaching open source | 5 Comments »
A Project Puppy update is long overdue: our first public data was released last week after working through privacy/licensing/permission issues, and that journey warrants its own storytelling down the line — but right now I’m exhausted enough that I’m just going to put it out there in all its unexplained messy glory, and profusely thank Jon Stolk for his extraordinary courage in offering to be the first person to go through this. I know I’m putting out something that begs more questions than answers, so… please ask them, because we’d love to answer.
So, that journey of making the data transparent… I’m trying to think about the best way to explain it. I think what I shall do is to try and reverse-engineer it into the clear steps I’m attempting to apply into my own small “radical transparency research” project (more on this as it comes up; I’ve mostly not had time to truly start it). The main purpose of this second experiment, which I will call “Project Kitten” for amusement purposes, is to take more time to experiment with and really clarify and walk through the copyright, publishing, and ethics/IRB concerns of doing radically transparent research.
Here’s the raw crazy idea, which I expect to have all sorts of things wrong with it that I’ll find out by doing.
If there are cultures that operate with radical transparency, and individuals within those cultures consent to (or even request for) a completely open research process… why can’t I, as a researcher, abide by that request? If I…
- Got permission to interview someone and use their anonymized, locked-in-a-vault transcript in full for research (basically, “normal research procedure,” and then
- interviewed them, we’re still in the middle of a normal research procedure. Okay. Let’s keep going.
- Next, I’d assign copyright of the resulting transcript to them, while maintaining “normal research rights” to use the “anon/locked” versions of the data in the stuff I’m working on for publication. This is a bit unorthodox, but outwardly not a huge deal; if the interviewee decides to stop here, we’ve still done things the “normal research way,” it’s just that transcript copyright ownership is actually clear (as opposed to rather fuzzy, which seems to be the case for most research interview transcripts).
- Now, if the interviewee wants to go farther… things start looking weird. As the copyright holder, the interviewee now has the choice to release their interview data under an open license. They can choose to release only a subset of it, they can choose to edit it before release, even to the point of anonymizing it to their satisfaction before putting it out there… it’s their call. (All sorts of questions and alarm bells should be going off now for any researchers who’ve read this far. What if it’s anonymized but someone guesses correctly? How can we be sure that these people really understand what they’re getting into?)
- Okay. Still with me? We now have an unambiguously public fork of the data, complete with paper trail, that can be used by anyone for anything (after the relevant IRB deems it a public/exempt data set): by interviewees for project marketing (ding ding concern bell!), by researchers (original team or not) who can then perform their coding/analysis/etc in public, etc. The latter is what I am hoping for; I want to “open up” the black box of how “engineering education research is done,” to let people listen in on conversations of this type and see what it looks like to think that way. Discourse exposure. Interesting conversations.
- And to throw even more interestingness into the mix: the original research team has the original private version of the data (which may be anywhere from “bitwise identical” or “only vaguely reminiscent” of the public version, and may include things completely excluded from the public dataset). Now. Research group: what can you do with that mix of information?
All sorts of really interesting deep chewy issues here, like how this process affects what people say, questions of coercion, what risk prediction and mitigation looks like in this case, how to make sure the public stuff doesn’t identify the anonymized stuff if an interviewee doesn’t want it to, etc. Fun to consider, interesting to work through, probably a painful set of IRB convos… but I’ve got time, and I am learning to be patient.
I’m talking with my advisor and slowly (very slowly) moving through talking with Purdue’s IRB as well as with other researchers who’ve looked at open communities; this blog post is in part a way for me to have something to point them to when I email them (hi!) This is a naive statement, but it looks to me right now like most of the other researchers who’ve done this have followed standard procedure — anonymized and locked-down data, working how the IRB expects researchers to work. The rationale I sense is “because I didn’t realize there might be a different possibility for this earlier on, and don’t have time to look into it now because I want to finish my thesis,” but I could be wrong — I hope I am wrong, very wrong, and wish to be corrected! But that is the reason I’m hurtling into this process first year, when it’s a side project that does me no harm if it fails.
This post is poorly structured, poorly written, and nowhere near as well-explained as I would like. But: release early, release often. Hopefully someone, someday, can help me turn this into a clearer writeup. But for now, I think this is somewhat expected; we’re exploring unfamiliar terrain, and this sort of terrain is usually shrouded in fog.
Welcome to the fog.
Monday, March 5th, 2012 | engineering edu, teaching open source | 4 Comments »