Community Wishlist Survey 2023/Admins and patrollers

Community Wishlist Survey 2023

Admins and patrollers

16 proposals, 278 contributors, 651 support votes

The survey has closed. Thanks for your participation :)

Here are the Community Wishlist Survey 2023 results!

Block history for individual IPs on ranges

Edit proposal/discussion

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

Discussion

There is a tool hosted on Toolforge called Rangeblock finder, which seems to cover what this asks for. And although it only supports enwiki, making it support other wikis should be trivial. Nardog (talk) 06:01, 6 February 2023 (UTC)[reply]
That is a possible solution and would be considerably easier than implementing it in MediaWiki, but I've added phab:T146628 to the proposal anyway as this would add IP range support for all log types. MusikAnimal (WMF) (talk) 22:17, 6 February 2023 (UTC)[reply]

I have bookmarked it and used it a couple of times. Daniel Case (talk) 02:47, 12 February 2023 (UTC)[reply]

I am ok with it if it comes with ways of not block ISPs/Severs with dynamic IPs, some users, specially outside first world countries, may get blocked from using or edit wiki because some vandal happens to have the same,ISP provider as this person, I think that should be seem firest before a such tool be made Meganinja202 (talk) 14:37, 14 February 2023 (UTC)[reply]
This proposal is about block history for all IPs and subranges of a given range. Blocking functionality for ranges has been existing for a long time, and I don't think anybody is arguing that such blocks should be handled very carefully. ~~~~
User:1234qwer1234qwer4 (talk) 16:47, 24 February 2023 (UTC)[reply]

Voting

Support Dan.- (talk) 21:36, 10 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 00:17, 11 February 2023 (UTC)[reply]
Support * Pppery * _{it has begun} 03:38, 11 February 2023 (UTC)[reply]
Support Spencer (talk) 04:41, 11 February 2023 (UTC)[reply]
Support Soumendrak (talk) 06:14, 11 February 2023 (UTC)[reply]
Support Martin-78 ^{(discutailler)} 07:57, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:08, 11 February 2023 (UTC)[reply]
Support CaféBuzz (talk) 09:52, 11 February 2023 (UTC)[reply]
Support Wotheina (talk) 12:22, 11 February 2023 (UTC)[reply]
Support Golmote (talk) 12:40, 11 February 2023 (UTC)[reply]
Support Shizhao (talk) 13:36, 11 February 2023 (UTC)[reply]
Support This should be done by adding BlockList page/block history for a page like a new special page. Thingofme (talk) 13:57, 11 February 2023 (UTC)[reply]
Support Robertsky (talk) 17:26, 11 February 2023 (UTC)[reply]
Support Thomas Kinz (talk) 18:29, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 18:36, 11 February 2023 (UTC)[reply]
Support HJ Mitchell | Penny for your thoughts? 18:51, 11 February 2023 (UTC)[reply]
Support Sgd. —Hasley 18:58, 11 February 2023 (UTC)[reply]
Support — Jules* ^talk 21:12, 11 February 2023 (UTC)[reply]
Support – Dhtwiki (talk) 22:01, 11 February 2023 (UTC)[reply]
Support Daniel Case (talk) 02:47, 12 February 2023 (UTC)[reply]
Support Gohan 03:00, 12 February 2023 (UTC)[reply]
Support Ameisenigel (talk) 08:49, 12 February 2023 (UTC)[reply]
Support Nux (talk) 09:07, 12 February 2023 (UTC)[reply]
Support Tryvix ^t 14:00, 12 February 2023 (UTC)[reply]
Support The other way round could also be convenient. Daniuu (talk) 19:18, 12 February 2023 (UTC)[reply]
Support Izno (talk) 06:54, 13 February 2023 (UTC)[reply]
Support JAn Dudík (talk) 10:25, 13 February 2023 (UTC)[reply]
Support Titore (talk) 13:58, 13 February 2023 (UTC)[reply]
Support --Minarin ^[talk] 14:52, 13 February 2023 (UTC)[reply]
Support —Yahya (talk • contribs.) 21:21, 13 February 2023 (UTC)[reply]
Support Ayumu Ozaki (talk) 22:30, 13 February 2023 (UTC)[reply]
Support ドラみそ (talk) 02:54, 14 February 2023 (UTC)[reply]
Support. I've used the Toolforge link before, but I think it'd be more helpful to have it more "in-house". Sdrqaz (talk) 03:08, 14 February 2023 (UTC)[reply]
Support Tris T7 (talk) 18:31, 14 February 2023 (UTC)[reply]
Support Antimuonium ^{U wanna talk?} 23:00, 14 February 2023 (UTC)[reply]
Support Goodshort (talk) 10:20, 15 February 2023 (UTC)[reply]
Support ✠ SunDawn ✠ (contact) 10:22, 15 February 2023 (UTC)[reply]
Support cyrfaw (talk) 11:32, 15 February 2023 (UTC)[reply]
Support .... 0mtwb9gd5wx (talk) 04:21, 16 February 2023 (UTC)[reply]
Support --——d—n—f (fr.-sysop) (talk) 08:03, 16 February 2023 (UTC)[reply]
Support Hey man im josh (talk) 15:07, 16 February 2023 (UTC)[reply]
Support Geraki ^T_L 10:40, 17 February 2023 (UTC)[reply]
Support Ppt91 (talk) 19:08, 17 February 2023 (UTC)[reply]
Support The Yennefer (talk) 21:14, 17 February 2023 (UTC)[reply]
Support Lightoil (talk) 02:55, 18 February 2023 (UTC)[reply]
Support --Minorax^«¦talk¦» 09:03, 18 February 2023 (UTC)[reply]
Support Johannnes89 (talk) 11:45, 18 February 2023 (UTC)[reply]
Support -- Ferien (talk) 16:20, 18 February 2023 (UTC)[reply]
Support MarioGom (talk) 18:29, 18 February 2023 (UTC)[reply]
Support One should see individual IP because a range would include to many unrelated editors. Libertyguy (talk) 21:03, 18 February 2023 (UTC)[reply]
Support Bass-Kuroi (talk) 04:12, 19 February 2023 (UTC)[reply]
Support —MarcoAurelio (talk) 20:59, 19 February 2023 (UTC)[reply]
Support Niskka2 (talk) 21:53, 19 February 2023 (UTC)[reply]
Support Augend (talk) 07:49, 20 February 2023 (UTC)[reply]
Support — Draceane ^talk_contrib. 11:01, 20 February 2023 (UTC)[reply]
Strong Support --Pa2chant.bis (talk) 10:22, 21 February 2023 (UTC)[reply]
Support Superpes15 (talk) 15:59, 21 February 2023 (UTC)[reply]
Support. —— Eric Liu_（Talk） 01:58, 23 February 2023 (UTC)[reply]
Support NicoScribe (talk) 20:43, 23 February 2023 (UTC)[reply]
Support Range support for contribs was added in 2017, and more than five years later this still doesn't work for logs and deleted contributions? Not to mention this... ~~~~
User:1234qwer1234qwer4 (talk) 16:45, 24 February 2023 (UTC)[reply]

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

Edit proposal/discussion

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

Discussion

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

Voting

Support Strainu (talk) 20:09, 10 February 2023 (UTC)[reply]
Support Dan.- (talk) 21:39, 10 February 2023 (UTC)[reply]
Support Proposer. — Jules* ^talk 21:58, 10 February 2023 (UTC)[reply]
Support TheLionHasSeen (talk) 22:39, 10 February 2023 (UTC)[reply]
Support LD (talk) 23:28, 10 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 23:51, 10 February 2023 (UTC)[reply]
Support Support, however there are a lot of work needed to be done. Thingofme (talk) 00:20, 11 February 2023 (UTC)[reply]
Support Hehua (talk) 00:50, 11 February 2023 (UTC)[reply]
Support * Pppery * _{it has begun} 03:37, 11 February 2023 (UTC)[reply]
Support Hanif Al Husaini (talk) 05:22, 11 February 2023 (UTC)[reply]
Support Jurbop (talk) 07:47, 11 February 2023 (UTC)[reply]
Support Martin-78 ^{(discutailler)} 07:53, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:04, 11 February 2023 (UTC)[reply]
Support CaféBuzz (talk) 09:44, 11 February 2023 (UTC)[reply]
Support Golmote (talk) 12:36, 11 February 2023 (UTC)[reply]
Support Shizhao (talk) 13:35, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:22, 11 February 2023 (UTC)[reply]
Support A quick way to permit it in all odd-numbered (talk) pages might be handy. It might also be useful to block everywhere except the File: namespace. WhatamIdoing (talk) 19:55, 11 February 2023 (UTC)[reply]
Support Heterotrofo (talk) 20:59, 11 February 2023 (UTC)[reply]
Support ◇HelenDegenerate◆ 21:28, 11 February 2023 (UTC)[reply]
Support Nehaoua (talk) 21:31, 11 February 2023 (UTC)[reply]
Support Tryvix ^t 14:09, 12 February 2023 (UTC)[reply]
Support Hári Zalán (talk) 17:38, 12 February 2023 (UTC)[reply]
Support --Minarin ^[talk] 22:42, 13 February 2023 (UTC)[reply]
Support ドラみそ (talk) 02:55, 14 February 2023 (UTC)[reply]
Support Ayumu Ozaki (talk) 10:44, 14 February 2023 (UTC)[reply]
Support Vincent Vega ^msg? 20:28, 14 February 2023 (UTC)[reply]
Support Antimuonium ^{U wanna talk?} 23:32, 14 February 2023 (UTC)[reply]
Support Rzuwig^► 08:47, 15 February 2023 (UTC)[reply]
Support Goodshort (talk) 10:18, 15 February 2023 (UTC)[reply]
Support cyrfaw (talk) 11:34, 15 February 2023 (UTC)[reply]
Support ~Cybularny ^Speak? 13:43, 15 February 2023 (UTC)[reply]
Support Hey man im josh (talk) 15:00, 16 February 2023 (UTC)[reply]
Support Tommy Kronkvist (talk) 15:46, 16 February 2023 (UTC)[reply]
Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:40, 17 February 2023 (UTC)[reply]
Support --Yining Chen (Talk) 10:13, 18 February 2023 (UTC)[reply]
Support Libertyguy (talk) 21:14, 18 February 2023 (UTC)[reply]
Support And don't abuse the spam blacklist for editorial purposes. — Omegatron (talk) 17:00, 20 February 2023 (UTC)[reply]
Support —מקף⁻ණ (Hyphen) 22:51, 20 February 2023 (UTC)[reply]
Support --Pa2chant.bis (talk) 10:17, 21 February 2023 (UTC)[reply]
Support Krzysiek 123456789 (talk) 13:01, 21 February 2023 (UTC)[reply]
Support. —— Eric Liu_（Talk） 01:57, 23 February 2023 (UTC)[reply]
Support Snowmanonahoe (talk) 13:18, 23 February 2023 (UTC)[reply]
Support SCP-2000 08:24, 24 February 2023 (UTC)[reply]

Stop-time blocks

Edit proposal/discussion

Discussion

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

You could set this up so admins wouldn't be able to see the exact time left ... perhaps just an indicator that would go from red to yellow to green as the block progressed. Daniel Case (talk) 02:44, 12 February 2023 (UTC)[reply]

I don't see how this is going to be implemented. First, logging "minutes spent on Wikipedia" requires some privacy issues. Secondly, the block will be unbearable and too long for all editors. Let's consider 24 hours block, a block that is given as a "first offense". A person averaged 4 minutes on every visit. Let's say people visit Wikipedia 3 times a day, which goes for 12 minutes every day. Then, for 24 hours block, it will take 120 days for the editor to be unblocked. I usually spend around 4 hours per week reading Wikipedia outside editing, which is way above the average user. It will take me 45 days for a 24-hour block to expire. If you want stricter/stronger punishment, a longer block is an easier solution. SunDawn (talk) 12:34, 11 February 2023 (UTC)[reply]
You'd go with a shorter block than 24 hours. Maybe 10. Daniel Case (talk) 23:51, 11 February 2023 (UTC)[reply]

Also, remember, blocks are not supposed to be punitive. We are getting to the point where in some situations (range blocks, block evasions using IPs) admins are increasingly opting for longer blocks on the first offense. This is going to hurt us with some prospective editors who may want to start an account, find that their school or whatever was blocked six months ago and will be blocked for another six months when they can't, and then just give up on ever getting involved. Daniel Case (talk) 02:44, 12 February 2023 (UTC)[reply]

Voting

Support SHB2000 (talk | contribs) 22:24, 10 February 2023 (UTC)[reply]
Support Hanif Al Husaini (talk) 05:12, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:06, 11 February 2023 (UTC)[reply]
Oppose SunDawn (talk) 12:34, 11 February 2023 (UTC)[reply]
Oppose Wakelamp (talk) 13:17, 11 February 2023 (UTC)[reply]
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)[reply]
Support Srijan Suryansh (talk) 17:23, 11 February 2023 (UTC)[reply]
Support Daniel Case (talk) 02:44, 12 February 2023 (UTC)[reply]
Oppose Per the privacy and implementation difficulties. Nosebagbear (talk) 17:30, 13 February 2023 (UTC)[reply]
Oppose Erbiton (talk) 21:06, 13 February 2023 (UTC)[reply]
Support ドラみそ (talk) 02:53, 14 February 2023 (UTC)[reply]
Oppose SpacedShark (talk) 05:31, 14 February 2023 (UTC)[reply]
Support cyrfaw (talk) 11:32, 15 February 2023 (UTC)[reply]
Oppose PRmaster1 (talk) 12:36, 15 February 2023 (UTC)[reply]
Oppose Phatom87 (talk) 16:10, 17 February 2023 (UTC)[reply]
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)[reply]
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)[reply]
Oppose.--Vulcan❯❯❯Sphere! 12:30, 18 February 2023 (UTC)[reply]
Oppose --Libertyguy (talk) 21:32, 18 February 2023 (UTC)[reply]
Oppose Kcat37 (talk) 13:32, 21 February 2023 (UTC)[reply]
Oppose per Nosebagbear. ~~~~
User:1234qwer1234qwer4 (talk) 17:15, 24 February 2023 (UTC)[reply]

Add link to CentralAuth on Special:Contributions

Edit proposal/discussion

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

Discussion

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

I always go to Meta, so that what is essentially the same page has only one entry in my browser history and is in the language I'm familiar with (also "Previous global account changes" only seems to appear on Meta). I get sending the user to another site could be contra expectation though (if so I'll keep on using my MoreMenu custom link). Nardog (talk) 19:46, 11 March 2023 (UTC)[reply]

Local CA page is useless for stewards, I never use it. If it links to a local CA page at least a local CA page should include a link to CA on Meta. Stryn (talk) 07:13, 12 March 2023 (UTC)[reply]

Voting

Support V0lkanic (talk) 18:28, 10 February 2023 (UTC)[reply]
Support I'm doing cross-wiki anti-spam investigations, and not having this link easily accessible on every wiki is a pain. — Jules* ^talk 18:34, 10 February 2023 (UTC)[reply]
Support As someone whose UI language is not English, it's hit-or-miss whether a link to CentralAuth shows up. A solution in software would eliminate that issue, and make support by skins easier. It'd be really neat if this could be part of the group: User page, Talk Page, Contributions page. —Mainframe98 _talk 19:04, 10 February 2023 (UTC)[reply]
Support I will start to use it. Taivo (talk) 19:51, 10 February 2023 (UTC)[reply]
Support Tol (talk | contribs) @ 20:23, 10 February 2023 (UTC)[reply]
Support This is a no-brainer, IMO. Much easier than typing "Special:CentralAuth/USERNAME" or scrolling down to the bottom. SHB2000 (talk | contribs) 22:12, 10 February 2023 (UTC)[reply]
Support LD (talk) 23:32, 10 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 23:58, 10 February 2023 (UTC)[reply]
Support ·addshore· ^{talk to me!} 00:01, 11 February 2023 (UTC)[reply]
Support Tgr (talk) 01:45, 11 February 2023 (UTC)[reply]
Support Hanif Al Husaini (talk) 05:21, 11 February 2023 (UTC)[reply]
Support Jurbop (talk) 07:46, 11 February 2023 (UTC)[reply]
Support --Jim Hokins (talk) 07:48, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:01, 11 February 2023 (UTC)[reply]
Support Dulcetia (talk) 08:10, 11 February 2023 (UTC)[reply]
Support Oltrepier (talk) 08:46, 11 February 2023 (UTC)[reply]
Support NguoiDungKhongDinhDanh 09:06, 11 February 2023 (UTC)[reply]
Support CaféBuzz (talk) 09:34, 11 February 2023 (UTC)[reply]
Support Liuxinyu970226 (talk) 11:22, 11 February 2023 (UTC)[reply]
Support Golmote (talk) 12:15, 11 February 2023 (UTC)[reply]
Support SunDawn (talk) 12:37, 11 February 2023 (UTC)[reply]
Support Lupe (talk) 13:13, 11 February 2023 (UTC)[reply]
Support Contribution footer should be added automatically with fixed links to CentralAuth, XTools editcount and other useful things like articles created, external tools ... Thingofme (talk) 13:30, 11 February 2023 (UTC)[reply]
Support Shizhao (talk) 13:33, 11 February 2023 (UTC)[reply]
Support OwenBlacker (Talk) 14:05, 11 February 2023 (UTC)[reply]
Support Rots61 (talk) 15:55, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:20, 11 February 2023 (UTC)[reply]
Support Matěj Suchánek (talk) 19:12, 11 February 2023 (UTC)[reply]
Support WhatamIdoing (talk) 19:56, 11 February 2023 (UTC)[reply]
Support Gohan 03:05, 12 February 2023 (UTC)[reply]
Support Ameisenigel (talk) 08:49, 12 February 2023 (UTC)[reply]
Support —MarcoAurelio (talk) 14:29, 12 February 2023 (UTC)[reply]
Support Hári Zalán (talk) 17:38, 12 February 2023 (UTC)[reply]
Support This is already available via a script, but this function would be handy as part as of the standard software. Daniuu (talk) 19:18, 12 February 2023 (UTC)[reply]
Support Bencemac (talk) 20:17, 12 February 2023 (UTC)[reply]
Support AnthonyLSJ (talk) 04:33, 13 February 2023 (UTC)[reply]
Support Izno (talk) 07:01, 13 February 2023 (UTC)[reply]
Support Big impact with (hopefully) quite small effort. Tacsipacsi (talk) 09:01, 13 February 2023 (UTC)[reply]
Support β₁₆ - (talk) 09:53, 13 February 2023 (UTC)[reply]
Support BRP^ever 09:55, 13 February 2023 (UTC)[reply]
Support JAn Dudík (talk) 10:19, 13 February 2023 (UTC)[reply]
Support It would be good if the link takes user directly to Meta. This will also help stewards in dealing with various LTA's as the global lock tool is available in CentralAuth on Meta. ❄Mykola❄ 13:26, 13 February 2023 (UTC)[reply]
Support Wargo (talk) 18:54, 13 February 2023 (UTC)[reply]
Support —Yahya (talk • contribs.) 21:13, 13 February 2023 (UTC)[reply]
Support Ayumu Ozaki (talk) 22:31, 13 February 2023 (UTC)[reply]
Support --Minarin ^[talk] 22:38, 13 February 2023 (UTC)[reply]
Support ドラみそ (talk) 02:57, 14 February 2023 (UTC)[reply]
Support //Lollipoplollipoplollipop::talk 13:39, 14 February 2023 (UTC)[reply]
Support Quiddity (talk) 21:01, 14 February 2023 (UTC)[reply]
Support Labdajiwa (talk) 00:00, 15 February 2023 (UTC)[reply]
Support Rzuwig^► 08:44, 15 February 2023 (UTC)[reply]
Support Good and useful proposal. Naḥum (talk) 09:58, 15 February 2023 (UTC)[reply]
Support support cyrfaw (talk) 11:25, 15 February 2023 (UTC)[reply]
Support ~Cybularny ^Speak? 13:32, 15 February 2023 (UTC)[reply]
Support Matma Rex (talk) 21:54, 15 February 2023 (UTC)[reply]
Support আফতাবুজ্জামান (talk) 00:29, 16 February 2023 (UTC)[reply]
Support .... 0mtwb9gd5wx (talk) 04:18, 16 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 06:58, 16 February 2023 (UTC)[reply]
Support --——d—n—f (fr.-sysop) (talk) 08:01, 16 February 2023 (UTC)[reply]
Support Hey man im josh (talk) 15:03, 16 February 2023 (UTC)[reply]
Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:41, 17 February 2023 (UTC)[reply]
Support —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:45, 17 February 2023 (UTC)[reply]
Support -- Ferien (talk) 20:11, 17 February 2023 (UTC)[reply]
Support The Yennefer (talk) 21:17, 17 February 2023 (UTC)[reply]
Support Seperation (talk) 01:22, 18 February 2023 (UTC)[reply]
Support Kacamata (talk) 01:38, 18 February 2023 (UTC)[reply]
Support Bilykralik16 (talk) 01:47, 18 February 2023 (UTC)[reply]
Support This will ease our work exponentially Uncle Bash007 (talk) 04:23, 18 February 2023 (UTC)[reply]
Support --Yining Chen (Talk) 10:14, 18 February 2023 (UTC)[reply]
Support Johannnes89 (talk) 11:44, 18 February 2023 (UTC)[reply]
Support -- Herbert Ortner (talk) 12:14, 18 February 2023 (UTC)[reply]
Support MarioGom (talk) 12:17, 18 February 2023 (UTC)[reply]
Support Sakretsu (炸裂) 12:57, 18 February 2023 (UTC)[reply]
Support Quangkhanhhuynh (talk) 13:06, 18 February 2023 (UTC)[reply]
Support Vulcan❯❯❯Sphere! 15:14, 18 February 2023 (UTC)[reply]
Support Libertyguy (talk) 21:11, 18 February 2023 (UTC)[reply]
Support Bass-Kuroi (talk) 03:56, 19 February 2023 (UTC)[reply]
Support, clearly a very handy feature to have. Summer ^talk 20:12, 19 February 2023 (UTC)[reply]
Support – would be of great help for reverting cross-wiki vandalism. –FlyingAce^✈hello 01:40, 20 February 2023 (UTC)[reply]
Support Amir (talk) 08:22, 20 February 2023 (UTC)[reply]
Support — Draceane ^talk_contrib. 10:59, 20 February 2023 (UTC)[reply]
Support Risker (talk) 03:15, 21 February 2023 (UTC)[reply]
Support CatMan 149 (talk) 01:39, 22 February 2023 (UTC)[reply]
Support. —— Eric Liu_（Talk） 01:55, 23 February 2023 (UTC)[reply]
Support NicoScribe (talk) 20:41, 23 February 2023 (UTC)[reply]

Layering/timing of blocks

This proposal has a project page

Edit proposal/discussion

Discussion

Useful resource: Community health initiative/Partial blocks/Multi-blocks. --Matěj Suchánek (talk) 09:29, 4 February 2023 (UTC)[reply]
Nice to know about this. I give it my full support. Daniel Case (talk) 03:25, 5 February 2023 (UTC)[reply]

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

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

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

Please note that the project has been renamed Multiblocks.

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

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

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

We have updated the project page – November 10, 2023

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

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

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

Voting

Support Allowing for overlapping blocks would certainly be useful. — xaosflux ^Talk 18:19, 10 February 2023 (UTC)[reply]
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)[reply]
Support I have multiple times thought, that this would be useful. Taivo (talk) 19:52, 10 February 2023 (UTC)[reply]
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)[reply]
Support Strainu (talk) 20:11, 10 February 2023 (UTC)[reply]
Support HouseBlaster (talk) 20:24, 10 February 2023 (UTC)[reply]
Support Tol (talk | contribs) @ 20:26, 10 February 2023 (UTC)[reply]
Support Patar knight^chat/_{contributions} 20:36, 10 February 2023 (UTC)[reply]
Support Dan.- (talk) 21:37, 10 February 2023 (UTC)[reply]
Support SHB2000 (talk | contribs) 22:19, 10 February 2023 (UTC)[reply]
Support both layered protection and layered block. Jeeputer (talk) 23:05, 10 February 2023 (UTC)[reply]
Support LD (talk) 23:29, 10 February 2023 (UTC)[reply]
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 Wolf^Talk_{Blaze Wolf#6545} 23:37, 10 February 2023 (UTC)[reply]
This is exactly the issue I was describing at the second bullet point. Daniel Case (talk) 02:52, 12 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 23:54, 10 February 2023 (UTC)[reply]
Support StartGrammarTime (talk) 00:39, 11 February 2023 (UTC)[reply]
Support Hehua (talk) 00:52, 11 February 2023 (UTC)[reply]
Support Mark Ironie (talk) 01:18, 11 February 2023 (UTC)[reply]
Support Dreamy Jazz ^{talk to me | enwiki} 02:41, 11 February 2023 (UTC)[reply]
Support Why we can't do this like we can overlay semi-protection over pending changes has baffled me. Katie^talk 03:19, 11 February 2023 (UTC)[reply]
Support * Pppery * _{it has begun} 03:37, 11 February 2023 (UTC)[reply]
Support Spencer (talk) 04:38, 11 February 2023 (UTC)[reply]
Support Hanif Al Husaini (talk) 05:25, 11 February 2023 (UTC)[reply]
Support Soumendrak (talk) 06:15, 11 February 2023 (UTC)[reply]
Support Martin-78 ^{(discutailler)} 07:54, 11 February 2023 (UTC)[reply]
Support --Jim Hokins (talk) 07:57, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:05, 11 February 2023 (UTC)[reply]
Support NguoiDungKhongDinhDanh 09:20, 11 February 2023 (UTC)[reply]
Support Golmote (talk) 12:26, 11 February 2023 (UTC)[reply]
Support Lupe (talk) 13:18, 11 February 2023 (UTC)[reply]
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)[reply]
Support Guerillero ^{Parlez Moi} 13:51, 11 February 2023 (UTC)[reply]
Support Rots61 (talk) 15:59, 11 February 2023 (UTC)[reply]
Support Robertsky (talk) 17:29, 11 February 2023 (UTC)[reply]
Support Thomas Kinz (talk) 18:40, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 18:47, 11 February 2023 (UTC)[reply]
Support Also, per Jeeputer, layered protections would also be helpful! HJ Mitchell | Penny for your thoughts? 18:55, 11 February 2023 (UTC)[reply]
Support WhatamIdoing (talk) 20:12, 11 February 2023 (UTC)[reply]
Support — Jules* ^talk 21:18, 11 February 2023 (UTC)[reply]
Support Hey, I proposed it. Daniel Case (talk) 23:46, 11 February 2023 (UTC)[reply]
Support Gohan 02:59, 12 February 2023 (UTC)[reply]
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)[reply]
Support Daniuu (talk) 19:16, 12 February 2023 (UTC)[reply]
Support Izno (talk) 06:52, 13 February 2023 (UTC)[reply]
Support Tacsipacsi (talk) 08:48, 13 February 2023 (UTC)[reply]
Support Titore (talk) 14:02, 13 February 2023 (UTC)[reply]
Support - per the above Nosebagbear (talk) 17:31, 13 February 2023 (UTC)[reply]
Support · · · Peter (Southwood) ^(talk): 17:54, 13 February 2023 (UTC)[reply]
Support —Yahya (talk • contribs.) 21:17, 13 February 2023 (UTC)[reply]
Support Ayumu Ozaki (talk) 22:29, 13 February 2023 (UTC)[reply]
Support ドラみそ (talk) 02:50, 14 February 2023 (UTC)[reply]
Support. Greater nuance is a good thing. Sdrqaz (talk) 03:05, 14 February 2023 (UTC)[reply]
Support SpacedShark (talk) 05:20, 14 February 2023 (UTC)[reply]
Support //Lollipoplollipoplollipop::talk 13:38, 14 February 2023 (UTC)[reply]
Support Barkeep49 (talk) 16:52, 14 February 2023 (UTC)[reply]
Support Tris T7 (talk) 18:14, 14 February 2023 (UTC)[reply]
Support Antimuonium ^{U wanna talk?} 23:18, 14 February 2023 (UTC)[reply]
Support Rzuwig^► 08:48, 15 February 2023 (UTC)[reply]
Support -Xayala Mammadli (talk) 10:29, 15 February 2023 (UTC)[reply]
Support cyrfaw (talk) 11:33, 15 February 2023 (UTC)[reply]
Support ~Cybularny ^Speak? 13:42, 15 February 2023 (UTC)[reply]
Support Ruthven (msg) 15:30, 15 February 2023 (UTC)[reply]
Support --——d—n—f (fr.-sysop) (talk) 07:56, 16 February 2023 (UTC)[reply]
Support Hey man im josh (talk) 15:05, 16 February 2023 (UTC)[reply]
Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:37, 17 February 2023 (UTC)[reply]
Support Kalesh (talk) 09:02, 17 February 2023 (UTC)[reply]
Support Geraki ^T_L 10:46, 17 February 2023 (UTC)[reply]
Support ~ Amory (u • t • c) 16:25, 17 February 2023 (UTC)[reply]
Support —‍CX Zoom (A/अ/অ) (let's talk|contribs) 19:42, 17 February 2023 (UTC)[reply]
Support Lightoil (talk) 02:53, 18 February 2023 (UTC)[reply]
Support This is a good proposal Uncle Bash007 (talk) 04:28, 18 February 2023 (UTC)[reply]
Support --Minorax^«¦talk¦» 09:02, 18 February 2023 (UTC)[reply]
Support Johannnes89 (talk) 11:45, 18 February 2023 (UTC)[reply]
Support Sakretsu (炸裂) 13:00, 18 February 2023 (UTC)[reply]
Support FoBe (talk) 14:20, 18 February 2023 (UTC)[reply]
Support —‍Mdaniels5757 (talk • contribs) 17:48, 18 February 2023 (UTC)[reply]
Support The person who loves reading (talk) 21:29, 18 February 2023 (UTC)[reply]
Support Alfa-ketosav (talk) 14:00, 19 February 2023 (UTC)[reply]
Support Zsinj (talk) 02:13, 20 February 2023 (UTC)[reply]
Support Amir (talk) 08:25, 20 February 2023 (UTC)[reply]
Support — Draceane ^talk_contrib. 11:03, 20 February 2023 (UTC)[reply]
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)[reply]
Support --Rosičák (talk) 16:05, 20 February 2023 (UTC)[reply]
Support —מקף⁻ණ (Hyphen) 22:36, 20 February 2023 (UTC)[reply]
Support --Lamiot (talk) 11:04, 21 February 2023 (UTC)[reply]
Support Snowmanonahoe (talk) 13:26, 21 February 2023 (UTC)[reply]
Support DrowssapSMM (talk) 16:06, 21 February 2023 (UTC)[reply]
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)[reply]
Support. —— Eric Liu_（Talk） 01:31, 23 February 2023 (UTC)[reply]
Support Sennecaster (talk) 02:12, 23 February 2023 (UTC)[reply]
Support আফতাবুজ্জামান (talk) 15:58, 24 February 2023 (UTC)[reply]
Support ~~~~
User:1234qwer1234qwer4 (talk) 16:55, 24 February 2023 (UTC)[reply]

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

Edit proposal/discussion

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

Discussion

@Mannivu: Thanks for sharing this suggested improvement. Could you clarify the proposed solution? I think what you mean is that, when using Special:RelatedChanges for a category, you would like the option to also display changes from subcategories - is that right? One top-of-mind concern I'll just note on this is that MediaWiki categories can be circular and/or incredibly deep, so this might need to be limited to direct subcategories. Samwalton9 (WMF) (talk) 13:26, 30 January 2023 (UTC)[reply]

@Samwalton9 (WMF) yes, my idea is that I'd like to have an option that the user can activate in order to see the changes from subcategories of a given category. Maybe it could also let the user set a deep option (i.e. 2 for the direct subcategories and their subcategories). --Mannivu · ✉ 13:37, 30 January 2023 (UTC)[reply]

So far RelatedChanges does not even seem to support transclusions, which (unlike subcategories) is included in Special:WhatLinksHere. ~~~~
User:1234qwer1234qwer4 (talk) 16:57, 24 February 2023 (UTC)[reply]

Voting

Support with an option to set levels deep to include Joshbaumgartner (talk) 21:45, 10 February 2023 (UTC)[reply]
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)[reply]
@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)[reply]
Support CaféBuzz (talk) 09:52, 11 February 2023 (UTC)[reply]
Support With the depth limit being proposed. Some category "tree" may node back to itself. Thingofme (talk) 13:51, 11 February 2023 (UTC)[reply]
Support Heterotrofo (talk) 21:00, 11 February 2023 (UTC)[reply]
Support BeyPolite (talk) 12:03, 12 February 2023 (UTC)[reply]
Support 🌸 Sakura emad 💖 (talk) 15:21, 12 February 2023 (UTC)[reply]
Support ドラみそ (talk) 02:55, 14 February 2023 (UTC)[reply]
Support support cyrfaw (talk) 11:25, 15 February 2023 (UTC)[reply]
Support Sadads (talk) 01:07, 16 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:19, 18 February 2023 (UTC)[reply]
Support Wire723 (talk) 10:38, 18 February 2023 (UTC)[reply]
Oppose --Libertyguy (talk) 21:17, 18 February 2023 (UTC)[reply]
Support Bass-Kuroi (talk) 04:24, 19 February 2023 (UTC)[reply]
Support Carlotm (talk) 08:21, 19 February 2023 (UTC)[reply]
Support Blue Edits (talk) 10:18, 19 February 2023 (UTC)[reply]
Support DrowssapSMM (talk) 16:04, 21 February 2023 (UTC)[reply]
Support Morten Haan (talk) 18:05, 22 February 2023 (UTC)[reply]
Support. —— Eric Liu_（Talk） 01:45, 23 February 2023 (UTC)[reply]

Utility to attach acccount to all wikis

Edit proposal/discussion

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

Discussion

To reduce certain abuse factors, may want to limit to a permission. — xaosflux ^Talk 17:09, 3 February 2023 (UTC)[reply]
@Xaosflux Would fixing the user script be a solution? I wonder how many people really want this functionality and whether it really belongs as part of mw:Extension:CentralAuth. But if it's restricted to some permission, as you say, I suppose it's harmless to implement it directly in MediaWiki.

Either way we will approve this proposal, but if most people are content with a working script, I imagine that can be done quite easily – likely within a day. MusikAnimal (WMF) (talk) 18:31, 3 February 2023 (UTC)[reply]
@MusikAnimal (WMF) since this is really only for massive centralauth deployments (which practically is only the WMF cluster) - script based should still be fine (we could even gadgetize it here). We certainly didn't require a permission for a script - but was trying to not make it too easy for User:DisruptiveUsername to show up on hundreds of account creation logs at once. — xaosflux ^Talk 18:37, 3 February 2023 (UTC)[reply]
Got it! I will accept this proposal as-is, then, but I imagine a script is what we'll actually do. This wish may or may not be granted before the survey even finishes :) MusikAnimal (WMF) (talk) 20:47, 3 February 2023 (UTC)[reply]
Possible patch to old userscript listed at User_talk:Krinkle/Tools#running_Global_SUL.js_does_not_create_local_accounts by User:Suffusion of Yellow. — xaosflux ^Talk 01:56, 6 February 2023 (UTC)[reply]
Path appears to work. — xaosflux ^Talk 17:43, 9 February 2023 (UTC)[reply]
The patch has been applied to the original script which fulfills this wish before voting is even complete. --BDavis (WMF) (talk) 21:36, 10 February 2023 (UTC)[reply]
I don't get the point of this proposal. What would it actually improve? It would make the local account autocreation log entirely useless (granted I'm not sure how useful it is now), in exchange you'd have accounts on wikis you have never visited... what for? --Tgr (talk) 05:48, 6 February 2023 (UTC)[reply]
@Tgr, may be helpful for local searching by others users perhaps, for receiving a message by mail or at own talk page locally. Also the user will have the ability to be notified.

@MusikAnimal (WMF): I wonder what will be the underlying IP of accounts created. There may have privacy concerns. If the IP is owned by the account owner, they will leave too many tracks, and they will be able to be checked everywhere, which is good and bad at same time. If that’s someone else’s IP, that can be confusing. Just thought about it. —Teles «Talk ˱_{C L @ S}˲» 16:20, 9 February 2023 (UTC)[reply]
@Teles Today, script-wise, it is the enduser ip; the same as if they just visit a new project SUL logs them in. — xaosflux ^Talk 11:05, 12 February 2023 (UTC)[reply]
@Xaosflux, got it. Tks. —Teles «Talk ˱_{C L @ S}˲» 16:08, 13 February 2023 (UTC)[reply]
maybe... but why doe still have local accounts ? Maybe its time to get rid of that instead ? one step closer now that actor migration is so much further along. —TheDJ (talk • contribs) 14:13, 18 February 2023 (UTC)[reply]
Might want to add the script as a gadget here on Meta (restricting to autopatrolled or similar would probably be sensible) but I don't think this needs a native implementation. ~~~~
User:1234qwer1234qwer4 (talk) 17:02, 24 February 2023 (UTC)[reply]
@Xaosflux: I've marked this as Done by Suffusion of Yellow, given that Krinkle's user script now works — does that sound okay? — TheresNoTime (talk • they/them) 19:49, 14 March 2023 (UTC)[reply]
I'd think so, unless someone really wants to write a path to SUL for this! — xaosflux ^Talk 21:14, 14 March 2023 (UTC)[reply]

Voting

Support Xbypass (talk) 19:48, 10 February 2023 (UTC)[reply]
پاسخگویی در مقابل عملیات انجام شده توسط ادمین با سرعت بیشتری صورت گیرد Sat1980 (talk) 06:44, 15 February 2023 (UTC)[reply]
Support Luxtaythe2nd (talk) 19:53, 10 February 2023 (UTC)[reply]
Support PureTuber (talk) 20:11, 10 February 2023 (UTC)[reply]
Support It appears this will be easy to implement. Perfect for the wish-a-thon. HouseBlaster (talk) 20:21, 10 February 2023 (UTC)[reply]
Support RenkoTheBird (talk) 20:23, 10 February 2023 (UTC)[reply]
Support MisterSynergy (talk) 20:37, 10 February 2023 (UTC)[reply]
Support Quinnerwinner12 (talk) 20:44, 10 February 2023 (UTC)[reply]
Support Baah Thomas (talk) 21:19, 10 February 2023 (UTC)[reply]
Support It's a pity that the userscript is no longer compatible with current browsers. SHB2000 (talk | contribs) 22:09, 10 February 2023 (UTC)[reply]
Support Hehua (talk) 00:54, 11 February 2023 (UTC)[reply]
Support 26 Ramadan (talk) 01:38, 11 February 2023 (UTC)[reply]
Support XtexChooser (talk) 01:41, 11 February 2023 (UTC)[reply]
Support Should be relatively easy to implement as there already exists a MediaWiki job that could be run to autocreate on every wiki. Dreamy Jazz ^{talk to me | enwiki} 02:39, 11 February 2023 (UTC)[reply]
Support EpicPupper (talk) 05:04, 11 February 2023 (UTC)[reply]
Support Soumendrak (talk) 06:13, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:03, 11 February 2023 (UTC)[reply]
Support V0lkanic (talk) 08:42, 11 February 2023 (UTC)[reply]
Support Oltrepier (talk) 08:48, 11 February 2023 (UTC)[reply]
Support CaféBuzz (talk) 09:38, 11 February 2023 (UTC)[reply]
Support Shizhao (talk) 13:35, 11 February 2023 (UTC)[reply]
Support User scripts are not usable and we need a new tool for this. There are not many people who want to do this, though. Thingofme (talk) 13:52, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:19, 11 February 2023 (UTC)[reply]
Support Robertsky (talk) 17:31, 11 February 2023 (UTC)[reply]
Support Ameisenigel (talk) 08:51, 12 February 2023 (UTC)[reply]
Support Tryvix ^t 14:02, 12 February 2023 (UTC)[reply]
Support Husky (talk) 20:54, 12 February 2023 (UTC)[reply]
Support Svartava (talk) 08:00, 13 February 2023 (UTC)[reply]
Support ドラみそ (talk) 02:54, 14 February 2023 (UTC)[reply]
Support SpacedShark (talk) 05:22, 14 February 2023 (UTC)[reply]
Very strong support This tool is desperately needed in my opinion. NPRB (talk) 14:30, 14 February 2023 (UTC)[reply]
Support --ElBe ^{1 | 2 | WP} 15:49, 14 February 2023 (UTC)[reply]
Oppose Ani6032 (talk) 09:57, 15 February 2023 (UTC)[reply]
Support cyrfaw (talk) 11:33, 15 February 2023 (UTC)[reply]
Oppose .... 0mtwb9gd5wx (talk) 04:17, 16 February 2023 (UTC)[reply]
Support --——d—n—f (fr.-sysop) (talk) 07:53, 16 February 2023 (UTC)[reply]
Support Hey man im josh (talk) 15:08, 16 February 2023 (UTC)[reply]
Support JFremd (talk) 15:46, 16 February 2023 (UTC)[reply]
Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:38, 17 February 2023 (UTC)[reply]
Support Kalesh (talk) 09:02, 17 February 2023 (UTC)[reply]
Support Lightoil (talk) 02:50, 18 February 2023 (UTC)[reply]
Support Best Resolution Homolego (talk) 15:27, 18 February 2023 (UTC)[reply]
Support -- Ferien (talk) 16:19, 18 February 2023 (UTC)[reply]
Support, preferably as a user script... which is now fixed ;-) MarioGom (talk) 18:25, 18 February 2023 (UTC)[reply]
Support Captain Almighty Nutz (talk) 01:58, 19 February 2023 (UTC)[reply]
Support The person who loves reading (talk) 16:16, 19 February 2023 (UTC)[reply]
Support 🌸 Sakura emad 💖 (talk) 16:30, 19 February 2023 (UTC)[reply]
Support Augend (talk) 07:50, 20 February 2023 (UTC)[reply]
Support Morten Haan (talk) 18:06, 22 February 2023 (UTC)[reply]
Support. —— Eric Liu_（Talk） 01:46, 23 February 2023 (UTC)[reply]

Enable removing block log entries entirely, not just redacting

Edit proposal/discussion

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

Discussion

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

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

@WikiFer If I'm understanding you correctly, are you proposing a mechanism by which the community could collectively remove the log entry without requiring an admin/suppressor to be the one to enact the consensus? Samwalton9 (WMF) (talk) 10:42, 6 February 2023 (UTC)[reply]

@Samwalton9 (WMF) The admin will still be responsible for clearing the lock log, but it wouldn't be considered a hide in the way suppressors use it. The consensus for applying this removal would be by consensus among local administrators. WikiFer ^msg 11:34, 6 February 2023 (UTC)[reply]

@WikiFer I'm not sure I understand your proposal and how it's different from what is currently possible - could you elaborate on what the difference is? Samwalton9 (WMF) (talk) 12:49, 6 February 2023 (UTC)[reply]

@Samwalton9 (WMF) See this example here, it has the block log where a user was unblocked because another administrator objected to the block. My proposal is to remove this block log of user, leaving the his account without any blocking records. If it was unlocked because the lock was incorrect, it shouldn't be part of this history. WikiFer ^msg 13:03, 6 February 2023 (UTC)[reply]

@WikiFer Here you can see a test I just did where I removed blocks from the logs for my test account. Are you suggesting that the software should enable you to remove those log entries entirely, rather than have "removed" text in the log? Samwalton9 (WMF) (talk) 13:35, 6 February 2023 (UTC)[reply]

@Samwalton9 (WMF) Exactly. The proposal is for the software to remove log entries of locks that the local community has deemed to be incorrect. In the example you showed, the lock configuration change is another log. The proposal is not to remove only text, but not to appear in the account history anymore. WikiFer ^msg 13:56, 6 February 2023 (UTC)[reply]

@Samwalton9 (WMF) Another better example was this administrative war of blocking and unblocking this account only on December 30, 2020 on Portuguese Wikipedia. My proposal is to leave this entire history blank, as if there were no blocks. WikiFer ^msg 14:00, 6 February 2023 (UTC)[reply]

@WikiFer Gotcha. I've updated the proposal title to clarify this. Samwalton9 (WMF) (talk) 14:50, 6 February 2023 (UTC)[reply]

@Samwalton9 (WMF) @WikiFer Note that if you use RevDel (aka redaction) on all fields, the entry is completely hidden from the log. Only users who have the ability to change the visibility of the log entry will be able to see it, and they will see it as "([field] removed)". In this case that is only admins, but you can use suppression to hide it from them, too. Are we sure that doesn't satisfy the wish?

I don't think full proper deletion from the database is something that would be considered. We could add yet another layer of visibility, as in something above suppression, but is there really any point in doing that? MusikAnimal (WMF) (talk) 16:49, 6 February 2023 (UTC)[reply]

@MusikAnimal (WMF) In this example, it would be unfair for a person to have a history of having their account blocked due to an administrative war. I think that in situations like this, deleting database locks would resolve unfairness. WikiFer ^msg 16:58, 6 February 2023 (UTC)[reply]

@WikiFer "Deleting" isn't really a thing. I see now above you said you wanted something that worked without the assistance of suppression, but I still have the same concerns. We need a log of everything that happens. Anything done by an admin should be auitable by another admin. If we want it hidden from admins, use suppression. In your example, if you use RevisionDelete, the log entries are only visible to 49 users (and those users will see it as "hidden" and have to click through to see what actually happened). To everyone else (non-admins), they won't see the log entries at all. If suppression is used, it brings down the visibility to just three users, who again will see them as "hidden" and have to click through if they want more information. MusikAnimal (WMF) (talk) 17:02, 6 February 2023 (UTC)[reply]

@MusikAnimal (WMF) Oh, huh. I swear I tested looking at the Samwalton9Testing block log from a non-admin account and could still see the deleted logs, but now I'm looking again I don't see them, so maybe it was an account cache issue. I agree that there's not much else to be done if that's the current behaviour. Samwalton9 (WMF) (talk) 17:29, 6 February 2023 (UTC)[reply]

I'd like to hear confirmation from @WikiFer first, but I'm thinking this proposal could be archived as there are existing solutions. I'm unclear on why we would need the ability for admins to completely hide block log entries from other admins. Those other admins will see "[field] removed", and if they use the "Change visibility" link or check the deletion log, they will see the rationale which for this use case would say something like "accidental block". That is by design. All actions in MediaWiki are intended to be audited. Imagine a rogue admin who remove visibility of the blocks they made, and also the log entries of them changing the visibility.

As I said suppression can be used to hide the entries from admins, too, but I don't see the point as admins can already confirm the blocks are invalid. MusikAnimal (WMF) (talk) 18:57, 6 February 2023 (UTC)[reply]

@MusikAnimal (WMF) As I already opened the proposal, the ideal thing is for the community to manifest itself in a vote, since the tool for hiding administrators is just another blocking log, a new administrative action that can only be used if the username is incorrect, or the edit summary violates the local hiding policy. I believe that wrongs blocks should be removed from an account's history, and admins will be able to set this by consensus on each project. WikiFer ^msg 19:16, 6 February 2023 (UTC)[reply]

My point is that what you're proposing is already possible. I don't think anything new needs to be engineered. But, the proposal is actually already approved, so as it stands now it's going to voting. MusikAnimal (WMF) (talk) 17:22, 7 February 2023 (UTC)[reply]

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

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

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

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

Voting

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)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose suppression should be enough here. Outright removal removes accountability. Dreamy Jazz ^{talk to me | enwiki} 02:37, 11 February 2023 (UTC)[reply]
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)[reply]
Oppose Per above. Spencer (talk) 04:36, 11 February 2023 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
Oppose SunDawn (talk) 12:37, 11 February 2023 (UTC)[reply]
Oppose don't hide errors, but maybe mark them Lupe (talk) 13:28, 11 February 2023 (UTC)[reply]
Oppose due to transparency issues. Thingofme (talk) 13:55, 11 February 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose --cyrfaw (talk) 11:32, 15 February 2023 (UTC)[reply]
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)[reply]
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)[reply]
Oppose per above. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:33, 18 February 2023 (UTC)[reply]
Oppose. See voy:Wikivoyage_talk:Deny_recognition#How_far_should_hiding_go. Pashley (talk) 13:45, 18 February 2023 (UTC)[reply]
Oppose --Libertyguy (talk) 21:25, 18 February 2023 (UTC)[reply]
Oppose Carlotm (talk) 08:49, 19 February 2023 (UTC)[reply]
Support iff this is only part of oversighter rights. Else, neutral. Alfa-ketosav (talk) 14:02, 19 February 2023 (UTC)[reply]
Oppose hiding blocks will not fix anything ANewPreson (talk) 12:41, 21 February 2023 (UTC)[reply]
Oppose This is unnecessary, we can use revisiondelete instead. 星海子 (talk) 16:09, 21 February 2023 (UTC)[reply]
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)[reply]
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)[reply]

Display a notice on newly created articles

Edit proposal/discussion

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

Discussion

@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)[reply]
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)[reply]
- @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)[reply]
@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)[reply]
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)[reply]
yes,it's more like that what i thaught Owee mªthias (talk) 12:09, 2 February 2023 (UTC)[reply]
@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)[reply]
I've updated the description per the above. Samwalton9 (WMF) (talk) 10:38, 6 February 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

Voting

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)[reply]
Support Tgr (talk) 01:46, 11 February 2023 (UTC)[reply]
Oppose Templates exist for this purpose. 5225_C (talk • contributions) 02:53, 11 February 2023 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
Learning from the best. Raydann (talk) 02:04, 19 February 2023 (UTC)[reply]
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)[reply]

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

Oppose --Jim Hokins (talk) 08:01, 11 February 2023 (UTC)[reply]
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)[reply]
Oppose CaféBuzz (talk) 09:48, 11 February 2023 (UTC)[reply]
Oppose SunDawn (talk) 12:36, 11 February 2023 (UTC)[reply]
Oppose Lupe (talk) 13:32, 11 February 2023 (UTC)[reply]
Oppose There are resolutions to the problem like Draft namespace and user sandboxes. Thingofme (talk) 13:56, 11 February 2023 (UTC)[reply]
Support One of the best ideas. Heterotrofo (talk) 21:01, 11 February 2023 (UTC)[reply]
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)[reply]
Oppose 06:43, 13 February 2023 (UTC) already established solutions available
Support Leo067 (talk) 08:39, 13 February 2023 (UTC)[reply]
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)[reply]
Oppose --cyrfaw (talk) 11:25, 15 February 2023 (UTC)[reply]
Support ~Cybularny ^Speak? 13:30, 15 February 2023 (UTC)[reply]
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)[reply]
Oppose No, sandboxes are enough. --——d—n—f (fr.-sysop) (talk) 08:00, 16 February 2023 (UTC)[reply]
Support A person with less notability should also get a chance to list on Wikipedia. Stardustnite (talk) 08:44, 17 February 2023 (UTC)[reply]
Support This would be a good thing. Kalesh (talk) 09:00, 17 February 2023 (UTC)[reply]
Oppose Bilykralik16 (talk) 01:53, 18 February 2023 (UTC)[reply]
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)[reply]
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)[reply]
Oppose --FoBe (talk) 14:18, 18 February 2023 (UTC)[reply]
Support First time readers should no about the article if it is recently created
Homolego (talk) 15:27, 18 February 2023 (UTC)[reply]
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)[reply]
Support Libertyguy (talk) 21:27, 18 February 2023 (UTC)[reply]
Support Captain Almighty Nutz (talk) 01:57, 19 February 2023 (UTC)[reply]
Support Bass-Kuroi (talk) 04:03, 19 February 2023 (UTC)[reply]
Support Packerfan386 (talk) 09:39, 19 February 2023 (UTC)[reply]
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)[reply]
Support 我支持此提案。 --维基佛祖 (talk) 23:23, 20 February 2023 (UTC)[reply]
Support --Serieminou (talk) 22:23, 21 February 2023 (UTC)[reply]
Support -- I really think that this is a very good idea. -- Manjiro91💬 12:09, 23 February 2023 (UTC)[reply]
Oppose per Pppery. ~~~~
User:1234qwer1234qwer4 (talk) 16:48, 24 February 2023 (UTC)[reply]

Allow viewing of edit filter logs for IP ranges

Edit proposal/discussion

Discussion

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

Admins will, I understand, still have the ability to see IPs. And won't they be assigned unique on-wiki identifiers à la vanished users? They could still be searched that way by patrolling users? Daniel Case (talk) 03:21, 5 February 2023 (UTC)[reply]

I think they will. But I'm not sure either what queries will be possible (reformulating your second question). --Matěj Suchánek (talk) 13:54, 5 February 2023 (UTC)[reply]

Voting

Support — xaosflux ^Talk 18:20, 10 February 2023 (UTC)[reply]