Jump to content

中央管理通知/使い方のガイドライン

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page CentralNotice/Usage guidelines and the translation is 24% complete.

目標

  1. できるだけ控えめに。
  2. できるだけ空間を取らないように短く。
  3. consensusに立脚してウィキメディア運動の基本方針を尊重すること。
  4. できるだけ掲出の回数を減らしてbanner blindnessを予防し、ローカルのコミュニティがバナーを出す期間を残すこと。

承認

  • 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).
    • You should look into other options including but not limited to

多くの編集キャンペーンやイベントの告知ツールとして、一斉通知バナーは必ずしも最適ではありません。他の選択肢もぜひご検討いただき — これには大量メッセージ、メーリングリストチャットグループなどウィキ外のグループ他のチャンネルを介した広報連絡、SNSの発信などが含まれますが、これらに限定されるわけではありません。経験豊富な編集者に手伝ってもらいたい場合は、招待リストを検討してください。広報連絡の戦略設計にもっと支援が必要な場合は、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 communities is necessary. Exceptions include global movement governance processes (e.g., stewards, U4C, Board elections), community conventions (e.g., Wikimania, WikiIndaba, WikiCon), and long-established campaigns.
  • 一斉通知カレンダーの同一の「枠」を使って(Central Notice calendar)、特定のウィキや地理的範囲や言語で他との重複を避けたり、申請の調整を行いますが、バナー申請にもすべての情報を記載してあるか確認してください。提案された時間枠に実際に募金バナーが掲載されるかどうか、再確認してください(連絡先情報の詳細は、以下の見出し「募金」(Fundraising)バナーを参照してください)。

バナーの要件

Banners need to follow the following standards:

  • Freely Licensed Content — All banner content including text, and images must be free to use under a free license.
  • ウィキメディアの各種ドメイン限定 — バナーのリンクは提携団体もしくはウィキメディア財団が管理するウェブサイトに限定すべきで、公認されたアンケートを使う場合を例外とします(以下を参照)。営利団体所有の商標を含めてはいけません。
  • No External Resources — All banner resources (code or images) must be sourced from a wiki hosted by the Wikimedia Foundation. The link target must provide guarantees equal to or stricter than the privacy policy.
  • Secure Links — All links in CentralNotice banners must use HTTPS connections.
  • 自分のロゴを持ち寄ろう — 自作のバナーを使いたい場合は、送信する申請に(バナーの設計図やデザイン画ではなく)完成版バナーのコードを添付しなければなりません(自作バナーを作るとき以下のガイドラインは必見です)。バナーの標準書式をリクエストして取り寄せてください。この書式に添付できるのはロゴや画像、アイコンを合わせて2件以内、(右と左、正方形)、特定の1ページへのリンクを共有し、また解説文は最大1–2文で構成し文字上限は50–70ワードとします。テキストできます。テキストは簡単に翻訳できる必要があります。その文は編集しやすいように書いてください。
  • Code Review for Experimental Banners — If you plan to use other tools to run a script within a banner, you need code review by another developer familiar with the system. Make sure the code review is documented in the request for the banner.

バナーのコードやデザイン、書式をカスタム化する

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 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.

提携団体と財団職員に関する方針

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.

特例のバナー

The Central Notice Admins and the Wikimedia Foundation, have identified several situations where banners need additional attention. Please review the following guidelines if your banner includes fundraising or a survey.

募金

募金活動用のバナーは掲出予定日から少なくとも90日前までにウィキメディア財団に通知するものとし、例外なくウィキメディア財団の承認を受けてください。この件については、当財団のジュリア・ブラングズ(Julia Brungs)もしくは資金調達チームにご連絡願います。

  • オンラインの募金活動用バナーはウィキメディア財団の管理下にあります。当財団はそれぞれの提携団体に当該キャンペーン開始の3-5ヵ月前に連絡をして、ほとんどの国と地域でこれらキャンペーン展開のタイミングを調整します(例外はアメリカ合衆国、イギリス、カナダ、アイルランド、ニュージーランド、オーストラリア)。募金活動の日程変更は、当財団の担当チームと交渉願います。当財団はまた、ほとんどのコミュニティが募金活動に関与できるように、それぞれの言語別に専用のコミュニティ協同ページを用います。
  • オンラインの募金活動用と免税対象であることを提携団体がバナーで広める場合は、 ウィキメディア財団と法務上の合意を経て承認を受けなければなりません。その手続きを済ませると、一斉通知(CN)管理者から重ねて承認を得る必要はありません。
  • 提携団体とウィキメディア財団が募金キャンペーンや免税対象であることを広めるキャンペーンを実施する場合、一斉通知(CN)管理者の補佐が不要になるよう、CN キャンペーンおよびバナー専従の係員を自前で確保しなければなりません。
  • 提携団体とウィキメディア財団が募金キャンペーンや免税対象であることを広めるキャンペーンを実施する場合、ウィキメディア財団の原則を遵守しなければなりません。
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.
  • 状況によってはアンケートへのリンクを提示できますが、個人情報保護の方針と手順の説明文書を複数リンクを示したバナーで明確に広く公示する必要があります。
    • 一例として、ウィキメディア・ドイツ協会がウィキデータのコミュニティに関するアンケートをしたときには複数のリンクを明確に示しました:実例は バナーの設定ならびにそのプレビューをご参照ください。

I need help with my survey!

提携団体は、自前のアンケートの支援をウィキメディア財団に依頼できます。surveys@wikimedia.org に連絡して、面談の予定を立てることと、そのメール連絡には関連のある情報をすべて書いてください。アンケートの支援には連絡をいただいてから最低3週間は必要で、十分に調整する時間を確保できるよう通知してください。1、2営業日内に返信がない場合は、恐れ入りますが、再度、メッセージをお送りください – もしかしてこちら側で見逃しているのかもしれません。

調査の申請をするには:

一斉通知による調査を申請する場合は、以下の情報(のうち不用な情報を除去して)必ずコメントに添えて、調査にコメントを付けやすくしてください。

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:

関連項目