User:Bradyamcevoy/Report

Introduction
In this paper I will reflect on my experience as a Wikipedia editor, focusing closely on the process by which stub articles are found and worked on. I will then use theory and principles developed from the research of online communities, along with my personal experience, to offer actionable advice and insight into how Wikipedia could increase both access to, and motivation to complete, the millions of stub articles that exist on the platform.

Background
According to Wikipedia, 36.9% of all articles are categorized as stubs. This amounts to 2,285,658 articles total. Naturally there are ways to filter this massive pool of articles further but it takes awhile to reach a manageable point. When choosing my stub article to update, I reached this point when I looked at the music section of stubs, made my way to hip-hop, and settled on “2010’s rap albums”. The list still contained 100 plus stub articles but with a number of albums being relatively familiar to me, I finally settled on updating the  page for “56 Nights”, a lesser known mixtape from rapper Future. It was a pretty standard stub: didn’t have very many sources (nor any of substance), the writing wasn’t polished and had a few grammatical errors, some of the information about the mixtapes background felt irrelevant and there were missing sections that would solidify an encyclopedic entry for an album.

I rewrote the lead section, trying to be more in line with the standards of a Wikipedia album page. Though shaky, I built off the sources of the original article and found more substantial interviews with the producer, chart data from reputable sources as well as critical acclaim for the mixtape. Using this I was able to rewrite the background section, something that is important for any album article but was particularly relevant for “56 Nights” due to the unique nature of how the mixtape came about. Finally, I added a “critical reception” section to the article which the original stub did not have. I thought this section was important because it rounded out how the mixtape was received by the world and how it impacted the contributing artist’s careers. This was all about as straightforward as it sounds. Once I found the article I wanted to improve, the Wikipedia platform (even source editing, which looked intimidating) was generally easy to figure out and I ended up with a final product that I was really proud of. The issue I had with my experience and where I now want to apply theory and research is the process of finding the stub in the first place. This is an area I think the platform could absolutely improve, primarily by using its community structures in new ways to increase user motivation for finding and completing stub articles.

Suggestion #1
My first suggestion is based on theory and design claims from the book “Building Successful Online Communities” by Paul Resnik and Robert Kraut. When discussing how to increase productivity within an online community, they make the claim that “providing easy-to-use tools for finding and tracking work that needs to be done increases the amount that gets done” (Kraut, Resnick, & Kiesler, 2011. p. 42). This is something I thought about a lot when searching for a stub to work on. While there are massive lists of every stub on Wikipedia and they are thoroughly categorized, there is a lack of depth to this categorization. In addition to being able to filter stubs by topic, editors would benefit greatly from being able to filter them based on their closeness to completion. This blends well with another claim from Kraut and Resnick, who state that “making the list of needed contributions easily visible increases the likelihood that the community will provide them” (Kraut, Resnick, & Kiesler, 2011. p. 41). Returning to my experience searching for a stub, I wish I had been able to look at the list of 2010’s rap albums whose articles needed work, but could tell exactly which were very close to being finished (maybe they only needed light polishing or a single added section), and which could benefit from a lot of work (such as needing a full track list, background, and improved lead). Having information like this easily visible could have enabled me to work on multiple articles either simultaneously, or take the time to fully complete a single article that would require a lot of effort. While it is simple enough to click through 10-30 stubs and choose one to work on based on your knowledge/ available time, this process could absolutely be streamlined, which brings me to my next suggestion.

Suggestion #2
Wikipedia faces a somewhat unique dilemma regarding how it should stimulate an entirely volunteer editor workforce. Kraut and Resnick tell us that often, requests for contribution in online communities should remain simple because over-explanation of a task's motivators may discourage the casual user who is not interested in evoking deep processing (Kraut, Resnick, & Kiesler, 2011. p. 46). However, in the case of Wikipedia, the contribution we are looking for ideally would be stimulated by deep processing. So, if too much explanation scares users away, and Wikipedia needs to do a better job of encouraging work on stub pages, yet editors should be properly motivated to do this work, what is a solution? I think the answer is subdivision. Wikipedia should promote and encourage editors to form subcommunities that center on a single category of stubs, say 2010’s rap album stubs. Each community has a dedicated administrator, a private talk page/ sandbox, and access to a feed showing recently worked on articles, specific major contributions and from who, and most importantly: requests for help or contribution. Kraut and Resnick make the claim that compared to broadcasting necessary contribution requests to the entire community, when a specific few members are targeted, the likelihood of the work being done increases dramatically (Kraut, Resnick, & Kiesler, 2011. p. 43). Applying this principle to Wikipedia, being able to direct tasks to a dedicated subcommunity of editors would likely increase the number of completed stub articles, probably far more than when a casual editor has to choose articles one by one out of a seemingly endless list.

Conclusion
The number of stubs that exist on Wikipedia is, in my mind and I’m sure others, its largest area for improvement. By creating systems that better funnel work to motivated editors, and spaces where Wikipedia’s excellent collaborative tools can be more specifically utilized, I think the platform could begin to dig into what is currently its weakest facet.