It was a simple assignment, theoretically.
I’m currently taking an Education class on new technologies and their potential use in classroom. This past week, we were broken up into groups of five and tasked with working on a wiki. The final product of the wiki was supposed to be a 500-word editorial about the downsides of certain Web 2.0 tech (in our case, it was Twitter). Our professor only gave us one condition: You cannot divide the work into different sections and assign it to different people.
The purpose of this assignment, as I understood it, was to confront us with the benefits and challenges of using wikis. Many magazines and news publications write breathlessly of the promise that these types of emerging technologies hold, but once you try using these things in the real world, it usually results in a cold, hard, splash of reality to the face. If this was indeed the purpose of the assignment, then mission accomplished.
Before I proceed, let me just say that I have nothing but the deepest and utmost respect for all of the members who worked in my group with me. They are each incredibly intelligent and considerate, and nothing that this post says should in any way be taken as a slight against any of them. In short, they are awesome! Rather, my area of interest is in how assigning a wiki to a group of students is inherently maddening, frustrating, and therefore, genius.
There’s a lot of appeal to using a wiki. Allowing everyone to contribute theoretically generates a better product than any one person could create by herself. The asynchronous nature of a wiki also permits people to work on it at several different times. But as one starts using a wiki, especially in the context of a class assignment, its limitations quickly become apparent.
Formatting – It is quite easy for people to disagree over what format the final product should take, and what structure the article should be in. Moreover, group members can disagree over the appropriate approach to the assignment itself. Typically, when group projects stretch out over the course of months and involve weekly meetings, these details tend to resolve themselves. But for an assignment such as this, where the primary interactions took place over e-mail or within the wiki itself over the course of one week, there was simply not enough time for these issues to be worked out. Thus, often disagreements and conflicts remained unresolved, or were resolved by whoever happened to have edited the wiki last.
The Pareto Principle – We’ve learned, time and time again, that most sites that rely on some utopian vision of crowdsourcing rarely end up succeeding in the way they’d originally imagined. On Wikipedia, we’ve seen that 74% of all edits are made by only 2% of the users. Or check out the social bookmarking site Digg, where a few years ago, the top 100 community members were responsible for over 40% of the stories that made the front page.
It’s a fact of life: Whenever you get a bunch of people together in one place and assign them to do a task, some people are going to do more work than others. This can happen for a myriad of reasons, many of them legitimate: Some people may have more expertise than others in the specific topic. Some people may not have time enough time to contribute due to external factors. Some people just might not enjoy the process of contributing. An assignment like this lends itself to seeing this principle in action.
As I reflect on the possibilities of how things could have gone, I can conjure up a number of ways the assigned editorial could be constructed. Here are a few potential workflows:
1) The work could be divided evenly into different sections. This option was forbidden by the constraints of the assignment.
2) One person could write out most of the editorial and lay the groundwork, while the others could all chip in and refine the initial person’s work.
3) The article could be constructed very piecemeal, where each person contributes a sentence or a paragraph to build the final product.
Option 1 was forbidden, and I’d argue that options #2 and #3 both have pretty significant flaws. For Option #2, you have one person clearly doing more work than the others (This is particularly salient, given that on some level we were evaluated for our contributions as part of our grade), while for Option #3, you end up producing a piece that might not be as coherent or unified as you might otherwise have. I would argue that these difficulties, while they do exist, are not as pronounced in a setting such as Wikipedia, where articles are constructed over the course of years, and not seven days. In any case, given the relatively few options to create the final product, this assignment almost inherently leads to a suboptimal outcome.
No Regard for Expertise – I once went to a leadership conference where as an icebreaker, I was told to stand side-by-side with someone else, but facing in opposite directions (along with everyone else in the room). I was then told to grasp the hand of the person next to me and then, in the span of 30 seconds, touch his hand to my hip as many times as possible. I quickly negotiated a deal with my partner: If he let me rapidly move our hands quickly between our hips, we would achieve the more touches than if we just tried to fight against each other. We won the game handily and learned a valuable object lesson in the process.
One of the most liberating things about Web 2.0 is that it is the great equalizer. Everyone on Twitter and on Wikipedia has a voice, and the same status as the next person. But this obviously has its downsides too; without any respect or regard for expertise, you can end up with a final product that might not reflect the best qualities of your cohort. Oftentimes in reality, you can achieve a superior outcome by letting people just do their thing. I’m sure we’ve all experienced that this happens all the time for any type of school project. When you value the act of contributing itself more than the quality of the contribution, you can end up, again, with a suboptimal outcome.
Typically, when people end up doing more work than others, this results in a few bitter behind-the-back conversations and maybe a smidgen of resentment, but that’s where it ends. This sort of tension is amplified, however, in a wiki assignment for the simple reason that group member contributions are easily trackable. Thus, the professor will always know how much you’ve contributed, a fact that might compel you to contribute more than you otherwise would/should.
The Neverending Story – Wiki assignments are like Will Wright games: They never end. Like that paper that you finished last week but haven’t handed in yet, the final product can always be bettered. But even in that situation, you are ultimately the arbiter of what you end up handing in. In our situation, since nobody is specifically assigned to have the “final cut,” this led to everyone having ownership of the project, which, of course, led to no one having ownership of the project. For us, as I’m sure for many other groups, the final 12 hours of the project saw a flurry of edits on the wiki. Thus, the final product ends up not a result of deliberation and intention, but of the vagaries of the assignment due date.
**
Wikis are ideal for aggregating the expertise of dozens, hundreds, or thousands of people from disparate places, and creating a baseline of their collective knowledge on a specific topic. Applying them to a situation where all the wiki members knew each other and communicated regularly seemed like an interesting gambit.
In the end, I’m truly grateful for the illuminating experience of having worked on a wiki for class. But the time constraints of the project, coupled by the restriction that everyone contributes equally to each section, augmented the artificial elements of an already-artificial situation (i.e. working on wikis in general). In short, it heightened the positive and negative elements (mostly the negative) of working on wikis rather expertly. But it also raises the question: Is it possible to assign the same thing the next time around, without making it quite as maddening to participate in?