Extension:CentralNotice/Phase 2

Feature justification
Central notice is meant to be a global messaging system for WMF but lacks a number of key features that other systems provide.


 * Geo located banners
 * Admin log of changes
 * Relative percentages

User requirements

 * Ability to deliver banners by country and eventually by city.
 * An easy way to understand what work has been done in the system through an admin log
 * An easy way to understand the current state of the system and what the relative % of impressions any one banner might have

GeoIP
Using the internal Wikimedia GeoIP service serve the currently enabled campaign. We would need the ability to lazy load the banner possibly in an iframe.

Admin Log
The Admin log at a minimum would have to display


 * Campaign enabled/disable, date changes, preferred changes, deletions
 * Banner ads/deletes
 * New campaigns
 * Slot assignments.

Relative %'s
We would need a simple way for a user to understand the actual amount of views any banner might actually get. This would require knowledge of what campaigns are running and calculating the actual display % of the configured banners.

Software design document
In order to support geo functionality and the features in phase 3 were going to need to re-architect the loading mechanism for Central Notice. Instead of the current one request pulls all banner method were going to two move to a two stage loader.

When a visitor requesta a Wikimedia project page they will issue a request to the central notice extension and be given back a small amount of js that will act as a controller. This controller will issue a request to the new loader and will receive back a simplified list of banners that they could show along with their weights. In parallel the client will contact our geoip service to figure out its location and if any national level banners should be shown. Once the banner list is complete the client will pick one banner based on weights and will only retrieve the js for it.

This is a large departure from our previous architecture and will break backwards compatibility with our previous loader. While it will increase the number of requests on every Wikimedia project page it will lessen the page request size as we will no longer be serving back banner content for a banner that will never be shown.

Test plan
We'll be able to do limited testing on tesla and test wiki to see how well the GeoIP functionality works. Testing the new loader is difficult as the current Wikimedia architecture can't do an a/b test per extension with a % of web traffic. We'll be heavily leaning on our staging and dev servers to do all of our functional tests.

GeoIP and new Loader

 * Code Review: 9/13-9/14
 * Fixes, Testing, Production Staging: 9/14-9/15
 * Production Test: 9/16 (late afternoon PST)

Task management
(e.g. link to relevant Bugzilla queries)