Author Thanks

This document describes a system whereby anonymous readers can express appreciation and gratitude to article authors, using the Thanks extension and Echo.

Simply, it is a way for Editors to receive daily (or weekly) "rollups" of gratitude, in a similar form to:

"39572 readers thanked you for your work on Barack Obama."

Rationale

Volunteer editing the encyclopedia is largely a thankless job. Recognition is largely given to editors by other editors and other editors alone, which creates a closed-loop system of recognition.

Partly, this is because readers of the encyclopedia have no easy method to show gratitude to editors. Previous experiments in the area of reader interaction (e.g., Article Feedback) have largely been focused on determining errors and provide a generally negative interaction.

We would like to create a purely positive interaction that allows readers to express gratitude to editors.

Hypothesis

A system that allows for readers to express gratitude to article authors will:

1. Provide editors with a sense of accomplishment, recognition, "fiero", and make their audience more tangible
2. Motivate editors to continue editing that article or similar articles
3. Provide readers a sense of participation;
4. Further instill within readers the understanding that they could possibly become editors (and thus themselves be shown gratitude as well)

System

The system is simple: an affordance is introduced that, when clicked, collects a "thanks" notification and sends it to a prescribed number of editors for the article.

Interface

The interface for this system does not require a great deal of design. In fact, given how light-weight it is, a confirmation dialog may not be required.

A simple link or button at the bottom of the article will likely suffice: "Thank the authors" or something similar. Clicking on the link will provide a confirmation (something similar to that provided by Post-edit feedback) saying "You have sent thanks to X editors". We could include the usernames of these 5 authors to make the thank more personal.

Experiments can (and should) be performed concerning the optimal position of the affordance as well as its "volume" with relation to the rest of the article content.

Who Gets Thanked?

The question of "who" receives thanks for an article's edit history is an interesting one and could possibly be difficult or expensive to compute. Sending thanks to every author in an article's history is probably a non-starter (and likely pointless). It is recommended that an algorithm be determined (by product), similar to this:

1. Only X editors (suggest 5)
2. No IP editors
3. No bot editors
4. Always include article creator, if possible
5. Ignore redirects
6. Editors with most contributions (cheaper) or
7. Editors with largest contributions (expensive)
8. Recent editors (within the last month) with less than 5 edits

The members of that list will, at the end of the day, receive a notification via Echo that "X number of readers thanked you for your work on ArticleName".

Perhaps we can use IP address information to determine where these readers are. It would be interesting to see "10 readers from 3 different countries thanked you for your work on ArticleName"., helping editors to see that their audience is worldwide.

Rollups and Delivery

Sending single notifications for every atomic event would be insane and sadistic. Therefore, thanks events must be collated into rollup events and delivered as a single unit. At the end of the prescribed period (daily, weekly, whatever), singular notifications are sent to those determined to be in the "author list".

The delivery schedule could be configurable so as to avoid spamming. This document is written assuming a static schedule per article. However, a more likely (and possibly more pleasant) scenario would involve a rotating, ten-day schedule based on the last digit of the article's ID number (thus, rollups for article 123456 happen on day 6, and ones for 582745902 happen on day 2). This helps to ensure that editors do not get "thanks blindness" for seeing the same article every day.

Rollups of Rollups

If an editor is very prolific, it's likely that they may receive hundreds of such notifications per day, even accounting for staggered deliveries - a stream which would make Echo useless for them. In this case, an additional rollup may be required so that only 1 notification is sent, collating all the notifications into one:

"3,455,229 people thanked you for your work on Barack Obama, Iron Maiden, Led Zeppelin, and 63 other articles."

User Experience

• 
  Thanks - button
• 
  Thanks - sent
• 
  Editors' notification

At the bottom of an article, a user sees a box called "Thank the Editors". The user clicks the Thanks button, and the box changes to show that the Thanks were sent, and then they see an invitation to edit the article.

The editors who get thanked receive a notification telling them how many readers thanked them for an article. They can then look at the readership data or edit a similar article.

Implementation

Storage

Cheaply, the "Author Thanks" could be logged easily thus:

Article

Count

Date

Where the "Count" increments by one each time the "Send thanks" button is clicked. At the end of the day, the rollup is triggered, and a new row is created for the article when the button is clicked again. This storage method has a flaw, however, in that it would not be able to detect multiple clicks from the same IP (see below about Denial of Service).

Alternatively, a row can be created for each IP:

Article

IP Address

Date

This would allow for more fine-grained prevention of mass-clicking, but will be of significantly lower performance (collecting the tally alone, for instance). These logs would also grow very large very quickly, compared to the first option (which has a maximum size per day).

A third alternative is to zero out the tables entirely every day/week (and thus we only keep one unit's worth of logs, up until the rollup event). This is probably the smartest solution.

Possible Denial of Service

It is theoretically possible for a single IP user to hammer the "thank the authors" affordance and create hundreds if not thousands of "thanks" entries in the database. For this reason, the system should accept one and only one instance of a "thanks" event from a single IP for a single article (if the IP has thanked the authors for a specific article before, then that "thanks event" is discarded.)

Ideally, we would be able to disable the "Thanks" affordance if a reader has already provided thanks for the article; however, there is no simple way to do that (other than browser-local storage). Accordingly, simply ignoring additional thanks events may be the prudent solution.

Issues

A reader-focused interaction of this nature has several problems, mostly regarding scale and possibility of service denial. High traffic articles could likely produce tens or even hundreds of thousands of "thanks" events per-day and, if left unchecked, could make the encyclopedia unusable for many editors (see the section about "Rollups" for how this feature solves this problem).

Further, particularly controversial articles may engender hostility and harassment. Accordingly, readers will not be exposed to the usernames of the editors they are expressing gratitude towards. Obviously, committed trolls will be able to divine the names of these editors using analytics but this is already a problem and generally requires far, far more work and expertise than the average drive by troll is capable of producing.

Publication of rolled-up thanks lists may be problematic. At the time of this writing, the English Wikipedia had over 4 million articles. It is theoretically possible that four million distinct Echo notifications would be sent every evening. This could have a drastic impact on the event queues.

Editors - especially prolific ones - may find the thanks notifications intrusive or mechanical. This would necessitate the ability to disable this kind of notification.