From Meta, a Wikimedia project coordination wiki
(Redirected from Talk:CentralNotice/Calendar)
Jump to: navigation, search

Subpaging campaigns[edit]

Hi. We've currently got pages scattered around for specific CentralNotice campaigns. For example, CentralNotice/Generic maintenance notice and CentralNotice/Shared and Image filter referendum/CentralNotice. I'm wondering if it makes sense to move all these pages to a subpaged format under "CentralNotice/Campaigns/" or something. So it'd be ... CentralNotice/Campaigns/General site maintenance, CentralNotice/Campaigns/Shared, and CentralNotice/Campaigns/Image filter referendum, respectively. A bunch of other pages could also be moved. Thoughts? --MZMcBride 17:33, 10 December 2011 (UTC)

  • Having a single page where they're all listed would make it much easier to follow them (no need to keep adding them to your watchlist)... Mike Peel 20:12, 10 December 2011 (UTC)
    • Using subpages, MediaWiki can auto-generate a list of pages. It'd be syntax like ... {{CentralNotice/Campaigns/}}. That's one of the advantages to using subpages. --MZMcBride 22:52, 10 December 2011 (UTC)
      • True. But I'm not clear about how that relates to following pages? Mike Peel 23:00, 10 December 2011 (UTC)
        • Ah, I missed that you wanted to watchlist them. I don't think MediaWiki supports any feature that would make that easier. No matter the system used (subpages, independent pages, pages in a category), you'll need to manually update your watchlist. You could also try something like Special:RecentChangesLinked. --MZMcBride 05:05, 11 December 2011 (UTC)

Meta:Central notice requests[edit]

Aww wtf?. C'mon. You are the worst! Also, Hi! We do need a centralized page for centralnotice, all the other pages could be linked from there. We never really developed any guidelines or found a conclusion to that RfC about global banners, until we have those, it's better to have a separate page for Admins to keep track of centralnotice requests. I made that page after the discussion on Internal-l, when Brion and Beria disabled the campaign there wasn't a location they could have made a note at, or explained why. Theo10011 13:57, 10 December 2011 (UTC)

Try a noticeboard? And it's not related to Meta-Wiki, so it wouldn't go in Meta-Wiki's namespace. Some pages are already neatly subpaged (e.g., CentralNotice/Calendar and CentralNotice/Shared). So you'd want CentralNotice/Noticeboard or something of that nature. Maybe not "noticeboard," maybe "water cooler" or "beer pub" or whatever. Move the redirected page there and then make it less of a cluttered mess? Sounds like a plan to me. :-) --MZMcBride 17:09, 10 December 2011 (UTC)
Also, there surely was a location they could have made a note at. Nemo 17:34, 10 December 2011 (UTC)
Well, yes, there was a location, but I think Theo's point is that there might have been a better/more centralized/more obvious location. --MZMcBride 17:52, 10 December 2011 (UTC)

Banners with no CSS[edit]

Can someone take a look into this issue? Helder 21:40, 29 October 2012 (UTC)

Please see discussion at Bugzilla #41751 Mwalker (WMF) (talk) 21:42, 3 November 2012 (UTC)

Origin is not allowed by Access-Control-Allow-Origin[edit]

I got the following error on ptwikisource: XMLHttpRequest cannot load Origin is not allowed by Access-Control-Allow-Origin. Helder 01:28, 1 November 2012 (UTC)

Hopefully this issue has been resolved. We are now using a different method to record the number of banners seen by users. This was pushed late afternoon PDT on the 1st. Mwalker (WMF) (talk) 21:38, 3 November 2012 (UTC)
I should also say that this was tracked at Bugzilla #41623. Please comment there if you are having further issues. Mwalker (WMF) (talk) 21:50, 3 November 2012 (UTC)

Notice for CentralNotice administrators[edit]

Since MediaWiki 1.21wmf8 you don't need to specify translations for dummy language codes (such as be-x-old, but not de-formal, the latter is a regular language variant, like be-tarask). For more details, see MediaWiki 1.21/wmf8 and patch details. Thank you! Wizardist (talk) 20:19, 30 January 2013 (UTC)

There are some doubts about it: Help_talk:CentralNotice/Translations#message fallback. --Nemo 20:28, 30 January 2013 (UTC)
Nemo, Wizardist is talking about a different patch (for reference my fallback patch is 44224.) But; on that note; I'm confused about what dummy language codes were actually used for in CentralNotice. It seems like be-x-old would fall back to be just like de-formal would fall back to de -- but in the case of be-x-old. Is this because the I18N team has decided that be-x-old is not a 'real' language and therefore removed it? Mwalker (WMF) (talk) 21:03, 30 January 2013 (UTC)
It's all due to confusing different terms. de-formal is a legitimate language code for a language variant. be-tarask is a legitimate language code for a language variant. They fall back to de and be respectively (though the latter is not very good, but it's ok). be-x-old is a dummy language code. In other words, it's not a real language code and MediaWiki knew it for a while already. Using this terminology, be-x-old should not exist as a Language entity (speaking by terms of MediaWiki i18n implementation), but it existed and used the fallback mechanism. Now be-x-old is automatically transformed to be-tarask, so the system just doesn't deal with be-x-old (for example, if you set ?uselang=be-x-old, and get the value of wgUserLanguage in JS debugger, you'll get be-tarask; and de-formal will be kept, because it is a different matter). Wizardist (talk) 21:17, 30 January 2013 (UTC)
Ah, thank you. Actually I do know the difference between dummy languages and language fallbacks, but suspected you were still talking about the same change. (And indeed I was confused when I ended up on that commit.) --Nemo 21:20, 30 January 2013 (UTC)
Concerning "what dummy language codes were actually used for in CentralNotice": if a dummy code was set by the user in Preferences, then the CentralNotice would not fall back to a working one. Nevertheless the dummy language code is requested on client-side or server-side, if it's requested via Language class, it will be converted to a real code. Wizardist (talk) 21:22, 30 January 2013 (UTC)

Interface change? Bugs?[edit]

Has the interface been changed recently (a couple of days ago, perhaps?) -- I can't see any banners in Special:NoticeTemplate, and can't either select languages from the dropdowns, ie, in: [1]. Any idea of what's happening? Thanks. -- MarcoAurelio (talk) 16:19, 9 May 2013 (UTC)

Yep; we pushed the new interface yesterday. Special:NoticeTemplate is now Special:CentralNoticeBanners but it should be redirecting you. Not seeing any banners though is interesting -- a lot of the fundraising banners (or any banner that hides itself based on a cookie) you won't be able to preview yet because the banners are not yet written to look for a force=1 URL parameter. That being said it sounds like you aren't getting any previews? Does this hold true with the preview on Special:CentralNoticeBanners/edit/WLPA_alt? Internally the preview works by loading an iframe targeted at a special page on meta which then loads the banner and some skin overrides before communicating back to the parent page to resize itself. Is the iframe just not loading itself for you, or do they collapse to nothing?
"Not being able to select languages from dropdowns"... is the control disabled? If it is enabled and you click on it, does the page not refresh with the new messages? (We are tracking an existing bug that seems to be preventing banner preview in a language that is not the users default -- so the preview doesn't change, but the messages in the "Translatable banner messages" section should.) Mwalker (WMF) (talk) 16:33, 9 May 2013 (UTC)
Thanks for your detailed answer. I do not see the previews while logged in, but I do while logged out in CentralNoticeBanners/NoticeTemplate. They do collapse to nothing. Regarding the dropdown, it happens that when I try to choose a language, the page inmediatelly reloads, preventing from choosing any language from that dropdown. Thanks. -- MarcoAurelio (talk) 16:40, 9 May 2013 (UTC)
Do you perhaps have some user JS/CSS that is hiding the centralNotice div? E.g. to always block banners? (Or have the hide banners gadget installed and enabled?) If so that's going to prevent you from previewing whilst logged in.
It looks like I'm probably using the wrong JS hook for the language selector. I'm curious why it works for me though... I'll push a patch this afternoon 62987. Mwalker (WMF) (talk) 17:07, 9 May 2013 (UTC)
It's in User:MarcoAurelio/monobook.css (div#siteNotice {display: none !important}). PiRSquared17 (talk) 17:26, 9 May 2013 (UTC)
I've pushed patches for the language selector and banner preview in arbitrary languages. Please let me know if you're still having issues. Mwalker (WMF) (talk) 16:44, 10 May 2013 (UTC)

FDC banner[edit]

Hi. I've tweaked the FDC banner to spell out what FDC stands for. The change, made via this form, resulted in three separate edits: [2] [3] [4]. A bit strange. --MZMcBride (talk) 17:59, 18 October 2013 (UTC)

To me what is strange about it is that there should have been four changes. Each message is a separate object in both the MediaWiki namespace, and the CNBanner namespace. You edited in English, and in the UI, which is considered a canonical change so was immediately accepted for use (in the MW namespace) and presented for translations (the CNBanner namespace). Tilman apparently made the text2 change on the 16th; so the banner change you apparently made updated the CNBanner namespace... not sure why that didn't happen when Tilman edited. Mwalker (WMF) (talk) 18:15, 18 October 2013 (UTC)

Bug 55635 - New mailing list for centralnotice admins[edit]

FYI --Nemo 23:42, 22 October 2013 (UTC)

Has been live for a while now: mail:centralnotice-admins . --Glaisher (talk) 17:25, 25 September 2014 (UTC)

RFC on improving CentralNotice[edit]

mw:Requests for comment/CentralNotice backend improvements. --Glaisher (talk) 17:19, 25 September 2014 (UTC)

Global dismissing[edit]

I don't understand, why are all the recent banners not globally dismissed? I have to dismiss them individually on each and every wiki for each account I have. (Seen with POTY, Wikimania scholarships, stewards elections, ...) Is a bug filed? --Nemo 08:10, 10 February 2015 (UTC)


Screen-shot showing issue with banner obscuring page title.

All the best: Rich Farmbrough, 15:29, 29 October 2015 (UTC).

Dismiss the banner? — Martin (MSGJ · talk) 15:38, 29 October 2015 (UTC)
For all our readers? I never get it, when I point out a problem with the interface, I get solutions that hide the symptom for me. I feel like an ageing climate scientist trying to warn of an impending ice age, and getting a rug tucked around my knees, and a cup of hot coco.
Thanks for the coco! But that's not really the point.
All the best: Rich Farmbrough, 16:23, 29 October 2015 (UTC).
Looks like a meta:CentralNotice. —TheDJ (talkcontribs) 16:59, 29 October 2015 (UTC)
I'll cut and paste this there. All the best: Rich Farmbrough, 22:45, 29 October 2015 (UTC).
I saw this problem too. Firefox 41.0.2, Windows XP, MonoBook skin. --Redrose64 (talk; at English Wikipedia) 00:08, 30 October 2015 (UTC)
@Shizhao: 這是在用MonoBook時以發生的問題。你可以看看能否解決這個問題嗎? -- KTC (talk) 02:13, 30 October 2015 (UTC)
see [5]--Shizhao (talk) 08:50, 30 October 2015 (UTC)

Central notice in en on cywiki[edit]

Once again, no notice was given to me of the English-only banner on the top of all Welsh Wikipedia pages. I've received several emails from the community who are very offended. I've also spent two hours searching where to translate it. What a waste! I'm now going to suggest that NO banners to be placed on Wicipedia Cymraeg. Llywelyn2000 (talk) 18:45, 15 March 2016 (UTC)

Hi, Llywelyn2000. If it was the Wikimania banner — you can now translate it. Have no idea why it wasn't made translatable from the start, I rather share your state of mind. If it was some other one, please point which one. --Base (talk) 19:43, 15 March 2016 (UTC)
Thanks Base; yes it's the Wikimania Banner. Any idea where can it be translated? Llywelyn2000 (talk) 05:56, 16 March 2016 (UTC)
It now has the "help with translation" link in it. Here [6]. --Base (talk) 07:23, 16 March 2016 (UTC)
Many thanks. How can we ensure this never happens again? Any ideas? Llywelyn2000 (talk) 11:24, 16 March 2016 (UTC)
If the link isn't compulsory per CentralNotice/Usage_guidelines, maybe you could start a related thread on the talk page (and maybe link it from other more prominent discussion venues). --Elitre (WMF) (talk) 11:38, 16 March 2016 (UTC)
Just for reference, the banner did not just lack the link (or mor precisely it did have it but the code responsible was commented), but the text strings were hardcoded in it, so just providing the link by itself would do nothing. The guadilenes actually already do have requirement of not setting English banner to people who user non-English project/UI. --Base (talk) 12:26, 16 March 2016 (UTC)


Our original guidelines weren't intended for so much activity. I believe these guidelines should be revised and have more structure. They are too vague in certain aspects. We can categorise them depending on who requests them, and keep certain annual events like wikimania permanently on calendar and plan accordingly.

There seems to be a banner overload that happens intermittently. And people requesting these campaigns, don't usually have an idea of the impact and reach of their own requests. I am currently in a country with a population of over 1 Billion, a high or even normal priority is serving up way too many views than it should. In times of multiple campaigns running concurrently, this is becoming a really pestering issue. It will certainly affect future campaigns and fundraising plans, if we burn these views out so quickly. We get several million views more in large countries than we should. We need a guideline that takes in to account the size of the country and the number of ongoing or planned campaigns - If 2 or more banner are supposed to be run, lower banner weightage should be considered, or we can limit certain community campaigns in a month to a certain number. We need some solution here, this is going to be an issue sooner or later. The staff should take a look here. If no one comments, I am going to propose and make some changes here. Theo10011 (talk) 18:31, 3 June 2016 (UTC)

Agreed. These banners should be the exception, not the rule. It might be worth creating some other space in the interface for smaller campaigns to be displayed - maybe a line of text under the user links, for example? But the current overload of banners is getting a bit ridiculous. Ajraddatz (talk) 18:34, 3 June 2016 (UTC)
(Moved from RFH) Basicly yes, the problem is brightly there, and I as a user executing some of the banners putting in recent months am not very happy about that. But. What I am not sure is how to make rules more strict without scaring "clients". What I mean is that it is already not uncommon for people rather than meet the requirements we set here on Meta to just put a banner locally in SiteNotice where they can do whatever they want (links to third party sites unwarned, third parties' trademarks as the most blatant abuses from my POV but not the only ones). While for some communities we can appeal with the fact that we have geolocation and SiteNotice does not, in case of many other languages that is not really a problem (my native Ukrainian including), as most of the language's speakers live in a single country anyway. Another good thing we have is banners' rotation, but this is performable via scripts locally too. I think a reform would be a go only if we adopt some global rules concerning any banners, rather than just CentralNotice. --Base (talk) 20:50, 16 June 2016 (UTC)

I propose some amendments -

  • Limit community campaign number to 3 (or 2) in a month
  • Strictly enforce a limit of 2 geolocated campaigns
  • Staff campaigns won't be affected so any community limit has to take any ongoing or planned staff campaign in to consideration
  • Better calendar and scheduling - update calendar with annual campaigns like wikimania, elections, fundraising months marked off
  • lower visibility/weightage of campaigns - 50% or lower for geolocated
  • avoid high visibility all together
  • Most campaigns originate from either chapter request or commons - better co-ordination with both
  • Avoid large, bold and bright banners in lieu of more direct smaller banners

Some thoughts to start thinking along. Theo10011 (talk) 21:05, 16 June 2016 (UTC)

Speaking only for the campaigns I run for IdeaLab like the current one, I think it's a good idea that these centralnotices are limited to 50% or lower, and I'm always OK with deferring to a banner for a community event or program to be shown more often than one for Inspire. I think a calendar is a great idea as well to help plan and negotiate conflicts ahead of time. I JethroBT (WMF) (talk) 22:37, 16 June 2016 (UTC)
I think WMF and Community has to find balance, instead of requiring community to sacrifice for WMF. — regards, Revi 15:21, 17 June 2016 (UTC)
Most WMF campaigns can be suppressed without damage. Nemo 21:40, 17 June 2016 (UTC)
I think we should ban CentralNotice usage altogether outside of the annual fund-raiser. I'm very sick of the constant use of "leaderboard A" to advertise discussions that I don't care about (harassment campaign, picture of the year, etc.). Nobody is saying these aren't worthwhile projects, but they don't need to be advertised to every user in such a prominent place. Try MassMessage or e-mail or something less annoying. Stop abusing a tool designed to be as in-your-face as possible.
Alternately, we could implement opt-out/unsubscribe lists for CentralNotice, similar to what horrible companies who won't take "no" for an answer do. You would end up requiring users to opt out of specific categories of notices they don't want to see (e.g., surveys, contests, fund-raising, elections) rather than doing the right thing of not spamming users with noise they didn't ask for. --MZMcBride (talk) 12:58, 18 June 2016 (UTC)
It's not a bad idea, but I think we should try to prevent overload in the first place, rather than letting people opt-out. There is the occasional interesting/important one for them to see; we just need to figure out a rate at which they are not too painful and disruptive. Ajraddatz (talk) 07:46, 19 June 2016 (UTC)
Agree that we should prevent banner overload. Especially for banners which are enabled for logged out users we need unmistakable restrictions, we shouldn't set too much banners for logged out people (of crouse for logged in as well). --Steinsplitter (talk) 07:39, 19 June 2016 (UTC)
Agree for banner that have an impact extensively in several languages and projects and countries and absolutely for banner put for very long time, but open to a more rational use for some banners that have an impact in limited regions or for limited projects and limited with the timeline. I have seen banners put on centralnotice for several months and the worst banners have been that of the community (some banners put on projects for three months). About Inspire campaign I am in the IEG too and I would also bring here the other positive aspect of this campaign and basically that some people (not being member of the community) apply for a grant thanks to the banner. The biggest benefit is that these are people not member of the wikipedian community and they bring a valuable "different" point of view and new blood. It's difficult to do outreach with other tools (like mass-message), because it's an "out"-reach. --Ilario (talk) 09:07, 19 June 2016 (UTC)
No problem with taking a lot more consideration to banner overload etc., but would objects to any suggestion that limit CN to fundraiser only. MassMessage or emails etc. are suitable for certain type of users and campaigns but totally unable to reach out to certain type of editors/readers that CN would. One additional suggestion I would add is minimal scheduling notice. There's rarely any campaigns that are truly unforeseen and urgent. Seeing repeats requests for CN by 24 hours time or even NOW on RFH is not unusual but definitely should be. -- KTC (talk) 10:53, 19 June 2016 (UTC)

Thanks guys. Reading through the comments here - 1) I agree we need an alternative to CentralNotice. But as admins here, we answer the requests and turn-on most of these campaigns ourselves, so it's a bit of our responsibility to be good caretakers of it. 2) Banning all CentralNotice usage doesn't seem like something we can just do ourselves? There are certainly more stakeholders than just us - chapters, committees, annual projects, groups - I imagine a lot of people will have an earful to say if we just unilaterally initiate something like that. It's going to need a bigger discussion and consensus than just admins here getting together and deciding to ban all community usage all together. 3) We can't really do anything about WMF campaigns, they built this originally and are the primary users of it, and honestly, I don't want another round of staff vs community faceoff that go nowhere - These are all bigger decisions that require wider community input and consensus. If anyone wants to pursue that, they should start an RfC. However, the intention here is far simpler, we as admins here, can tighten up the guidelines for centralnotice usage and try to discourage longer, more visible campaigns - I think that is an achievable goal that won't require a lot of consensus. All the comments so far above seem to be in agreement to a certain extent about limiting usage.

So, Here are some ideas/suggestions to add to the guidelines and for admins to keep in mind -

  • Exclude Meta, campaign only on content projects - The campaigns include Meta a lot. Meta isn't a content project, all other projects are. There isn't likely to be a lot of views generated through meta. How about adding a guideline to limit campaigns to content projects only? (Also mention there that project-specific campaigns should use site notice or local banners)
  • Soft-limit/hard-limit - Set a monthly limit on campaign number to 2.
  • Campaign length - 1 week, maximum 2 weeks. Month-long campaigns should be really avoided.
  • Banner weightage/priority - High priority should never be used by community campaigns, Medium for important and short campaigns (1 week or less). Low <50% (~30%) is the ideal priority for community campaigns.
  • Better calendar/scheduling - We need a better scheduling system, wikimania scholarship, elections, fundraising should be permanently on an annual calendar and should be given priority. (this is a project one of us has to undertake to make a better scheduling system, any takers?)
  • Smaller banners - perhaps we can suggest smaller banners or text based messages. The loud, colorful, persistent banners really detract from common usage of the projects. They make reading articles difficult with a distracting banner. They should be much less distracting. More Suggestions to achieve this are welcome.
  • Alternative - Admins themselves and guidelines should suggest alternative communication methods, massmessage and email are alternative that should be suggested to people requesting these campaigns. If WMF staff or any community member, wants to come up with a new way for Mediawiki where local solution can pick up the slack for these banners, it would be appreciated.

Those are a few from the top of my head. Please offer feedback and finalise these soon. This is turning in to a real problem. The wle campaign has been running for a month, and I remember dismissing it at least 2 dozen times in the last weeks - I can't even imagine how those banners would seem for regular logged-out users. I really hope we can avoid situations like this in the future. Any others suggestions? Theo10011 (talk) 16:13, 19 June 2016 (UTC)

June 31st?[edit]

Not found in my calendar.--Tekstman (talk) 19:42, 3 June 2016 (UTC)

Requests process[edit]

I might have missed something but did we have a vote approving that new process? It seems to be more than just changing the venue where the requests are proceeded so it requires it, IMHO.
It is not very clear as well in my opinion. If I am going to create a campaign on behalve of some project I am active in how should I proceed? I am more than welcome to have it reviewed, but as I do not need another Meta/CN admin to actually create it some steps a little bit not adapted to it. (e.g. It might be much easier to actually create a banner and link it than to specify what are the landing page and stuff). It also removes some of the flexibility in terms of creating banners for approved campaigns in short time. E.g. on Wiki Loves Earth some countries provide data needed for the campaign for their specific country just several minutes before the start, while WLE campaigns as whole were known to be expected to run. On CEE Spring I had been creating new banners for Ukrainian campaign on very short notice like several mins before the week (wasn't able to get new banner text from the other local orgs faster), though the campaign itself was approved. Actually in such cases when the review was going on on other pages (there are such for WLM, WLE, Wikimedia Ukraine campaigns) even if with shorter time, I can probably just apply IAR and proceed as usual, but I'd rather we have some common exceptions to the process written in its page itself. I do not want to have a feeling that what I am doing is an abuse. --Base (talk) 14:44, 28 June 2016 (UTC)

Hey Base. You haven't missed something, there wasn't a vote approving the process. I reached out to the CN and Meta admins who use Central Notice to get some input. What was fed back was that generally having some sort of formal but lightweight approval method was a good thing. What we have is fairly basic but the current form isn't something we are stuck with. It most definitely can be improved with time and feedback and by more people than just myself. I would like to find ways we can provide additional things such as regular banner metrics etc. as part of the process. What this is deliberately meant to do is to make project leads think about their use of CentralNotice more than just a last minute thing. We need to use CentralNotice in a more efficient and effective manner. People need to think in advance about how they are going to use it. It's such a powerful tool than people need to start seeing it as such.
For the time being there are three campaigns with exceptions relating to their organising for this process. WLM, WLE and Fundraising. For these, approval will simply be broad approval for the campaigns since they have such complex setups. If project leads get campaign approval then I see no issue with any CentralNotice or Meta admin dealing with last minute changes or campaign setup whatever their relationship. I see no issue with you assisting with the CEE spring banners all I would ask is that they request the banner more than a week in advance which is not a particularly strenuous requirement. You do some excellent work with CentralNotice and I definitely want to support you in doing that as much as possible. Jseddon (WMF) (talk) 08:58, 29 June 2016 (UTC)
Hi, Curious about the request process. I requested a banner for the international LGBT writing weeks and did not get respons yet. Do I need to wait a little longer? Can I place it in the calender? --Denise Jansen (talk) 07:47, 4 July 2016 (UTC)

French WikiCon[edit]


I don't see the banner for the French WikiCon. It is mentioned in the calendar. Could someone look at it? It's very important to publicise the registration as it's the first time that a WikiCon is organized in French!

Yes check.svg Done Jseddon (WMF) (talk) 17:21, 7 July 2016 (UTC)
Thanks @Jseddon (WMF): but I don't see the banner. I've tried with different accounts and on different browsers. Pyb (talk) 14:31, 8 July 2016 (UTC)
It is now disabled so that is not strange. Jseddon (WMF), I would have enabled it but I am not sure about having that link to a non-Wikimedia site without any explicit notice about it and its ToU/PP. Well and also that pointer cursor and translatable message for alt text of the close button look a little bit weird but are much less concerning things. --Base (talk) 16:32, 8 July 2016 (UTC)

Emergency request based on community processed request for sitenotice[edit]

Hey All,

Just want you all to be aware that I have processed an emergency request due to an issue with the korean wikipedia not showing sitenotices to mobile users. It was based on a request on the local wiki as well so as far as I am concerned the need for local involvement has been met. I've logged the request and marked as completed for transparency CentralNotice/Request#Emergency_-_KoreanWikiConference. Currently this process is not designed for such requests so I was bold and felt this was the best way to handle such a request. Jseddon (WMF) (talk) 17:47, 16 July 2016 (UTC)

We should have a formal guidelines for these 'urgent' or 'emergency' requests - they should have prepared in advance, so I tend to say NO to any future "emergency" requests. (Though I'm not a CN regular.) — regards, Revi 09:16, 17 July 2016 (UTC)
So in this instance they actually weren't after a central notice banner in the first place and were in fact only after a sitenotice which they requested through their own wiki. This got enabled however there was a technical limitation they discovered whereby sitenotices hadn't been enabled on mobile webviews on the minerva skin front end. In this instance the mobile banner was only created to supplement a community decision in lieu of the technical issues. Jseddon (WMF) (talk) 10:08, 17 July 2016 (UTC)
I do agree however that if Central Notice banners are the main intention then they should in fact go through the 7 day process. Jseddon (WMF) (talk) 10:09, 17 July 2016 (UTC)
Of course I know that the sitenotice is there by myself being kowiki admin. However I believe all CN request (regardless of their previous status) must be held for '7 days community consensus' period, regardless of their excuses. I already know the requester was told about mobilefrontend's ability to show sitenotice (wgMFEnableSiteNotice), and it should've been done this way, not using CN. If they wanted to use CN, they should have used CN at the first place, through correct process. — regards, Revi 11:36, 17 July 2016 (UTC)