Article feedback/Public Policy Pilot/Technical

API
The following API calls will be used with

getCumulativeResults
invoked by  where pageid is the page ID and revid is the revision ID of the desired page

This will return a cached result in an object nested like so  Where 1-4 are the indicies for the dimensions of the review, avg is the average for that dimension, and total is the total number of reviews

setUserVals
invoked by where reviewcookie is the unique identifier for this user in the review system, authcookie is a cookie to match against the server to avoid CXRF, pageid is the page ID, revid is the revision ID of the desired page, and djsonRevObj is a review object in JSON of the following: where val are the values the user has assigned

Database
The data stored will be in the following tables:

article_assessment
Will hold 1 entry per user per revision, namely: Where m1...mn are the dimensions we're measuring (completeness, npov, etc)


 * Known Issue/Open Question: We are assuming that optimal performance may be achieved by using one column per "question".  However, it may be that we wish to have one row per answer (so each submit click results in four rows instead of one).  This is something of lesser concern for the pilot but will be of great concern if/when this feature is rolled out on a higher profile basis.

article_assessment_pages
Will hold 1 entry per page revision per dimension we're measuring, namely: Where dimension refers to the dimension that's being measured (1 = completeness, etc)

Assumptions

 * previous user ratings will be stored in a cookie on the user's browser. All that needs to be stored is [pgid, revid, dimension, rating] but only for the last revision that has been given
 * the page's pageid and current revid need to be visible to JS as variables
 * Historical information will be retained per user per article. That is:  if a user rates a given article 5 times on 5 different revisions, all 5 ratings will be stored to facilitate "over time" statistical analysis.
 * Note that if the user re-rates the same revision, the data will be an update and not an insert. So if the user rates a given article 6 times on 5 revisions, only 5 entries will be stored.

Limitations

 * Any user who uses a different browser or clears their cookies will be seen by the system as having a different browser
 * After the user hits the maximum number of reviewable pages, they won't be able to see their ratings for the first reviewed page
 * We need to limit the MWHooks to 1 call so that code only gets injected when it is a page that has AA enabled for it, and this comparison only needs to be made once

Open Issues

 * Cache invalidating - On every new rating, the cached version of this page will have to be invalidated.
 * We mark pages as invalid after an edit, short-term solution is to do this
 * Long-term solution is to get the ratings info from an API call that has cache-able resources


 * Only to appear on select pages
 * Short-term solution is to have a configurable list of page titles or IDs that this extension will be visible on, and optimize to exit out if the page is not among these
 * Long-term solution not necessary as this will be on all pages long-term