Issue: Clear description of new process
Given the move to more geography specific usage of central notice, it's rare for campaigns to get approval by the wiki's targeted. A transparent process to enable community members a process through which they can comment would be useful. It would also enable there to be a clearer location for requests for campaigns as well as peer review amoungst the central notice and meta administrators.
Issue: Clearer guidelines on campaigns setups
Over the years there are various accepted practices and usages of central notice. Percentage of traffic, number of impressions, length of campaigns. Documenting these to encourage consistency would be better.
Issue 1:Majorly Out of Date
Some of this page is based on banners from 8 years ago. Information is also split on a to separate page.
Proposed Solution: New documentation
Unify documentation and bring it fully up date about the technical workings of central notice.
Issue 2: Lack of suitable templates
Reusing previous banners is a long and accepted custom. Generally speaking this is a fine practice but it generally involves a degree of knowledge of previous banners. The search function is useful but it can result in the use of an old banner.
Proposed Solution: Banner Catalogue
Ideally there should be a catalogue of community banners specifically for reuse. Partly for ease of finding the right info and partly for maintenance.
Issue 3: Lack of design/campaign support
Currently there is little formal support for our community campaigns. Although not to replace the efforts of community members, it should be the role of the WMF to provide such capacity to the online communities if needed.
Proposed resolution:Clearly define the role of the Wikimedia Foundation
I would love to try to and use some of the resources that we already have to hand within movement and particularly at the foundation to support community campaigns. Both from the more traditional comms role that the WMF has played but also design aspects, from Communications and from Trilogy, the external consultants who support the Wikimedia Foundation with our Fundraising Campaigns.
Similarly we should make it clear where community members can get assistance for building campaigns and I think part of this will come from creating a more formal process for requesting campaigns. Similarly ensuring that there is a dedicated point contact at the Wikimedia Foundation for questions relating to Central Notice and it's usage.
Issue 4: Documentation incomplete
The translation extension utilised within Central Notice does not perform in necessarily a way consistent with it's implementation elsewhere on meta.
Proposed Resolution: Update and improve
There are a number of issues documented on Phabricator relating to the extension and CN. How these affect the expected behaviours should be properly documented. In addition some issues relating to the translate extension should be prioritised.
Issue 5: No visualisation of campaign timelines
- Currently the calendar consists of a wiki table.
- No visualisation of campaigns. Difficult to identify overlapping campaigns.
Proposed Solution: Integration of a Calendar into Central Notice
Phabricator Ticket: T35650
- Several Calendar extensions currently exist with which to build this function on: 
Issue 6: Cannot run overlapping campaigns with different mixins
One of the most limiting factors and a source of much frustration is overlapping campaigns. This is compounded by the fact that once one campaign has finished delivering a specified number of impressions, there is no way to fall back to another campaign.
Proposed Solution: Enable Campaign Fallback
Phabricator Ticket: T124969
- After a campaign has delivered a set number of impressions, it will fall back to a lower priority campaign
Issue 7: Lack of Publicly Available Statistics
Currently, to produce banner statistics for community campaigns, it requires a member of WMF staff to run queries.
Proposed Solution: Create Analytics API/Dashboard
Phabricator Ticket: T115042
- One key feature is to enable access to statistics for community campaigns
Issue 8: Translations & Central Notice
T116235 Covers many of the current issues surrounding translation and banners and some of these should be prioritsed.
Proposed Solution: Prioritisation of tickets
Replace with a dedicated request process
- 7 Day Request Period
- Details of Campaign
- Banner Mock Up image provided by requester or created by CN admins
- Allows public feedback
- Combined with usage guidelines to review campaigns
- If campaign is requested by a Central Notice admin then peer review occurs.
Issue 9: It's a wikitable
See Issue 5
Realistically this should be replaced and integrated into central notice. It is clunky, based in wikitext, manual, not necessarily always complete and a pain to track. The timeline currently in use there is more a proof of concept than something functional for the long term (since it simply conflates the existing issue of manual updating etc.)
Proposed Resolution: Several options...
At a minimum we should:
- Manually link from calendar to both campaign and approved requests.
As a middle ground we should look into seeing if:
- a python script could be written to be run to update requests either semi-automatically or automatically
- integrating the calendar into the central notice interface would be great.
- Complete integration between the request process, calendar and CN interface
Issue 10 - Review only
This is a useful tool but presently no way of watchlisting campaigns.
Proposed Resolution - Enable+ alerts? Potentially through echo?
I would love to see some sort of push alerts for central notice through echo
A makeshift solution would be a recent changes feed on IRC. That would do the trick.
No real issues here but might be useful to expand and incorporate links into outcomes of Issue 2 and Issue 3. Look through recent banners and explore room for expansion.