Steward requests/Miscellaneous

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
← Requests and proposals Steward requests (Miscellaneous) Archives→
Shortcut:
SRM

This page is for Wikimedia wikis having no active administrators. Requests can be made here for specific administrative actions (such as page deletion) to be performed by a steward or global sysop. In other cases:

  • If the wiki does have active administrators, file the request with one of them.
  • If the wiki has an active editor community, any potentially controversial action (deletion of actual content, edit to a protected page, renaming of a protected page, etc.) should receive consensus from the wiki community before being requested here, and a link should be provided to that consensus in the request.
  • For global lock/block requests, file a request at Steward requests/Global.
  • For non-controversial deletion requests such as empty page, simple spam or vandalism, and non-controversial or emergency requests to block vandals, spammers or other malicious users, you may use global sysop requests instead.
  • If a consensus is considered required to act, similar principles apply as expressed at Steward requests/Permissions/Minimum voting requirements, and can be used for guidance to how and what should be done at small and medium communities to gain a consensus.

To add a new request, create a new section header at the bottom of the "Manual requests" section using the format below: 

=== Very brief description of request here ===
{{Status|In progress}}
Give details about your request here. --~~~~

It is helpful if you can provide a link to the wiki (or the specific page on the wiki) in question, either in the header or in the body of your request.

When reporting cross-wiki vandalism, the following template calls can be used to link to a user's contributions across all Wikimedia content wikis (these are for logged in users and non-logged-in users, respectively):

* {{sultool|Username}}

* {{luxotool|IP.address}}

Template {{LockHide}} can also be used in appropriate cases.

To request approval of OAuth consumers please use {{oauthapprequest}} (see the documentation before using).

Old requests are archived by the date of their last comment.


Cross-wiki requests
Meta-Wiki requests


Bot-reported requests[edit]

See Global sysops/Speedy delete requests.

Manual requests[edit]

Edit Interface of fa.wikibooks.org[edit]

Status:    In progress

I raised the issue on the VP and no one opposed it: fa:b:Special:Permalink/113740#تغییرات_رابط_کاربر

Please see b:fa:بحث_مدیاویکی:Common.js#Request_for_changes_moved_from_meta for the requested chnages.

My previous request was archived unsuccessfully: Steward_requests/Miscellaneous/2021-10#Edit_Interface_of_fa.wikibooks.org

Please note that the proposed changes have been taken from the English Wikibooks. If the English Wikibooks can have them, then Farsi Wikibooks can have them too. I'm not a regular editor of that project. I was asked to take care for this change, and I did that as a favour. I am a volunteer and not going to invest more time to look for better solutions. So, let's just copy&paste what I have prepared so far. I miss the old days when you could simply ask a local admin to edit the interface :(

Thanks, 4nn1l2 (talk) 03:53, 16 October 2021 (UTC)[reply]

@4nn1l2 What does this script do that the built-in .mw-collapsible doesn't? AntiCompositeNumber (talk) 02:41, 28 February 2022 (UTC)[reply]

Configure a Wikiset to opt out fawiki from GIBPE[edit]

Status:    In progress

Based on local community consensus at fa:ویکی‌پدیا:نظرخواهی/اصلاح_وپ:معاف#مستثنی_شدن_ویکی‌پدیای_فارسی_از_دسترسی_سراسری_معافیت_از_قطع_دسترسی_آی‌پی, I am requesting on behalf of fawiki that a Steward sets up a Wikiset here on Meta using which fawiki is opted out of GIPBE permission. All users who wish to bypass local or global IP blocks on fawiki shall request it locally at fa:ویکی‌پدیا:درخواست برای دسترسی/معافیت از قطع دسترسی نشانی اینترنتی.

I also suggest that GIPBE be edited to mention the above and provide a link to fa:ویکی‌پدیا:درخواست برای دسترسی/معافیت از قطع دسترسی نشانی اینترنتی. Furthermore, I propose that MediaWiki:Wikimedia-globalblocking-ipblocked-range is edited to include the following phrase: "If you have Global IP block exemption right, you may still need to request and receive local IP block exemption right on some projects".

The second paragraph consists of suggestions only; the community's wish, expressed in the first paragraph, would best be granted regardless of whether those suggestions are agreed to or not. Please {{ping}} me if you have any questions. Huji (talk) 01:25, 19 January 2022 (UTC)[reply]

Was the community informed that GIPBE only applies to global blocks and for local blocks people need to apply for local IPBE anyway? --Base (talk) 11:39, 19 January 2022 (UTC)[reply]
Huji, ^. --Base (talk) 11:39, 19 January 2022 (UTC)[reply]
@Base: yes. Fully aware. Huji (talk) 13:22, 19 January 2022 (UTC)[reply]

Can I voice my opposition to this. Global block means global. Global IPBE is to cover stewards actions. If you wish to locally block someone use local blocks. gIPBE is not circumvent any local blocks of a person or an IP address.  — billinghurst sDrewth 23:48, 19 January 2022 (UTC)[reply]

@Billinghurst: of course you can! And User:Martin Urbanec also shared some similar comments which you can now find in User_talk:Martin_Urbanec/Archives/2021#Global_group_opt-out_configuration. In short: (a) proxy blocks are often at the global level only, and for good reason (why repeat thousands of blocks on every project?); (b) fawiki is "special" in the number of its users who use proxies; (c) users who almost exclusively edit on fawiki have evaded proxy blocks by obtaining GIBPE and at least on two occasions, this has had negative consequences on local CUs' ability to run investigations on said users; and (d) if Stewards decide to reject the local community's wish, which I hope they don't, their decision would only be symbolic because fawiki will move on to the next option which is to import all global proxy blocks as local blocks, whereby GIPBE will become practically ineffective at fawiki.
So, you all are free to do as you wish. The outcome, one way or the other, is that fawiki will not allow anyone to circumvent blocks on open proxies unless they have locally been given IPBE access. Huji (talk) 00:08, 20 January 2022 (UTC)[reply]
What I am hearing is that there is something broken in the allocation of gIPBE that people have got through who should not, rather than allowing stewards to let through people are affected by their blocks. Your proposal is contrary to the whole scope and current design of global blocks and stewards' management of their blocks. It becomes a management nightmare. I believe that that this should be a global RfC due to what it could portent.  — billinghurst sDrewth 01:35, 20 January 2022 (UTC)[reply]
AND two occasions of slipping in the gIPBE is truly minor. How many socks do you have all the time, and people using unblocked proxies. It is an unproportional response to the problem and using a sledge hammer to crack a nut.  — billinghurst sDrewth 01:37, 20 January 2022 (UTC)[reply]
AND I wonder whether it is possible to omit a wiki, as the permissions look to be set by an extension, and not by a wikiset, so what ability is there to withdraw them with a wikiset?  — billinghurst sDrewth 01:45, 20 January 2022 (UTC)[reply]
@Billinghurst: Starting from your last point: I was told that Wikisets can be used here; if that is incorrect, I am happy to explore a way to modify the extension code or WMF config for it.
Your first point is accurate: part of the issue is GIPBE is given out not to users who are editing cross-wiki and are impacted by non-proxy IP blocks, but to users who are nearly exclusively editing in one or two projects and who are impacted by proxy IP blocks. But another part of it is that GIPBE may work for many projects, but its cost-benefit tradeoff is not the same for all projects. Specifically, for projects in which sockpuppetry through proxies is more common.
Again, I refer you to the discussion I had with Martin, in which I explained the three-step solution. Step one: reach consensus GIPBE should be given out more thoughtfully (Requests for comment/Global IPBE guidelines was created, but failed). Step two: reach consensus that GIPBE should not apply to certain projects in which the rate of open proxy use and sockpuppetry is high (consensus achieved on fawiki, request presented here is getting push back by you and formerly by Martin). Step three: make GIPBE obsolete on those projects (starting with fawiki) by importing hundreds of thousands of blocks (retrospectively and prospectively).
And guess what: if a user complains about the local block of a proxy where the block is imported from a global block, local community will not take responsibility for it and will refer the user to Meta to discuss the global block. So, once again, I emphasize that you all are free to choose what you want to do. The outcome is the same. The third option is just produces more workload for no good reason. Huji (talk) 13:36, 20 January 2022 (UTC)[reply]
Please do not expect any user to go to a user talk page to read about a proposal, and its history, the proposal should be a standalone proposal presented to the community in its entirety. This approach is a de facto attempt to circumvent the principles and fundamentals of global block and gIPBE and it should be put before the community to see whether any wiki has the right to opt-out of that system. Such changes belong as global RfCs. Your proposal simply makes it harder to explain the global system and so far this is due to two identified users, and where it relates to the application of rules of gIPBE by stewards.  — billinghurst sDrewth 20:52, 20 January 2022 (UTC)[reply]
zhwiki (which has a high rate of usage of open proxy due to GFW) choose the third option, we have an adminbot blocking OP. Since nearly all global blocked OP has a hard block locally, this seems not a problem if you guys reach the consensus of option 2. Stang 14:59, 20 January 2022 (UTC)[reply]
@Stang: would you think that if this proposal is implemented for fawiki, zhwiki would also seek to be in the opt-out and stop importing the blocks? Huji (talk) 17:07, 20 January 2022 (UTC)[reply]
That's the community's decision, but imo unlikely because a lot of locally blocked OP range is not blocked globally. Stang 17:10, 21 January 2022 (UTC)[reply]
I think that a simpler solution is that you should track the applications for the GIPBE and raise an objection in any questionable case. I actually have not recently seen a lot of users from fa.wiki requesting the GIPBE. Ruslik (talk) 21:03, 20 January 2022 (UTC)[reply]
@Ruslik0: It should be the user's responsibility to prove that they are impacted by a global non-proxy block; it should not be our job to prove that they are not, and are getting GIPBE to abuse proxies. If Meta fails to ascertain that, and fails to adopt a guideline to do so (see RfC link above), then instead of arguing with those individual users on Meta when they ask for GIPBE, I'd rather just do the obviously defensible thing: blocking all proxies locally.
Anyway, it seems like the gravity of the situation is not understood despite my multiple tries. Clearly, the other large wiki that I know would benefit from it (zhwiki) also has given up on Meta already and taken option #3. I am going to start importing blocks in a few days. It is up to Meta to decide if they think that should be the end of it (and close this request) or if all aspects of proxy blocks should be actively managed globally, in which case exemptions from them should be very selectively given.
Another option Meta may want to pursue: work with Extension developers to separate global proxy blocks from other global blocks, and then use GIPBE to exempt users from non-proxy global blocks only (and possibly use another very selectively given right to allow some users to globally evade proxy blocks).
I am keeping this request open because it seems like Stewards are choosing the overrule a local consensus, and this needs to be explicitly stated here and kept in the history.Huji (talk) 16:17, 22 January 2022 (UTC)[reply]
@Huji Please stop accusing stewards of overruling/ignoring consensus. No steward ever said anything like that in this discussion (nor elsewhere) and there was no decision made yet. As you can see, some of the wikimedians sharing their thoughts here are not stewards and as such, they can't speak on behalf of the stewards. The only stewards (me and @Ruslik0) who shared their opinion on this matter made it crystal clear it's their personal opinion only. As the SP says, "[stewards] do not lose the ability to think and feel because they have access to more buttons". Sincerely, Martin Urbanec (talk) 16:43, 22 January 2022 (UTC)[reply]
I am not sure what it has to do with the local consensus? Stewards decide, which IPs are globally blocked, and they also can exempt some users from their own global blocks. In addition, stewards are under no obligation to block all open proxies and moreover can unblock some of them if necessary. So, one wiki cannot dictate how global blocks are applied and who is exempted from them. Ruslik (talk) 21:05, 22 January 2022 (UTC)[reply]
@Martin Urbanec: Your point is fair: I should have used a conditional statement ("if the Stewards choose to overrule the local consensus ..."). Huji (talk) 20:46, 22 January 2022 (UTC)[reply]
Note: the reason of blocking webhost IP (i.e. proxy) in zhwiki is excessive proxy abuse by LTA, which is unrelated to GIPBE. See also local discussion. Thank you. SCP-2000 16:55, 22 January 2022 (UTC)[reply]
The reason for fawiki asking to be exempt from GIPBE is the same.
I think part of the problem is that a few projects have a much higher rate of proxy use than most other projects.
Another part of the problem is the way proxy blocks are executed (globally) and exemptions are executed for them via GIPBE (also globally, without considering impact on specific local communities). Huji (talk) 20:48, 22 January 2022 (UTC)[reply]
BUT All gIPBE does is reverse the impact of a stewards' action. It does nothing more or less. One gIPBE puts ONE specific account back to the status quo of the account, so that ONE account has the same editing rights as anyone not impacted by a steward's block. Stop beating this up to be more than it is. We all have problematic users, we all have users who abuse from dynamic ranges that cannot be blocked. Your wiki can use its granted rights and block problematic ranges just like any other. You have not been talking large numbers, and you have every opportunity to identify improvements to the system to the allocation of gIPBE WITHOUT having to change the bedrock of what global blocks and gIPBE are meant to be doing globally.  — billinghurst sDrewth 23:04, 22 January 2022 (UTC)[reply]
Comment CentralAuth developer note: Technically speaking (not commenting on if this is a good idea to implement) this can be done by creating an opt-out wiki set with fawiki in it, and then changing the GIPBE group to use that wiki set. Majavah (talk!) 15:08, 20 January 2022 (UTC)[reply]

For context, please see prior discussion about this at my talk page. --Martin Urbanec (talk) 00:05, 20 January 2022 (UTC)[reply]

@Huji: I've sent an email to the stewards internal mailing list to discuss this. Would you mind waiting at most two weeks (probably less than that, but giving us a reserve here) to go ahead with the local blocks? Thanks, —Thanks for the fish! talk•contribs 17:16, 22 January 2022 (UTC)[reply]

@Tks4Fish: yes, I find that agreeable. I will use the time between now and Feb 7 to write and test the code for the block importing bot, but I will not run it broadly until then (or sooner, if this discussion comes to a conclusion sooner). Thanks for the constructive suggestion. Huji (talk) 20:50, 22 January 2022 (UTC)[reply]

I'm not a huge fan of diluting the term “global”, to be honest. The reasoning is weak, too. A local community could neither decide to remove the stewards' ability to assign local user rights on every wiki. Seems like an issue to be taken to WMF what they consider stewards to be. Best, —DerHexer (Talk) 22:09, 22 January 2022 (UTC)[reply]

I share sDrewth's concerns and I've just asked WMF to give its opinion about the matter. --Vituzzu (talk) 22:09, 23 January 2022 (UTC)[reply]
  • I also would like to hear WMF's opinion, specially regarding the risk of privacy violation involving this change. Global block exemptions are many times discussed by stewards using private information. How is that going to be handled locally? I feel that we are creating a bigger problem instead of working on a simpler solution. This is the first time I am aware of that issue with block exemption on fawiki and believe we can come up with easier solutions. For instance, creating a better communication with local checkusers before approving exemption from users from fawiki or even other interested projects.—Teles «Talk ˱C L @ S˲» 22:45, 23 January 2022 (UTC)[reply]
    Your idea sounds like a much better solution. Letting a wiki opt-out of GIPBE seems like a significant overreaction. Legoktm (talk) 07:21, 24 January 2022 (UTC)[reply]
    @Teles: the point about privately discussing the reasons for GIPBE is valid; however, note that any wiki can decide to imports all global blocks as local blocks too, in which case the user inevitably has to discuss their reasoning for getting local IPBE with local sysops/CUs of that wiki too. I don't think Meta can disallow that, can they?
    The point about having a better system for assigning GIPBE is one already raised at Requests for comment/Global IPBE guidelines. Aside from a user who is active on fawiki, I see no other supporters. I also don't see much involvement from Stewards in that RfC. I cannot see a path forward for this argument.
    I also don't see much of a path forward with the current request. I am keeping it open just for the sake of fawiki seeing a clearly written decision on it. Huji (talk) 21:15, 24 January 2022 (UTC)[reply]
    I see this as very problematic to put global rights on optout. Global rights are there and necessary for global work.
    In my opinion, a single local community cannot apply for optout because it works within the global community. 𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 18:04, 29 January 2022 (UTC)[reply]
@Tks4Fish: given the above conversation, is there any response from Stewards on this matter, and should I proceed with enabling my block-importer bot? Huji (talk) 23:42, 7 February 2022 (UTC)[reply]

Import gadgets from enwiktionary to fawiktionary[edit]

Status:    In progress

Hello, I was fixing on the fa:hello, and during the comparing between the hello and the fa:hello, I see Show/Hide Toggles for header Template:trans-top in fawiktionary is disable.

In Template:trans-top because the following two gadgets is enable for everyone by default, Toggles in header of Template:trans-top is displayed.

I have a request that a admin import MediaWiki:Gadget-VisibilityToggles.js and MediaWiki:Gadget-defaultVisibilityToggles.js to MediaWiki:Gadget-VisibilityToggles.js and MediaWiki:Gadget-defaultVisibilityToggles.js , and so add required configs for definitions these two gadget from en:definition to fa:definition.

Beginneruser (Talk) 22:53, 9 May 2022 (UTC)[reply]

Help me?! Beginneruser (Talk) 22:12, 13 May 2022 (UTC)[reply]
(non-steward comment) Please ask @Ahmad252 for help, since fawikt has local interface admin. Stang 22:24, 13 May 2022 (UTC)[reply]
Hi @Stang,
I make a request import in this topic, But because all admin in this project are not very active, Me create a request in Meta.
Please if you have access help to me. Beginneruser (Talk) 22:39, 13 May 2022 (UTC)[reply]
I add new topic in user talk page of Ahmad252, I wait a week for to answer me. Beginneruser (Talk) 21:13, 15 May 2022 (UTC)[reply]
@Beginneruser: Just a quick message to let you know we've seen this 🙂 if you don't hear back from Ahmad252, a global interface administrator can take a look at this if there is sufficient local consensus — TNT (talk • she/her) 20:39, 16 May 2022 (UTC)[reply]
My sincere apologies for the delay. For some reason, I didn't get an email notification until after TheresNoTime's ping. I'll check right away. Thanks for your patience and for notifying me! Ahmadtalk 21:02, 16 May 2022 (UTC)[reply]
@Ahmad252, @Stang
Ahmad help me in wikt:fa:Special:PermaLink/844777 and wikt:fa:Special:PermaLink/844763
Pleas close and archive my request. Beginneruser (Talk) 23:22, 16 May 2022 (UTC)[reply]
Hello @TheresNoTime,
Ahmad252 answered me
Thanks. Beginneruser (Talk) 00:08, 17 May 2022 (UTC)[reply]

Edit ProofreadpageIndexTemplate be.wikisource.org[edit]

Status:    In progress

Please fix the mediawiki bug for the Index space in the Belarusian section. Example here--Arxivist (talk) 20:09, 18 June 2022 (UTC)[reply]

Please, provide precise instructions of what needs to be done. Ruslik (talk) 20:25, 19 June 2022 (UTC)[reply]

OAuth permissions[edit]

Symbol comment vote.svg Preferably permission requests should be submitted using the form from Special:OAuthConsumerRegistration.

After submitting this form, you will receive a token that your application will use to identify itself to MediaWiki. An OAuth administrator will need to approve your application before it can be authorized by other users. It is possible to request approval using {{oauthapprequest}}, please create a sub-section to this part.

A few recommendations and remarks:

  • Try to use as few grants as possible. Avoid grants that are not actually needed now.
  • Versions are of the form "major.minor.release" (the last two being optional) and increase as grant changes are needed.
  • Please provide a public RSA key (in PEM format) if possible; otherwise a (less secure) secret token will have to be used.
  • Use the JSON restrictions field to limit access of this consumer to IP addresses in those CIDR ranges.
  • You can use a project ID to restrict the consumer to a single project on this site (use "*" for all projects).
  • The email address provided must match that of your account (which must have been confirmed).

See also[edit]

Cooperation requests for: comments (local) (global) · translation

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Steward_requests/Miscellaneous&oldid=23427907"