Wikipedia:Village pump (idea lab)/Archive 54

From Wikipedia, the free encyclopedia

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? HouseBlastertalk 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. HouseBlastertalk 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. HouseBlastertalk 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. HouseBlastertalk 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:
TALKPAGEAlexis 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). HouseBlastertalk 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". HouseBlastertalk 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. HouseBlastertalk 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). HouseBlastertalk 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). HouseBlastertalk 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. HouseBlastertalk 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. 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)

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 Towers among the rest! GabGruntwerk 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 . 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 rfcAlexis 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. GMGtalk 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:
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[a], 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32[b], 33, 34, 35, and 36.

To be fair, I found four bluelinks that were saved because they were "ineligible for soft deletion": 1[c], 2, 3[d], 4. But I don't think that a redirectDescriptions of the Jyllands-Posten Muhammad cartoons, a stub, a non-neutral REFBOMB mess, and No Pants Day[e] justify the volunteer hours spent rubber-stamping uncontroversial nominations. Therefore, my idea: let these things be soft-deleted. Even if they were controversial[f] 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. HouseBlastertalk 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. HouseBlastertalk 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

  1. with the relist comment Not eligible for soft-deletion (due to contested prod back in 2006 (!) ...
  2. a batch nomination of seven was relisted because one had been dePROD'd
  3. kudos to User:FormalDude for finding sources
  4. closed as redirect after the closer found an appropriate target
  5. Okay, No Pants Day is awesome. I would say it is the exception that proves the rule.
  6. by "controversial", I mean someone at some point in time expressed the idea that the article should exist

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 (talkthey/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. GMGtalk 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

Æ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: 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

The Instinct to Punish (essay)

Deletion of account is needed

Understandablifying advanced math articles -- GPT and the Holy Grail

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

Quick template script

Editing goals

Change the new article requirement to extended-confirmed

Mickey Mouse (film series) and adding shorts

RFC Surveys

Biography Chronology/Timeline Addition

Related Articles

Wikiwand AI