Wikimedia Meta-Wiki

CentralNotice/Usage guidelines/eo

< CentralNotice
This page is a translated version of the page CentralNotice/Usage guidelines and the translation is 7% complete.
Outdated translations are marked like this.
Other languages:

Celoj

  1. Be as unobtrusive as possible.
  2. Be as narrowly tailored as necessary.
  3. Be consensus-driven and respect our principles.
  4. Avoid constant use, to prevent banner blindness as much as possible, and to leave some space to the local community.

Aprobo

  • You must submit any campaign request at least 14 days in advance on the Meta request page. If you request a banner with less than 14 days’ notice, Admins may push the start date to allow for the full 14 days, depending on the Admin’s decision.
  • Last-minute requests will likely not be approved and sometimes the Admin backlog will extend beyond 14 days, so please plan ahead.
  • Campaigns should run for a maximum of two weeks to avoid banner fatigue unless a specific community consensus exists for a longer run.
  • Campaigns should show a clear reason for the need to reach a wide audience through Central Notice. This means that the organizer/requester must show that the users who see their banner can participate in the action prompted by the banner (or would otherwise be interested in it).
    • Central Notice banners are not the best tool for many editing campaigns or events. You should look into other options including but not limited to — Mass Message, communication via off-wiki channels like mailing lists or chat groups, social media communication, etc. Consider trying Invitation List if you are looking for experienced editors. If you need additional help designing a communication strategy consider contacting campaigns@wikimedia.org.
  • For new campaigns (those that haven’t used Central Notice before), you need to get approval from the relevant community before submitting a request. It can also be helpful to get input from relevant affiliates. If you’re unsure if this kind of campaign has been done on the target wiki, reach out to that wiki’s community first and establish consensus before making your request. Consensus can be made on a location like the Village Pump.
    • Obtaining consensus from local communitiesis necessary. Exceptions include global movement governance processes (e.g., stewards, U4C, Board elections), community conventions (e.g., Wikimania, WikiIndaba, WikiCon), and long-established campaigns.
  • Use the Central Notice calendar to avoid overlap and mediate requests for the same “slot” on a given wiki, geography, or language, but make sure that all information is also available in the banner request. Please double-check if there is a fundraising banner will be run during the proposed time (see the section below on Fundraising Banners for further contact information.

Postuloj pri rubandoj

Custom Banner Code, Design and Styling

The following are guidelines for custom banners. You can choose to use the standard banner format see here, but if you want customization we need the following:

  • Banners must ensure responsiveness, consistent appearance, and accessibility across devices (especially mobile devices). Banners are made with HTML and CSS, not Wikitext.
  • Keep images as small as possible (around 250 KB) to accommodate users with limited bandwidth, especially on mobile.
    • When embedding images, it is mandatory to use images with a file size no larger than required.
    • For specific cases like “Picture of the Year”, slightly larger images might be acceptable, but the general guideline is to reduce file size as much as possible. Admins may remove images if they disrupt readability on mobile devices.
  • When possible, use icons or graphics instead of images to improve banner readability, reduce visual complexity, and minimize layout disruptions, particularly on mobile devices.
  • Prioritize design quality over specific orientation and ensure that files work well within the banner’s layout.
  • Central Notice Admins can make adjustments to improve how banners look and function on mobile devices, especially for people who aren’t logged in. This helps ensure that banners are user-friendly for everyone, no matter what device they’re using.
  • Central Notice admins may provide guidance, feedback, and basic troubleshooting for banner code issues, especially for users with limited coding experience depending on the availability of the Admins. However, Admins are not expected to build or fully code banners for you.
    • Please be aware that you are responsible for testing custom banners on all devices you are requesting (desktop, mobile, etc.)!
  • We recommend that all banner designs ensure compatibility with dark mode. See here.
  • We recommend that you avoid overly distracting designs; banners should be unobtrusive, and consistent with Wikimedia sites’ usual style.
  • Caution is advised when using images of people due to privacy and cultural sensitivities.
  • The text of the banner should be submitted in the language of the target wiki(s). If the banner contains minimal text in an international language used widely for translation (i. e., UN languages like English, French, Spanish, Arabic, Chinese, etc.), prepared translations may not be required but only a note added to the banner text that translations are welcome. Consult CN admins if unsure.
  • We recommend the banner text:
    • Focus on the activity described.
    • Not promise anything that could be misinterpreted (e.g., promise monetary prizes).
  • Banners should invite and activate potential participants to learn more about the activities described on the landing page.
  • Organizers should be prepared to translate the banners. These translations can be provided to ensure clarity for the target audience.
    • To provide translations with Content Translation the banner text in English is needed as the source. Please use simple and clear International English

Landing Page Requirements

Landing pages on Wikimedia wikis should be designed using the following guidelines:

  • The landing page must provide sufficient instructions for the target audience to meaningfully participate in the call to action on the page. For events we strongly recommend using a registration strategy, like that provided by Event Registration.
  • If your landing page expects participants to edit Wikimedia projects, actions should:
    • Be simple and repeatable with instructions for newcomers, especially for campaigns targeting readers. Examples of simple, repeatable tasks include uploading photos, adding citations, or contributing to Wikiquote. These do not include complex improvements to Wikipedia pages, article translation, or creating new pages.
    • Only include more complex instructions for participation or behaviors for registered and/or more experienced users; contribution instructions or learning materials need to be clear and in the target language.
  • Requestees should be able to track the efficacy of the campaign (using landing page pageviews and evidence of participation, such as EventRegistration). Admins reserve the right to limit or turn off ineffective campaigns or campaigns where participants are little responsive or barely interact with the banner.
  • Landing pages should preferably be available in all languages the campaign intends to target. For that purpose, the landing page has to be marked as translatable. Translations should be ready in the main languages of the campaign and the banner should make clear that translations of the landing page are welcome, especially for smaller language communities.

Policies for Affiliates and WMF Staff

Affiliates and WMF Staff should adhere to the following:

  • Community campaigns are given priority for banner visibility and frequency, while affiliate-generated campaigns should generally have a lower display frequency to ensure fairness.
    • Community campaigns should be prioritized and given “right of way” over affiliate-generated campaigns when there is scheduling overlap. If there is clear community support for a campaign requested by an affiliate, it should be treated as a community-driven campaign, which may take priority over other affiliate requests.
    • Ideally, affiliates and community groups should negotiate campaign timing and priorities among themselves. However, if no consensus is reached, Central Notice admins may need to mediate.
  • Banners requested by Affiliates or WMF staff are subject to the same approval process as banners from unaffiliated community members. This means, among other things, that they too must be requested, or proposed for discussion through the creation of a request page, at least 14 days in advance and require community and volunteer CentralNotice admin approval. For fundraising campaigns, see the extra section.
    • Programmatic banners don’t have automatic approval in all cases, and should consult Central Notice community admins when working on a new topic, theme or call to action. A request for a new programmatic banner will be reviewed by volunteer administrators as appropriate, before requesting the organization to configure the campaign.
  • Affiliates and WMF should avoid submitting multiple campaign requests simultaneously to minimize overlap with community-led campaigns.
    • Affiliates and the Foundation are encouraged to prioritize one request at a time, particularly for large or complex organizations (like WMF, WMDE or WMFR) that frequently propose campaigns.
  • We recommend that affiliates or Wikimedia Foundation teams that run more than 2 banners a year, have a Central Notice Admin on staff for organizational requirements.

Special Kind of Banners

Fundraising

Banners for fundraising need to be brought to the attention of the Wikimedia Foundation at least 90 days before the intended schedule for running the banner and require approval from the Wikimedia Foundation in all instances. For these please contact Julia Brungs or the Fundraising Team at the Wikimedia Foundation.

  • Online fundraising banners are managed by the Wikimedia Foundation. The Foundation reaches out to local affiliates to coordinate the timing of these campaigns in most countries (except for the US, UK, Canada, Ireland, New Zealand, and Australia) about 3-5 months before the campaign. Changes to the fundraising schedule can be discussed with the team at the Foundation. The Foundation also involves most communities in their fundraising through dedicated, language-specific, community collaboration pages.
  • Online fundraising banners and tax campaigns run by affiliates have to be approved through a legal agreement with the Wikimedia Foundation. They then do not need any extra approval from CN admins.
  • The Wikimedia Foundation and affiliates who run fundraising or tax deductibility campaigns have their own staff responsible for the CN campaigns and banners and don’t need CN admin support.
  • The Wikimedia Foundation and affiliates who run fundraising or tax deductibility campaigns must adhere to the Wikimedia Foundation Fundraising Principles.
Surveys

Banners for external surveys should be discussed for at least 90 days and require approval from the Wikimedia Foundation in all instances. For surveys, please ping Tanja Andic in your CentralNotice survey request.

What do we mean by “survey”?

Surveys in this definition are any information gathering that requires people to input information into an external, non-public form which leaves Wikimedia servers, such as Google Forms, LimeSurvey, Qualtrics, or others. This is inclusive of research purposes or other kinds of data collection activities.


Is Central Notice the right tool?

Most surveys do not need a Central Notice Banner: consider other communication channels such as user talkpages, user email, mailing lists, social media, appropriate notice boards/talk pages, and village pumps BEFORE any CentralNotice campaign. Central Notice is a powerful tool for reaching large groups of survey respondents – that is, potentially tens or even hundreds of thousands of people. We should use it rarely and only when it makes sense to do so. That is to say, not all surveys are meant to be taken by “everyone”. Before considering Central Notice for your survey distribution, consider a few questions:

  • Do the questions in your survey apply to “everyone” or are they meant for a more specific group of people (users of a certain tool, participants in a specific campaign) who could be better reached through listservs, talk pages, or social media channels?
  • Do you have a well-considered plan for how you will use every piece of the data you collect?
  • Sometimes when we write survey questions, we’re so immersed in our own focus area that we aren’t always able to think about how other people will understand the questions. Have you tested your survey to make sure the questions make sense to a broader group?

Some examples of good use cases for Central Notice surveys:

  • Researchers want to collect responses from a random sample of editors or readers to help make population estimates on a project in order to better understand and share knowledge about these groups.
  • An affiliate wants to better understand the needs of editors in their country, to be able to develop programs that target these needs. They want to target a random sample of editors based in this country to give them an estimate of the needs for the general population.
  • A user group wants to recruit participants for a project that teaches readers how to edit. They want to recruit interested readers from a specific location and language community through a survey to do so.


How are surveys approved?

Tanja Andic is the current reviewer for surveys.

Reviewers are particularly looking for the impact of the survey, the quality of the survey, whether it collects Personally Identifiable Information (PII), and how the people collecting the data will treat this PII data. Some examples of PII are:

  • IP addresses
  • Emails
  • Usernames or real names
  • Demographic information (such as age, gender, education level, country, nationality, and others)


Linking to surveys

Like other banners, banners for surveys need to link to a landing page on a Wikimedia server such as Metawiki, the wiki you are collecting data on, or an Affiliate website, rather than going directly to the survey. Before respondents leave the Wikimedia servers, we want to ensure that they:

  • Are aware of what survey project they are participating in.
  • Know how their data will be used.
  • Know they will be leaving Wikimedia servers.
  • Have a page to return to where they can contact the people or affiliates running the survey.
  • Have a privacy statement to refer to and have links to the policies of the external survey software being used. Privacy statements should be written by the researcher or Affiliate, and available on the landing page.
    • Please note: you are legally responsible for the data you collect, including holding yourself to the standards you set in your privacy statement.
  • You can provide direct links to surveys under circumstances, where the privacy policy is advertised clearly alongside documentation of the process in a multilink banner.


I need help with my survey!

Affiliates can request help with their surveys from the Wikimedia Foundation. Please contact surveys@wikimedia.org to schedule an appointment, and include all relevant information in the email. We will need at least 3 weeks of notice to help with your survey to make sure we have time to coordinate. If you don’t receive a response in a working day or two, please feel welcome to message again – it’s possible we missed it!


Making a survey request:

When making a Central Notice survey request, please include the following information (and delete irrelevant information) in a comment to make it easy to review your survey:

What type of survey is this?

  • I want to gather contacts for a campaign, event, or affiliate project.
  • I want to gather representative data about a population of readers or editors for research purposes or to inform strategy in my affiliate.
  • Other type (please specify):


How many responses do you hope to get?

(“As many as possible” is usually not a good answer, as this can mean hundreds of thousands depending on the case and can crash your survey tool server; typically a few hundred is enough for most surveys).

Which populations should the survey banner be displayed to?

  • Logged-in users (“editors”).
  • Not logged-in users (“readers”).
  • Specific criteria:


Which wikis and countries will the banner display to?

Will you be collecting any of these types of data?

  • IP addresses
  • Emails
  • Usernames or real names
  • Demographic information (such as age, gender, education level, country, nationality, and others)


Please note: all demographic questions should be optional. We recommend putting demographic questions at the end of your survey, with a specific note that says all responses to these questions are optional. Likewise, there are special legal protections for respondents under the age of 18 in most countries. If you are asking demographic questions, please ensure you have a way to filter out respondents who are less than 18 years old (or whatever the legal age is for your specific country or countries) from being asked personal questions.

How will you publish or share your data?

  • It will only be used internally.
  • We will publish aggregate anonymous data in a report.
  • We plan to publish the raw dataset.
  • Some other way: (please explain).

Link to your project page (where the survey will be linked and respondents can find out more about the project):

Link to your privacy statement** (it can be on the same page as the project page):

Link to the survey:


Vidu ankaŭ

Retrieved from "https://meta.wikimedia.org/w/index.php?title=CentralNotice/Usage_guidelines/eo&oldid=27836698"