In this paper, the authors conduct an in depth analysis of the Wikipedia editing process. They differentiate between two types of coordination: explicit coordination and implicit coordination. More editors did not always lead to an increased quality in the articles. Implicit coordination that was focused was useful with a lot of editors, but explicit coordination through “direct” communication was proven not to be.
The validity of the quality of Wikipedia was really convenient for their use case. However, it would have been insightful if they mimicked their study in a different context to further validate their findings. Workers using their time redundantly and ineffectively is an important result that can lead to people finding a better way to delegate time and energy. Explicit coordination in an online context is tricky to define and use. Google docs has a small level of this by allowing users to see the cursors of other collaborators and when they are online. Meanwhile, the “track changes” features allows users to take advantage of implicit coordination in an asynchronous fashion. Understanding how to manipulate and create these coordination types in other contexts could be really useful in further analyzing these two types of coordination.
This study reminds me of the parallel computing subfield. If the workload is imbalanced or there are too many threads used, the computation process can actually be slower than a serial process or using a program with less threads. We have a relatively small class, so the groups are most likely efficient and not wasting resources with too many people on the same project. However, perhaps delegating people to different tasks (“articles” if we are continuing the analogy) can help maximize the group’s potential and final outcome. This can be extremely tricky to understand in a creative process. While the Wikipedia articles are “creative” in a sense, they are more constructive, attempting to define and articulate existing knowledge. I believe all projects are unique as they have their own resources, number of people, and goals. The biggest takeaway from this article should not be to parse a number or range in which too many people is too many. Rather, the purpose should be to understand the essence of how people overloaded on a problem can lead to inefficiency. A more grandeur and future work task would be to create a system that attempts to understand the system and then calculate the best number of people that should be working on the problem or creative process. Overall, this was a thought-provoking read with much to learn from.