Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

"0 days ago" in time duration calculation

[edit]

Reading the July 2024 global cyber outages article one notices in the infobox that the incident happened "0 days ago". Shouldn't that be "today" or "Today" instead? Nxavar (talk) 10:32, 19 July 2024 (UTC)[reply]

Thanks for pointing this out. Nxavar (talk) 14:38, 19 July 2024 (UTC)[reply]
Looks like it was discussed about a year ago at Template_talk:Time_ago. I don't think anyone has volunteered to add this feature, nor is it the result of anyone's previous work causing it, more like a design question than a bug, best way to say "now". Could also try WP:TEMPREQ for help. -- GreenC 15:49, 19 July 2024 (UTC)[reply]
It really feels like the most expedient solution would be to use Template:Start date and switch to Template:Start date and age after a day has passed. Firefangledfeathers (talk / contribs) 16:01, 19 July 2024 (UTC)[reply]
"Today" isn't the same day everywhere in the world. "0 days ago" indicates less than 24 hours ago, which could include "yesterday" in some time zones. WhatamIdoing (talk) 05:30, 20 July 2024 (UTC)[reply]
So have it say "Less than 24 hours ago" or "Less than 1 day ago" instead of "0 days ago" Soni (talk) 03:42, 24 July 2024 (UTC)[reply]
I've no objections to that, and I suspect that if you posted the code in an edit request on the template's talk page, then it would be accepted. WhatamIdoing (talk) 05:17, 27 July 2024 (UTC)[reply]
I would agree with that. Alternatively if the exact time is posted, the number of hours and/or minutes could also be used in place of “0 days ago.” West Virginia WXeditor (talk) 20:04, 30 July 2024 (UTC)[reply]

Does the community still want moved pages to be unreviewed

[edit]

Back in 2017, the community decided in this RfC that moved pages should be unpatrolled. The feature was stuck in Phabricator purgatory and was never actually implemented.

Does the community still want this feature implemented? (cc @Pppery, @Hey man im josh and @Novem Linguae who participated in an initial discussion on the NPP Discord server, also see T370593) Sohom (talk) 07:44, 21 July 2024 (UTC)[reply]

Taking my developer hat away, I personally don't think this should be implemented anymore. Sohom (talk) 07:54, 21 July 2024 (UTC)[reply]
I'm really surprised so many people supported that: it would create a substantial added burden for patrollers in exchange for maybe making a very rare problem slightly easier to detect. (Redirects from page moves already go into the queue, and even if they're retargeted elsewhere, a good reviewer should notice the suspicious history.) Unless this is a much larger-scale issue than I'm aware of, I don't think that proposal should be implemented. Extraordinary Writ (talk) 08:00, 21 July 2024 (UTC)[reply]
I have seen cases (e.g. recently at AT CBS This Morning) where a long-standing patrolled page becomes unpatrolled because a non-autopatrolled user moved the page - like from vandalism being reverted like CBS This Morning, or from requested moves like (709487) 2013 BL76. There can be quite a lot of these cases. Is this scenario also part of this discussion? thanks. Aszx5000 (talk) 09:36, 21 July 2024 (UTC)[reply]
@Aszx5000 That specific behavior is part of a bug that started happening recently and will be probably reverted. It's being tracked in T370593. The default behaviour is to not unpatrol page that are moved. Sohom (talk) 10:00, 21 July 2024 (UTC)[reply]
I think the RfC should be respected. Yes, WP:CCC but we really shouldn't overturn an RfC without an new RfC. Besides, this will help with detecting move vandalism in some cases so it is a useful change. Nickps (talk) 12:32, 21 July 2024 (UTC)[reply]
  • Oppose: If the RfC hasn't been implemented in 7 years, and it was only recently implemented by accident, it makes sense to revisit the discussion instead of implementing it by surprise so much later on in time. As one of the more active patrollers, I absolutely hate the idea of adding to the workload / massive backlog by adding pages to the queue just for being renamed. Really we'd want to just mark it as patrolled 99% of the time anyways. Hey man im josh (talk) 14:49, 21 July 2024 (UTC)[reply]
  • Strong oppose per nom and Josh. Reviewers already are swamped as it is. (t · c) buidhe 14:53, 21 July 2024 (UTC)[reply]
  • Oppose on the merits. I agree this is unnecessary and wasteful. But this discussion needed to be had and formally codified anyway to avoid unintentional cabalish behavior /WP:CONLEVEL problems. * Pppery * it has begun... 15:19, 21 July 2024 (UTC)[reply]
  • FWIW, I attempted to figure out how much moving and patrolling actually goes on so I could see if making it necessary to re-patrol moves would indeed add a significant workload. I came up with 916 moves and 1225 patrols yesterday. My SQL is weak (and my understanding of the MediaWiki schema even weaker) so I don't know if these numbers are accurate or not. If they are, then it looks like this would almost double the patrolling workload. RoySmith (talk) 15:33, 21 July 2024 (UTC)[reply]
    Hmmm, maybe I should have restricted this to mainspace? But I'll let somebody with better SQL-fu than I have play with it. RoySmith (talk) 15:34, 21 July 2024 (UTC)[reply]
    It's even worse than that - there were more moves in mainspace yesterday than there were total curations. —Cryptic 16:27, 21 July 2024 (UTC)[reply]
    Though, as usual, raw statistics are misleading. Neither of our queries, for instance, try not to count page moves by autopatrolled users, or pages moved out of the main namespace without leaving a redirect or where the redirect was later deleted. I can at least compensate for the small sample size by showing stats for all of July up to now, which are better: 7068 page moves starting in mainspace, 13519 mainspace page curations. —Cryptic 16:55, 21 July 2024 (UTC)[reply]
  • Oppose. I don't see much of a point in implementing this as it would unnecessarily double the workload of the NPP team. Redirects left behind from moves are already placed in the redirect queue (except for users in the page mover, autopatrolled, and redirect autopatrolled groups, including administrators). DannyS712 bot then automatically reviews a portion of them if the changes fit certain criteria, and the rest are reviewed manually. I feel like this system works just fine; it's not like we have a runaway page-move vandalism issue on our hands. —TechnoSquirrel69 (sigh) 17:50, 21 July 2024 (UTC)[reply]
  • Oppose. To quote myself from 2017: Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? We have the answers to some of those questions above, and it's not looking good. Doing this would double the NPP workload in order to close a loophole that is apparently so small that nobody noticed it had been accidentally left open for the last seven years. Really bad idea. – Joe (talk) 21:35, 21 July 2024 (UTC)[reply]
  • Comment: the proposal as it developed in the 2017 RfC was not for all article moves but for those by non-EC users which I think was 40 a day at the time. Cenarium's comment is not clear to me but search for "40" (not pinging them because they have not edited since April). Pinging @Ivanvector: who initiated the proposal for their comments. We don't know if this is still a concern or if other mechanisms were put in place. S0091 (talk) 19:39, 22 July 2024 (UTC)[reply]
    not for all article moves but for those by non-EC users which I think was 40 a day at the time. This somehow ended up not reflected in the 2017 RFC close and not reflected in the 2017 Phabricator ticket. We could go off on a tangent about whether that RFC was closed correctly or not, but I think it's a non-issue because we'll get a fresh consensus in this RFC that will override any lack of clarity about the previous close. –Novem Linguae (talk) 23:58, 28 July 2024 (UTC)[reply]
  • ??? I don't know that area that well because that not normally where I do my NPP work but I thought this was already happening. For example Extracorporeal procedure was in the cue. The community really needs for fix some things to help with the disaster at NPP but worrying about easy stuff like this really isn't it. North8000 (talk) 20:28, 22 July 2024 (UTC)[reply]
  • Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. C F A 💬 22:15, 28 July 2024 (UTC)[reply]

Bot to restore long-term protections after shorter-term higher protections expire

[edit]

A recurring issue with page protection is that long-term protections are sometimes overwritten by shorter-term protections at a higher protection level. When the shorter-term protection expires, administrators need to manually restore the previous lower protection level. For example, Beyoncé is indefinitely semi-protected due to vandalism and was recently fully protected due to edit warring. When the full protection expired, semi-protection needed to be restored manually by an administrator (more examples: 162794559, 162856607, 162974964, 163272356, 163337925). In addition to this happening after full protection due to edit warring, it also happens with ECP being applied to previously semi-protected articles.

Right now, administrators need to remember on their own, set a reminder, or rely on someone submitting a reprotection request on WP:RFPP. Unfortunately, disruption can be the result when the restoration of protection is delayed too long. Also, concerns about timely restoration can influence administrators to choose an approach other than protection when protection would have been their first choice in some situations.

The bot will not take any action if the duration of the higher protection level extends beyond the prior protection's expiration date, or if the protection level is the same or lower.

Following the requirements in WP:ADMINBOT, I'm requesting community approval before requesting approval at WP:BRFA. Thanks. Daniel Quinlan (talk) 02:47, 24 July 2024 (UTC)[reply]

This is a great idea. It would be helpful for the protection log entry to note the original protecting admin, the one responsible for the long-term protection. Firefangledfeathers (talk / contribs) 03:04, 24 July 2024 (UTC)[reply]
Definitely! I also plan to include the originally logged reason. Daniel Quinlan (talk) 03:09, 24 July 2024 (UTC)[reply]
Thanks, this would be very helpful. Johnuniq (talk) 03:31, 24 July 2024 (UTC)[reply]
Great idea. I've had to badger too many admins to reapply protections in similar scenarios. – Aza24 (talk) 06:10, 24 July 2024 (UTC)[reply]
I'm definitely not the first person to have the idea. After I starting looking into this, I found more than a few previous discussions (which also helped me iron out some details), such as this proposal for a bot in 2017. Starting with this task, I'm hoping to alleviate some of the drudgery I've experienced as an administrator helping out on WP:RFPP. Daniel Quinlan (talk) 08:56, 24 July 2024 (UTC)[reply]
I should also mention https://phabricator.wikimedia.org/T41038 which is from 2012. In the absence of a solution built into MediaWiki, a bot seems like the best approach and I'm volunteering to maintain and run it. Daniel Quinlan (talk) 09:21, 24 July 2024 (UTC)[reply]
As I mentioned on discord, and at m:Community Wishlist/Wishes/Restore long term protection when short term protection expires. This would be super handy. ScottishFinnishRadish (talk) 10:48, 24 July 2024 (UTC)[reply]
I agree this would be useful functionality. I'n not sure implementing it as a bot is the right approach (but I won't oppose the idea either). T194697 covers the same idea for blocks; all the reasons given there apply equally well to page protections. RoySmith (talk) 12:05, 24 July 2024 (UTC)[reply]
I feel like this has been raised before and went nowhere, though I might be misremembering. In any case, yes, this is functionality that should exist, whether as a bot or part of the protection interface. Vanamonde93 (talk) 17:59, 24 July 2024 (UTC)[reply]
Ah, now I remember why this sounded familiar: Wikipedia:Bots/Requests for approval/DYKToolsAdminBot. RoySmith (talk) 20:14, 24 July 2024 (UTC)[reply]
This would be useful functionality. May I suggest that the bot also drop a templated message about its actions at the user talkpage of the (non-bot) admin who most recently protected the page, so that they can undo/adjust the bot's page-protection if needed? Abecedare (talk) 02:29, 25 July 2024 (UTC)[reply]
Full support here. One would think this would just be in the MediaWiki code by now... EggRoll97 (talk) 21:41, 25 July 2024 (UTC)[reply]
I agree. There should be some kind of automatic mechanism for reinstating the previous protection (like for example, an article already semi-protected gets bumped up to extended confirmed, and then when the EC protection expires, there should be some automatic mechanism to reinstate the semi-protection) West Virginia WXeditor (talk) 20:02, 30 July 2024 (UTC)[reply]
I think that this feature would be useful. Ideally, it would be in software, but I see no need to wait if the MediaWiki devs haven't put it in yet. — Red-tailed hawk (nest) 20:04, 30 July 2024 (UTC)[reply]

Thanks for the comments and feedback, everyone. The request for approval of this bot is now posted on WP:BRFA. Daniel Quinlan (talk) 22:26, 30 July 2024 (UTC)[reply]

Organized toolbar

[edit]

I've tried making the toolbar a bit more orderly: https://snipboard.io/12CV83.jpg. Infogiraffic (talk) 09:19, 24 July 2024 (UTC)[reply]

"Has wiki in the name vs. not" isn't that useful of an organizational principle to me. Sdkb talk 12:15, 24 July 2024 (UTC)[reply]
In this example, how do Blame and Wikiblame differ? Folly Mox (talk) 17:55, 25 July 2024 (UTC)[reply]
@Folly Mox. For some reason they exist as two different pages: https://xtools.wmcloud.org/blame/en.wikipedia.org?page and https://blame.toolforge.org/wikiblame.php. Infogiraffic (talk) 17:48, 26 July 2024 (UTC)[reply]
Blame and Wikiblame have the same goal, but they're separate tools/separate software code. Someone might want to have access to both tools, but they should be side by side in the list.
On the other hand, Wikiblame should not be in the list with Wikidata, Wikinews, Wikibooks, and other sister projects. But Commons and Wiktionary should be in the list of sister projects, and I don't see them. WhatamIdoing (talk) 05:24, 27 July 2024 (UTC)[reply]
@WhatamIdoing. Hopefully I haven't given off the impression that I am offering an exhaustive overview. Commons and Wiktionary are just as welcome. My main focus was on getting some relatively hidden tools to be accessible via 'Analysis'. Infogiraffic (talk) 08:32, 29 July 2024 (UTC)[reply]
As a proof of concept, I think it's fine. I wouldn't personally find it very useful, because I'd rather type than look for anything in a menu. But others, especially those less familiar with MediaWiki software, likely have the opposite preference. WhatamIdoing (talk) 16:29, 29 July 2024 (UTC)[reply]
Both tools serve the same purpose (revision history tracking) but have separate codebases. Ideally, they should be grouped together under a single, clear label like "Revision History." While some users prefer keyboard shortcuts, menus can be helpful for those less familiar with MediaWiki. Perhaps a balance can be struck? We could consider a hybrid approach with both keyboard shortcuts and a more intuitive menu structure. What about submenus for categories like "Analysis Tools" (where "Revision History" would reside) and "Sister Projects"? BlackOrchidd (talk) 08:46, 7 August 2024 (UTC)[reply]

Afd to Prn/Pcn

[edit]

Can we rename Articles for deletion to Articles for checking/Reviewing notability which will give a positive impression than the present one. 103.66.169.3 (talk) 19:36, 26 July 2024 (UTC)[reply]

  • I think this is one of the perennial proposals, and the answer is "not necessary" (at any rate, it would require rewriting thousands of lines of active software, and moving half a million pages). jp×g🗯️ 22:15, 26 July 2024 (UTC)[reply]
    • The French Wikipedia did this, perhaps two years ago. AIUI they thought the communicative value (e.g., that we are here to check notability, not necessarily to delete the page) outweighed the one-time hassle. (Also, you don't have to move the prior pages; you can just move a few key pages, like Wikipedia:Articles for deletion itself, and leave the old ones alone.) WhatamIdoing (talk) 05:39, 27 July 2024 (UTC)[reply]
      • I've been around long enough to remember the move from Wikipedia:Votes for deletion. It was a one-time hassle, yes, but it was a major hassle. (Uncle G may want to comment; xe did most of the legwork IIRC, and is still active.) —Cryptic 05:51, 27 July 2024 (UTC)[reply]
        • It was indeed a huge undertaking; no, we do have to move a huge amount of pages (as my major work 'bot did); and as JPxG points out there is more in place nowadays that is hardwired to the page prefix (from the templates that we invented at the same time, to people's private add-in scripts) than there was back then. Moreover we are not checking notability. We are deciding whether an administrator hits a delete button on an article, for those cases where it isn't obvious on sight that the article should be deleted and 1 person alone can safely make the decision to press that button. It's a very clear name for the very single purpose that it is there for. Stuff outwith the decision about whether an administrator hits a delete button or not is intentionally left to the editorship at large. Uncle G (talk) 02:08, 28 July 2024 (UTC)[reply]
          I'm also old enough to remember the VfD days. Anyway, AfD has its problems. What it's called is not one of them. Let's worry about stuff that matters. RoySmith (talk) 02:25, 28 July 2024 (UTC)[reply]
          @Uncle G I appreciate the clarfication that this tool is focused on assisting administrators with clear cut deletion decisions, leaving broader editorial judgments to the communiity. Maybe having a name that reflects this purpose, like "Rapid Deletion Assist" or something similar, could be helpful. BlackOrchidd (talk) 09:15, 7 August 2024 (UTC)[reply]
          "Rapid Deletion Assist"? Did you mean Category:Expired proposed deletions? Or perhaps WP:CSD? Or perhaps Special:Nuke? Also AfD is a venue and a process, but not a tool (those are pieces of code).
          Maybe we should leave the name as is, so we don't have to rewrite thousands of scripts and move a half million pages. If there's one deeply embedded major nomenclature failure on the project, it's Notability. The amount of confusion about / discomfort with AfD would need to increase by two orders of magnitude before it would be worth renaming at this point.
          Apologies for the grumpiness. My keyboard keeps crashing, which I hate is a thing that is possible. Folly Mox (talk) 10:12, 7 August 2024 (UTC)[reply]
  • I agree with Uncle G, the current name has a clarity that said replacements would not have. Even if the new name is somewhat less intimidating to newcomers, it's better to be upfront about what's happening. ― novov (t c) 06:14, 28 July 2024 (UTC)[reply]
  • Rename to Articles for Discussion?, in line with the other XFDs. I had a similar query and sometimes feel uncertain about nominating articles when I'm on the fence if they should be deleted/merged/redirected. The 'AfD' acronym is also maintained. Svampesky (talk) 23:11, 30 July 2024 (UTC)[reply]

Rephrase the talk page box "Description" prompt

[edit]

I propose to change the message string at MediaWiki:Discussiontools-replywidget-placeholder-newtopic from Description to Your talk page comment.

The current "Add a topic" interface

Currently if a user clicks "Add a topic" on an article talk page, a box appears which prompts them for a "Subject" and a "Description".

"Description" is somewhat cryptic in that context, and seems like a placeholder string that was never reassessed. A talk page message or question isn't really a description of anything. In some contexts (like Talk:ChatGPT and Talk:Google, talk pages which ended up locked in response to so many people mistaking "Add a topic" for a direct query to those services) asking for a "Description" may, to some users, look more like a prompt to communicate privately with a generative AI or web service, rather than the start of a human conversation with Wikipedia editors.

I raised the suggestion more broadly at the idea lab earlier in the year and was told that, regarding a change to this specific interface message, altering these strings will affect all pages. This change has to be very carefully considered. So here's a concrete proposal to change it. Will "Your talk page comment" make sense in all contexts where this string is displayed, and would we agree that it was an improvement on "Description"? Belbury (talk) 14:06, 8 August 2024 (UTC)[reply]

We can certainly improve on "description", and "Your talk page comment" would be such an improvement although I am not immediately certain it is the best we can do - especially if this appears anywhere other than talk pages? Perhaps something as simple as "Your message" would work? Thryduulf (talk) 14:13, 8 August 2024 (UTC)[reply]
"Your message" is a definite improvement to "Description". Schazjmd (talk) 14:18, 8 August 2024 (UTC)[reply]
Notified: WT:UX, WT:TPP. I would also be interested to hear what PPelberg (WMF) or others on the Talk Pages Project think of this. Sdkb talk 15:12, 8 August 2024 (UTC)[reply]
  • This is a smart suggestion; thanks for raising, Belbury! I'm inclined to support "Your message" for conciseness and to be on the safe side given Thryduulf's concern that it might be used outside of talk pages. Sdkb talk 15:15, 8 August 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1239313917"