Media Rating System Implementation Plan edit

Overview edit

Users are requesting a rating mechanism with which they can rate the media files based on artistic merit and usefulness to Wikimedia projects. Below, a system is proposed which will allow users to rate the files on a scale from 1 – 10, and a system for displaying information about the votes.

Timeline edit

1)Discovery and Discussion Process for Stakeholders / Request for Comments.

2)Consensus Building / Plan Finalization.

3)Coding / Database Implementation.

4)Quality Assurance (Unstable Branch).

5)Staging (Testing Branch).

6)Deployment to Organizational Servers.

Discovery and Discussion Process for Stakeholders / Request for Comments edit

Stakeholders in the MediaWiki software are invited to comment on this document, and this document will serve as a starting point for the discussion regarding this feature. Important stakeholders include: MediaWiki leadership, the Operations team (as appropriate if it is decided that this feature should fast tracked for release rather than rolled into a larger upgrade), previous MediaWiki code contributors, the users of MediaWiki, both organizationally as well as end users.

Consensus Building / Plan Finalization edit

At a point in the near future (first issue to be decided in the discussion), the plan will be finalized and implementation will begin.

The feature is proposed to have a simple moderation interface, in which each image has a drop down menu (with the numbers 1 - 10), a link that says "Vote!", and the words "Average Rating:" followed by the average rating.

For example:

 

DROPDOWN (Vote! or Change Vote!) - Average Rating: RATING - Number of Votes: VOTES

Coding / Database Implementation edit

Database changes will be made on a development server. The database changes will include:

A many to many join table between the user and image tables, with 3 columns.

Votes Table:

user_id INTEGER(5) INDEX

vote INTEGER(2)

img_name VARCHAR(255) PRIMARY INDEX

Modifications to the mediawiki codebase will be made on a development server. These changes will be made to the image retrieval code and include:

The following algorithm:

1) Run the following SQL query: "SELECT AVERAGE(vote), COUNT(*) FROM `Votes` WHERE `img_name` = Image name here"

2) Run the following SQL query: "SELECT vote FROM `Votes` WHERE `user_id` = User Id here"

3) Display the average vote under the image

4) If the user has a vote in the table, initialize the dropdown menu with their vote. If not, have the dropdown blank.

5) If the user has a vote in the table, display the words "Change Vote". If the user does not, display the word "Vote!". Display the words: "Average Rating:" followed by the average retrieved in step 1. Display the words "Number of Votes:" followed by the count retrieved in step 1.

Once modifications to the database schema and codebase are complete and nominally bug free (ie work for the developers), they will be committed to the unstable branch.

Quality Assurance edit

The feature will then be stress and security tested on the development server. Once it is found to be bug free, it will be committed to the Testing branch of svn. It will then wait for a period of time for stakeholders to comment on the new feature. If changes are necessary, return to the Coding / Implementation stage will occur. If changes are not necessary, the feature will then be committed to a release branch of svn.

Staging edit

Two possible paths are possible here. If it is agreed that the feature should be fast tracked for usage and there are no plans to upgrade the production version of the codebase soon, the feature will be separately testing in the mediawiki staging environment. However, it is more likely that the change will be incorporated into an already planned upgrade, and tested as part of a larger set of features. Input from the Operations team and other stakeholders is desired here.

Deployment edit

The Operations team will then deploy the feature (likely along with several other features as part of a general upgrade) to the live site. Special care, as always, will be made to ensure continuity of service.

Risks / Limitations edit

As with any new feature, there are several possible risks associated with this addition. Any additional features of course create the risk of additional security holes, as well as possibilities for data loss or mistakes during the upgrade process. However, this feature has several other unique risks / limitations:

1) Users may be able to "game" this feature by registering many accounts and voting repeatedly for a piece of media (or other strategies). While there are various mechanisms for detecting this kind of behaviour, this introduces a game of cat and mouse between developers and users.

2) Even if the users are generally not abusive of the feature, a numerical rating system is rather simplistic for something as subjective as much art. Different pieces of media may have different reasons why they are good or bad, or be particularly good at one thing but bad at another (a painting by Matisse, for example, is likely to be very appropriate for an art history page, while totally useless for a page on modern science fiction).

3) Assuming users are not abusive and the ratings are accurate, this feature could still benefit from further improvements. Examples could include ways to browse all media by rating, independent of which pages they appear on, or ways to retrieve a list of all media that users have voted for. Please discuss below these enhancements.

Discussion edit

Please put your discussion threads here.