Grants:IEG/Stepwise Disclosure Edition: Wikipedia for shy people

status: not selected

Individual Engagement Grants	review grant submissions	visit IdeaLab submissions
eligibility and selection criteria

project:

Stepwise Disclosure Edition: Wikipedia for shy people

project contact:

oscar.diazehu.es

participants:

grantees: Oscar Diaz, Cristobal Arellano

summary:

Wikipedia makes editing readily visible. By contrast, we argue for a stepwise disclosure editing where hesitant contributors can draft/share their editing before being disclosure to the public.

engagement target:

English (?) Wikipedia

strategic priority:

Increasing Participation

total amount requested:

25,000 USD

2014 round 1

Project idea

This project focuses on situational editing, i.e. editing that enhances existing articles rather than creating articles from scratch. In this setting, Wikipedia default editing might not always be the most convenient one. Wikis in general, and Wikipedia in particular, rest on the premise that editing is readily followed by publication: edit&go. As soon as editing is saved, it becomes quickly published. However, this might not be the best approach depending on the type of user. Some examples follow:

• the shy. Not all users feel equally confident when contributing to Wikipedia. New comers or youngsters might be intimated by being subject to public scrutiny, more to the point if there exist peer pressure (e.g. class assignments). Literature seems to confirm these insights: fear of edits being judged by other users on the accuracy and quality of the edits made ; not amending others contributions due to a concern for hurting the feelings of other group members ; and finally, the fact of being intimidated by the responsibility of editing in an open wiki setting .
• minority-language speakers. Here, it is common for users to be fluent in speaking but less confident in writing. This might put off potential editors. Due to the lack of instant grammar checkers, these editors might need the reassurance of a grammar expert before publicly releasing their contribution.Euskara is a case in point.
• the reputation minded. People care about their reputation and the writings they sign. They strive to elaborate good writings. But drafting might need to be conducted outside the spotlight. Similar to academic publications, a private reviewing process might be conducted before releasing the contribution. Stepwise disclosure permits to mimic peer reviewing without leaving Wikipedia.

Next, we look at existing mechanisms in Wikipedia to address these scenarios. For our purpose, editing can be characterized along two dimensions: visibility (i.e. who can see the editing: public versus private), and "in-place-ness" (where is the editing conducted: in-place editing versus detached editing, depending on whether the editing is conducted in the article place or not). Next, we elaborate on current approaches:

• Traditional Wikipedia editing can be qualified as having public visibility and being in-place.
• In addition, registered users are able to create drafts (the drafts namespace on English Wikipedia) (thanks to Siko for pointing this out). Wikipedia drafts account for a semi-public visibility (i.e. though drafts are not indexed by search engines, they are still URL addressable), but draft editing is no longer conducted within existing articles but in a separated area. This approach works well for bright new articles but not so clear how to use it for situational editing.
• Alternatively, users can also resort to workpages. A workpage is "an article subpage serving as a collection of material and work in progress that may or may not be incorporated into an article." Workpages are a neat mechanism to avoid polluting existing articles with material in preparation. Workpages account for a separate place where to elaborate the material before being integrated into the main article. Notice however that this approach is public and detached.
• A related MediaWiki extension is flagged revision (thanks to J. Felipe for the input). This extension permits "to set an article such that when a user viewed the article, they would see not the most recent edits to the article, but instead an older version of the article that had been tagged as a clean or "sighted" version. Established Wikipedia editors might be granted rights (possibly automatically) that would let them review page revisions and determine whether the flag on an article should be reset to a more recent version". Flagged revisions account for an in-place approach where some changes are kept hidden till receiving the green light from " established Wikipedia editors". Compared to our proposal, differences are three-hold: target audience, aim and technological platform. Flagged revision is thought for "the community to fashion proposals which set the specific procedures for reviewing". Our proposal is somehow complementary since it gives the power to the contributor: it is up to the contributor to decide who and when to see her editing. Finally, flagged revisions is server-based (i.e. an extension to MediaWiki). Our approach would be client-based (i.e. an extension to Google's Chrome).
• mw:Editor campaigns. This is a nascent Wikimedia Engineering project, kicking off in mid-February 2014 (thanks Nemo for the input). It addresses the question of "how we get potential new editors to sign up and make their first edits to Wikipedia". To this end, they provide infrastructure to provide some recurring assets such as "choosing a list of things to do, creating a place for people to join and these find things to do, inviting people, providing them instructions and help, and reporting on the progress of the group". mw:Editor campaigns addresses the lack of a "campaign infrastructure" as the hindrance for editing. This is certainly a help for newcomers. By contrast, we address a different concern: shyness. No matter whether editing is conducted within a campaign or as individual effort, shyness (or peer pressure) is still there.

In short, people who want to be kept outside the spotlight of directly editing Wikipedia articles, are forced to move outside the article realm by creating drafts or workpages. Besides implying an additional burden (e.g. being registered), these mechanisms do not account for situational editing (i.e. changes are not made within the context of the current article) nor are they private (i.e. peers can still access drafts and workpages).

We believe above limitations can be mitigated through stepwise disclosure in-place editing:

• the part "stepwise disclosure" highlights the process: editing starts by being totally private, next being gradually unveiled to the author-selected mates, till finally consolidated as a traditional Wikipedia editing,
• the part "in-place editing" points out that this process should be conducted in the very same way as "normal" editing (i.e. the one you got when clicking on the edit tab). No change in either the place or the way editing is conducted.

What is your solution?

So far, most approaches are server-side (i.e. they rest on extensions of MediaWiki). Our approach advocates for a client-side approach (i.e. a browser extension) that permits to make editing and visibility two orthogonal concerns. The challenges ahead include:

• supporting distinct "spheres of visibility", and
• making visibility transparent to editing, i.e. no difference should exist in editing regardless of the visibility being chosen.

Challenge 1. Contributors should be free to select “the sphere of visibility” with which they feel more confident. Initially, editing can be for their eyes only ('private' sphere). This private setting can be used to collect notes, references, and hold initial drafts, which might be in a too early stage to be released to the public or be shared in the article’s talk page. The first draft can next be shared with close friends who then, start to collaboratively contribute (i.e. 'fellow' sphere). As additional confidence is gained, they can unveil their editing to their supervisors. Finally, they all back the version that ends up being disclosed on Wikipedia. This should be achieved without leaving Wikipedia, better said, users should keep interacting through the Wikipedia graphical interface that pops up when clicking the edit button (i.e. in-place editing). This moves us to the second challenge.

Challenge 2. The introduction of visibility spheres should not introduce additional burdens to users. Editing should be made in the very same way as before: click the 'edit' tab, and you are done. No need to move somewhere else (i.e. drafts or workpages). No need to learn a new interface. No change from traditional article editing. The difference stems from “the visibility button”. By default, visibility is set to ‘private’. No one will see your edits. Next, contributors can share their editings with colleagues taken from their contact list. Finally, locally-kept editing can be consolidated as a traditional Wikipedia editing. Only after this step is the contribution publicly visible.

How is this achieved? Think of "visibility spheres" as different locations where to keep article versions. Public versions (those supported so far) are centrally located at the MediaWiki database. By contrast, "visibility spheres" change the place where versions are located. When users decide to switch to a private sphere for a given article, this article's versions are no longer store in the Wikipedia database but kept locally at the user's browser.

This begs the question of how the latest article version is obtained. Users connect to Wikipedia as before. However, when article pages are loaded, current Wikipedia content is seamlessly and dynamically intertwined with locally-kept history versions. Likewise, when users disclose their editings to close fellows, their browser-based versions are kept in sync (sync granularity is article). In this way, editings are propagated along the so-built social networks before being unveiled to the whole Wikipedia community. This vision however entails a main challenge: the parallel evolution of the public content (the article itself) and the private draft being prepared by the "shy" contributor.

This is achieved through sophisticated annotation techniques and Web Augmentation that permit the preservation of both Wikipedia's GUI and Wikipedia's way of editing. Just the visibility button.

A bit more detail for techies about the planned implementation. The MediaWiki’s VisualEditor module needs to be extended. This extension is realized in the browser, adding a hook to the MediaWiki’s ResourceLoader when the core of the VisualEditor extension. In order to add this new functionality, a new type of node is introduced: ContributionNode. ContributionNode is similar to the existing TextStyleBoldAnnotation; it is a ve.[ce/dm].Annotation. DissonanceNodes are introduced by the user through the toolbar (ve.ui.DissonanceDialog[Tool]). ContributionNodes are automatically used to annotate all the text introduced by the user capturing the events of content addition (contentChange of VeUISurface).

Project goals

• Engage fledgling users in Wikipedia editing.
• Support gradual disclosure of editings.

This proposal aligns with Wikipedia’s strategic priorities: Increase Participation as well as with the Teahouse initiative

Project plan

Scope

Activities

Our intention is to schedule the project along four stages, namely:

• Background (1 month): collect more evidences and experiences about the issue addressed in the proposal that can guide the solution.
• Use case "private sphere" (3 months): support local editings.
• Use case "fellow sphere" (1 month): support the sharing of editings among close colleagues.
• Use case "consolidation" (1/2 month): unveil local editings into Wikipedia.
• Validation (5 months). Design thinking is planned so that early prototypes are checked by a range of selected students based on their confidence with English and extroversion. This core set of students are selected from our own undergraduates in San Sebastián. In addition, one main validation for each use case will be conducted by our validator partner.

The result of the project would be a Google Chrome extension. Google Chrome has been selected due to being the most popular browser to access MediaWiki projects. Notice that such extension could be supported as a MediaWiki extension but the grant requirements set that "any technical components must be standalone or completed on-wiki".

Each use case would be tested with students. So far, available subjects are limited to our own students. However, we do hope to engage other lecturers. Testing would be conducted using controlled experiments. Students would be split in two groups. One group will use Wikipedia in the normal way. The other group will use this extension. Comparison would be set in terms of:

• Quantity, e.g. size of contribution in terms of number of words (hypothesis: private spheres spur fluency).
• Quality as judged by the lecturer (hypothesis: private spheres promote a more fluent and open exposition of potentially divergent views).
• Number of reversals (hypothesis: private spheres promote fellowship while facilitating bold but friendly reversals of classmate editings which would be embarrassing when conducted in a public setting).
• Number of people involved (hypothesis: private spheres spur collaboration-in-the-small).

Budget

Total amount requested

26,000 USD

Budget breakdown

Concept	Amount
Stipends for supporting browser-located revision history	8,000 USD
Stipends for Web augmenting Wikipedia Visual Editor	9,000 USD
Contract for external lecturer who acts as the validator	3,000 USD
Wikimedia merchandise for participating subjects	2,000 USD
Travel expenses to present results in a conference (OpenSym, Wikimania) (2 persons)	4,000 USD

Intended impact

Target audience

Our main target audience are undergraduates. This project could be of interest for the different initiatives that aim at bringing Wikipedia in the classroom. Specifically, Wikipedia Campus Ambassadors and Wikipedia Online Ambassadors might spread this notion of stepwise disclosure. In addition, the Wikipedia Teaching Fellowship might also echo this approach among Wikipedia Teaching Fellow.

Community engagement

We are glad to acknowledge the support of Felipe Ortega, a Board member for Higher Education and Universities of Wikimedia España, the Spanish chapter of Wikimedia Foundation. Dr. Ortega will act as a validator. Also happy to add Dr. Juan M. Dodero from University of Cadiz as a second evaluator. Dr. Dodero act as the Spanish liaison from the European project opendiscoveryspace which provides a unique opportunity to evaluate the extension.

In addition, we hope to tap into other universities that are already using wikis and could be interested in:

• University of Massachusetts Boston [1].
• University of Columbia [2].
• University of Arizona [3].

In addition, all the projects that appear in School and university projects could be candidates for use our proposed solution (initial email being already sent).

Fit with strategy

This proposal aligns with Wikipedia’s strategic priorities: Increase Participation.

Sustainability

The extension would be open source. As other open source projects, we hope the community will help to keep moving it forward.

Measures of success

The goals of this project are:

• A Google Chrome extension for stepwise disclosure of Wikipedia editings.
• Improve the quantitative metrics as defined by the WikiProject: United States Public Policy. These metrics can be found here.

Participant(s)

Our profiles can be found at: Oscar Díaz and Cristóbal Arellano. We think we are well placed to conduct this project for the following reasons:

• We suffered this problem with our own students.
• We have a broad experience in JavaScript programming.
• We have previously developed publicly available extensions for web browsers (see Sticklet).

Discussion

Community Notification

We have initiated communications with the team responsible of the Wikipedia Education Program, in order to get the maximum spread and get in contact with universities that are already using Wikipedia for teaching.

Endorsements

Do you think this project should be selected for an Individual Engagement Grant? Please add your name and rationale for endorsing this project in the list below. Other feedback, questions or concerns from community members are also highly valued, but please post them on the talk page of this proposal.

• I like the sound of this project and I can see it being useful, but I don't know that people will take the time to install a Google Chrome extension. I weakly support this. (Also note that I haven't reviewed the budget) Zellfaze (talk) 13:51, 18 April 2014 (UTC)
• Community member: add your name and rationale here.