Jump to content

Community Wishlist Survey 2023/Admins and patrollers

From Meta, a Wikimedia project coordination wiki
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]


  • 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]
    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]


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]


  • 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]
  • 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]
  • 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]


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]


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]

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]
  • 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]
    You'd go with a shorter block than 24 hours. Maybe 10. Daniel Case (talk) 23:51, 11 February 2023 (UTC)[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]


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]



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]
  • Phabricator tickets: phab:T194697
  • Proposer: Daniel Case (talk) 20:20, 3 February 2023 (UTC)[reply]


We have an important update about this wish – October 17, 2023

Hello Daniel Case, and everyone supporting this request about blocks.

We have selected this wish for fulfillment, and as usual, we have created a project page to share information about our approach and give you space to give feedback.

Please note that the project has been renamed Multiblocks.

Visit the project page to learn more about the scope of work, constraints, and the status of our technical investigation into this wish.

Please read what we have presented, and give us feedback immediately if you disagree with anything. We would also like to know if you agree with our approach.

Thank you. ––– STei (WMF) (talk) 22:25, 17 October 2023 (UTC)[reply]

We have updated the project page – November 10, 2023

We have added more information in November 2023 about our technical investigation of the wish, and a brief glossary of terms used on the project page. Please check and give feedback on the project talkpage.

–– STei (WMF) (talk) 19:00, 10 November 2023 (UTC)[reply]

Pinging users: –– STei (WMF) (talk) 19:00, 10 November 2023 (UTC)[reply]


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]


@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]
@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]
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]


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]



Enable removing block log entries entirely, not just redacting

  • Problem: When an administrator perceives a wrong block and/or one considered incorrect by the local community, it is in the Block log history (Special:Log/block) of the user.
  • Proposed solution: The idea would be to delete this permanently, keeping only a record of correct and valid blocks.
  • Who would benefit: Everyone would benefit, as the history of incorrect blocks could be removed, in addition to the administrators being more cautious in the application of blocks that are in the local blocking policy.
  • More comments: The approved proposal would be implemented in all Wiki projects. Each local community would establish rules to remove the "block log" from users (obviously it would be for cases of wrong blocks).
  • Phabricator tickets:
  • Proposer: WikiFer msg 14:26, 5 February 2023 (UTC)[reply]


Comment Comment Although it is possible to hide the blocking log, the suppression policy of each local community may not allow this use to hide a blocking considered incorrect. That's why I created this proposal, so that there would be no link with the suppressors. WikiFer msg 04:56, 6 February 2023 (UTC)[reply]

@WikiFer If I'm understanding you correctly, are you proposing a mechanism by which the community could collectively remove the log entry without requiring an admin/suppressor to be the one to enact the consensus? Samwalton9 (WMF) (talk) 10:42, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) The admin will still be responsible for clearing the lock log, but it wouldn't be considered a hide in the way suppressors use it. The consensus for applying this removal would be by consensus among local administrators. WikiFer msg 11:34, 6 February 2023 (UTC)[reply]
@WikiFer I'm not sure I understand your proposal and how it's different from what is currently possible - could you elaborate on what the difference is? Samwalton9 (WMF) (talk) 12:49, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) See this example here, it has the block log where a user was unblocked because another administrator objected to the block. My proposal is to remove this block log of user, leaving the his account without any blocking records. If it was unlocked because the lock was incorrect, it shouldn't be part of this history. WikiFer msg 13:03, 6 February 2023 (UTC)[reply]
@WikiFer Here you can see a test I just did where I removed blocks from the logs for my test account. Are you suggesting that the software should enable you to remove those log entries entirely, rather than have "removed" text in the log? Samwalton9 (WMF) (talk) 13:35, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) Exactly. The proposal is for the software to remove log entries of locks that the local community has deemed to be incorrect. In the example you showed, the lock configuration change is another log. The proposal is not to remove only text, but not to appear in the account history anymore. WikiFer msg 13:56, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) Another better example was this administrative war of blocking and unblocking this account only on December 30, 2020 on Portuguese Wikipedia. My proposal is to leave this entire history blank, as if there were no blocks. WikiFer msg 14:00, 6 February 2023 (UTC)[reply]
@WikiFer Gotcha. I've updated the proposal title to clarify this. Samwalton9 (WMF) (talk) 14:50, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) @WikiFer Note that if you use RevDel (aka redaction) on all fields, the entry is completely hidden from the log. Only users who have the ability to change the visibility of the log entry will be able to see it, and they will see it as "([field] removed)". In this case that is only admins, but you can use suppression to hide it from them, too. Are we sure that doesn't satisfy the wish?
I don't think full proper deletion from the database is something that would be considered. We could add yet another layer of visibility, as in something above suppression, but is there really any point in doing that? MusikAnimal (WMF) (talk) 16:49, 6 February 2023 (UTC)[reply]
@MusikAnimal (WMF) In this example, it would be unfair for a person to have a history of having their account blocked due to an administrative war. I think that in situations like this, deleting database locks would resolve unfairness. WikiFer msg 16:58, 6 February 2023 (UTC)[reply]
@WikiFer "Deleting" isn't really a thing. I see now above you said you wanted something that worked without the assistance of suppression, but I still have the same concerns. We need a log of everything that happens. Anything done by an admin should be auitable by another admin. If we want it hidden from admins, use suppression. In your example, if you use RevisionDelete, the log entries are only visible to 49 users (and those users will see it as "hidden" and have to click through to see what actually happened). To everyone else (non-admins), they won't see the log entries at all. If suppression is used, it brings down the visibility to just three users, who again will see them as "hidden" and have to click through if they want more information. MusikAnimal (WMF) (talk) 17:02, 6 February 2023 (UTC)[reply]
@MusikAnimal (WMF) Oh, huh. I swear I tested looking at the Samwalton9Testing block log from a non-admin account and could still see the deleted logs, but now I'm looking again I don't see them, so maybe it was an account cache issue. I agree that there's not much else to be done if that's the current behaviour. Samwalton9 (WMF) (talk) 17:29, 6 February 2023 (UTC)[reply]
I'd like to hear confirmation from @WikiFer first, but I'm thinking this proposal could be archived as there are existing solutions. I'm unclear on why we would need the ability for admins to completely hide block log entries from other admins. Those other admins will see "[field] removed", and if they use the "Change visibility" link or check the deletion log, they will see the rationale which for this use case would say something like "accidental block". That is by design. All actions in MediaWiki are intended to be audited. Imagine a rogue admin who remove visibility of the blocks they made, and also the log entries of them changing the visibility.
As I said suppression can be used to hide the entries from admins, too, but I don't see the point as admins can already confirm the blocks are invalid. MusikAnimal (WMF) (talk) 18:57, 6 February 2023 (UTC)[reply]
@MusikAnimal (WMF) As I already opened the proposal, the ideal thing is for the community to manifest itself in a vote, since the tool for hiding administrators is just another blocking log, a new administrative action that can only be used if the username is incorrect, or the edit summary violates the local hiding policy. I believe that wrongs blocks should be removed from an account's history, and admins will be able to set this by consensus on each project. WikiFer msg 19:16, 6 February 2023 (UTC)[reply]
My point is that what you're proposing is already possible. I don't think anything new needs to be engineered. But, the proposal is actually already approved, so as it stands now it's going to voting. MusikAnimal (WMF) (talk) 17:22, 7 February 2023 (UTC)[reply]

I come to this discussion from a situation where this was an issue. I opposed because I agree that, as framed, leaving it solely to administrative discretion is too open a door to abuse.

But ... certainly someone who gets mistakenly blocked for a few hours after, say, 15 years of productive, block-free editing might be entitled to ask for this sort of expungement, which could be granted through community consensus and only a limited number of users (i.e., the OS team, maybe) could actually do it.

Maybe we'll consider that proposal next year. Daniel Case (talk) 02:37, 12 February 2023 (UTC)[reply]

I am that soldier! (Hi Daniel!) Yes, I would like my 15-year clean block log record back, please! Note also the provisions of the EU's General Data Protection Regulations. Included in the seven principles of GDPR are two that are very relevant: a) the requirement for accuracy (and the consequent right to have incorrect information amended or deleted!); and b) the principle of accountability (which means that Data Controllers need to ensure that they not only comply with the principles, but also have appropriate processes and records in place to demonstrate compliance.) Other jurisdictions have similar laws in place. Now, it may well be the case that RevDel meets those criteria (as only other delegated Data Controllers can see the logs), but the proposal should not be dismmised out of hand. Bastun (talk) 11:09, 13 February 2023 (UTC)[reply]


Display a notice on newly created articles

  • Problem: For many wikipedians, Admins and Patrollers don't leave enough time to do some articles. Me for example, I create an article and 8 minutes later it was deleted.
  • Proposed solution: Display a notice on newly created articles, for maybe 30 minutes, noting that it has only just been created.
  • Who would benefit: Anyone who want to do articles
  • More comments:
  • Phabricator tickets:
  • Proposer: Owee mªthias (talk) 17:23, 29 January 2023 (UTC)[reply]



@Anrchyte: Yeah, it's called sandboxes and drafts. Mr. C.C.Hey yo!I didn't do it! 07:37, 11 February 2023 (UTC)[reply]

Allow viewing of edit filter logs for IP ranges

  • Problem: Administrators doing anti-vandal work on (at least) the English Wikipedia are increasingly blocking the /64 range when faced with vandalism from IPv6 addresses, reflecting the practice of many ISPs of assigning those ranges to a single user, as long as it can be found that this is the case for the /64 range in question. But while it is also common to review edit filter logs for an IP address in the course of assessing the severity of the vandalism or disruption (most importantly, whether the user has been warned by the filter that they are risking a block should they continue), the filter logs can only be reviewed for a single IP at a time. This makes it difficult to determine whether a /64 rangeblock, or even any block, would be warranted for a particular vandal for whom only the edit filter logs are available
  • Proposed solution: Make it possible to view edits on the /64 range for any IPv6 address whose edits are caught by an edit filter. Or at least give filter creators the option of allowing that (I can see that there might be situations where you might not want anybody doing that, or, at least, not just any admin).
  • Who would benefit: Admins who could more efficiently and effectively prevent damage to the project, and editors who could contribute more productively without having to revert vandals or, especially, the LTAs that the filters are primarily meant to deter and warn about.
  • More comments: Possibly this could, maybe in the future, be applied to the /24–/30 ranges on IPv4 addresses if it is considered necessary. Maybe we should also allow the option of being able to see the relevant ranges with a link from the Contributions page (similar to how the basic reporting template for WP:AIV now displays a link to the /64 for any IPv6 reported to the page) as well; currently one must manually enter the range value desired in the browser's URL window after the IP address. But that might make a better separate proposal.
  • Phabricator tickets: phab:T256823
  • Proposer: Daniel Case (talk) 05:03, 30 January 2023 (UTC)[reply]


Currently, it is possible to search for ranges only on Special:Contributions. There are even more views that would benefit from such a feature: Special:Log (phab:T146628, phab:T188690), Special:DeletedContributions, Special:AbuseFilter/test (phab:T257420). Maybe a way to make it work for any similar view could also be made.
Yet, there is the ongoing IP masking initiative that will probably soon change patterns of anti-vandalism efforts regarding IP's. --Matěj Suchánek (talk) 16:44, 4 February 2023 (UTC)[reply]

Admins will, I understand, still have the ability to see IPs. And won't they be assigned unique on-wiki identifiers à la vanished users? They could still be searched that way by patrolling users? Daniel Case (talk) 03:21, 5 February 2023 (UTC)[reply]
I think they will. But I'm not sure either what queries will be possible (reformulating your second question). --Matěj Suchánek (talk) 13:54, 5 February 2023 (UTC)[reply]