Talk:Requests for comment/CentralNotice backend improvements

Great to see some thinking about this important part of our infrastructure, thanks Tim! Why CNBanner instead of just Banner? Namespaces show up in a lot of places so that seems unnecessarily implementation-focused.--Erik Moeller (WMF) (talk) 07:35, 12 September 2014 (UTC)


 * Just because it exists already. I guess if we extend it to other wikis then that will be a good time to rethink the name. -- Tim Starling (talk)

Suspiciously missing
Some points are surprisingly not touched at all: Taken from mwalker's m:Help:CentralNotice/Translations, which is still relevant. --Nemo 12:18, 15 September 2014 (UTC)
 * Extension:Translate (not mentioned once) and interaction with it,
 * 1495,
 * Language converter.

Community concerns
Thank you Tim for this wonderfully thorough, independent review! I'm relieved to see a public discussion beginning, the poor Fundraising crew have been moaning into our cupboards for too long now ;)

Complete agreement on your points so far, one more concern to make explicit is that high-impact changes to things like how banner JS can be edited must be negotiated with the community. For convenience, we have a centralnotice-admins@lists.wikimedia.org mailing list, I believe all centralnotice-admin users are subscribed.

However... that still might not include all the involved parties: I recently learned that metawiki site admins can edit banner content through a side door, without specific CN privileges. I don't know yet how often that happens.

While we're rapidly expanding scope, it would be worth mentioning the page load hit, even when no banner is displayed. Some improvements include, 1) We could back down a bit from our aggressive approach to delivering impressions on the first pageview of a session. 2) If we reduce the complexity of rules for targeting banners to viewers, lots of other efficiencies become achievable, such as eliminating the DNS lookup to metawiki, and eventually edge side inclusion.

Adamw (talk) 07:04, 19 September 2014 (UTC)


 * On your question: most banners are managed by Meta-Wiki sysops and requests handled on m:WM:RFH. CentralNotice/Usage guidelines was written by a Meta-Wiki sysop, too.
 * As long as this RfC is titled "CentralNotice backend improvements", I'd personally expect it not to change anything user-visible. As you mention, plenty of work is possible: Requests for comment/CentralNotice Caching Overhaul - Frontend Proxy is looking for a main author/point of contact, is it the best resource available on that side of things? --Nemo 07:19, 19 September 2014 (UTC)
 * I agreed to help with that RfC; I hope we can pool efforts. :) There was some relevant discussion on that RfC at the meeting on July 30. AGreen (WMF) (talk) 17:13, 23 September 2014 (UTC)

Scope and methodology
Fantastic, really great to see this!! I think the first things to consider are scope and methodology. I'd suggest that we...


 * combine all CentralNotice work, includng the caching RfC, into a single, concerted effort and, eventually, a single roadmap;
 * start by scoping out the requirements on all levels and for all stakeholders;
 * not dive deeply into minute implementation details right away (though a lot of proposals here and in the caching RfC do sound great); and
 * ensure we have sufficient resources to follow through.

If almost every part of CentralNotice will undergo big changes, are we looking at a complete rewrite? The current codebase is not huge—less then 11 000 lines, according to cloc. (Full disclosure: I have a thing for rewrites.)

--AGreen (WMF) (talk) 16:39, 23 September 2014 (UTC)

Additional general considerations

 * Deployment of new code will have to be super-smooth (the caching RfC has more on this).
 * I think would be fantastic if we could have participation, input and buy-in from the broader community throughout the process (echoing Adam's concern here).
 * It might also be nice if we could redesign CentralNotice as a set of modular compontents, some of which might be re-usable. (For example, maybe, general mechanisms for the dynamic injection of UI components, device detection and A/B tests?)
 * We should try to create synergies with other work on the Mediawiki codebase, like the move to a service-oriented architecture.

--AGreen (WMF) (talk) 16:39, 23 September 2014 (UTC)

More problems and needs rundown

 * The overall impact of banners on site performance and bandwidth (relevant to the message caching issue discussed here, targeted by the caching RfC, also mentioned above.)
 * The codebase was not designed for the current number of banners and campaigns.
 * The codebase has a few sketchy bits (i.e., inconsistent terminology, code needing refactoring, and quick fixes that remain in place).
 * Domain model issues (for example, geo/lang/project targeting is attached to campaigns, but device targeting is linked to banners).
 * The recording of banner impressions could be migrated to EventLogging (mentioned in caching RfC).
 * The campaign and banner administration UIs could be improved with regard to usability and the data provided about campaign and banner allocations.
 * Analytics needs/like-to-haves: full banner impression datasets, integration with other data from EventLogging, longer A/B tests and guarantees about A/B test isolation.

--AGreen (WMF) (talk) 16:39, 23 September 2014 (UTC)

Stakeholders
Just thought it would be fun to try to list the stakeholders for this software:
 * Fundraising
 * Analytics
 * CentralNotice admins
 * Meta admins and local sysops
 * Everyone (site performance, donations, community-process-related notices, and other current and future uses of notices)

--AGreen (WMF) (talk) 16:39, 23 September 2014 (UTC)