5
Summary
In this paper, the author discuss group work outcome quality on wikipedia through coordination. Two categories of collaboration was defined: explicit coordination, the editors plan the article through communication, versus implicit coordination, which subset of editors structure the work by doing the majority of it. The author’s assumption is that, in coordination intensive tasks, increasing the number of contributors will lower the effectiveness of the group, which is caused by the increased coordination requirements or decreased member motivation, especially for complex tasks or those with strong interdependencies. As for quality analysis, the author utilize wikipedia’s article assessment tool, together with MTurk rating, resulting in high agreement thus validate the results. The first finding is that, articles with many editors are generally better than those with fewer editors, but only with appropriate coordination techniques. The second finding is that, both implicit and explicit coordination have stronger associations with increases in article quality in the early phase of an article’s life cycle. This is when tasks are most interdependent and coordination needs are highest, and this is when the article’s creator(s) need to provide a structure for the article to which others can contribute.
Reflection
I’m interested in two aspects from this paper. The first thing is how they processed implicit and explicit categories. When I first read the paper, I thought they were going to split the raw data into two categories, but what they actually did is using # of article editors and # of talk editors and integrate these two into the analysis process. It is a very interesting use of gini coefficients, which is commonly heard in the field of economics, to operationalize the two kinds of coordinations. Articles with edits concentrated in a few individuals have gini coefficients closer to one. This approach also resulted in some interesting findings, like explicit coordination via discussion has an implicit structural component: planning is done by a small subset of contributors. The second is, the author mentioned that, in other type of online group works, there is a second variable: the type of production task. The example he made is that the top 15 developers contributed 88% of new lines of code to the Apache server project, but only 66% of the bug fixes and 5% of the problem reports. In this case, we can claim that in a software project, having enough number of problem reports will improve the project quality. The more the better, until a certain threshold reached, and then the quality should remain plateau. I think it is safe to make this assumption without proof, but this is when the conclusion made in this paper hard to generalize to all online group working scenarios. As a practical outcome of this research paper, will online communities adapt to this guide line in some way to improve the community outcome quality? In general, I find this paper of high quality and very useful.