CentralNotice/Usage guidelines

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

These are CentralNotice banner guidelines which explain current practices.

Goals[edit]

  1. Be as unobtrusive as possible.
  2. Be as narrowly tailored as necessary.
  3. Be consensus-driven and respect our principles.
  4. Have the CentralNotice not constantly in use, to avoid banner blindness as much as possible, and to leave some space to the local community.

Approval[edit]

There is no formal approval system for CentralNotices. Central notices, as local sitenotices, are used exclusively to promote initiatives of the Wikimedia movement: for instance, the WMF fundraising, notices from the projects' (local and global) editors, the biggest initiatives of the chapters and the community at large.

  • Fundraising banners are completely managed by the WMF staff (or by chapters staff if delegated by the WMF), which decides what to run, creates them and maintains them. The staff has only to respect some very generic principles. Nonetheless, for the sake of transparency, reports are published on Meta's fundraising pages.
  • Other kinds of banners which are routinely run don't need additional discussion to assume consensus. This includes for instance banners for Wikimania, steward elections, board elections, other general Wikimedia votes and surveys, maintenance notices.
  • Other banners usually need some sort of consensus before. The notice is proposed/announced/discussed in the projects which will be affected by it: the local notices discussion page if any (for instance MediaWiki talk:Sitenotice), another noticeboard or the village pump – whatever is most suitable to efficiently reach most interested users –; if multiple projects in the same language are affected, a single discussion on one of them might be enough to reach them. If the notice affects more projects, it's announced/discussed on Meta.
  • Some banners may involve further matters than the simple issue of whether the initiative is worth the occupation of some space on the projects, especially if they're a new sort of banners or "non super-core" initiatives of the Wikimedia movement only. This covers a large spectrum of cases, from the quite simple case of a national event which is a joint initiative of a Wikimedia organization and an "external" organization, to the very complex case of a project-wide protest or advocacy initiative. Depending on how potentially controversial the notice is, such additional issues should be discussed with the global community and with a bigger visibility, for instance on the Wikimedia Forum and wikimedia-l.

Implementation[edit]

  • Every central notice (or group of them) must be added on due time to the Calendar, which is the key tracking and coordination tool. It must also have a contact person/responsible who asks it on behalf of the promoters and defines its specifications, as follows. The calendar and calendar's talk can be used to refine specifications and, depending on the "importance", can also be enough of a discussion on the banner (as defined above).
    • "Coordination" means also that because there can be only one global campaign at a time (or at least only one at full load), and we can't permanently have global campaigns running, there will/can be some adjustment by reducing campaigns' length or broadness.
  • The banner coder has to write it as needed, not overlooking in particular that the banner
    • must:
      • have a start and end date,
      • target projects as actually needed and absolutely without slips/takeovers (for instance, don't show a "Wikipedia" banner on non-Wikipedia projects),
      • target only needed languages and avoid showing banners in languages different from the users' if at all possible (e.g. English banners for anonymous users on non-English projects or for non-English UI logged in users);
    • should consider carefully how broad the campaign needs to be (to respect goals 1 and 2), using the broadest campaigns only when needed, targeting only users with whom the "success rate" of the campaign will be highest and in short avoid shooting a fly with a cannon, in particular with regard to:
      • user type targeting (anonymous users, logged-in users, both),
      • geotargeting (for instance targeting only users of the region where an event is going to happen, even if national, if casual readers are likely to participate only if near, as they usually are),
      • size and visibility of banners, the standard being banners like this, this or at most this,
      • load of the banner, considering the possibility to show the blank banner (for instance 50:50, hence reducing by 50 % the number of impressions),
      • for registered users, targeting only the most relevant ones, using metrics like edit count on the local project (global edit count not currently available), time since registration, user groups, as in Central notice admin: Banner: stew2012 noms, Central notice admin: Banner: stew2012 vote, or at a more advanced level, Central notice admin: Banner: HSP final (still to be polished and documented).
    • If the banner code/style uses external resource, it must be protocol relative (not http) for security reasons.
  • A Meta administrator will actually implement and enable the banner, checking that it works, it respects guidelines, practices, consensus etc., applying the commons sense he or she is bound to have and so filling the gaps of this non-formalised process.

Note that these three persons can actually be a single user, obviously; the coder and most of all the implementing admin can be searched by the promoter with a simple request if needed.

See also[edit]