Wikimedia Meta-Wiki

Community Wishlist Survey 2023/Admins and patrollers

< Community Wishlist Survey 2023
Community Wishlist Survey 2023
Admins and patrollers
16 proposals, 278 contributors, 651 support votes
The survey has closed. Thanks for your participation :)



Block history for individual IPs on ranges

  • Problem: It would be nice to be able to see the block history for individual IPs on a range when viewing the range's contribution history, both past and present. This is useful when evaluating whether a rangeblock against a vandal is desirable, what IPs the block needs (or doesn't need) to reach, and what blocks might be superseded if a rangeblock is imposed, a problem I've noted before.
  • Proposed solution: Allow block history for a range to be visible in the range's contributions history.
  • Who would benefit: Everybody who would benefit from more efficient blocking.
  • More comments:
  • Phabricator tickets: phab:T146628
  • Proposer: Daniel Case (talk) 05:06, 6 February 2023 (UTC)Reply[reply]

Discussion

  • There is a tool hosted on Toolforge called Rangeblock finder, which seems to cover what this asks for. And although it only supports enwiki, making it support other wikis should be trivial. Nardog (talk) 06:01, 6 February 2023 (UTC)Reply[reply]
    That is a possible solution and would be considerably easier than implementing it in MediaWiki, but I've added phab:T146628 to the proposal anyway as this would add IP range support for all log types. MusikAnimal (WMF) (talk) 22:17, 6 February 2023 (UTC)Reply[reply]
    I have bookmarked it and used it a couple of times. Daniel Case (talk) 02:47, 12 February 2023 (UTC)Reply[reply]
  • I am ok with it if it comes with ways of not block ISPs/Severs with dynamic IPs, some users, specially outside first world countries, may get blocked from using or edit wiki because some vandal happens to have the same,ISP provider as this person, I think that should be seem firest before a such tool be made Meganinja202 (talk) 14:37, 14 February 2023 (UTC)Reply[reply]
    This proposal is about block history for all IPs and subranges of a given range. Blocking functionality for ranges has been existing for a long time, and I don't think anybody is arguing that such blocks should be handled very carefully. ~~~~
    User:1234qwer1234qwer4 (talk)     16:47, 24 February 2023 (UTC)Reply[reply]

Voting

In Spam blacklist, allow sysops to enable blacklisting only on some namespaces

  • Problem: Adding a website on Mediawiki:Spam-blacklist prohibits everyone from adding the website everywhere on the wiki. But this is not always relevant: in many cases, it's only needed to prevent the website addition on mainspace, and the technical prohibition to use the URL on talk pages complicates discussions.
  • Proposed solution: Allow sysops to select, for each website added to the Spam blacklist, to which namespaces the prohibition is enabled. It would require to change/improve the currently raw interface of Mediawiki:Spam-blacklist.
  • Who would benefit: Everyone discussing spam or quality of sources.
  • More comments: Two examples of cases in which the blacklisting of an URL on all namespaces creates problems:
    • it's sometimes needed to discuss a blacklisted website by citing specific URLS;
    • adding the website to the spam-blacklist is often the subject of a prior discussion (on fr-wp, often on the talk page dedicated to the evaluation of sources quality, or on the antispam project talk page) with references of specific URL of the website. Once the website is blacklisted, it is not possible to archive the talk page, as it contains blacklisted URL.Improving Spam-blacklist interface would be an opportunity to add a specific area/text box dedicated to comments (the reason why each website has been blacklisted).
  • Phabricator tickets:
  • Proposer: — Jules* talk 16:54, 29 January 2023 (UTC)Reply[reply]

Discussion

  • Improving Spam-blacklist interface would also be an opportunity to add a specific area/text box dedicated to comments (the reason why each website has been blacklisted). — Jules* talk 17:06, 29 January 2023 (UTC)Reply[reply]
  • A very simple method to abuse this would be to create a blank page in a little-watched namespace where this link is permitted; transclude the new page in an article; after that add the link to the new blank page. If implemented, this request must have a simple method to prevent this. Animal lover 666 (talk) 21:16, 2 February 2023 (UTC)Reply[reply]
  • I think a more interesting fix would be implementing MCR for the spam whitelist, which I filed a while ago as phab:T203157. Then however the local wiki has decided to make edit requests can do so much more locally and quickly. Izno (talk) 06:58, 13 February 2023 (UTC)Reply[reply]

Voting

Stop-time blocks

  • Problem: Blocks are currently all running time ... they are set, and run the designated time, at the end of which they expire.

    This does not always deter vandals/disruptors blocked for the first or sometimes second time, as they can simply wait out the block, then come back and start right up again, perhaps getting away with more this next time. Eventually we have to block for longer amounts of time, which isn't fair, really, to other people on those IPs who might want to edit constructively or create accounts. Especially on ranges.

  • Proposed solution: Allow an admin to set a block to be tolled or, as we put it in the sport I officiate, "stop-time" (i.e., the normal arrangement for sports played in clocked time periods): Time on the block would run only as long as the IP or user was actively reading (and in the latter case, logged in) the wiki in question. By "actively reading", I mean clicking on links, viewing new pages, something that could easily be determined technically (I don't know how, it's not my department, but it seems from what I do know that it would be possible to monitor this and distinguish between a user looking at different pages (for what would be varying, yet realistic, amounts of times for a human to have looked at them) and a user trying to fool such a block with a script that just keeps refreshing the same small page over and over every second).

    These wouldn't have to be long periods of time, maybe 50 hours at the most (perhaps you'd want to go longer at places like educational institutions, where there's bound to be a higher amount of page viewing) to get their point across. It would make the magnitude of what they have done abundantly clear to those affected.

    We could also set these in multiples of five, independently of the clock.

    Since theoretically this could make a 20-hour block indefinite if the editor just gives up trying, admins (who would be able to see how much wikitime remains on the block) would of course have the discretion to lift these blocks if they had gone on for far longer than they would reasonably be expected to.

  • Who would benefit: Everyone. Productive editors would have less vandalism/disruption to deal with, admins might have to do less blocking and the admin work that comes with that, and prospective editors who just happened to pick the wrong school to go to would face less obstacles in making the kind of trial edits that could get them started.
  • More comments:
  • Phabricator tickets:
  • Proposer: Daniel Case (talk) 03:55, 5 February 2023 (UTC)Reply[reply]

Discussion

I appreciate that you're trying to come up with a solution, but I think this could be problematic. If I understood correctly, I as an admin would basically be able to "force" a user to spend an X amount of time online, on Wikipedia, clicking on links and so on, or else that person would not be able to edit again? Most of the vandals are probably less than 15 years old, and I would much rather want to tell them to go outside and/or do your homework instead of reading random pages on Wikipedia. Also, I'm pretty sure that letting admins see how much time someone spends on Wikipedia is against the privacy policy. -kyykaarme (talk) 10:00, 11 February 2023 (UTC)Reply[reply]

You could set this up so admins wouldn't be able to see the exact time left ... perhaps just an indicator that would go from red to yellow to green as the block progressed. Daniel Case (talk) 02:44, 12 February 2023 (UTC)Reply[reply]
  • I don't see how this is going to be implemented. First, logging "minutes spent on Wikipedia" requires some privacy issues. Secondly, the block will be unbearable and too long for all editors. Let's consider 24 hours block, a block that is given as a "first offense". A person averaged 4 minutes on every visit. Let's say people visit Wikipedia 3 times a day, which goes for 12 minutes every day. Then, for 24 hours block, it will take 120 days for the editor to be unblocked. I usually spend around 4 hours per week reading Wikipedia outside editing, which is way above the average user. It will take me 45 days for a 24-hour block to expire. If you want stricter/stronger punishment, a longer block is an easier solution. SunDawn (talk) 12:34, 11 February 2023 (UTC)Reply[reply]
    You'd go with a shorter block than 24 hours. Maybe 10. Daniel Case (talk) 23:51, 11 February 2023 (UTC)Reply[reply]
    Also, remember, blocks are not supposed to be punitive. We are getting to the point where in some situations (range blocks, block evasions using IPs) admins are increasingly opting for longer blocks on the first offense. This is going to hurt us with some prospective editors who may want to start an account, find that their school or whatever was blocked six months ago and will be blocked for another six months when they can't, and then just give up on ever getting involved. Daniel Case (talk) 02:44, 12 February 2023 (UTC)Reply[reply]

Voting

Add link to CentralAuth on Special:Contributions

  • Problem: Admins, patrollers, and other editors often find useful to find out whether someone has been blocked elsewhere, or which other wikis they're active in. However, there are no easy links to Special:CentralAuth in the interface.
  • Proposed solution: The top of Special:Contributions has a line that says "For Example (talk | block log | uploads | logs | abuse log)". A link to Special:CentralAuth should be added to this handy list of links.
  • Who would benefit: Admins, patrollers, translators, community event organizers, and anyone who needs to find someone who is familiar with a different language or different wiki. (Also, in a more light-hearted way, it will be convenient for anyone who wants to check their own edit count total across all the wikis. This is not an important use, but sometimes it's fun to discover that you've passed a milestone number.)
  • More comments:
  • Phabricator tickets: T331743
  • Proposer: WhatamIdoing (talk) 23:39, 24 January 2023 (UTC)Reply[reply]

Discussion

  • If you're asking for enwiki, there's a link at the bottom of a user's contributions page – link "accounts", here en:MediaWiki:Sp-contributions-footer. If it's for some other wiki, any sysop can edit the MediaWiki message. If you still want it on the top, I'm not sure if there would be enough space for the link in that one line. But I agree, it helps to have the CentralAuth link handy. ponor (talk) 01:13, 25 January 2023 (UTC)Reply[reply]
    I'm asking for this to be present at all the wikis, not just the biggest, and especially including the many wikis that don't have any admins who feel comfortable editing the interface. WhatamIdoing (talk) 06:28, 1 February 2023 (UTC)Reply[reply]
  • Sure, there's also this that you can use: User:Linedwell/centralauthlink.js. Stryn (talk) 06:42, 25 January 2023 (UTC)Reply[reply]
    Another script you can use, which I use globally, is CAWhoisProxy.js. Sdrqaz (talk) 17:29, 26 January 2023 (UTC)Reply[reply]
    Sure, there are scripts that I already use, but this should be available to everyone, not just to the highly experienced editors who know where to ask or how to find the magical scripts. WhatamIdoing (talk) 06:29, 1 February 2023 (UTC)Reply[reply]
  • Many projects already include this somewhere on that page, typically in the footer. Not sure the mediawiki software should be changed just for this. — xaosflux Talk 14:59, 26 January 2023 (UTC)Reply[reply]
    This does seem like something the software can be expected to offer, and should be trivial to add. Also, on a very technical level, it's not guaranteed that Special:CentralAuth/Foo will be the same user (although the only SUL stragglers are now ancient bots and users with weird one-off migration bugs) so it's better done by the software. Tgr (talk) 02:01, 1 February 2023 (UTC)Reply[reply]
  • They are already included at the end of the contribution page, but not all wikis show these links. Thingofme (talk) 03:11, 28 January 2023 (UTC)Reply[reply]
  • The link at the bottom (in some wikis) is pretty inconvenient. I think CentralAuth does belong to the top links. It is probably useful to even a bigger audience than, let's say, abuse logs. MarioGom (talk) 17:38, 28 January 2023 (UTC)Reply[reply]
  • Note that the Sp-contributions-footer links are unreliable: apart from the fact that every community has to set them up on their own, if you read English Wikipedia with a non-English interface language you probably won't see them (due to T57473). I would actually go the opposite direction and add the widely-used, well-maintained tools from the footer via the ContributionsToolLinks hook. --Tgr (talk) 05:27, 1 February 2023 (UTC)Reply[reply]
    That sounds much more complicated, so I'd rather leave it for another time. Among the complications, I believe that Toolforge has rules against having anything in MediaWiki depend on its tools, and the non-WMF-hosted tools have privacy challenges. For example, if you click a link on the English Wikipedia to geolocate an IP address at a third-party website, you are inadvertently telling that third-party that someone at the English Wikipedia is interested in that IP. This might not be very valuable information (I hope), but it's not really living up to our ideals about privacy, either. WhatamIdoing (talk) 06:34, 1 February 2023 (UTC)Reply[reply]
    Differentiating between what can be linked from the footer vs. what can be linked from the header just because they happen to be generated via different means doesn't seem useful to me. Tgr (talk) 07:27, 1 February 2023 (UTC)Reply[reply]
    I've been poking at this problem for years. Main notes are in phab:T140585 and details at mw:Notes for potentially moving some mediawiki system messages into wikimediamessages (and linked subpages one and two) (and older notes in my old comment that was forked into phab:T67446). I believe the solution is to (1) research the most-used links, and their ordering, in the wikis which currently use these systems, (2) use Extension:WikimediaMessages to make a new 'default'. -- I've been blocked on 2, as it needs dev-confirmation that this is the best route forward. But I'd also welcome the CommTech team taking on the research and outreach aspects. Quiddity (talk) 20:32, 6 February 2023 (UTC)Reply[reply]
  • This indeed should be visible on all wikis. Taylor 49 (talk) 10:14, 5 February 2023 (UTC)Reply[reply]
  • Maybe the contribution footer with CentralAuth and editcount link should be the default on all Wikimedia wikis, no matter how big or how small. Thingofme (talk) 14:43, 6 February 2023 (UTC)Reply[reply]
    Strongly support this. If a certain project doesn't want it or wants a different set/sequence of links at the footer, they are always free to edit the relevant MediaWiki page. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:44, 17 February 2023 (UTC)Reply[reply]
  • See also w:User:The Voidwalker/centralAuthLink.js. ~~~~
    User:1234qwer1234qwer4 (talk)     17:17, 24 February 2023 (UTC)Reply[reply]
  •   Question: I've picked this up (T331743 / patch) as a quick little task to do, and a question of user experience has been raised. So rather than us guess what y'all want, I thought it was best to just ask: when you click on this new CentralAuth link in the ContributionsToolLinks, would you want that to go to the local Special:CentralAuth (i.e., if you were on the English Wikipedia, the link would go to en:Special:CentralAuth) or always come to Special:CentralAuth here on Meta? — TheresNoTime (talk • they/them) 22:57, 10 March 2023 (UTC)Reply[reply]
    As there's no difference in the results shown, I don't care which wiki it's displayed on. WhatamIdoing (talk) 19:22, 11 March 2023 (UTC)Reply[reply]
    I always go to Meta, so that what is essentially the same page has only one entry in my browser history and is in the language I'm familiar with (also "Previous global account changes" only seems to appear on Meta). I get sending the user to another site could be contra expectation though (if so I'll keep on using my MoreMenu custom link). Nardog (talk) 19:46, 11 March 2023 (UTC)Reply[reply]
    Local CA page is useless for stewards, I never use it. If it links to a local CA page at least a local CA page should include a link to CA on Meta. Stryn (talk) 07:13, 12 March 2023 (UTC)Reply[reply]

Voting

Layering/timing of blocks

  • Problem: Twofold:
    • The introduction of partial blocks was long overdue. However, admins are still limited to one or the other. When a user has, say, edit-warred on an article but contributes constructively elsewhere, we can either block sitewide for a short time or partial block for a long time. Both options present a tradeoff. The shorter sitewide block may seem unfair to the blocked user since it was only one article, and for other editors on the page it is entirely possible that once the block expires the blocked user just goes back to the edit warring because, y'know, they were right. But a longer partial block may seem too lenient if the edit warring on the one article was particularly egregious (i.e., one or two reverts a day, incivil edit summaries, etc.).
    • I was asked a while back by a user to block sitewide a range that was already under long-term partial block on several other articles; they may have been at the limit. I had to decline since changing to a sitewide block would completely wipe out the partial block ... i.e., once the sitewide block expired the range would be free.
  • Proposed solution: Allow blocks to be layered, with a partial block running concurrently with a shorter sitewide block. I've read that this is not possible technically at the moment. If it indeed isn't, perhaps we could set things up so that the partial block would begin only upon the expiration of the sitewide block, i.e., User X is blocked 24 hours for violating 3RR and then for a week from the article or articles where the violation occurred. Yes, you could do this all manually now, but it gets kind of messy.
  • Who would benefit: Editors who will know that there is a greater risk to edit warring or generally tendentious/disruptive behavior, facilitating more constructive collaboration; editors blocked for such conduct who will have the chance to show that they can edit constructively off a certain article/topic, and admins working to prevent such disruption.
  • More comments: It would also be useful to allow this same functionality for page protection ... i.e. page Foo will be extended-confirmed protected for, say, a month, and then automatically drop down to semi-protection for the next five or whatever. Daniel Case (talk) 05:09, 6 February 2023 (UTC)Reply[reply]
  • Phabricator tickets: phab:T194697
  • Proposer: Daniel Case (talk) 20:20, 3 February 2023 (UTC)Reply[reply]

Discussion

Voting

Option to show changes from subcategories when viewing related changes of a category

  • Problem: Using the Special:RelatedChanges page of a Category shows the changes related to the pages contained in that category.
  • Proposed solution: However, for some patrollers, it may be beneficial to control edits from a parent category.
  • Who would benefit: Patrollers and users
  • More comments: For example, if I wanted to check all the changes related to the London category and its subcategories, at the moment I can't do it, I have to manually check each category, while it would be useful to have a setting which, once activated, allows me to see the changes made even in subcategories.
  • Phabricator tickets:
  • Proposer: --Mannivu · ✉ 19:02, 23 January 2023 (UTC)Reply[reply]

Discussion

@Mannivu: Thanks for sharing this suggested improvement. Could you clarify the proposed solution? I think what you mean is that, when using Special:RelatedChanges for a category, you would like the option to also display changes from subcategories - is that right? One top-of-mind concern I'll just note on this is that MediaWiki categories can be circular and/or incredibly deep, so this might need to be limited to direct subcategories. Samwalton9 (WMF) (talk) 13:26, 30 January 2023 (UTC)Reply[reply]
@Samwalton9 (WMF) yes, my idea is that I'd like to have an option that the user can activate in order to see the changes from subcategories of a given category. Maybe it could also let the user set a deep option (i.e. 2 for the direct subcategories and their subcategories). --Mannivu · ✉ 13:37, 30 January 2023 (UTC)Reply[reply]
So far RelatedChanges does not even seem to support transclusions, which (unlike subcategories) is included in Special:WhatLinksHere. ~~~~
User:1234qwer1234qwer4 (talk) 16:57, 24 February 2023 (UTC)Reply[reply]

Voting

Utility to attach acccount to all wikis

  • Problem: There are over 800 WMF wiki's that cross-project contributors may use. Users may autocreate accounts on projects by visiting, however it only occurs by logging in to the project.
  • Proposed solution: Create a function that will attach an existing CentralAuth user to every project.
  • Who would benefit: Stewards, Global Rollbackers, Global Sysops, the Small Wiki Monitoring Team, and others doing massively cross-project support
  • More comments: There used to be a userscript to help with this process, however it is not compatible with current browsers.
  • Phabricator tickets:
  • Proposer: — xaosflux Talk 17:03, 3 February 2023 (UTC)Reply[reply]

Discussion

  • To reduce certain abuse factors, may want to limit to a permission. — xaosflux Talk 17:09, 3 February 2023 (UTC)Reply[reply]
    @Xaosflux Would fixing the user script be a solution? I wonder how many people really want this functionality and whether it really belongs as part of mw:Extension:CentralAuth. But if it's restricted to some permission, as you say, I suppose it's harmless to implement it directly in MediaWiki.
    Either way we will approve this proposal, but if most people are content with a working script, I imagine that can be done quite easily – likely within a day. MusikAnimal (WMF) (talk) 18:31, 3 February 2023 (UTC)Reply[reply]
    @MusikAnimal (WMF) since this is really only for massive centralauth deployments (which practically is only the WMF cluster) - script based should still be fine (we could even gadgetize it here). We certainly didn't require a permission for a script - but was trying to not make it too easy for User:DisruptiveUsername to show up on hundreds of account creation logs at once. — xaosflux Talk 18:37, 3 February 2023 (UTC)Reply[reply]
    Got it! I will accept this proposal as-is, then, but I imagine a script is what we'll actually do. This wish may or may not be granted before the survey even finishes :) MusikAnimal (WMF) (talk) 20:47, 3 February 2023 (UTC)Reply[reply]
    Possible patch to old userscript listed at User_talk:Krinkle/Tools#running_Global_SUL.js_does_not_create_local_accounts by User:Suffusion of Yellow. — xaosflux Talk 01:56, 6 February 2023 (UTC)Reply[reply]
    Path appears to work. — xaosflux Talk 17:43, 9 February 2023 (UTC)Reply[reply]
    The patch has been applied to the original script which fulfills this wish before voting is even complete. --BDavis (WMF) (talk) 21:36, 10 February 2023 (UTC)Reply[reply]
  • I don't get the point of this proposal. What would it actually improve? It would make the local account autocreation log entirely useless (granted I'm not sure how useful it is now), in exchange you'd have accounts on wikis you have never visited... what for? --Tgr (talk) 05:48, 6 February 2023 (UTC)Reply[reply]
    @Tgr, may be helpful for local searching by others users perhaps, for receiving a message by mail or at own talk page locally. Also the user will have the ability to be notified.
    @MusikAnimal (WMF): I wonder what will be the underlying IP of accounts created. There may have privacy concerns. If the IP is owned by the account owner, they will leave too many tracks, and they will be able to be checked everywhere, which is good and bad at same time. If that’s someone else’s IP, that can be confusing. Just thought about it. —Teles «Talk ˱C L @ S˲» 16:20, 9 February 2023 (UTC)Reply[reply]
    @Teles Today, script-wise, it is the enduser ip; the same as if they just visit a new project SUL logs them in. — xaosflux Talk 11:05, 12 February 2023 (UTC)Reply[reply]
    @Xaosflux, got it. Tks. —Teles «Talk ˱C L @ S˲» 16:08, 13 February 2023 (UTC)Reply[reply]
  • maybe... but why doe still have local accounts ? Maybe its time to get rid of that instead ? one step closer now that actor migration is so much further along. —TheDJ (talk • contribs) 14:13, 18 February 2023 (UTC)Reply[reply]
    Might want to add the script as a gadget here on Meta (restricting to autopatrolled or similar would probably be sensible) but I don't think this needs a native implementation. ~~~~
    User:1234qwer1234qwer4 (talk)     17:02, 24 February 2023 (UTC)Reply[reply]
  • @Xaosflux: I've marked this as   Done by Suffusion of Yellow, given that Krinkle's user script now works — does that sound okay? — TheresNoTime (talk • they/them) 19:49, 14 March 2023 (UTC)Reply[reply]
    I'd think so, unless someone really wants to write a path to SUL for this! — xaosflux Talk 21:14, 14 March 2023 (UTC)Reply[reply]

Voting