Posts that are olin-ish
I’m tired of people saying things like “oh, people are naturally resistant to change” or “everyone’s afraid of change” or “change is hard,” and treating those statements like Immovable Axioms that One Cannot Change Or Argue Against. They’re not entirely untrue; change is sometimes hard and scary. However, we’re not going to get anywhere if we use that as an excuse for not looking deeper.
It is not change that causes anxiety; it is the feeling that we are without defenses in the presence of what we see as danger… –Kegan & Lahey, Immunity to Change
I love the first part. Seriously, folks; I put on a new t-shirt every day, but that doesn’t cause me to go into paroxysms of fear as I stare at the closet in the morning. I’d be bored to tears if I had to eat the same thing for dinner every night, and think nothing of the sky going dark every evening. I look forward to starting new classes, getting new books, to the births of my new little nephews (welcome to the world, Oobs and Ewan!) We go through tons of changes that we’re not the least bit anxious about. (Okay, maybe my cousins were anxious about their babies being born, but I sure wasn’t.) Point being: not all change causes anxiety.
So what does? That’s the second part of the quote. There are two parts to it that I want to highlight.
It is the feeling that we are without defenses.
The feeling. Not the objective reality (if there is such a thing). If someone believes they are defenseless — if they don’t realize there’s a safety net, if they don’t think others will step in to protect them, if they don’t trust their own abilities to make everything okay — regardless of the situation, they will be afraid, and they will probably resist change.
In the presence of what we see as danger.
Again, subjectivity. If you don’t see something as a danger but someone else does, then of course they’re going to be more anxious than you. This works the other way around too; my parents and boyfriend are a lot more concerned about me walking around strange cities alone at night than I am.
And note that these two things together; if I’m without defenses but am confident that no danger will arrive, I’m not anxious — actually, I feel pretty safe. For instance, I feel fine walking around my apartment barefoot because I know there aren’t sharp things on the floor that could hurt me. And if you’re in the presence of something you think is dangerous, but you have defenses you feel are sufficient, you’re also going to be just fine; I know I would stand no chance against a full-grown tiger, but had no problem watching one pace behind thick glass the last time I went to the zoo.
Implication: to fix anxiety (whether it’s linked to change or not), make the fearful person either (1) feel like they’re well-protected, or (2) believe that what they’re seeing isn’t dangerous.
Sounds simpler than it is; this is still hard work. But it’s a heck of a lot better than going “well, people just don’t like change!” and throwing our hands up and walking away.
Thursday, May 10th, 2012 | olin | 1 Comment »
One of the things I tried out as part of my independent study on open access this semester was the idea of reverse-engineering a publication. This isn’t about hacking code; it’s about hacking copyright. And as it turns out, it doesn’t work.
Here’s the setup: imagine you’re a researcher and you’ve written a great paper that’s published in a prestigious journal. You beam with pride! Life is fantastic. And then you find out about the open access citation advantage, realize your publisher allows archiving of preprints, and think that life is about to get even better.
There’s just one problem. You can’t find your preprint version (the final edited version you send to the publisher, usually a plain Word or LaTeX document). You only have the final copy PDF with all the branding and pretty-print formatting on it – the version that got published in the journal. Somehow, in the frenzy of hard drive clean-up that accompanied your “I am done with this paper forever!” project completion celebration, you… you lost the file.
But wait… the final print version is identical to the text you sent in, right? All the publisher did was add formatting. So if you could just grab the text from the final print version and throw it back into a Word document, that would be identical to the preprint, and you could post that. A preprint is just the end publisher content there without the end publisher formatting. Right?
Wrong. The problem here isn’t technical, it’s legal. I actually took a print pdf and “reverse engineered” it into a LibreOffice document, and it looked fantastic — I did the process by hand, but it would be easily automatable, so the software portion of the problem is trivial. I talked with Donna Ferullo, Purdue’s copyright librarian, and the copyright portion of the problem is, unfortunately, a blocker bug. The crux of it the matter is that we don’t know what value the publisher added before printing. Okay, this probably is “not much other than formatting,” but still… it’s legal grey. So we hit a hard wall on that, but at least we learned something.
I promised to write something up about this since I don’t think the reverse-engineering idea has been broached before, and it’s at least good for others to know that it’s a dead-end — so here it is.
Thursday, May 3rd, 2012 | engineering edu, fedora, olin, teaching open source | 4 Comments »
For folks who’ve been following the radically transparent research adventures of project puppy (and the similarly transparent project kitten), we have… unexpected news.
Project Puppy is, apparently, not human subjects research. We don’t need to go through IRB.
Which is fantastic news (we don’t need to go back to our participants with yet more paperwork), but also somewhat confusing news; it feels like playing Minefield and clicking on a square and having the computer tell you “yay, you didn’t die!” But that only tells you about the square you’re on. Fog is all around you, so you’re not sure whether you can move in any direction without dying; there might be a cliff two feet to the right that you can’t see.
So I asked Robin to send back the following reply, and we’ll see what we get.
Thanks for your decision — this is great news that will help our research group move forward with our work. Since we plan on doing more projects with the radically transparent research technique in the future, would you mind helping us understand why our project is not human subjects research, and whether we are close to the boundaries of any actions that would make it human subjects research? We were told during initial office hour consultations that it ought to be submitted for HSR approval, so we’d like to make sure we understand the rationale so we can make sure we submit future “radically transparent research” projects for review appropriately in the future.
The short term effects of this, however, is that now we can talk openly about Project Puppy. Actually, we can call it by its real name, and show people its data, and explain the research, and… oh, this feels good. So, without further ado: I’m going to stop calling it Project Puppy, and start using the project’s proper name. Changemakers. (That’s what we call it, anyway.)
The short (overly-academic-sounding) version is that we’re doing “preliminary work on change knowledge through a study that investigates what exemplar changemakers understand about how transformation occurs.”
What this actually means is that Linda did long interviews with 8 people who’ve caused substantial changes in engineering education through the course of their careers, asking them to talk about how the heck they did that, and we’re trying to figure out, okay, how do they think? What makes someone able to affect that sort of change? Can we learn how to do it too? And stuff like that.
Now to put Project Kitten through the IRB process (armed with the Changemakers decision) so we can open that up to the world properly as well!
Thursday, May 3rd, 2012 | engineering edu, olin, teaching open source | 1 Comment »
Matt, Sebastian, Jan, Danny, myself, and a growing cast of characters from Berea College are working on (the) Craft of Electronics, a curriculum for “college-level electronics in a craft-first (and theory-sometime-later) format, through learning from, participating in, and contributing to the open hardware movement.” We decided that “we’re going to do it in the open from Day 0. Everything’s going to be open hardware, open source, open content, and done the open source way.”
This morning, Matt wrote an email (largely for Danny, a Berea student who is new to open source — but really for us all as reminders) explaining what “the open source way” meant in this context. It is one of the best “how to get started in this project practicing the open source way” explanations geared towards students I’ve ever seen, so I am simply quoting it below (but you should go read it in full).
The below is from Matt Jadud’s email to the Craft of Electronics mailing list.
1. BE BOLD.
As we discuss and begin development of material, do not be afraid to contribute. Do not continually ask for permission to suggest things, edit things, or throw things out. We will typically work with systems that automatically preserve the complete history of what we are doing, so that we can all be bold in making changes to our own and others’ work. Anything that doesn’t work well can always be reverted — and, hence, no change has even the remotest chance of being “damaging.”
Likewise, you are a full peer in this dialog (as are we all)… My point being: don’t hesitate to join in. It does not matter what you do or do not know; it does matter if you are silent, and that isn’t what we’re looking for. We’re currently just brainstorming and exploring as a lead-up to the summer work, and you should chime in anywhere and everywhere you think is relevant.
2. TOSW
Actually, I’ve just encapsulated most of The Open Source Way: http://opensource.com/open-source-way
- We believe in an open exchange.
- We believe in the power of participation.
- We believe in rapid prototyping.
- We believe in meritocracy.
- We believe in community.
See the link, and that sums things up. I’ll stop blathering. Ah. One other.
3. RELEASE EARLY, RELEASE OFTEN
We’re going to be working in the open on this project. That means we’ll be discussing ideas before they’re “fully baked,” and the intent is that we will generate a better final product by sharing our thinking and work at every stage of development (as opposed to waiting until it is “finished.”) In fact, the explicit acknowledgement of this model is that nothing is every done, it is just due. We won’t be “done” with this course by September, nor will we be “done” with it in December. It will simply be due by September, and we have to deliver it and evaluate it over the coming term. Then, revision happens.
So, we release our work early (even if it is partial), and we release it often (or, continuously, if it is open). Hence, while we may debate things with vigor, and triage ideas like they’re going out of style, we know that whatever we come up with is just another step.
To summarize
These principles are typically different than any coursework you’ve done in the past. Dive in, contribute, and help us make this excellent. Likewise, the openness in this process means that anyone can join in the discussion and contribute. If you have classmates that you think would like to be part of the conversation, they should feel free to join, to whatever level they feel is appropriate.
I think that’s enough for now. When I have infinite time, I’ll turn this into a page on the website. In the meantime, it’s fine here, and we can point to it in the discussion archive for any other people who join us.
The mailing list is already home to some vigorous discussion about materials, learning objectives, and the like. If you’re interested in electronics education and how to transfer thinking about craft and learning techniques from the hacker movement into the formal academic space at the undergraduate level, please come join us – we would love company.
Tuesday, April 3rd, 2012 | engineering edu, olin, teaching open source | 1 Comment »
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 »
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 love the point in the semester when the light at the end of the tunnel becomes visible and you can see exactly what’s remaining to be done and it looks humanly doable. At 59 minutes past midnight today, I finished all my readings and reflections for all my classes for the remainder of the semester. This means that my remaining work for the term is:
- Keep up on German homework that hasn’t yet been assigned (this is easy and typically done before dinner the day it’s assigned)
- Get comments on, and do a final revision of, my already-completely-translated German For Reading Knowledge project (I’m just waiting for the class sessions where we can bring our drafts in for workshopping, and expect my paper to give us all something to do the first few classes while the other students start their project.)
- Write my course design for “A Blogger Is You!” which won’t be too hard since I’m already teaching the material to a classmate, and just need to write up what Nikitha’s learning. Plus if it works, next year’s incoming grad students will all be blogging, which I would love; there are so few engineering education researchers out there that we need to get our thinking and our work as available to people as possible if we want to maximize our impact.
- Write my Programmabilities paper. More accurately, the portion of it that counts as a class assignment is “write the portion of the paper discussing how the existing practices of open source communities afford cognitive apprenticeship.”
- Revamp my webpage to include a research section. I can’t believe Shannon is letting me do this as a final project. This is awesome.
Okay, so maybe “humanly doable” is still a bit of a stretch, considering I’m on the road or hosting a visitor every week between now and the end of the semester (except for one week, I think, which my parents have just asked me to visit during… I may have to say no, though I feel bad about that). And considering that I’ve got as much consulting work as I can handle, and that there are some side projects (learning German? steno? RSI prevention exercises and bodywork and stretches?) that consume… nonzero time, and then there’s the load of keeping up a life: taxes, cooking, laundry, vacuuming. And friendships: calls, dinners, letters, emails, cards. And a long-distance relationship (more calls, letters, emails, cards, and hundreds of text messages a week), and…
Right. I’m making sure I take microbreaks, longer rests, and get a proper vacation lined up for summer term, then.
So, in order to relax a bit… some light fun reading.
- This is brilliant, and someday if I teach a class on C programming, reading through this code and dissecting it should be an assignment: Inception programmed in C.
- A three-part interview with the researcher and filmmaker behind the epidemiology documentary “They go to die.” Talk about nontraditional (and far more powerful) dissertation formats. Inspirational.
- Lang-8, which might be useful if I get into blogging in German on a regular basis.
- Best webpage on learning objectives I’ve seen yet.
- And finally, the hilarious comedy piece, five minute university (“ The idea is that in five minutes you learn what the average college graduate remembers five years after he or she is out of school“) which I’d like to write a longer bit up on sometime, in celebration of my 5-year college graduation mark (which is in a bit over 2 months, and… okay, now I feel old) and as a more serious discussion on what value (if any, though I think there are some important ones) a college education has.
But right now it’s past 1am, so now is not the time; right now is the right time for me to go home and go sleep.
Wednesday, March 7th, 2012 | olin | 1 Comment »
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 »