CentralNotice/Process Review
Issue: Clear description of new process
editGiven 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
editOver 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
editSome of this page is based on banners from 8 years ago. Information is also split on a to separate page.
Proposed Solution: New documentation
editUnify documentation and bring it fully up date about the technical workings of central notice.
Issue 2: Lack of suitable templates
editReusing 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
editIdeally 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
editCurrently 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
editI 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
editThe 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
editThere 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
edit- 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
editPhabricator Ticket: T35650
- Several Calendar extensions currently exist with which to build this function on: [1]
Issue 6: Cannot run overlapping campaigns with different mixins
editOne 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
editPhabricator 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
editCurrently, to produce banner statistics for community campaigns, it requires a member of WMF staff to run queries.
Proposed Solution: Create Analytics API/Dashboard
editPhabricator Ticket: T115042
Related:
- T124132
- T88744
- T122589
- T120997
- One key feature is to enable access to statistics for community campaigns
Issue 8: Translations & Central Notice
editT116235 Covers many of the current issues surrounding translation and banners and some of these should be prioritsed.
Proposed Solution: Prioritisation of tickets
editReplace with a dedicated request process
edit- 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
editSee 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...
editAt 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.
Ideally:
- Complete integration between the request process, calendar and CN interface
Issue 10 - Review only
editThis is a useful tool but presently no way of watchlisting campaigns.
Proposed Resolution - Enable+ alerts? Potentially through echo?
editI 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.