Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VPR)
"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]
Thanks for clarifying that Sohom. Aszx5000 (talk) 09:01, 9 August 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]

Deploying Edit Check on this wiki

[edit]

While attending Wikimania this year, Selena Deckelmann (User:SDeckelmann-WMF) demonstrated a new feature for Visual Editor, Edit Check in a session. Edit check introduces additional prompts in Visual Editor when an editor tries to insert a blacklisted URL as reference and also when they try to publish a revision without inserting a reference. This greatly helps with encouraging editors inserting references in their edits. If I recall correctly, the percentage of editors inserting references increased from 11% to 40% in their tests (do correct me if I am wrong as I am going off on my recollection).

There is certainly some benefits in enabling this, primarily on improving the verifiability and reliability of content that's on English Wikipedia. Most of the sister projects have already been deployed with this feature. English Wikipedia does not have this feature enabled yet. The only thing that is holding back this feature is that Visual Editor is not set as the default editor for anonymous and new editors.

Therefore, I would like to propose that:

  1. Visual Editor be the default editor for anonymous and new editors.
  2. Deploy Edit Check.

– robertsky (talk) 17:26, 9 August 2024 (UTC)[reply]

I thought Visual Editor is already the default for new accounts and unregistered editors? Folly Mox (talk) 17:59, 9 August 2024 (UTC)[reply]
The last time I checked, new editors are presented with a pop-up box that asks them to choose which editor they'd like to use, with the solid blue button pushing them a bit toward the VisualEditor.
This thread is rather underdeveloped. For a proposal of this magnitude, I think we should figure out relevant factual questions (like what the current default is) and then draw up a more formal survey that could be CENT-listed, etc. Sdkb talk 19:05, 9 August 2024 (UTC)[reply]
Another question is how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)? Thryduulf (talk) 19:08, 9 August 2024 (UTC)[reply]
In theory, this sounds like a great idea. I'm eager to try it out, but I think a first step would be to make it available as an opt-in on enwiki. Then after people have got some experience with it, let's come back and talk about making it the default. RoySmith (talk) 20:09, 9 August 2024 (UTC)[reply]
Here's an userscript that I cooked up: User:Robertsky/edit-check-optin.js. It adds &ecenable=1 to edit links that goes to Visual Editor (mw:Help:Edit_check#Testing_Reference_check). – robertsky (talk) 20:37, 9 August 2024 (UTC)[reply]
There's a simpler option for userscripts that should work: window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;
So long as that's there before VE loads, it should force you to have edit check. Either method also bypasses the account restrictions on edit check, so you're not quite getting the pure experience that people would if we just turned it on for enwiki. By default it only shows up for new users (defined as under 100 edits), and someone might want to edit the configuration on-wiki for that. DLynch (WMF) (talk) 21:26, 9 August 2024 (UTC)[reply]
The add-reference check is very conservative currently. You need to be a user with less than 100 edits who has added a whole new paragraph of at least 50 characters (configurable per-wiki) that contains no references before it'll pop up. This can all be loosened up in the future, whether by default or through community configuration, but we figured that those criteria had pretty low odds of being a false positive to start with.
It's quite interesting that this boosts the percentages so much, because I honestly thought that complete new-editors would be doing far more minor edits. But no, major new blocks of text are pretty popular.
It's actually turned on with the reference check everywhere but 8 of the wikipedias (bn, de, en, hi, id, nl, pl, ru), so it's pretty easy to try it out on another wiki if you don't want to jump through userscript hoops here. DLynch (WMF) (talk) 21:34, 9 August 2024 (UTC)[reply]
Not sure where ReplyTool will put this, but nothing I'm seeing in the documentation requires VE to be the default editing interface in order to deploy the new tool. So deployment doesn't seem contingent upon answering the larger question of whether VE should be default. Folly Mox (talk) 22:17, 9 August 2024 (UTC)[reply]
Unless things have changed in the last year, it doesn't need it to be the default, but editor does need to be in the visual editor, and that's somewhat more likely to happen (especially for the editor's first edit) when the visual editor is the default. WhatamIdoing (talk) 01:29, 10 August 2024 (UTC)[reply]
The functionality is targeted towards new editors and anonymous editors, therefore the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Also there are on wiki configuration options that we may want to adjust. As stated by Dlynch (WMF) above, the tool is configured by default for an user with less than 100 edits and making revisions of more than 50 characters. – robertsky (talk) 04:15, 10 August 2024 (UTC)[reply]
Minor quibble: enwiki has already got the prompts about blacklisted URLs for references/links. We rolled those out everywhere on the logic that any edits involving them were going to get blocked-on-save anyway so it wasn't going to disrupt any workflows. :D
It's a bit fuzzy because we called the project "Edit check", and we're developing a specific system called edit check (of which the "add reference" check is the first example), but we're also doing smaller edit-enhancement features along the way that colloquially get called checks just because of the project.
To use the famous quote: "There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors." DLynch (WMF) (talk) 21:43, 9 August 2024 (UTC)[reply]
Given the information you've provided.
Conduct a thorough analysis of the potential consequences of setting Visual Editor as the default for anonymous and new users. Consider factors such as user experience, editor retention, and overall editing patterns. If making Visual Editor the default is not feasible, investigate other strategies to increase Edit Check adoption. This could include targeted outreach to experienced editors, promoting the feature through in-editor messages, or developing incentives for reference usage. Regardless of the chosen approach, it's essential to closely monitor the impact of Edit Check on reference usage and article quality. This data will be crucial for refining the feature and measuring its overall effectiveness.
BlackOrchidd (talk) 09:31, 10 August 2024 (UTC)[reply]
BlackOrchidd, please sanity check your chatbot's AI response before posting embarrassing things like this. Folly Mox (talk) 13:04, 10 August 2024 (UTC)[reply]
  • I'd support making Visual Editor the default, as long as they also leave wikitext editing as an option (which I'm sure they will). VE is much better nowadays than when it was first released. As a WYSIWYG editor, I suspect it is much more new editor friendly. It is unarguably better at things such as automatic citation generation and table editing (adding and removing columns and rows, moving columns and rows around). And for the few things it is bad at (such as complicated template syntax), power users can just switch to wikitext editing. Any logged in user can select their default at Special:Preferences (under "Editing mode"). –Novem Linguae (talk) 10:47, 10 August 2024 (UTC)[reply]
    Agree 100% MichaelMaggs (talk) 12:00, 10 August 2024 (UTC)[reply]
    I totally agree that VE should be the default for new users. I use VE every day, and it's just fine for most stuff, and getting better incrementally. Folks who think VE should not be the default should go to edit-a-thons and try teaching new users. 20 years ago, wiki-markup was the new hotness and was miles ahead of editing raw HTML. Today it's just a barrier to entry for potential new editors. RoySmith (talk) 12:24, 10 August 2024 (UTC)[reply]
  • When I first edited English Wikipedia as an IP editor, I found WikiText editing very difficult to understand. I’m sure that most new IP editors face this issue. I strongly support making the Visual Editor the default. New IP editors are often unfamiliar with Wikipedia and may not know how to cite a reference using the WikiText editor. They may also not know how to switch to Visual Editing. Frankly, I still have to check the preview before publishing edits using the WikiText editor because I sometimes make mistakes. GrabUp - Talk 11:08, 10 August 2024 (UTC)[reply]
  • Potentially minor bugbear alert: The visual editor reference creator still hasn't figured out the basic functionality of allowing for an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first. It's not a groundbreaking issue, but it's really disappointing that it's still around after so long, especially given the many words given over the years about attracting more diverse perspectives etc. The default reference tool that we are going to create a pop up asking all new editors to use should allow for sources from authors whose names don't fit into the common European name format. It may be hidden behind an additional field button, but at least the wikitext reference creator has the option. CMD (talk) 12:10, 10 August 2024 (UTC)[reply]
    My biggest bugbear is the lack of ability to set a reference name. For example in this edit I switched from visual to source editing so I could reuse citations between prose and infobox. Although admittedly this is not something a brand new editor wants to do, being able to set a name other than ":0", ":1", etc would be rather handy. Thryduulf (talk) 12:28, 10 August 2024 (UTC)[reply]
    Agreed, that's a huge bugbear. It was the sixth most agreed upon community wish for 2023, and something that is also already part of the wikitext reference creator. CMD (talk) 12:39, 10 August 2024 (UTC)[reply]
    All programmers should read Falsehoods Programmers Believe About Names, and then re-read it every few years to refresh their memory. People who design database schemas should re-read it every time they start a new project. I agree that it's not a showstopper for our purposes, but it is a surprising lack of cultural sensitivity from an organization which is so into i18n.
    For me, the biggest bugbear is that there's no good way to convert a {{cite web}} into another template without basically starting from scratch. It really should be smart enough to figure out that if {{cite web}} has a "first=" field, it can safely map that into {{cite news}}'s "first=" and so on. It won't be perfect, but it'll get you most of the way there. RoySmith (talk) 12:57, 10 August 2024 (UTC)[reply]
    @Chipmunkdavis @RoySmith Visual editor follows the definition of the template parameters at Template:Cite web#TemplateData (and so on for other cite templates). I think the developers would also wish that you didn't require the name to be split into two fields; it's a chore to fill it out this way. If you think this can be changed, please edit it there. Matma Rex talk 13:58, 10 August 2024 (UTC)[reply]
    @Matma Rex you are entirely correct that VE gets its field definitions from the templates. The first part of my comment about first_name/last_name ethnocentricity applies equally well to template writers.
    But, the part about being able to convert one type of citation to another really is a VE issue. The "automatic" feature of the VE template editor is very handy, but it often can't intuit the proper type of template (that's not VE's fault) and falls back to using {{cite web}}. It would be really handy if you could say, "Please make that into {{cite news}}, and do the best job you can converting the fields". RoySmith (talk) 14:38, 10 August 2024 (UTC)[reply]
    Please post corresponding Phabricator tickets for all mentioned "bugbears". 1) Having tickets for these things and 2) making noise in them is the best way to move these fixes forward. –Novem Linguae (talk) 14:31, 10 August 2024 (UTC)[reply]

Wikipedia:Notability (species)

[edit]

An RfC to adopt a guideline regarding the notability of species has been opened at Wikipedia talk:Notability (species)#Proposal to adopt this guideline. C F A 💬 00:06, 10 August 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1239629095"