Wikipedia:Village pump (idea lab)/Archive 54

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56

Disallowing invalid signatures

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

(previous title was "Disallowing signatures with LINT errors")

We currently have a bunch of humans and bots fixing WP:LINT errors, and we do not let people create new signatures with LINT errors. However, signatures set before c. 2020 are not affected and are used in discussions, creating more errors for bots to clean up. Per this post at phab, the technical infrastructure is already in place to eliminate the grandfather clause, in which case invalid signatures would default to the "standard" signature. Therefore, I think we should set $wgSignatureValidation to disallow and $SignatureAllowedLintErrors to an empty array (which would implement the described changes). We would have to send out some mass messages to inform people of the change.

This would also "disable" signatures that have a link to none of: (ADDENDUM 19:31, 26 November 2023 (UTC): this category would comprise the majority of signatures affected)

• Your user page
• Your user talk page
• Your contributions

(This bit is already part of WP:CUSTOMSIG/P, but it is not enforced via the software on old signatures)

Relevant links include:

• The February RfC which resulted in consensus for bots perform LINT fixes en masse
• The proposal/consultation (at MediaWiki) which led to signature validation
• The list of LINT bots
• The guideline about <font>...</font> tags in signatures
• The list of users with LINT errors in their signatures and who have contributed to a discussion in the last three months (ADDENDUM 19:31, 26 November 2023 (UTC): this report also tracks sig-too-long-post-subst errors; those signatures would not be affected by this proposal.)
• The userscript that made getting these links so much easier. No more underscores in section links!

Thoughts? HouseBlaster^talk 02:53, 26 November 2023 (UTC)

Pinging @Matma Rex, @AntiCompositeNumber, and @Jonesey95. WhatamIdoing (talk) 05:45, 26 November 2023 (UTC)

Thanks for the ping. I don't really have anything to add to this discussion right now. I would be happy to answer questions about how exactly this works (I wrote the code some years ago), although it looks like the confusion in the discussion below has already been cleared up. Feel free to ping me again if you need any answers, though :) Matma Rex talk 16:35, 27 November 2023 (UTC)

This seems very desirable. I believe the proposal would result in non-compliant signatures being automatically replaced with username/talk/date as in my following signature. Johnuniq (talk) 05:58, 26 November 2023 (UTC)

Seems like a good idea to me. We would just need to mass message everyone who would be affected as mentioned so that people aren't confused. Galobtter (talk) 06:04, 26 November 2023 (UTC)

HouseBlaster, _{Thanks for the script link, I should add page title copying (already do whole wikilinks, but I can see how page titles are sometimes preferred) to my script as well.}
I suggest we leave a talk page message for all 226 users from your link with a templated message to suggest they fix their signature themselves and making the config changes a month later. Even if all 226 users fix their signature, there will be users with bad signatures who just haven't been active for a while.
There are actually a few names on the list I recognize. @Adam Cuerden, @Ahecht, @Davest3r08, @EarwigBot (@The Earwig), @InternetArchiveBot (@Cyberpower678, @Harej), Y U NO have valid signature? — Alexis Jazz (talk or ping me) 07:09, 26 November 2023 (UTC)

I will note that the list is just for people that edited in the last three months. If this goes ahead, we should do a quarry to get everyone. I realize that we will be messaging a bunch of accounts last active a decade ago, but I would point to WP:USURPNAME or the mass messages sent for SUL finalization (m:Single User Login finalisation announcement and phab:T74123) as precedent. HouseBlaster^talk 07:27, 26 November 2023 (UTC)

We should notify everybody, not just the editors on that three-month list. I will note that the vast majority of signature errors are not actually Wikipedia:Linter errors, since a group of editors has been notifying editors for over three years with messages like this. Almost all of the errors are for other validation failures. – Jonesey95 (talk) 07:40, 26 November 2023 (UTC)

Is there an error after the templates are substituted? Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 17:10, 26 November 2023 (UTC)

Adam Cuerden, looking at User:Adam Cuerden/FP signature maybe it's a false positive. That page is 251 characters so would push you over the limit of 255, but it contains some substitution itself and your actual signature is 209 characters after all substitution is done. I suspect the software wouldn't block your signature as it's not a lint error. — Alexis Jazz (talk or ping me) 17:21, 26 November 2023 (UTC)

If that shows up in a list of LINT-failed signatures, how many others are false positives? Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 17:42, 26 November 2023 (UTC)

The list includes more than just lint errors - it mentions for Adam Cuerden's signature that the error is that the signature is "sig-too-long-post-subst". I would hope the actual software check fully substs before checking length. Galobtter (talk) 18:24, 26 November 2023 (UTC)

209 characters is not too long. --Redrose64 🌹 (talk) 19:50, 26 November 2023 (UTC)

It appears that the tool does not fully expand nested substitutions, unless I am missing something (which happens a lot). I have posted a note to T248632. – Jonesey95 (talk) 20:22, 26 November 2023 (UTC)

@Alexis Jazz: Thanks for the ping. I'm pretty confident my signature (and my bot's) is not too long: 114 and 106 characters respectively. And thanks for your subsequent clarification that these non-issues wouldn't be affected by this proposal. ;) — The Earwig (talk) 14:11, 27 November 2023 (UTC)

There is enough agreement here to move the question (without these replies) to proposals. I would just notify recent editors. Notifying everyone would probably involve pointless commentary on long-gone users, including those who have been indeffed. Lighting up people's watchlists is unwelcome. If someone who hasn't edited in the last three months returns and notices their signature isn't what they expect, they should think that something has changed during their absence and with luck they will find somewhere to ask. Johnuniq (talk) 09:42, 26 November 2023 (UTC)

Johnuniq, maybe the period for inactivity could be stretched to 2 years or so. (and exclude indeffed editors, and if possible also exclude {{Deceased Wikipedian}}) I'd wager someone who returns after more than 2 years won't remember they had customized their signature anyway. — Alexis Jazz (talk or ping me) 10:04, 26 November 2023 (UTC)

This already links a larger project, phab:T248632 about this topic, which seems to be for all WMF projects? I'd rather see this done a wmf-default then try to do something for only enwiki. — xaosflux ^Talk 10:57, 26 November 2023 (UTC)

There are two reasons I brought this here (i.e. enwiki). One is per this comment which says in part If you convince the community of English Wikipedia (or any other project) that they should disallow obsolete HTML tags in signatures, then I'd be happy to make a config change that would enforce that (for that project only) (this is now the config flag $SignatureAllowedLintErrors). Second, getting this change done globally would entail cross-wiki mass messages, which brings in questions of translation, how many notifications we need (do we notify a user once? once per project they have an account? once per project they have edited?), etc. I would like this to be global, but I think just doing enwiki is a good first step. HouseBlaster^talk 15:20, 26 November 2023 (UTC)

The mw:Editing team had been planning at least two messages per affected user, at each affected wiki, probably for editors who had made any action during the last year. WhatamIdoing (talk) 23:35, 26 November 2023 (UTC)

This is trying to fix a non-problem. Already there have been bots and people putting in a lot of effort to fix something that does not matter. Just let the signatures decay in newer browsers that don't support the old syntax. They will likely still display the text for the name of the user. Early on I just signed "GB" and it could be hard for bots for figure out who that was. But it does not matter. Graeme Bartlett (talk) 11:08, 26 November 2023 (UTC)

I realize that we are on opposite ends of this particular debate (and I deeply respect your opinion), but I think that ship has sailed. Bots are already fixing old signatures; this would actually decrease the amount of edits they will make. HouseBlaster^talk 15:20, 26 November 2023 (UTC)

The problem, Graeme Bartlett, is that there are still people signing with invalid sigs like "GB". That diff is from 27 October 2023. Those people's signatures should be changed to something valid. – Jonesey95 (talk) 20:31, 26 November 2023 (UTC)

@Jonesey95: If you spot such "signatures", serve them a {{subst:Uw-siglink}} as I did here. --Redrose64 🌹 (talk) 22:19, 26 November 2023 (UTC)

Thanks for that link. I think the idea of this discussion is that a bot or AWB editor would deliver a similar message to a few hundred editors all at once, and then after some period of time without a change, their signatures would be changed for them. I'll wait for this discussion to conclude before taking action on my own, since it wouldn't make much sense (to me) for those editors to get two such messages in close succession. – Jonesey95 (talk) 22:33, 26 November 2023 (UTC)

Ahecht, an effect similar to TALK
PAGE without line break may be achieved with TALK PAGE though the actual display may depend on browser/installed fonts. Perhaps it can be optimized. — Alexis Jazz (talk or ping me) 11:49, 26 November 2023 (UTC)

@Alexis Jazz Thanks, but I believe the tool is mistaken, as the technical enforcement prohibits line-break or carraige-return characters but not <br> and <p>. I'll keep that in mind if I get any serious complaints that my signature is disruptive, I believe it meets the spirit of WP:SIGAPP even if it's a technical violation since it doesn't negatively affect nearby text display. --Ahecht (TALK
PAGE) 17:10, 27 November 2023 (UTC)

Ahecht, I gave it some thought. Line breaks are probably prohibited because they break up lists and would complicate finding the signature in wikitext. For <br> this doesn't seem to be the case. But if your signature timestamp and signature userlink are separated by a <br> it might confuse some tools. At any rate, it looks terrible.
Your <br> lives inside of an inline-block. I doubt this particular case would cause technical problems. The font is very tiny so accessibility could be a concern, but you also have a userlink with the regular font size so the talk page link is just extra. There may be an alternative though that doesn't require a line break nor depends on word wrapping:

<b style="background:#f4a;color:#fff;padding:0.04em;"><sup style="display:inline-block;min-width:3em;font-size:0.5em;">TALK</sup><sub style="margin-left:-3em;font-size:0.5em;">PAGE</sub></b>

Result:
^TALK_PAGE — Alexis Jazz (talk or ping me) 18:10, 27 November 2023 (UTC)

Comparison of three different ways to format Ahecht's sig

This is what those three options look like for me. The original is the only one that displays like I expect it to. WhatamIdoing (talk) 19:59, 27 November 2023 (UTC)

WhatamIdoing, hmm, guess it still depends on what fonts you have installed and/or browser engine. SVG would be more appropriate I think, but images are not allowed in signatures. — Alexis Jazz (talk or ping me) 20:51, 27 November 2023 (UTC)

@Ahecht and Alexis Jazz: I mean, you can change the target link of an image, so there's always an option to use a small image in a pinch. Though that could have issues for our blind Wikipedians. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 00:55, 28 November 2023 (UTC)

SIGIMAGE says that images in signatures are not an option. Anomie⚔ 01:51, 28 November 2023 (UTC)

Isn't there an emoji for "TALK OVER PAGE BLUE BACKGROUND" yet? We seem to make an exception for those. —Cryptic 02:09, 28 November 2023 (UTC)

Here are some more versions to try: TALKPAGE TALKPAGE Anomie⚔ 02:26, 28 November 2023 (UTC)

This should be done. The links you've presented already shows the en.wiki community consensus and the greater WMF one on the matter. We don't really need yet another discussion for this. Gonnym (talk) 12:24, 26 November 2023 (UTC)

As the guy who BOLDly deprecated WP:A5, I hate discussion for the sake of discussion. However, the folks at phab really like RfCs with closing statements (see also step two of m:Requesting wiki configuration changes#How to request a change). HouseBlaster^talk 15:20, 26 November 2023 (UTC)

Another thought while we are here: should we also propose enforcing the post-subst sig length limit? I do not see that documented as a configurable option, but I don't think it would be too hard to implement. Maybe phrasing this as (two separate proposals?) "enforcing WP:SIG through the software however feasible" + "no more LINT, period". HouseBlaster^talk 15:20, 26 November 2023 (UTC)

HouseBlaster, enforcing the post-subst sig length is difficult I think. For the MediaWiki software to check it it would have to substitute the entered signature. It needs to access the DB, have any further templates substituted, have parser functions executed, all while saving preferences. That's a very different kind of validation compared to validation required for other inputs which can be completed without accessing other resources. This could result in bugs. I suppose it could be done onblur() of the signature input field, such a check could be circumvented but that doesn't really matter as changing the content of the substitution target afterwards is easier than disabling JS in your browser. But a gadget can't do this as those can't be loaded on Special:Preferences, so that would have to be part of the MediaWiki software. — Alexis Jazz (talk or ping me) 16:26, 26 November 2023 (UTC)

Fair enough; I have struck it as out of scope. HouseBlaster^talk 19:31, 26 November 2023 (UTC)

I continue to believe the entire concept of lint errors is nothing more than a classic WP:Parable of the wildflowers and hence oppose this change. * Pppery * _{it has begun...} 16:40, 26 November 2023 (UTC)

Oppose. I've never seen a Lint fix actually touch my signature as done; I think it just doesn't like the pre-subst: and flags it. If you can't point out a LINT error in the signature at the end of this, then the bad-LINT detection is wrong. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 17:14, 26 November 2023 (UTC)

I have clarified the proposal: your signature would not be affected. sig-too-long-post-subst is tracked at the list, even though there is no currently no technical way to enforce it (which is probably why it less accurate than the other errors). I originally came across this as a way to reduce lint errors, but framing this as mainly a LINT fix was a mistake on my part: most signatures would be disabled for non-LINT reasons (namely, they do not have a link to their local user / user talk / user contribs page). HouseBlaster^talk 19:31, 26 November 2023 (UTC)

Forgive me if I'm wrong, but surely that's a requirement already, right? Is there any example of not doing that (Presuming one-out-of-three is sufficient). I mean, there's always ways around it; For example, this (between the arrows) → Adam  Cuerden ← technically contains a link to my user page (It's linked to a hair-space, the narrowest possible whitespace character I found on a quick glance, just after my first name), but sometimes you just have to accept that certain violations have to be dealt with by admins, not programming. But that's kind of an aside. I'd say requiring a link to one of the three is fine, and if that affects a subst: chain in someone's signature where the link gets buried, well, can't be helped. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 20:34, 26 November 2023 (UTC)

It would be great if we could Obi-Wan the brains of people who are referring to this as a discussion about Linter (or "LINT", which is not valid capitalization), since only 19 of the 226 current errors in this week's list are Linter errors like "missing end tag". Most of them are violations of other signature rules, like not having a link to your user/talk/contributions, or linking to a user page that does not match your username (105 and 31 entries, respectively). I don't think anyone is talking about retroactively fixing pages where those invalid signatures were applied. We're just talking about fixing signatures that are presumed to be currently in use (i.e. the editors have at least one talk page edit in the last three months). As far as I can tell, the "too long after substing" list is also out of scope because the detection is not working properly. P.S. to Adam Cuerden: Yes, a link to a user or similar page is a requirement, but the new requirements applied only to new or changed signatures. Existing signatures were grandfathered in and continue to be used more than three years after the requirements started to be enforced via technology. – Jonesey95 (talk) 20:52, 26 November 2023 (UTC)

Wikipedia:Signatures#Links requires a link, but that hasn't been enforced in software in the past. WhatamIdoing (talk) 23:39, 26 November 2023 (UTC)

It's possible this discussion got off on the wrong fooot: I'd be absolutely fine with the not matching username/missing link ones being dealt with, but the framing of this was very Linter-heavy, including me getting called out for showing up in one of the buggier detection checks. It's clear that we shouldn't try and use every error code, but starting with some of the robust and non-controversial ones would make this an easy proposal to pass, then we can discuss the other codes in turn. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 20:59, 26 November 2023 (UTC)

This is turning out to be a great exercise in why RFCBEFORE is so important.... I have done some more digging and think I have untangled the various things I conflated in my head. My original proposal was born from the toolforge list linked above, but this proposal addresses a separate (but overlapping) problem.

Setting $wgSignatureValidation to disallow is hopefully uncontroversial. It is currently set to new, which prevents invalid signatures from being saved in preferences, but does not affect signatures from before this was implemented. Setting to disallow would eliminate that grandfather clause, defaulting old invalid signatures to MediaWiki:Signature.

mw:New requirements for user signatures is the complete list of reasons a signature is considered invalid, and (as I now realize) it is not identical to what is tracked at the toolforge list. The validator cares that the signature contains a link to their user / user talk / user contribs, and a few other things (all of this is already in force for newly saved signatures). Notably, Line breaks and sig-too-long-post-subst are not considered invalid by the software (and this proposal would not change that). The validator also requires signatures be lint-free unless that type of lint error is listed at $wgSignatureAllowedLintErrors (see Wikipedia:Linter § List of lint errors for the different types). Currently, that list contains only obsolete-tag (primarily <font>...</font>, but also <strike>...</strike> and <tt>...</tt>). Setting this to the empty array would make the validator care about obsolete tags (which would prevent them from being used in new signatures, and if $wgSignatureValidation is set to disallow, default old signatures to MediaWiki:Signature). HouseBlaster^talk 23:05, 26 November 2023 (UTC)

It would be great to disallow these long-obsolete tags in signatures. Allowing them to be added with new edits just means more bot and human cleanup when support is eventually removed for those tags. – Jonesey95 (talk) 01:17, 28 November 2023 (UTC)

Adam Cuerden, your hair-space userlink is technically fine, tools like DiscussionTools, reply-link (if you manage to load it), ConvenientDiscussions and my own userscript should detect that just fine. If any bot would use it (not sure any do), they should have no problem with it either.
The admins might have a problem with it though. — Alexis Jazz (talk or ping me) 22:09, 26 November 2023 (UTC)

@Alexis Jazz: Well, yes. Just pointing out we can't try to block everything. At some point, humans are better judges. So if we can stop the problems one can make by mistake, e.g. failing to link or, say, if I linked to User:Adam by mistake (more likely if my name was, say, User:Adam356, admittedly) ... that's going to be very helpful, but if we focus on trying to fix everything, including things with buggy reporting tools, and especially if we're going to have continuous checking so something can suddenly go wrong one day, it feels like this becomes a mess. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 20:36, 27 November 2023 (UTC)

A reminder that VPI is not the place for bolded support/oppose !votes. Also the list of users is for more than just lint errors; in fact most of the people listed here are for not lint error issues. Galobtter (talk) 18:30, 26 November 2023 (UTC)

It's also worth noting, this or the future discussion isn't a question about lints and whether you think they are worth fixing or not. We had that discussion here and any argument on the merit of that is purely disruptive. The discussion should only be on if or how to implement the above proposal. Gonnym (talk) 12:02, 28 November 2023 (UTC)

Moving to VPPROP

I have drafted an RfC in my sandbox (permalink); feedback/wordsmithing is welcome. HouseBlaster^talk 06:16, 27 November 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Change edit summary after publishing an edit

I am annoyed when I’m using the Visual Editor, publish my edit, and add an edit summary, only to realize that I put an edit summary I instantly regret putting. It happened to me tens of times. I want a solution to this problem. I propose a solution named “Live Summary” which does just that. Equalwidth (C) 14:36, 2 December 2023 (UTC)

I note this sort of thing has been suggested before. Once it was pointed out that then you'd need a history for edits to edit summaries, and then the edit summaries in each edit summary's history would similarly need to be editable and have history, it has generally been acknowledged that this seems like a lot of complexity for not much benefit. Even if you do get consensus for it here, you'd need to convince software developers to write all the code to make it happen. Anomie⚔ 15:07, 2 December 2023 (UTC)

I make a lot of mistakes in edit summaries, mainly typos. If you think an edit summary will cause problems, make a dummy edit to mitigate the problem in a new edit summary. Donald Albury 18:27, 2 December 2023 (UTC)

Isn’t that a little inconvenient? Equalwidth (C) 18:57, 2 December 2023 (UTC)

I'm like Donald Albury in that I make many errors. Usually they are inconsequential, so I just let them go, but occasionally I will make a dummy edit to correct things. I don't think that that approach is any more inconvenient than correcting the summary would be. As Anomie says it would be nice to be able to correct the original summary, but that would be a lot of work for very little benefit. Phil Bridger (talk) 19:11, 2 December 2023 (UTC)

• Just to be snarky… this doesn’t happen to those of us who don’t bother writing edit summaries. 😉Blueboar (talk) 23:15, 2 December 2023 (UTC)

  Please don’t use emojis in the village pump, they are not helpful at all. Equalwidth (C) 04:51, 3 December 2023 (UTC)

  Please don't police other editors' language use unless it's legitimately disruptive. Folly Mox (talk) 05:06, 3 December 2023 (UTC)

  I find them quite helpful, seeing them makes me smile and keeps my spirits high so I keep working hard and helping others. Remsense留 05:12, 3 December 2023 (UTC)

  WP:FUNPOLICE Edward-Woodrow (talk) 15:59, 3 December 2023 (UTC)

I agree that a simple warning when you posting with a blank edit summary would be nice and a relatively clean add-on. When I accidentally do that, I make second dummy edit. Other ideas that would only require an extension, as opposed to new/changed WM code:

1. AI-generated edit summary, with the suggestion generated if the summary is left blank, using a model trained off of GPT (provided WMF would fund a modest amount of API calls), or maybe even some simpler non-LLM that can be run on a small server. Alternatively, such a summary can be generated automatically for blank or terse edit summaries regardless of editor wishes, and then saved for a few months on the server, visible to editors with the extension.
2. Simple edit summary checker, like spellcheck + automoderation, that warns you if you may be publishing something you regret. (Also useful for Meta and Talk page posts.)

That's all I got for now. Honestly I don't think auto-summarizing a typical WP edit requires, or even benefits from, a LLM, since most necessary info should be extractable from the markup templates used (or lack thereof) (thus an entirely competent program could be entirely linear with no AI jazz whatsoever). SamuelRiv (talk) 15:10, 3 December 2023 (UTC)

There's already "Prompt me when entering a blank edit summary (or the default undo summary)" in Special:Preferences#mw-prefsection-editing, FYI. Anomie⚔ 15:21, 3 December 2023 (UTC)

Future crosswiki citation of Wikifunctions

Of course, in its present state Wikifunctions doesn't even support numerical datatypes, so that this is not going to be realizable in the next few years is a given. And I suppose it might be obvious given their stated goals with that project, but: understanding why the pillars of Wikipedia are designed the way they are, I don't see why one couldn't just cite a mature Wikifunctions in math articles to support mathematical claims. There would need to be some assurance that the algorithm cited actually does what it's claimed as doing, but that seems in itself like a solveable second-order problem. Now I'm excited. Thoughts?Remsense留 16:50, 29 November 2023 (UTC) — Please ignore this, I didn't state my ideas clearly at all, I will try again when I'm able to do so.

I can barely understand your argument. First, can you elaborate the connection between your proposal and the pillars of Wikipedia? Next, can you give an example of how Wikifunctions can improve math articles, if not computer science articles? MilkyDefer 05:47, 5 December 2023 (UTC)

Reenabling some form of PC2 to assuage complaints about ARBECR?

Looking at RFC which prevented PC2 from being used, many of the oppose arguments have lost relevance over time, specifically lingering hostility towards PCR and complaints that ECP had only recently been enabled. In the meantime, ECP use has massively increased, and not without some pushback. Obviously this would be a long process, but a trial of PC2 may be in order Mach61 (talk) 05:39, 25 November 2023 (UTC)

The pending changes backlog is effectively zero and has been such for maybe 2 years now, whenever I've bothered to check. I personally got permissions just to watch a single page that a reviewer made an inattentive mistake on, and I realized it's the only article of the ~800 on my watchlist that is under WP:PCPP. (Incidentally, the barrier to getting PCR permissions would be reasonably low, at least on paper, as long as you don't get audited like in an RfA -- I complained about my request for that reason.)

It seems to me that PCP is underused and WP:ECP is grossly overused. I find myself, not on some crusade but just on what I think is common sense, to be frequently advocating for IP and new user agency over the reverts of other editors (though more commonly when they make complaints on Talk pages, where neither protection applies.) I would suggest instead that admins apply PCP far more liberally over ECP. (The latter sets another barrier that discourages new editors making minor corrections on popular pages; at least with PCP they don't have to write an essay to fix a comma.) Another tier of PCP seems hardly necessary when there is no backlog and no usage of the existing, already quite restrictive tier.

(Not to sidetrack the issue, but looking through protections, why is WP:FULL used for a month or more on pages where registered editors are edit warring, such as in Common Dead? What the heck happened to restricting the individual editors?) SamuelRiv (talk) 12:11, 5 December 2023 (UTC)

If I'd hazard a guess, blocked editors complain more and blocks are scrutinized more than protected pages. The page can't file an AN/ARBCOM report, after all. Jo-Jo Eumerus (talk) 12:22, 5 December 2023 (UTC)

Mandating 2FA usage for users with advanced permissions

Right now, two-factor authentification is an option for all users. If you are a user without advanced permissions, you have to request metawiki stewards to give you access. Which probably is fine for an average user but advanced permissions require advanced security. Right now, certain users on metawiki already must use 2FA.

What I propose is an analogous requirement for certain users with advanced permissions (as listed in H:ACCESS2FA, plus ArbCom members, ArbCom clerks and SPI clerks that are not already covered. I think bots could be covered as well, because a rogue actor automatically deploying malicious code via bots is probably about as dangerous as a rogue admin). So in order to get to the advanced permission/role, a user must enable 2FA or else not be able to use the account within advanced roles (they will still be able to do so within EC rights).

Now, before this goes to VPR, I have a couple technical questions:

1. Admins and other advanced permission users have automatic 2FA access but they don't have to use it. Is there a way to check that a given user with 2FA access actually uses it, i.e. they did not disable it?
2. Is there a technical implementation for disabling advanced permissions-related functions when 2FA is disabled?
3. In particular as relates to ArbCom correspondence (as theoretically non-admins can be ArbCom members, just that it didn't happen yet), is there a way to deny access to the internal email system for users not having enabled 2FA? Because surely internal mailing list access is only given to specific users confirmed to be arbs, right?

See also WP:PASSWORD. This will be impacted. Szmenderowiecki (talk) 13:39, 2 December 2023 (UTC)

Given my experience (while serving on ArbCom) at using 2FA as currently implemented in Wikipedia, I will resign my adminship if forced to use 2FA to keep it. - Donald Albury 18:22, 2 December 2023 (UTC)

What was so bad about it? Szmenderowiecki (talk) 19:41, 2 December 2023 (UTC)

Too easy to brick an account using the Wikimedia 2FA. I do use 2FA for some non-Wikipedia accounts. I don't want to risk bricking an account that I have been using for more than 18 years. Donald Albury 00:20, 3 December 2023 (UTC)

I know the feeling. I had a yahoo email from 1999 that I lost access to after changing the password for security. Regards, Thinker78 (talk) 19:17, 9 December 2023 (UTC)

@Szmenderowiecki: What problem does this solve? Is there a large number of compromised admin accounts that would be prevented by this requirement? RudolfRed (talk) 19:54, 2 December 2023 (UTC)

First, it's about defence in depth. Cybersecurity kinda works the way that it works well until it doesn't. 2FA in my view is a reasonable thing to activate - setting up takes 3 mins, takes another 5 s to login, but it is much better security-wise than just a password.

Secondly, the cases in which admins' accounts being compromised had some effect on Wikipedia are not nonexistent. As far as my research went these were User:AlisonW in 2016, User:Staxringold in September 2022. From global perspective, Rubin16 was compromised in March and glocked (was admin on Commons). So it's not hypothetical, it happens. Not every week to be sure, but

Of course, you can be compromised by other ways, such as keyloggers on your computer, viruses or other malware, and you can deploy antiviruses, firewalls, adblockers etc. to combat it. This, unlike 2FA, is beyond our control.

Also, to be clear: the idea is that admins will have their bits whether or nor they use 2FA, but it will not be possible to use these bits unless you log in with 2FA (I imagine the system can distinguish between a user logging in with a simple login and then enable 2FA while logged in and disable it before logging out vs a user logging in with a 2FA token. Szmenderowiecki (talk) 21:07, 2 December 2023 (UTC)

• Just as an aside, there were quite a few logins of long-term editors whose accounts were hacked in 2016, it wasn't just me! imho 2FA is a very good thing. --AlisonW (talk) 14:51, 9 December 2023 (UTC)

Szmenderowiecki, you don't need me to tell you that fundamentally, security is not merely about denial of access, it is also about availability of access, and is a balance. Defense in depth is a valid framework to analyze a lot of different issues, but mostly those where the possibility for knock-on effects is systematic, which compromised admin accounts do not appear to have already by design.
This isn't the most direct counterargument, but the enwiki is already suffering a bit of an adminship crisis for reasons unrelated to this discussion, and if a measure is implemented, A potential reduction of the admin pool further or one that prevents it from growing is, in my mind, a bigger distributed security flaw in the broad sense. So if it is true that this would seriously dissuade adminship, that needs to be seriously considered. Remsense留 22:28, 2 December 2023 (UTC)

Ultimately what we are speaking here is the balance between the cost of developing the system and needing to log in with an additional factor and the benefits of not needing to direct volunteer efforts on compromised admin accounts and feeling better about security of power users. For me the benefits outweigh the costs even in the current implementation in the vast majority of situations, and anyway any mandate will have some downsides, but if what is needed first is an improvement we know we are going to push for before rolling it out I can wait for it, but only if we actually do sth about it.

Also, if 2FA is the hill admins feel they have to die on, then OK I guess but IMHO that's not tackling the problem that's chickening out of it. Szmenderowiecki (talk) 23:35, 2 December 2023 (UTC)

There are shortcomings with the current implementation, as described by Risker during the 2019 RfC on requiring admins to use two-factor authentication, who also provided additional details on required improvements in their view. (Some of the concerns are specifically around the need for users to have full admin control over a personal computing device, so that appropriate software can be installed. While this is true for many, it's not something that can be assumed for all admins.) Until the infrastructure and ongoing support issues are addressed, mandated widespread use of two-factor authentication would be operationally challenging. isaacl (talk) 21:08, 2 December 2023 (UTC)

From a technical standpoint, I support #1 and #5 in Risker's suggested improvements; the WMF should have a code steward designated for the extension, and some further design work would be beneficial. — Frostly (talk) 21:19, 2 December 2023 (UTC)

If it means confronting WMF about not doing anything for the past 4 years on that front and doing their job for once with the money they have I think it's worth a try. Idon't expect much from that but the alternative is arguably worse. Szmenderowiecki (talk) 21:24, 2 December 2023 (UTC)

That, I'm all for. But while I do use 2FA, there are a fair number of requirements for that. I have full and (essentially, notwithstanding some use by family) exclusive control over several computers, including the one I normally use to edit and the one I use for the authenticator. I have a safe and secure place to keep my backup codes in case the device I use for authentication fails. That is not necessarily true for every editor, including every admin, certainly not at every point in their life. Before we start requiring 2FA, we need both improvements to how it works (I see Risker's excellent summary of those issues has been linked above), and a defined process by which someone who does get locked out can prove their identity and regain access. Seraphimblade ^{Talk to me} 22:52, 2 December 2023 (UTC)

OK, so shall we discuss the steps we should do to get to that stage? As in write a letter to WMF, or sth else? Szmenderowiecki (talk) 23:41, 2 December 2023 (UTC)

I'm not sure if "improve 2FA to be not terrible and irreversible" is an appropriate community wishlist item, but the next round is probably coming up in a few months. As to this idea, I could see mandatory 2FA for functionaries including Arbcom members, who are actually dealing with private information, and for intadmins, who have higher potential for widespread disruption, but requiring it for regular admins seems pretty unnecessary. Folly Mox (talk) 03:03, 3 December 2023 (UTC)

Intadmins already must use 2FA. Szmenderowiecki (talk) 07:59, 3 December 2023 (UTC)

@Szmenderowiecki, it sounds like you're looking for m:Talk:Wikimedia Foundation Community Affairs Committee/Talking:2024#Discussion questions, question 2: "What are the main technology topics on your mind right now". WhatamIdoing (talk) 21:53, 11 December 2023 (UTC)

I think bots could be covered as well, because a rogue actor automatically deploying malicious code via bots is probably about as dangerous as a rogue admin). I really don't think this is the case, a bot account can't really do anything more than any other editor, other than make edits faster. Also malicious code can be run using any account. Galobtter (talk) 23:38, 2 December 2023 (UTC)

• Is it really in the project's interests to force all technophobic admins to retire at once? Espresso Addict (talk) 01:02, 3 December 2023 (UTC)

  Why does not wanting to use the Foundation's implementation of 2FA make me "technophobic"? In fact, I resent that term being applied to me. The final 20 years of my working life was spent in writing production software and supporting computers and computer networks. I was also a volunteer sysop on the Novell Software Support Forums for several years.[1] Donald Albury 01:52, 3 December 2023 (UTC)

Ah, sorry, I meant I am technophobic (as my edit summary makes clear) -- the word was not intended to describe you. I would certainly resign adminship if 2FA were to be required. Espresso Addict (talk) 01:59, 3 December 2023 (UTC)

Strong no. Besides the fact that 2FA is a pain the rear, not everyone is even technically capable of using it. See my and Alexis Jazz's comments in this older discussion. Users shouldn't be forced to buy a smartphone just to pass RfA. Edward-Woodrow (talk) 15:58, 3 December 2023 (UTC)

The way I understand it, there are a few ways to implement 2FA. One of them requires you to own a cell phone and keep it turned on sitting on your computer desk all day, and then if your phone gets f'd up you are toast, and then the other one involves owning some kind of expensive dongle that tells you a code to log in with. If someone mails me one of those dongles I would be glad to use it.

One thing that makes me extremely uncomfortable about many applications that use 2FA is that it's often an irreversible account change, i.e. it is completely impossible to remove 2FA from an account where it's enabled (even if you have technical problems with it later, or the implementation turns out to be buggy, or if it's just a pain in the ass, et cetera). I guess this is part of a general trend in modern UI design -- the user's opinion does not matter and they can go to hell -- but it seems obvious to me why people would not want to make an irreversible change to their account that has a significant risk of posing major problems in their use of the website. The preferences section here, when I go to the 2FA section, seems to be very coy about whether this change can be undone later, which is another thing that seems extremely worrying. Since I know that other websites have adopted a "get bent, you have to use 2FA forever" model, it would seem condign here to note that this isn't the case here (if indeed it isn't the case). jp×g🗯️ 21:48, 9 December 2023 (UTC)

Any device that can run the time-based one-time password algorithm is needed, whether it's a phone, computer, or specialized device in a fob. The device needs to be able to know the current time accurately. (Cell phones need to keep accurate time anyway to be able to communicate with the cell network, and they synch up to network time as part of connecting.) meta:Help:Two-factor authentication#Disabling two-factor authentication explains how to turn off two-factor authentication; you of course have to be able to pass a two-factor authentication check in order to turn it off (or else attackers would just turn it off). Businesses like banks will use other shared secret information that both sides know to re-authenticate you and reset your two-factor authentication, should you lose access to your authentication device. For the general user, though, there is no secret information shared with the WMF that can be used. isaacl (talk) 22:51, 9 December 2023 (UTC)

I'm going to pile on by mentioning that the admins who have adopted the current 2FA system are those with a fascination for this kind of technology. Even in that elite group, there have been quite a few plaintive pleas along the lines of "bad stuff happened and I can't log in". If hundreds of admins who do not want another hassle in their life were required to use 2FA, there would be many more problems. We might say, well that's the price of progress but there is no problem needing to be solved. A more significant issue with a bunch of admins not being able to log in would be that the system to manually reset their password and remove 2FA would be a gaping security problem where social engineering would be likely to allow bad actors access to admin accounts. Johnuniq (talk) 03:11, 3 December 2023 (UTC)

• FYI, there are very few groups that are required to use 2FA (c.f. meta:Category:Global user groups that require two-factor authentication). There are 2 serious technical hurdles for mass adoption: (a) There is no "helpdesk" for users to report issues to where someone that could do anything about problems with 2FA will be required to help them. (b) There is no good way to positively identify users that break their 2FA, and require a reset of it. — xaosflux ^Talk 19:55, 9 December 2023 (UTC)

  FWIW, the users that are required to use it are audited periodically. — xaosflux ^Talk 19:56, 9 December 2023 (UTC)

This is an idea lab and it's a valid idea, but I think the potential loss of good admins would far outweigh any reduction in the already low level of security breaches. If a privilege I held required 2FA, whether admin or other, I'd certainly resign the bit rather than risk losing my account by adopting 2FA. Certes (talk) 16:03, 10 December 2023 (UTC)

Markdown support

Given that the language used for the site is decaying among a younger audience that often uses simpler tools like markdown for docs, I was curious if there is any interest or possibility in beginning to provide a path toward integrating markdown support to allow populations of differing demographics (e.g. younger users) to more easily be part of editing and updating the site. Oglopf (talk) 19:10, 9 December 2023 (UTC)

 Courtesy link: Markdown (I've never heard of this before; let my skim the article and I'll get back to you) Cremastra (talk) 19:59, 9 December 2023 (UTC)

Meh, nope, we use wikimarkup and will continue to do so. (and HTML, a bit, I guess). Cremastra (talk) 20:00, 9 December 2023 (UTC)

Actually, looking at the syntax, wikimarkup is about as simple as Markdown, and more powerful. Cremastra (talk) 20:01, 9 December 2023 (UTC)

Wikitext is kind of a bizarre relic from the year 2001; it's extremely difficult and idiosyncratic to parse, to the point that I believe there are literally no canonical parsers for it aside from MediaWiki itself. Markdown, on the other hand, is supported by just about every modern website (Github, every single Stack Exchange site, many commenting systems, every Reddit, Discord, etc). People know how to write things in Markdown. There's also a very large number of parsers that are capable of processing Markdown.

The other side of the coin is that Wikipedia's codebase is a total disaster. There's literally millions of pages hacked together in the bizarre patois of wikitext and template calls and HTML, exploiting bizarre edge-case behavior in the MediaWiki parser to do rather critical functions. For example, my signature exploits nested <b> tags inside of the titles of wikitext bracketed links. Lots of templates do stuff like embed a `<` or a `subst` in includeonly tags to produce some desired behavior -- note how I just typed ` to mark off that as a code block, which would have worked in markdown, but in wikitext I have to type <code><nowiki></nowiki></code>.

This would be enough of a gigantic undertaking in and of itself, but the codebase of Wikipedia is also extremely difficult to change or fix -- people who run bots to fix deprecated HTML tags are routinely brought to the public square to be questioned over it because the edits fixing HTML make a bunch of lines appear on people's watchlists. It's extremely unlikely that people would permit every page to have its source code modified to support Markdown without nitpicking every step of the way, blocking the bots, etc. There's also the issue that Markdown lacks a lot of the features wikitext has. Granted, it would probably be better to have those features implemented on top of Markdown than implemented on top of Wikitext, but you know, whatever. jp×g🗯️ 21:34, 9 December 2023 (UTC)

Let us not forget that User:MalnadachBot was fixing linter errors in a fashion that might be indistinguishable from mathematically maximum inefficiency, and that one rather underdiscussed downside of bots fixing html is that the "Sort by date last edited" functionality in Special:Search is now permanently broken, and will require dev intervention to create queries that exclude bot edits in order to function again. As it stands, if I want to find out when the last time some idea was discussed at some policy talk page, for anything prior to 2023 it's not possible, because every archived discussion page on the project was edited by MalnadachBot during 2022 and 2023. No opinion on implementing Markdown atop Wikicode, other than it sounds nightmarish to attempt. Folly Mox (talk) 22:20, 9 December 2023 (UTC)

You can sort search results by the date of page creation, which is much more stable for the cases you're talking about. Graham87 (talk) 10:07, 11 December 2023 (UTC)

As an aside, Markdown has its own idiosyncrasies, which its creator has declined to address, so there are also lots of variants of Markdown as well (though many sites follow the CommonMark specification now). Markdown has its roots in text email conventions, so it is a good fit for producing paragraphs of text (which can be indented and decorated with bullets or numbers, for example). Ultimately, it's hard representing the end of a document element without having start and end delimiters, and those conflict with the desire to have easily human-readable plaintext, so all these text-based markup languages make tradeoffs. isaacl (talk) 22:22, 9 December 2023 (UTC)

@Oglopf: You're about twenty years too late to ask for this. As noted above, the MediaWiki markup is so well-established on this and more than a thousand related websites that any attempt to change it simply isn't going to happen. --Redrose64 🌹 (talk) 14:11, 10 December 2023 (UTC)

Comment. i learned wiki in august having previously known markdown and HTML and there was no difficulties transitioning. बिनोद थारू (talk) 14:28, 10 December 2023 (UTC)

If by "markdown support" you just mean for the syntax for editor input, one option is to just program an extension on your own that just transcribes some of the basic markdown syntax into MW markup (I'd be surprised if one didn't already exist on someone's userpage or blog). You would necessarily still have to learn MW markup for links, templates, refs, and tables (since if they have any features or functionality on an article page beyond the basics they will be given in MW markup or under a template).

Every Markdown utility will parse it slightly differently according to their technical needs. So the Markdown you may use to post on Reddit is rather jarring if you normally use it to compose documents, for example. For any language the syntax differences italics, paragraph weight, etc may seem important at first glance but they're really the easiest thing to learn and correct, whereas the underlying quirks are the thing that takes much longer to understand and for which you cannot build a simple translator extension. (For a natural language analogy I'd say verb conjugation looks like an overwhelming arbitrary pain in the butt at first, and when I was in school I wished we all spoke Esperanto at times, but then one realizes that it's actually the least important part of learning the language.)

If you find using MW markup consistently annoying (which many people do when they're often switching between machine languages), then I encourage trying the visual editor, which even seasoned editors here use. SamuelRiv (talk) 17:00, 10 December 2023 (UTC)

Using VisualEditor is a good idea, as suggested above. You can also try converting text with Pandoc. — Frostly (talk) 04:52, 11 December 2023 (UTC)

Short answer is that our solution for editing accessibility for new users is WYSIWYG, adding another editor would be a massive undertaking (the WYSIWYG one has been in constant development for a long time). — xaosflux ^Talk 11:46, 11 December 2023 (UTC)

(The visual editor is an Online rich-text editor, not WYSIWYG.) WhatamIdoing (talk) 00:29, 12 December 2023 (UTC)

Add Wikipedia:Task center to top banner on Special:Contributions?

At the contributions-page, there are 3 buttons right on the top under "New contribution", being creating a new page, uploading media or starting a translation. Though encouraging folks to create content is important, I think we should have an option to find out tasks to complete to make existing articles better. NotAGenious (talk) 17:31, 11 December 2023 (UTC)

@NotAGenious: I don't see any "New contribution" on my contributions page. Do you have a gadget installed for that? Or maybe it depends on skin: I am using the legacy vector. RudolfRed (talk) 21:48, 11 December 2023 (UTC)

@NotAGenious the menu you refer to is added by the Content Translation tool. Instead of creating a specific one-off entry point for the tool we wanted to test the idea of establishing a more general space for editors to discover and start any kind of contribution, included but not limited to translation. We plan to replace the existing entry point with a better implementation of the idea: the Contribute menu.

The new menu provides an extensible list of activities that any MediaWiki extension can contribute to (no longer dependent on Content Translation). It is responsive (working on mobile and desktop) and it is already available in a small group of wikis to learn, improve and expand to more wikis. Based on the initial feedback, it would be useful to expand the current set of activities with more options for users to contribute. I created a ticket to incorporate the access to the Task Center. Feel free to track and share any comment.

Let us know if you have other ideas of activities that we could expose in the menu for users to contribute. The intention is to link to tools that provide enough guidance for users to be able to successfully engage in those activities for the first time.

Thanks! Pginer-WMF (talk) 09:26, 12 December 2023 (UTC)

Revamping the header of NPOVN

There is currently a discussion on the talk page of WP:NPOVN about revamping the header of that noticeboard. -- LCU ActivelyDisinterested «@» °∆t° 21:51, 14 December 2023 (UTC)

Portals on the main page

Portal links have been removed from the top of the main page, after a 2022 discussion. A 2021 discussion was closed as no consensus. However, in the wake of the 2022 discussion, portals were removed entirely from the main page, save for one small link promoting a "unique way to navigate the encyclopedia".

On the 14th of April, 2022, Izno implemented the Village Pump consensus. This removal was fatal for Wikipedia:Contents/Portals and for the broad-topic portals.

The graph speaks for itself. A major argument in removing portals from the main page is that they don't receive enough pageviews. Clearly, removing them from the main page significantly adversely affects the pageviews. And a little link isn't enough. The broad-topic portals are good. I say that because a lot of portals aren't, because they don't have enough maintainers.

• Should we...

1. Maintain the status quo and slowly kill off portals
2. Insert links to the broad-topic portals lower down on the main page – that would point readers to quality, informative content.
3. Have a "featured portal of the week" or similar section of the main page to highlight diverse topics
4. Something else? This is the idea lab, after all, so suggest something new!

Edward-Woodrow (talk) 18:53, 3 December 2023 (UTC)

I think even the portal-philes have accepted that the community doesn't want them and that the steep drop-off in views is an intended effect. Espresso Addict (talk) 21:06, 3 December 2023 (UTC)

We shouldn't suppress quality content on the Main Page. (—Formerly Edward-Woodrow) Cremastra (talk) 15:18, 4 December 2023 (UTC)

Clear consensus in the 2022 RfC disagrees. – Joe (talk) 08:28, 5 December 2023 (UTC)

I agree that the drop-off in views was both expected and intended.

Whether that constitutes "suppressing quality content" seems to be something that different editors have different opinions about. WhatamIdoing (talk) 21:27, 11 December 2023 (UTC)

From what I gather, the problem with deprecating the namespace entirely is the importance of Portal:Current events? Mach61 (talk) 03:37, 4 December 2023 (UTC)

It used to live in the main namespace at Current events and could easily do so again. It's always been a poor fit for the portal namespace. —Cryptic 08:40, 5 December 2023 (UTC)

Wikipedia:Current events is also fine, currently a redirect. Izno (talk) 08:52, 5 December 2023 (UTC)

Is there a reason any still active portals couldn't be merged with their relevant projects? They would seem a good match and would localise all editors active in a particular topic. -- LCU ActivelyDisinterested «@» °∆t° 20:06, 5 December 2023 (UTC)

Because portals are reader-focused topic hubs that provide an overview of the topic and provide links to more detailed articles, wheras Wikiprojects are groups of editors interested in improving articles related to the topic. "Merging" them would make no sense. Cremastra (talk) 22:20, 5 December 2023 (UTC)

It's not just portals directly linked from the main page that suffered, either. Take a look at the pageviews at Portal:Anime and manga. Cremastra (talk) 23:56, 5 December 2023 (UTC)

Notified: WT:WPPORT, WT:PORTAL, T:MP. ~~~~

Thanks, Cremastra (talk) 22:16, 5 December 2023 (UTC)

WP:ENDPORTALS and WP:ENDPORTALS2 found a substantial minority who would like to remove the Portal: namespace, though its most vocal opponents are no longer active on Wikipedia. Another major argument in the 2022 RfC was that the space at the top of the main page was urgently needed for other content, but this was never added or even identified. There is a logical connection between the main page and portals; they look superficially similar, and a good portal is what the main page would be if it were limited to one subject area. Although in a different namespace, portals are in a sense subpages of the main page. Certes (talk) 23:37, 5 December 2023 (UTC)

It was a perverse decision, in my opinion, to remove the portal links in favour of an expansive blank space, yet that was the clear outcome of the discussion. Espresso Addict (talk) 01:24, 6 December 2023 (UTC)

One option is to add a portal bar to the main page:

There may be room to squeeze one or two more portals in there, or even rotate one from a selection of portals which are good but narrower in scope, by adding a final entry something like |{{#switch:{{CURRENTDOW}} |1=Germany |2=Modern History |3=Music ...}}. Certes (talk) 12:08, 6 December 2023 (UTC)

I like that, especially switching portals in and out occasionally. Cremastra (talk) 13:24, 6 December 2023 (UTC)

It would need an RfC, as there is substantial opposition to making portals discoverable. Certes (talk) 14:33, 6 December 2023 (UTC)

I would be against exposing a potentially unregulated and deprecated namespace being surfaced on the main page. Sohom (talk) 15:09, 8 December 2023 (UTC)

Although not universally popular, I don't think the Portal: namespace is technically deprecated, as two well-attended RfCs decided against abolishing it. Certes (talk) 16:38, 8 December 2023 (UTC)

What? Cremastra (talk) 20:44, 8 December 2023 (UTC)

@Cremastra There are no actual guidelines wrt to what can go in and what cannot in a portal right? Not only that, these portals require maintainence, which the community seems to be unwilling to do. Exposing them as part of the Main page can cause people to have a bad experience especially if they end up on a page that nobody actaully maintains and has outdated information and/or is straightup broken.

Also, I agree that they are not "technically" deprecated, but at this point, the treatment the namespace gets is more akin to the failed Flow project (barely keep it working) which feels like a soft deprecation. Sohom (talk) 20:59, 8 December 2023 (UTC)

Mhm. There are few guidelines on anything, because it would be instruction creep. There's a general consensus as to what a portal should look like, at WP:POG, and other guidelines at WP:PORTAL. Cremastra (talk) 21:24, 8 December 2023 (UTC)

WP:POG explicitly states that it is a failed proposal and that it never achieved consensus and I'm unsure of how well updated and reflective of current consensus WP:PORTAL is (there is a maintainance tag on the top saying that it is somewhat out of date). Sohom (talk) 21:40, 8 December 2023 (UTC)

I know it's a failed proposal, but most portals around at least roughly follow the suggestions within it. Cremastra (talk) 21:41, 8 December 2023 (UTC)

Failing to be adopted as a guideline doesn't mean that the page has bad advice. Wikipedia:BOLD, revert, discuss cycle has failed formal proposals at least three times. WhatamIdoing (talk) 21:06, 11 December 2023 (UTC)

I wasn't really making the point that they were bad advice, I was just pointing out that there isn't enough of a active community around portals for us to consider creating a explicit guideline around it (unlike pictures, lists, community areas, articles all of which have established processes for determining what is considered "good" in the specific area). Sohom (talk) 21:47, 11 December 2023 (UTC)

This is cute and good. jp×g🗯️ 13:20, 9 December 2023 (UTC)

I've created a mock-up at User:Cremastra/MP; feel free to make changes. I've implemented Certes' additional idea of switching in narrower-topic portals; I think its important to highlight more specific portals as well, besides Physics, Geography, Society, The Arts, etc.

Of course, this is not dissimilar to how things used to look, and clearly there's enough support in regards to keeping portals off the main page to get them off in the first place... Cremastra (talk) 21:16, 11 December 2023 (UTC)

You've put the box at the top of the page, which is not compatible with 2022 RFC ("There is a clear consensus to ... move the link to the portals contents page to the Other areas of Wikipedia section lower on the Main Page"). WhatamIdoing (talk) 21:34, 11 December 2023 (UTC)

See the second heading. Cremastra (talk) 21:47, 11 December 2023 (UTC)

The box at the bottom seems more likely to gain consensus, and is at least as consistent with the 2022 decision as the change which was actually made. Judging the number of portals to advertise is difficult. I simply copied the list which was removed from the page top in 2022. There's plenty of space either side on my basic laptop, but I'm using Vector 2010. I don't know whether we should aim to fill a "typical" width (????px screen in Vector 2022) or just put the content we want there and hope it doesn't look too bad for anyone, including on mobile where there may only be one or two portals per line. Certes (talk) 21:55, 11 December 2023 (UTC)

In theory, we should be able to make the number of portals display depend on the screen width, using CSS like this:

@media(max-width:380px) {
	div.portal-extra {
		visibility:hidden;
		position:absolute;
	}
}

That's a very rough draft of CSS, mind. Cremastra (talk) 22:02, 11 December 2023 (UTC)

We definitely should not use this CSS on the Main Page! position:absolute is the devil in sheeps clothing. :) Sohom (talk) 22:55, 11 December 2023 (UTC)

Why does "Germany" feature in the list ? Also, I really really don't the fact that the icons are distracting from the more content oriented sections. Sohom (talk) 21:42, 11 December 2023 (UTC)

"Germany" is a random more narrow-scope portal. Refresh the page, and you'll get a different one. I would argue that the portals put the portals on equal footing with the other sections with their large, flashy images. Cremastra (talk) 21:49, 11 December 2023 (UTC)

@Cremastra I do not see a different portal on reload (I only see Germany). I think advertising a "random" narrowly-scoped portal on the Main Page is not the greatest idea, especially if there are no controls on what kind of portal is being advertised. Sohom (talk) 21:59, 11 December 2023 (UTC)

The final portal rotates daily in the example code above. (If it's Monday, this must be Germany.) We could use a random number instead of the day of the week, but I'm not sure what impact that would have on performance, especially if purging the main page to see another portal becomes a thing. Other options include the hour or something like (hour+day)%24 so someone who visits at the same time daily still cycles through the candidates. This being an ideas lab, at this stage I'm more concerned with proof of concept than finished product. Certes (talk) 22:00, 11 December 2023 (UTC)

@Certes Right, yes. Perhaps I should know about the Mediawiki code in question before talking about it. Cremastra (talk) 22:56, 11 December 2023 (UTC)

Most of the other Main Page content updates daily. Anyone using it as a regular read will visit once a day, so that seems like a logical interval to refresh the portal selection too, but there are several good alternatives. Certes (talk) 23:05, 11 December 2023 (UTC)

The mockup wraps at my browser zoom. Removing one item would eliminate the wrapping for me. –Novem Linguae (talk) 21:43, 11 December 2023 (UTC)

Can we restart and try something much much simpler ? How about something like this ? Sohom (talk) 22:12, 11 December 2023 (UTC)

That might be more acceptable as it doesn't display the P word, but the portal bar is more standard, more visible and (on my screen) occupies less space. Certes (talk) 22:35, 11 December 2023 (UTC)

@Certes I'm unsure of what you mean by "more standard". The {{hlist}} template is a fairly well accepted way of display multiple links to the user (and is used by almost every infobox). I do agree that it takes up more space vertically, I have made a new version that displays everything in a single line in case that is prefered (design with two lines design with single line) Sohom (talk) 00:54, 12 December 2023 (UTC)

The portal bar is standard for dipslaying portals (along with {{portal}}. I suppose we could have an hlist of {{portal-inline}}(?) but {{portal bar}} is among the standard templates for displaying relevant portals. Cremastra (talk) 00:57, 12 December 2023 (UTC)

I'm honestly fine with any template that does not show the small images that distract from the rest of the content. {{portal bar}} and {{portal-inline}} both show images which distracts from the rest of the content. Sohom (talk) 01:12, 12 December 2023 (UTC)

Oh. I like the icons because the draw attention to the portals. Otherwise, it's just a wall of text, which may have been fine in 2005, but today is completely out of touch. Cremastra (talk) 01:15, 12 December 2023 (UTC)

Icons have a higher propensity to look dated years down the line. Text and basic colors normally don't. The icon pack that y'all are using is something that was fashionable in 2012, 2013 and isn't really modern and in fact, it looks jarring with the rest of the page which has almost zero icons otherwise. Sohom (talk) 01:25, 12 December 2023 (UTC)

The icons come from lists such as Module:Portal/images/a and are easy to update. I think they add visual impact and are worth having as long as they fit in the allocated space. However, if they're going to put !voters off, links without icons are better than nothing. Certes (talk) 09:59, 12 December 2023 (UTC)

• Still support the 2022 consensus - place the portal link box somewhere at the bottom of the main page. For all the reasons expressed at the previous RFCs on this. Blueboar (talk) 00:18, 12 December 2023 (UTC)

  @Blueboar: but would you support a box of portals near the bottom, as opposed to the status quo? Cremastra (talk) 00:20, 12 December 2023 (UTC)

  As long as it is small and somewhat discrete, sure. I am not a big fan of portals, but I do understand that some find them useful. Having a small box at the bottom of the page should make them available, without “highlighting” them. Blueboar (talk) 00:30, 12 December 2023 (UTC)

  There's already a link to the main portals page on the Main Page. (⌘F for the word "unique".) The request here is to have more links. WhatamIdoing (talk) 00:37, 12 December 2023 (UTC)

  Yes. To clear up any remaining confusion, here's what we currently have (I've highlighted the line on portals for clarity):

• • Community portal – The central hub for editors, with resources, links, tasks, and announcements.
  • Village pump – Forum for discussions about Wikipedia itself, including policies and technical issues.
  • Site news – Sources of news about Wikipedia and the broader Wikimedia movement.
  • Teahouse – Ask basic questions about using or editing Wikipedia.
  • Help desk – Ask questions about using or editing Wikipedia.
  • Reference desk – Ask research questions about encyclopedic topics.
  • Content portals – A unique way to navigate the encyclopedia.

• A {{portal bar}} being added somewhere is what is proposed. Cremastra (talk) 00:48, 12 December 2023 (UTC)

  Yes, there's one wikilink (buried at the end of a list near the foot of the page) to Wikipedia:Contents/Portals, which will eventually lead the reader to some portals. However, even that has been proposed for removal as making portals too accessible. Certes (talk) 10:07, 12 December 2023 (UTC)

I've been following these discussions about portals since 2017 and I like to have my opnion. The removal of the Portals from MainPage was a consequence and not a cause of the problems with the Portal space. That's why it's best to discuss the solution to these problems before discussing the return of Portals to MainPage.Guilherme Burn (talk) 17:38, 13 December 2023 (UTC)

My position for a long time is something I stated on my archived user page, that "true portals of this site are what search engines and wiki searches lead people to, and that is the main subject articles themselves, not what we call portals". Like for vital articles, we can identify main subject articles and give them some portal aspects. Thus, my position is to kill portals and then resurrect them in the places readers naturally land. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 05:50, 16 December 2023 (UTC)

Manually remove specific edits from the watchlist

I have not been around the village pump a lot, so I am not sure if I am in the right place. Correct me if I am wrong, but as I understand, this is where proposals are first made before sending them at WP:VPR.

So I am the guy who will check several times that I closed the door, that the taps are closed, that I took everything I needed before leaving the house. It might be a result of OCD, and it can get very annoying and time-consuming. This manifests to me too while editing Wikipedia, one notable case being when I am checking the changes of my watchlist (WP:Watchlistitis...). Sometimes I can get stuck checking a really small change for minutes, wasting a ridiculous amount of time over something insignificant. The fact that the edit stays there can make me check it several times again even though I had already "made sure" everything was okay with it. So I've been thinking for a while it would be nice if I could remove the notices for specific edits once I had checked them to force myself to stop checking.

Now this is a very weird and specific rant from me but I've decided to talk about it seeing there's some other watchlist-related stuff in Wikipedia I can relate to [2] [3]. Regardless of this I think it would in any case benefit the watchlist feature anyway and make it more versatile. There's probably several other situations in which manually removing changes from your watchlist might be useful, and I also don't think it can hurt the feature in any way.

Again I apologize for this quite strange rant from me and I am aware there's some better things to discuss in Wikipedia. Hopefully some other people find it a useful possibility, personally it would be useful for me. Also, maybe this can somehow already be done and I am not aware of it, please tell me if so. Regards, Super Dromaeosaurus (talk) 21:44, 19 December 2023 (UTC)

Well on my watchlist there is a column of circles on the left. If I have seen the page, it is hollow and unviewed it is solid. But the watchlist has to update or refresh to change. Graeme Bartlett (talk) 23:00, 19 December 2023 (UTC)

Running low on administrators

Running out of low on administrators

Hey guys, I feel like this is an issue that is important to address. According to WP:Admin count, which other users and I have contributed to - since 2011, we have been having a net loss of administrators. There has been a long, gradual decline since then, with a sudden decrease in early 2023 due to new policies. I don't know how well this project can be managed with less admins around to do ever more tasks. I feel like something should change, but I do not know what should. What does the community say? Cheers, Wikiexplorationandhelping (talk) 20:48, 24 November 2023 (UTC)

I've considered running for administratorship, but I don't want to give up personal info. If the latter isn't required? Then I'd make a bid, only if nominated by another editor. GoodDay (talk) 20:54, 24 November 2023 (UTC)

It wasn't required when I ran. --Redrose64 🌹 (talk) 21:09, 24 November 2023 (UTC)

What personal information is required to be given? Personal image? I haven't been able to find anything in this regard. Wikiexplorationandhelping (talk) 22:10, 24 November 2023 (UTC)

I just may throw my hat into the ring. But, I'm aware that my chances of being elected (even though I've been on Wikipedia for 18 years), may be near impossible. GoodDay (talk) 22:13, 24 November 2023 (UTC)

You seem to be pretty experienced. I'd say you have a decent chance. Wikiexplorationandhelping (talk) 21:43, 25 November 2023 (UTC)

I've seen people who have edited less and became admins, just letting you know. Wikiexplorationandhelping (talk) 21:44, 25 November 2023 (UTC)

Well, it depends how you define "editing a lot" or "editing a little". 0xDeadbeef (talk · contribs) ^[no ping] passed RfA fine and they only have ~8K edits over two years. Edward-Woodrow (talk) 21:46, 25 November 2023 (UTC)

That's one example right there. If a user gets adminship and has less than 20k edits, I would consider that to be little. Wikiexplorationandhelping (talk) 21:55, 25 November 2023 (UTC)

Well, nobody ever found out I was a dog. jp×g🗯️ 13:24, 9 December 2023 (UTC)

Courtesy link : you're a dog. Alexcalamaro (talk) 05:49, 22 December 2023 (UTC)

This is endlessly discussed on WT:RFA, and there have been many proposals and previous RfCs to fix this - I don't see the point of this RfC. Galobtter (talk) 21:12, 24 November 2023 (UTC)

This isn't an RFC, just something that should have been posted on VPI Mach61 (talk) 02:53, 25 November 2023 (UTC)

not everything is an rfc Edward-Woodrow (talk) 20:56, 25 November 2023 (UTC)

But this was an rfc — Alexis Jazz (talk or ping me) 21:02, 25 November 2023 (UTC)

Oop, my bad. Striking. Edward-Woodrow (talk) 21:08, 25 November 2023 (UTC)

Yeah, I wanted more people to come to a consensus on something that can be done to increase adminship. I felt like starting an RfC right from the get go was a better option for quicker consensus. Wikiexplorationandhelping (talk) 21:46, 25 November 2023 (UTC)

Note that inactivity requirements were very mildly tightened a year or two ago. Administrators who left due to this criteria weren't really admin'ing much or at all before anyway, so them losing the bit doesn't actually change much in those cases. SnowFire (talk) 03:24, 25 November 2023 (UTC)

• I've been covering this subject in The Signpost a few times as recently as last month, and will be adding to it in the upcoming issue. Others took it up before me, probably most in-depth by Kudpung here. Yes, it is happening, and no, nobody knows really what to do about it. ☆ Bri (talk) 05:00, 25 November 2023 (UTC)

Moving to WP:VPI.
Wikiexplorationandhelping, with a sudden decrease in early 2023 due to new policies For those who aren't called Alexander, can you provide some links? — Alexis Jazz (talk or ping me) 05:48, 25 November 2023 (UTC)

That's when criterion 2 of WP:INACTIVE (originating rfc) went into effect. —Cryptic 06:07, 25 November 2023 (UTC)

Thanks. Admins who made <100 edits over a period of 5 years probably weren't having too much of an impact on any backlog anyway. Appointing a million administrators won't have any impact if they don't edit. — Alexis Jazz (talk or ping me) 06:16, 25 November 2023 (UTC)

Maybe this is so obvious that it's naïve for me to suggest it, but...would it be possible to have another tier below admin where many of the less-sensitive tasks can be afforded, but perhaps has less broad requirements? It sounds like kind of a huge paradigm shift, but since I feel the bar for adminship is about correct, I'm not sure what else can help. Remsense聊 06:16, 25 November 2023 (UTC)

We did that, and called them rollbackers. Then we did it again and called them template-editors, and again and called them pagemovers. (Maybe in the other order for the last two, I don't remember.) There's not really anything else to split out except the core admin abilities of deleting, blocking, and protecting, and they're too interconnected. See WP:Perennial proposals#Hierarchical structures and WP:Unbundling administrators' powers. —Cryptic 06:37, 25 November 2023 (UTC)

Aye, I knew I should've thought to think of specifics. Remsense聊 06:41, 25 November 2023 (UTC)

Remsense, fawiki has "eliminators". On Commons I suggested creating a "general maintainer" user group 4 years ago. ("huge paradigm shift" is my middle name 🤪) It didn't happen, partially because of technical limitations, partially because of concern it would cannibalize RfAs. — Alexis Jazz (talk or ping me) 06:38, 25 November 2023 (UTC)

Alexis Jazz, hum. At this point, the question of cannibalizing RfAs would seem to be moot, and perhaps even the reverse dynamic would be observed, because the intermediate "eliminator" role could be seen as a "stepping stone" to adminship that would make more people comfortable going through an RfA in the long run. Remsense聊 06:40, 25 November 2023 (UTC)

Remsense, let me quote myself from 2019: General maintainer can be a step towards adminship, but doesn't have to be.
But that was Commons and that was 2019, so who knows. Maybe enwiki in 2023 wants general maintainers/eliminators/lite admins. — Alexis Jazz (talk or ping me) 07:01, 25 November 2023 (UTC)

fawiki's eliminator has all the permissions that make people treat RFA like a big deal here. I'm not seeing anything their admin has that eliminator doesn't that anyone would care about, except for undelete and granting permissions (including eliminator!) as a kind of bureaucrat-lite. (And eliminator has deletedtext anyway, which is the part of undelete-broadly-construed that people object to handing out willy-nilly here.) That's not going to make it easier to become an admin here; it'll be just as hard to get eliminator as admin currently is, admin as hard as bureaucrat currently is, and bureaucrat as - I don't even know, we appoint checkusers and overseers and arbitrators more often than that. —Cryptic 11:24, 25 November 2023 (UTC)

For those interested, compare fa:Special:ListGroupRights#sysop with fa:Special:ListGroupRights#eliminator - there are 50 admin permissions that eliminators don't have; there is one (autoreviewrestore) that eliminators have but admins don't. Admins can also grant and remove certain permissions to others, eliminators are unable to do either. Their admins also have several rights that ours don't, mainly concerning abusefilters and flow. --Redrose64 🌹 (talk) 15:54, 26 November 2023 (UTC)

Also, does anyone know, on average, how many edits a user has made before getting adminship? It's quite a lot of information for me to dig, was wondering if anyone knows a quick answer. Wikiexplorationandhelping (talk) 21:57, 25 November 2023 (UTC)

Wikipedia:Request a query/Archive 3## of edits each admin had at the time of their RFA and #Candidate edit count at time of RFA. —Cryptic 23:24, 25 November 2023 (UTC)

Note: This was originally posted to the proposals village pump. Graham87 (talk) 08:12, 25 November 2023 (UTC)

This is just a dog howling on a hillside, a voice into the wind, I don't suppose anyone will even read this.

The problem is obvious: in Wikipedia, non-admins are allowed to do almost everything that a human can do, without use of special tools. The small minority of tasks that can only be done by admins almost all require special tools that a non-admin will never encounter. Therefore the pool of non-admins with any knowledge of what admins do is near zero. The number of non-admins who can demonstrate that they need admin tools is near zero, because by definition, they're not doing a job that needs admin tools (because they don't have them, so they can't do those jobs; circular argument). Therefore almost no one is in a position to ask to be an admin.

The only people who want to be admins are (1) misguided newbies who like the idea of blocking people, and (2) an incredibly tiny subset of people who can say "I have been diligently closing requests-for-review at the review-request requested review reviewers noticeboard for 13 years, and I'm desperately keen to be able to close requests-for-review that end in a request for relisting at the review-of-requests-for-requested-review noticeboard, which would require WP:ReviewRequestRequestGenerator rights, and so I'm applying to become an admin so that I can move review-requests". This latter group will then have to endure 25 pages of questions about why in 2002 they messed up a requested move review and how they would handle this differently if it arose again.

So quite obviously, WP struggles to maintain a decent set of admins. There will almost certainly be a boom/bust cycle over the decades, as good waves leave, and panic leads to selection of a wild-west collection again. At the moment we're in a good phase, so enjoy it while it lasts, folks. Or develop a training-route for would-be admins to pick up certain highly-needed tasks, with mentoring, oversight, and limited grant of the tools necessary for doing those tasks. It's not that complicated to arrange training; every business does it routinely. Elemimele (talk) 21:04, 13 December 2023 (UTC)

Speaking as someone who once ran at RfA but was heading toward a decline at least in part because of a self-made stupid mistake, I don't really agree with this. I knew some (though definitely not all) things I could do to help, and I knew that they required the tools, and I thought I had the temperament and general competence such that if I was an admin I'd do a reasonable job of it. I rather think most editors who are around long enough to have any degree of credibility have the temperament and general competence to be an admin...or at least, deserve the chance to try, if they wish. But I think there are a lot of people who approach RfA nominees from the standpoint of "guilty until proven innocent" rather than "innocent until proven guilty", and there are very few editors who I believe haven't made mistakes at times. Indeed, it's been argued that the best way to become an admin is to make the minimum number of edits to qualify (because the more edits you make, the greater the chance you'll make an edit that attracts attention) and never, ever say you want to be an admin (because if you want to be an admin, then clearly you shouldn't be one because you're in it for the wrong reasons).

Your point about enduring 25 pages of questions about something they did in 2002 is hyperbole, but there is a kernel of truth to it, in that I feel...or I think the general perception is that...RfA can become a bit of a star chamber focusing on one specific instance of bad judgment.

At this point, I still think that if I had the admin tools I could be of benefit, but I have no idea where help is particularly wanted, and I don't really desire to run the gauntlet just so I can, if successful, deal with more stressful responsibilities than the ones I have now. Put another way, RfA creates the sense that you're auditioning for the people...but at this point, if the people want me to admin for them, I feel they need to do some auditioning for me. I'm content to gnome for the rest of my time here, and while I'm aware that I could likely be of more use to the project, I'm not interested in jumping through hoops in an attempt to prove it. Wikipedia (usually) isn't serious business for me, and I don't want it to feel that way more often than it presently does.

I did have an admin approach me in the not-too-distant past to 'screen' me in a possible bid to nominate me for adminship, and we had a pretty candid discussion about it, and my recollection is that our consensus was that while I'd likely do fine as an admin, I'd never get the approval at RfA. Wikipedia's loss; I'm not going to lose sleep over it. DonIago (talk) 13:51, 14 December 2023 (UTC)

Doniago, yes, that makes perfect sense. I'm also not sure which areas need most help, except of course AfC leaps out as being desperately, desperately in need of more participation (and AfD's a bit rubbish too, with very many discussions having to be relisted umpteen times in hopes that enough will comment). But AfC is an area that's even more contentious than being an admin, and what AfD needs isn't more people with admin tools able to implement a delete closure, it's more normal editors willing to comment, and improve articles that are in a poor state but not bad enough to delete.

I'm sorry about the hyperbole, but honestly, on the few occasions I've looked at RfA's I've been rather unimpressed at the atmosphere in which they're conducted. Elemimele (talk) 14:50, 14 December 2023 (UTC)

I think I've made it clear that I think RfA is a bit of a mess as well (one of the significant reasons my RfA sank is because I dared to tell anyone I was running, which fine, total n00b mistake, but does it really reflect on how competent I'd be as an admin?)...unfortunately, there's not a significant enough number of people who agree substantially enough on how RfA should be changed and are passionate enough to pursue it to make change happen, so at this point complaints about RfA for me have largely become a 'been there, heard that'. I don't think anything's going to change unless and until a crisis point is reached...but I'm also not entirely convinced that things need to change in any case. I don't exactly see admins regularly saying, 'Please apply for adminship; we desperately need the support and will do everything we can to make the process as painless for you as possible.' As I alluded to above, I already auditioned for my fellow Wikipedians once...next time around, they need to audition a bit for me.

Alternately, maybe things need to be restructured so that if there's an admin who primarily intends to work at AfC, for instance, they're primarily vetted by people who primarily work at AfC and who will be working with this potential admin and will face the most scrutiny if this admin makes mistakes. As an analogy: when you apply for a job, you don't interview with everyone who works at the company; you interview with the people you'll be working for/with, with HR to learn the basic principles you need to know, etc.

I also think article creation needs to be deemphasized as a qualification. I've been here 15 years, I have over 100K edits, and I've never been blocked (I'm not sure whether I've ever been at significant risk of being blocked). I've never created an article because that's not where my strengths lie and I know that's not where my strengths lie...and if I was an admin, I wouldn't focus on areas related to article creation, so why is that even relevant to my suitability to be an admin? DonIago (talk) 15:06, 14 December 2023 (UTC)

Good point. Also if the article came from a redirect or permastub, it doesn't count as article creation. North8000 (talk) 21:17, 14 December 2023 (UTC)

I think one problem is that we constantly recruit people who are good at maintenance tasks for adminship, robbing those maintenance tasks of manpower. For instance, I passed RfA on the basis of prior work at AfD, NPP, and AfC. But after I got the bit, my activity in all of those processed dramatically declined, because I started closing AfDs instead of participating in them, reviewing requests for reviewer rights instead of reviewing pages, and... well, because AfC is a motivation-sapping garbage dump and always has been. Those are all tasks that need doing too, and I think it makes sense for admins to prioritise them because there are less people to do them, but the net result is that a lot of key processes are chronically undermanned because many of the people who are motivated and able to do them only do so for a short time before the project tells them they're needed elsewhere. – Joe (talk) 15:07, 14 December 2023 (UTC)

Conversely, I've never gotten the sense that I was "needed" (and sometimes also not wanted) anywhere other than in the areas I'm already focusing. I've commented on RFA-related stuff enough times and (maybe?) drawn enough eyes that I'd like to think that if anyone felt there were ways I could be of greater benefit to the project than, for instance, providing cynical commentary on RfA, that they'd approach me about that. :p DonIago (talk) 15:11, 14 December 2023 (UTC)

I was considering a reply but Doniago just said it all for me. I was also approached but didn't get as far as RfA. If Wikipedia ever started to accept gnomes who don't write GAs as admins, I could get by, but others are doing the job better and it would divert me from tasks which no one else does. Certes (talk) 14:35, 14 December 2023 (UTC)

• Is having fewer Admins a bad thing? (Or to put it another way: Do we really need more Admins?) Are “Admin-only” tasks not getting done? Are current Admins overwhelmed? Blueboar (talk) 15:17, 14 December 2023 (UTC)

  As far as I can tell, the answer to each of those questions is 'yes'. Remsense留 15:19, 14 December 2023 (UTC)

  Apart from whether or not a reduction in the number of active admins is detrimental, having an influx of new admins is important for the community to thrive. It alleviates pressure on long-serving admins, allowing for them to achieve better balance between helping out because they want to versus helping out because they feel obligated to continue. Task rotation helps editors gain broader experience, with more interactions across the community. That provides more opportunities to develop trust, which helps when the community needs to select people to assume various roles of authority. isaacl (talk) 18:05, 14 December 2023 (UTC)

IMO needs 3 things to fix:

1. (Probably only informally) bifurcate the role. Where only more experienced admins do things like sanctioning experienced editors. (this sort of how it works anyway). RFA has become a very high bar because respondents are thinking "Do I want to set this person up to sanction experienced editors?" This could be done informally via some guidance and the admin page and letting it be known.
2. Change the name of RFA to something along the lines of "Volunteering to serve as an Admin". This will shift the mental ground there. We need "willing and able to serve" people, not "I want this" people. And so the "I want this" title which also screens fore Type A personalities sets the wrong tone
3. Add some guidance at the RFA page to say the qualities required and review by them. Less of the "lets spend half the RFA page discussion some off-comment or rough situation"

Sincerely, North8000 (talk) 16:36, 14 December 2023 (UTC)

The selection process is very off-putting and if one has ever had a content dispute in a controversial area with any other editors, one is unlikely to get accepted.

I would suggest the best way would be by automatic promotion. Editors who have been around a certain number of years, made a certain number of edits, have created articles, haven't been sanctioned lately if ever could be automatically offered administrators' tools.

Sure some new administrators would fail to act as required. But that happens anyway and those administrators are removed. I would think that any long term editor who had not been blocked or sanctioned would have the common sense to avoid misusing administrative tools. TFD (talk) 21:38, 14 December 2023 (UTC)

I've never created an article and I would decline anyway. Adminship has its own set of problems apart from RfA. But sounds like a definite improvement. ―Mandruss ☎ 21:47, 14 December 2023 (UTC)

Offering admin status to seasoned editors who haven't been naughty is an interesting idea which might work. The bar could start very high and be lowered as necessary. Anyone who reaches the bar (or is hit by it on its way down) might be offered a mop immediately and, if they decline, become eligible for "promotion" on request unless they have sinned in the meantime.

A place to try this idea with limited risk might be new page patrol. Veterans such as myself create hundreds of pages but aren't eligible for autopatrolled because we write dabs, redirects, etc. rather than articles. Maybe we could give everyone with, say, 100k edits, 10 years' service and no blocks the autopatrolled flag and see what happens. If chaos results, we probably shouldn't be offering those people a mop. Certes (talk) 22:04, 14 December 2023 (UTC)

Was planning on waiting 'til next month. But, I'm leaning towards seeking administratorship & will likely soon make it official. GoodDay (talk) 02:05, 15 December 2023 (UTC)

Maybe try to make the mobile version of the website more comfortable for readers

For me, the display of the mobile version is not very comfortable for me and I have trouble understanding what I‘m reading. Can we make it more easier to read and more comfortable? Acman1o (talk) 01:20, 24 December 2023 (UTC)

Acman1o, what facets of the mobile reading experience are uncomfortable for you or lend themselves to misunderstanding? Special:MobileOptions allows you to adjust the default font size if that would help. The Wikimedia Foundation actually did a lot of research and testing to try to make the website as readable as possible, most recently by increasing the default spacing between lines, I think. More work has gone into the desktop skins, so depending on your device and your eyes, you might find the desktop version more comfortable, but you might be redirected to the mobile frontend unless you have "Desktop site" (or similar) enabled in your browser. The dark mode gadget (enabled in Special:Preferences) has made my experience here a lot more comfortable. Folly Mox (talk) 02:23, 24 December 2023 (UTC)

According to this announcement, WMF are planning on launching a new beta feature soon that should allow you to fine tune the typography of the site for your account. The main project page is here. I'm sure they'd welcome your feedback. Folly Mox (talk) 02:29, 24 December 2023 (UTC)

Mechanism for establishing clearly notable topics

Some years ago, YouTube took a controversial decision that prevented users from seeing the number of dislikes (or likes) to their content. This was based on the supposed psychological effect this had on content creators. While there are obvious differences in the internal workings of YouTube and Wikipedia, the underlying logic have obvious similarities that I consider relatable. I have worked extensively with new editors on Wikipedia (even though not as often as before), and one thing that is really discouraging for them is to see their article (or AFC submission) being tagged as "not being significant". You can argue that this only means the article in its present state does not have notability established, however in practice it really means pick another to write about, not this one. And herein lies the need for my proposal.

I intend to propose that there is a mechanism for listing definitely notable topics. Not just anyone should be allowed to enter and validate an entry to this list, probably only editors with reviewers rights should accept entries. Articles with marginable or contentious notability will not be accepted to this list. This will not in any way address other issues regarding article suitability, such as promotional/not written in encyclopaedic form/no references/etc but it will also reduce the number of blatant deletion or rejection of articles that usually have a psychological impact on editors. From experience, if a new editor creates an article, there is a big difference between I am rejecting your AFC because this article is promotional and I am rejecting your AFC because there is no claim of notability. This vetted list will also ensure that new editors who claim they just want to create content, will be able to do that from a pool of community chosen content. You can say there are many todo list on Wikipedia across various WikiProject, but those are not really vetted and many contain non-notable article suggestion. I really think this can work and will be value-adding even though my hunch tells me it will be hard for it to be accepted. It can very well be refactored into something better. HandsomeBoy (talk) 11:36, 15 December 2023 (UTC)

I think the psychological effect you mention, as well as the extremely common and understandable misconception that notability has some connection to significance, would be well ameliorated if we change the word "notability" in all guidance across the project to the more accurate and descriptive "alreadypublishedaboutness". Notability is a word about sourcing, not any intrinsic property of a subject, and is a definition of the word wholly divorced from standard English usage anywhere but here.

Having said that, the idea of a community-vetted central list of approved topics seems like it would be a systemic bias black hole.

An alternative idea might be to start with topics in sister language wikipediae that have passed some form of peer review but lack a corresponding en.wp article. This could be done algorithmically, and would spread out the bias to become the bias of the experienced contributors of the entire Wikimedia editing ecosystem. I have no doubt, however, that due to en.wp's stricter sourcing requirements, there are Good / Featured article analogues on other projects that would not be acceptable for inclusion here.

The real real problem, as I see it, is one of education. People seem to think that Wikipedia has an article on everything, and that therefore their thing should belong here as well. A substantial proportion of new accounts register in order to create a new article on a topic they've already selected, most of which are not the subject of sufficient prior publishing in reliable independent sources, but they don't learn that until they've had their aspirations crushed at AfC.

I think I've suggested this somewhere before, and see people occasionally ask it at the Teahouse, but a pre-draft source review would be a really beneficial process to add. Before someone starts a draft, they submit a list of 3–5 sources. Then experienced editors can evaluate them, and come back with judgements as to whether the provided sources (an important distinction, moving the conversation away from the topic, which the article proposer may have feelings about) are sufficient to establish appropriateness of encyclopaedic inclusion (another go at eliminating the term notability). Folly Mox (talk) 13:09, 15 December 2023 (UTC)

I think the dream was that draftspace and AfC would provide that kind of function, but that never materialised. It used to be something one could post at wikiprojects, but aside from Women in Red, I've not seen much evidence of editors doing this recently. The problem is that it would need to be a specialised review, by someone familiar with the appropriate subject guidelines and outcomes at AfD in that area; for example, rejections of academics at AfC tend to give the wrong boilerplate. Espresso Addict (talk) 00:51, 16 December 2023 (UTC)

No doubt a specialised review as you describe (sort of a pre-AfD) would greatly improve accuracy, and might come close to HandsomeBoy's idea of "guaranteed notability" (minimal false positives). But it doesn't take a topic area notability specialist to tell a first-day editor "source 1 is self-published, source 2 is a press release, source 3 just mentions the subject in a single sentence" etc.

I agree that the AfC declines could use an additional layer of granularity. prof being underutilised seems like a reviewer culture issue, and all the SNGs seem to have their own NN declines, but as far as I'm aware, there's no automated way to append, for example, "interviews don't help establish notability" or "a gallery hosting an artist's exhibition is not considered an independent source with respect to the artist", and the reviewers have to type it in manually, so often don't. Folly Mox (talk) 04:35, 16 December 2023 (UTC)

Sure; I guess I'm principally interested in cases where a good-faith new editor comes into conflict with an enthusiastic AfC reviewer, where the newbie has a better understanding of relevant policy than the AfC reviewer, which in my experience has mainly been over academics but also occasionally material falling under CREATIVE. DGG used to accept a lot of aca-bios from AfC and no-one (as far as I know) has stepped in to fill that chasm. Espresso Addict (talk) 05:22, 16 December 2023 (UTC)

That's a good point, and a scenario I hadn't considered. Folly Mox (talk) 05:28, 16 December 2023 (UTC)

Possibly one way to handle this would be advising new article editors to state what notability standard they are targeting. A talk page comment saying what standard and what references prove that the article passes that standard would help any AfC reviewer. -- LCU ActivelyDisinterested «@» °∆t° 17:23, 19 December 2023 (UTC)

A step in the wizard which asked the creator to check if any of the following applied (The article's subject is an academic...author...artist) and then guided them into presenting appropriate evidence to meet the relevant guideline might be useful. Espresso Addict (talk) 01:18, 20 December 2023 (UTC)

I could imagine some (possibly very small) value in the question, especially if the wizard then provided more relevant advice, but I think that claiming that I think this SNG applies is kind of pointless. Just because I think the article's subject should be evaluated according to WP:SOMETHING doesn't mean that it should be, or that other editors will apply the SNG that I've picked out (even if they really ought to). WhatamIdoing (talk) 04:20, 26 December 2023 (UTC)

• God no. We do not need a layer on top of AfC, on top of AfD, on top of PNG. GMG^talk 01:30, 20 December 2023 (UTC)

How to message a range

So, there was one day where an IPv6 made an edit/addition to an article which was later modified by an user. A little later, a different IPv6 commented on this edit on the user's talk page. The IP Range calculator says that they have a common range 2a01:cb1d:3cf:ca00::/64, and according to mw:Help:Range blocks/IPv6 this is a range with an "end-user allocation size" which I guess means "probably just one computer". The list of enwiki contributions from said range and list of global contributors from said range strongly imply that all the edits come from the same person. However, the only action that can be performed range-wide is a block. Has anyone ever thought of creating a message/ping functionality for an entire range? Jo-Jo Eumerus (talk) 10:17, 23 December 2023 (UTC)

Oh yes, messaging /64s is a perennial suggestion, which I think is currently confounded by the IP masking project. There's going to be a load of wishlist or bug requests. See for example m:Community Wishlist Survey 2021/Archive/Mirror contents of previous IPv6 talk page when a new address is assigned and phab:T112325, which lead to a number of other links. I usually recommend WP:IPHOP at times like this. In my experience anyone who is regularly editing will know how to find both your talk page and the article's talk page. -- zzuuzz ^(talk) 12:51, 23 December 2023 (UTC)

This problem should largely go away when m:Temporary accounts are rolled out (probably in 2024). WhatamIdoing (talk) 04:26, 26 December 2023 (UTC)

Or make it worse, depending on how it works. I don't see much explanation of how it applies vis-a-vis a range. Jo-Jo Eumerus (talk) 08:35, 26 December 2023 (UTC)

I've asked questions on that matter but not received answers, probably because no decisions have been made. If a vandal can just hop from 2000:9:8:7:0:0:0:1 to 2000:9:8:7:0:0:0:2 and appear like someone on the other side of the world, we'll have to reconsider whether to abandon our founding principles and disallow unregistered editing. I'm hoping that the lack of response means that the backward step of IP masking is stuck in development hell and won't be imposed in the foreseeable future. Certes (talk) 11:40, 26 December 2023 (UTC)

The docs they've posted seem to have the answers to me. It looks like IP hopping won't change the temporary account name, but clearing cookies or opening a new incognito tab will. OTOH, if you jump through the right hoops you can still see the IPs. It also looks like range blocks and autoblocks will still work as they do now, the difference is that someone who jumped through those hoops will have to look up the IP first where an IP is needed. There's a vague mention that they're going to look into ways to handle someone clearing cookies a lot. Anomie⚔ 13:47, 26 December 2023 (UTC)

Thanks. Of course, clearing cookies isn't always malicious, and tools such as uMatrix withhold cookies from sites which request but don't need them. I have it turned off for Wikipedia, because this site uses cookies in ways that help readers rather than advertisers, but casual visitors may not. Certes (talk) 14:11, 26 December 2023 (UTC)

Watchlist adjuster

I have a somewhat odd way, usually setting my time limit at two days and looking at the edit as it approaches the bottom. Such edits are usually around 30 or 40 hours old, so the more obvious problems have been caught by quicker watchers and I can check for more subtle ones. However, the pace of those edits varies greatly, so I must keep going into Preferences to adjust the time limit by a fraction of a day so as to avoid missing them. Simpler if there were a click from the watchlist to the Preference page that can make fine adjustments to it. Jim.henderson (talk) 04:48, 22 December 2023 (UTC)

A user script could probably do this. Might want to ask for a user script at WP:US/R. Please be very specific about which setting(s) you want it to be able to edit. Is it the "Days to show in watchlist" setting? –Novem Linguae (talk) 11:12, 25 December 2023 (UTC)

In the watchlist, the "Period of time to display:" dropdown has eight predefined values: 1 hour; 2 hours; 6 hours; 12 hours; 1 day; 3 days; 7 days; and 30 days. It's not necessary to use those values - just amend the URL in the browser's address bar. Using 4 days as an example, the following amendments could be used:

• From https://en.wikipedia.org/wiki/Special:Watchlist to https://en.wikipedia.org/wiki/Special:Watchlist?days=4
• From https://en.wikipedia.org/wiki/Special:Watchlist?days=2 to https://en.wikipedia.org/wiki/Special:Watchlist?days=4
• From https://en.wikipedia.org/w/index.php?title=Special%3AWatchlist&namespace=0 to https://en.wikipedia.org/w/index.php?title=Special%3AWatchlist&namespace=0&days=4

The days= parameter can have any value between 0.00001 (approximately one second) and 30. --Redrose64 🦌 (talk) 16:37, 25 December 2023 (UTC)

Ah. Thank you. And it resets the Preference for the next time I look. This URL editing trick is indeed quick and not too techie for me to remember. I normally run my ENWP watchlist at two days, but when traffic is heavier or I miss most of a day, I generally add one day and then trim it down successively by fractional days. Or, when a bot has made changes to a great many of my pictures in Commons, sometimes it's better to handle it by making the day count large. Then I adjust the number shown, usually by ten at a time. I still would like if the watchlist, along with the short list of choices in the multiple choice list, would offer a link to the Preference page for finer tuning. However, it looks like I'll follow this method from now on. Thanks again. Jim.henderson (talk) 01:59, 26 December 2023 (UTC)

There's a setting or gadget somewhere to show a blue dot if a diff in the watchlist is unread. I set mine to show 1000 revisions, then track things that need my attention by using the blue dot. –Novem Linguae (talk) 10:10, 27 December 2023 (UTC)

Curlie

Curlie is the successor to DMOZ. We have a long tradition of including links to DMOZ in lots of articles and the current template, {{Curlie}}, has 6749 transclusions. I saw it recently and thought "who uses these anymore?" Web directories used to be essential tools, but in 2024 ... I can't remember the last time I used one. Most seem to be a combination of links already easily found in relevant Wikipedia articles, the most obvious links that would come up with any search, and spam. Over time, we've come to see the external links space as something to be used sparingly, but these remain.

So, real question: does anyone use these Curlie links?

This is not a proposal to remove them, to be clear. Even if they aren't used very often, they may be sufficiently aligned with our ideals/purpose to retain them, but it seems worth asking nonetheless. — Rhododendrites ^talk \\ 18:29, 28 December 2023 (UTC)

Maybe it's time for another TfD discussion. Some of the "keep" opinions last time seemed to want to keep these links only as somewhere to send people who want to add unwanted links to Wikipedia articles. That is a very poor reason for keeping. We should be honest and tell people that their links are unwanted if that is the case. Phil Bridger (talk) 18:37, 30 December 2023 (UTC)

Grammar checker

My idea is that when you edit an article, there should be a built in grammar checker that doesn't detect spelling errors in links but instead in general text. Oo-rah! the marines are here (talk) 04:37, 21 December 2023 (UTC)

@Oo-rah! the marines are here: Please see WP:PEREN#Enforce American or British spelling. --Redrose64 🦌 (talk) 16:51, 25 December 2023 (UTC)

@Redrose64: Is there a regional variety of English in which "comittee" or "paralell" are considered correct? jp×g🗯️ 11:34, 28 December 2023 (UTC)

Not as far as I know. --Redrose64 🦌 (talk) 20:28, 28 December 2023 (UTC)

To me, the idea of a spellcheck feature built into the editing interface seems like it would have negative utility. In addition to the ENGVAR issues, spell checkers in general have a tendency to propose changing proper names they don't recognise into common terms they do, and the same goes for words in other languages, which appear with some frequency in certain topic areas. Additionally, high typo / misspelling proportions in an article can be a hint there are deeper issues, since they are often the earliest problems corrected. Folly Mox (talk) 19:50, 30 December 2023 (UTC)

Disagree. In addition to what others have stated, spellcheckers can be clumsy when applied to technical topics. A spellcheck function would be very obtuse when, say, talking about genes that often have strange names like GLUT. Even if this could be disabled, I can foresee countless edits by laypeople to "correct" something the program highlights, but is accurate. Just-a-can-of-beans (talk) 00:03, 1 January 2024 (UTC)

Allow soft deletion of unopposed nominations

Hi. I am wondering what people would think about repealing the "a page is only eligible for soft deletion if it has been PROD'd/deleted in the past" rule. I am not the most active person at AfD, but I invite anyone to go to a random page in the (recent-ish) AfD archives and ctrl+f for the word "ineligible". Uncontroversial nominations (or nominations in which the nominator leaves nothing for further participants to add) get relisted all the time because someone objected to a PROD, or it was previously deleted.

I went through the closed discussions in December, and I found 36 discussions which were relisted as ineligible for soft deletion but were subsequently deleted (usually after a few delete per nom or delete NN !votes, and perhaps some additional relists): 1, 2, 3, 4, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32, 33, 34, 35, and 36.

To be fair, I found four bluelinks that were saved because they were "ineligible for soft deletion": 1, 2, 3, 4. But I don't think that a redirect, a stub, a non-neutral REFBOMB mess, and No Pants Day justify the volunteer hours spent rubber-stamping uncontroversial nominations. Therefore, my idea: let these things be soft-deleted. Even if they were controversial at one point in time, they are not anymore. They would be eligible for WP:REFUNDs, and a single objection in the current AfD debate would still prevent soft deletion. I think it is time to get rid of this WP:CREEPy rule. HouseBlaster^talk 05:51, 2 January 2024 (UTC)

It generally takes a lot more effort to create content than to delete it, so I'd apply strict scrutiny to any proposal to relax the criteria for PRODding. {{u|Sdkb}} ^talk 22:35, 2 January 2024 (UTC)

To be clear, this would not change eligibility for PROD. It would only change eligibility for WP:SOFTDELETEing articles listed at AfD for a week (with all the associated notifications).

On a different note, I would also consider that the status quo is those 36+ articles (accounting for batch nominations) are "hard"-deleted. If someone subsequently finds sources, you either have to make a very convincing case to the deleting admin or spend a week's worth of editor-time at DRV. This proposal would make them all eligible for a REFUND. HouseBlaster^talk 23:28, 2 January 2024 (UTC)

Ah, thank you for clarifying, and best of luck formulating the proposal! {{u|Sdkb}} ^talk 23:31, 2 January 2024 (UTC)

Notes

Interest in testing a tool for Breaking News? Seeking feedback.

My team at the foundation, WME, has developed a dashboard that tries to identify new articles related to global "newsworthy" events as they are being written about across Wikipedia language editions at any given moment. You can read more about it here. I'm seeking help to improve the feature.

Here is the direct link to the dashboard. (desktop only).

I'd appreciate if anyone that tries it out can surface any potentially missing templates from across language projects that would help us capture more results. Using the thumbs up and down buttons in the demo to confirm or deny if entries are accurately identified as breaking news, would help me in the long and medium-term in building a better, more accurate tool.

Although Enterprises' focus is not on creating editing tools or gadgets, we hope this can be of use to the community, too.

Thanks! FNavas-WMF (talk) FNavas-WMF (talk) 16:19, 8 December 2023 (UTC)

Are the thumbs up/down supposed to be if the article as a whole is about a current news event, or has been created in wake of a current news event? Because e.g. you have on the tracker Mama Diabaté who died two days ago, so that would be news and result in increased traffic and editing, but her notability would have been established over decades. On the other hand 2023 Guyana Defence Force helicopter crash was created for the purpose of covering a specific important recent news event. Are both to be considered "hits" for the tracker?

Also, "indications count" isn't documented, and I don't know what it means, and it seems odd (being a count) that you can only filter numbers equal to the count as opposed to higher or lower than. I also don't think the raw number of edits is too useful of a metric for the user to filter potential news articles, since news is rather localized by interest and region. Page-views-to-editor-ratio would seem more useful -- a niche new article or split may have a lot of edits from a dedicated editor and reviewers at first, but very few outside viewers will care to see it in the first hours. Any news event will blow it out of the water in viewer-to-editor ratio, even if news stories will have more anonymous editors. SamuelRiv (talk) 16:58, 8 December 2023 (UTC)

Thanks for this feedback @SamuelRiv -- thumbs are to say, is this news or or not. there are a lot of false positives so were trying to filter what is not news. I'd consider both those examples as news. What is news and what isn't is so subjective, so really just up to the individual.

We don't use any pageviews right now, so all this is based on editing behavior/presence. Good call on the "viewer-to-editor" ratio idea ... My only issue that we could only calculate that 24/h too late (given how PV work right now). FNavas-WMF (talk) 21:10, 8 December 2023 (UTC)

A 24h delay in the ratio is fine as long as you have some smoothing average on both views and edits -- it will be better than the metrics you currently have available. (I'm sure you can figure out better metrics once you get some data.)

News isn't really subjective in these clear cases -- your first verification would just be a Google n-gram call to see if there was a major spike in searches in the past week. If the API for that is free, that'd be the best metric I can think of. There's tons of simple algorithms to verify a spike or step discontinuity in rough data. SamuelRiv (talk) 21:20, 8 December 2023 (UTC)

@FNavas-WMF many breaking news items are related to articles that already exist - so being able to see articles that have high "within last hour" activity instead of only new articles may be useful. — xaosflux ^Talk 18:08, 8 December 2023 (UTC)

yep 100% agree @Xaosflux -- i'm working on getting us to within the last hour method you describe as we speak! FNavas-WMF (talk) 21:11, 8 December 2023 (UTC)

I would go further and say that anyone who feels compelled to write about a news event on Wikipedia should look for existing articles to update rather than create a new one. This is an encyclopedia, not a newspaper. Phil Bridger (talk) 21:27, 8 December 2023 (UTC)

@Phil Bridger totally agree. It seems to me that folks, at least on enWiki, do try to add to an existing article, which is why this tools as it works now is only very good for NEW, totally unforeseen events. Do you pointing editors to existing articles that are part of news is more valuable than to new articles? FNavas-WMF (talk) 16:25, 11 December 2023 (UTC)

If memory serves, Another Believer does a lot of work with breaking news and might be interested in this. WhatamIdoing (talk) 00:33, 12 December 2023 (UTC)

Thanks for the ping. This is on my radar and I was even able to chat with Francisco a bit at WikiConference North America recently. I've subscribed to this discussion and I'm curious to see what folks say about the tool. ---Another Believer _(Talk) 00:39, 12 December 2023 (UTC)

Thanks! These comments have been very useful. I'm looking for more ways to cut down false positives to cut the noise! The "cite news" template is extremely useful to catching breaking news. It seems quite reliably used in new news events.

@WhatamIdoing @Phil Bridger @Xaosflux do you all see any more templates I should be following? FNavas-WMF (talk) 20:01, 18 December 2023 (UTC)

{{cite web}} gets used a lot as well, especially when being used by newer editors who are using one of the citation insertion tools. — xaosflux ^Talk 20:46, 18 December 2023 (UTC)

That template is probably less specific, though. WhatamIdoing (talk) 21:13, 18 December 2023 (UTC)

Indeed. But especially if you are a user (new or old) that isn't aware of some of these templates and go through the basic VE workflow of (a) Type in something (b) Click the Cite button (c) Dump in your URL -- you will end up inserting a cite web. — xaosflux ^Talk 21:46, 18 December 2023 (UTC)

@FNavas-WMF, an article being tagged with {{Current}} would be a direct indicator that we consider it a current event. But it is automatically removed by bot as soon as editing activity fades, which is often still while a layperson might consider something to be breaking news. Wikipedia:Current event templates#Current events has related templates/categorization. I'm curious how your tool uses/relates to this. An article being linked from Portal:Current events would be another strong indicator. {{u|Sdkb}} ^talk 00:12, 3 January 2024 (UTC)

Adding searching to the nearby page

Hello, Not sure is this is the correct place to put this, but is it possible to add coordinate or location searching to the nearby page, to allow for location permissions to not have to be granted? Thanks, Geardona (talk) 12:49, 4 January 2024 (UTC)

Geardona, this can be done manually with the search keywords neartitle and nearcoord. See :mw:Help:CirrusSearch § Geo Search for documentation. Folly Mox (talk) 12:58, 4 January 2024 (UTC)

Geardona you might want to see Wikipedia:Village_pump_(technical)/Archive_113#Passing_a_location_to_Special:Nearby? Sungodtemple (talk • contribs) 13:01, 4 January 2024 (UTC)

Ok, did not realise that was a feature, maybe add a search bar to the page itself for more user-friendliness? Geardona (talk) 13:03, 4 January 2024 (UTC)

Mass patrolling

Hi everyone,

I was just curious if there was any discussion earlier, as I was not able to find it in the archives. If not, is it possible to have mass patrolling done? This could be helpful when dealing with multiple edits, where a user has made minor changes such as adding a specific number or other minor details. Instead of going into each and every single one of the edits, is there any way that mass patrol can be implemented, allowing us to check and approve certain unpatrolled edits more efficiently?

Thanks!

Боки ^{Write to me!} 14:37, 4 January 2024 (UTC)

@Боки: We don't have edit patrolling enabled on English Wikipedia. Only new pages are patrolled, not individual edits. 🌺 Cremastra (talk) 01:01, 7 January 2024 (UTC)

@Cremastra If I may ask, why not ? How do you manage the information that gets posted on the Wikipedia pages then ? People can just post anything and everything. There has to be a way that this gets managed. Боки ^{Write to me!} 15:02, 8 January 2024 (UTC)

@Боки: That's a good question, but I don't really know the answer. Many users informally patrol RecentChanges to watch for vandalism, myself included. We check our watchlists, and keep an eye on worrisome editors. Things seem to generally tick along fine. 🌺 Cremastra (talk) 20:46, 8 January 2024 (UTC)

@Cremastra What about the fact if someone makes a mistake or puts some incorrect information ? How do users here correct it ? They redo it or do they just revert the edit ? Боки ^{Write to me!} 20:59, 8 January 2024 (UTC)

Yeah, someone would generally fix the problem or just revert the edit. There has been discussion of enabling edit reviewing lately, but I believe the idea was shot down. I think, in practice, edits are generally reviewed at some time or another, there's just not a special person clicking a "review" button. The process is unofficial and informal. It seems to (mostly) work. 🌺 Cremastra (talk) 21:01, 8 January 2024 (UTC)

@Cremastra The reason why I am asking is because at Serbian Wikipedia (with a lot less edits, mind you) we have bunch of reviewers (including myself) who review edits of non-auto-patrolled users which brings me to the next point, how does person here on English Wikipedia become auto-patrolled ? Боки ^{Write to me!} 21:04, 8 January 2024 (UTC)

The auto-patrolled right (where your articles are patrolled automatically) is granted by an admin through a formal request process. See WP:PERM/AP. Cheers, 🌺 Cremastra (talk) 22:12, 8 January 2024 (UTC)

@Cremastra I will definitely work towards that considering I am an interface admin of Serbian Wiki. My only concern is with this amount of edits, does it not "ruin" the reputation of article if someone can easily add something to the article without anyone noticing it for a while ? Боки ^{Write to me!} 00:26, 9 January 2024 (UTC)

does it not "ruin" the reputation of article if someone can easily add something to the article without anyone noticing it for a while Someone easily adding something to an article is how Wikipedia works. 🌺 Cremastra (talk) 00:31, 9 January 2024 (UTC)

@Cremastra I know but in this occassion, I am referring to person adding, for example, "... and this woman has been involved with my dad" (literally) as part of the article. If this does not get patrolled or checked, then this goes on the article that someone will read and say what is going on. Боки ^{Write to me!} 08:45, 9 January 2024 (UTC)

Well, to a degree that would get checked. I patrol recentchanges fairly regularly, and if I saw that edit, I would revert it. 🌺 Cremastra (talk) 13:11, 9 January 2024 (UTC)

@Боки, I think you might be unclear on the purpose of auto-patrolled. Most new articles are reviewed by a team of editors, the new pages patrol. When an editor has created a lot of acceptable articles, they can be assigned "auto-patrolled" so the reviewing editors have more time to concentrate on other articles. It makes no difference in editing abilities or rights for the editor who has auto-patrolled. Schazjmd (talk) 00:32, 9 January 2024 (UTC)

@Schazjmd on Serbian Wikipedia, auto-patrolled means we, as patrollers, do not have to check your edits (whether it's new page or just a simple edit on something) any more and you have gained trust that you will not make meaningless edits and that you know what you are doing on Wikipedia. That's what my definition of auto-patrolled is and that's what I am referring to. Боки ^{Write to me!} 08:47, 9 January 2024 (UTC)

The scale of editors on enwp, as well as automated anti vandalism tool leaves good faith but non-constructive edits. And it generally works on enwp. Incorrect Source verification is probably hardest challenge we have ~ 🦝 Shushugah (he/him • talk) 09:02, 9 January 2024 (UTC)

@Боки: With a description like that, I think that you are referring to pending changes review. That is not the same as autopatrolled, which concerns only the creation of new articles. --Redrose64 🌹 (talk) 15:22, 9 January 2024 (UTC)

Auto-confirmed

Hi. I’ve realized that it’s insanely easy to get auto-confirmed status… and I thought I had to use articles for creation forever. Would it be a good idea to make it more difficult? Say 50 edits, like on es.wp, or more time editing; one month, maybe? Encyclopédisme (talk) 14:32, 4 January 2024 (UTC)

@Encyclopédisme

What do you mean that it's easy to get auto-confirmed status ? I've been writing for years now and I still have not had my username confirmed.

Боки ^{Write to me!} 14:38, 4 January 2024 (UTC)

I mean being able, to say, move pages, create pages etc. You need 10 edits and a 4 day old account. That is auto-confirmed. Encyclopédisme (talk) 14:39, 4 January 2024 (UTC)

@Encyclopédisme Sorry, I mixed it up with auto-patrolled :) My bad !

Боки ^{Write to me!} 17:29, 4 January 2024 (UTC)

Despite the name, the autopatrolled flag is only handed out manually. Some accounts are marked as autopatrolled fairly quickly; others can be active for many years and create thousands of pages without it. Certes (talk) 20:30, 4 January 2024 (UTC)

@Certes I am one of those in the second group :) The funniest part is that I am interface administrator of Serbian Wikipedia, wrote over 800 articles there yet somehow English Wikipedia needs me to show more values.

Боки ^{Write to me!} 22:25, 4 January 2024 (UTC)

Please don't take it personally. I've created thousands of pages over the last 16 years and am not autopatrolled. The flag is simply a convenience for patrollers, and doesn't allow the account to do anything it couldn't do anyway. Certes (talk) 22:44, 4 January 2024 (UTC)

@Боки: You have been autoconfirmed since 03:20, 14 July 2020 (UTC). --Redrose64 🦌 (talk) 22:17, 4 January 2024 (UTC)

@Redrose64 Yeah, I just realized that I have misread the auto confirmed vs auto patrolled :)

Боки ^{Write to me!} 22:26, 4 January 2024 (UTC)

The section refers to autoconfirmed status, which is handed out automatically on the account's tenth edit or four days after registering (whichever is later). That link should show a box top left saying "Your account is autoconfirmed" if you are logged in to an account that is not very new. Certes (talk) 14:46, 4 January 2024 (UTC)

No any thoughts? Would it be possible? Encyclopédisme (talk) 15:43, 4 January 2024 (UTC)

I personally would keep the WP:AFC route, until an AFC reviewer recommends the article author directly publishes articles. Having multiple eyes is an asset, not a detriment. I wish sometimes as a niche publisher that more people would review my articles. I say that as someone who is WP:AUTOPATROLLED. But making space for newer article contributors is in the interest of the wider encyclopedia. ~ 🦝 Shushugah (he/him • talk) 17:50, 4 January 2024 (UTC)

I started creating 2 articles already. One of them was reviewed, the other already edited by other editors. The problem is indeed that niche subjects are widely overlooked, and due to the small audience, often state outright false info (Specifically I created articles about the Inca, also widely touched by this), based on old sources, or works of vulgarisation which don’t correspond exactly with the academic consensus. Encyclopédisme (talk) 17:56, 4 January 2024 (UTC)

If you're writing about the Inca, I'd look around for editors like User:Smallchief or User:Greenman, since they have both contributed significantly to Inca Empire in the past. WhatamIdoing (talk) 02:04, 10 January 2024 (UTC)

A Wikipedia journal

There's a lot of research about Wikipedia, but it tends to be from an 'outsider' perspective: computer scientists and computational social scientists that are interested in Wikipedia because it's a huge, open dataset; critiques of our content, or lack thereof, in specific fields; or, increasingly, experiments in replacing some or all of our work with algorithms. All very interesting and valuable, but what I'd really like to read is more studies of Wikipedia in its own terms. Things like the histories of specific policies, analyses of how processes work, biographies of prominent editors. Research like that does exist (e.g. the WMF's Wikipedia @ 20 edited volume springs to mind), but it's scattered around and hard to find.

If the Wikipedia community was a conventional collective organisation, a scholarly society or a trade union or something, it'd probably already have its own little periodical for that kind of thing. Something like The Signpost, but with bibliographic references, peer review, etc. Written and read primarily be people who are involved in, or at least have a deep knowledge of, the community. It could be hosted on-wiki like the Signpost or, perhaps better for discoverability, somewhere else, as long as it has that rooting in the community. Would anybody else be interested in something like that? – Joe (talk) 08:56, 5 January 2024 (UTC)

Well, I once wrote something that might fit there. XOR'easter (talk) 18:07, 6 January 2024 (UTC)

Well as you know I don't really agree with what you wrote there. But certainly that could be one role of a journal like this: counter-critiques to academic critiques of Wikipedia are unfortunately not going to be taken as seriously when they're published on Wikipedia itself. – Joe (talk) 13:59, 8 January 2024 (UTC)

A nice idea! A major issue is the unpaid aspect of it. On other hand, if an academic is being paid, they can push for open-access, open-data etc.. which is what a lot of meta:Wikiresearch is. I also think about wikinews:Main and the success/challenges it faces ~ 🦝 Shushugah (he/him • talk) 01:11, 7 January 2024 (UTC)

@Shushugah: Thanks. I'm not sure I follow though, who is(n't) being paid? – Joe (talk) 13:53, 8 January 2024 (UTC)

Not quite what you're describing, but there are the WikiJournals. The idea there is more about getting wiki contributions to "count for something" by sending them through peer review and formatting them as journal pieces. There was the Wiki Studies Journal which involved several Wikipedians, but it doesn't appear to still be going. Heather Ford kicked off Wikihistories fairly recently -- not sure where that's headed.

Back to your thought, though, it would certainly be interesting. I'd be curious how much enthusiasm there is. I've seen a lot of valuable research projects undertaken by volunteers that would benefit from being cleaned up and formally "published". It may also be useful to provide a forum to publish literature reviews or to critique existing research. — Rhododendrites ^talk \\ 14:26, 7 January 2024 (UTC)

My thinking exactly. This is the kind of thing people do already, and especially for users that are also in academia, or plan to be, it would be nice to be able to collect formal citations and credit for it.

Level of interest is the key. If the Wiki Studies Journal was a similar and failed, then it'd be good to know what went wrong. Otherwise, I was thinking of trying to put together an initial issue of invited contributions. If we couldn't find enough contributors, then we have our answer. – Joe (talk) 13:57, 8 January 2024 (UTC)

Don't think that's a bad idea. A similar organization—the Organization for Transformative Works (which operates the fandom web archive Archive of Our Own) operates its own peer-reviewed academic journal like this. ~ F4U (talk • they/it) 19:16, 7 January 2024 (UTC)

HaeB knows a lot about research on Wikipedia. I'm not sure that it's true that a lot of it is done by outsiders. WhatamIdoing (talk) 02:07, 10 January 2024 (UTC)

Notability reform

I have a new guideline/policy draft at Wikipedia:Article inclusion criteria, and would love to have some feedback on it. Thanks in advance! Ca ^{talk to me!} 09:06, 2 January 2024 (UTC)

What is the problem that this proposal is meant to fix? 331dot (talk) 09:23, 2 January 2024 (UTC)

I answered it in a below response. Ca ^{talk to me!} 12:06, 2 January 2024 (UTC)

Any proposal that says Downranking all SNGs to essays will not achieve consensus. Curbon7 (talk) 09:55, 2 January 2024 (UTC)

Agreed - it have been removed. Ca ^{talk to me!} 11:27, 2 January 2024 (UTC)

I respect the ambition, but realistically any massive change to WP:N would have to have been prompted by some unprecedented event or shift in community sentiment. I don't think people are actually dissatisfied with how notability as a whole works, even if some individual SNGs remain contreversial. Mach61 (talk) 10:12, 2 January 2024 (UTC)

My feedback is that it looks like you are throwing out all of WP:N and trying to start again from first principles. But why? Barnards.tar.gz (talk) 11:10, 2 January 2024 (UTC)

My first problem is with length: all the notability guidelines(SNG and GNG) make up for a reading experience nearing typical novellas — WP:N alone contributes 4000 words of reading material. However, all those tens of thousands words of guidance are thrown into a wrench by WP:PAGEDECIDE. How our numerous SNGs interacts with GNGs are defined is lacking, and newcomers are just meant to figure it out themselves. Any attempt to formally define it will inevitably be met with series of no-consensuses. I believe that hints that the way we are defining notability right now is fundamentally flawed. My goal with the proposal is instead of trying to use importance as criterion for inclusion(an insurmountably subjective and unfeasible task), but just to use the pre-existing policies as guidance. Ca ^{talk to me!} 11:19, 2 January 2024 (UTC)

Is "trying to use importance as criteria for inclusion" actually the current standard? WP:N goes to pains to distinguish notability from simple importance (except as reliable sources decide to cover it, which is the current N standard). DMacks (talk) 11:27, 2 January 2024 (UTC)

That's what it says on the tin, but reading SNGs like WP:BIO and WP:NPROF clearly shows it's more of a importance criteria than anything. Even GNG proves to be an publicity indicator since it does not actually deal with article content. I don't know why we have all these guidelines when it could be replaced with "What is the best possible article that can be made?" Ca ^{talk to me!} 11:40, 2 January 2024 (UTC)

If you feel that the criteria are not being properly applied, have you tried fixing that first before deciding that everything should be thrown out? 331dot (talk) 11:49, 2 January 2024 (UTC)

I recognize I am in a minority position with this belief but I believe notability as a system is fundamentally flawed for reasons described as above.

I made an attempt to Wikipedia:Village_pump_(idea_lab)/Archive_53#Rewriting_WP:N_to_reflect_community_consensusstandardize SNG and GNG in the past, but it was clear that any wording put forward was will fail to gain enough consensus. Ca ^{talk to me!} 12:04, 2 January 2024 (UTC)

So I'm just wondering what makes you think a broader proposal covering more ground will gain consensus when a narrower proposal didn't. 331dot (talk) 15:04, 3 January 2024 (UTC)

I would be a fool to think such a radical change like this would gain consensus. I'm poking around with different proposals to gauge community sentiment with notability. Ca ^{talk to me!} 15:43, 3 January 2024 (UTC)

The rationale behind notability is positively defined at WP:WHYN Mach61 (talk) 16:31, 2 January 2024 (UTC)

I am not sure what point is being made here. WHYN only explains the reasoning behind GNG. Ca ^{talk to me!} 16:36, 2 January 2024 (UTC)

@Ca, what do you make of the sentence at the end of WHYN that says "Because these requirements are based on major content policies, they apply to all articles, not solely articles justified under the general notability criteria"? It's been there since WHYN was created. WhatamIdoing (talk) 01:16, 10 January 2024 (UTC)

So, practicality concerns aside, I want to engage with the philosophy of this, since that's really what's interesting and it's what you're looking for.

If I'm reading correctly. you see "notability", the term of art we have built up onsite, as fallacious: we claim "notability" to be something robust and objective, independent from "importance"—which is ultimately a subjective notion—but ultimately, "notability" just boils down to just being "importance" in many cases anyway. I agree with this.

However, I'm not really convinced it's a problem that can be solved, and I think your attempt goes a ways to explain why: you've just moved the problem back a step, offloading the subjectivity at the heart of an encyclopedia onto other terms of art: how do we know when we can establish WP:NPOV and WP:V—when we feel like the framing is neutral enough; when we feel like the claim is verifiable enough? Surely these can't be solved by statistical analysis, or whatever—at least I don't think so.

Since we're also axiomizing "what Wikipedia is not"—when does an article stop being an indiscriminate collection of information, or a dictionary? Those are informed by our present policy, and now they have no practical criteria whatsoever.

The consensus mechanism we have to fill in the gaps left by the flexibility of WP:N is ultimately powered by subjectivity, but I think someone here may need to win a Berggruen Prize before we can really tackle that problem. Remsense留 09:01, 3 January 2024 (UTC)

• I've always been first in line to say that SNGs are a mess and should generally be ignored in favor of GNG, just like discretionary sanctions should be ignored in favor of simply not being a jerk. But the community is attached to their pet SNGs and there's almost zero chance of doing away with them. We got NPORN removed, and even on such an immensely niche topic, it was like pulling teeth. GMG^talk 12:47, 2 January 2024 (UTC)
• If I'm understanding correctly, the problem you're trying to address is that there are some articles that meet the notability threshold but nevertheless should not have an article because of one of the reasons at WP:PAGEDECIDE. I agree that that's a problem. My explanation for it would be that, because 95% of AfDs deal with notability rather than PAGEDECIDE, many inexperienced editors use the heuristic "notable → keep" and ignore PAGEDECIDE.
  That said, I don't think a new policy or guideline is the solution. We already have too many of those, and the impulse to replace them with a simplified version isn't going to succeed. PAGEDECIDE already has guideline status as part of the WP:Notability guideline page, so I'd instead encourage you to suggest changes to make it clearer, more easily invoked, and the notability guideline page as a whole simplified.
  Something our policy/guideline pages badly need overall is for someone good at plain English writing to go through them with no agenda except shortening/simplifying/clarifying them. It won't be an enviable task, as everything on every PAG page was added for some reason or another, so there will be a lot of discussion/pushback about how to simplify without losing meaning. But it'd really be a valuable service. {{u|Sdkb}} ^talk 23:46, 2 January 2024 (UTC)

  The main thing is, I do not understand why we have the whole vaguely defined concept of notability when PAGEDECIDE supposedly trumps everything. Ca ^{talk to me!} 02:15, 3 January 2024 (UTC)

  PAGEDECIDE doesn't trump WP:N. It says that there are times that while a topic may merit a stand-alone article that it can be shown to meet the GNG or an SNG, there are reasons not to have a stand-alone article (such as when the topic is better covered in concern with a larger topic or similar topics).

  Notability is a guideline and purposely vague because it is meant to encourage articles to start from a point that shows potential for growth so that the wiki-way can be used to expand. But as others have pointed out, this is not a one-size-fits-all approach, due to systematic bias from sources. Masem (t) 05:09, 3 January 2024 (UTC)

• If you were seriously proposing to dump GNG and its emphasis on hype and publicity and one-size-fits-all rules over importance, and try to push more subject-specific importance-based guidelines, I might be on board. This goes in exactly the wrong direction. We cannot possibly include articles on all topics about which reliable but local or routine sources have provided enough information to write start-class articles, which is what GNG pretends to do (but in practice doesn't). Instead, we need to use notability to filter out the truly unimportant topics. But because GNG does that based on publicity, it is inaccurate and easy to game. Cutting out all the nuance and making it be one size fits all can only worsen those problems, without solving any actual problem with current practice. —David Eppstein (talk) 04:43, 3 January 2024 (UTC)
• I'll echo the above comment: this seems to be a step in the opposite direction from what I could conceivably report. Moreover, it doesn't actually reduce the "subjective" aspect, just pushes it off to a different place. Who decides whether a biography is "negative", or whether all the sources are "marginally reliable", or what counts as "undue weight", or when an article is "unwieldy", or when related topics are "better appreciated" as separate pages, or when a topic is "controversial" instead of "mundane"? If the goal is to reduce the number of different policy/guideline pages, I say we go all out and synthesize WP:V, WP:NPOV, WP:NOR, WP:NOT, and WP:BLP into a single Wikipedia Rulebook. They're only separate pages due to historical accidents; if one were starting a wiki-based encyclopedia project now, with the benefit of Wikipedia's accumulated experience, one could cover the whole ethos in a single document instead of multiple pages that all talk about each other. XOR'easter (talk) 05:35, 3 January 2024 (UTC)

  A merger of just two of those policies, V and NOR, failed to get support. Since then, we've had nearly seventeen years of inertia for those policies... Mach61 (talk) 05:41, 3 January 2024 (UTC)

• Tangential note: A few people have mentioned that it's hard understand notability guidelines due to their length and detail. A couple weeks ago, I began drafting User:Wracking/Notability with the goal of creating bullet-point summaries of each SNG, mainly for my own reference. If this is something anyone wants to collaborate on, please reach out. Wracking ^talk! 05:47, 3 January 2024 (UTC)
• I tend to agree with David and XOR'easter. If I got to rewrite Wikipedia's inclusion guidelines from scratch, I'd go for specific guidelines on specific subjects, based on the consensus of editors knowledgeable about those subjects, and drop the futile quest for a Grand Unified Theory of Notability. The idea that we can use a single standard to classify literally all of human knowledge into the boxes "notable" or "not notable" would sound like complete madness to the average non-Wikipedian. And then try telling them that we think we can do so with just five bulletpoints... – Joe (talk) 09:29, 3 January 2024 (UTC)

  Yeah, what he said, and also what they said. jp×g🗯️ 11:06, 3 January 2024 (UTC)

  @Joe, in fairness, the idea that we're going to have an encyclopedia that anyone can write without even needing so much as a user account or email, that also sounds like complete madness. So not sure that "sounds like complete madness" is a strong argument against anything on Wikipedia :-) Levivich (talk) 20:57, 7 January 2024 (UTC)

• I actually think that WP:GNG is a good Grand Unified Theory of Notability, since it ties back into core policies with the theory "So, can this topic ever make a core policy-compliant Wikipedia article?". Most alternatives tend to lean into "Someone finds this important" which is a lot more subjective and tends to invite both mass stubs and snobbery. Jo-Jo Eumerus (talk) 13:37, 3 January 2024 (UTC)

  I know this comment was made last week, but it seems as good a place as any for me to add my piece of the elephant, which is that in my view the GNG works terribly as a Grand Unified Theory because it applies a pseudo-objective threshold to sets of sources and topics that are in themselves quite heterogenous. But an inflexibly-applied, source-based standard will always lead to the overrepresentation of privileged groups in biographies (like white Europeans) because they are overrepresented in reliable sources. And topics like sub-national geographies of human settlement, or national elections, will be treated inconsistently not only because of actual differences in the "reality" of each geographical or social context but even in cases that are objectively similar, simply because sources are easier to find in some instances than in others. Some periodic elections in a specified polity will meet GNG and others in the same polity will not. Some sub-national territories of a Westphalian state will meet GNG and others at the same level of the same state will not. This does not serve an encyclopaedia.

  In my view, one goal of an encyclopaedia is to treat equivalent topics in equivalent ways, and while reliable sourcing is always required, the myth that there is a specifiable level of sourcing that would work for all topics is actively detrimental to the project of building an encyclopaedia of knowledge by and for human beings. Newimpartial (talk) 02:50, 10 January 2024 (UTC)

  Problem is, "white Europeans are overrepresented" in practice means "not-'white Europeans' are underrepresented". It's a subtle distinction but it does matter: If a topic is underrepresented, you can run into serious difficulties in accurately depicting it. I don't write biographies but I've seen the same problem of a non-Western topic having much fewer sources to use in my area of editing (volcanoes, natural phenomena). Sometimes you get lucky as I did with African humid period and there is enough coverage, but other times you have Nuevo Mundo volcano with much fewer sources than the comparable Crater Flat. Jo-Jo Eumerus (talk) 08:28, 10 January 2024 (UTC)

  Obviously Wikipedia cannot publish ahead of the reliable sources. But Wikipedia can publish closer to the extent of RS coverage in areas of underrepresentation while being more restrained in publishing in areas of overrepresentation. Grand Unified Theory approaches to GNG operate in the direction opposite to encyclopaedic coverage in this respect, IMO. And this is a great example also of what an encyclopaedia for humans, by humans, can do better than neural networks can. I think the project should do that. Newimpartial (talk) 11:57, 10 January 2024 (UTC)

• Counterproposal: rename "Notability". If we're really going to rework the inclusion criteria for an encyclopaedia article here, let's do away with the confusing term "notability" and call it what it is. Right now it's something close to alreadypublishedaboutness (catchy, I know), but if we're going to redo the inclusion criteria, we could either rename the larger body of policy after what consensus agrees on the fundamental criterion is, or just call it inclusion criteria. Folly Mox (talk) 14:16, 3 January 2024 (UTC)

  That is indeed the title of Ca's original idea here. – Joe (talk) 15:10, 3 January 2024 (UTC)

  Support this idea much more than dismantling GNG. 🌺 Cremastra (talk) 00:59, 7 January 2024 (UTC)

  While I'm not convinced this is necessary per se, I'm just going to vomit a few potential terms: the crime of "notability" is arguably the "-ability". However, the term should have as little lexical overlap with "verifiability" as possible.

  How about substantiation, attestation, recognition, corroboration, representation, precedence?

  No, I don't think any of these work: I think "notability" might be the closest, best English word to use for this concept, so that the greatest number of people understand its usage as easily as possible.

  I still think it's likely we just have to live with the subjectivity at the heart of "encyclopedias" as a concept. It's not like anyone else has figured this out! Remsense留 01:33, 7 January 2024 (UTC)

  "Inclusion criteria" is the way to go. One fundamental flaw in "notability" is it suggests a property of the subject that we as editors are discovering (something is notable or not notable and it's up to us to figure out which). In fact, "notability" isn't a property inherent in any subject, it's a decision editors make (we don't discover or learn if a subject is notable, we decide whether subjects are notable or not). "Inclusion criteria" has the advantage of being clear that it's a set of rules made up by editors for the purpose of deciding what topics should be covered--and not some inherent property, or something having to do with the inherent value of topics. Levivich (talk) 21:01, 7 January 2024 (UTC)

  Oh and the inclusion criteria should be "enough reliable independent secondary sourcing to write an accurate and complete tertiary encyclopedia article" which is what GNG already tries to get at. Levivich (talk) 21:04, 7 January 2024 (UTC)

  Agree with this. This is why some SNGs, and de facto notability, are bad, because sometimes there isn't enough information out there to write an encyclopedic article. 🌺 Cremastra (talk) 21:14, 7 January 2024 (UTC)

  WP:NOPAGE literally exists, so this comment makes no sense. Curbon7 (talk) 08:48, 8 January 2024 (UTC)

  "Standards of inclusion" is the term I suggested once upon a time, in one of the longest discussions on renaming the notability page. One of the reasons was indeed that it emphasizes that it's a Wikipedia standard, not an inherent characteristic or externally defined property. These days I usually use the more clunkier "standards for having an article", due to Wikipedia:What Wikipedia is not, as it is another standard of inclusion based on scope that is typically evaluated independently of the guidance on the notability page. isaacl (talk) 22:34, 7 January 2024 (UTC)

  I've long said that we should rename it to something that refers to our criteria or requirements for having a Wikipedia:Separate, stand-alone article. Creating redirects for your favorite titles could be a way to identify possible future titles. WhatamIdoing (talk) 01:33, 10 January 2024 (UTC)

I have to agree with Remsense on most points. While some kind of notability reform is needed, this is not the best way to go about it. Currently, apart from some less stringent SNGs, all articles have to meet GNG. This keeps out of one-reference sub-stubs that are better suited to wiktionary or wikidata. If we remove GNG, then our only rationale for deleting unhelpful articles that wouldn't be notable under GNG is likely a combination of WP:NOTDIC, WP:NOTDB, WP:INDISCRIMINATE, and WP:5P1.

The problem is that all of those are mostly or entirely subjective. Who decides what qualifies as an "indiscriminate collection of information", or what "encyclopedic" really means, when you get right down to it? We already have these disputes (case in point: the Barbenheimer RfC), but if they became commonplace at Articles for Deletion, matters would get worse.

We shouldn't rely on subjective measures. We already do, to a degree (how much coverage is "significant" coverage? How reliable is this source, really?) but implementing such a proposal, and accordingly dismantling the GNG, would intensify existing disputes.

The GNG is not great. But it works, and it's quantifiable, at least more so than allusions to WP:NOT. You need multiple sources, three is recommended, and they have to be reliable and secondary.

I think we should have more, specific, SNGs, that are objective and easily quantifiable. Notability isn't a yes-no question, but if we have more subject-specific notability guidelines, then we can be more accurate. Vaguer standards aren't helpful, because vagueness invariably leads to disputes. 🌺 Cremastra (talk) 18:26, 7 January 2024 (UTC)

I asked (again) about defining SIGCOV last year. The answers can be divided this way:

• [the minority view] We have found and cited at least one source that uses words like 'significant' or 'important' to describe the subject. For these few editors, two short sentences are good enough, so long as one of the sentences says something like "He's the most significant Ruritanian player during the last decade". They're wrong, of course, but it suggests that @Ca is on the right track with the idea of editors wanting to screen out subjects they believe are unimportant.
• [the common view among experienced editors] We have found sources that contain enough facts to write an article, as measured, e.g., by word counts or by information contained. However, editors are afraid of saying how much is enough, because as soon as they say "a subject is notable if it gets a total of 2,908 words spread across four news articles in a newspaper on the top-20 list in the List of newspapers by circulation, counting only one article from each year and at least one of the articles has to contain two photos, plus evidence that the subject was mentioned in a still-extant source on social media by a person who won an Olympic medal", then some horrible spammer is going to destroy Wikipedia by getting their stupid little unworthy subject covered in depth by all of these sources, and then where will we be? Plus, if I say that we require 2,500 words in sources, then that might keep out the stuff that I want to write about. If we leave it vague, I can say that my subject only needs Wikipedia:One hundred words in sources, but your subject needs thousands, and unless you're watching my every word, you'll never notice what a hypocrite I am.

We did not come to an overally conclusion, but I think that

• we basically agreed that sources containing information that is useless in practice ("I heard a funny joke this morning...") plus content that is potentially useful in an article ("Paul Politician's birthday is on the 32nd of Octember") should only have the potentially useful parts counted towards any sort of word/fact count, and
• we inched towards the idea that a couple hundred words of potentially useful content is SIGCOV (i.e., not just a couple of sentences, but also not requiring whole books, or even whole chapters).

WhatamIdoing (talk) 01:54, 10 January 2024 (UTC)

then some horrible spammer is going to destroy Wikipedia by getting their stupid little unworthy subject covered in depth by all of these sources, and then where will we be? Plus, if I say that we require 2,500 words in sources, then that might keep out the stuff that I want to write about. If we leave it vague, I can say that my subject only needs Wikipedia:One hundred words in sources, but your subject needs thousands, and unless you're watching my every word, you'll never notice what a hypocrite I am. Incredible. This describes me exactly. 🌺 Cremastra (talk) 02:15, 10 January 2024 (UTC)

This is what I'm getting at when I gesture to the subjectivity at the heart of an encyclopedia. The encyclopedia genre is synthetic, no one has ever figured out what "should" be in one. It would be very difficult to stomach an overturning of consensus that has existed the entire length of the site, that the presence of some classes of article is a serious net negative to the site, even if it means being arbitrary and potentially keeping some good articles from being created. I believe this very strongly.

I don't want to edit on a site that looks like Urban Dictionary, Reddit, or the oldest editions of the Brittanica in spots: it feels bad, incurious, lacking united understanding in what we're doing here. It's cultural and subjective, but I'm okay with that. Remsense留 02:33, 10 January 2024 (UTC)

@Cremastra, I think it describes all of us, when we feel like the stakes are high enough. WhatamIdoing (talk) 02:36, 10 January 2024 (UTC)

WP:Notability is a big vague confusing mess but it mostly works. IMO the way that it really works is that it combines 3 attributes:

1. Sourcing criteria which ostensibly is the only criteria. This is also used as a measuring stick for #2
2. Real world importance/notability
3. Degree of enclyclopedicness .....degree of compliance with Wp:not, above the floor of outright rejection under Wp:not

If we ever want to tidy up wp:notability, we're going to need to acknowledge this as a starting point. North8000 (talk) 14:29, 3 January 2024 (UTC)

I agree with this. There is a balance between coverage (how often and how in-depth a subject is featured in independent sources) and the importance of the subject. There ought to be or there is more flexibility of sourcing needed for individuals who are at the top of their profession (whether in academics, sport, politics, business) compared with individuals who are active locally, in minor or secondary leagues, or non-executive positions. This is why the SNGs are useful - to help make determinations of real world importance. - Enos733 (talk) 18:23, 3 January 2024 (UTC)

For example, if two published high school newspapers did lengthy in depth coverage of guitar player John Smith, that fully satisfies GNG but the system might not let that one pass. If the same two writeups were in Rolling Stone magazine, the system would certainly pass him. So the prominence of the sources (combined with the space they dedicated) matters for assessing #2, and #2 matters.

Another example: A town of 1,000 people with no sources other than a couple which (merely) reliably establish it's existence. The system is going to let that one be an article. Some will say it's because "GNG sources are likely to exist" but in reality it's because it's an ultra-enclyclopedic topic. Because it passes wp:not by a mile, and is also mentioned in 5P. North8000 (talk) 21:53, 3 January 2024 (UTC)

Agreed. When we let the sports SNGs die, we inadvertently opened the door to a lot of minor league baseball players, because minor league baseball necessarily receives a bunch of local/routine coverage which looks like or could be GNG even if the player never comes close to making the major leagues, which was functionally necessary to enter a print baseball encyclopaedia. I'm not generally a fan of SNGs, but the ones that exclude rather than include can be very helpful. SportingFlyer T·C 07:01, 4 January 2024 (UTC)

I knew at the time that that fix was only going to be 1/2 of a fix. In the "grand wp:notability unification" that I have in my head, it

• Acknowledges that real world notability/importance is a factor and the coverage is a measuring stick for that as well
• Calibrates for the ratio of coverage to real world notability in that field. Since in sports coverage is an end/product of itself and so less of / a weaker indicator, coverage in this area is less meaningful and it adjusts for that
• Calibrate for degree of enclyclopedicness. A typical sports artticl is a bit lower here than a typical enclyclopedia article and it adjusts for that

The net result would be that the standard would be a bit tougher for sports than it currently is. North8000 (talk) 18:14, 4 January 2024 (UTC)

Third RfC on Vector 2022

• Wikipedia:Requests for comment/Evaluation of Vector 2022 is open.

Æo (talk) 20:56, 9 January 2024 (UTC)

Oh god, why? It's not even the third RfC, it's the eleventh, and when you guys floated this at VPI last you got a resounding please don't. – Joe (talk) 08:49, 10 January 2024 (UTC)

It's a survey with actual voting. A place to dump all your complaints and wants. Maybe something with more focus will come out of it but I wouldn't want to be the one who had to summarise it. Doug Weller talk 16:59, 10 January 2024 (UTC)

Rethinking WP:Spoken Wikipedia

I think spoken versions of articles have some of the most potential for improvement of any area of the site. Of course, the existing paradigm has an obvious central issue: recordings become out of date almost immediately, which dissuades both potential narrators and listeners. I've thought a bit about this, and I have a preliminary idea for a format that could at least exist alongside the existing spoken articles: abridged spoken sections. Especially on good or featured articles, it seems like sections could be excerpted, possibly adapted to be better read aloud (adapted to a "podcast" form, if you like), and then those could be recorded. Because they are their own text—which would also exist as a readable transcript, of course—they wouldn't immediately go out of date, while reflecting both the work put into the accompanying article and the needs of listeners. Remsense留 04:47, 8 January 2024 (UTC)

Why wouldn't these excerpts also be prone to going out of date?

I'd be interested to know how many people prefer listening to an out of date version of an article, versus having a screen reader read the up-to-date version.

I also wonder if effort could be focused on marking up difficult passages to assist screen readers in some way. Barnards.tar.gz (talk) 08:58, 8 January 2024 (UTC)

Because they would have their own transcript that may be edited to have particular suitedness to being read aloud—they would only meaningfully become out of date if the substance of the part of the article that was abridged changes, not just minor changes in wording or sentence reshuffling.

I think screen readers are the other major reason articles aren't read anymore, but I think—albeit as someone who uses screen readers but does not require them to read—that they're just not as nice a lot of the time? Sure, people can set screen readers to a blistering pace they're still comfortable with, but they still produce errors and best-fit algorithmic awkwardness. There's plenty to explore in a "podcast" presentation to achieve what screen readers cannot. Perhaps the format can diverge even further—during a discussion I was having a few days ago, the possibility of writing for/recording a dialogue format came up, and I think that has potential. Remsense留 20:57, 8 January 2024 (UTC)

I think the best way to solve the outdating issue would be to create a clickable tool or function that would use something like AI or computer speech that would be in-built in Wikipedia that can read the text in all articles exactly as they currently stand. Helper201 (talk) 21:50, 8 January 2024 (UTC)

As already mentioned, many people already use screen readers that are highly customizable by each individual user: we are discussing a potential form of spoken article that would also be less redundant in the age of screen readers. Remsense留 21:53, 8 January 2024 (UTC)

Screen readers have existed longer than Wikipedia has. They've probably become a bit more mainstream though, with VoiceOver and Google TalkBack being pre-installed on smartphones. As a screen reader user, I'm very text-oriented so I almost never use Spoken Wikipedia and would almost never use spoken excerpts either. I don't think many proficient screen reader users would. Graham87 (talk) 06:08, 9 January 2024 (UTC)

Thank you very much for your insight. This may seem like an off-topic question, but what about podcasts? Are they perceived as too slow or inferior to (hypothetically) equivalent passages from books using a screen reader as well? If not, what advantages do they have? Are there any advantages for you personally to have something narrated by a person as opposed to a screen reader, or are the disadvantages simply too great? Remsense留 06:15, 9 January 2024 (UTC)

@Remsense: Sorry, just got this. Lots of blind people like them; several use audio players to speed them up. I don't listen to them often though but I'm probably an outlier that way. If both a podcast and a transcript were available, I personally would only listen to the podcast if I wanted to find out what a person's voice was like ... or if the production had sound effects, etc. that couldn't be conveyed through a transcript. As I said I'm a bit more extreme than most blind people this way though. Graham87 (talk) 12:21, 11 January 2024 (UTC)

I just remembered Wikipedia:Village pump (proposals)/Archive 186#Spoken narrations of the blurbs at Today's featured article (TFA), which has some similarities to this section. Graham87 (talk) 12:27, 11 January 2024 (UTC)

Pinging @Isaidnoway:, who also uses a screen reader and expressed the polar opposite view from mine in that discussion. Graham87 (talk) 12:30, 11 January 2024 (UTC)

Export to PDF, Epub, Odt and LaTeX

Hi, I would like to include mediawiki2latex in Wikipedia. It exports wiki articles to PDF, Epub, Odt and LaTeX. Yours 11:43, 15 January 2024 (UTC) Dirk Hünniger (talk) 11:43, 15 January 2024 (UTC)

Excise the "crime" topic from the "law" topic; make "law, government and administration" an established grouping of topics

As an editor largely focused on law and legal philosophy articles, I find it hard to locate articles on subjects relevant to me and my expertise on Wikipedia-space pages that are sorted by topic (like WP:FAC, WP:GAC, or WP:RfC).

The undifferentiated inclusion of the very popular "crime" and "law enforcement" categories (here I don't mean categories in the technical sense) in the overall fairly unpopular "law" category means that most articles sorted under "law" turn out to be "Murder of so-and-so" or "Jimminy Bob Killman (murderer)"-type articles which require no particular expertise in any country's law or any field of legal scholarship. In terms of the skills required to contribute, they are perhaps closer to biography or history articles, or they might be in a category of their own.

Since law is a fairly underappreciated topic on Wikipedia (I find), it may be appropriate in some contexts to group it together with related topics. I would suggest that "government" be split off from "politics and government" where it exists, and merged with "law" and a newly minted category, "administration", forming the "law, government and administration" category. ("Government" would thenceforth focus more on formal/institutional political science and social philosophy, whereas "politics" would be retain people, parties, ideologies, and what have you.)

I'd be interested in alternative solutions, though, since two objections to the idea do spring readily to my mind: For one, public law is arguably the only government-/administration-adjacent field of law, and private law should be appended to the "economics" topic or something. For another, grouping law with government might create the impression that the law is definitely an institution of the state (the government), or even synonymous with it. This is not undisputed; especially some jurists in the common law tradition (found e.g in England and the U.S.) maintain that it is fundamentally a set of societal traditions, influenced by, but not derived from, the state.

What I'll be looking for when I put the finished proposal out is a consensus that the new categorization/grouping practices be recommended for internal and public-facing categorization purposes.

Again, I'd love to hear perspectives and suggestions. If you could tell me which user communities I should notify about this post or the finished proposal so that consensus is representative and the relevant people are aware of this re-systematization, I'd also be much obliged.

§§ LegFun §§ talk §§ 22:20, 13 January 2024 (UTC)

I was going to recommend -deepcat:"Crime", but there are too many subcategories and the search fails. Folly Mox (talk) 02:44, 14 January 2024 (UTC)

Have you tried searching incategory:"WikiProject Law articles" -incategory:"WikiProject Crime and Criminal Biography articles" ? Make sure you are searching in the Talk: namespace or maybe just go through Category:WikiProject Law articles 115.188.140.167 (talk) 10:16, 14 January 2024 (UTC)

Are you looking for articles to edit, or specifically for FAs and GAs? SuggestBot can look at your contributions and suggest a list of articles that you might be interested in. WhatamIdoing (talk) 23:44, 14 January 2024 (UTC)

Thanks for those recommendations! SuggestBot and the specific phrasing of the search terms provided, in particular, sound useful for my purposes. I was hoping to help bring already high-quality law articles into the spotlight by reviewing/supporting them in the FA/GA processes, which is why I was looking there specifically. I also want to get a general idea of the structure and weak points of jurisprudential Wikipedia.

That said, I'm not sure if looking for articles listed by WikiProject Law will help in every case. Wherever articles of all topics are listed for specific encyclopedic purposes, the poor categorization of law will make things hard; which is why I wanted to achieve a general consensus before I charge ahead with shifting around categories. Additionally, I'm not too well-versed in Wikipedia's more technical side, so any list-producing bots that automatically compile articles into categories would need to be adjusted by more adept minds.

Incidentally, it occurs to me that perhaps I ought to get WikiProject Law on board first . . .

§§ LegFun §§ talk §§ 08:04, 15 January 2024 (UTC)

I agree that making friends over at WPLAW is a good idea. Also, take a look at Wikipedia:Version 1.0 Editorial Team/Law articles by quality statistics. The top- and high-priority articles are probably the ones you want (or, the ones you want should probably be considered top- and high-priority; the categorization is not always perfect). Wikipedia:WikiProject Law/Popular pages might also be useful to you. WhatamIdoing (talk) 17:32, 15 January 2024 (UTC)

Bibliography articles

We have a number of articles titled 'Bibliography of X'/'X bibliography'. Sometimes these are lists of works by a subject, eg Virginia Woolf bibliography. Sometimes they are lists of works about a subject, eg Bibliography of Andrew Jackson. Sometimes they're both, eg Harold Pinter bibliography. Is "both" a desired approach? For example, if I wanted to split out some of the massive bibliography at Virginia Woolf, would I add it to the existing Virginia Woolf bibliography or would I create a new article? And if the latter, what would that be called to distinguish it from the existing article? Nikkimaria (talk) 21:06, 7 January 2024 (UTC)

That massive bibliography at the Virginia Wolfe article isn't just a bibliography, it is part of the references. The article uses shortened footnotes, so each of those sources is the target of a hyperlink from the short footnotes in the references section. So they can't be moved to another article. Since the term "Bibliography" is ambiguous I would rather articles used the terms Citations / References for the two sections rather than References / Bibliography.

This doesn't answer your question, however. StarryGrandma (talk) 10:19, 8 January 2024 (UTC)

Many of the works listed at Virginia Woolf#Bibliography are in fact not referred to by any of the shortened footnotes: more than eighty of them, at a quick count. A script like User:Trappist the monk/HarvErrors marks these.

To answer Nikkimaria's question, the only comparative example I can immediately find is Winston Churchill, which has Bibliography of Winston Churchill for works about Churchill, and Winston Churchill as writer for works by him. Caeciliusinhorto (talk) 20:55, 8 January 2024 (UTC)

Yep, wouldn't be looking at removing any of the sources actually cited, just some of the ones that aren't. Thanks for the example, that's helpful - anyone have thoughts on what the best titling approach would be for these different types of bibliographies? Nikkimaria (talk) 00:04, 9 January 2024 (UTC)

Post on an article's Talk page when you remove/move anything from an article's improperly-intermingled Bibliography + Works Cited + References section -- that is, so that anything removed was not from the article's history from a state prior to material being cited in-line, such that any residual material failing in-line verification may be more easily cross-referenced to the article's history. (To those to whom this paragraph seems like nonsensical word salad: you know it when you see it -- see major history articles.) SamuelRiv (talk) 00:30, 16 January 2024 (UTC)

New tags on recent changes.

Hello, Would it be possible to add the tags "previously undone edit", "possible edit war" and "likely repeated vandalism". All would be activated in slightly different ways, the first would be activated when the same user undos the reversion of their original edit; the second would be activated when 2 separate versions of a revision are rapidly changed between; the third would be an escalation for the first, a high ORES score edit being consistently reverted and re-added.

 Thanks Geardona (talk to me?) 02:37, 14 January 2024 (UTC)

Definitely maybe. The first might be possible in Special:AbuseFilter (about which you can inquire at Wikipedia:Village pump (technical)). I think that detecting the others might (a) have to be done in MediaWiki code, like the Reverted tag, and (b) not be available instantly, especially if you want it to work if there have been unrelated intervening tags. WhatamIdoing (talk) 23:47, 14 January 2024 (UTC)

Probably useful to file a phab for this, and maybe something that the ModTools team would be interested in looking into :) Sohom (talk) 15:17, 15 January 2024 (UTC)

How would I file a phab request? Geardona (talk to me?) 19:29, 16 January 2024 (UTC)

WP:BUGS. --Redrose64 🌹 (talk) 19:32, 16 January 2024 (UTC)

 Thanks Geardona (talk to me?) 19:34, 16 January 2024 (UTC)

Can Wikipedia Provide An AI Tool To Evaluate News and Information on the Internet

(refactored from Help desk)

The integration of a neutral and curated AI platform with search engines has the potential to revolutionize information access and combat misinformation. By providing context, flagging biases, and promoting critical thinking, these platforms can empower users to navigate the complex information landscape of the internet Perfedge (talk) 06:06, 15 January 2024 (UTC)

Wikipedia is an online encyclopaedia, not a search engine, so that would be out of scope for the project. And while the Wikimedia Foundation might possibly have the funding to finance such a project, if it were feasible, they don't have much of a reputation for creating complex software with any degree of rapidity. And frankly, the evidence that current AI is even capable of fulfilling the objectives you describe would appear to be lacking. 'Critical thinking' will, for now, have to be facilitated by actually doing the thinking ourselves. AndyTheGrump (talk) 06:17, 15 January 2024 (UTC)

Oddly enough, that statement sounds like something a chatbot would spit out. Or a "corporate mission statement." But I have to object to using "curated" "revolutionize" "combat" "promoting" "empower" and "landscape" in just two sentences.

Also, no. Per AndyTheGrump, we will have to continue to use brains. 🌺 Cremastra (talk) 22:40, 16 January 2024 (UTC)

Ignoring the lead comment (which no offense to user, sounds like machine-generated businessbabble, hold the synergy), I'm intrigued by the header question. I don't think ChatGPT in any nearcoming commercial iteration will be particularly useful as a dynamic tool for evaluating sources, not least because it doesn't get updated fast enough. However at its most basic, I'd like to see if it can give some intelligent analysis (at either the individual article level or of an outlet given a sample of articles) that's better than some of the crud at Media Bias/Fact Check. (Have MBFC's writeups gotten better in the last couple years? Their methodology for comparing outlets actually in theory seems not bad.)

To start I tried asking ChatGPT (3.5) in a couple prompts to evaluate bias and reliability on article from an inner-metro local paper, the Dorchester Reporter, figuring that the author is unknown and the paper would not be much evaluated in any secondary media GPT may have seen. I'm currently having trouble getting the output to say anything of substance (it almost seems to be telling me to do my own homework!) (and yes I'm including the full article plaintext in the prompt). If anyone else is interested, see if they can get anything substantial -- I have then prepared a regional cross-section of local outlet stories on the same topic, and a also spread of sample stories from a new outlet, to see what kind of reports it will give. SamuelRiv (talk) 01:54, 17 January 2024 (UTC)

Improving Wikipedia's Editing Process

I'm an expert in an emerging technology called "General Collective Intelligence" or GCI platforms, which aim to significantly increase the collective intelligence of groups, and hence to significantly increase impact on any collective outcome in general that a group might target, per dollar of resources spent. This has the potential for radically disruptive positive impact in a vast range of areas from addressing poverty, to sustainable economic development, to addressing the environmental degradation that has been associated with climate change, but I'd like to begin with improving Wikipedia's editing process. In summary, a general collective intelligence identifies different problem solving strategies and the domains in which each strategy is optimal in order to switch to the optimal strategy for each problem. Some typical issues that plague Wikipedia (like edit warring) are just symptoms of a clash between problem-solving strategies rather than the collective intelligence to cooperate in using the optimal strategy. A short summary is linked below. I look forward to your guidance.

https://en.wikipedia.org/wiki/User:CognitiveMMA/sandbox CognitiveMMA (talk) 14:39, 15 January 2024 (UTC)

Please provide citations to appropriate third-party sources supporting your claims concerning the abilities of 'General Collective Intelligence'. AndyTheGrump (talk) 14:44, 15 January 2024 (UTC)

What is a GCI platform? Is this something you invented? Barnards.tar.gz (talk) 21:29, 17 January 2024 (UTC)

To achieve Collective Intelligence one needs a lot of permutations and most Wikipedia articles tend to reach a "good enough" state, then don't deviate much beyond that due to the work involved in rewriting existing text. It's actually harder to rewrite an existing article than create a new one. In rewriting, you have to consider and incorporate what is already there, plus add new content around it. Very time consuming. Most users don't undertake that unless they are really dedicated, or the existing requires WP:TNT. Most articles reach a point then don't evolve much. (Ignoring all the maintenance and trivial edits). A better example of GCI is generative AI because it speeds up the evolution process to (literally) light speed, one can quickly see collective intelligence generating new things of value. -- GreenC 16:24, 15 January 2024 (UTC)

Uh, what? CactiStaccingCrane (talk) 17:31, 15 January 2024 (UTC)

Sounds like doi:10.1007/978-981-19-2840-6_18. It's probably not a notable subject, and I doubt that it would work. That is, it would only work if nearly all the participants were truly open to any outcome, which is basically never the case when there's a dispute. It would have us be hyper-rational when people are being emotional. It could probably turn into a decent consulting career specializing in things like creating corporate mission statements and such, though. WhatamIdoing (talk) 17:52, 15 January 2024 (UTC)

Indeed, uh what? Or to put it another way, 'citation needed'. I know it's fashionable these days to claim that AI can solve all of the world's problems before tea-time, but we actually need concrete verifiable evidence to justify using it on Wikipedia. AndyTheGrump (talk) 17:56, 15 January 2024 (UTC)

Option to omit subordinate sections on edit

Case in point: [4] The editor meant to add the content at the end of the "Discussion (II)" section, but ended up adding it at the end of its subordinate section, "Split off into a new page". He didn't catch the error and it was fixed later by a different editor (me). He is an experienced editor, significantly above average in technical competence, and I see this happen too often.

(In this case, I ended up changing the level of "Split off into a new page" to that of "Discussion (II)" to prevent this from happening again, but that solution was sub-optimal. By all logic the "Split off into a new page" should be subordinate to the Discussion section.)

Even if one is aware of this pitfall, it can be really cumbersome to have to back up to find the section you want. Imagine if there are four or five subordinates, some of them really long.

There should be the option to edit a section without its subordinates. Equally beneficial on any page that has multi-level sections, including articles, not just talk pages. As for specifics, that's why I'm on this page.

One thing to consider is that an editor might not know the option exists, or it might not occur to them to use it. In such cases the option would do little good. I'm thinking a pop-up box if the edited section has any subordinates: "Do you want to include the subordinate section(s)?" ―Mandruss ☎ 21:58, 10 December 2023 (UTC)

+1 for this sort of feature. It's been requested in various places for over a decade IIRC. I don't get caught adding content in the wrong place, so much as it's annoying to have to scroll to the correct place and an excessively long preview of subsections I am not planning to change. DMacks (talk) 22:19, 10 December 2023 (UTC)

Okay, only half a decade. I knew it sounded familiar though... Wikipedia:Village pump (technical)/Archive 163#Edit section without subsections. DMacks (talk) 07:52, 12 December 2023 (UTC)

So the last comment in that thread was PrimeHunter, one of our most credible editors on technical questions, saying this is not only technically possible but "straightforward". There was no reply, suggesting concession by the naysayers. That was at VPT, and it seems to me the next step would've been this page. Not sure why that didn't happen. ―Mandruss ☎ 22:17, 12 December 2023 (UTC)

@PrimeHunter:... DMacks (talk) 20:16, 18 December 2023 (UTC)

I said "It seems straightforward". I'm not a MediaWiki developer and don't know how easy it would be in practice but it doesn't sound hard. I don't believe Izno's earlier comment there: I'm pretty sure "this is not technically feasible" is the answer due to the way that HTML sectioning works. That seems irrelevant. When you save a section edit, MediaWiki reparses the wikitext of the whole page in the same way as if you had edited the whole page. PrimeHunter (talk) 21:55, 18 December 2023 (UTC)

-1 to the popup confirmation, but +1 to being able to edit just the "lead" of a section sans any subsections. I'm sure people will jump in with some good examples, but I'm struggling to imagine when "edit smallest applicable subsection" and "edit entire page" are both worse options than "edit intermediate size chunk". Folly Mox (talk) 02:19, 11 December 2023 (UTC)

@Folly Mox: Your last sentence seems to suggest that it should never include subordinate sections, which would be another way of solving this problem; do I have that correct? If so, there are some cases where one would want to do that, such as re-ordering the subordinate sections or moving text between subordinate sections. Such things could be accomplished in other ways, including editing the entire page, but significantly less easily and more error-prone. ―Mandruss ☎ 20:33, 11 December 2023 (UTC)

Yeah, never including subsections except in the "edit full page" case was my idea for avoiding a popup confirmation, but those things you mention are fine arguments for retaining the ability to edit a section including all its subsections. Another one is when there is no "section lead", and the prose starts after the first subsection. Misclicking on the wrong pencil would send users to an empty editing interface, which we'd have to cancel out of annoyingly. So maybe my idea is bad? I definitely am not liking an additional modal thing to tap between the editing pencil and the editing interface, but I'm not sure of the way round it. Folly Mox (talk) 21:45, 11 December 2023 (UTC)

"Editing pencil": You must be using a different editor. I click [ edit ] next to the section heading.

Remember that the pop-up would only happen when there are subordinates, so the impact might be less than you imagine. The question would be asked only when needed. ―Mandruss ☎ 21:56, 11 December 2023 (UTC)

On mobile skin, you have to go all the way to the top toolbar on a page, click the three dots, and click "edit full page" to do that. On very large pages that may well be a bigger inconvenience than the issue described here. Mach61 (talk) 19:50, 11 December 2023 (UTC)

(Actually, there's no technical reason why this feature would have to be implemented the same on m.wiki AFAIK, so carry on) Mach61 (talk) 19:52, 11 December 2023 (UTC)

There are indeed two issues here. The major one is the back-end: we need MW API support for it. The other one is the interface to activate it, for which we could have all sorts UI/UX design ideas, gadgets, etc. But none of the latter matters without the former. DMacks (talk) 02:12, 12 December 2023 (UTC)

That's above my pay grade. If this earned a consensus at VPR, what are the realistic odds it would happen? ―Mandruss ☎ 06:47, 12 December 2023 (UTC)

Any chance the gadget that allows the editing of lead sections might help? CMD (talk) 07:43, 12 December 2023 (UTC)

No, that is quite different. Each section is numbered sequentially, so the lead is section 0 already and is not a header-delimited section at all (so the other sections are not subsections of it, in the way a === is a subsection of ==). DMacks (talk) 07:52, 12 December 2023 (UTC)

All the gadget does is make a section=0 link like https://en.wikipedia.org/w/index.php?title=The_Example&action=edit&section=0&summary=/*%20top%20*/%20 to use a feature which already exists in MediaWiki. You could have made the same url manually. The proposal here would require a new MediaWiki feature. PrimeHunter (talk) 21:55, 18 December 2023 (UTC)

Brainstorming a gadget that would be a clickable link in the section to call action=edit buth then intercept the actual spawning of the editor. It would snip off everything starting with the first line that begins with "==" into a hidden separate field, then reattached it when the user clicks 'publish'. DMacks (talk) 10:11, 2 January 2024 (UTC)

Also, when used, it can prepend an edit summary accordingly -- that alone, if graduated from gadget to default anonymous feature, would be so worth it to ease reviewing a significant percentage of edits to article ledes (which are a significant %age of cruddy/controversial edits). SamuelRiv (talk) 23:02, 17 January 2024 (UTC)

Bump XfD heading sizes

I currently have a draft to bump XfD heading sizes for each page to level-2 and for each day's log to level-1 at User:Aaron Liu/sandbox#XfD heading size. Thoughts? Aaron Liu (talk) 02:15, 21 January 2024 (UTC)

Are you asking about the format or substance? InfiniteNexus (talk) 04:37, 21 January 2024 (UTC)

The format. I don’t see how this could affect the substance. Aaron Liu (talk) 14:07, 21 January 2024 (UTC)

Adding section/portion of a page to Watchlist

Is it possible to add a portion or a subsection of an article to one's watchlist instead of the entire page? Or are there any options available to do something like this? IOHANNVSVERVS (talk) 07:41, 18 January 2024 (UTC)

It is possible on talk pages through the recently introduced WP:SUBSCRIBE feature. InfiniteNexus (talk) 08:03, 18 January 2024 (UTC)

Right, I was aware of that (although I didn't know that it was only recently introduced)

Speaking of that feature, do you know if there's a way to have topics one has created on a talk page be subscribed to automatically?

Thanks, IOHANNVSVERVS (talk) 09:01, 18 January 2024 (UTC)

It's in your Preferences (Ctrl+F Automatically subscribe to topics). InfiniteNexus (talk) 01:30, 21 January 2024 (UTC)

Thank you! IOHANNVSVERVS (talk) 04:31, 24 January 2024 (UTC)

It would be helpful to have them added to one's watchlist rather than the notification system. I often want to watch one section in a major forum such as VPT or ANI without being alerted to each comment on several massive unrelated threads that are important to others but of little interest to me. Actually, what might be better is "don't alert me for updates to this section", so I get notified of new sections by default but can set each of them to ignored. That works well on other forums such as Usenet (yes, it still exists). Certes (talk) 14:14, 18 January 2024 (UTC)

Use of ChatGPT and other LLMs specifically for medical and scientific content

There has been much debate about the use of ChatGPT and other LLMs already, and from what I gather, the chief objections to using these tools for page content creation center around one or more of these subjects:

1. Inaccurate/falsified statements
2. Bias of the program and its database(s)
3. Falsified references in generated content
4. Sometimes being overly vague

I agree fundamentally with these conclusions, and I believe that they make LLMs unsuitable for many types of page on Wikipedia, such as biographies.

However, within my usual discipline, medicine, I have observed an exceptionally high degree of accuracy and completeness in ChatGPT's ability to characterize diseases. It is not flawless - but not even an expert is. Hence why even subject matter experts cite their sources. Fundamentally, what I am thinking about is generating page content with ChatGPT, and then manually verifying information before putting it on Wikipedia. This makes article expansion much easier, and there is a lot of expansion needed in WP:Medicine.

I present an example in the form of Japanese spotted fever, which is currently a stub. I know how to track down good sources to expand this page, and I have both a textbook and a high-quality review article open right now, but actually writing the page out would take a lot of time. And there are thousands of pages just like this.

Take a look at what ChatGPT wrote for me. I challenged it to "create profiles of diseases and medical conditions, including at minimum sections on: clinical presentation, diagnostics, treatment, and epidemiology" and then simply prompted it with Japanese spotted fever. To summarize: everything written there is correct. It is more detailed than the textbook I'm using to verify things, and much of it can only be found from sources like this, which are well over 20 years old. I find that impressive.

While that page needs some more formatting and editing, the base content is a vast improvement over the current stub. Would a single editor object to replacing the stub with that sandbox page, after I formatted it and verified+cited all the material? Would it not represent a major improvement to Wikipedia's medical utility, if medical editors were encouraged and guided to responsibly use ChatGPT as a tool, even for page content? Just-a-can-of-beans (talk) 20:29, 19 January 2024 (UTC)

What you are talking about is an article where every word is written or specifically verified by a human editor and determined by that editor to be sourc-able and where the human editor has sourced it sufficiently to comply with wp:ver. This is sound human editing, IMO not a reason for Wikipedia to give a particular blessing to what inspired or guided them to do that work (personal discussions with friends or experts, ChatGPT, a Ouija board :-) etc.) North8000 (talk) 20:47, 19 January 2024 (UTC)

This might work well for a subject that has only been written about by knowledgeable people, but how does it get on with, say, COVID-19 vaccine or finasteride? Phil Bridger (talk) 21:39, 19 January 2024 (UTC)

This is an interesting question. If database materials are inaccurate, then the AI could weave specific inaccuracies into the material. That reinforces the need to verify against outside sources, with existing standards for source veracity.

I'm not familiar with finasteride or what I presume are controversies surrounding it, but I asked it some COVID vaccine questions and even tried giving it some loaded questions. It definitely gets vague, but perhaps that's due to brevity. I don't see anything that looks like information sourced from questionable authors - perhaps the training data was vetted by competent and knowledgeable people or (more likely, in my opinion) the AI is able to draw its own conclusions about source veracity. It's also pretty good about answering specific questions posed in response to bits of vague language. This is more than good enough for a knowledgeable editor to use as a tool, I think. Just-a-can-of-beans (talk) 22:28, 19 January 2024 (UTC)

Agree, but that isn't the question. North8000 (talk) 22:37, 19 January 2024 (UTC)

I'm not really sure what Mr. Bridger was asking, then Just-a-can-of-beans (talk) 22:45, 19 January 2024 (UTC)

My fundamental concern with suggestions of this nature, generally, is that (for instance) ChatGPT uses Wikipedia itself as part of its training corpus which presents the possibility of circular learning. However, in the specific form presented here: "Fundamentally, what I am thinking about is generating page content with ChatGPT, and then manually verifying information before putting it on Wikipedia." I probably don't personally have any objections, for whatever that's worth. Chetsford (talk) 22:42, 19 January 2024 (UTC)

You make a great point about circular learning - if it does behave that way, this could be very dangerous in the long term. I formerly assumed ChatGPT used Wikipedia and thus didn't use it as a study aid for a long time, but having used it lately, I no longer personally believe it uses Wikipedia heavily, if at all, at least for medical subjects. A good example of this is coincidentally in the Japanese spotted fever page - compare ChatGPT's description of the rash with the one on Wikipedia at the moment. The AI is more detailed in its description, and matches several sources, but none exactly - while also omitting the mention of progression to petechiae. However, this could just be due to this particular page being very short and thus not considered much by the AI, so perhaps some testing with other pages is in order. Your concern definitely merits attention. Just-a-can-of-beans (talk) 22:58, 19 January 2024 (UTC)

A fifth concern to add to the list is the possibility of the model emitting copyright-violating material. This could be of greater concern if the information only exists in a small number of niche sources. Barnards.tar.gz (talk) 22:53, 19 January 2024 (UTC)

Considering the nature of LLMs, I'd say the burden is to show they have ever produced prose that would appear as plagiarism (by clone or close paraphrase) of a single source -- putting the as-yet unsettled nuances of copyright in scraping content for LLMs aside for now (and for the many years it will take to decide such law). Certainly they can reveal trade secrets or anything else people blab in their prompts, but that's not illegal. SamuelRiv (talk) 23:19, 19 January 2024 (UTC)

Several examples in this article Barnards.tar.gz (talk) 23:50, 19 January 2024 (UTC)

The song lyrics prompt examples are clearly problematic. The NYT prose example is basically directly asking for a copyvio of a specific article, which is kinda ridiculous.

Looking at G-Scholar I do see stuff on memorization (artificial intelligence) (WIP), which I didn't realize is an emergent LLM behavior. The studies they are doing are mostly still on GPT-2 to build on old literature it seems, so take some %ages with salt. Note de Wynter et al 2023 discusses GPT-3 and 4, and that while conditioning/biasing prompts on existing prose and authors/titles greatly increases likelihood of outputting memorized training data, simple prompt mitigations dramatically lower it.[pp. 9--10] Note also that memorization scales (log-linear to quadratic) with frequency in the training data, so pop songs are astronomically more likely to be quoted than a niche academic paper.

We could say plagiarism detection software as many of these papers use, perhaps a cloud-based solution with easy credits for editors, may be additionally appropriate if we think remaining risk is still inappropriately high (relative to general risk from close paraphrasing). Any automated tool would certainly speed up the necessary review process anyway.

Note fyi Hartmann et al 2023 go over what is and isn't decided in copyright law, potentially, regarding LLM issues. It may or may not be the case that spontaneous memorizations are a copyvio per se. SamuelRiv (talk) 21:30, 20 January 2024 (UTC) SamuelRiv (talk) 21:30, 20 January 2024 (UTC)

I can forsee issues with this. If people don't mind an anecdote, at work someone tried to help when we couldn't find information on a MEDRES something and asked an AI for a list of scientific papers that covered the topic. Of the three papers returned, one was a real paper which didn't cover the topic and the other two were total hallucinations. The first of the two hallucinations was particularly difficult to spot because it took the name of a real paper, and the author list of another real paper and merged them. Red Fiona (talk) 15:17, 20 January 2024 (UTC)

Yeah. I don't think it's up to snuff just yet for identifying sources. I'm involved in a systematic review using AI to help sift through things and even that proprietary, paid service requires a lot of human oversight and manual correction.

Basically what I support is letting the AI write up a paragraph or a page on a subject, then verifying the info manually. ie, you may prompt the AI to "write a paragraph explaining medical treatment options for condition X" and then when it spits out that short-course corticosteroids are the preferred first-line treatment, you do a quick check of good sources to make sure that's correct. It saves a lot of time because while you would have had to look up those sources anyway, you would have also had to spend a lot of time writing up the paragraph yourself, phrasing and editing it, etc. Just-a-can-of-beans (talk) 15:12, 22 January 2024 (UTC)

This might be me, but I am not seeing much time/effort saving between "I choose a topic, read a bunch of papers, synthesise and write" Vs "I choose a topic, machine writes it, I read the papers, check what's written reflects the papers, possibly have to rewrite much of what the machine wrote". Red Fiona (talk) 18:20, 23 January 2024 (UTC)

I think the main practical issue is that it's easier to fact-check text while you are writing it yourself, than to go through every sentence of text someone else wrote. Jo-Jo Eumerus (talk) 10:40, 24 January 2024 (UTC)

Here's the sort version of my previous post. For the example described in the OP, the article was full written and sourced by a human. So the example is not a reason for Wikipedia to be blessing ChatGPT.

For example, if I get my inspiration for an article from a Ouija board, and then I write a great article derived from and sourced to wp:reliable sources, that is not a reason for Wikipedia to specifically endorse use of Ouija boards. North8000 (talk) 23:25, 19 January 2024 (UTC)

OP's sandbox article was not "full written" by a human -- not a word of the prose was written or altered by a human -- that's OP's point! Would a single editor object to replacing the stub with that sandbox page, after I formatted it and verified+cited all the material? No change in prose -- just verification and citations. We are long past talking about getting "inspiration" from AI as if it's 1988. SamuelRiv (talk) 23:32, 19 January 2024 (UTC)

I'm with you in spirit, but I think that you are interpreting me in reverse. For the example, a human editor either OK'd or wrote every word and sourced it. My point is that we should not let this probably-OK example be a Trojan horse to get Wikipedia to partially bless use of ChatGPT. Sincerely, North8000 (talk) 15:33, 22 January 2024 (UTC)

References

The Instinct to Punish (essay)

Also WP:Crime labels. Both new. -- GreenC 06:33, 15 January 2024 (UTC)

This is an excellent essay and reflects a concern I've been incubating for some time. Wikipedia — because of its page rank prominence and the use of article leads to populate the snippets of Google Knowledge Graph — is now in the position of being a prime destination for the application of punitive measures against perceived transgressors and realization of this instinct is having a deleterious impact on our maintenance of encyclopedic standards in some cases.

I would like to see some practical measures adopted to deflate the ability of this project to be used in such a way. For instance, courtesy de-indexing (if requested by subjects) of BLPs (perhaps with some exceptions) would make the stakes considerably lower and disincline, to a certain degree, some editors from using BLPs as a punitive tool while still maintaining our WP:NOTCENSORED ethos. Chetsford (talk) 18:46, 17 January 2024 (UTC)

I think there's a good point behind Wikipedia:Crime labels, but I don't think it's presented well (e.g., no clear definition of "label", no way to know whether the suggested criteria are met). Unfortunately, my efforts to clarify it, or even get my questions answered, do not appear to be welcome at the moment. WhatamIdoing (talk) 18:27, 26 January 2024 (UTC)

Deletion of account is needed

There should be an account deletion system. Edits made by deleted account should be left with name of the account without a link. 160.238.0.118 (talk) 19:34, 26 December 2023 (UTC)

For legal reasons related to attribution of material, it is not possible to delete accounts. They can however be renamed in some circumstances: see Wikipedia:Courtesy vanishing. AndyTheGrump (talk) 19:45, 26 December 2023 (UTC)

Given I can just search for all other edits made by that "name of the account", there is no difference whether or not they have a "link". Sounds like a distinction without a difference. What is it your understanding of what an 'account' actually is? DMacks (talk) 10:03, 2 January 2024 (UTC)

In the site's terms of service, you agree that the link is sufficient attribution. Remove the link, and the attribution is no longer within what you agreed to, and technically, you can sue the WMF. Snowmanonahoe (talk · contribs · typos) 14:27, 14 January 2024 (UTC)

I don't think that's true. First, the attribution wording is about linking to the article, not to your userpage ("Through hyperlink (where possible) or URL to the article to which you contributed (since each article has a history page that lists all contributors, authors and editors);"). Second, we could remove the link to your userpage and still keep the links to your talk page and contributions. We could even remove them all, and people would still be able to look up everything through pages like Special:Search and Special:Contributions and Special:Log.

The question is: What specific benefit does the OP think they would get from removing the link to the userpage? It's possible that what they're looking for is {{db-user}} (e.g., if by "delete account" they mean "don't link to the embarrassing thing I posted on my userpage"). WhatamIdoing (talk) 16:55, 28 January 2024 (UTC)

Understandablifying advanced math articles -- GPT and the Holy Grail

Forever ago (2007) I created a few theoretical comp sci and neurosci articles -- stressing the content is mostly math. One of which I (mis?)remember, but cannot seem to find now, attracted some comment on the Talk page like it was completely incomprehensible and the worst article they had ever read on WP. (I had thought it was Flashsort, which I wrote on WP:REQuest and attracted some mockery, but I might be confusing stuff.) I had a good laugh at this stuff -- if you check the Talk pages on WP math articles, such comments aren't exactly unusual -- I always wondered in my time educating and writing if there wasn't some way to just break through this seeming dense incomprehensibility barrier that's almost universal in rigorous technical text.

Fastforward to today and people figuring out use cases for ChatGPT (3.5). I type in the following: Rewrite the wikipedia article on Flashsort into simplified English

ChatGPT 3.5: Flashsort into simplified English

Flashsort is a way to arrange numbers or data in order, from the smallest to the biggest. It's a special method that does this really quickly. When we want to sort things, like a list of numbers, there are different methods to do it. Some are faster than others. Flashsort is one of the faster ones. Here's how it works: Dividing the Range: First, we look at the numbers we want to sort and find the smallest and biggest numbers. This helps us figure out how big our sorting range is. Creating Buckets: Imagine we have a bunch of boxes, and each box can hold a certain range of numbers. We create these boxes, also called "buckets," to fit the range of numbers in the list. Distributing Numbers: Now, we go through our list of numbers and quickly put them into the right buckets. We do this by calculating where each number should go based on its value. Sorting Inside Buckets: After we've put all the numbers in their respective buckets, we sort the numbers inside each bucket. We can use any sorting method we like, but inside each bucket, the numbers are already close to each other, so we don't have to do a lot of work. Joining Buckets: Finally, we take the sorted numbers from each bucket and put them together. When we do this, the numbers are all sorted from smallest to biggest. Advantages of Flashsort: It's fast, especially when dealing with a large number of items. It's efficient because it doesn't waste time comparing every number to every other number. It works well when the numbers are distributed unevenly, meaning some numbers are way bigger or smaller than others. Limitations of Flashsort: It might not be the best choice for sorting very small lists. It needs some extra memory space to create the buckets. In simple terms, Flashsort is a clever way to quickly sort numbers by dividing them into buckets, sorting those buckets, and then putting everything together. It's like sorting toys into different boxes based on their size and then arranging the toys inside each box neatly. This helps us find what we need faster.

The output is mostly accurate. More to the point, while it doesn't sound completely precise in a mathy sorta way, when I went over it a few times I couldn't think of anything wrong with it, or even necessarily disqualifyingly imprecise about the text. It reminded me of a really really well-written teen/lay science book, except such a really esoteric topic that nobody would ever put it in a teen or pop book.

All I can think is that this is a game changer, especially with GPT-4. The lede of almost every major, but densely written, technical article can be run through this and then curated, since the lede does not have to be 100% precise on any topic -- history, agriculture, sports, whatever -- that's for the body. Even more significantly, this could be an engine to draft minor articles for review for Simple English WP, which is still anemic by comparison.

Again, to emphasize, (as if anyone anywhere serious disagrees or hasn't considered this:) all generated material is a draft that must be reviewed in its entirety for content; and (lesser consensus on this:) any lengthy prose retained verbatim for WP or other publication should include attribution to content generation tools used. SamuelRiv (talk) 01:59, 16 January 2024 (UTC)

I think the "mostly" in "mostly accurate" is a problem. ChatGPT and these things have a known reputation for saying untrue things. In practice, I think this suggestion will fail because it's a lot of effort to check each claim, and people will often forget to do so. Jo-Jo Eumerus (talk) 08:48, 16 January 2024 (UTC)

And let's not forget that the sheer existence of English Wikipedia and Simple English wikipedia, is one of the reasons this model even knows how to do this. —TheDJ (talk • contribs) 09:34, 16 January 2024 (UTC)

You really don't see "anything wrong" with "It works well when the numbers are distributed unevenly"? I'm also going to take issue with why it says "Sorting Inside Buckets" is fast, the very existence of the "Joining Buckets" step, and (relatedly) that it doesn't say anything besides "quickly" about how this differs from a histogram sort, the explanation of which forms the bulk of the article. —Cryptic 10:09, 16 January 2024 (UTC)

I know the idea lab is for positive feedback, but this example is not great. There are basic errors: not only does flashsort not work well when the numbers are distributed unevenly (because some buckets remain big), but "uneven" doesn't mean some numbers are way bigger or smaller than others (1, 2, 10 is uneven; 1, 1001, 2001 isn't). Worse, it sounds credible: having sucked the reader in with a few truisms, it hallucinates plausibly. Even some true facts are misleading: it doesn't waste time comparing every number to every other number, but even bubble sort isn't that dim. Less importantly, the tone is unencyclopedic, but that covers up the fact that even the correct statements are vague and imprecise (fast rather than O(n), etc.). One day we may be able to curate good AI-written articles, but we seem to be a long way from that yet. Certes (talk) 14:16, 16 January 2024 (UTC)

Some things to clarify:

First, I did all this several months ago and only have notes of the prompt and output. I should have reread instead of going just from memory. Yes, the "Advantages" and "Limitations" are awful, so I shouldn't have flatly said there wasn't "anything wrong".

Second, we can show it with a better article example (one I actually cared to remember anything about), and also on GPT-4, but what I'm impressed by is the ability to put technical text into a readable format while still accurately describing steps of the algorithm. I'd still say on a quick re-read there's nothing disqualifyingly wrong in what is affirmatively stated (except in the two sections noted), except there is significant omission (it's a very short output for a long technical article) -- my point is that it can help write good ledes where you will always have imprecision and omission. I'm not sure where specifically you see hallucinations per se -- it doesn't go off into outer space in the sections noted.

Third, you can fine-tune tone with prompts, and you can fine-tune how much mathematical language you want to have in there too (or just add it yourself in the curation process. For the prompt I used, copied literally, I'd say it output something expected.

Fourth, who said anything about "AI-written articles"? I'm talking about a tool to aid in writing -- the kinds of things the whole rest of the ChatGPT-using population is using it for. SamuelRiv (talk) SamuelRiv (talk) 18:06, 16 January 2024 (UTC)

I agree that a simple prompt like the one you have provided can easily be improved to get better results. Pinging @JPxG who has a lot of experience in this area. — Qwerfjkltalk 19:37, 16 January 2024 (UTC)

This output seems more suitable for the Simple English Wikipedia, than here. I disagree that since the lede does not have to be 100% precise on any topic - leads are subject to WP:V, WP:NPOV as much as any other article content. Sure, we can elide details in the lead but it still has to be verifiable and accurate. Galobtter (talk) 21:41, 19 January 2024 (UTC)

I wonder whether this is an Accuracy and precision problem. The lead has to be accurate; it does not necessarily need to be precise. "Amoxicillin is an antibiotic" is accurate. "Amoxicillin is a aminopenicillin subtype of the β-lactam antibiotics" is precise. Both of these statements are verifiable. WhatamIdoing (talk) 17:04, 28 January 2024 (UTC)

My biggest problem, aside from the inaccuracies stated above, is how redundant most of the wording is. The second and the last paragraphs add nothing whatsoever. There's lots to say about flashsort's advantages other than being "fast". --Ahecht (TALK
PAGE) 16:01, 24 January 2024 (UTC)

Looking for a common way to indicate no last name for sorting

There are at least two situations where a person's name shouldn't be changed to "Last Name First" for the purposes of sorting. Defaultsorts for Categories and listas for Biographies. I'd like a common way to indicate that a person's name should be taken as a unit and not flipped with a supposed last name. (For example, a way to indicate that the drag queen Adore Delano should be *always* sorted under A, and never treated as if Delano was a last name. This can also occur in some cases in countries where names do not include patronymics. I know there are the various templates in Category:Hatnote_templates_for_names, but I guess I'm looking for something more general.Naraht (talk) 19:05, 23 January 2024 (UTC)

Thank you for starting this discussion. I get tired of changing the DEFAULTSORT and LISTAS fields re: categories and WikiProject Biography talk page banner for drag performers, after editors (presumably not knowing the page title is a stage name) sort by a fake "last name".

I would welcome a way to flag this sorting issue to editors. Look at Willow Pill, for example. This should not be sorted as "Pill, Willow". Fixing this all the time is tiring. ---Another Believer _(Talk) 19:10, 23 January 2024 (UTC)

I proposed last year explicitly noting bibliographic surname in the {{infobox person}} parent box, but was told to use DEFAULTSORT instead. The reason I think the infobox is a useful place to flag it is it offers a few other indicators -- place/time of birth, parents, etc -- that can be used to help indicate (by algorithm or not) that some extra consideration should be given. Also, listing bibliographic sort explicitly and visibly by editors following naming guidelines is a lot different from something like DEFAULTSORT where doing so is seen as part of a backend cleanup with minimal concern for front-end content. SamuelRiv (talk) 19:38, 23 January 2024 (UTC)

Greetings, adding my two-cents here. How about adding a comment like <!--- Sort by article TITLE --->? In both Def. sort and Talk-WP Bio locations. Only issue I see is with Rater assessment tool-wants to flip title, so that would need to be addressed. Regards, JoeNMLC (talk) 17:10, 28 January 2024 (UTC)

Quick template script

I have been working on a script that allows for the quick addition of important templates (such as citation needed), and I was wondering if I could get some feedback. It is very simple at the moment, being that JavaScript is not my strong suit. At the moment the way click inputs are handled is very inefficient, and templates can only added to the top of an article. I intend (if technically practical) to add options for different variations of templates, to handle click inputs better, and to future-proof it; which would allow for easy addition of new templates to the script. The page is found here. I thank you for your feedback, and I hope this is the correct way to present this (I am fairly new and haven't fully figured out Village Pump) Vghfr (talk) 04:01, 18 January 2024 (UTC)

@Vghfr, did you get the feedback you need? If not, I suggest posting at Wikipedia:Village pump (technical).

It looks to me like this is similar to a script that is popular at the French Wikipedia (for the now-defunct 2006 wikitext editor) and for patrollers at one of the CEE Wikipedias in the 2010 wikitext editor (@Martin Urbanec, is it the Czech Wikipedia that has custom buttons in the editor, rather than using Twinkle?). WhatamIdoing (talk) 17:07, 28 January 2024 (UTC)

I didn't get any feedback but its fine, I'm working on making more practical anyways and I'd rather present a more complete version at this point vghfr 18:26, 28 January 2024 (UTC)

Editing goals

A lot of people like to just edit articles, but it might be fun for users to set a goal of how many edits they want to make (maybe on their user homepages?) The lesbian froggie (she/her) (talk) 16:28, 27 January 2024 (UTC)

I won't take part, but some editors may want to publicise goals. However, I think these goals should be set in terms of output (sourcing, GAs etc) rather than numbers of edits. Some people do in one edit what others do in ten, so number of edits is pretty meaningless. Phil Bridger (talk) 18:50, 27 January 2024 (UTC)

Some people do in one edit what others do in ten And some do almost 20,000. 😀 Anomie⚔ 19:10, 27 January 2024 (UTC)

Depends on the purpose of said goal. If the user is using it as a personal motivational tool and not really comparing themselves to other users it could still come in handy. ― novov (t c) 10:59, 28 January 2024 (UTC)

Gamifying Wikipedia can be a good source of motivation (I say this as someone with ADHD) but we should be wary of promoting WP:EDITCOUNTIS and instead promote clear outputs whether it is clearing a backlog, adding more sources, upgrading stub-level articles etc ~ 🦝 Shushugah (he/him • talk) 11:05, 28 January 2024 (UTC)

Fair point. ― novov (t c) 11:22, 28 January 2024 (UTC)

I set up https://outreachdashboard.wmflabs.org/courses/Wikipedia/WikiProject_Medicine_reference_campaign_2023/students/overview last year. It auto-counts the overall net number of words and refs added/removed from articles in the designated category. I don't know if anyone deliberately used it as motivation, but it was kind of fun. WhatamIdoing (talk) 17:24, 28 January 2024 (UTC)

Edit: There could also be an option for you to make your goal private? It just occurred to me. The lesbian froggie (she/her) (talk) 19:42, 28 January 2024 (UTC)

I get that, for some people, the mere fact of writing down a goal even if it is private can be motivational, but I don't see why we need to be involved in that process. Can't they just write the goal on a scrap of paper? — Preceding unsigned comment added by Phil Bridger (talk • contribs) 20:32, 28 January 2024 (UTC)

Change the new article requirement to extended-confirmed

WP:ACTRIAL happened in 2011, when extended confirmed user right did not yet exist (that came about in 2016). The autoconfirmed right is 10 edits and four days on Wikipedia and for almost all editors that is not enough experience to successfully create an article. Over at the Help Desk / Teahouse, the suggestion to new users is quite often that they should get more experience with Wikipedia before trying to take on the task of creating a new article.

Idea: Change the autoconfirmed requirement to extended-confirmed (500 edits, 30 days), so that users will have more experience with Wikipedia before they can create a new article directly.

Thoughts? RudolfRed (talk) 00:31, 25 January 2024 (UTC)

• I see where this is coming from, but I feel like that's too much for good faith editors that might benefit from initial failure, and the non-good faith editors will just game the system to reach that level(which is done already). The purpose of autoconfirmed is not to weed out inexperienced editors, but simply to confirm a person is operating the account and grant them additional access(that described at WP:AUTOCONFIRM). It would seem odd to let autoconfirmed do the stuff listed there except create articles. 331dot (talk) 00:40, 25 January 2024 (UTC)

Considering that many new users come in wanting to make new articles right off the bat, extended confirmed might come off as bitey. A new user right of 30 edits and 7 days might be good. QuietCicada chirp 01:02, 25 January 2024 (UTC)

I think that would be an improvement. Doug Weller talk 12:01, 25 January 2024 (UTC)

500 edits can seem a daunting amount of work, especially for those very welcome editors who preview and think before pressing Publish and thereby do more work with a lower edit count than others. It might also encourage article hijacking, which is harder to patrol than correctly created new articles. Would this restriction apply to the creation of all mainspace pages? I think I could have managed a useful redirect, and perhaps even a simple dab, before clocking up 500 edits. Certes (talk) 11:56, 25 January 2024 (UTC)

Even unregistered editors are creating good pages where ACTRIAL fails to obstruct their efforts because the page title fortuitously exists. An example from this morning: new dab 05. Certes (talk) 12:08, 25 January 2024 (UTC)

• 10 to 500 edits is a massive jump and I think far too high a bar. EC seems trivial to those of us who edit frequently, but if you're someone who just focuses on content contributions in a limited area (writing new articles, for example!), it could take years to get there. More fundamentally, I don't think the idea behind ACTRIAL/ACPERM was that you need a certain level of experience to write articles. It was that before, it was trivially easy for bad faith editors to create a throwaway account for spam, vandalism, etc. The idea that writing articles is a difficult or beyond the capabilities of new editors has become a bit of a meme lately, but I've never seen any actual evidence for it, and it seems belied by the number of perfectly fine articles created by new editors. – Joe (talk) 14:31, 25 January 2024 (UTC)
  • Done much new editor training, Joe? In my experience new editors fall roughly into two groups: those who find it all too easy to start new articles, and those who find it technically & psychologically rather difficult - if they continue editing these are often the stronger ones. I don't know what evidence there could be for new editors not starting new articles. Johnbod (talk) 15:07, 25 January 2024 (UTC)

    No, but I've reviewed several thousand new articles. The theory, as I understand it, is not that new editors don't create articles, but that they do and do so badly – hence the need to be discouraged and/or restricted from trying. The evidence I'm looking for and not finding is lots of bad articles by new editors (just like, before ACTRIAL, it was very easy to find examples of bad articles by non-autoconfirmed accounts). – Joe (talk) 21:17, 25 January 2024 (UTC)

• Support an increase to 100 edits and 7 days. If the new article is "urgent" someone else will probably start it, or they can ask another editor to do it for them. Johnbod (talk) 15:07, 25 January 2024 (UTC)
• I think that is way to excessive. If we could ever get the new article patrol log down (it is currently at 8259 articles and 18460 redirects over 1254 days) then maybe I'd be supportive of changing it so that unpatrolled new articles are soft-published (only visible to logged in editors). — xaosflux ^Talk 15:20, 25 January 2024 (UTC)

  One way to get the backlog down would be to autopatrol experienced editors – say 10 years, 100k edits, no blocks – even if they aren't article writers, so that their dabs and redirects don't clog the queue. Certes (talk) 20:52, 25 January 2024 (UTC)

The NPP backlog and problem is due to difficult-to-NPP articles, not the sheer quantity. A difficult-to-NPP article takes 50-100 times longer than a clear-pass article. An experienced NPP-er could do 50-100 clear pass articles in the time it takes to do one difficult one. North8000 (talk) 21:38, 25 January 2024 (UTC)

As it turns out, there are only 841 editors with more than 100,000 edits, and all but 271 already have autopatrolled. So it'd certainly be feasible to go through the remainder and check their eligibility. Not sure how much of a difference it would make to the queue, though. – Joe (talk) 21:41, 25 January 2024 (UTC)

I don't really understand the edit count calculus if you don't run cleanup bots. 100k edits in 10 years means ~30 edits a day. It usually takes me 10--30 minutes to do each articlespace edit. I don't get where this time is supposed to come from. SamuelRiv (talk) 02:00, 26 January 2024 (UTC)

Nobody ought to be allowed to edit Wikipedia at all til they have made at least 1000 edits on Wikipedia. That'd show them. Hyperbolick (talk) 02:40, 26 January 2024 (UTC)

Indeed. I've long thought that all pages, in all namespaces, should be extended-confirmed protected. 🌺 Cremastra (talk) 00:37, 29 January 2024 (UTC)

As of this moment all pages are on double-secret-extended-confirmed protection! SamuelRiv (talk) 07:58, 29 January 2024 (UTC)

Things like antivandalism easily bring the edit count up, especially with tools like Huggle or AntiVandal, with each revert+warning being two edits in one click. ChaotıċEnby(talk · contribs) 16:38, 27 January 2024 (UTC)

• Redirects have their own autopatrol with a lower bar at Wikipedia:New pages patrol/Redirect autopatrol list. CMD (talk) 03:40, 26 January 2024 (UTC)

• What issue is this seeking to fix? NPP has been working pretty efficiently recently, so I'm not sure bumping more stuff to AfC (which by nature gets more inundated) is a good idea. Also, I created several articles directly in mainspace pre-ECP, so it would be hypocritical of me to support a raise all the way up to ECP. Curbon7 (talk) 22:04, 25 January 2024 (UTC)
• Strong Support It's easier to create an article on WP than it is to delete one and new articles are one of the areas most ripe for abuse. We already recognize that fact by requiring new articles be reviewed by NPP, except in cases of Autopatrolled editors who have to meet standards in excess of Extended Confirmed (not just meeting the mathematical criteria of EC, but also undergoing a manual review of their edit history). To not, therefore, require new article creators to be, at a minimum, Extended Confirmed is policy incoherence. Chetsford (talk) 01:21, 26 January 2024 (UTC)

  I guess whether that's "incoherent" depends on whether you believe that Wikipedia is best served – as the Wikipedia:Editing policy claims – when we have the most accepted knowledge, or if it's best served by making it as difficult as possible for new people to contribute separate articles on what they believe to be worthy subjects.

  BTW, the suggested level means that only the top 0.25% of registered accounts will be able to start an article directly in the mainspace. Have you considered what it means for 3,999 out of 4,000 registered accounts to be unable to do this? WhatamIdoing (talk) 18:41, 26 January 2024 (UTC)

@WhatamIdoing: Thank you for pointing this out. I just checked Special:Statistics and now see that there are only 68K extended confirmed editors, which is about half of the active editor count and a very small fraction of all editors. I had thought that EC user count would be much higher, so these stats suprised me. RudolfRed (talk) 23:12, 26 January 2024 (UTC)

That particular statistic is a little complicated due to the EC status having been created after Wikipedia had been around a long time, and then the software only marking them as EC if they made an edit after its creation. On the off chance that someone is interested, then out of the 46.8 million people who have ever registered an account, of which only 14 million have ever successfully posted an edit to any page, we have:

• 117,000 accounts that would qualify for EC (most of which are inactive now);
• 68,000 accounts that would qualify for EC and made an edit after EC was officially created (some of which are inactive now); and
• 24,000 accounts that have EC and actually made one or more edits during the last month (assuming quarry:79972 is correct).

While anyone in the 117K group "could" create an article under this proposal, in practice, it's only the 24K group that likely "would" do so. WhatamIdoing (talk) 03:39, 27 January 2024 (UTC)

• Oppose per Joe Roe this suggestions seems to pulled out of nowhere and has the potential to negative impact the project. There needs to be some actual justification about a) there being a problem b) how this would improve it and c) what the potential negative impacts would be. Seddon ^talk 20:59, 26 January 2024 (UTC)
• Oppose - too high a bar per Joe Roe, and per 331dot it won't have the desired effect. As an anecdote: I also edit the social GPS navigation app Waze, where you have to make a certain number of edits to get to the next level and unlock more functionality and road access. But my small province doesn't build a lot of roads, and Waze keeps locking new features to the highest edit level which you can only get to by applying. Even though I'm an "area manager" for my province I've been stuck at their level 2 (there are 5 levels) for nearly 10 years now, as the threshold for level 3 has gone from 5k edits when I started, to 10k edits a few years later, then to 15k, and just as I got close to that number they pushed it to 25k. Basically it means that except for like drawing a new parking lot, I have to ask someone else to do nearly everything, and every time I get close to being able to do some of those things myself, they raise the bar. It's incredibly frustrating, and I frequently wonder why I bother at all. I do not want any new Wikipedia editor to have that experience: new editors gain experience by editing, not by jumping through pointless hoops. As another anecdote: my account was 5 years old before I ever created a new article, and I was still under 500 edits at that time. If some automated message told me I wasn't trusted enough to write my own article after five years, I would have just bailed and never come back. And it still won't keep away dedicated spammers, we all know it won't. Ivanvector (^Talk/_Edits) 21:27, 26 January 2024 (UTC)

Thank you, everyone, for the replies. I understand the objections and why this is not a good idea. Appreciate everyone sharing their perspectives. RudolfRed (talk) 21:46, 26 January 2024 (UTC)

You raise attention to longstanding logistical problems in AfC that have not been resolved, and you suggested a possible mitigation. Just because the idea seems to be a non-starter doesn't mean the identified issues go away, so better you said something rather than nothing. SamuelRiv (talk) 22:52, 26 January 2024 (UTC)

Agreed; always good to raise ideas to handle the AfC or NPP problems, even if they turn out to be non-starters. BilledMammal (talk) 04:30, 27 January 2024 (UTC)

Definitely, Wikipedia always benefits from editors identifying problems and suggesting solutions, otherwise we never fix anything. That's exactly what this page is for. Ivanvector (^Talk/_Edits) 12:19, 27 January 2024 (UTC)

Mickey Mouse (film series) and adding shorts

What do people think about adding the public domain Mickey Mouse shorts directly to the Mickey Mouse (film series) page? I think it would make them feel more accessible since you don't have to go to the direct page for each short. And it makes the public domain status feel more concrete to use them in a wider context. Generally this is an idea I have for all short film series, but I wanted to start smaller. SDudley (talk) 01:11, 21 January 2024 (UTC)

I would agree with you, but adding a video short needs to be credited as well as using more common sense on consensus. Gold Like Shore8 (talk) 00:43, 3 February 2024 (UTC)

Credited how? SDudley (talk) 18:10, 6 February 2024 (UTC)

RFC Surveys

Around 18 months ago I started being more active in RFC discussions. It's a great way to learn more about Wikipedia policies and to help build consensus. However, I have noticed in some of the contentious topics the surveys get bogged down in walls of text, badgering, and bludgeoning. Yes, problem users can be taken to Arb or ANI, but that's a lot of work and in some cases more trouble than it's worth.

The best RFCs I have jumped into keep discussion and comments separate from the survey. The survey should be reserved for the editors who have volunteered their time to comment. They could be wrong, they could be right, but it shouldn't be an invitation to debate. If there's a question about a comment just ping the user in the discussion section.

what is the best way to keep surveys clean? Use templates? A policy on how RFC should be conducted? I believe a great deal of time would be saved and editors would be more willing to comment if the RFC process was cleaner. Let me know what you think. Thanks! - Nemov (talk) 18:24, 30 January 2024 (UTC)

I’m not sure what you mean. RfCs are meant to have differing formats to fit different needs and scales. Templates for !votes were already banned. Aaron Liu (talk) 18:50, 30 January 2024 (UTC)

You've never seen a RFC with wall to wall text, bludgeoning, and badgering where it's unclear where to even leave your comment? Nemov (talk) 18:56, 30 January 2024 (UTC)

The first three, yes, but as someone who was heavily involved in Wikipedia:V22RFC2, I have not seen any RfC where it’s unclear to leave your comment.
I also still don’t understand what proposals you intend to workshop. Aaron Liu (talk) 19:20, 30 January 2024 (UTC)

This is the idea lab. I have brought what I believe is an issue in high traffic/contentious RFCs and I'm looking for ideas on how to make it better. If you don't think there's an issue that's perfectly fine, but that hasn't been my experience on occasion. Nemov (talk) 19:29, 30 January 2024 (UTC)

Well, my opinion is against using templates or a format that all RfCs should follow, and as I don’t get the problem I can’t suggest anything either :p Aaron Liu (talk) 19:32, 30 January 2024 (UTC)

Why has this not been raised at Wikipedia talk:Requests for comment? --Redrose64 🌹 (talk) 23:52, 30 January 2024 (UTC)

Shouldn't I have something more concrete before it's brought up there? Nemov (talk) 00:08, 31 January 2024 (UTC)

@Nemov, no, there's no need to wait. We're usually pretty friendly over there. Come talk to us whenever you want, about anything RFC-related, or even just to tell us about an interesting idea or discussion happening elsewhere. For example, a little while ago, I suggested that if an RFC has separate sub-sections, maybe the discussion should go before the vote. WhatamIdoing (talk) 01:34, 9 February 2024 (UTC)

Biography Chronology/Timeline Addition

In perusing biographical entries on Wikipedia, I've often felt the absence of a succinct chronological summary detailing the significant milestones in a subject's life. While one can generally piece together this timeline from the narrative, the absence of specific dates can occasionally be a hurdle. A brief, date-specific chronology, inserted at the outset or conclusion of all biographies, would immensely aid in grasping the flow and context of a person's life experiences. It would also reduce errors when writing about a person's life. This addition, presumably a minor task for someone well-acquainted with the subject's life, could exponentially streamline research efforts for many others. Jamesgmccarthy (talk) 18:01, 5 February 2024 (UTC)

Jamesgmccarthy, I think it is a great idea. Something like the "Key dates" portion of Channel Tunnel? Wikipedia:Manual of Style/Biography doesn't seem to mention a chronological summary, yet.--Commander Keane (talk) 01:18, 7 February 2024 (UTC)

Thank you for your reply. Yes, the Channel Tunnel sidebar of "Key Dates" would work well. On some events it would be good to state the start and stop date as some key dates have long gaps between them. For example, when studying the life of Charles Darwin, it would be helpful to know when he began and ended his studies at the University of Cambridge, not just when he entered the university. Jamesgmccarthy (talk) 09:23, 7 February 2024 (UTC)

The "Timeline" section of Charles Darwin's Resonator page does has some key moments of his life in a horizontal timeline; though because he had so many children and awards, the timeline is a bit crowded. You may have to scroll down far or collapse sections to see the timeline at towards the bottom of the page.

Reasonator pulls data from Darwin's item page on Wikidata, a free collaborative database that supports Wikipedia. Though people in past requests for comment about incorporating Wikidata information in English Wikipedia articles haven't been enthusiastic.

Lovelano (talk) 11:24, 9 February 2024 (UTC)

I would imagine this would spawn a whole host of arguments of what ought and ought not to be included in various articles' timelines (Is event X really a key date for this person? Why isn't event Y in there?...), plus arguing over if certain articles should even contain a timeline at all. Effectively, the infobox wars but on a brand-new front. 2603:8001:4542:28FB:2F1F:EA76:7140:85DA (talk) 09:14, 8 February 2024 (UTC) (Send talk messages here instead)

I don't think this will prove to be an insurmountable problem. WhatamIdoing (talk) 01:36, 9 February 2024 (UTC)

+1 - This is a good idea and I agree should be done more widely in articles. There are some articles that have "timeline" spin offs (usually the titles start with "Timeline of...") for major events (e.g. Timeline of the French Revolution) but I agree it would be helpful for all history topics -- history of people (biographies), history of buildings, history of cities, events, etc. etc. Levivich (talk) 18:23, 8 February 2024 (UTC)

Timelines would definitely make that kind of research easier, but I worry they would become a magnet for fancruft in some articles. I would not add anything resembling a trivia section to a BLP for example. HansVonStuttgart (talk) 08:46, 9 February 2024 (UTC)

This could be good. I’m not super keen on having a second vertical sidebar where there is already an infobox, so I wonder if it could be integrated into the infobox. This is concordant with the purpose of the infobox anyway:- to summarise key points. We already have birth and death dates there. Perhaps we could insert key dates between these. As a reader, I would be much more interested in seeing, at a glance, when the notable person did their notable things, not just when they were born or died. Barnards.tar.gz (talk) 09:18, 9 February 2024 (UTC)

I'd suggest remaining flexible. For some articles, in the infobox would work. For others, a separate verticle sidebar (e.g., if the top of the article isn't the best placement for the timeline). For others, it might be a separate section in the prose, and not a sidebar at all. I could see it all depending on the length of the article, the length of the timeline, and other factors (content of the article, BLP considerations, whether items on the timeline are particularly controversial or not, etc. etc.). For example, the timeline for a YouTube star might be very different from the timeline for a president. Levivich (talk) 16:56, 9 February 2024 (UTC)