Community noticeboard/Archive 25

__NOINDEX__

Problem tabber
Hi, there, Would you know how to make a caption only appear in one tabber window? I know how to make it appear in both, but when I try to do it in one, the caption shows up in bold, as you can see here: Thanks in advance. Darkrai18 (talk) 13:49, 14 November 2021 (UTC)


 * Hello, my apologies for delay in responding. Has this been resolved? I have located the page you mean and it seems like you managed to get the caption going in one and not the other. If you meant something else, I ask for more information on what is intended. --Raidarr (talk) 12:43, 17 November 2021 (UTC)
 * Hi . Yes I managed, but the text appears in bold. I want it not to be. Sorry for the delay. Darkrai18 (talk) 09:16, 19 November 2021 (UTC)

Question for category pages
Hi, it's me again. Do you know how to make the category pages look more like Fandom's than Wikipedia's? For example having icons next to the category names, or "trending pages". Thanks in advance. Darkrai18 (talk) 22:09, 19 November 2021 (UTC)

Improving password standards on Miraheze

 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * Site Reliability Engineering would like to thank all participants in this Request for Feedback for sharing their thoughts, comments and concerns. Your feedback is very important to us and always plays an important role in any decision-making and we assure you that we will take all of this feedback into consideration. For more technical information on this task, please see T7713. Thank you! Agent Isai  Talk to me! 03:57, 23 November 2021 (UTC)

Hello all,

In order to comply with the latest security standards, the SRE team wishes to slowly increase password requirements to require that passwords are at least 12 characters.

The plan we thought of would be to progressively institute these requirements: first for global groups, after for local administrators, bureaucrats and bots and finally to extend the longer password requirements to the entire user base.

Before we go ahead with these changes we would like to get feedback from the community, so please do feel free to raise any concerns or provide any feedback you may have or ask us questions about this change and we would be happy to respond.

Thanks, Reception123 (talk) ( C ) 15:09, 4 September 2021 (UTC)


 * 1) My feedback is that this policy is as dumb as most of our Covid-related policy that assumes attaining Zero Risk is more important than living our lives.  Anyone who wants the additional security of a longer password can have one instantly.  There is no need to mandate that the entire user base do anything (except perhaps to those with power over the website) except to pat yourselves on the backs for having done something.  If someone is actually asking for this, then implement a customization option for individual wikis where their administration can enforce password length if desired.   20:34 4-Sep-2021
 * 2) Is there a demonstrated need on Miraheze that would entail people changing in this way? I have not seen enough of a wider requirement or evidence on the internet of widespread compromise to think this is in any way necessary. --Raidarr (talk) 00:26, 5 September 2021 (UTC)
 * Hmmmm, not sure if this is exactly necessary. I have yet to see any reports of recent account attacks. DarkMatterMan4500 (talk) (contribs) 23:02, 9 November 2021 (UTC)
 * How is the server protected against such attacks? I think that adding a one second delay after each failed login attempt for a specific user name and IP would prevent such attacks from beeing successful, am I wrong? WHen yes, where is the flow in my considerations? LilyLilyu - smile.svg talk and I will listen · Lilypond Wiki 08:13, 11 November 2021 (UTC)
 * 1) Support for global groups, but not for local groups. The current status quo for many of Miraheze's affairs is to let local wikis govern themselves and decide on their own policies, and only intervene when there is a legal obligation to do so, or if there is a ToU violation. Global groups should absolutely have strict password policies, because users with such groups can affect all of Miraheze. However, for local admins and bureaucrats, it's best to leave strong passwords as a recommendation rather than a requirement. Local wiki communities can decide on their own password policies if they so choose. As for the entire user base, I don't think it's necessary. A good idea in theory, but in practice it might not do much to encourage better password use. For all we know, someone who's password is the unacceptably insecure "password" could easily change it to "passwordpassword" to get their password up to 16 characters and meet the requirement, yet still have a terrible password.
 * Also, may I ask, what exactly are the "latest security standards" that you're referring to? If by "latest security standards", we mean "using HTTPS", "hashing passwords", and "keeping up to speed with security patches", we're already doing that, right? — k6ka  🍁 ( Talk ·  Contributions ) 23:24, 9 November 2021 (UTC)
 * 1) not sure what that current mandated length is, but 12 seems too long to me. 8, sure, I'd understand, that's common practice. enforcing numbers and special characters, also good. but 12 digits? for casual users? we'd see a huge uptick in password resets. I can maybe see the benefits for global groups, admins, bots, the like (i.e. people who's accounts could damage wikis if compromised) but for someone who logs in once every six months? not worth it imo. also, which security standards are you referring to? you mention "the latest" - who's latest? Amazingakita (talk) 08:57, 10 November 2021 (UTC)
 * 2) I only want to say that lenght and complexity checkings are ok (mine already is complex and long enough) but I don't agree with checks that compare the previous password with the new one. If I change a password (imagine, because I want it, not because a data breach) I don't want to lose that password forever. Jakeukalane (talk)
 * Hi, I'm also wondering what the "latest security standards" are. Is it some kind of policy that Miraheze has to abide by? Regardless of that, I'm ok with enforcing stronger passwords for users who have potentially destructive permissions, both locally and globally (deleting, blocking, editing interface, etc.). For users without these permissions, maybe there could be a warning with a "your password is not secure" message that the user can dismiss? Just an idea! --Ondo (talk) 10:45, 10 November 2021 (UTC)
 * 1) Pls do not change the current standards for passwords on Miraheze. I totally agree with Spike that everyone is free to chose a password as long as he likes. I would really hate to change my Miraheze passwords. All these password requirements (special character, number, small/big letter etc.) on many websites are really annoying me, so pls do not introduce a new password policy, thank you, LilyLilyu - smile.svg talk and I will listen · Lilypond Wiki 21:29, 10 November 2021 (UTC)
 * 2) Please DO increase password security. This is common sense, and a reality online to protect people's accounts from being easily broken into. I use a password manager that generates random string 20+ character passwords. Working in tech, I can say that increases in password security is just the way things are going to keep modernizing. Fighting that makes little sense because it's going to have to be done elsewhere eventually anyhow and is increasingly insisted on, on other sites. Insecure accounts can affect the Miraheze community because of the unified login; these logins being usable on other wikis can be problematic when an account is easily broken into. I would hope people would consider please keeping up with the tech and being realistic about what that often looks like today. CrystalClear (talk) 22:10, 10 November 2021 (UTC)
 * This is frankly not my experience even including services like Discord, Protonmail and Gmail (though Gmail is aggressive in pushing alternative functions anyways). The path of inevitability is not as clear cut as this would make it seem, at least from allegorical experience that would be easy to find. Though this is not to say that these password changes wouldn't have some benefit, and that people shouldn't be going well past them anyways. But frankly, unless you have responsibility that obliges you to more cutting edge protection, it's discretion I'd rather see users retain until it is demonstrably no longer viable on the internet. --Raidarr (talk) 09:18, 11 November 2021 (UTC)
 * 1) I do not see a strong need to increase the password requirements as proposed. As with K6ka's comment, I do  increased password security and two-factor authentication for users holding global groups (to be clear, wiki creator and interwiki administrator should not count as global groups for this purpose). I'm speaking of the SRE, Trust and Safety, and Stewards groups, principally because the   group on Miraheze is not the same as the   group on other wikis, as Miraheze has ManageWiki which provides for the granting of user group permissions without having to have the   user right that would otherwise provide access to the most sensitive, restricted user groups. I also feel that twelve characters is too much, but would support a 9-10 character minimum, with a combination of a minimum of one capitalized character, one non-alphanumeric character, and a mix of numeric and alphabetic characters. Dmehus (talk) 01:54, 15 November 2021 (UTC)
 * 2) I this as well. Coming from a company where this has been mandatory since years I would like to have this level of security here as well, especially because of the global login. Password managers can deal with even longer PWs, just saying. Soukupmi (talk) 07:58, 15 November 2021 (UTC)
 * 3) You say "latest security standards", yet provide no evidence for how this is considered to be so. Considering that I haven't seen any widely used platforms make such a change to password length, this change seems to lack any sort of proper reason behind it from what I can see. K599 (talk) 20:53, 15 November 2021 (UTC)
 * 4) It is my opinion that in this matter it is necessary to take a balanced and reasonable approach rather than a overreaching one. Unlike some comments above suggest I do not believe that it is unreasonable to require a certain password length and I think this is a sensible approach. That being said I do not agree with imposing a 12 character password for all users indiscriminately. This is because as many users have said before me the SRE team does not provide us with any justification or evidence to justify such a measure. If there have not been any accounts that have been hijacked why is it necessary to take such a measure right now? Is there a security risk we do not know about? I believe that in terms of regular users there is no need to change the current requirements and that users with low level access should make their own decisions regarding password length. I have personally not seen another website that has such strict requirements for lay-users. However, I do think that all global groups with significant power (such as Stewards, System Administrators and Global Sysops) should have this requirement as an extra safety precaution. I would not necessarily disagree with local groups such as administrator and bureaucrat having the requirement but I tend to lean towards the direction of them not having this requirement for the time being unless an actual need is proven. In conclusion, my current opinion is that an all encompassing requirement is inappropriate at the time but I would be willing to change my opinion if the SRE team will provide me with a reasoned explanation and justification for these measures other than just to be very careful. To be more clear after reading all the comments again my opinion is closest to that of Dmehus which I would support and which I find the most reasoned. --DeeM28 (talk) 20:12, 16 November 2021 (UTC)


 * The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section

Interwiki
hi, staff you can help me my two wiki 麥克百科 wikiand日語-麥克百科事典 wiki inter language? thanks.--Msnhinet8 (talk) 08:14, 22 November 2021 (UTC)
 * ✅, check your local Special:Log/interwiki for confirmation. Agent Isai  Talk to me! 08:17, 22 November 2021 (UTC)
 * ok,thanks.--Msnhinet8 (talk) 08:22, 22 November 2021 (UTC)

How to change font
Hi, I want to customize the font of my wiki. I tried to change the css file a lot of ways, but I can't use a google font (EB Garamond in particular). I tried a lot of possibile sintaxes, but nothing seems to work. Adri Ikharai (talk) 07:31, 23 November 2021 (UTC)

I've had help with this before, maybe it'll help you. Raichu&#39;s Endless Nights (talk) 07:52, 23 November 2021 (UTC)


 * Tibi gratias fa pro me servando Adri Ikharai (talk) 08:44, 23 November 2021 (UTC)

Page previews
Is it possible to add page previews to a miraheze wiki, like the ones that appear on Wikipedia? (https://www.mediawiki.org/wiki/Page_Previews) TomebinderL (talk) 15:16, 23 November 2021 (UTC)


 * Yes, it is. To enable it, please go to Special:ManageWiki/extensions on your wiki and enable "Popups" Agent Isai  Talk to me! 16:03, 23 November 2021 (UTC)
 * Thanks! TomebinderL (talk) 18:04, 23 November 2021 (UTC)

Where is my old request?
I had a Fancade Wiki request. Because I lost it, I had to create a new one. It appears declined. Can you find the old one? TylerMagee (talk) 21:36, 23 November 2021 (UTC)


 * Your original request for a  is #21420. Both your old and new request were declined because they lacked a good reason. Please edit your wiki request and expand on your wiki's scope in 2-3 sentences (e.g. "My wiki will focus on X and will document Y and Z", etc.) and we'll process it again, thanks.  Agent Isai  Talk to me! 22:23, 23 November 2021 (UTC)

Templates and tags
Hi, Could you please tell me where I may find
 * a list of common templates like as in m2 ?
 * a list of common tags like  ·   ·  ·  · [[Category:]]
 * Translations: · ·  · 
 * It's already there. You want to put it on your wiki or what? Anpang   Talk   Stuff  02:18, 28 November 2021 (UTC)

One of my posts that I last updated November 18th is gone
I had a post on the noticeboard that I intended to update regularly. I last updated it on November 18, and according to the edit history of the noticeboard, it was archived three days later, on November 21st. How long will it take to update Revibot to only archive posts that have had no activity for 14 days? I know how to retrieve my post, but I'm unable to do so because I'm posting from a Nintendo Switch (it has an internet browser, but it can't be easily accessed. There are many tutorials online on how to access it, if you want to), which doesn't have a copy-and-paste feature. Also, where can I put my post so that this doesn't happen again? Tali64³ (talk) 17:15, 25 November 2021 (UTC)

Problem with reCAPTCHA when creating a account
Hi, When I attempt to create an account, I get this : "reCAPTCHA validation failed: score retrieved from server is lower than the minimum required score. Please try again later. If problems persist, please contact sre-mediawiki@miraheze.org."

Does anybody knows why?

In fact no captcha appears, and there is no adblock or alike on my Firefox.

What appends ? -- Webmaster1 (talk) 21:57, 26 November 2021 (UTC)


 * Please email cvt@undefinedmiraheze.org to request they make an account for you. Agent Isai  Talk to me! 22:05, 26 November 2021 (UTC)
 * OK, I will. But here I wanted to know what happens.
 * Is that ok, if no captcha is proposed ? Isn't it a problem on miraheze.org ?
 * In fact I hate to have people at cvt(at)miraheze.org loose their time with such a boredom... Webmaster1 (talk) 22:30, 26 November 2021 (UTC)

Extensions not clickable
To allow Youtube embedding, I am trying to click on the Youtube extension box; however, none of the boxws in Special:ManageWiki/extensions are clickable? HID&#38;GEM (talk) 00:57, 28 November 2021 (UTC)


 * What exactly? Are the checkboxes grayed out? Anpang   Talk   Stuff  02:13, 28 November 2021 (UTC)
 * For the record, this was resolved on Discord. Agent Isai  Talk to me! 02:14, 28 November 2021 (UTC)

Miraheze @ Wikimania 2023
Hello,

During today's Miraheze Meeting, we confirmed that in 2023 we are considering attending Wikimania. If you'd like to join the party or get further information, please fill out https://forms.gle/GT2VCeRSCw9NdmR6A and we'll be in touch! RhinosF1 (Miraheze) (talk) 22:33, 15 November 2021 (UTC)


 * !mpressive early preparation start :-) --ZBlace (talk) 06:41, 29 November 2021 (UTC)

interwiki

 * Hi staff, can help me オンライン百科事典 wiki interwiki 网路百科 wiki? thanks.--Msnhinet8 (talk) 12:13, 26 November 2021 (UTC)
 * For the record, this has been ✅ by Ugochimobi (talk) 21:23, 28 November 2021 (UTC)

How do I add a background theme to my wiki?
want to make the background color of my wiki, Appalling TikToks Wiki, black, but I don't know how. SleepParalysisDemon (talk) 19:32, 27 November 2021 (UTC)


 * Check https://pastebin.com/QSpDFPAx
 * I will try polishing it later, and will give you updates when I do (to allow other things to be visible) -- Cheers, Bukkit ( Talk • All Contribs ) 00:11, 29 November 2021 (UTC)

SVG Program
Anyone to recommend me some FREE program that converts images to SVG without it going blank on the wiki? YellowFrogger (✉ Talk  ✐ Edits ) 04:26, 29 November 2021 (UTC)


 * Could you clarify what you mean about it "going blank on the wiki"? Agent Isai  Talk to me! 04:27, 29 November 2021 (UTC)
 * When you use these random google sites, and go to upload file on wiki, stay all white. But I believe it's not the wiki. YellowFrogger (✉ Talk </b> ✐ Edits </b>)</b> 04:30, 29 November 2021 (UTC)
 * Ok, this isn't really an answer, but can you just redraw it in a vector drawing program? Anpang   Talk   Stuff  04:47, 29 November 2021 (UTC)

Suggestion: Confirmation when clicking Logout
My computer is a laptop with a touchpad. Sometimes I accidentally touch the touchpad and move and the touchpad would move the cursor to the top right (Log out button) and click (because the touchpad has click on drag thing). Suggestion is to add a confirmation when clicking Log out. Anpang  Talk   Stuff  06:27, 29 November 2021 (UTC)
 * It would be a good suggestion only if it was in the preferences. For example: I didn't want this, to have a confirmation. You probably wouldn't have it either if it weren't for your laptop. So this is a system business and it's hard to solve, but we'll see if some admin can handle it, and I suggest you open a ticket in phabricator YellowFrogger</b> (✉ Talk </b> ✐ Edits </b>)</b> 06:31, 29 November 2021 (UTC)
 * I second that this could be a nice DIY to have in Preferences. --Raidarr (talk) 09:52, 29 November 2021 (UTC)
 * Agreed, this could be helpful to implement for mobile users to have available. Turtle84375 (talk) 18:06, 29 November 2021 (UTC)
 * You should make a task on WMF Phab. This is an amazing idea. -- Cheers, Bukkit ( Talk • All Contribs ) 18:22, 29 November 2021 (UTC)

Where can I ask for wiki deletion?
I have a wiki that I would like to be deleted; it's been sitting inactive for months and I just want to be done with it, but I can't find anything that says where I should go for wiki deletion. So, where should I go to ask for the deletion of my wiki? (I am a bureaucrat and administrator on this wiki) -- Waffledogefern (talk) 01:43, 30 November 2021 (UTC)
 * I recommend that you do it on the Stewards noticeboard, citing the reasons for the deletion in a short description. You must also quote the name of wiki YellowFrogger</b> (✉ Talk </b> ✐ Edits </b>)</b> 01:56, 30 November 2021 (UTC)
 * Put a wiki deletion request on Stewards' Noticeboard. Maybe make it something like


 * == Wiki deletion ==


 * Can I get my wiki abcdefgwiki to be deleted? ~ Anpang   Talk   Stuff  11:03, 30 November 2021 (UTC)
 * Okay, thanks! -- Waffledogefern (talk) 23:53, 30 November 2021 (UTC)

2021 Tech Excellence
Hello,

Before the end of year festivities start and the exams, Here's a quick post to celebrate the achievements we've made this year.

First, A massive thank you to Redmin (53 closed tasks / 40 commits) & Doug (50 closed tasks / 33 commits) for being our top non-sysadmin contributors.

Between 1 December 2020 00:00:01 and 23:00, 30 November 2021 (UTC) we had:
 * 2001 modified tasks
 * 67 users closed a task modified this year.
 * 49 users currently own a task
 * 629 users created a task modified this year
 * 293 tasks have no assignee.
 * 1247 tasks were closed as resolved.
 * 57 tasks were closed as duplicate.
 * 329 tasks were closed as invalid.
 * 306 tasks were closed as declined.
 * 62 tasks survived this period.

Thanks to all 78 users (2 users were excluded for being disabled) to have closed or are assigned to a closed task in the last 12 months.

RhinosF1 (Miraheze) (talk) 23:00, 30 November 2021 (UTC)
 * 1) Reception123 ( 717 task(s) )
 * 2) Universal_Omega ( 629 task(s) )
 * 3) John ( 226 task(s) )
 * 4) RhinosF1 ( 158 task(s) )
 * 5) Paladox ( 110 task(s) )
 * 6) Redmin ( 53 task(s) )
 * 7) Dmehus ( 50 task(s) )
 * 8) Void ( 41 task(s) )
 * 9) Southparkfan ( 28 task(s) )
 * 10) Agent_Isai ( 18 task(s) )
 * 11) Zppix ( 17 task(s) )
 * 12) Bukkit ( 16 task(s) )
 * 13) Ugochimobi ( 10 task(s) )
 * 14) Hispano76 ( 7 task(s) )
 * 15) PiscesKazeMGR ( 6 task(s) )
 * 16) Joritochip ( 4 task(s) )
 * 17) MarioMario456 ( 4 task(s) )
 * 18) Cocopuff2018 ( 4 task(s) )
 * 19) Lakelimbo ( 3 task(s) )
 * 20) Rob_Kam ( 3 task(s) )
 * 21) Owen ( 3 task(s) )
 * 22) WikiJS ( 3 task(s) )
 * 23) Videojeux4 ( 3 task(s) )
 * 24) Beninantidota ( 2 task(s) )
 * 25) Majavah ( 2 task(s) )
 * 26) Altter ( 2 task(s) )
 * 27) GabbiNova ( 2 task(s) )
 * 28) GustavioBitenkas ( 2 task(s) )
 * 29) J-Josyu ( 2 task(s) )
 * 30) Pfyh ( 2 task(s) )
 * 31) Anton ( 2 task(s) )
 * 32) Turtle84375 ( 2 task(s) )
 * 33) labster ( 2 task(s) )
 * 34) Sunilbutolia ( 2 task(s) )
 * 35) AmandaCath ( 2 task(s) )
 * 36) MacFan4000 ( 2 task(s) )
 * 37) Timboliu999 ( 2 task(s) )
 * 38) Shili ( 2 task(s) )
 * 39) HopelessNightOwl ( 2 task(s) )
 * 40) DonaldoCRG ( 1 task(s) )
 * 41) Darkrai18 ( 1 task(s) )
 * 42) Emojiwiki ( 1 task(s) )
 * 43) K599 ( 1 task(s) )
 * 44) CnoTe ( 1 task(s) )
 * 45) Xymachos ( 1 task(s) )
 * 46) MFSFreak ( 1 task(s) )
 * 47) Blackwolfe ( 1 task(s) )
 * 48) MrJaroslavik ( 1 task(s) )
 * 49) LukeTheNuke ( 1 task(s) )
 * 50) Iploystaffingph ( 1 task(s) )
 * 51) SoyokoAnis ( 1 task(s) )
 * 52) AnuWicky ( 1 task(s) )
 * 53) Verne ( 1 task(s) )
 * 54) github-migration ( 1 task(s) )
 * 55) Sario528 ( 1 task(s) )
 * 56) SamanthaNguyen ( 1 task(s) )
 * 57) Manuela ( 1 task(s) )
 * 58) Kees_Langeveld ( 1 task(s) )
 * 59) Scott_Williams ( 1 task(s) )
 * 60) AquaSZS ( 1 task(s) )
 * 61) DarkMatterMan4500 ( 1 task(s) )
 * 62) metalmax2000 ( 1 task(s) )
 * 63) Peggyfresh2012 ( 1 task(s) )
 * 64) DidierThunus ( 1 task(s) )
 * 65) Arcane21 ( 1 task(s) )
 * 66) Helper ( 1 task(s) )
 * 67) Dadoctorwhofan ( 1 task(s) )
 * 68) Clb123 ( 1 task(s) )
 * 69) The.Prettiest.Prettyboy ( 1 task(s) )
 * 70) Harryburr ( 1 task(s) )
 * 71) Ertosi ( 1 task(s) )
 * 72) Winn ( 1 task(s) )
 * 73) MusikAnimal ( 1 task(s) )
 * 74) TeNoR ( 1 task(s) )
 * 75) ChipWolf ( 1 task(s) )
 * 76) Callipedia ( 1 task(s) )
 * 77) Revival ( 1 task(s) )
 * 78) ImBoPhil ( 1 task(s) )


 * Hey, I see someone in the task list that looks familiar... 🤔 -- Cheers, Bukkit ( Talk • All Contribs ) 00:26, 1 December 2021 (UTC)
 * What does this list really mean? Are they requests in Phabricator? My name is not on the list, which means it's not just requests. YellowFrogger</b> (✉ Talk </b> ✐ Edits </b>)</b> 00:29, 1 December 2021 (UTC)
 * As said above the list, it is a list of people who "have closed or [have been] assigned to a closed task in the last 12 months." Agent Isai  Talk to me! 00:30, 1 December 2021 (UTC)

Edit rights restricted
Hi, I want my open wiki to be editable for Members only. Right now I made : "Everybody" with no rights and "Confirmed users" with Edit rights. Is that the best way ? Does anybody may become a "Confirmed user" on my wiki by his own ? Thanks for your advices Webmaster1 (talk) 16:41, 30 November 2021 (UTC)


 * Hi there :), you're welcome here.
 * Yes, I am sure you're on track as only confirmed users should be able to view your wiki (if it's private).
 * Plus, No, No one can grant themselves the confirmed user group, you or a sysop has to grant them.
 * Hope this helps. Ugochimobi (talk) 16:54, 30 November 2021 (UTC)
 * Thanks for this fast answer. But this : the site should'nt be private. Everyone reading it, only the granted one editing. Is my way ok for that ? Is there a better way ? Webmaster1 (talk) 17:40, 30 November 2021 (UTC)
 * For only site administrators to edit it, you must enable the extension ProtectSite in ManageWiki/extensions of your wiki. This won't make your wiki private, and I recommend reading the MediaWiki page about this extension to see how to edit, among other things. Hope this helps you. YellowFrogger</b> (✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 18:02, 30 November 2021 (UTC)
 * No, I don't want only site administrators to edit it, but only Confirmed users (granted by me) to edit it. Webmaster1 (talk) 18:24, 30 November 2021 (UTC)
 * I've never used this extension, so I recommend that you don't believe this answer: but I think it works like this. If you want guest users to edit, put them as admin on the site. If you only want registered users to edit on the site, this extension: "EditSubpages" should do it. But that's another thing. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 18:42, 30 November 2021 (UTC)
 * I wasn't the one that replied with that though, but just like I said above, I thought your wiki is private, but if what you want is what you said in the second RE, then, it's simple, all you need is a public wiki then the page you don't want everybody to edit, you'd protect "Allowing on autoconfirmed user's access" by so doing, only autoconfirmed and "confirmed users" will be able to edit such pages. Ugochimobi (talk) 19:10, 30 November 2021 (UTC)
 * @Ugochimobi: Sorry for the mistake, and thanks for the answer. Webmaster1 (talk) 19:38, 30 November 2021 (UTC)
 * No problems,:P Ugochimobi (talk) 20:07, 30 November 2021 (UTC)
 * Hi there! Uh, it looks like a lot of the previous solutions are pretty unnecessarily complicated. If I am correct that you want only members that you choose to edit, you can do this simply by changing which user groups have the  permission on your wiki. You can do this under Special:ManageWiki/permissions by removing the   permission from the   group (which is the same as the   group), and adding it to whichever group you desire. You may even wish to create a new group like   and give it the   permission for more control over who exactly has the ability to edit.
 * I can see that you have already figured out how to unassign the  permission from the   group, and have assigned it to the   group. If you would like to ensure that only confirmed users can edit your wiki, you will need to be sure to also remove the   permission from the   group as well (which applies to all logged in Miraheze users) at [ Special:ManageWiki/permissions/user].  dross  (t • c • g) 23:17, 30 November 2021 (UTC)
 * Seriously? And I used to edit a lot on a wiki, and I always went through ManageWiki, but I had no idea that this was exclusively for this. That's why it's good to volunteer even if you're not a steward. I think this is good because we don't need to solve it with extensions. Because extensions one day ceases to exist and is very manual. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 00:25, 1 December 2021 (UTC)
 * I've been around MediaWiki installs since probably about the time of 1.25 or so. Worked on the basics of or hosted a few independent wikis myself, including Hypercane's Hypoverse when it was once an independent farm. Those kinds of projects mean making changes to the LocalSettings.php file itself and running the included scripts from time to time. For me, ManageWiki is just like an extension of everything that goes into the backend management of a MW wiki. dross  (t • c • g) 07:08, 1 December 2021 (UTC)
 * they're all similar solutions. Thanks anyway :) Ugochimobi (talk) 07:00, 1 December 2021 (UTC)
 * Thanks to all for your valuable comments. What @dross has said is important as there is something weird. Though "All Users/Everyone * " has no editing rights, yet the simple "User" group has about all rights ! Apparently every group should be carefully checked... Webmaster1 (talk) 14:51, 1 December 2021 (UTC)
 * Another strange detail : I created a group 'Member' with edit rights, but this goup does'nt appear in the '[mywiki/]Spécial:ManageWiki/permissions' list. Quid ? This let me think there should be somewhere a clear definition of the Groups. For instance "Robot" and "Bureaucrates" : of Mywiki ? or of Miraheze ? Webmaster1 (talk) 15:01, 1 December 2021 (UTC)
 * Did you get it figured out? Everything looks good to me in Special:ManageWiki/permissions/member and on Special:ListGroupRights. dross  (t • c • g) 19:15, 1 December 2021 (UTC)
 * Yes I did get it figured out, and as I am learning I admire... Thanks for the Special:ListGroupRights address. Webmaster1 (talk) 21:33, 1 December 2021 (UTC)
 * I am sorry, I have this problem : though I belong to the Administrator group of my Wiki, I have no permission to create the Discussion page of any page I created ! So I figure I have missed something and nead your help. -- Webmaster1 (talk) 09:53, 2 December 2021 (UTC)
 * Hey! No problem! It looks like none of your user groups have the  permission, which I do believe is necessary to create any pages in addition to editing existing ones. There is also a   permission for discussion pages which you may want to assign to a user group. Hope this helps!  dross  (t • c • g) 09:59, 2 December 2021 (UTC)
 * Just on the principle, I should say something important about MediaWiki permissions - nothing is assumed, and by default everything is inherited. If a user was able to do something, an admin probably doesn't have it because they inherited from the user. So if you remove something from one group that was inherited from, you must make sure to add it to groups you want able to use it. --Raidarr (talk) 10:14, 2 December 2021 (UTC)
 * Thank you. I got the  and   permissions checked. -- Webmaster1 (talk) 10:26, 2 December 2021 (UTC)

MediaWiki 1.37
Can you please upgrade all farm wikis on this farm to MediaWiki 1.37? Thanks. TylerMagee (talk) 18:26, 1 December 2021 (UTC)
 * The version is still coming, maybe in a few days! Miraheze systems work and that's why Miraheze always gets a new version in a short time. Remembering that Wikipedia already uses version 1.38 <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 19:47, 1 December 2021 (UTC)
 * Based from my inquiry on Discord to SRE, the idea is to roll out in the next few weeks; however, there are snags with extensions that need to be worked out. Until that happens, a full update will be delayed. SRE is actively working on the matter. --Raidarr (talk) 20:32, 1 December 2021 (UTC)
 * Upgrades aren't something you have to request, they are something we do automatically. One of our commitments to our users is to always provide the latest version of MediaWiki. Currently, we're testing all 300+ extensions on our farm to make sure they work well with MediaWiki 1.37 with only about 20 extensions left to test. We anticipate to probably upgrade to MediaWiki 1.37 in the next few week if possible. Agent Isai  Talk to me! 20:42, 1 December 2021 (UTC)

Accidentally removed self from bureaucrat role
Hi there. I am completely new to this and was poking around roles and removed myself from the bureaucrat role (i am the sole member currently) thinking administrator role would still allow me to access to editing the wiki settings. I'm now stuck, what should I do? Hamishpo (talk) 08:57, 2 December 2021 (UTC)


 * You can request a steward in this to re-add you to the bureaucrat role in your wiki. Anpang   Talk   Stuff  09:03, 2 December 2021 (UTC)
 * Thankyou so much! Hamishpo (talk) 10:18, 2 December 2021 (UTC)

Problem with infoboxes
Hello, I'm new to setting up wikis of my own here, had The Pantheon Verse Wiki started earlier today, and I'm struggling with the infoboxes. I've imported a number of templates and modules from Wikipedia to get them working, but every time I try to create one, this text appears next to it in the preview: " <templatestyles src="Module:Infobox/styles.css"> "

I have no idea where I went wrong, can anyone help me? - 59Efra (talk) 17:42, 2 December 2021 (UTC)


 * Please enable TemplateStyles at Special:ManageWiki/extensions -> Parser hooks to get rid of that. Agent Isai  Talk to me! 17:48, 2 December 2021 (UTC)
 * Did that, now I'm getting this other message instead: "Page Module:Infobox/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text")." How do I solve this? - 59Efra (talk) 17:56, 2 December 2021 (UTC)
 * I've fixed that for you. For the record, I changes the content model of the page using Special:ChangeContentModel from text to Sanitized CSS. Ugochimobi (talk) 18:11, 2 December 2021 (UTC)
 * Thank you very much! - 59Efra (talk) 18:15, 2 December 2021 (UTC)
 * Hi there, to be honest with you, importing templates and modules from ENGLISH WIKIPEDIA is where you started making the whole mistake, as infoboxes from there always has one or two issue here, why? they're complex that you need enough Lua programming knowledge to fix them to your taste.
 * Per Agent above, Head to this page in your wiki and scroll down to find the mw:Extension:TemplateStyles and turn it on. Enabling that should fix your current issue. Ugochimobi (talk) 17:53, 2 December 2021 (UTC)

Removal of the Liberty skin
Hello,

SRE wishes to inform the community that the Liberty skin will be removed in preparation for Miraheze's upgrade to MediaWiki 1.37 on 5 December, 2021, due to lack of compatibility with MediaWiki 1.37. While testing the skin on MediaWiki 1.37, page contents loaded incorrectly and unstyled due to resources not loading. As this skin is not compatible with the latest release of MediaWiki, we will have to remove it before upgrading.

Miraheze offers many skins to choose from. Affected wikis who have the Liberty skin enabled as the default are encouraged to move from the Liberty skin to one of Miraheze's other skin offerings. You can enable new skins at Special:ManageWiki/extensions -> Skins on your wiki and set it as the default at Special:ManageWiki/settings -> Styling. Note that once the skin is removed and if it is your default skin, you'll be moved to the Vector skin automatically. If you don't have the skin enabled as the default, no further action is required.

Thank you for your understanding, Agent Isai  Talk to me! 12:00, 3 December 2021 (UTC)


 * Thanks for telling us. SoyokoAnis  12:14, 3 December 2021 (UTC)
 * Is there a method to identify and contact default users of Liberty directly? I can't imagine that on its own, this message will effectively reach the management of each affected wiki. --Raidarr (talk) 13:07, 3 December 2021 (UTC)
 * All affected wikis have been notified via a sitenotice like the one that appears here on Meta. Per our statistics however, it seems only 8 wikis have it set as the default. Agent Isai  Talk to me! 13:10, 3 December 2021 (UTC)
 * Great, that makes us safe, as long as the wikis/users in question have been notified. Ugochimobi (talk) 13:17, 3 December 2021 (UTC)
 * I don't use the skin, but giving something like this 2 days notice is not cool and is something right out of the Fandom book. Especially when 1.36 is not reaching its EOL until May 2022 and there is certainly no rush to update. Naleksuh (talk) 19:36, 3 December 2021 (UTC)
 * Timely updating is part of the Miraheze base pitch, but more advance notice would be good to consider going forward. --Raidarr (talk) 20:31, 3 December 2021 (UTC)
 * It's going to be a not-so-great change for those who wear the skin. I don't use it and I won't be sorry. But one must understand who is for good. so its good, even if it sejas one less skin. Let this new version come. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 21:07, 3 December 2021 (UTC)
 * I'm sorry that you feel like two days notice is not enough, we will keep your comments in mind and seek to provide notice earlier next time when possible. As for the no rush to upgrade argument, one of Miraheze's main commitments is to upgrade to the next version of MediaWiki in a timely manner, as Raidarr points out above. We don't think it would be fair to hold up an entire upgrade for all users simply because of one skin that isn't compatible and for which we have no reason to believe there will be a fix in the near future (based on the current activity of the developers). Maybe there is a reason that I'm missing but I personally don't see what would be different if the notice had been there five days instead of two for example, but as I say, a longer period of time is something we will consider in the future for such changes if that is what the community wishes. We are sorry that we have to remove Liberty but it is up to the developers to keep their extensions up to date and compatible with the latest versions of MediaWiki. Universal Omega does regularly help developers and fix bugs, but unfortunately the developers for Liberty don't seem to be interested in keeping it up to date with the latest stable version of MediaWiki. If wants to add something he should feel free. Reception123 (talk) ( C ) 11:15, 4 December 2021 (UTC)

I'd like to apply for Interwiki administration on my site
...now that enough time and edits have passed. (Only doing so because I'd like to get in my next two IW IDs any hour from now--and at the suggestion of and  from back in July.) This comes as I'm taking a break from conlang-dictionary entry-import duties; keep in mind I'm rescuing them from a now slower-than-laboratory-pitch Referata, a.k.a. what used to be the Semantic MediaWiki hotspot. (Long story...)


 * Wiki ID: constantnoble
 * Requested IWs:
 * mwe (mediawiki.org/wiki/Extension:$1 / MediaWiki extension details)
 * mwm (mediawiki.org/wiki/Manual:$1 / MediaWiki manual pages)


 * Active/Registered users: 1 (this founding contributor) / 25 (through Miraheze login)
 * Contributions by this applicant: Almost 9,000 (and please, no Dragon Ball jokes)

Over at Phabricator, I'm gearing up for my next filing--concerning a few issues I'm having with PageForms lately--and to I am awaiting a much-needed adjustment to my DPL3 install (whereby count in "ParametersData.php" must be raised from the default 500 [locally or otherwise] to get the correct result[s] for various page tallies in the resultsheader).

All this, as the 1.37 era is gradually approaching on here...

All right, / Have at it.

Once again, many thanks!

--Lily talk and I will listen · Lilypond Wiki 13:54, 14 December 2021 (UTC)

Imported infoboxes from Wikipedia aren't working
For my wiki, (Link), I wanted to use some infoboxes from Wikipedia. I followed the steps on the Miraheze page on importing infoboxes, but even though the templates for the infoboxes and their /doc versions are imported, it doesn't work. I enabled the extensions that the page explained were required, and it still did nothing. Whenever I want to edit an infobox now, it will let me insert the template, but not provide any fields for me put information into, showing a message that there are "no unused fields." Any help with this would be greatly appreciated. - IAmTheSenate (talk) 21:06, 11 December 2021 (UTC)
 * Hi, I'm the creator of the test page you're probably talking about. Note firstly that the page is in the process of being created and it is not recommended, yet, to follow what was written on it because everything is incomplete and in the middle it may fail. When that message appears explaining about missing module, example: There is no module with that name: Yesno you must create a Yesno module imported from Wikipedia. Your mistake is that the unused fields probably means you didn't put any message in the parameter or something. I've never had this error with me so I'm not exactly sure what this is. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 22:09, 11 December 2021 (UTC)
 * Your wiki is private, I can't see what's on it. I would even analyze what this is <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 22:12, 11 December 2021 (UTC)
 * If you're ok with doing so, I can add you as a member to analyze the situation. IAmTheSenate (talk) 03:56, 12 December 2021 (UTC)
 * yes I would like to see what's there <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 19:28, 12 December 2021 (UTC)
 * I've added you as a member now, so hopefully you can help find the problem. Thank you again for helping with this. IAmTheSenate (talk) 19:51, 12 December 2021 (UTC)
 * You must also add the extension TemplateStyles. I saw on your wiki that it is not activated. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 21:01, 12 December 2021 (UTC)
 * I believe I've done all the things you suggested in the edits, however nothing seems to be working. IAmTheSenate (talk) 21:58, 12 December 2021 (UTC)
 * I should also probably mention that I have not used MediaWiki before, nor Miraheze, so I don't have a full grasp of exactly how to do everything. IAmTheSenate (talk) 22:00, 12 December 2021 (UTC)
 * I also at first struggled to add infoboxes to the wiki.
 * All pages that say: "Page "Name of page/styles.css" must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text")", you delete and recreate with the same content. I saw here that you added the extension <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 22:27, 12 December 2021 (UTC)
 * Will solve? <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 00:03, 13 December 2021 (UTC)
 * Unforutnately no. I changed my user content model to Santitized CSS and I did so with the templates required for, in this case, the country infobox, and now it says they aren't in Santitized CSS when they are. It gives me this message on the template for the country infobox page: Page Module:Documentation/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text"). and Page Module:Hatnote/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").
 * I honestly cannot find what is wrong. IAmTheSenate (talk) 03:10, 13 December 2021 (UTC)
 * I will see. So, please, help to know what's going on here. you should also delete and restore the page again, as you had added the TemplateStyles extension. And not to have changed content model <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 03:45, 13 December 2021 (UTC)
 * Hi there, would you add me as a member of your wiki so I can fix this for you? Ugochimobi (talk) 05:35, 13 December 2021 (UTC)
 * Sure, thank you for offering your help. IAmTheSenate (talk) 21:48, 13 December 2021 (UTC)
 * He (Ugochimobi) understands about this and it's interesting that you add him as a member. <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 23:49, 13 December 2021 (UTC)

How to add OCR in a Miraheze wiki?
I have a wiki like Wikisource in Bengali Language. It is "গ্রন্থশালা". Here is an index page. Here I want to use Google OCR while proofreading. But, I failed to add OCR in this wiki. So, I am requesting you to help me in this regard. Thanks. MS Sakib (talk) 10:43, 10 December 2021 (UTC)


 * Hello there, kindly as that the Extension:Wikisource be installed. Request on Phabricator. This extension would do what you want. Ugochimobi (talk) 23:12, 10 December 2021 (UTC)
 * @Ugochimobi: Thanks a lot for responding. MS Sakib (talk) 20:36, 11 December 2021 (UTC)
 * no problem, you would find necessary documentation of the extension here. Ugochimobi (talk) 20:58, 11 December 2021 (UTC)
 * @Ugochimobi: I requested in Phabricator. But no solution was found. MS Sakib (talk) 19:55, 14 December 2021 (UTC)
 * It seems it's the Proofread extension that can be the only option, unfortunately. Ugochimobi (talk) 09:00, 15 December 2021 (UTC)

Modules
Hello? I'm new here. How can I add a navbox module for my wiki? LiaMinina (talk) 01:26, 15 December 2021 (UTC)


 * Go to Special:Import and scroll down to the "Import from another wiki" section, set Source wiki to meta, set Source page to Module:Navbox, and click Import. It will maybe require more modules so import those too. <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> AP 📨 03:03, 15 December 2021 (UTC)
 * Navbox is a more complicated thing just like Infobox. You must first configure them with MediaWiki:Common.css and js from Wikipedia. Any questions, send it to me <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 03:18, 15 December 2021 (UTC)
 * But how do I do that? LiaMinina (talk) 14:33, 15 December 2021 (UTC)

Another suggestion
A new special page or a new Special:ManageWiki section called "Quick templates". The special page would contain lots of buttons with names of commonly used templates (infobox, userbox, documentation, mbox, navbox, etc), clicking one of those buttons will import that template and also all modules needed for it to work. I'm coding an extension that does exactly that too haha <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> AP 📨 07:32, 16 December 2021 (UTC)

Security disclosure
Community members,

On 15 December, 2021, a security advisory was issued for MediaWiki, the software that powers Miraheze, which disclosed several security issues which allowed malicious actors who willingly attempted to see pages on private wikis to see them. Site Reliability Engineering was made aware of the issue and took steps to patch it temporarily while we upgraded to a newer version of MediaWiki which completely fixed the issue.

Unfortunately, due to an issue with one of our extensions, one of the several vulnerabilities was still exploitable for a short while after we patched all the other security issues. As a result, some pages on private wikis may have been accessible and made fully visible to malicious actors who purposefully attempted to view them using these exploits. We were able to verify that no one used this exploit to view private wiki contents and that the previous MediaWiki vulnerabilities were not used to view private wiki contents in the past few days. In keeping up with our transparency, we are informing the community so that they are aware. If you have any further questions, feel free to reply to this thread, thank you. Agent Isai Talk to me! 20:47, 16 December 2021 (UTC)


 * Hello. What was the extent/function that itself caused this incident? I was about to wonder if this is a new widge. If so, it's one less extension. And, what do you mean, see private wikis? Anyone could see the private wikis? or anyone had to have effort to see the content of private wikis beyond the main page? <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 20:52, 16 December 2021 (UTC)
 * The issues we in MediaWiki Core and made worse by MirahezeMagic. By performing certain actions, (undo, rollback, signature editing), it was possible to view private wiki contents. You would have had to have acted deliberately to view any content. It's not something anyone would have found by accident. ~ RhinosF1 - (chat)· acc· c -  21:53, 16 December 2021 (UTC)

Community Discussion: Wiki creators and creating wikis for themselves
Since an RfC would be too much for just one addition to the Wiki creator policy I am opening a Community Discussion here. As you all know, wiki creators are elected to serve the community and approve/decline wikis that are requested. They can in theory of course also approve their own wikis, but in my view for purposes of objectivity it would be preferred that they had another wiki creator do that.

However, what I'm proposing here isn't a complete ban on wiki creators creating their own wikis, it's simply the possibility for a Steward to remove a wiki creator if they are excessively create wikis for themselves and tend to not be creating wikis for other users.

The following would be added to "Revocation": A wiki creator's rights may also be removed by a Steward if they are mainly creating wikis for their own use and not focusing on their role of creating wikis for other users. Reception123 (talk) ( C ) 08:21, 7 December 2021 (UTC)

Support

 * 1)  as proposer. Reception123 (talk) ( C ) 08:23, 7 December 2021 (UTC)
 * 2)  Wiki creators should serve the community, not themselves. It wouldn't make sense if a wiki creator misused their privileges to create an excessive amount of wikis for themselves without any consequences.  Agent Isai  Talk to me! 08:23, 7 December 2021 (UTC)
 * 3)  The proposal pretty much covered it.  08:25, 7 December 2021 (UTC) ］ |
 * 4)  Why not?  Anpang   Talk   Stuff  08:27, 7 December 2021 (UTC)
 * 5) . This should stop wiki creator spam. TylerMagee (talk) 08:38, 7 December 2021 (UTC)
 * --Magogre (talk) 09:04, 7 December 2021 (UTC)
 * 1)  I don't really have to much to add, the post covered basically what I wanted to say on this issue. TigerBlazer (talk) 11:15, 7 December 2021 (UTC)
 * 2)  Ugochimobi (talk) 11:25, 7 December 2021 (UTC)
 * 3)  Don't get me wrong, I'm fine with wiki creators requesting wikis for themselves and self-approving it, but if it becomes excessive to the point of flooding the farmer log, then it does come off as either disruptive or somewhere between messy and cloggy like a clogged toilet. --DarkMatterMan4500 (talk) (contribs) 11:56, 7 December 2021 (UTC)
 * That's a fair point too, though I was more concerned with objectivity and creating more wikis for yourself rather than for other users. Since it's no secret what actions started this Community Discussion, I would point out that many requests that were made and 'self-approved' would have likely not been approved by another wiki creator, at least not by myself. Wiki creators also decline wiki requests if someone is requesting too many wikis, so it's definitely unfair that a wiki creator can create many wikis for themselves while regular users are told not to create an excessive amount. Reception123 (talk) ( C ) 12:07, 7 December 2021 (UTC)
 * Yes, that's very true. DarkMatterMan4500 (talk) (contribs) 13:50, 7 December 2021 (UTC)
 * 1) All users must respect the content policy and wiki creator is no exception <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ UnEdits </b>) <b style="font-size:9px; color: #000;>(Bring back patrolled)</b></b> 14:29, 7 December 2021 (UTC)
 * Well the Content Policy as such doesn't mention wiki creators creating an excessive amount of wikis for themselves at all, which is why I opened this Community Discussion, as there needs to be a separate ground beyond the CP removal ground. Reception123 (talk) ( C ) 15:44, 7 December 2021 (UTC)
 * that's right <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 23:19, 7 December 2021 (UTC)
 * 1)  Absolutely. I actually think it would be a good convention for a wiki creator to request a wiki and let another wiki creator approve it in the name of transparency, but I won't push for that here. --Raidarr (talk) 14:49, 7 December 2021 (UTC)
 * That's an interesting point yeah, I'm kind of undecided on that but related to what I say below I feel like if a wiki creator wants to create a wiki that they could see be declined by someone else they should wait for someone else to approve, but that's not really a clear question. Reception123 (talk) ( C ) 15:43, 7 December 2021 (UTC)
 * 1)  I agree with what is said above. Maybe this example is too extreme but it is like a judge deciding their own case. Here of course it is not nearly as serious or complicated but the principle still applies in that a judge is someone who is trusted and knows how to apply the law but that does not mean that they are trusted to apply it if they are involved in a case. In my personal view we are not being strict enough and I would go further than this proposal and vote for not allowing wiki creators to create their own wikis at all for reasons of impartiality; can someone really impartially interpret the Content Policy in regards to their own wiki? That is not however the subject here but in consequence I believe that it is perfectly desirable for a wiki creator to be removed if they are not adhering to their original "oath" which is to create wikis for other users, not for themself. I have seen the comments opposing the Steward discretion aspects of this proposal. While there is a point to the argument of not giving up everything to Stewards in this particular case I agree with what is said by Reception123 and believe that it would not necessarily be desirable to have a "direct democracy" model for these removals as is the case for other more positions. Sometimes it is necessary for the community to delegate their powers to Stewards and this situation is to me is one of those times. If Stewards are not trusted by the community then they should open a revocation request instead of attacking the discretionary powers of Stewards. Accordingly it is my strong view that it is not acceptable for a wiki creator to be focusing on creating multiple wikis for themselves and to not be creating almost any wikis for other users. --DeeM28 (talk) 09:23, 8 December 2021 (UTC)
 * 2)  I don't really see how this could be bad.  &mdash;Lakelimbo (talk)&emsp; 19:22, 15 December 2021 (UTC)

Oppose

 * 1) A wiki creator is someone who has the experience and trust to create wikis that can follow Miraheze policy, which you arguably can do best if you yourself are managing it. Whether or not people should be creating their own wikis is a seperate issue, but I don't think there is a distinguishment between doing so "mainly" and not. There is no obligation or commitment as a wiki creator, it is a volunteer position, and I do not support requiring people to "balance" with other wikis. Also, the proposed change is that any Steward can just take the permissions away unilaterally which is definitely a no-go. Changes like that should require consensus. Naleksuh (talk) 21:08, 7 December 2021 (UTC)
 * I also agree with you. No need for early revocation for a single basic reason <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 05:20, 8 December 2021 (UTC)
 * No one suggested that someone should be removed based on one instance and without warning. The suggestion that Stewards would take permissions away as they please suggests a lack of trust in the current Stewards to me which is a different issue altoghether.If there is not currently an obligation on a wiki creator to approve other users' wikis and not just create wikis for themselves, I think there should be, and this new addition to the policy would imply that. Stewards can already take permissions away unilaterally for violations of the Content Policy, so in that regard they already have a similar power, just limited to the CP. While "A wiki creator is someone who has the experience and trust to create wikis that can follow Miraheze policy" is true, what if a wiki creator has lost that trust because they're not creating wikis for users but just for themselves? There should be a way for them to be removed. Reception123 (talk) ( C ) 07:46, 8 December 2021 (UTC)
 * There should be a way for them to be removed. Yes, but that doesn't mean that way should be stewards unilaterally removing it. Also, removal should be because of creating wikis against policies, not by not creating enough wikis for people other than themself Naleksuh (talk) 01:05, 10 December 2021 (UTC)
 * 1)  if a wiki creator is only there approving their own requests, provided they are doing it properly, I see no problem with that - indeed it is beneficial to Miraheze as a whole as it means other wiki creators do not have to deal with them. If they are not doing so properly then a better proposal would be to ban wiki creators from approving their own requests. ~ El Komodos Drago (talk to me) 12:43, 10 December 2021 (UTC)
 * Well yes, the issue isn't about creating a few wikis for ones-self, it's basically about abusing the process and creating an amount of wikis for oneself that otherwise would have not reasonably been approved by any other wiki creator. While there is no hard rule, it is a convention that unless they have a good reason we don't really allow users to create a large amount of wikis for themselves. Reception123 (talk) ( C ) 07:00, 13 December 2021 (UTC)
 * Well propose that rule. It seems like you are trying to eliminate one behaviour by creating a rule banning an entirely separate one that seems (alone) to be harmless. This is bad rule making. ~ El Komodos Drago (talk to me) 11:04, 15 December 2021 (UTC)
 * 1)  – Mainly based on the Naleksuh's reasoning. I agree the removal should be performed if the wiki creator is creating wikis only for their own and/or against policy but it shouldn't be the unilateral decision of a steward to remove the rights without consulting the community. Stewards are trusted, but I do not feel comfortable with the rights being removed unilaterally by a steward if the user is elected by community. If community consultation added to the proposal, I'd completely agree with it. --Magogre (talk)  13:41, 10 December 2021 (UTC)
 * 2)  in part, per what others have said above, namely Naleksuh, Magogre, and El Komodos Drago, but also because I feel this proposal was made in response to a user who speaks little to no English, but who I might also add has created wikis for users and whose Content Policy understanding actually not that bad. As our only Chinese language wiki creator, if their bit was hypothetically removed by a Steward per this criterion, I feel they'd have a difficult time getting it back mainly because of their lack of Meta activity and command of the English language. As well, since the proposal is very, very vague, you potentially have a situation where one Steward might agree with revocation and another Steward might not. Moreover, though I generally prefer Steward discretion rather quantified details, I feel this is a case where it's better to be more explicit. What constitutes "for their own purposes"? One wiki? Ten wikis? 100 wikis? I guess I could potentially support something along these lines, but only an alternate proposal that (a) takes into account the above arguments, (b) quantifies specifics, (c) ideally is part of a larger RfC or an acknowledged prelude to a forthcoming RfC to amend the wiki creator inactivity and revocation clauses (i.e., for example, should the SRE revocation clause still exist? if so, under what conditions?), (d) takes into account the multilingual nature of Miraheze and Meta Wiki, and (e) requires at least super-majority (i.e., 75%) of existing Stewards to agree to the removal, if not unanimity, and only after, say, a thirty (30) day notice and remediation plan had been put forward to the wiki creator in question. Dmehus (talk) 07:37, 13 December 2021 (UTC)
 * To respond to your first point about the specific user I will admit I am not aware in respect of which user this request was made but I believe it is problematic for a wiki creator to speak no English especially if they are approving requests in English. I think it is quite obvious why such a situation is not desirable.
 * In regards to discretion I would currently support a wider discretion for Stewards to remove wiki creators generally beyond simply the Content Policy but based on the other opposes it appears to me that such a wide discretion is not desirable.
 * Regarding your proposal it appears to be too lenient for me. Why do wiki creators need to be given such a large measure of remediation options? If they are not creating wikis for other users they should be removed in my opinion and the community can reinstate them if that is what it wants. While there may be no appetite for this change my view is still that it would be simpler to not allow users to create their own wikis for reasons of impartiality.
 * To respond to the vagueness I am not sure how specifics would make sense in this context and how someone would be able to define a number of wikis that a person can create for themselves. I am confused as to the reason why you believe that in this case general Steward discretion is not appropriate; I think it is.
 * In conclusion my general view is that wiki creators need to be held to a higher level of scrutiny and it is better to remove more wiki creators if that is necessary to preserve the integrity of the process. Wiki creators can always be added back if they pledge to respect the rules and conventions in the future but I disagree with being overly lenient if they are not serving the community but are serving themselves. DeeM28 (talk) 18:43, 16 December 2021 (UTC)
 * The issue, though, is for the user in question, there's not really been any Content Policy issues in their wiki approvals. Dmehus (talk) 05:49, 20 December 2021 (UTC)
 * As for the discretion, I'm not necessarily opposed to Steward discretion, but this was hurried and rushed proposal, which even Reception123 admitted to me on IRC, that did not consider all of the procedural ramifications. What if one Steward disagrees with another Steward's removal? Can the rights be re-added without a community vote? Without some sort of readdition clause, or a thorough remediation and corrective action plan, we'd essentially be substituting one form of mob mentality !voting with another. I do agree with you that I feel for some positions, direct democracy is not the best form of appointment. I would be supportive of granting greater authority and discretion to Stewards to remove the  for more than just a defined inactivity clause or repeated Content Policy understanding and application issues, if we also allowed for Stewards to grant the   bit, perhaps on a temporary basis, where the request tends devolve into mere !voting based on English Wikipedia essays, so as to allow reasonable candidates, perhaps candidates who speak languages other than English, a track record by which the community could assess, from a practical standpoint, whether the user can consistently apply their understanding of Content Policy correctly. So, as an example, in such cases, Stewards could be granted the discretion to grant the bit on a temporary basis (say, for a maximum of 30 days), after which the bit would be automatically removed. Either shortly before their temporary status was due to expire, or after it had expired, the candidate would then be able to have a track record to cite to the community in standing for election as a permanent wiki creator. Additionally, I'm more inclined to support some sort of Meta Wiki only activity for the purposes of the inactivity clause, as we have some wiki creators who are globally active, but have not created one wiki. Thus why I feel a more major overhaul of the policy is needed. Dmehus (talk) 06:07, 20 December 2021 (UTC)

Comments

 * While I don't see the problem with self-approving wiki requests that other wiki creators have self-requested, it becomes a distraction to all others who would want to review the wiki request if it becomes excessive. --DarkMatterMan4500 (talk) (contribs) 12:07, 7 December 2021 (UTC)
 * I think it's worth mentioning that the case which lead to this conversation is a holdout of a time when WCs were appointed with little in the way of community input, and it was done two days before the process changed. Just an observation, not to fault the Steward at the time who made the call. --Raidarr (talk) 14:45, 7 December 2021 (UTC)
 * Indeed, the proposal may serve a limited purpose (for a single user) but I think either way it would make clear to any future wiki creators that when creating wikis for themselves if they choose to do so they should take the chance to think: would another wiki creator really have approved this if I was a regular user? Though of course its main point is limiting excessive wiki creations for ones-self which would not otherwise be approved of by any creator Reception123 (talk) ( C ) 15:42, 7 December 2021 (UTC)
 * By all means, this is very reasonable to do regardless of the 'catalyst' to propose. Plus it solidifies the precedent for new requests in the future. --Raidarr (talk) 15:55, 7 December 2021 (UTC)
 * Reception123 said he's open to having this essentially serve as a non-binding community input session, rather than any sort of binding policy-setting discussion, in view of the strong arguments presented in opposition. So essentially, the comments expressed herein would help to refine the aims of the proposal in a broader RfC that looks at reforming the wiki creator policy, perhaps in January or something. Based on the conversations I've had with Agent Isai on IRC, he seemed receptive to the idea as well. Dmehus (talk) 05:54, 20 December 2021 (UTC)
 * As pointed by the Naleksuh, I also believe a steward should not remove the rights unilaterally and I'd like it if somehow there should be a fixed time for the community to comment on the removal. A note on the AN or SN should be sufficient and anyone should be able to request the revocation of other's rights upon misuse. --Magogre (talk) 05:17, 8 December 2021 (UTC)
 * As commented above, this is already possible for Content Policy violations so this isn't some large new change that gives Stewards significant extra power. While this was never discussed before explicitly, my feeling is that the reason for why wiki creator revocations are Steward discretion rather than community consensus/vote is to avoid mob-mentality, for example people teaming up to remove a wiki creator because they disagree with their specific approval/disapproval of wiki requests. Again, that's just my view, it was never actually discussed in this way. Though either way, as I say above, if you disagree with the current Steward discretion that exists for revocation then that's a different issue because it already exists for CP violations. Reception123 (talk) ( C ) 07:50, 8 December 2021 (UTC)