Jump to content

User:TheresNoTime/1

From Meta, a Wikimedia project coordination wiki
User:TheresNoTime/1
0 proposals, 0 contributors




Block history for individual IPs on ranges

Discussion

[edit]
  • 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)
    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)
    I have bookmarked it and used it a couple of times. Daniel Case (talk) 02:47, 12 February 2023 (UTC)
  • 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)
    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)

Voting

[edit]

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

Discussion

[edit]
  • 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)
  • 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)
  • 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)

Voting

[edit]

Stop-time blocks

Discussion

[edit]

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)

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

Voting

[edit]
  • Support Support SHB2000 (talk | contribs) 22:24, 10 February 2023 (UTC)
  • Support Support Hanif Al Husaini (talk) 05:12, 11 February 2023 (UTC)
  • Support Support Arado Ar 196 (talk) 08:06, 11 February 2023 (UTC)
  • Oppose Oppose SunDawn (talk) 12:34, 11 February 2023 (UTC)
  • Oppose Oppose Wakelamp (talk) 13:17, 11 February 2023 (UTC)
  • Oppose Oppose No need to do that, it's hard to implement and no way it will work. Also it will cause some privacy breaches. Thingofme (talk) 13:38, 11 February 2023 (UTC)
  • Support Support Srijan Suryansh (talk) 17:23, 11 February 2023 (UTC)
  • Support Support Daniel Case (talk) 02:44, 12 February 2023 (UTC)
  • Oppose Oppose Per the privacy and implementation difficulties. Nosebagbear (talk) 17:30, 13 February 2023 (UTC)
  • Oppose Oppose Erbiton (talk) 21:06, 13 February 2023 (UTC)
  • Support Support ドラみそ (talk) 02:53, 14 February 2023 (UTC)
  • Oppose Oppose SpacedShark (talk) 05:31, 14 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:32, 15 February 2023 (UTC)
  • Oppose Oppose PRmaster1 (talk) 12:36, 15 February 2023 (UTC)
  • Oppose Oppose Phatom87 (talk) 16:10, 17 February 2023 (UTC)
  • Oppose Oppose It seems like a nice idea until you think about people spamming and/or gaming the system. Or the opposite, someone who doesn't spend much time on Wikipedia or mostly uses an IP is effectively indefinitely banned. Mitch199811 (talk) 18:18, 17 February 2023 (UTC)
  • Oppose Oppose per all the others above; there isn't a reasonable way to even define "time spent reading", much less measure it. 3mi1y (talk) 08:24, 18 February 2023 (UTC)
  • Oppose Oppose.--Vulcan❯❯❯Sphere! 12:30, 18 February 2023 (UTC)
  • Oppose Oppose --Libertyguy (talk) 21:32, 18 February 2023 (UTC)
  • Oppose Oppose Kcat37 (talk) 13:32, 21 February 2023 (UTC)
  • Oppose Oppose per Nosebagbear. ~~~~
    User:1234qwer1234qwer4 (talk)     17:15, 24 February 2023 (UTC)

Discussion

[edit]
  • 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)
    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)
  • Sure, there's also this that you can use: User:Linedwell/centralauthlink.js. Stryn (talk) 06:42, 25 January 2023 (UTC)
    Another script you can use, which I use globally, is CAWhoisProxy.js. Sdrqaz (talk) 17:29, 26 January 2023 (UTC)
    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)
  • 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)
    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)
  • 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)
  • 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)
  • 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)
    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)
    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)
    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)
  • This indeed should be visible on all wikis. Taylor 49 (talk) 10:14, 5 February 2023 (UTC)
  • 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)
    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)
  • See also w:User:The Voidwalker/centralAuthLink.js. ~~~~
    User:1234qwer1234qwer4 (talk)     17:17, 24 February 2023 (UTC)
  • Question 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)
    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)
    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)
    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)

Voting

[edit]

Layering/timing of blocks

Discussion

[edit]

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

[edit]

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)

We have updated the project page – November 10, 2023

[edit]

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)

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

Voting

[edit]
  • Support Support Allowing for overlapping blocks would certainly be useful. — xaosflux Talk 18:19, 10 February 2023 (UTC)
  • Support Support I personally haven't seen a need for layered blocks (yet), but stacked blocks (as in sequentially following each other) would definitely be useful. —Mainframe98 talk 18:59, 10 February 2023 (UTC)
  • Support Support I have multiple times thought, that this would be useful. Taivo (talk) 19:52, 10 February 2023 (UTC)
  • Support Support reducing cognitive load on admins who must currently remember to check back in when a sitewide ends in order to reapply a partial block. Folly Mox (talk) 20:07, 10 February 2023 (UTC)
  • Support Support Strainu (talk) 20:11, 10 February 2023 (UTC)
  • Support Support HouseBlaster (talk) 20:24, 10 February 2023 (UTC)
  • Support Support Tol (talk | contribs) @ 20:26, 10 February 2023 (UTC)
  • Support Support Patar knightchat/contributions 20:36, 10 February 2023 (UTC)
  • Support Support Dan.- (talk) 21:37, 10 February 2023 (UTC)
  • Support Support SHB2000 (talk | contribs) 22:19, 10 February 2023 (UTC)
  • Support Support both layered protection and layered block. Jeeputer (talk) 23:05, 10 February 2023 (UTC)
  • Support Support LD (talk) 23:29, 10 February 2023 (UTC)
  • Support Support Adding on to this, I've noticed that if a user is blocked site-wide then an admin has to remember to reinstate the partial block. With layered blocks this wouldn't be an issue as they would be site-wide blocked while still having the partial block. ― Blaze WolfTalkBlaze Wolf#6545 23:37, 10 February 2023 (UTC)
    This is exactly the issue I was describing at the second bullet point. Daniel Case (talk) 02:52, 12 February 2023 (UTC)
  • Support Support --NGC 54 (talk｜contribs) 23:54, 10 February 2023 (UTC)
  • Support Support StartGrammarTime (talk) 00:39, 11 February 2023 (UTC)
  • Support Support Hehua (talk) 00:52, 11 February 2023 (UTC)
  • Support Support Mark Ironie (talk) 01:18, 11 February 2023 (UTC)
  • Support Support Dreamy Jazz talk to me | enwiki 02:41, 11 February 2023 (UTC)
  • Support Support Why we can't do this like we can overlay semi-protection over pending changes has baffled me. Katietalk 03:19, 11 February 2023 (UTC)
  • Support Support * Pppery * it has begun 03:37, 11 February 2023 (UTC)
  • Support Support Spencer (talk) 04:38, 11 February 2023 (UTC)
  • Support Support Hanif Al Husaini (talk) 05:25, 11 February 2023 (UTC)
  • Support Support Soumendrak (talk) 06:15, 11 February 2023 (UTC)
  • Support Support Martin-78 (discutailler) 07:54, 11 February 2023 (UTC)
  • Support Support --Jim Hokins (talk) 07:57, 11 February 2023 (UTC)
  • Support Support Arado Ar 196 (talk) 08:05, 11 February 2023 (UTC)
  • Support Support NguoiDungKhongDinhDanh 09:20, 11 February 2023 (UTC)
  • Support Support Golmote (talk) 12:26, 11 February 2023 (UTC)
  • Support Support Lupe (talk) 13:18, 11 February 2023 (UTC)
  • Support Support IP blocks are layered by ranges so this should be done. Also, protections as admin temporary fully protect a page while this page is getting indefinite semi/or 30/500 protection and when the full one expire they have to remember to reinstate the block again or the page getting vandalized. Thingofme (talk) 13:47, 11 February 2023 (UTC)
  • Support Support Guerillero Parlez Moi 13:51, 11 February 2023 (UTC)
  • Support Support Rots61 (talk) 15:59, 11 February 2023 (UTC)
  • Support Support Robertsky (talk) 17:29, 11 February 2023 (UTC)
  • Support Support Thomas Kinz (talk) 18:40, 11 February 2023 (UTC)
  • Support Support Novak Watchmen (talk) 18:47, 11 February 2023 (UTC)
  • Support Support Also, per Jeeputer, layered protections would also be helpful! HJ Mitchell | Penny for your thoughts? 18:55, 11 February 2023 (UTC)
  • Support Support WhatamIdoing (talk) 20:12, 11 February 2023 (UTC)
  • Support Support — Jules* talk 21:18, 11 February 2023 (UTC)
  • Support Support Hey, I proposed it. Daniel Case (talk) 23:46, 11 February 2023 (UTC)
  • Support Support Gohan 02:59, 12 February 2023 (UTC)
  • Support Support This proposal so firmly establishes the desire, need, and utility of this clearly missing technical capability that should, otherwise, be in long term use before now that I am, hereby, compelled to give my support.--John Cline (talk) 16:29, 12 February 2023 (UTC)
  • Support Support Daniuu (talk) 19:16, 12 February 2023 (UTC)
  • Support Support Izno (talk) 06:52, 13 February 2023 (UTC)
  • Support Support Tacsipacsi (talk) 08:48, 13 February 2023 (UTC)
  • Support Support Titore (talk) 14:02, 13 February 2023 (UTC)
  • Support Support - per the above Nosebagbear (talk) 17:31, 13 February 2023 (UTC)
  • Support Support · · · Peter (Southwood) (talk): 17:54, 13 February 2023 (UTC)
  • Support Support —Yahya (talk • contribs.) 21:17, 13 February 2023 (UTC)
  • Support Support Ayumu Ozaki (talk) 22:29, 13 February 2023 (UTC)
  • Support Support ドラみそ (talk) 02:50, 14 February 2023 (UTC)
  • Support Support. Greater nuance is a good thing. Sdrqaz (talk) 03:05, 14 February 2023 (UTC)
  • Support Support SpacedShark (talk) 05:20, 14 February 2023 (UTC)
  • Support Support //Lollipoplollipoplollipop::talk 13:38, 14 February 2023 (UTC)
  • Support Support Barkeep49 (talk) 16:52, 14 February 2023 (UTC)
  • Support Support Tris T7 (talk) 18:14, 14 February 2023 (UTC)
  • Support Support Antimuonium U wanna talk? 23:18, 14 February 2023 (UTC)
  • Support Support Rzuwig► 08:48, 15 February 2023 (UTC)
  • Support Support -Xayala Mammadli (talk) 10:29, 15 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:33, 15 February 2023 (UTC)
  • Support Support ~Cybularny Speak? 13:42, 15 February 2023 (UTC)
  • Support Support Ruthven (msg) 15:30, 15 February 2023 (UTC)
  • Support Support --——d—n—f (fr.-sysop) (talk) 07:56, 16 February 2023 (UTC)
  • Support Support Hey man im josh (talk) 15:05, 16 February 2023 (UTC)
  • Support Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:37, 17 February 2023 (UTC)
  • Support Support Kalesh (talk) 09:02, 17 February 2023 (UTC)
  • Support Support Geraki TL 10:46, 17 February 2023 (UTC)
  • Support Support ~ Amory (u • t • c) 16:25, 17 February 2023 (UTC)
  • Support Support —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:42, 17 February 2023 (UTC)
  • Support Support Lightoil (talk) 02:53, 18 February 2023 (UTC)
  • Support Support This is a good proposal Uncle Bash007 (talk) 04:28, 18 February 2023 (UTC)
  • Support Support --Minorax«¦talk¦» 09:02, 18 February 2023 (UTC)
  • Support Support Johannnes89 (talk) 11:45, 18 February 2023 (UTC)
  • Support Support Sakretsu (炸裂) 13:00, 18 February 2023 (UTC)
  • Support Support FoBe (talk) 14:20, 18 February 2023 (UTC)
  • Support Support —‍Mdaniels5757 (talk • contribs) 17:48, 18 February 2023 (UTC)
  • Support Support The person who loves reading (talk) 21:29, 18 February 2023 (UTC)
  • Support Support Alfa-ketosav (talk) 14:00, 19 February 2023 (UTC)
  • Support Support Zsinj (talk) 02:13, 20 February 2023 (UTC)
  • Support Support Amir (talk) 08:25, 20 February 2023 (UTC)
  • Support Support — Draceane talkcontrib. 11:03, 20 February 2023 (UTC)
  • Support Support As a former cs:wiki arbcomer I mean, this thing will be very useful. We’ve banned one user for one year to article discussion and for two years editing of article, and this block settings is now impossible--F.ponizil (talk) 14:15, 20 February 2023 (UTC)
  • Support Support --Rosičák (talk) 16:05, 20 February 2023 (UTC)
  • Support Support —מקף⁻ණ (Hyphen) 22:36, 20 February 2023 (UTC)
  • Support Support --Lamiot (talk) 11:04, 21 February 2023 (UTC)
  • Support Support Snowmanonahoe (talk) 13:26, 21 February 2023 (UTC)
  • Support Support DrowssapSMM (talk) 16:06, 21 February 2023 (UTC)
  • Support Support Some administrators often forget to set up a new protection after a higher level of protection has expired. 星海子 (talk) 16:17, 21 February 2023 (UTC)
  • Support Support. —— Eric Liu（Talk） 01:31, 23 February 2023 (UTC)
  • Support Support Sennecaster (talk) 02:12, 23 February 2023 (UTC)
  • Support Support আফতাবুজ্জামান (talk) 15:58, 24 February 2023 (UTC)
  • Support Support ~~~~
    User:1234qwer1234qwer4 (talk)     16:55, 24 February 2023 (UTC)

Discussion

[edit]
@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)
@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)
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)

Voting

[edit]
  • Support Support with an option to set levels deep to include Joshbaumgartner (talk) 21:45, 10 February 2023 (UTC)
  • Oppose Oppose some categories can be very deep and all of this is subjective to the wiki anyway. On some wikis, such as Wikivoyage, all categories essentially come back to 10 core categories, and this would just make things more confusing. --SHB2000 (talk | contribs) 22:23, 10 February 2023 (UTC)
    @SHB2000 I understand, and I know that there are such situations, that's why I proposed this as a toggle, so that the user can activate it, but it's not mandatory. --Mannivu · ✉ 08:43, 14 February 2023 (UTC)
  • Support Support CaféBuzz (talk) 09:52, 11 February 2023 (UTC)
  • Support Support With the depth limit being proposed. Some category "tree" may node back to itself. Thingofme (talk) 13:51, 11 February 2023 (UTC)
  • Support Support Heterotrofo (talk) 21:00, 11 February 2023 (UTC)
  • Support Support BeyPolite (talk) 12:03, 12 February 2023 (UTC)
  • Support Support 🌸 Sakura emad 💖 (talk) 15:21, 12 February 2023 (UTC)
  • Support Support ドラみそ (talk) 02:55, 14 February 2023 (UTC)
  • Support Support support cyrfaw (talk) 11:25, 15 February 2023 (UTC)
  • Support Support Sadads (talk) 01:07, 16 February 2023 (UTC)
  • Support Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:19, 18 February 2023 (UTC)
  • Support Support Wire723 (talk) 10:38, 18 February 2023 (UTC)
  • Oppose Oppose --Libertyguy (talk) 21:17, 18 February 2023 (UTC)
  • Support Support Bass-Kuroi (talk) 04:24, 19 February 2023 (UTC)
  • Support Support Carlotm (talk) 08:21, 19 February 2023 (UTC)
  • Support Support Blue Edits (talk) 10:18, 19 February 2023 (UTC)
  • Support Support DrowssapSMM (talk) 16:04, 21 February 2023 (UTC)
  • Support Support Morten Haan (talk) 18:05, 22 February 2023 (UTC)
  • Support Support. —— Eric Liu（Talk） 01:45, 23 February 2023 (UTC)

Utility to attach acccount to all wikis

Discussion

[edit]
  • To reduce certain abuse factors, may want to limit to a permission. — xaosflux Talk 17:09, 3 February 2023 (UTC)
    @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)
    @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)
    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)
    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)
    Path appears to work. — xaosflux Talk 17:43, 9 February 2023 (UTC)
    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)
  • 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)
    @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)
    @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)
    @Xaosflux, got it. Tks. —Teles «Talk ˱C L @ S˲» 16:08, 13 February 2023 (UTC)
  • 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)
    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)
  • @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)
    I'd think so, unless someone really wants to write a path to SUL for this! — xaosflux Talk 21:14, 14 March 2023 (UTC)

Voting

[edit]

Enable removing block log entries entirely, not just redacting

Discussion

[edit]
  • @WikiFer: It is already possible to hide the block log entries, just as with any log entry or revision. If you want it hidden from other admins, too, suppression can be used. Is that not satisfactory? MusikAnimal (WMF) (talk) 02:19, 6 February 2023 (UTC)
    @MusikAnimal (WMF) Help:RevisionDelete only hides information in the text, summary of edits and account name or IP. The lockout log is not deleted if there is an administrator error in applying the lockout. WikiFer msg 04:11, 6 February 2023 (UTC)
    @WikiFer Using my sysop account, if I go to Special:Log/block, I see checkboxes next to each log entry and a "Change visibility of selected log entries" button. Is this not doing what you want? Apologies if I'm still missing something! I know RevisionDelete is a bad name, because in this case it's not actually a revision that we're deleting. MusikAnimal (WMF) (talk) 04:18, 6 February 2023 (UTC)
    @MusikAnimal (WMF) You are right. Now I realized that this option really exists. I'm sysop on ptwiki, but I've never used the possibility of hiding a blocking log. WikiFer msg 04:46, 6 February 2023 (UTC)

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)

@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)
@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)
@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)
@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)
@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)
@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)
@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)
@WikiFer Gotcha. I've updated the proposal title to clarify this. Samwalton9 (WMF) (talk) 14:50, 6 February 2023 (UTC)
@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)
@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)
@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)
@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)
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)
@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)
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)

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)

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)

Voting

[edit]
  • Oppose Oppose. A later unblock should be sufficient. However, there should be possible to add a tag to the block log to mark the block as "done in error". --Ciencia Al Poder (talk) 18:29, 10 February 2023 (UTC)
  • Oppose Oppose. You can look this. In my opinion unblock is enough. This "feature" would encourage administrators to hide their own mistakes, which would be not good. Everything what admin does, including mistakes, must be public as much as possible. Taivo (talk) 20:02, 10 February 2023 (UTC)
  • Oppose Oppose this creates a system open to abuse. Especially on some wikis (such as kawiki), this feature could be abused just so admins can hide the fact that they've been misusing their tools to block good-faith users for some time. --SHB2000 (talk | contribs) 22:17, 10 February 2023 (UTC)
  • Oppose Oppose this can go entirely unchecked. I have been involved in assisting administrators on the English Wikipedia with continuing to report long-term abusers. Doing this will give the long-term abusers an upper-hand. - TheLionHasSeen (talk) 22:41, 10 February 2023 (UTC)
  • Oppose Oppose suppression should be enough here. Outright removal removes accountability. Dreamy Jazz talk to me | enwiki 02:37, 11 February 2023 (UTC)
  • Oppose Oppose The stated problem is a deliberate social construct of the community, not a technical issue in need of solving. * Pppery * it has begun 03:35, 11 February 2023 (UTC)
  • Oppose Oppose Per above. Spencer (talk) 04:36, 11 February 2023 (UTC)
  • Oppose Oppose We are supposed to be held to a high standard. (That doesn't always happen). Admins even more so. You wouldn't want something covered up at work for example. So why is here any different? There needs to be accountability and transparency. What you have proposed would remove that and allow some admins to abuse it. Those that do abuse it shouldn't be an admin to be begin with. Good thing the proposer is not an admin (if they're not) because I could see them doing this. Mr. C.C.Hey yo!I didn't do it! 09:09, 11 February 2023 (UTC)
    @Fishhead2100 I'm an admin, but the proposal doesn't for me, but to users who are blocked unfairly and have their blocking record tarnished by the incompetence of wrong blocks by other administrators. WikiFer msg 14:51, 11 February 2023 (UTC)
  • Oppose Oppose This is unnecessary, the unblock log is the right place to point this out, if there has been a conflict or a debate between sysops, or mistake by the initial blocker, there is no good reason why this should not be visible in the log. CaféBuzz (talk) 09:51, 11 February 2023 (UTC)
  • Oppose Oppose SunDawn (talk) 12:37, 11 February 2023 (UTC)
  • Oppose Oppose don't hide errors, but maybe mark them Lupe (talk) 13:28, 11 February 2023 (UTC)
  • Oppose Oppose due to transparency issues. Thingofme (talk) 13:55, 11 February 2023 (UTC)
  • Oppose Oppose but only as an action an admin may take on their own. If the tool were, say, only part of the oversighter user right, and required consensus to implement, I think there would be more supports. See my comments above. Daniel Case (talk) 02:33, 12 February 2023 (UTC)
  • Support Support A clean block log is a great value for a user, and accidental or bad faith blocks may spoil it. Bináris tell me 10:46, 12 February 2023 (UTC)
  • Support Support As someone who had a 15-year clean block log tarnished due to an admin's mistake, I support this, Bastun (talk) 11:11, 13 February 2023 (UTC)
  • Oppose Oppose --cyrfaw (talk) 11:32, 15 February 2023 (UTC)
  • Support Support A clean block log is a great value for a user, and bad faith blocks spoil it. .... 0mtwb9gd5wx (talk) 04:13, 16 February 2023 (UTC)
  • Support Support Per Bináris and Bastun, I support this but it should be restricted to stewards, almost like bigdeletes. Just to be clear, I only support it if only stewards could do remove block entries, and the blocks were accidental, like https://en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3AFerien -- Ferien (talk) 20:11, 17 February 2023 (UTC)
  • Oppose Oppose per above. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:33, 18 February 2023 (UTC)
  • Oppose Oppose. See voy:Wikivoyage_talk:Deny_recognition#How_far_should_hiding_go. Pashley (talk) 13:45, 18 February 2023 (UTC)
  • Oppose Oppose --Libertyguy (talk) 21:25, 18 February 2023 (UTC)
  • Oppose Oppose Carlotm (talk) 08:49, 19 February 2023 (UTC)
  • Support Support iff this is only part of oversighter rights. Else, neutral. Alfa-ketosav (talk) 14:02, 19 February 2023 (UTC)
  • Oppose Oppose hiding blocks will not fix anything ANewPreson (talk) 12:41, 21 February 2023 (UTC)
  • Oppose Oppose This is unnecessary, we can use revisiondelete instead. 星海子 (talk) 16:09, 21 February 2023 (UTC)
  • Oppose Oppose on philosophical grounds--MediaWiki loves to save literally everything, why should there be an exception to this? Snowmanonahoe (talk) 12:44, 23 February 2023 (UTC)
  • Oppose Oppose per Taivo, I don't see how [e]veryone would benefit. Accidental blocks aren't a big deal. ~~~~
    User:1234qwer1234qwer4 (talk)     17:06, 24 February 2023 (UTC)

Display a notice on newly created articles

Discussion

[edit]
  • @Owee mªthias: the only time limits about new page creation are in large values (weeks+) and have to do with indexing. I think what you are talking about is a process that people are doing on a project, and not something that will be resolved with a technology change - correct? — xaosflux Talk 01:52, 30 January 2023 (UTC)
  • There might be some possibilty to add {{in use}} or equivalent - many users don't know that this possibility exists. But this can be misused by spammers. JAn Dudík (talk) 08:01, 31 January 2023 (UTC)
    • @JAn Duík: That template is for major edits to an existing article. It's not for an article created five minutes ago. That's what sandboxes and drafts are for. One would think you would have known that. I guess not. Mr. C.C.Hey yo!I didn't do it! 09:18, 11 February 2023 (UTC)
  • @Owee mªthias: As noted by Xaosflux above - this seems to be a suggestion for a community process, rather than a technical change. Is there a specific change you would like to see to MediaWiki software to enforce this limit in some way? Samwalton9 (WMF) (talk) 11:11, 2 February 2023 (UTC)
  • I guess the way this could be helped technically would be a feature so that any new article could automatically have some "Created in the last hour" or "New article" notice that would inform readers and patrollers alike with users having to tag and de-tag. Option to set duration and configure message/format would be required. KylieTastic (talk) 11:15, 2 February 2023 (UTC)
    yes,it's more like that what i thaught Owee mªthias (talk) 12:09, 2 February 2023 (UTC)
    @Owee mªthias Could you update the wish description fields above to clarify this? It's the section that will be translated so it will be helpful to clarify there so that voters understand what they're voting on. Samwalton9 (WMF) (talk) 09:22, 3 February 2023 (UTC)
    I've updated the description per the above. Samwalton9 (WMF) (talk) 10:38, 6 February 2023 (UTC)
  • Meanwhile, the way to do it is to work on an early-stage article in your user space or in draftspace rather than create an article in mainspace. For example, your draft fr:Trash(Youtube) was moved to fr:Utilisateur:Owee mªthias/Brouillon where you have more time to work on it. Fayenatic london (talk) 14:36, 2 February 2023 (UTC)
  • Comment Comment Draft namespace is only in some wikis. Sandbox is one of solutions, but sometimes user need to work in main namespace because of wikidata connection. But this is probably not problem of newbies, their problem is not knowing about {{inuse}}. JAn Dudík (talk) 10:05, 13 February 2023 (UTC)
  • If you're talking about articles in Wikipedia, there is already a template called Under Construction that can notify any readers to not edit the page in order to avoid edit conflicts. Tutwakhamoe (talk) 20:01, 20 February 2023 (UTC)

Voting

[edit]
  • Oppose Oppose Seems to be a Wikipedia-only problem; the deletion processes of each individual wiki should be handled locally. --SHB2000 (talk | contribs) 22:19, 10 February 2023 (UTC)
  • Support Support Tgr (talk) 01:46, 11 February 2023 (UTC)
  • Oppose Oppose Templates exist for this purpose. 5225C (talk • contributions) 02:53, 11 February 2023 (UTC)
  • Oppose Oppose This is yet another proposal that is trying to solve a fundamentally social problem through technical means. That won't work. * Pppery * it has begun 03:38, 11 February 2023 (UTC)
  • Oppose Oppose the {{inuse}} template satisfies this need. Article deletion can be contested in case a genuine article is deleted by speedy deletion and/or community consensus is enough to decide the fate of the article if it reaches the AfD venue. Raydann (talk) 05:29, 11 February 2023 (UTC)
    @Raydann: That template is for major edits to an existing article. It's not for an article created five minutes ago. That's what sandboxes and drafts are for. One would think you would have known that. I guess not. Mr. C.C.Hey yo!I didn't do it! 07:35, 11 February 2023 (UTC)
    Learning from the best. Raydann (talk) 02:04, 19 February 2023 (UTC)
  • Oppose Oppose - likely unnecessary. New articles should in theory be no less unreliable than old articles. If there is a problem, or if it is still under construction, local wikis have ways to manage these. Anarchyte (talk) 06:57, 11 February 2023 (UTC)
@Anrchyte: Yeah, it's called sandboxes and drafts. Mr. C.C.Hey yo!I didn't do it! 07:37, 11 February 2023 (UTC)
  • Oppose Oppose --Jim Hokins (talk) 08:01, 11 February 2023 (UTC)
  • Oppose Oppose Using sandboxes and drafts solve this issue as they are there for the proposed solution. (Drafts will be deleted after a certain period of inactivity, so best to use your sandbox until ready). Mr. C.C.Hey yo!I didn't do it! 09:14, 11 February 2023 (UTC)
  • Oppose Oppose CaféBuzz (talk) 09:48, 11 February 2023 (UTC)
  • Oppose Oppose SunDawn (talk) 12:36, 11 February 2023 (UTC)
  • Oppose Oppose Lupe (talk) 13:32, 11 February 2023 (UTC)
  • Oppose Oppose There are resolutions to the problem like Draft namespace and user sandboxes. Thingofme (talk) 13:56, 11 February 2023 (UTC)
  • Support Support One of the best ideas. Heterotrofo (talk) 21:01, 11 February 2023 (UTC)
  • Oppose Oppose I don't think it's necessary, but if a community does decide it is this is a policy issue that can be addressed locally by creating a template that attaches to any article created by a user with >n edits. Daniel Case (talk) 02:54, 12 February 2023 (UTC)
  • Oppose Oppose verweis=User_talk:Flossenträger 06:43, 13 February 2023 (UTC) already established solutions available
  • Support Support Leo067 (talk) 08:39, 13 February 2023 (UTC)
  • Support Support I had the same problem, made my first article and Admin rushed to delete it, lost 50' of work because of "edit conflict". Also, "sandboxes" and "drafts" are the solution only if you accept to further complicate the article creation: for me it is better to have one stub more than no article at all. FranzXYZ (talk) 08:44, 13 February 2023 (UTC)
  • Oppose Oppose --cyrfaw (talk) 11:25, 15 February 2023 (UTC)
  • Support Support ~Cybularny Speak? 13:30, 15 February 2023 (UTC)
  • Oppose Oppose It would support SPAM edits in order to have the page indexed on Google and other search engines. Ruthven (msg) 15:29, 15 February 2023 (UTC)
  • Oppose Oppose No, sandboxes are enough. --——d—n—f (fr.-sysop) (talk) 08:00, 16 February 2023 (UTC)
  • Support Support A person with less notability should also get a chance to list on Wikipedia. Stardustnite (talk) 08:44, 17 February 2023 (UTC)
  • Support Support This would be a good thing. Kalesh (talk) 09:00, 17 February 2023 (UTC)
  • Oppose Oppose Bilykralik16 (talk) 01:53, 18 February 2023 (UTC)
  • Support Support I think this is a great idea. Especially for the fact that I use RTRC in viewing recent edits, I have to open a page history to verify whether it is newly created or not. I therefore support if the fact that I can see newly created articles right before I even open the page. I support this proposal Uncle Bash007 (talk) 04:16, 18 February 2023 (UTC)
    You might want to use mw:XTools/ArticleInfo.js, which shows the age and creation date of a page below its title. ~~~~
    User:1234qwer1234qwer4 (talk)     16:49, 24 February 2023 (UTC)
  • Oppose Oppose --FoBe (talk) 14:18, 18 February 2023 (UTC)
  • Support Support First time readers should no about the article if it is recently created

    Homolego (talk) 15:27, 18 February 2023 (UTC)

  • Oppose Oppose: this seems like feature creep. There are technical solutions like templates (en:Template:In use), user sandboxes, and draft namespaces. There are also policy/guideline solutions such as adding guidance to admins and patrollers about time to deletion. For example, in English Wikipedia, new page reviewers wait for some time before nominating a new article for deletion, unless it's blatant vandalism or spam. MarioGom (talk) 18:23, 18 February 2023 (UTC)
  • Support Support Libertyguy (talk) 21:27, 18 February 2023 (UTC)
  • Support Support Captain Almighty Nutz (talk) 01:57, 19 February 2023 (UTC)
  • Support Support Bass-Kuroi (talk) 04:03, 19 February 2023 (UTC)
  • Support Support Packerfan386 (talk) 09:39, 19 February 2023 (UTC)
  • Oppose Oppose This is wiki-specific, intrudes on policy rather than being a purely technical feature, and half the supports on here don't list valid reasoning (what on earth does "A person with less notability should also get a chance to list on Wikipedia." have to do with this?) Blue Edits (talk) 10:20, 19 February 2023 (UTC)
  • Support Support 我支持此提案。 --维基佛祖 (talk) 23:23, 20 February 2023 (UTC)
  • Support Support --Serieminou (talk) 22:23, 21 February 2023 (UTC)
  • Support Support -- I really think that this is a very good idea. --  Manjiro91💬 12:09, 23 February 2023 (UTC)
  • Oppose Oppose per Pppery. ~~~~
    User:1234qwer1234qwer4 (talk)     16:48, 24 February 2023 (UTC)

Allow viewing of edit filter logs for IP ranges

Discussion

[edit]

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)

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)
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)

Voting

[edit]

Add block option to hide or suppress username from logs

Discussion

[edit]

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)

@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)
  • 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)
Are we talking about abusive/swearing/toxic login names? Wakelamp (talk) 13:20, 11 February 2023 (UTC)
  • Local oversighters already have a checkbox in Special:Block (added by having the hideuser right) to suppress the username from lists and logs upon blocking. Is this is to have a similar function for admins, as per the Phabricator ticket? —MarcoAurelio (talk) 10:29, 12 February 2023 (UTC)
    Yes. There should be a similar function as the one for oversighter for admins. 𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 10:37, 12 February 2023 (UTC)
  • I'm not really seeing the use case for administrators to have this. Some further explanation would be helpful. Risker (talk) 03:22, 21 February 2023 (UTC)

Voting

[edit]

Allow grouping of blocks and protections

Discussion

[edit]
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)

Voting

[edit]

Attribution repair mechanism

Discussion

[edit]
  • 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)
    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)
    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)
    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)
    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)
  • 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)
    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)
    @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)
    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)
    @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)
    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)
  • @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)
    @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)
  • 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)

Voting

[edit]
  • Oppose Oppose This seems like a lot of effort spent on a relatively minor thing. If admins want to annotate the history in this way, they can just use the already-existing import feature instead. * Pppery * it has begun 03:39, 11 February 2023 (UTC)
  • Neutral Neutral This thing is useful when editing the edit summary or import feature rather than making a dummy edit, but otherwise it is not useful. Thingofme (talk) 13:50, 11 February 2023 (UTC)
  • Support Support Bluerasberry (talk) 15:03, 11 February 2023 (UTC)
  • Support Support a better way of fixing attribution problems and edit summary errors. · · · Peter (Southwood) (talk): 16:28, 13 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:27, 15 February 2023 (UTC)
  • Support Support Ppt91 (talk) 19:08, 17 February 2023 (UTC)
  • Support Support 3mi1y (talk) 08:33, 18 February 2023 (UTC)
  • Support Support Alfa-ketosav (talk) 12:40, 19 February 2023 (UTC)
  • Support Support. In addition, in my opinion it could be used for any additional need for linking between edits, not just for providing attribution. —מקף⁻ණ (Hyphen) 22:47, 20 February 2023 (UTC)

Discussion

[edit]

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)

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)

Voting

[edit]

Option to filter bots from the block log

Discussion

[edit]
Question 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)
Yep, thanks, you are right! I want to filter them. Iniquity (talk) 15:05, 26 January 2023 (UTC)
I have renamed your proposal to reflect this. I hope that is OK. DWalden (WMF) (talk) 13:49, 27 January 2023 (UTC)
Thanks :) Iniquity (talk) 15:38, 27 January 2023 (UTC)
  • Bot edits should not be seen in the standard log, just like Recent changes. Thingofme (talk) 03:17, 28 January 2023 (UTC)
  • Special:Logs includes a Tag filter which can be inverted. It should be possible to tag bot log actions with an edit filter, so we could theoretically implement a version of this proposal today. -FASTILY 10:25, 28 January 2023 (UTC)
    What Fastily said. Bots making these blocks can be filtered out today if we make a tag for it and then use the existing facilities. I think that'd be a great idea to change the existing bot(s), which CommTech could assist with if necessary. Izno (talk) 06:53, 13 February 2023 (UTC)
  • Here we have 4903 QBA-bot out of 5000. At least this bot must be filtered! These 5000 entries only cover 1 hour of time.--Jaguar K (talk) 22:09, 23 February 2023 (UTC)

Voting

[edit]

Inline diffs and inline patrol

2024 update

[edit]
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)

Discussion

[edit]
  • 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)
    @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)
    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)
    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)
    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)
    See User:NguoiDungKhongDinhDanh/QuickDiff. He has deployed the tool onto Wikimedia. Thingofme (talk) 03:10, 28 January 2023 (UTC)
    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)
    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)
    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)
    QuickDiff cannot patrol edits like this (QuickDiff was copied from Fandom script). Thingofme (talk) 13:34, 11 February 2023 (UTC)
  • 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)
    @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)
  • 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)
    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)
    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)
    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)
  • 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)
  • 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)
    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)
    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)
    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)
  • Somewhat overlaps with Redesign the watchlist. --Tgr (talk) 00:58, 1 February 2023 (UTC)
  • 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)
  • 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)

Voting

[edit]
  • Support Support Xbypass (talk) 19:49, 10 February 2023 (UTC)
  • Support Support needs more thoughts, but I kinda like the idea MisterSynergy (talk) 20:40, 10 February 2023 (UTC)
  • Support Support Jeeputer (talk) 23:17, 10 February 2023 (UTC)
  • Support Support --NGC 54 (talk｜contribs) 00:10, 11 February 2023 (UTC)
  • Support Support Tgr (talk) 01:44, 11 February 2023 (UTC)
  • Support Support EpicPupper (talk) 05:05, 11 February 2023 (UTC)
  • Support Support Hanif Al Husaini (talk) 05:27, 11 February 2023 (UTC)
  • Support Support It would make patrolling much more efficient and quick. Raydann (talk) 05:34, 11 February 2023 (UTC)
  • Support Support Doktor Züm (talk) 05:59, 11 February 2023 (UTC)
  • Support Support Arado Ar 196 (talk) 08:03, 11 February 2023 (UTC)
  • Support Support Oltrepier (talk) 08:49, 11 February 2023 (UTC)
  • Support Support Matěj Suchánek (talk) 09:23, 11 February 2023 (UTC)
  • Support Support CaféBuzz (talk) 09:43, 11 February 2023 (UTC)
  • Support Support Waldyrious (talk) 10:48, 11 February 2023 (UTC)
  • Support Support Wikipelli (talk) 12:52, 11 February 2023 (UTC)
  • Support Support There are significant proposals to include the diffs, and to view diffs more efficiently but I think we need WMF attention to the difficulty of viewing diffs without external tools like QuickDiff, Huggle and SWViewer. Thingofme (talk) 13:31, 11 February 2023 (UTC)
  • Support Support Swagtennis (talk) 13:50, 11 February 2023 (UTC)
  • Support Support FinixFighter (talk) 15:22, 11 February 2023 (UTC)
  • Support Support Prairie Astronomer (talk) 15:33, 11 February 2023 (UTC)
  • Support Support Rots61 (talk) 15:55, 11 February 2023 (UTC)
  • Support Support Novak Watchmen (talk) 17:22, 11 February 2023 (UTC)
  • Support Support Thomas Kinz (talk) 18:45, 11 February 2023 (UTC)
  • Support Support De nue pw (talk) 22:19, 11 February 2023 (UTC)
  • Support Support MASUM THE GREAT (talk) 06:21, 12 February 2023 (UTC)
  • Support Support Mauricio V. Genta (talk) 07:45, 12 February 2023 (UTC)
  • Support Support Epifanove (talk) 11:39, 12 February 2023 (UTC)
  • Support Support BeyPolite (talk) 12:02, 12 February 2023 (UTC)
  • Support Support Tryvix t 14:00, 12 February 2023 (UTC)
  • Support Support Hári Zalán (talk) 17:36, 12 February 2023 (UTC)
  • Support Support --Minarin❄️[talk] 01:56, 13 February 2023 (UTC)
  • Support Support Izno (talk) 07:00, 13 February 2023 (UTC)
  • Support Support β16 - (talk) 09:58, 13 February 2023 (UTC)
  • Support Support Titore (talk) 14:03, 13 February 2023 (UTC)
  • Support Support Wargo (talk) 00:02, 14 February 2023 (UTC)
  • Support Support ··· 🌸 Rachmat04 · ☕ 09:49, 14 February 2023 (UTC)
  • Support Support Tris T7 (talk) 18:28, 14 February 2023 (UTC)
  • Support Support Quiddity (talk) 21:05, 14 February 2023 (UTC)
  • Support Support Rzuwig► 08:42, 15 February 2023 (UTC)
  • Support Support NPP volunteers on enwiki have been asking for improvements for a long long time. —⁠andrybak (talk) 09:49, 15 February 2023 (UTC)
  • Support Support Ani6032 (talk) 09:51, 15 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:26, 15 February 2023 (UTC)
  • Support Support ~Cybularny Speak? 13:33, 15 February 2023 (UTC)
  • Support Support Sadads (talk) 01:06, 16 February 2023 (UTC)
  • Support Support Aishik Rehman (talk) 06:42, 16 February 2023 (UTC)
  • Support Support The Yennefer (talk) 21:18, 17 February 2023 (UTC)
  • Support Support --Yining Chen (Talk) 10:05, 18 February 2023 (UTC)
  • Support Support Bilykralik16 (talk) 11:32, 18 February 2023 (UTC)
  • Support Support Vulcan❯❯❯Sphere! 12:29, 18 February 2023 (UTC)
  • Support Support The idea of making more known the topic of protection the environment (including animals) is very important. Eugene Eugene 1992 (talk) 12:58, 18 February 2023 (UTC)
  • Support Support Quangkhanhhuynh (talk) 13:04, 18 February 2023 (UTC)
  • Support Support Bass-Kuroi (talk) 04:12, 19 February 2023 (UTC)
  • Support Support Blue Edits (talk) 10:23, 19 February 2023 (UTC)
  • Support Support — Omegatron (talk) 16:24, 20 February 2023 (UTC)
  • Support Support UTF48 (talk) 22:27, 20 February 2023 (UTC)
  • Support Support Dr vulpes (talk) 06:16, 21 February 2023 (UTC)
  • Support Support Kalendar (talk) 07:18, 21 February 2023 (UTC)
  • Support Support Jaguar K (talk) 06:48, 24 February 2023 (UTC)
  • Support SupportI like the idea of all users being able to see which edits have not been patrolled or have been patrolled and by who SoupePrimordiale (talk) 07:36, 24 February 2023 (UTC)



Allow checkusers to use XFF variable in Abusefilters

Discussion

[edit]

Voting

[edit]

Notifications for user page edits

Discussion

[edit]
  • The request was successful in 2022, but it is requested again to attract attention by CommTech team. Thingofme (talk) 02:16, 29 January 2023 (UTC)
  • I think this really belongs under "notifications and watchlists". Daniel Case (talk) 23:24, 29 January 2023 (UTC)
    • It logically makes sense there too, yes, but as the use-case is primarily for anti-harassment, I think it's fine to stay here. MusikAnimal (WMF) (talk) 15:14, 30 January 2023 (UTC)
  • FWIW this was #2 by votes and #6 by the CommTech team's combined priority score in 2022. There's some in-progress work courtesy of @Legoktm:. --Tgr (talk) 01:57, 1 February 2023 (UTC)
  • WMF develeopment change alternative : What about adding a preference for a new notification option similar to "Edit to my user talk page"? Wakelamp (talk) 02:53, 7 February 2023 (UTC)
  • If WMF resources are the bottle neck, could we use a new bot job that sends a notification for edits that are not done by bots or the owner. OR What about external page watch tools? They exist on apps and desktops. Wakelamp (talk) 02:53, 7 February 2023 (UTC)
  • This would have to be optional, because I at least don't want these types of notifications. I trust that my homewiki userpage is defended by the abusefilter for the most part, and if that fails it's very likely that a RC patroller or another good faith user reverts the vandalism before I see it. I don't want to see it, and I don't even keep my userpage on my watchlist. --kyykaarme (talk) 15:38, 11 February 2023 (UTC)
  • Instead of a notification, i think than an option for an user to protect his own page from edits would be more useful. Particularly for user under big harassment, casual users who rarely edit, are on "vacation", or think than their time has finally come... etc. Miniwark (talk) 10:17, 13 February 2023 (UTC)
  • My hi: Wikipedia userpage was created by a vandal long ago. I never knew that my global userpage was being overriden by a blank white page for over 2 years. This is not desirable at all. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:26, 17 February 2023 (UTC)
  • @MarioGom: @MusikAnimal (WMF): Wouldn't it be even better if every user is notified not just for edits to their user pages, but for any edit to any page or subpage on any wiki belonging to someone's username? Nythar (talk) 14:17, 20 February 2023 (UTC)
    I believe having notifications for subpages is subject to debate, but it could likely easily be supported if we wanted it to be. Notifications will already be cross-wiki without any additional effort because of how Echo works. MusikAnimal (WMF) (talk) 14:56, 24 February 2023 (UTC)

Voting

[edit]
  • Strong support Strong support As someone who deals with vandals (including some LTAs) frequently, this is long overdue. ◇HelenDegenerate◆ 19:44, 10 February 2023 (UTC)
  • Support Support Firestar464 (talk) 20:34, 10 February 2023 (UTC)
  • Support Support I hope this can be done easily using a similar mechanism to talk page notifications. Certes (talk) 20:56, 10 February 2023 (UTC)
  • Support Support most definitely! Joshbaumgartner (talk) 21:57, 10 February 2023 (UTC)
  • Support Support with the condition that you should be able to turn this off at any time. SHB2000 (talk | contribs) 22:27, 10 February 2023 (UTC)
  • Support Support LD (talk) 22:28, 10 February 2023 (UTC)
  • Support Support BluePenguin18 🐧 ( 💬 ) 22:54, 10 February 2023 (UTC)
  • Support Support DemonDays64 (talk) 23:45, 10 February 2023 (UTC)
  • Support Support HeyElliott (talk) 23:46, 10 February 2023 (UTC)
  • Support Support ·addshore· talk to me! 00:02, 11 February 2023 (UTC)
  • Support Support --NGC 54 (talk｜contribs) 00:30, 11 February 2023 (UTC)
  • Support Support XtexChooser (talk) 01:42, 11 February 2023 (UTC)
  • Support Support Tgr (talk) 01:48, 11 February 2023 (UTC)
  • Support Support Lalalalala7 (talk) 02:07, 11 February 2023 (UTC)
  • Support Support Svartava (talk) 02:21, 11 February 2023 (UTC)
  • Support Support ··· 🌸 Rachmat04 · ☕ 02:31, 11 February 2023 (UTC)
  • Support Support Hehua (talk) 02:43, 11 February 2023 (UTC)
  • Support Support Dreamy Jazz talk to me | enwiki 02:46, 11 February 2023 (UTC)
  • Support Support Antonio B.1234 (talk) 02:52, 11 February 2023 (UTC)
  • Oppose Oppose Is there some reason the watchlist isn't sufficient for this? * Pppery * it has begun 03:40, 11 February 2023 (UTC)
    @Pppery: For cross-wiki patrollers (or any editors who work on many wikis), it's highly unlikely that they can watchlist their user pages (if uncreated; since most wikis allow autoconfirmed users to edit other userpages) and/or keep checking them for vandalism. As stated above, [u]nlike article vandalism, user page vandalism can affect the unwitting user's standing in the community, so usually it is much more urgent to be alerted of it. Svartava (talk) 05:43, 11 February 2023 (UTC)
    @Pppery: In my case, my watchlist has hundreds of items so I rarely check it, but I swiftly address notifications.--Error (talk) 10:15, 13 February 2023 (UTC)
  • Support Support Khoshhat (talk) 04:05, 11 February 2023 (UTC)
  • Support Support Spencer (talk) 04:59, 11 February 2023 (UTC)
  • Support Support EpicPupper (talk) 05:06, 11 February 2023 (UTC)
  • Support Support Soumendrak (talk) 06:16, 11 February 2023 (UTC)
  • Support Support Doktor Züm (talk) 06:52, 11 February 2023 (UTC)
  • Support Support Transient-understanding (talk) 07:38, 11 February 2023 (UTC)
  • Support Support Arado Ar 196 (talk) 08:00, 11 February 2023 (UTC)
  • Support Support Martin-78 (discutailler) 08:00, 11 February 2023 (UTC)
  • Support Support --Jim Hokins (talk) 08:05, 11 February 2023 (UTC)
  • Support Support Oltrepier (talk) 08:54, 11 February 2023 (UTC)
  • Support Support Szymonel (talk) 09:00, 11 February 2023 (UTC)
  • Support Support —Bruce1eetalk 09:15, 11 February 2023 (UTC)
  • Support Support CaféBuzz (talk) 10:00, 11 February 2023 (UTC)
  • Support Support //Lollipoplollipoplollipop::talk 10:03, 11 February 2023 (UTC)
  • Support Support Sebleouf (talk) 10:07, 11 February 2023 (UTC)
  • Support Support Waldyrious (talk) 10:45, 11 February 2023 (UTC)
  • Support Support Mirliz (talk) 11:46, 11 February 2023 (UTC)
  • Support Support User:Djm-leighpark(a)talk 12:41, 11 February 2023 (UTC)
  • Support Support SunDawn (talk) 12:42, 11 February 2023 (UTC)
  • Support Support Golmote (talk) 12:55, 11 February 2023 (UTC)
  • Support Support Hervegirod (talk) 12:55, 11 February 2023 (UTC)
  • Support Support Wyslijp16 (talk) 13:20, 11 February 2023 (UTC)
  • Support Support Tiputini (talk) 13:32, 11 February 2023 (UTC)
  • Support Support Lupe (talk) 13:36, 11 February 2023 (UTC)
  • Support Support OwenBlacker (Talk) 14:08, 11 February 2023 (UTC)
  • Strong support Strong support I kind of assumed something like this was already in-place. Yikes. Alhadis (talk) 14:14, 11 February 2023 (UTC)
  • Support Support This is long overdue and should be notified. Thingofme (talk) 14:54, 11 February 2023 (UTC)
  • Support Support -- Spielvogel (talk) 14:56, 11 February 2023 (UTC)
  • Support Support Bluerasberry (talk) 15:01, 11 February 2023 (UTC)
  • Support Support CROIX (talk) 15:17, 11 February 2023 (UTC)
  • Support Support FinixFighter (talk) 15:27, 11 February 2023 (UTC)
  • Support Support Realmartcraft (talk) 17:03, 11 February 2023 (UTC)
  • Support Support Novak Watchmen (talk) 18:53, 11 February 2023 (UTC)
  • Support Support Vukky (talk) 18:59, 11 February 2023 (UTC)
  • Support Support Thomas Kinz (talk) 19:21, 11 February 2023 (UTC)
  • Support Support De nue pw (talk) 22:22, 11 February 2023 (UTC)
  • Support Support Gohan 03:14, 12 February 2023 (UTC)
  • Support Support Betseg (talk) 03:59, 12 February 2023 (UTC)
  • Support Support HLFan (talk) 06:57, 12 February 2023 (UTC)
  • Support Support EnIRtpf09b (talk) 07:33, 12 February 2023 (UTC).
  • Strong support Strong support i deal with vandals to the point they frequently vandalized my User Page (along with talk page) on some projects that i was unaware of until an admin protected my user page and notified me of what happened. 🌸 Sakura emad 💖 (talk) 13:35, 12 February 2023 (UTC)
  • Support Support Daniuu (talk) 19:21, 12 February 2023 (UTC)
  • Support Support Bencemac (talk) 20:14, 12 February 2023 (UTC)
  • Support Support Funcrunch (talk) 23:40, 12 February 2023 (UTC)
  • Support Support — Officine Informatiche msg 09:02, 13 February 2023 (UTC)
  • Support Support BRP ever 10:03, 13 February 2023 (UTC)
  • Strong support Strong support Error (talk) 10:15, 13 February 2023 (UTC)
  • Support Support JAn Dudík (talk) 10:28, 13 February 2023 (UTC)
  • Support Support -- EN-Jungwon 10:34, 13 February 2023 (UTC)
  • Support Support β16 - (talk) 10:36, 13 February 2023 (UTC)
  • Support Support Maybe include even subpages of the user and user talk pages? That would need a separate opt-out, though. Tacsipacsi (talk) 11:01, 13 February 2023 (UTC)
  • Support Support Syunsyunminmin 🗨️talk 13:52, 13 February 2023 (UTC)
  • Support Support Airtransat236 (talk) 16:08, 13 February 2023 (UTC)
  • Support Support —Yahya (talk • contribs.) 21:29, 13 February 2023 (UTC)
  • Support Support --Minarin[talk] 22:46, 13 February 2023 (UTC)
  • Support Support ドラみそ (talk) 02:59, 14 February 2023 (UTC)
  • Support Support To make Wikipedia universally acceptable, it should avoid all kinds of controversial topics including obscenity, blasphemy. Hossain Muhammad Ramzan (talk) 04:48, 14 February 2023 (UTC)
  • Strong support Strong support - I hope, as this proposal's technical development begins that developers will extend the scope of notification need to also include user/subpage edits/moves. It seems reasonable, to me, that T296955 could be concurrently resolved with the same technical effort needed for the sole implementation of this proposal in isolation.--John Cline (talk) 05:07, 14 February 2023 (UTC)
  • Support Support SpacedShark (talk) 05:34, 14 February 2023 (UTC)
  • Support Support Mikxth (talk) 12:13, 14 February 2023 (UTC)
  • Support Support ZandDev (talk) 12:53, 14 February 2023 (UTC)
  • Support Support Meganinja202 (talk) 14:40, 14 February 2023 (UTC)
  • Support Support Barkeep49 (talk) 16:42, 14 February 2023 (UTC)
  • Support Support Labdajiwa (talk) 00:05, 15 February 2023 (UTC)
  • Support Support Rzuwig► 09:12, 15 February 2023 (UTC)
  • Support Support cyrfaw (talk) 11:37, 15 February 2023 (UTC)
  • Support Support PRmaster1 (talk) 12:42, 15 February 2023 (UTC)
  • Support Support Mike gigs (talk) 15:26, 15 February 2023 (UTC)
  • Support Support —MdsShakil (talk) 18:12, 15 February 2023 (UTC)
  • Support Support PumpkinHusky (talk) 19:06, 15 February 2023 (UTC)
  • Support Support Aishik Rehman (talk) 06:59, 16 February 2023 (UTC)
  • Support Support ABAL1412 (talk) 14:08, 16 February 2023 (UTC)
  • Support Support Hey man im josh (talk) 15:13, 16 February 2023 (UTC)
  • Support Support JFremd (talk) 15:49, 16 February 2023 (UTC)
  • Support Support OtroQus (talk) 17:35, 16 February 2023 (UTC)
  • Support Support Kays (talk) 02:29, 17 February 2023 (UTC)
  • Support Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:35, 17 February 2023 (UTC)
  • Support Support Gubeko (talk) 10:08, 17 February 2023 (UTC)
  • Support Support ~ Amory (u • t • c) 16:32, 17 February 2023 (UTC)
  • Support Support —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:27, 17 February 2023 (UTC)
  • Support Support As long as it's like undo notifications where you can turn them off when you want, I think this is a great idea. -- Ferien (talk) 20:17, 17 February 2023 (UTC)
  • Support Support Totalstgamer (talk) 22:18, 17 February 2023 (UTC)
  • Support Support Dankowski (talk) 22:52, 17 February 2023 (UTC)
  • Support Support DoublePendulumAttractor (talk) 06:01, 18 February 2023 (UTC)
  • Support Support -- Karelj (talk) 08:43, 18 February 2023 (UTC)
  • Support Support --Yining Chen (Talk) 10:13, 18 February 2023 (UTC)
  • Support Support Fabius Lector (talk) 11:23, 18 February 2023 (UTC)
  • Support Support MarioGom (talk) 12:17, 18 February 2023 (UTC)
  • Support Support Trimton (talk) 15:15, 18 February 2023 (UTC)
  • Support Support —‍Mdaniels5757 (talk • contribs) 17:53, 18 February 2023 (UTC)
  • Support Support Teafed (talk) 20:51, 18 February 2023 (UTC)
  • Support Support Kess (talk) 05:21, 19 February 2023 (UTC)
  • Support Support Blue Edits (talk) 17:19, 19 February 2023 (UTC)
  • Support Support Ïvana (talk) 01:06, 20 February 2023 (UTC)
  • Support Support Hans5958 (talk) 02:48, 20 February 2023 (UTC)
  • Support Support I support this as vandalism of their user talk causes editors to quit, but we need a better process for watchlists due to thei increasing length, Wakelamp (talk) 10:18, 20 February 2023 (UTC)
  • Support Support Nashona (talk) 14:41, 20 February 2023 (UTC)
  • Support Support Yes, useful PamD (talk) 15:16, 20 February 2023 (UTC)
  • Support Support Krzysiek 123456789 (talk) 13:01, 21 February 2023 (UTC)
  • Support Support Kcat37 (talk) 13:41, 21 February 2023 (UTC)
  • Support Support DrowssapSMM (talk) 16:09, 21 February 2023 (UTC)
  • Support Support Rosewood (talk) 14:25, 22 February 2023 (UTC)
  • Support Support Tryvix t 14:27, 22 February 2023 (UTC)
  • Support Support XRozuRozu (talk) 17:15, 22 February 2023 (UTC)
  • Support Support. —— Eric Liu（Talk） 02:05, 23 February 2023 (UTC)
  • Support Support --Tchoř (talk) 10:11, 23 February 2023 (UTC)
  • Support Support NicoScribe (talk) 20:46, 23 February 2023 (UTC)
  • Support Support CommanderWaterford (talk) 21:52, 23 February 2023 (UTC)
  • Support Support Krokofant (talk) 09:32, 24 February 2023 (UTC)
  • Support SupportAs an opt-in in Special:Preferences, like user talk notification emails. TheDragonFire300 (talk) 13:48, 24 February 2023 (UTC)
  • Support Support as last year. ~~~~
    User:1234qwer1234qwer4 (talk)     17:23, 24 February 2023 (UTC)

Allow checkusers to use user-agent variables in Abusefilters

Discussion

[edit]
  • User-agent's design is well-known. Such "Mozilla/5.0 (Linux; Android 6.0; HTC One M9 Build/MRA58K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.98 Mobile Safari/537.3" for HTC One M9's mobile could be handled by a few variables, depends how precise we need to be : kernel from a database [equiset] and inherited from browser, browser = "Chrome 52.0.2743.98" [browser_version ?], device = "HTC One M9", system = "Android 6.0". Even if vars are regex-alike, a Toolforge tool can easily parse and convert an UA's string into regexes (mainly . into \., [0-9] into \d). LD (talk) 20:59, 2 February 2023 (UTC)
  • phab:T242825 should probably resolved first. The current status from Chrome suggests time is running out, and Firefox is in support so they will likely follow suit. I'm thinking if anything, someone should re-propose Community Wishlist Survey 2022/Anti-harassment/Deal with Google Chrome User-Agent deprecation. Would you be interested in that, Jules*? I think it's going to be worked on regardless, but the proposal will help ensure it has the urgency it needs. MusikAnimal (WMF) (talk) 02:42, 6 February 2023 (UTC)
    Maybe @LD or Hyméros could re-propose that, as they better know the subject than myself? — Jules* talk 16:53, 6 February 2023 (UTC)
    Re-proposing a known whish is irrelevant (at least not recommended). RFC1945's design, or RFC8942's design, doesn't matter much in front end. It's all about matching properties retrieved in Abuse Filter. At some point, SEC-CH-UA might be used instead of UA, but while waiting for the migration, the request seems justified to me. On top of that, SEC-CH-UA seems to not be uncompatible with the purposes of this request [1][2]. LD (talk) 17:44, 6 February 2023 (UTC)
    Well, as I said, I assume the user agent deprecation will be worked on anyway. And you're right; whether it's client hints or UAs, we can use whatever one is available and expose in CheckUser.
    We just approved Allow checkusers to use XFF variable in Abusefilters knowing it involves phab:T234155 which the more significant amount of work. So I'm going to approve this one, too. According to a blog post from Google, UAs as we know them will largely be gone in just a matter of months, and thus probably not that useful in AbuseFilter. But there other browsers than just Chrome, and automation can still supply a custom UA. So I think there's something to do here regardless of what happens.
    I'll approve this now. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 21:28, 7 February 2023 (UTC)
    Hello everybody. I just want to emphasize that in the few cases where we need to track the "agents", it always involves the use of mobile phones, sometimes with the added use of WikiApp. In this case, the phone model is the final discriminant element. The ability to select or sort based on one of the agents would really save us hours. Hyméros --}-≽ ♥ Yes ? 17:47, 8 February 2023 (UTC)

Voting

[edit]

Minimize Wikimedia/Wikipedia's risk by enforcing 2FA on 'Mandatory Use User' groups

Discussion

[edit]
    • Just a demo notification. Getting the credentials for these accounts is improbable but not impossible.
      Just a demo notification. Getting the credentials for these accounts is improbable but not impossible.
    • If any ill-intention expert hacker can get access for 10 minutes in any of these accounts, just imagine how much damage could be done to Wikimedia web sister projects!
      If any ill-intention expert hacker can get access for 10 minutes in any of these accounts, just imagine how much damage could be done to Wikimedia web sister projects!
    • By not enabling 2FA (or improving security) on these accounts, we are actually challenging non-admirer hackers to use brute-force cracking or other methods.
      By not enabling 2FA (or improving security) on these accounts, we are actually challenging non-admirer hackers to use brute-force cracking or other methods.

    This was a wish on the previous 2019 wishlist survey, proposed by MASUM THE GREAT, and ranked #10.--MASUM THE GREAT (talk) 15:03, 1 February 2023 (UTC)

    • This probably should be in the Anti-harassment section, not Multimedia and Commons? And the more relevant task is T150898 I think. --Tgr (talk) 02:15, 1 February 2023 (UTC)
      Someone, please do that. Many thanks. -- MASUM THE GREAT (talk) 08:41, 1 February 2023 (UTC)
      @Tgr and Ahm masum: Moved, and the other Phabricator task added. Thanks! SWilson (WMF) (talk) 12:29, 1 February 2023 (UTC)
      Disagree that this should be in anti-harassment, unless every single security issue is also in anti-harassment. There's no harassment element in people failing to use 2FA. This is targeted at users who are already *supposed* to have 2FA in place; the overwhelming majority of them keep 2FA in place once they have it, so there's no reason that a hypothetical hacker would go after specific accounts. Risker (talk) 03:29, 21 February 2023 (UTC)
      @Risker: We've already established a conscious, which is why they're called "Mandatory Use User" groups. We don't need to make the same conscious again. So can you tell me, why just 'majority', not 'all' required account holders? Can you, or any advanced permission holder, guarantee us that the current non-enabling state is a 0% security loophole? Are these non-2FA advanced permission holders not a threat to our platform with each passing day?
      Yes. I agree. To make a long term effective mass implimentainon we need to rethink/redesigh our current 2FA mathod. We must have to make it as per industry standard, automative as much as possible. We also have to keep in mind that, as a nonprofit charitable organization, we have limited resources. We can't afford to hire too many paid support representatives. -- ~ MASUM THE GREAT (talk) 13:08, 21 February 2023 (UTC)
      Large-scale websites like this, always attract non-admirers, ill-intentioned people who want to do harm. They don't need Steward credentials. Getting access to any wiki Homepage/Database for 20 minutes through any one of the advanced account holders would be enough for them to tarnish Wikipedia/wikimedia's reputation. We've already seen how we've gotten negative news coverage for silly little mistakes or through vandals.
      Yes. We will wait for a redesigned 2FA. But in the meantime, leaving a 'security loophole' in our platform isn't a wise decision. Is it, @Risker ? -- ~ MASUM THE GREAT (talk) 13:57, 21 February 2023 (UTC)
    • This proposal should must not be implemented without quite a few improvements to the 2FA process as is, in terms of set-up, use, support, how to handle globally, amongst others. Nosebagbear (talk) 13:28, 1 February 2023 (UTC)
      The people who would be affected by this proposal are already required by Foundation policy to have 2FA enabled. This would make it a technical requirement, rather than a social one. Yes, those issues need to be addressed, but this would not make the current situation any worse. HouseBlaster (talk) 21:40, 2 February 2023 (UTC)
    • Stewards/WMF Staff could have a routine audit process on this today - would likely catch most deviations. — xaosflux Talk 15:04, 12 February 2023 (UTC)
      @Xaosflux On non-crat wikis, in theory, yes. On other wikis, we can't remove permissions, so it'd be an informative campaign. Martin Urbanec (talk) 15:38, 15 February 2023 (UTC)
    • I question the problem statement that initiates this request. Administrators and editors are not amongst those who have mandatory 2FA requirements, most of those who have that requirement were verified to have 2FA enabled at the time of their accession to the positions that have mandatory 2FA. There is a limited number of individuals involved, and it should be an easy activity to ensure that they maintain 2FA through periodic scripted verification that has nothing to do with anything else in this proposal. It should be noted that the limitations of the current 2FA software are very well known, and have been for years; it was never designed or intended for broad community use, but instead was designed for use by those who have very close contact with the few individuals who can reset 2FA if the user has a problem (i.e., highest level developers, WMF staff, stewards, and a few others with a long history within the community). If the desire is to improve usage of 2FA amongst those outside of this very limited group, then the software needs a major redesign as well as dedicated ongoing multilingual support by paid employees, not just a minor tweak. There have been extremely few account hijackings over the last 20 years, and to my knowledge they have all been related to poor password hygiene on the part of the account holder. It would be more cost-effective, and considerably less work, to require a password change as a condition of granting advanced permissions. Note that I fully support the proper redesign of 2FA, but right now the current 2FA is massively below the industry standard and I do not think we should be further promoting it until it is brought up to something at least close to industry standard. Risker (talk) 03:56, 21 February 2023 (UTC)

    Voting

    [edit]
    • Support Support Rakib (talk) 21:48, 23 February 2023 (UTC)
    • Support Support HouseBlaster (talk) 20:31, 10 February 2023 (UTC)
    • Support Support As pointed out by HouseBlaster, the user groups that will be affected by this proposal are already required to use 2FA. This is just making it a technical requirement. Firestar464 (talk) 20:31, 10 February 2023 (UTC)
    • Support Support BluePenguin18 🐧 ( 💬 ) 22:17, 10 February 2023 (UTC)
    • Oppose Oppose I don't see how this is any different from the status quo. --SHB2000 (talk | contribs) 22:26, 10 February 2023 (UTC)
    • Support Support XtexChooser (talk) 01:51, 11 February 2023 (UTC)
    • Support Support Lalalalala7 (talk) 02:09, 11 February 2023 (UTC)
    • Support Support LD (talk) 02:31, 11 February 2023 (UTC)
    • Support Support Hehua (talk) 02:45, 11 February 2023 (UTC)
    • Support Support Arado Ar 196 (talk) 07:56, 11 February 2023 (UTC)
    • Support Support Szymonel (talk) 09:00, 11 February 2023 (UTC)
    • Support Support Lemonaka (talk) 10:32, 11 February 2023 (UTC)
    • Support Support OtherPrivacyGuy (talk) 10:45, 11 February 2023 (UTC)
    • Support Support OwenBlacker (Talk) 14:07, 11 February 2023 (UTC)
    • Support Support This is extremely useful that this is enforced by technical means. Thingofme (talk) 14:46, 11 February 2023 (UTC)
    • Oppose Oppose Ain't broke. --Radio-Somewhere (talk) 16:44, 11 February 2023 (UTC)
    • Support Support Realmartcraft (talk) 17:04, 11 February 2023 (UTC)
    • Support Support Vukky (talk) 17:56, 11 February 2023 (UTC)
    • Support Support Novak Watchmen (talk) 18:53, 11 February 2023 (UTC)
    • Support Support Izno (talk) 07:05, 13 February 2023 (UTC)
    • Support Support β16 - (talk) 10:34, 13 February 2023 (UTC)
    • Support Support ドラみそ (talk) 02:58, 14 February 2023 (UTC)
    • Support Support cyrfaw (talk) 11:36, 15 February 2023 (UTC)
    • Support Support -- Riaz (talk) 17:27, 15 February 2023 (UTC)
    • Support Support ~ Amory (u • t • c) 16:27, 17 February 2023 (UTC)
    • Support Support Dankowski (talk) 22:53, 17 February 2023 (UTC)
    • Support Support Johannnes89 (talk) 11:48, 18 February 2023 (UTC)
    • Support Support Vulcan❯❯❯Sphere! 15:15, 18 February 2023 (UTC)
    • Support Support Anonimo88 (talk) 16:45, 18 February 2023 (UTC)
    • Support Support enforcing 2FA on accounts with advanced permissions is an essential security measure for any website at this scale. MarioGom (talk) 18:34, 18 February 2023 (UTC)
    • Support Support This is a security problem, and therefore not something you can say "If it ain't broke, don't fix it" to. There is no point in requiring 2FA if you don't actually require 2FA, and this is a serious issue waiting to happen. Snowmanonahoe (talk) 19:15, 18 February 2023 (UTC)
    • Support Support Niskka2 (talk) 21: