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]

Discussion

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

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]

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

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]

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]

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]

Voting

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

Discussion

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

Discussion

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]

Voting

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

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

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]

Discussion

Voting

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]

Discussion

  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]

Voting

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]

Discussion

Voting

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

Discussion

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]

Voting

Add block option to hide or suppress username from logs

Discussion

This is more of an "anti-harassment" item, so maybe it belongs there, but yes I'm for it all the same. Daniel Case (talk) 23:20, 29 January 2023 (UTC)[reply]

@WikiBayer: Thanks for this proposal. It might be helpful to elaborate in the "Who would benefit" section on the proposed benefits. It seems like there are potential benefits both for sysops (time savings) and for other users (not seeing bad usernames in logs). This will help other editors understand why they might want to vote for this! Samwalton9 (WMF) (talk) 13:51, 30 January 2023 (UTC)[reply]
  • To be clear, there is an option to hide usernames from logs. The linked task is about making that option available to admins (and not just oversighters). (Also, admins can already hide usernames from logs on a one-by-one basis via RevDel, but that can be quite cumbersome. Also also, the existing option is for SUL users; it might make sense to support such functionality locally, and to avoid dependency on the CentralAuth extension.) --Tgr (talk) 02:09, 1 February 2023 (UTC)[reply]
Are we talking about abusive/swearing/toxic login names? Wakelamp (talk) 13:20, 11 February 2023 (UTC)[reply]

Voting

Allow grouping of blocks and protections

  • Problem: Sometimes vandals/disruptors will be hitting a group of related articles (like, one about an upcoming election, then candidates and parties involved in that election). Likewise blocked vandals/disruptors often go to other IPs to evade and sock, and it is common for admins to extend the block on the IP used originally if there was one.

    To fully protect and block in these circumstances, it is necessary to enter the information for each protection/block separately.

  • Proposed solution: Make it possible to link the expiration dates for blocks/protections to other such actions, so they all run concurrently.
  • Who would benefit: Admins who will be able to work more efficiently, and good-faith users who will have less risk of their work being interrupted by a previously blocked IP suddenly free to disrupt again, or an article suddenly becoming unprotected.
  • More comments:
  • Phabricator tickets:
  • Proposer: Daniel Case (talk) 23:53, 31 January 2023 (UTC)[reply]

Discussion

There's already en:User:1234qwer1234qwer4/mass-tools.js for this exact reason, but a WMF remake would be good to see as a part of vanilla WP tools.--A09 (talk) 22:21, 1 February 2023 (UTC)[reply]

Voting

Attribution repair mechanism

  • Problem: In Russian Wikipedia I've found that most translations made before translation tool introduction doesn't have enough attribution in their edit summaries (or doesn't have it at all), because local rules allowed talk page template instead of attribution in edit history. There is no technical mechanism for attribution repair in the Wikipedia. Dummy edits are not official repair mechanism but are the only way to mark an edit as translation in edits history. Dummy edits are useless in long histories because search for added text won't show dummy edits near real edits without attribution in their summaries. Also they might vary in form and format. If somebody want to find out the source of the edit without attribution he will find added text and might try to add dummy edit. If another user already fixed attribution, duplicates may appear.
  • Proposed solution: Administrators or patrollers need to have technical possibility to link one edit to another if edit summary have special tag inside it and a reference to the original edit using special:redirect/revision/XXXX link. Linked dummy edit summary should appear near real edit summary in the page history and other tools. Alternatively comments to edit summary may be more appropriate feature, but their usage must be limited to forbid chatting.
  • Who would benefit: It might help to repair many Wikipedia articles in legal terms and prevent from adding attribution multiple times. Also it may be useful in some other cases like fixing previous edit summary.
  • More comments:
  • Phabricator tickets:
  • Proposer: D6194c-1cc (talk) 07:27, 28 January 2023 (UTC)[reply]

Discussion

  • For what is worth, English Wikipedia handles translation attributions with a template in the talk page: w:Template:Translated page, which can be added at any time, and usually includes links to exact revisions. MarioGom (talk) 15:44, 29 January 2023 (UTC)[reply]
    English wikipedia en:Wikipedia:Copying within Wikipedia declares that editor must provide either a list of authors or a hyperlink to the page in edit summary. Templates on the talk page add supplementary information. They don't provide legal mechanism for alternative attribution. D6194c-1cc (talk) 10:17, 30 January 2023 (UTC)[reply]
    Terms of Use in the paragraph 7b say: "Through hyperlink (where possible) or URL to the article to which you contributed (since each article has a history page that lists all authors and editors)" (m:Terms of Use/en). So our terms of use expect that information about all the authors will be available in the edit history. Talk page isn't related to the edit history nor to information about authors.
    Also paragraph 7c say: "You agree that, if you import text under a CC BY-SA license that requires attribution, you must credit the author(s) in a reasonable fashion. Where such credit is commonly given through page histories (such as Wikimedia-internal copying), it is sufficient to give attribution in the edit summary, which is recorded in the page history, when importing the text" (m:Terms of Use/en).
    So technically text copied from other page without attribution in edit summary is plagiarism (see en:Wikipedia:Plagiarism). Dummy edit helps to fix it, but they are useless in decades-long histories. D6194c-1cc (talk) 10:17, 30 January 2023 (UTC)[reply]
    Obviously it is an accepted practice that, in the absence of full attribution in edit summaries, templates in talk pages serve the same purpose. That template, indeed, contains cross-wiki links to exact revisions and history, which lists all authors and editors. Terms of use say that page histories are "commonly" used, not that they are the only way to do it. So far, I don't think there's a serious challenge to the idea that clear attribution in talk pages is crediting the authors in a reasonable fashion. If you really think that's not the case, this is probably a problem for WMF Legal team to clarify before jumping to implement any feature based on your interpretation. MarioGom (talk) 21:44, 31 January 2023 (UTC)[reply]
    In my understanding "commonly" means that attribution can be made in the face of the article as it is common with external CC BY-SA texts added to Wikipedia articles: en:Template:CCBYSASource. D6194c-1cc (talk) 14:26, 1 February 2023 (UTC)[reply]
  • Because this wish relates to legal concerns with the Wikimedia Terms of Use, I checked in with the Wikimedia Foundation Legal team to clarify whether this is a pressing concern. They said it's probably not a required change under the ToU, and the risk is pretty low and will be even lower when we move to CC 4.0 soon. @D6194c-1cc: Are there other potential benefits to making this change? If so I would recommend rewording the wish to focus around those, rather than legal concerns. Samwalton9 (WMF) (talk) 13:51, 1 February 2023 (UTC)[reply]
    Do you mean CC BY-SA 4.0 or CC 4.0 without BY-SA? Current Wikipedia authors licensed their texts under BY-SA, so its impossible to change the license of previously added content to a license without attribution. D6194c-1cc (talk) 15:37, 1 February 2023 (UTC)[reply]
    @D6194c-1cc CC BY-SA 4.0 - when I wrote CC 4.0 it was (confusing) shorthand. Samwalton9 (WMF) (talk) 16:03, 1 February 2023 (UTC)[reply]
    I have only legal concerns, so I'll leave it as is. I try to find best way to fix attribution of translations made long time ago. Currently I use something like this: ru:special:diff/128107741. D6194c-1cc (talk) 19:27, 1 February 2023 (UTC)[reply]
    @D6194c-1cc Because this change isn't required according to the WMF Legal team, I'm going to archive this wish. Thanks for making the suggestion and prompting us to look into this though! Samwalton9 (WMF) (talk) 11:08, 2 February 2023 (UTC)[reply]
    Because the wish has been updated to focus on other potential benefits I've unarchived it. Samwalton9 (WMF) (talk) 16:56, 3 February 2023 (UTC)[reply]
  • @D6194c-1cc Admin can add tags to revisions. Tags like credited later on 1st revision and credited here on crediting revision can solve this lack of order, that's compatible with license terms. On fr-wiki, we also use templates in references header to credit authors (see fr:Aide:Crédit d'auteurs => fr:Modèle:Crédit d'auteurs). Hope it helps ru-wiki. --LD (talk) 03:49, 11 February 2023 (UTC)[reply]
    @LD Thanks for the reply. But when the user contributes to the Wikipedia, he adds a piece of text so that anyone who re-uses article text under the CC BY-SA license needs to know what changes were made to every piece of text. Article's history is responsible not only for authorship, but also for information about modification of every added piece of text.
    I started using this translated template to mark articles with insufficient attribution: :en:Template:Copying within Wikipedia. This template has the same purposes as fr:Modèle:Crédit d'auteurs, but I think it's more appropriate and calls to fix attribution. D6194c-1cc (talk) 13:33, 11 February 2023 (UTC)[reply]
  • This is a tangent, but the concern I have is: Alice translates an article written by Bob at xxwiki. Carol deletes Bob's article from xxwiki. Now Alice's translation has a link to a page that no longer exists. It would be nice if Carol/xxwiki were aware that Alice had translated the article, so they could preserve the article history. WhatamIdoing (talk) 20:08, 11 February 2023 (UTC)[reply]

Voting

  • Problem: "When an IP address is blocked with the option to include logged-in users (e.g. hardblocked), the block includes a cookie block." Once a user hits this kind of block (e.g. using a VPN), they still get the block message for the blocked IP even if they turn off the VPN. This confuses good faith users who happen to accidentally hit open proxy blocks.
  • Proposed solution: Add an option to exempt a block from cookie blocks. This could be enabled by admins, stewards, and bots doing proxy blocking.
  • Who would benefit: Users who accidentally hit proxy blocks and turn off their proxies after noticing it.
  • More comments:
  • Phabricator tickets: phab:T306751
  • Proposer: MarioGom (talk) 15:40, 29 January 2023 (UTC)[reply]

Discussion

Having to spend a lot of time referring registered users caught in proxy blocks to IPECPROXY so they may request IPBE, I am in favor of any option that would reduce that caseload. Daniel Case (talk) 23:18, 29 January 2023 (UTC)[reply]

SHB2000: Sure. Users can clean cookies. They can change browser. They can use incognito mode. None of these solves the problem, which is that many users are encountering confusing blocks about IPs they are not currently using, and they end up at various venues for support, like VRT. MarioGom (talk) 18:29, 18 February 2023 (UTC)[reply]

Voting

Option to filter bots from the block log

Discussion

  Question: @Iniquity: to be clear, you don't want to "clear" as in erase/remove these from the log - just have a way to filter them (such as you can filter bot edits on watchlists) correct? — xaosflux Talk 15:01, 26 January 2023 (UTC)[reply]
Yep, thanks, you are right! I want to filter them. Iniquity (talk) 15:05, 26 January 2023 (UTC)[reply]
I have renamed your proposal to reflect this. I hope that is OK. DWalden (WMF) (talk) 13:49, 27 January 2023 (UTC)[reply]
Thanks :) Iniquity (talk) 15:38, 27 January 2023 (UTC)[reply]

Voting

Inline diffs and inline patrol

  • Problem: Patrolling recent changes is a time-consuming duty with very little help from MediaWiki software. It takes several clicks and browser tabs to patrol even the smallest change, while everything could be done inline, without ever leaving Recent changes, Page history or User contributions pages and losing track of where we left off. Unpatrolled changes are marked with a single ! in Recent changes, but not on Page histories and User contributions.
  • Proposed solution: I found the combination of "inline diffs" and "inline patrol" scripts extremely useful, and I'm proposing that their logic be added to MediaWiki software for all users with patrol rights. Every edit would get two buttons, one to [show diff] inline, one to [patrol] the change.
  •  
    Recent changes (animation)
  •  
    Article revision history
  •  
    User contributions
  • Who would benefit: users with any kind of patrol rights; the feature should be enabled for them by default
  • More comments: Everything needed for this feature is already there: diff table (example) and patrol actions are in the API. What's lacking are some hooks in the frontend software, consistent across recent changes, page histories and user contributions: buttons to expand or hide diffs, buttons to patrol a change, revision ID data present in every line of the lists.
Try it now

What the feature could look like can be tested by loading either (ExpandDiffs) mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Bradv/Scripts/ExpandDiffs.js&action=raw&ctype=text/javascript");
or inlineDiff: mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Writ Keeper/Scripts/commonHistory.js&action=raw&ctype=text/javascript");
together with inline-patrol.js mw.loader.load("//meta.wikimedia.org/w/index.php?title=User:Ponor/inline-patrol.js&action=raw&ctype=text/javascript"); This goes in one's local common.js, or in global.js at Meta. The first of the "inline diff" scripts only works on the English language wikis, but adds nice buttons in the style of Twinkle. The second script works on all wikis, as far as I know, but uses a tiny triangle to expand the diffs and messes up the "Group results by page" RC feature. Because all scripts depend on some hooks to manipulate the browser's DOM, they're very prone to breaking with any MediaWiki software updates and may not work on all pages on mobile/desktop sites.

Our wikis depend on the hard work of users with patroller rights. This feature would make their work much more efficient.
I know there is some external software or scripts that can do the same, but:
  • they seem to be enwiki-centric and don't play well with other wikis, or don't work at all
  • users, arguably, prefer working (writing, reading, patrolling, administrating) from the same interface (browser window), and on different devices
  • most users (patrollers) are, in my experience, reluctant to even create common.js and c&p two lines of code, because "not everyone is a computer scientist"
  • these tools and scripts are not easily discoverable, and debugging them to work on all wikis and for all users is likely very hard
  • some, if not all, do not have centralized message translation
  • or they show diffs separate from the changes list, causing a lot of scrolling back and forth.
My thanks go to Bradv, Writ Keeper, and Ivi1o4 for some inspirational code.

2024 update

 
Inline diffs and patrol (2024)

The proposed feature now exists as a single user script that works on all wikis: m:User:Ponor/inline-diff-inline-patrol. It could use some help from WMF teams for better/easier button positioning, "group results by page" RC feature, etc. ponor (talk) 15:25, 14 June 2024 (UTC)[reply]

Discussion

  • What if the diff is 100 lines long ? How would we handle that ? And how would this behave on mobile ? —TheDJ (talk • contribs) 19:37, 23 January 2023 (UTC)[reply]
    @TheDJ, the majority of diffs are short. I've used the two scripts to patrol thousands of edits, and had no issues with very long diffs either. It's as painful as checking the diff on a separate page: if it's too long, it's too long. The [show diff] button could ask for a second press if diffsize (example) is above some threshold. Every diff is downloaded on demand, and can be easily closed because the change entry and the corresponding [show diff] button do not shift relative to the viewport.
    No issues for me on mobile. I don't use my phone to patrol en masse, but the buttons come in handy for some users and some edits. Jdlrobson suggests using in lineinline, as opposed to side-by-side diffs on mobile (phab:T327566), that'd be cool if supported by MW API.ponor (talk) 21:09, 23 January 2023 (UTC)[reply]
    However, there are some problems resulting from the diff is too large, such as harder to load (some vandals insert a lot of content in one edit). Thingofme (talk) 01:50, 24 January 2023 (UTC)[reply]
    I use my own version of this type of script and it has built-in "jump to bottom/top" buttons ;) Nardog (talk) 19:23, 24 January 2023 (UTC)[reply]
    FWIW some Fandom wikis use QuickDiff, which arguably has slicker UI than the popular inline diff scripts on Wikipedia. Nardog (talk) 07:25, 27 January 2023 (UTC)[reply]
    See User:NguoiDungKhongDinhDanh/QuickDiff. He has deployed the tool onto Wikimedia. Thingofme (talk) 03:10, 28 January 2023 (UTC)[reply]
    I did think of using modal windows myself, and QuickDiff may indeed *look* slicker, but it introduces more complexity and actually slows down some common patroller workflows (I'm talking about 1000–2000 manually patrolled changes a month here!): 1) a user makes 10 small overlapping changes, you check their joint diff on Page history and quickly click one by one as patrolled using inline [patrol] buttons; with modal windows you'd need to open and close 10 windows; 2) when global (semi)-bots rename images, you also want to patrol quickly without checking the diffs; 3) it's sometimes convenient to see a few consecutive diffs at the same time, to check "where the user is going", and quickly patrol them; with modal windows you can view one diff at a time (...) All in all, I still prefer simple, efficient and quick over slick. The note at the bottom of NguoiDungKhongDinhDanh's page also tells you why we need some support from CommTech here: our hacks sometimes just don't play well together. ponor (talk) 09:19, 28 January 2023 (UTC)[reply]
    In Fandom, we have aggregative changes over one page by multiple users in Recent Changes, but in Wikimedia does not have this feature. Thingofme (talk) 13:57, 28 January 2023 (UTC)[reply]
    Actually, QuickDiff do allow you to navigate between consecutive diffs by using arrow keys. However, you're right: continuously opening and closing a window doesn't seem so nice. For inline patrolling, we have this Wikidata gadget which works quite well. NguoiDungKhongDinhDanh 09:15, 11 February 2023 (UTC)[reply]
    QuickDiff cannot patrol edits like this (QuickDiff was copied from Fandom script). Thingofme (talk) 13:34, 11 February 2023 (UTC)[reply]
  • Given the proposer, and supposedly other users, seem to be content with the existing tools, I feel like this should be developed bottom-up (by community), not top-down (by WMF). Not something I want to see CommTech's limited resources spent on. Nardog (talk) 19:23, 24 January 2023 (UTC)[reply]
    @Nardog, I never said I was satisfied. The scripts work (hackishly) on some wikis, for some users, on some pages, and only with some options, so the two features — [show diff] & [patrol] — definitely need some love and support from CommTech. Plus, I specifically asked this be enabled for all patrollers (and other roles I may not even know about) in a unified way, which helps with teaching, translations, debugging... I mean, you go to Revision history or User contributions and you can't even see which changes have or haven't been patrolled. Our patrollers deserve better than that! ponor (talk) 22:21, 24 January 2023 (UTC)[reply]
  • If implemented, it should have nothing to do with patrolling rights. This is useful for any advanced user, regardless of holding any advanced rights. That being said, I'm more or less satisfied with w:User:Bradv/Scripts/ExpandDiffs.js, and I think improving some of the existing scripts might be a good option. MarioGom (talk) 17:34, 28 January 2023 (UTC)[reply]
    If there's interest, all users can get [show diff] buttons inline, and patrollers/sysops/? can additionally get buttons to [patrol]. Also, if possible, non-patrollers could get [unpatrolled] 'tags" instead of the [patrol] buttons, so they could see which changes have been patrolled – why not? When thinking of user scripts, please don't think enwiki alone. I've used ExpandDiffs for my mock-ups because I like the style (of its buttons), but I'm forced to use the other script to patrol on my little wiki /has to do with how the script extracts some data from html source. ponor (talk) 23:49, 28 January 2023 (UTC)[reply]
    Sure. I think about all wikis. User scripts can also be improved for cross-wiki support. And, if required, MediaWiki can be improved to make it easier to port these scripts, if these rely on some features that are not portable. MarioGom (talk) 21:56, 29 January 2023 (UTC)[reply]
    I agree the proposal's coupling of diff and patrol is weird. I bet it would attract more support if it were about just one or the other. Nardog (talk) 14:30, 29 January 2023 (UTC)[reply]
  • Improving moderation tools by providing more context directly in the patrol interface (i.e., recent changes) is something I would much support. --Matěj Suchánek (talk) 13:55, 29 January 2023 (UTC)[reply]
  • I think that if this is done, we should make it a special 'app'. We should resist the urge to stuff ever more functionality into a few highly critical pages (that should also be mobile compatible). —TheDJ (talk • contribs) 23:36, 29 January 2023 (UTC)[reply]
    There are special apps like SWViewer that have this capability, however the request seems to be integrating it into MediaWiki and Wikimedia pages. Thingofme (talk) 15:31, 30 January 2023 (UTC)[reply]
    Arguably, we call RCh/PHist/UContrib pages highly critical *precisely because* that's from where we start patrolling. Since both actions (show diff + patrol) will happen on demand, with some quick calls to MW API, this can be coded as an "official" javascript gadget (or two), adding very little burden to those pages for patrollers/admins who leave the feature enabled and choose not to use it. Those who are patrollers but do not patrol can always disable the feature and will see nothing. ponor (talk) 16:40, 30 January 2023 (UTC)[reply]
    People usually start patrolling from there Recent Changes pages, and patrollers and rollbackers with these tools can perform their duties faster without using 3rd party apps like Huggle, SWViewer... but Twinkle and RedWarn/Ultraviolet has proven to increase the patrolling speeds. Thingofme (talk) 14:35, 31 January 2023 (UTC)[reply]
  • Somewhat overlaps with Redesign the watchlist. --Tgr (talk) 00:58, 1 February 2023 (UTC)[reply]
  • We can already view diffs in Navigation Popups; a "mark as patrolled" option could - and should - be added there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:10, 2 February 2023 (UTC)[reply]
  • You can also use this great script that allows you to see the changes in a pop-up window: commons:User:Serhio Magpie/instantDiffs.js - mw.loader.load('https://commons.wikimedia.org/w/index.php?title=User:Serhio_Magpie/instantDiffs.js&action=raw&ctype=text/javascript'); Iniquity (talk) 19:16, 10 February 2023 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Admins_and_patrollers&oldid=24623515"