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. [1] 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:

• Extension:Translate (not mentioned once) and interaction with it,
• bugzilla:1495,
• Language converter.

Taken from mwalker's m:Help:CentralNotice/Translations, which is still relevant. --Nemo 12:18, 15 September 2014 (UTC)

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. m: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)

Certainly it would be nice to have user input. But I don't think it is appropriate for centralnotice-admins to be allowed to choose any arbitrary tradeoff between convenience and security. The security impact of raw HTML editing threatens the whole site, not just the centralnotice-admins. -- Tim Starling (talk) 06:05, 24 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)

I am generally not a big fan of rewrites. I think there is less risk when you have two small projects than when you have one big project. Also, a lot of the code will stay the same, or nearly the same. For example, the list pages and campaign editing will presumably be retained, and the banner editing UI will mostly just be moved from a special page to a ContentHandler. Utility classes like Banner and Campaign will be able to present the same public interface, even if their implementation details are changed. The caching RFC mostly seems to affect Special:BannerLoader and bannerController.js. -- Tim Starling (talk) 05:36, 24 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)

I think splitting out reusable components and creation of synergies can be left for another project. I think it is best to limit project scope as far as possible, so that the project can get done and deployed in a minimum amount of time. This reduces risk and allows for more effective project prioritisation, since each independent subproject can be prioritised on its merits. In fact, the ContentHandler and MessageCache parts of this RFC could probably benefit from being done as separate projects. -- Tim Starling (talk) 05:53, 24 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 (some 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)

Wiki pages and not reinventing the wheel

From [2]:

[21:48:55] <Krinkle>	 TimStarling: Confession, I'm not a central notice admin, but I have sometimes edited banners in the MEdiaWiki namespace directly using my global editinterface right to address uncontroversial layout, security or performance issues in a banner.
[21:49:15] <K4-713>	 Krinkle: gah, really?
[21:49:47] <Krinkle>	 K4-713: I didn't know better at the time, couldn't figure the CentralNotice interface and didn't know how to search for the snipppet of html I found.
[21:50:04] <K4-713>	 Fair enough. :/

I was surprised by Katie's surprise. What's wrong with editing wiki pages? That's entirely normal and many if not most people who touched centralnotice banners (like sysops and bot-admins) worked that way. It's fine to revise namespaces/permissions and add some ContentHandler sugar coating but, please don't move stuff out of wiki pages.

Rather than reinventing the wheel, more interesting would be to use the core interfaces in more places, for instance Special:Log instead of the clumsy m:Special:CentralNoticeLogs. --Nemo 06:49, 25 September 2014 (UTC)

Notes following 2014-09-24 IRC meeting

I opened an Etherpad for some rough notes following September's meeting on IRC. -- AGreen (WMF) (talk) 18:00, 29 September 2014 (UTC)