Actually, South Africa is a big place; perhaps there will be more POSSEs there, in which case, we’ll have to call you Classic POSSE SA, or something like that. Mind you, you’ll always be special. But really, I digress. Already.
Take 2.
As you look to involve your students in the world of open source (and, indeed, as you explore it further yourself), use the tools you’ve been introduced to so we can stay in touch. Not so much because those who came before think we have all the answers, but because we’re hoping you can contribute to and improve the explorations we’re making already. And, for that matter, TOS can, we hope, serve as a space where we can support each-other as we try and engage in explorations that encourage our students to reach beyond their comfort zones as they begin exploring the world of decentralized collaboration under the aegis of free and open communities of practice.
During the summer of 2009, I had the good fortune of taking part in the Red Hat POSSE programme, meeting a bunch of excellent open source peeps, and getting a sense for how I might introduce more of my students to the world of open source contribution. This last spring, my colleague and I introduced 40 first-year students to the Fedora project. This semester, I’d like to introduce y’all to a few more.
This semester I will be leading eight intrepid students in an exploration of interface design and development at Allegheny College. Your open source project (or a small part of a larger project) could benefit greatly from these students, if you’re interested.
HOW YOU CAN HELP
I want developers/managers from “projects” that have a GUI. I say “projects” because you might be the lead on, say, a network settings dialog box that is part of Fedora. You need to be of the mindset that your GUI could always be better, but you never seem to have the time to sit down and do heuristic evaluations, sit users and do interaction testing, and so on. If we work with you, you also have to commit to being timely in responding to the students—most likely on your developer mailing lists—because we can’t wait for two weeks to go by in a 14-week semester while we’re waiting to hear back from you. (I’m not talking about 5-minute response times, but if you can’t reply to email from people trying to make your project better within 24-48 hours, please don’t respond.)
Basically, we ask that your community be reasonably responsive, and we’ll be doing all the work.
WHAT WE WILL DO FOR YOU
Small teams of students will, throughout the semester, engage one or more of these projects as budding interface designers. They have no prior experience in this regard, but will be engaging material on lo-fi prototyping, usability, the psychology of interface design, and so on. We will be discussing this material (which we will try and do in as open a manner as possible) and directly applying what we learn to the interfaces that are part of your project.
The students will work within your community, using your tools (mailing lists, wikis, etc.). I do not expect them to implement their designs, although some of them may be capable of doing so, and they might even do it. This, however, will not be a requirement of the course. (Not everyone in the course is capable.) If their work is good, and you like what you see, we only ask that you give their efforts serious consideration for implementation… we’re working with you because we don’t want to be doing interface design and testing in the abstract, but instead we want to add value to real projects through our efforts.
SOUND GOOD TO YOU?
If it does, please drop me an email (mjadud at allegheny dot edu). If you’d like to talk to me on the phone, I’m happy to chat—92JADUDM92 is my Google Voice number, which… well, it’s new to me, so we’ll see what happens.
I’ll have to write a longer post later, but I thought I’d just mention that OSCON is a great conference. Our presentation went well, and we’ve had a lot of great conversations with people about all kinds of things in the open source world.
More later… for now, it’s time to head out the door.
(Related, our parallel programming environment for the Arduino is now available on Ubuntu, Windows, and Mac. Hooray for packaging! And, I need someone to help me work through how to do proper source packages for some of the complexities I’m facing on the Fedora/Ubuntu side. Packaging compilers is not a lot of fun…)
Remember: these are first-year students in a Freshman Seminar who have not declared their course of study. Despite that, they’re diving into IRC, wikis, blogs, mailing lists, and sprints as they rapidly come up to speed on contributing to the Fedora project. I don’t think they have any idea just how big a jump this is for some people. And because they don’t know it’s a big jump, they’re just jumping.
Give em’ some props. (Or, leave the props here, and I’ll pass them on.)
Allegheny College has a Freshman Seminar series where students engage in writing and speaking exercises that explore a subject in the context of the liberal arts. Darren Miller (Art faculty) and I linked our seminars (mine is titled Technology and Activism, his is Art and Activism) so that we would come together as a large group on a regular basis, while breaking apart into smaller sections for discussion and debate on related but different themes.
The role of openness plays a critical role in my course. Every text I required was Creative Commons licensed, and we will be talking about the Commons (as well as notions of openness in software) throughout the course. This is, in part, because contributing work to the Commons is a kind of activism. Further, we wanted to introduce our students to the tools that open communities use to communicate and enact change in the world. The first tool we introduced them to was the weblog.
I was surprised at how few students were familiar with weblogs. Clearly, an assumption on my part that all of my students today have at least five blogs and seventeen Twitter accounts. Who knew? So, there are now 40 new bloggers in the world. (They also learned what an RSS reader is.)
To do this, though, we didn’t use private blogs in Sakai. Instead, I set up a WordPress-mu instance, and created accounts for them. The best part?
I’ll write more later, but I’m leave with the teaser that I’m very excited about our tie-in that we managed with Mel Chua, one of my POSSE wranglers last summer, now member of the RH Community Architecture team. She’ll be visiting later this term, and we’re going to do some Great Awesome with the students. At least, that’s our intent. Forty students will be introduced to the goodness of Fedora, but not in the way that you’d expect…
RedHat has kicked off another POSSE, this one on the other side of a continent and an ocean from where I live. (The faculty have come together in Singapore… I hope my travels take me that way someday!) I’m looking forward to seeing what they have to say, and what their experiences are like. Their blogs are online, and I’ll be doing my best to keep an eye on them over the coming days, weeks, and months ahead.
So, your professor has said those awful, fateful words: “You should have a project blog.” While all the cool kids are tweeting their thoughts, you’ve been shouldered with this ponderous blog; worse, you have no idea what to write in it, or who is going to read it.
Fear not! This quick guide (written primarily for students at Allegheny College who have been encouraged to blog as part of project work in the Department of Computer Science) will give you some context for:
Why blog?
What to blog?
When to blog?
Who will read your blog?
How to blog?
A quick search of the ‘net did not turn up a similar guide for students, so it is my hope that this is a useful resource. If you’re a student getting started blogging and are looking for a few pointers, read on.
Why blog?
Your professor suggested you maintain a blog for all the reasons mentioned in this document, plus a few relating to the fact that your professor is lazy. First off, your professor would like to know what you’re up to, and would most like to see those notes come by in their RSS reader (wiki). Second, your prof wants other people around the world to be able to keep track of the awesome projects you’re working on, and RSS is the little XML file that makes it all possible. You’ll want to use an RSS reader, too, but all in good time. This is a guide to writing blogs, not reading blogs.
Second, your prof wants your work to be visible to the world. This is because your prof is a marketing genius. Using an RSS aggregator (wiki), your professor is going to link your writing in with other students, and tell all his/her friends about what awesome stuff you’re doing.
Now, you can probably infer how this blogging thing is good for you. The most important thing is that your blog provides a way for you to capture your thoughts, link to inspirational/informational resources, and get feedback from others in your community of practice (wiki). It’s like a lab notebook, but you can embed images and video really easily, and other people can help fill in the blanks when you get stuck.
What to blog?
You can write anything you want in your blog, but you should probably think about the fact that Google and the Internet Archive have long memories. Also, someday, a potential employer might read what you have to write.
HOLYCOWWHATDIDTHECRAZYPROFGETMEINTOTHISTIME?!?!
Your blog is your space. You can write about your cats, or other people’s cats, or even repost awesome videos about cats from YouTube. For example, I’m a fan of Keyboard Cat:
You might write about politics, the media, music, food, or any number of other things on your weblog. You should probably sneak the occasional post in about your project, though. With regards to your project, you should write about your brainstorms, your explorations and experiments, any reading that you do, responses to other people’s posts, and successes you have along the way along with mistakes and dead-ends that you explore.
Throughout all of this, don’t be afraid of the hyperlink! When you read something useful, link to it! When you are inspired by someone else’s blog, link to it! This will be valuable to you later (when you go looking back at your own writing), as well as help your reader gain valuable context. Linklinklink!
To help your prof keep track of what you’re writing about any given day, you’ll want to use the tagging feature of your blogging software to make sure that you keep videos of Keyboard Cat in their place. For example, you might tag posts about cats as “lolz”. When you’re brainstorming new ideas, you might tag new ideas as “brainstorms”. When you’re writing about things that tripped you up, that you don’t want other people to discover the hard way, you might tag mistakes as “oops”. And you can give lots of tags to a single post, so one post might end up in several categories. For example, when I write a post about using the Arduino and the Transterpreter, I end up tagging it as “computing,plumbing,opensource,arduino,transterpreter”. Sometimes I mix in other tags… I’m not very consistent, really, but I try.
Ultimately, if your blog is specifically about a project, then keeping it “on message” will probably make the people reading it happier. However, it is your blog, and you should use that space however you see fit.
When to blog?
You should update your blog when you have things to say. If you’ve finished reading a blog post, web page, article, paragraph, chapter, or book that inspired you in some way, capture your thoughts! They might not be refined, but you can say that in your post:
“I just finished reading One Fish, Two Fish, and I realized that Dr. Seuss was totally talking about power management for embedded devices! These ideas are a bit raw, but here we go…”
In short, use your blog to capture thoughts that are in-progress, or perhaps to capture things you’ve been mulling over for some time.
But also remember: your blog is more than text! Capture images, video, and other media about your work whenever you can. Human beings are highly visual creatures, and the more pictures and video you can work in about your work, the better. Drawing diagrams forces you to organize your thoughts… sketch them on paper and scan them in! Or, just snap a picture with your cell phone camera. In short, don’t get hung up on things being perfect—just get the idea out there.
Oh, and remember: if you’re over 21, and you consume beverages of an adult nature, don’t blog when you’re drunk. It’s always a bad idea. Especially in light of the question…
Who will read your blog?
Your prof is going to ask you to designate one of your tags as the tag that gets fed into the aggregator. If you’re blogging a senior comprehensive project, then you might use the tag “comp” for everything that is related to your comp. These posts will get pulled into an aggregator, and potentially be read by your classmates, other faculty at your College, and possibly people around the world.
If your work uses tools that are part of a larger, open community (for example, if it uses the Arduino, or involves working with open source software like the Mozilla Project), then it is possible that people in that community will be following your work. This is a great, great thing! When a community starts paying attention, it means people think what you’re doing is interesting, and they might even begin suggesting new ideas that you had never considered. Never underestimate the power of an engaged community.
Thinking forward, potential employers may find what you’re writing. They might find it after you’re done with your project (perhaps because you included mention of your blog in your resume), or they might find your writing before you’ve even met them! Perhaps, because your work is awesome, they decide that they need to hire you. Mind you, this isn’t exactly common (I’m selling bridges in Brooklyn over on my own weblog if you’re interested), but the fact remains: you’re demonstrating your ability to communicate in a concrete, public way.
How to blog?
Some people (like me) use a native application for blogging. For example, on the Mac I use Ecto. Under Windows, I’ve used w.bloggar in the past. Some people use the web-based interface that comes as part of their blog (eg. the Javascript-based editor in WordPress). At the end of the day, you should choose the tools that work for you, and let you get the text out as easily as possible.
That’s it!
There is either nothing more to say, or everything to say. In the case of the former, I should stop writing, and you should start. In the case of the latter, you should start writing. So, either way, its time to get started. Write what you think, in your own voice, and you’ll be part of creating a more informative, interesting World Wide Web.
Now go!
Last Update
Suggestions for improving this post are always welcome. This post was last updated on July 27, 2009, 17:23 GMT-5.
I’ve managed to do an initial packaging for Fedora of the toolchain that we use for programming the Arduino (see post with cool video). This is a big step—it means I’ve learned something about packaging, and it means we’re closer to being able to provide a really cool educational tool to the Fedora community. There’s still plenty of work to be done, but I consider this pretty exciting.
This is sweet, sweet awesomeness. This is the first time I’ve seen a packaging process for our tools through this way… while I’m not done, getting to the point that rpmlint gives me zero warnings and zero errors on a compiler toolchain is (for me) a milestone. I now need to clean this up fully, write a script to automate it (eg. checkout from SVN, tarball, upload, generate .spec file, rpmbuild, rpmlint), and then modularize that process for the AVR version. So there’s a bit more work to do, but it’s well within striking distance now. ctylers, ianweller, and others have been a great help in this process.
Building Mozilla Minefield took 60 minutes on my Fedora 11 VirtualBox VM. The VM lives on an external USB drive, so given the I/O and everything else, that’s not so bad.
By “not so bad” I mean “that’s rather slow,” but all things considered, it will make working with things this week far easier than running everything remotely on a VM on fedoraproject.org.
One of the things that I clearly am too worried about is how I interact with open source community in a meaningful way and how that is reflected in my evaluation as a member of the faculty.
I am evaluated on the excellence of my teaching and my research. At Allegheny, the former is considered more important, but it all matters. Writing code and contributing to an open community process is not something that is easy to evaluate and, further, not something that my colleagues in Computing even understand well. I can say that with some confidence, because I have learned so much in the short time we’ve been here at POSSE.
Clearly, though, this is one of the conversations I need to have with my colleagues and my Dean when I return to Allegheny. If I want to be in a position to help my students take part in the open source community, I need to serve (I believe) as a knowledgeable guide into the space. That means that I have a working understanding of the practices and cultures that they will be encountering. And the only way that will happen, to some degree, is if I am involved myself.
Perhaps I’m wrong in this—gregdek or another POSSE participant will correct me if I am—but digging in and playing in the sandbox matters. And if I am going to do that, it is going to take time to get involved, and I will want to sustain that activity over the coming 3-5 years at the least. Any project I do on that timeframe, that absorbs a significant amount of my energies, needs to be acknowledged by my institution as having value.
A disclaimer
It is true that I could just contribute. I could continue to teach without integrating open source, and do my research on things completely unrelated. I can strive to be an excellent husband and father, and … stop sleeping and eating. Ultimately, for me to take part in this, I suspect it must count towards my professional development at the College in a meaningful way.
I’ll let you know how/if/when I’m wrong. I probably in, somehow.
