This post first appeared on Ethnography Matters

Trust. The word gets bandied about a lot when talking about the Web today. We want people to trust our systems. Companies are supposedly building “trusted computing” and “designing for trust”.

But, as sociologist Coye Cheshire, Professor at the School of Information at UC Berkeley will tell you, trust is a thing that happens between people not things. When we talk about trust in systems, we’re actually often talking about the related concepts of reliability or credibility.

Designing for trustworthiness

Take trustworthiness, for example. Trustworthiness is a characteristic that we infer based on other characteristics. It’s an assessment of a person’s future behaviour and it’s theoretically linked to concepts like perceived competence and motivations. When we think about whom to ask to watch our bags at the airport, for example, we look around and base our decision to trust someone on perceived competence (do they look like they could apprehend someone if someone tried to steal something?) and/or motivation (do they look like they need my bag or the things inside it?)

Although we can’t really design for trust we can design symbols to signal competence or motivation by using things like trust badges or seals that signal what Cheshire calls “trust-warranting” characteristics. We can also expose through design the “symptoms” of trust – by-products of actions that are associated with trust such as high customer satisfaction. But again, by designing trust seals or exposing customer reviews, we’re not actually designing trust into a system. We’re just helping people make decisions about who might behave in their interest in the future.

Reputation: implicit and explicit

Knowing who to trust can be helped along by reputation cues – something that has become increasingly popular as a way to gauge competence on the Web today. There are two ways to build for reputation: implicit mechanisms, where we expose different variables relating to a person’s contribution, for example “number of edits” versus explicit mechanisms where we ask others to rate people based on their experience working with them.

Implicit reputation design is challenging, says Cheshire.

“It means that we’re guessing “likely associates” of particular behaviors or outcomes. For example, in online Q/A forums, we know that showing one’s tenure on the site (“member for 5 years”) and/or number of contributions (“4353 posts”) can imply lots of things. But out of context this could be (either) a 5-year spammer or a 5-year expert who is fairly active.

Explicit reputation systems are often seen as a solution to this challenge since it means that real people are filling in missing context by giving an up/down rating on the person or content. But, this in turn creates a collective action challenge since you need people to take the time and effort to do the ratings – which is why we often want to find a way to use the earlier ‘implicit’ information in the first place!”

Cheshire believes that this problem of finding consistent, reliable correlates of trustworthiness from implicit information really depends on the context of a particular online environment. And this is at the heart of Cheshire’s work: discovering how people assess another person’s future behaviour in different online environments.

Do they rate competence higher than motivation, for example? In an experiment, Cheshire and his colleagues asked participants to choose which goods and services they would buy when faced with a series of differently worded advertisements. To improve the accuracy of the results, they said that participants could invest $5 of the money they were getting to participate in the survey ($10) in choosing the most trustworthy seller.

They found that competence matters more when buying a used good (such as a camera) and that motivation matters for buying services (such as website design) where a longer-term relationship is required.

Designing for interpersonal trust

When it comes to designing for interpersonal trust, three key features are essential, says Cheshire:

1. Repeated interactions between parties over time
2. Acts of risk-taking
3. The presence of uncertainty

In a study to work out different levels of trust between individuals based on levels of uncertainty, Cheshire and his colleagues found that as uncertainty goes up, the potential for trust to develop does too. The paradox of building assurance structures such as those that guarantee risk-free interactions on eBay, for example, is that they decrease uncertainty and thus the potential for interpersonal trust. In other words, designing for “trust” can actually decrease the potential for trust!

Betrayal (when someone says they will do something and then doesn’t follow through) is something often attributed to systems. But again, these are actually issues of credibility, reliability and security because the systems do not betray us, but people who build, maintain, and support them might, says Cheshire. When designing crowdsourced platforms like Ushahidi or Wikipedia, this becomes a really important to distinguish. We need to design the system to be secure and to enable participants to make good decisions about who to trust, but we can’t magically ensure that people will trust one another through that system.

Cross-cultural differences in trust and trusting

Cheshire also found that cross-cultural differences matter when it comes to trust. Looking at the same trust game in the US and Japan, they found that players could choose how much to entrust to their partner, as well as whether to return anything entrusted to them. Individuals were partnered with either the same fixed-partner or a new, random partner on every trial. They found that Americans took more risks and trusted their partners more than did the Japanese– even in the random-partner exchanges. They also found that the opportunity to choose the level of riskinvolved in trusting another helped improve the level of mutual cooperation for both American and Japanese participants.

In new research just completed in Romania and the US, Cheshire found that regional/societal differences do exist and can be rather large but that the experience of building trust can essentially erase the effect of region or disposition to trust. Developing systems that enable trust to be built among people is really essential to his work. In the end, Cheshire is driven by the need to understand how trust can be repaired.

“My interest in trust began over ten years ago when it became very clear to me that assessing trustworthiness and building trust with other human beings are fundamental aspects of human social interaction, community-building, and collective action in all offline and online settings. Going forward, my work is now focused on detailing what happens to interpersonal trust when individuals move from more secure, reliable, and certain interactions to environments that lack such assurances. Ultimately, I want to gather empirical evidence from many different sources to detail how individuals build trust through experience in uncertain environments and, perhaps most of all, repair trust when and if it fails.”

A screenshot from Reddit.com’s sub-Redit, “SnackExchange” showing point system

We want to build a reputation system for our new SwiftRiver product at Ushahidi where members can vote on bits of relevant content related to a particular event. This meant that I was really excited about being able to spend the day yesterday at the start of a fascinating workshop on online reputation organised by a new non-profit organisation called Hypothesis. It seems that Hypothesis is attempting to build a layer on top of the Web that enables users, when encountering new information, to be able to immediately find the best thinking about that information. In the words of Hypothesis founder, Dan Whaley, “The idea is to develop a system that let’s us see quality insights and information” in order to “improve how we make decisions.” So, for example, when visiting the workshop web page, you might be able to see that people like me (if I “counted” on the reputation quality scale) have written something about that workshop or about very specific aspects of the workshop and be able to find out what they (and perhaps even I) think about it.

The organisers write that a reputation will be “a way for the user community to collectively calibrate the contributions of its members”. And if work of the new system will be “annotating” content on the web, then the reputation model will be an important part of that system. It turns out that calibrating contributions is not as easy as developing a scale and then marking a measure on a measuring jug. First you have to work out what the measure is. When is comes to peer production projects, the goal might be an vibrant volunteer community that comes together to produce something of public value. Wikipedia, for example, wants to see a growing volunteer community working together to build and improve a free encyclopedia, especially in areas that the encyclopedia is weak. Ushahidi, on the other hand, might want to see volunteers deploying and organizing around content in order to improve decision making and effective action in crisis situations.

When co-founder and general manager of the tremendously successful Stack Overflow and Reddit talked yesterday about how they developed their reputation systems, I was struck by the organic nature of their reputation model building process. Building reputation systems, it turns out, relies on an effective process more than a fancy algorithm. Successful codified reputation systems like those used by Stackoverflow and Reddit have developed their codes the way doctors grow skin on different parts of the body in order to use on other parts. Organically, along with the community, evolving in a process of increasingly shared responsibilities. Just the right amount of adherence to what the community currently values and how they already distribute rewards and attention, with just the right amount favoring or weighting of activities and values that achieved desired communal goals.

General Manager of Reddit, Erik Martin, spoke about the evolutionary process of the community. Reddit started purely as a link aggregator where users could vote stories up or down. After that came comments, then the ability for users to create their own topics. Then there was the ability for users to write their own posts, and the growth of users building new sites on top of the Reddit platform (there is even a radio station and the “University of Reddit” in this category!). Users have the ability to create “sub-Reddits” on categories that Atwood said “we never would have thought of”. Reddit has a karma system made up of up and down votes but when managers of the site enabled users to roll their own CSS, they saw users of sub-Reddits doing really interesting things to moderate discussions. In one sub-Reddit, moderators verify certain users as experts in specific fields and their comments are then highlighted. Members were able to innovate in this way specifically because of their ability to edit the CSS. Another interesting example is “SnackExchange” where Reddit users share snacks from around the world. When they have successfully exchanged a snack, an image of an AK47 appears next to their name to denote that they have fulfilled the promise to exchange snacks (I can’t wait to join and ask for rusks!).

Jeff Atwood, Co-founder of Stack Overflow talked about the focus on educating newcomers about the culture and practice of asking questions on the site. Stack Overflow is actually just one of many different sites from the company, Stack Exchange. Stack Exchange enables members to lobby for new content-specific sites in a place called ‘Area51’ where you can see the stages of new communities (vote for Libraries and Information Science!). Atwood says that the reputation model they developed weighted answers more heavily than questions (Stack Overflow enables people to ask questions about programming challenges) which hints at how codified reputation systems can work well to encourage particular types of behavior that will serve the overall goals of the community. Questions are easier to ask than to answer, for example, and if there were too many questions and not enough answers, the ecosystem would fail. Moderators are elected and have significant power to edit and remove things on the site. The platform uses both reputation scores and badging systems which Atwood (jokingly?) described as “meaningless rewards for doing things” that make everything you do on Stack Overflow “a lot more fun”. Reading the FAQ has a badge, for example. Filling out your user profile does too.

Atwood said that they’ve learned that moderators need a good mix of badges and reputation score to be good community facilitators and that reputation score can be a bad proxy for leadership qualities with users voting for members in community elections primarily because of their high scores. He also noted that a key principle behind their badge and reputation scoring system was that as you progressed through the site and through different experiences, you always had something interesting happening. He stressed that users are the ones who helped build the system and that they are essential to its functioning, even though they had to be educated about their role in the health of the community. “If you just make someone into Superman, they will start running into buildings… we didn’t teach them how to do good and fight evil (at first).” Orientation and education are really essential to that partnership.

Four principles stood out to me as I listened to Atwood, Martin and other reputation experts talking yesterday that might be useful in developing codified reputation systems.

1. Reputation systems must be tied to governance and community responsibility and control. The organisation needs to trust the system enough to say that growing reputation will equate to growing responsibility for governing and maintaining the system. This is the only way to keep members active and engaged in the long term.
2. The corollary of this is that the codification of the reputation system must be driven by the community. Users are not going to accept a system that doesn’t reflect the way that they use and understand the goals of the system.
3. Reputations systems are not static. They should be about rewarding a person’s work on the project over time, in addition or perhaps parallel to them taking on more leadership roles and administrative privileges.
4. Reputation systems are contextual. I heard this throughout the day with many of the participants talking about how different projects have wholly different ways of rewarding and recognizing different activities. Using one standard is difficult. It may actually be destructive, especially when it serves to surface content using only a particular type of lens.

Listening to the day’s proceedings, I realised that when people talk about Wikipedia not having a reputation system, they’re missing that Wikipedia does have a reputation system. It’s just not codified or transparent (which probably explains a lot of its problems). Every community has ways of determining who should get the most attention and what types of activities should be rewarded. A reputation model that codifies such a system is what we’re actually hearing about when we hear about new “reputation systems”. But by seeing reputation systems and codified reputation systems as the same thing, we start to see a community without a coded system like a person missing a leg. When you think of it this way, the solution is often seen as merely attaching a spare leg (spare legs are stored in multitudes in my imagination) and hoping that it will miraculously attain all the functionality it needs.

As Chris Dellarocas from Boston University said in his talk later in the day, the focus on different aspects of a reputation system rely on an understanding of what one wants to achieve with such a system. Communities might use reputation systems to achieve one (or more) of four goals:

1. Trust: encourage good and discourage bad behavior, and provide incentives for quality contributions
2. Filtering: assisting users in finding quality content
3. Matching: assisting users in finding content and members that are good for them (i.e. you might not find the content you’re looking for with a search but you might find people who might help you to find relevant content, especially when it is subjective area)
4. Participation and loyalty: give users reasons to join and stay in the community

Knowing what your goals are is really important to the design of the system, said Dellarocas. Also important is understanding what motivates users (he divides motivations into the three: love, glory, money – looking forward to that paper!)

By the end of the day, I was left with a very clear sense of how important ethnographic methods could be for a project like this. Being close to the experience of users, tracking and observing what motivates behavior, as well as truly understanding the quirks of certain communities are all the things that ethnographers do well. If you start without an understanding of the pecularities of what a community values and how it distributes attention, you’re going to end up with a new leg that may look good but doesn’t function very well. I was also pleasantly surprised by how many economists and computer scientists said how they had abandoned game theory and other abstracted ways of looking at these problems when they realised how un-generalizable reputation really is.

And the quote of day?

“Game theory imagines that humans are perfect information processors. They are not.”

Featured image by MervC licensed under a Creative Commons Attribution Non-Commercial license on Flickr

During the aftermath of the Chilean earthquake last year, the Ushahidi-Chile team received two reports — one through the platform, the other via Twitter — that indicated an English-speaking foreigner was trapped under a building in Santiago.

“Please send help,” the report read. “i am buried under rubble in my home at Lautaro 1712 Estación Central, Santiago, Chile. My phone doesnt work.”

A few hours later, a second, similar report was sent to the platform via Twitter: “RT @biodome10: plz send help to 1712 estacion central, santiago chile. im stuck under a building with my child. #hitsunami #chile we have no supplies.”

An investigation a few days later revealed that both reports were false and that the Twitter user was impersonating a journalist working for the Dallas Morning News. But this revelation was not in time to stop two police deployments in Santiago that leaped to the rescue before they realized that the area had not been affected by the quake and that the couple living there was alive and well.

Is false information like this one just a necessary by-product of “crowdsourced” environments like Ushahidi? Or do we need to do more to help deployment teams, emergency personnel and users better assess the accuracy of reports hosted on our platform?

Ushahidi is a non-profit tech company that develops free and open-source software for information collection, visualization and interactive mapping. We’ve just published an initial study of how Ushahidi deployment teams manage and understand verification on the platform. Doing this research has surfaced a couple of key challenges about the way that verification currently works, as well as a few easy wins that might add some flexibility into the system. It’s also revealed some questions as we look to improve the platform’s ability to do verification on large quantities of data in the future.

What We’ve Learned

We’ve learned that we need to add more flexibility into the system, enabling deployment teams to choose whether they want to use the “verified” and “unverified” tagging functionality or not. We’ve learned that the binary terms we’re currently using don’t capture other attributes of reports that are necessary to establishing both trust and “actionability” (i.e., the ability to act on the information). For example, the “unverified” tag does not capture whether a report is considered to be an act of “misinformation” or just incomplete, lacking contextual clues necessary to determine whether it is accurate or not.

We need to develop more flexibility to accommodate these different attributes, but we also need to think beyond these final determinations and understand that users might want contextual information (rather than a final determination on its verification status) to determine for themselves whether a report is trustworthy or not. After all, verification tags mean nothing unless those who must make decisions based on that information trust the team doing the verification.

The fact that many deployments are set up by teams of concerned citizens who may have never worked together before and who are therefore unknown to the user organizations makes this an important requirement. Here, we’re thinking of the job of the administering deployment team providing information about the context of a report (answering the who, what, where, when, how and why of traditional journalism perhaps) and inviting others to help flesh out this information, rather than being a “black box” in which the process for determining whether something is verified or not is opaque to users.

As an organization that is all about “crowdsourcing,” we’re taking a step back and thinking about how the crowd (i.e., people who are not known to the system) might assist in either providing more context for reports or verifying unverified reports. When I talk about the “crowd” here I’m referring to a system that’s permeable to interactions by those we don’t yet know. It’s important to note here that, although Ushahidi is talked about as an example of crowdsourcing, this doesn’t mean that the entire process of submission, publishing, tagging and commenting is open for all. Although anyone can start a map and send a report to the map, only administrators can approve and publish reports or tag a report as “verified.”

How Will Crowdsourcing Verification Work?

If we had to open up this process to “the crowd” we’d have to think really carefully about the options we might have in facilitating verification by the crowd — many of which won’t work in every deployment. Variables like scale, location and persistence differ in each deployment and can affect where and when crowdsourcing of verification will work and where it will do more harm than good.

Crowdsourcing verification can mean many different things. It could mean flagging reports that need more context and asking for more information from the crowd. But who makes the final decision that enough information has been provided to change the status of that information?

We could think of using the crowd to determine when a statistically significant portion of a community agrees with changing the status of a report to “verified.” But is this option limited to cases where a large volume of people are interested (and informed) about an issue, and could a volume-based indicator like this be gamed especially in political contexts?

Crowdsourcing verification could also mean providing users with the opportunity of using free-form tags to highlight the context of the data and then surfacing tags that are popular. But again, might this only be accurate when large numbers of users are involved and where the numbers of reports are low? Do we employ an algorithm to rank the quality of reports based on the history of their authors? It’s tempting to imagine that an algorithm alone will solve the data volume challenges, but algorithms do not work in many cases (especially when reports may be sent by people who don’t have a history of using these tools) and if they’re untrusted, they might force users to hack the system to enable their own processes.

An Enduring Question

Verification by the crowd is indeed a large and enduring question for all crowdsourced platforms, not just Ushahidi. The question is how we can facilitate better quality information in a way that reduces harms. One thing is certain: The verification challenge is both technical and social, and no algorithm, however clever, will entirely solve the problem of inaccurate or falsified information.

Thinking about the ecosystem of deployment teams, emergency personnel, users and concerned citizens and how they interact — rather than merely about a monolithic crowd — is the first place to look in understanding what verification strategy makes the most sense. After all, verification is not the ultimate goal here. Getting the right information to the right people at the right time is.

Image of the Basílica del Salvador in the aftermath of the Chilean earthquake courtesy of flickr user b1mbo.

I like the idea of trusted networks of people working together (actually, it seems that this technique has been used for decades in the activism community) but I have some problems with the term that has been “coined”. I guess I will be called a “muggle” but I am willing to take the plunge because a) I have never been called a “muggle” and I would like to know what it feels like and b) the “crowdsourcing” term is one I feel is worthy of a duel.

Firstly, I don’t agree with the way that Meier likens “crowdsourcing” work like Ushahidi to statistical methods. I see why he’s trying to make the comparison (to prove crowdsourcing’s value, perhaps?) but I think that it is inaccurate and actually de-values the work involved in building an Ushahidi instance. Working on an Ushahidi deployment is not the same as answering a question through statistical methods. With statistical methods, a researcher (or group of researchers) tries to answer a question or test a hypothesis. ‘Do the majority of Hispanic Americans want Obama to win a second term?’ for example. Or ‘What do Kenyans think is the best place to go on holiday?’

But Ushahidi has never been about gaining a statistically significant understanding of a question or hypothesis. It has been designed as a way for a group of concerned citizens to provide a platform for people to report on what was happening to them or around them. Sure, in many cases, we can get a general feel about the mood of a place by looking at reports, but the lack of a single question (and the power differential between those asking and those being asked), the prevalence of unstructured reports and the skewed distribution of reporters towards those most likely to reply using the technology (or attempting to game the system) make the differences much greater than the similarities.

The other problem is that the term lacks a useful definition. Meier seems to suggest that the “bounded” part refers to the fact that the work is not completely open and is limited to a network of trusted individuals. More useful would be to understand under what conditions and for what types of work different levels of openness are useful, because no crowdsourcing project is entirely “unbounded”. Meier says that he ‘introduced the concept of bounded crowdsourcing to the field of crisis mapping in response to concerns over the reliability of crowd sourced information.’ But if this means that “crowdsourced” information is unreliable, then it would be useful to understand how and when it is unreliable.

If we take the very diverse types of work required of an Ushahidi deployment, we might say that they include the need to customize the design, build the channels (sms short codes, twitter hashtags, etc), designate the themes, advertise the map, curate the reports, verify the reports, find related media reports, among others. Once we’ve broken down the different types of work, we can then decide what level of openness is required for each of these job types. I certainly don’t want to restrict the advertising of my map to the world, so I want to keep that as “unbounded” as possible. I want to ensure that there are enough people with some “ownership” of the map to keep them supporting and talking about it, so I want to give them some jobs that keep them involved. Tagging reports as “verified” is probably a more sensitive activity because it requires a set of transparent rulesets and is one of the key ways that others come to trust the map or not. So I want to ensure that trusted people, or at least those over whom I have some recourse, do this type of work. I also want to get feedback on themes and hashtags to keep it close to the people, since in the end, a map is only as good as the network that supports it. Now if I have different levels of openness for different areas of work, is my project an example of “bounded” or “unbounded” crowdsourcing?

Although I am always in favor of adding new words to the English language, I feel that the term “unbounded crowdsourcing” is unhelpful in leading us towards any greater understanding of the nuances of online work like this. Actually, I’m always surprised at the use of the term “crowdsourcing” over “peer production” in the crisis mapping community since crowdsourcing implies monetary or commercial incentivized work rather than the non-monetary incentives that characterised peer production projects like Wikipedia (see an expanded definition + examples here). I can’t imagine anyone ever “coining” the term “unbounded peer production” (but I seem to be continually surprised, so I should completely discount it from happening) and I think that this is indicative of the problems with the term.

So, yes, if we’re talking about different ways of improving the reliability of information produced on the Ushahidi platform, I’m excited to learn more about using trusted networks. I just think that if a term is being coined, it should be one that advances our understanding of what the theory is here. Is it that: if you restrict the numbers of people who can take part in writing reports, you get a more reliable result? Where do you restrict? What kind of work should be open? What do we mean by open? Automatic acceptance of Twitter reports with a certain hashtag? Or an email address that you can use to request membership? Is there a certain number that you should limit a team to (as the Skype example suggests)?

This “muggle” thinks that the term doesn’t get us any further towards understanding these (really important) questions. The “muggle” will now squeeze her eyes shut and duck.

Cross-posted from blog.ushahidi.com

As Ushahidi ethnographer, my job is to do on-the-ground research on users’ experience with our technology in particular contexts. Something that we’ve been thinking about a great deal as we develop SwiftRiver is the process of verification, the ways in which technology and society work together to create useful, trustworthy and actionable information, as well as where the technology in particular contexts might be failing.

With over 20,000 installations of Ushahidi and Crowdmap since January, 2009, Ushahidi has been used in a number of different contexts – from earthquake support in Haiti, to reports of sexism in Egypt, to election monitoring in the Sudan. In each of these cases, a map is publicized and individuals are encouraged to send reports to it. The process of verifying information reported by the crowd has taken on a variety of different forms depending on the needs and affordances of the environment and the community supporting it.

The memo I just published on scribd introduces the concept of verification, how it has evolved at Ushahidi and in sample deployments, alternative ways of thinking about verification and some suggestions for further research. Its goal is to inform developers and designers as they develop the next generation of Ushahidi and SwiftRiver software to meet the needs of our users rather than prescribing what should be done.

Ushahidi support for verification has until now been limited to a fairly simple backend categorisation system by which administrators tag reports as “verified” or “unverified”. But this is proving unmanageable for large quantities of data and may not be the most effective way of portraying the nuanced levels of verification that can practically be achieved with crowdsourced data.

What research needs to be done to test verification alternatives so that Ushahidi and Crowdmap deployers are provided with due diligence tools that can advance trust in their deployments? Can we do this in a way that doesn’t add any new barriers to entry to those who need to have their voice heard on Ushahidi? How can we ensure that this solution is as close as possible to the needs, incentive systems and motivations of deployers and users? What is the next step for Ushahidi verification?

Wikipedia articles on breaking news stories dominate page views on the world’s sixth-largest website. Perhaps more importantly, these articles drive the most significant editor contribution — especially among new editors.

In the first three months of this year, English Wikipedia articles with the most contributors were the 2011 Tucson shooting, the 2011 Egyptian revolution and the 2011 Tōhoku earthquake and tsunami articles with 460, 405 and 785 editors contributing to the growth of the article respectively.

Interestingly, a number of Wikipedia policies discourage writing articles on breaking news. One of Wikipedia’s 42 policies, titled “What Wikipedia is not” (or WP:NOT), highlights that the site is, above all, an encyclopedia, not a newspaper (Wikipedia:NotNewspaper). The policy states that although the encyclopedia needs to include current and up-to-date information as well as standalone articles on “significant current events,” not all verifiable events are suitable for inclusion in Wikipedia.

Wikipedia articles are not journalism

According to the policy, “Wikipedia should not offer first-hand news reports on breaking stories” because “Wikipedia is not a primary source.” The encyclopedia has a tenuous relationship with primary sources. Policy states that primary sources, “accounts written by people who are directly involved in an event, offering an insider’s view of an event” are (mostly) inappropriate because Wikipedia strives to represent a “Neutral Point of View” (NPOV), and primary sources can be misused to reflect a fringe theory as mainstream. NPOV is one of the five pillars of Wikipedia and frames to a large degree what is allowed into the encyclopedia and what is left out.

News reports on a breaking news story require that Wikipedians use primary sources to update the rapidly evolving articles on issues like death counts after an earthquake. While journalists are able to use primary sources to make a judgment on the death count at the time of publishing and then do the same using new sources when they write successive stories, Wikipedians must do the same collectively and iteratively as new versions are created every few seconds.

In the Japanese earthquake article, this challenge resulted in contradictory facts about the height of the tsunami and the death tolls in the same article, prompting one editor (“Dcoetzee”) to create templates for the number of missing and the dead casualties that could be edited once with changes immediately reflected in every part of the page (see Keegan, Gergle and Contractor’s Hot off the Wiki: Dynamics, Practices, and Structures in Wikipedia’s Coverage of the Tohoku Catastrophes).

Wikipedia articles are not news reports

The barrier to entry into Wikipedia articles is notability: Subjects must be notable enough to create enduring articles on the encyclopedia. According to policy, while news reporting covers announcements, sports news or celebrities, the fact that something is “in the news” is not a sufficient basis for inclusion in the encyclopaedia. Notability is difficult, perhaps impossible to predict directly after an event, and can result in historical events being described in purely modern terms or an article being created about something noteworthy at a particular time which later might not meet notability requirements.

Wikipedians call this “recentism” and have a tag to make it transparent to readers that the article might be skewed towards “recent perspectives.” In an essay on “recentism,” Wikipedians describe the phenomenon as “writing or editing without a long-term, historical view, thereby inflating the importance of a topic that has received recent public attention.”

Both the “Wikipedia articles are not: Journalism” and “Wikipedia articles are not: News reports” policies recommend moving timely news subjects to WikiNews, a sister project to Wikipedia that allows use of primary sources and is intended to be a primary source. But WikiNews has suffered from a low contributor base and disagreement among contributors about the best way to build the news portal.

In September, a large portion of the Wikinews contributor base announced on the Foundation-l mailing list that they had forked the project and started OpenGlobe” after becoming deeply dissatisfied with Wikinews.”

Wikipedia articles are not who’s who

The third item of “Wikipedia:NotNewspaper” explains that, even when an event is notable, individuals involved in it may not be. This policy speaks to the need for enduring articles that will still be notable in the years after the event. While newspapers are often concerned with explaining events through the people affected by such events, Wikipedia wishes to take the long-term view, attempting to avoid cases that give undue weight to the person or event and thus conflict with NPOV.

 

The first rough draft of history?

It took just 11 minutes for the Japanese Wikipedia to create an article after the 9.0-magnitude undersea megathrust earthquake occurred off the coast of Japan on March 11. Twenty-one minutes later, the English Wikipedia article was created, and although the wire services reported the earthquake within minutes, The New York Times did not file a full story until more than three hours after the earthquake hit.

Despite the distinct discouragement of reporting on current news item for reasons mentioned above, Wikipedia has become the site of major activity around large news events like this one. The ability of anyone to edit the encyclopedia and the lack of any restrictions on editing articles, as well as the fact that notability is a relative concept, means that Wikipedia policy cannot stop the hundreds of editors who flock to the encyclopedia driven by a single purpose to work on a particular page.

But if Wikipedia and not the news media is the first rough draft of history, what does this mean for Neutral Point of View? If Wikipedians are evaluating and synthesizing primary sources rather than sources who have already evaluated the importance of an event, is Wikipedia at the risk of becoming subjective? Consensus may be more easily achieved when the event is a natural disaster, but when it’s a war or a revolution and the editors’ motivations are different, then the same architectural flexibilities can lock articles into disagreement.

Wikipedia may be a reluctant journalist, but its influence on the media landscape is unmistakable.

I arrived in Nairobi last night after an absence of about five years. As I left the plane through the walkway, I took a deep breath and inhaled the familiar southern African smell that I always miss so much living in America. I walked through to customs and baggage claim and to my taxi and hotel and became aware of all the things I was noticing: my slight frustration at the absence of instructions about which line to stand in at the immigration hall; the fact that there was not enough room for my place of birth in the immigration paperwork; the fact that, in stark contrast to the Amsterdam Schiphol Airport that I had come from, this airport seems not to have changed in a decade or so.

I noticed how long we had to wait for our bags to come through, the nationalities of the people coming here, how closely they stood next to one another. And my driver, patiently waiting for me, familiar sign in hand. On the car ride to the hotel, I looked at billboards and noticed what was being advertised and who was being represented, the state of repair of the roads and the roadside flowers and how people drive and the smells of food and industry and bodies.

I thought: Is this the collection of noticings that constitutes a place? And if what defines a place is its signposts, its boundaries, the taken-for-granted ways of doing things, the expected and the unexpected, what are the equivalents in online spaces? How do we know that we have left one space and arrived at another? How does the experience of outsiders (or n00bs) differ from that of locals?

This new way of thinking about social media (new for me, at least) came about when I was asked to speak at a conference about the ‘crucial role of social media’ in the Middle East and elsewhere. Buried in the description of the session was the question: ‘Does what happened in the London Riots diminish the power of social media?’ As I thought about what to say and what was expected of me, it struck me that the problem with the current way questions around social media are framed is that they require defining technological artefacts as good or bad, when it might be more appropriate to talk about technology as a place where good and bad things can, and do, happen.

If we frame social media as places, we can understand more fully the role of people in those places, rather than talking about the technical characteristics of Facebook or Wikipedia as determining a particular type of behaviour. Looking only at the “bad” privacy features of Facebook, for example, we are tempted to assume that “privacy is dead” because of the “forced sharing” that is happening through changes in the technology. But this view fails to represent the ways that people self-censor or move to more intimate spaces in order to protect their privacy, something I noticed in my study of privacy in an educational context, for example.

Framing social media as places enables us to realise how we move between platforms (for example, Facebook and Google+) not only because of the new shiny gadgets we find there, but because of the people who inhabit those spaces. It is the flow of people and practices that defines the place as much as it is its landscape and architectural features. Facebook, for example, is defined by particular boundaries (my page, your page, a photograph that belongs to a particular group), taken-for-granted ways of doing things that define deviance and compliance among particular groups (don’t friend your teacher, don’t send too many updates and flood your friends’ streams, don’t tag drunk pictures of friends) and artefacts (the activity stream, wall and photo albums) that, taken together, define the place.

It seems kind of obvious when you think about it, and it isn’t a new way of thinking about technology: we’ve been talking about going online and migrating from different operating systems for a while. But the fact that we’re surprised that Google+ isn’t currently teeming with people, or that more Kenyans aren’t contributing to Swahili Wikipedia, or that women make up such a small percentage of Wikipedia edits suggests that we are thinking too much of social media as things rather than as places. If we thought about Google+ as a big, shiny, new complex, we’d begin to understand that people won’t necessarily move there just because the technology is better when few of their friends are there.

The key aspect that we miss in thinking of social sites as technological artefacts is that we tend to ignore culture and power – two really big and slippery aspects of what makes certain types of people have certain types of conversations in particular online spaces, and of what defines who feels welcome or unwelcome to participate. It has caused us to define Wikipedia or Facebook at a level of granularity that isn’t deep enough to really get an understanding of what is happening there, where the power is located and how we might engineer to encourage particular creations and conversations. This is not just about understanding the affordances of the software. In order to understand Wikipedia collaboration, I can’t only look at the MediaWiki software – in the same way that to understand Kenya, I couldn’t just read about its legal framework or look at the statistics about the country. Being there, experiencing how people to speak to me, noticing what the signposts say and what they leave out, is part of the necessarily long journey toward a full understanding of the place.

Perhaps most importantly, it is the culture of a place that will dominate my decision to come back or not. And this, in its essence, is at the heart of what every online community seeks, and is the same reason why it’s so hard to control. The government of Kenya can build better roads and speak on television about being welcoming to tourists, for example, but the majority of the experience of being in Kenya as a tourist or a local, is outside of government control. Culture, we find out, is a mysterious mix of so many different qualities in varying proportions that act together to define a place. Understanding culture is probably more art than science, but however we learn about it, it’s an important part of what makes us stay in some places to become loyal nationalists or merely return as tourists.

Rachelle Annechino and I are recent graduates of the School of Information at UC Berkeley. We met one cold, sunny summer day in August (only in San Francisco!) when I arrived to find friends to learn Python with. Rachelle and I meet to co-work and chat at Brown Couch Café in Oakland where we talk about fascinating bits and pieces from our lives and work. For her final project, Rachelle and her project partner, Yo-Shang Cheng interviewed San Francisco residents and asked them to draw pictures of their internal images or “mental maps” of the neighborhoods they lived in and of the city as a whole. They then visualized these mental maps according to concepts like ‘corridors’ (where are the hearts of each neighbourhood?), ‘barriers’ (is it really that close? It’s not always as simple as it looks getting from one neighbourhood to another in San Francisco) and ‘boundaries’ (what neighbourhood are you in? according to whom?). Rachelle is simply one of the most insightful, brilliant people I know. And she rocks at Python – which makes her a good friend to have.

I met Jenna Burrell when Rachelle and I took her Qualitative Research Methods class last year. Jenna has been doing research on Internet use in Ghana for the past decade or so and was one of the most inspiring teachers that I had at the I School. Jenna’s forthcoming book ‘Invisible Users: Youth in the Internet Cafes of Urban Ghana’ is an incredibly rich contribution to our understanding of African Internet culture. Mostly when I think of Jenna, I think of the fact that while I was in Accra speaking in staid conference rooms during the Africa preparatory conference for the World Summit on the Information Society in 2005, Jenna was also out talking to young Ghanaians in Internet cafes and in the streets who were disconnected from a discussion which was ostensibly about them. Jenna is an incredible mentor and her writing about ‘The Fieldsite as a Network’ has been so helpful in thinking about how to ‘do’ digital ethnography. She continues to push the boundaries of the discipline and ask important questions about how digital technologies might become part of the grassroots, self-organizing efforts of populations marginalized from the global economy.

Tricia Wang was introduced to me in one of Jenna’s classes when Jofish Kaye suggested I read about the work she had done on Internet censorship in China. I looked her up and just knew we would be friends. Tricia’s critique of the Google China debacle and her calling for Google to employ more ethnographers in order to better understand the Chinese internet culture was so powerful, and her PhD work on migrant workers is inspiring to say the least. As I write this, Tricia is in China doing her fieldwork, sleeping in Internet cafes and accompanying migrant workers as they move through the city. She’s trying to understand how the use of technology changes how people interact with the physical city, a concept she calls’ digital urbanism on the margins’: migrants’ urban lives mediated through communications technologies like mobile phones and computers in Internet cafes.

And then there’s me, the budding ethnographer, finding herself lucky to know these incredible people and looking forward to the little journey we’re going to go on at this site. Ethnography Matters will be a place where we can share what we’re reading and writing about, how we’re thinking about ethnography, and hopefully giving a little insight for others who are thinking about a career in ethnography into what this even means today. We’ll have others join us in the future, and if you’re interested in contributing, please let us know. We’re looking forward to walking around in your shoes too!

Our key findings include:

1. About half of all deleted articles from June ’07 to Jan ’11 were unilaterally deleted by administrators via the CSD process.
2. Surprisingly, spam, vandalism and patent nonsense make up only 8.00%, 5.69% and 5.36% of CSDs respectively, while the more subjective ‘No indication of importance’ makes up 38.47% of all CSD criteria.
3. With some outliers, AfD discussions have few participants, and those participants are overwhelmingly regulars to the process. 74% of all AfDs are made up entirely of users who have previously participated in an AfD, and 18% of all AfDs only have one newcomer. You can read more on the PDFs below but there’s also a lot of great research by other authors at WikiSym and on from the Wikimedia Foundation’s Summer of Research program.

Poster PDF |  Participation in Wikipedia’s Article Deletion Processes (WikiSym accepted poster research) PDF

This morning I read a wonderful article by Tamar Ashuri from Ben-Gurion University for an upcoming edition of the journal New Media and Society entitled ‘(Web)sites of memory and the rise of moral mnemonic agents‘. Ashuri looked at how two websites set up by Israelis – one to monitor human rights of Palestinians at Israeli checkpoints; the other to collect testimonies of Israeli soldiers who served in the Occupied Territories – act as agents of collective memory. Ashuri argues that digital networked technologies is challenging the mechanisms that society employs to deny memories of immoral acts and how the online archives created by moral witnesses become a space of living memory and a sphere of moral engagement.

Ashuri explains that ‘collective memory is a social necessity; neither an individual nor a society can do without it.’ She quotes from Kansteiner (2002: 180) to describe how collective memory is different from history:

Collective memory is not history, though sometimes made from similar material [...]. It can take hold of historically and socially remote events but it often privileges the interest of the contemporary. It is as much a result of conscious manipulation as unconscious absorption and it is always mediated.

Ashuri describes how Avishai Margalit distinguishes between “common memory” (a group of people who recall a certain episode that each of them experienced) and “shared memory” (which requires communication). Shared memory is is not just an aggregate of individual memories because it requires those who remember the episode to come together to create one version (or at least a few version) through an active presentation and retelling of a story that Margalit terms ‘a division of mnemonic labor’ (2002: 52). Margalit wrote that whereas in traditional society there was a direct line from the people to their priest, storyteller or shaman, shared memory in modern society ‘travels from person to person through institutions, such as archives, and through communal mnemonic devices, such as monuments and the names of streets’ (2002: 52). Ushuri posits a new term “joint memory” to describe a new type of memory that is a ‘compilation of personal histories made public for the public’ (2011: 4). She argues that digital networked technology is challenging the exclusive role of professional mnemonic agents designated by the church, state, monarchy etc.

Significantly, joint memory is not motivated by personal interests – the desire to tell an interesting story or reveal new information – but is driven by a social purpose: Witnesses who add their recollections to an accessible and shareable compilation of memories attempt to expose events that the default collective (such as the nation) denies or wishes to forget.

I don’t agree that such reporting is not motivated at all by personal interests but I do agree with the fact that the social/moral purpose of witnessing is really critical here. Ashuri builds on Margalit’s conception of a moral witness whose testimony is ‘essentially driven by a moral purpose. It reflects hope for the witness to be a social agent who, in testifying to his or her harsh experience, transforms (passive) addressees into active audiences’. She says that what is happening now is slightly different because the moral witness now performs memories of suffering experienced in a public space.

In my conceptualisation, the (moral) mnemonic agent is the one who recalls his or her memories regarding events in whcih others have suffered and by that act of witnessing renders this suffering visible and hence difficult to marginalize or deny. The moral aspect of this act, in my estimation, derives from the content of the mnemonic text (testimony about suffering inflicted by evil) and from its objective (calling on the audience to shed their observer garb and re-enact the experience of the harsh realities). (p5)

I think this is really useful way to think about how websites like Ushahidi as well as engagement on social media sites like Twitter are acting as platforms for this kind of performance and the communication of suffering, and how this is one way of looking at how collective narratives about the world are being wrested from those who traditionally controlled this in the Middle East. Whether it is reporting on human rights violations in Saudi Arabia, harassment of women in Egypt on Harassmap  or reports of arrests and casualties in Syria I think that looking at the maps through the lens of moral witnessing and Ashuri’s “joint memory” could be a wonderful entry point for re-thinking Ushahidi’s role and effectiveness in the world.