This semester, I stumbled into a fairly recent tool created by Google. Google Documents allows group members to create a document, much like Microsoft word applications, that can be shared between 200 collaborators and edited by 10 people at any given time (See Figure: Google Doc home). This opens up an interesting opportunity for compiling group work. Although not a social network in the traditional sense, I suggest that Google Docs fits the profile for our topic this week concerning peer production on a much more simplistic level.
Strengths and Weaknesses
This model of peer production was an interesting counter to traditional formats. Because we had to depend on the online document for creating this project, more emphasis was placed on negotiating acceptable contributions, norms for timeliness and quality of information, and constructing positive criticism--all elements of HWPP (Haythornthwaite, 4). It revealed and supported a a couple major strengths and weaknesses presented in the readings.
Online peer production's strength lies in the freedom to contribute based on schedule and expertise of the user. Members can contribute at any time of the day, with any contribution they see fit. Because the availability of the project is increased while the project sections can be broken into smaller increments, barriers to contribution are lowered. Haythornthwaite suggests that "the larger the granules the more is required of each contributor, the smaller the set of agents who wil be willing and able to take a crack at the work" (5). This seems to be true for traditional formats as well. Face-to-face meetings tend to be brutally long, and group members often have nothing to say about a particular point in the project. This leads to disinterest and lack of motivation for contribution. If too much is covered in one setting, group members are burdened by the scope of the project. It does not play into each member's strengths. Timing is also an issue, as it it difficult to schedule meetings that last more than 1 hour at a time.
Because online formats allow users to contribute at their own pace, at any time of the day, members are more likely to contribute quality work. Also, members can focus on areas of the project that play most into their expertise. This increases motivation and endurance for completing the project. When members don't have to take on too much of the project, the entry barriers lower and the project gets done more efficiently. Google Docs allowed each member of my group to participate on their own schedules. Members would leave comments and make edits according to the information they could provide (See Figure: comments made on the Google doc at two different times). This saved time an effort because members did not need to work face-to-face or carve out significant time to work on the project together. Our work was done more efficiently because members contributed when they had the mind and means to participate.
However, this also leads to a particular weakness for online formats of peer production. As stated by Duguid, "With granularity set so low, individual contributions need have no overview of the piece, no awareness of where it begins and ends, and how it gets from one to the other, and no sense of obligation to the overall balance" (14). Because of the trend for making social networks personalized, individual preference and bias gets in the way of developing a quality product. For instance, as our group made edits to the Google Doc, I noticed a strong discord for the flow and voice of the article. There was instances where two of us would be editing the same section, making sentences completely incoherent.
This issue would not happen with traditional offline collaboration. Because the group discusses the information that is needed within the project, there is a much broader understanding of the overall goal. There is balance within the document because each group member shapes and molds ideas together before even putting it to paper. Two conflicting ideas can be worked out and discussed, where with online formats, users can edit or revise without regard. Users also tend to edit sections of the project that play into their specific knowledge base. This leads to the widening of gaps between project points, primarily because communication and understanding is limited.
This suggests some trouble with the idea that "given enough eyeballs, all bugs are shallow," as stated by Duguid as Linus's Law. While this may be true for software issues that prevent or delay contribution, this law of quality does not cover the issue of having "too many cooks in the kitchen." As with Wikipedia, "small changes in one part of the article make unnoticed trouble for other parts" (Duguid, 12). While it's true that the best information likely comes from many sources, it is difficult to manage the way the information is included. Too many contributors make for unsupported edits.
Graham's Law is slightly more efficient in this circumstance: quality that comes when "the good stuff spreads, and the bad gets ignored" (Duguid, 3). This law was pivotal for our Google Docs project. Because we had multiple members adding information on a consistent and periodic basis, there was an ongoing need for filtering (See Figure: View of other member editing at the same time; edits made by two people on the same sentence). Some members wanted to use bullet points while the assignment required well-written sentences. Some members used the document to add notes and links for further research, while others used it to finalize sections of the project. There was fragmented sentences, and complete paragraphs. I found myself continually deleting, revising, and repositioning text throughout the document to unify the overall document. Eventually it came together, but there was consistent discord for the emphasis and goals of the project.
My suggestion for improving this weakness in the online format would be to increase communication between contributors. Google Docs does not allow the chat function within the document as you edit. However, our group felt like we needed to discuss some edits that were being made, so we opened up another window for Google chat while we edited. We were then able to ask questions, play with terms, and share focus (See Figure: chat with group member concerning project).
Conclusion
It seems that peer production would benefit most from a collaboration of the elements above. Group work needs to have the communication that is available from face-to-face encounters, as well as the freedom to work according to busy schedules and knowledge base. Group work would be unlimited in the scope of members, expertise, and goals with the availability and convenience offered through online components. However, without the opportunities to communicate, peer production will be limited.
Posts
