Wikipedia:Village pump (idea lab)/Archive 36

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

Village pump (idea lab) archive

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

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

Warning for users when potentially unreliable sources are used

(based on discussion [1] with Headbomb)

Headbomb created a great tool that highlights potentially unreliable sources based on community consensus (such as WP:RSP). Would it be possible to create warnings (through edit filters maybe?) when a user's edit contains one of those sources?

For example something saying: "The community regards this source as questionable (see discussion here). Please make sure the standards for reliable sourcing are being met or you edit might be reverted" so that inexperienced users might be helped in discovering the past consensus by the community?

It could be a great learning tool and a great way of saving a lot of time for a lot of users and improve article quality fast.

Even better if the warning was incorporated in the "cite tool" of the visual editor.

-- {{u|Gtoffoletto}}  ^talk 13:10, 4 May 2021 (UTC)

We do have some warnings like that in Special:AbuseFilter/891. It's been a while since it's been expanded to cover more sources, but this one specifically deals with predatory sources. We could create other filters for different situations, but the threshold of crapness should be pretty high, not just "well.. it depends on a lot of things". YouTube is generally unreliable, but we wouldn't want to have a warning every time someone adds a YouTube link. Headbomb {t · c · p · b} 18:38, 4 May 2021 (UTC)

There's also the problem that the filters don't highlight which source is unreliable. They have to page back and forth between a list of unreliable sources, and their added text, and try to figure which is the one. Suffusion of Yellow (talk) 19:24, 4 May 2021 (UTC)

We do have a Wikipedia:Spam blacklist, and links from that list already get blocked. As for the filter warnings about unreliable sources, I think that any such warnings would have to be phrased rather conditionally. "You are trying to add a potentially unreliable source; please review it more closely" or something like that. Determining the reliability of a source requires a substantial degree of judgement and often depends on circumstances. Consensus regarding these issues is also complicated and should not be farmed out to bots or scripts. E.g. the outcomes listed at WP:RSP are themselves somewhat controversial, reflect varying degree of consensus, some of them are quite dated, some explicitly depend on how a source is used, etc. For sources that should never be used at all (I would put most junk predatory journals in that category), we should probably be trying to add them to Spam blacklist. Nsk92 (talk) 12:16, 5 May 2021 (UTC)

@Gtoffoletto, IMO you should be saying "Headbomb created a great tool that highlights potentially unreliable sources". If reliability were as simple as 'anything from this website is always bad, no exceptions' then it would be much easier. However, that's not reality, and WP:RSCONTEXT still matters, even for a source that is "generally" (aka "not always") unreliable. WhatamIdoing (talk) 17:32, 5 May 2021 (UTC)

I would agree with what WhatamIdoing says here. I'm grateful that on the odd occasion when I inadvertantly try to cite a predatory journal I get a warning message (I've no idea where from) but in general it takes human judgement to determine whether a particular source is reliable in context. We don't yet have enough advances in artificial intelligence to replace that. And, with the people here who develop code and templates seemingly being unable to cope with a few synonyms for parameters (something that was already old-hat in 1981 when I went into IT), we are unlikely on Wikipedia to even get close to what can be done elsewhere with AI. Phil Bridger (talk) 17:44, 5 May 2021 (UTC)

Agree with all of the above. This is why this is just a warning and not a complete block from using those sources. The editor will be aware of the previous discussion and can then make an informed decision himself. -- {{u|Gtoffoletto}}  ^talk 17:54, 5 May 2021 (UTC)

I'm not sure if that's true (when the Wikipedia:ABUSEFILTER is set to 'warn', lots of people just abandon their entire edit). Also, we have a problem with editors mindlessly removing 'bad' sources, so even if you know that the source is highly reliable for the particular point (e.g., Chinese state media on the official title of a Chinese politician) or actually authoritative (e.g., the original source of any quotation), there is still a risk that "your edit might be reverted" even if the source is being correctly and properly used. WhatamIdoing (talk) 21:01, 5 May 2021 (UTC)

The actual reliability of a source is it's objectivity and expertise with respect to the text/item that the cite is supporting. I'd recommend advice like that in the notice rather than further entrenching the over-generalization that a particular source is always reliable or always unreliable. North8000 (talk) 21:13, 5 May 2021 (UTC)

I would oppose this proposal. It would only put new Wikipedians off making edits to Wikipedia. Rollo August (talk) 15:28, 8 May 2021 (UTC)

The proposal has merit... but only if we're highly selective in which sources we warn in the edit filter. Everything deprecated at WP:RSPSOURCES would be fine to warn against, I feel. Below that (generally unreliable), we might want to log, but not to warn. Headbomb {t · c · p · b} 16:05, 8 May 2021 (UTC)

@Rollo August: on the countary I feel it would help new Wikipedians understand how Wikipedia works and have a more positive experience. Being reverted is never fun. -- {{u|Gtoffoletto}}  ^talk 09:06, 13 May 2021 (UTC)

@Headbomb: I agree. A simple example: the amount of time we waste on medical articles removing arXiv sources is staggering... and very often those are missed and remain in articles with unreliable information. Warning even just for deprecated sources would reduce this issue significantly. Do you think the best implementation would be an edit filter? I have no experience with those tools. -- {{u|Gtoffoletto}}  ^talk 07:58, 14 May 2021 (UTC)

But that's a bit the thing. Much like YouTube links, arXiv links are used for many reasons other than MEDRS claims. Giving an edit warning for it would be too much, because the majority of arxiv citations are relatively unproblematic. Unlike a citation to say, the Journal of Obvious Nonsense. Headbomb {t · c · p · b} 19:50, 14 May 2021 (UTC)

One of my favorite journals, along with The Journal of Obvious Results. Levivich ^harass/_hound 20:11, 14 May 2021 (UTC)

@Headbomb: Non peer reviewed articles are considered non-RS in all areas don't they? I see the only "exception" is for papers by proven SMEs. But that's why we warn and don't block. I mean: 99% of the times an Arxiv source will need to be rejected. The risk of a false negative (proper use being warned) is pretty low here and if you can make that determination (this is an SME so it's fine) then you can probably read and understand the warning. On the other hand we have a very high rate of true positives (99% of the time the arxiv link is inappropriate) and would be helping out new users and avoiding time waste by experienced editors. Normal editors don't know if a source has been discussed in the past (and should have to!). We can help them out and give them the contextual information to learn and discover past consensus rather than letting them "make a mistake by design" and cause the community to collectively waste time. Also: nobody likes being reverted. What would be really great is if we could give to the users the exact entry into the WP:RSP table. That would be very helpful but probably not technically doable with edit filters. -- {{u|Gtoffoletto}}  ^talk 12:57, 17 May 2021 (UTC)

"99% of the time the arxiv link is inappropriate" Really no. You can source plenty of uncontroversial statements to the arxiv. And a good chunk of the time, the citation is to papers like arXiv:1309.0102, which really is a lazy way of citing doi:10.1063/1.4869589. Headbomb {t · c · p · b} 19:10, 17 May 2021 (UTC)

Oppose Adding citations to Wikipedia is difficult. If you make it even more difficult then users will tend to add the same content without the citation. Also, it is well understood that Wikipedia is itself not a reliable source and that's because it is written by literally anyone with an axe to grind. And that especially includes the determinations made at WP:RSP. Andrew🐉(talk) 08:22, 14 May 2021 (UTC)
I would generally oppose this. There are quite a few museums out there that use blogspot (Wikipedia already flags up a warning message) and YouTube as channels for relaying reliable info/evidence. I think how we are is good enough, and people power is the best way to check refs.Davidstewartharvey (talk) 14:09, 17 May 2021 (UTC)

IP address confusion fix

Sometimes, when you're editing in an internet cafe or school, you get user-talks which aren't meant for you, since your IP address is shared. Maybe if each IP user had a special ID attached to them which is tied to device characteristics, the minor confusion of getting talks for someone else could be lessened. — Preceding unsigned comment added by 2600:1702:3520:3D50:D68:F0AD:9C8D:4EA2 (talk) 16:35, 18 May 2021 (UTC)

This would be hard, to ensure that things like your session information remain private. The easiest work around to this problem currently is to create an account. Accounts are free. — xaosflux ^Talk 17:03, 18 May 2021 (UTC)

This is why you can create an account. Sungodtemple (talk) 17:05, 18 May 2021 (UTC)

If they edit from the same device and same IP, then there is no way to differentiate it. Create an account and then you will only get messages for you and not your classmates. RudolfRed (talk) 22:30, 18 May 2021 (UTC)

A link bot

Moved from WP:VPPR

I have been through Category:All articles with too few wikilinks and I think a bot to link every word with a article on it would be good. It would mean editors don't have to go and make links anymore. Give me your opinions. TigerScientist Chat > contribs 20:21, 18 May 2021 (UTC)

I do not think this is a good idea... --Trialpears (talk) 20:23, 18 May 2021 (UTC)

This would likely create articles that have a WP:OVERLINK problem as Trialpears has so admirably demonstrated. Better too few than too many. OTOH the too few category would be a good start for any wikignomes looking for a new task. MarnetteD|Talk 20:31, 18 May 2021 (UTC)

Okay yeah I can see why no but maybe if it somehow could recognize normal words not worth linking. TigerScientist Chat > contribs 20:34, 18 May 2021 (UTC)

I'm sorry if that was a bit snarky, I just thought it was funny. On the other hand the WMF recently released Special:Homepage as a beta which has an add a link task which suggest places to add links. It's not perfect and I would definitely not want that to run unsupervised but there has been work in this direction. --Trialpears (talk) 20:37, 18 May 2021 (UTC)

No that was a great way to show why it would be bad. If it could identify links very well do you think it would be a good idea? TigerScientist Chat > contribs 20:40, 18 May 2021 (UTC)

If it was incredibly good with a near human level judgement then yes, but I can't see that happening in the coming decade. The growth team efforts here are almost certainly the best feasible improvement. --Trialpears (talk) 20:50, 18 May 2021 (UTC)

If a bot could do human-like constructive editing, running it would be a good idea. Actually, if it did its job correctly, running it would not even require approval. You'd just run it, and noone would notice that ToBeFree has been a bot all the time. Or TigerScientist. Or Trialpears. Whoever. So your "if" question is clearly answerable with "yes", but this answer does not actually contain information. ~ ToBeFree (talk) 21:06, 18 May 2021 (UTC)

I don't think you realise just how complex a problem this is. If an article contains the word "Chord" how does the bot figure out whether it's supposed to be linked to the musical, geometric or aeronautical article? If an article mentions "John Smith" how does the bot figure out if we have an article on the specific person mentioned? They might be listed on John Smith or we might not have an article on them. How does a bot figure out which words are a phrase relating to a concept that should all be joined together as one giant wikilink - if an article mentions the Internet of things it should be a single link, rather than e.g. Internet of things. How does a bot deal with things that go by multiple names, e.g. an actor that has a stage name? This would be an extremely difficult bot to program - it's a lot more complex than just putting square brackets around "interesting" words, and if done poorly it could make an enormous mess of incorrect links. 192.76.8.73 (talk) 21:18, 18 May 2021 (UTC)

My own experience (which is far from a proper statistical study) is that there are as many articles that have too many, or bad, internal links as there are with too few. This is just one more area where human judgement is still way ahead of any artificial, bot-like, intelligence. Phil Bridger (talk) 20:44, 18 May 2021 (UTC)

TigerScientist, bots are useless for this. It could link Earth, Wind & Fire which isn't even remotely connected to Earth, Wind & Fire. It could give Tony Hawks skateboard to a British comedian. It could render the windows in my house useless and the only sound the Doors could make would be being slammed shut. The Red Hot Chili Peppers would become edible and the tomatoes would become inedible. (unless you're a cannibal) It would be completely and utterly chaotic. You'd be giving that bot a license to kill Wikipedia. — Alexis Jazz (talk or ping me) 08:23, 19 May 2021 (UTC)

No, no. Avoid bots for this. They just give lots of errors. Redirection works fine. --Joujyuze (talk) 07:44, 19 May 2021 (UTC)

Yeah, I don't see a reason to do this. What should be linked is an editorial decision, and this requires actual editors. Elli (talk | contribs) 01:49, 20 May 2021 (UTC)

Recommendation for file (re)naming

Sometimes I add "(fair use)" to filenames. Generally when it's either shadowing a file on Commons or it's foreseeable that a file on Commons may get shadowed by it in the future. Examples: File:Lego Worlds (fair use).jpg because an unrelated file named "Lego Worlds.jpg" could be uploaded to Commons. File:Denis Akiyama (fair use).jpg because "Denis Akiyama.jpg" could be uploaded to Commons for various reasons that don't have to invalidate our local picture. File:Mickey Mouse (fair use).png because c:Category:Mickey Mouse isn't empty and the copyright on the little vermin is expected to expire in a few years which will result in more uploads to Commons, but that won't invalidate our fair use picture because 1928 Mickey looks nothing like current Mickey.

There is another reason to add "(fair use)" to filenames: it's the only thing that is sure to survive when third parties hotlink it and survive in some cases when a site caches the image. For example, on Everipedia or Wikivisually or WikiZero, how can you tell which images are free and which are fair use?

I'd prefer to always add "(fair use)" when a file needs to be renamed anyway (I wouldn't rename any files just to add it), but I wonder how others look at this. I'm not sure anything about this could or should be written into policy, but perhaps we could make a recommendation for file names. For fair use media, "Article title[, section title] (fair use).jpg" seems to work generally, never clashes with Commons, doesn't require subsequent renames if a movie poster is overwritten with cover art, or if a screenshot of a character from one game is overwritten with a screenshot of the same character from another game. I see both happening every now and then, needing a rename because the filename specified the game or medium. — Alexis Jazz (talk or ping me) 11:38, 17 May 2021 (UTC)

@Alexis Jazz: well, eventually, all fair use media will be copied to Commons when the copyright expires. So for long-term naming, I'm not so sure about including "(fair use)" in the name (more relevantly, the file could also be voluntarily re-licensed). Elli (talk | contribs) 12:44, 17 May 2021 (UTC)

Elli, those are some valid points. But getting re-licensed is fairly uncommon and entering the public domain takes decades (if not well over a century) for most files. And when a file gets copied to Commons, the hotlink URL will change anyway so there is not much harm in changing the filename when copying to Commons, I think. — Alexis Jazz (talk or ping me) 03:40, 18 May 2021 (UTC)

@Alexis Jazz: fair. I would be in favor of establishing an actual naming convention for certain NFCC criteria - and renaming all files we currently host to match - but I think if we do that well, we won't run the risk of being confused with Commons (for example, if we did, "Book Author Year (cover)" I don't think we'd ever get a naming conflict). Elli (talk | contribs) 05:09, 18 May 2021 (UTC)

Elli, I generally prefer not to specify "cover", "poster" etc in the filename because a fair amount of rename requests involves overwrites that replace one type with another or posters that were incorrectly labeled as covers and things like that. Renaming all currently hosted NFC files will be a Herculean task, but I would support it if we can hammer out a good naming convention. — Alexis Jazz (talk or ping me) 06:01, 18 May 2021 (UTC)

@Alexis Jazz: sure, I wasn't suggesting that be the naming convention. Just gave an example of something I think wouldn't clash.

And I agree - a Herculean task - but one probably worthwhile for improved categorization, clarity, etc. Elli (talk | contribs) 06:03, 18 May 2021 (UTC)

Elli, I just thought of another rationale for including "(fair use)" in the filename: it would allow the creation of an edit filter to prevent those files from being used outside article namespace by matching $fair[_ ]use$\.[wgjps] or something like that. We currently rely solely on bots (and highly observant users) to revert such inclusions afterwards. I remember some recent drama that could have been prevented had such a filter existed. — Alexis Jazz (talk or ping me) 02:31, 23 May 2021 (UTC)

@Alexis Jazz: interesting thought, but still not sure if it would be worth it overall. Elli (talk | contribs) 02:33, 23 May 2021 (UTC)

Elli, tools to export files to Commons could be adjusted to remove "(fair use)" automatically from the filename. (should be a rather trivial adjustment) Just saying, maybe ways can be found to address any remaining concerns. — Alexis Jazz (talk or ping me) 02:49, 23 May 2021 (UTC)

@Alexis Jazz: fair, I wouldn't be too opposed. I think a non-free content general naming convention would be more useful, though. Elli (talk | contribs) 02:52, 23 May 2021 (UTC)

Elli, I fully agree, but these ideas are not mutually exclusive. I'd prefer to include "(fair use)" in a naming convention.

— Alexis Jazz (talk or ping me) 02:56, 23 May 2021 (UTC)

Bot that updates net worth

Would it be possible to create a bot that updates billionaires' net worths based off of Bloomberg's index? ~ HAL333 05:36, 15 May 2021 (UTC)

@HAL333: Is there an easy to use, free API for that data? SQL ^{Query me!} 06:40, 15 May 2021 (UTC)

Not sure... ~ HAL333 17:02, 15 May 2021 (UTC)

It's a subscription site and this list (top 500) is one of their premier products behind a paywall - are they giving it away for free to be kept current on Wikipedia with an open source license? -- GreenC 17:23, 15 May 2021 (UTC)

I'm not sure whether any source can be said to be reliable when it comes to net worth. I couldn't tell you what my net worth is (my main assets are about 95% of a house (the mortgage will be paid off next year) which I share with my wife and a pension pot) and nobody's net worth is actually determined unless it is all held as cash. Assets such as property and shareholdings only have a specific value when they are sold, and in the case of large shareholdings they often cannot be sold for the current value determined by the stock market. And that is all ignoring the fact that nobody's worth depends on what they own. Phil Bridger (talk) 17:42, 15 May 2021 (UTC)

I agree with Phil; I think there would be V problems with that: a billionaire's net worth is only an estimate; estimates vary; and it changes every second (at least when stock markets are open). I feel that including net worth in an infobox is problematic for the same reason: whatever number is listed is always inaccurate; it's an example of false precision. Better to just state whether the individual is on a list, like Forbes 500. It's not really accurate to say, eg, that Gates's net worth is $150 billion (or whatever), because that can swing by a huge amount (sometimes an entire order of magnitude), as it did last year. It's better to say something like "Gates is consistently ranked in the top 5 richest people in the world, with his net worth estimated from $XXX billion to $YYY billion," than to put a single number on it. (Wikipedia should not, for example, state who is the richest person in the world, because it can't be said with any accuracy.) Levivich ^harass/_hound 17:47, 15 May 2021 (UTC)

@HAL333: ideally, we'd have that being updated in Wikidata, though we have a lot of editors opposed to including data from Wikidata in articles. Elli (talk | contribs) 09:58, 17 May 2021 (UTC)

I appreciate the responses. ~ HAL333 22:41, 18 May 2021 (UTC)

If I wanted to create a centralized discussion (probably an rfc) about including net worth in IBs, where should I do it? Maybe MOS? ~ HAL333 01:16, 28 May 2021 (UTC)

Why the separate tags?

Now, I'm a regular user of Special:RecentChanges, and I oftentimes use tags like #possible BLP issue or vandalism or #possible userspace spam to filter out messages. The issue is, there are tags like #possible vandalism and #Possible vandalism, and #Possible self promotion in user or draftspace and #Possible self promotion in userspace. I'm confused, why are the tags separate? And there are already tags like #possible vandalism that are tagged by multiple filters. Sungodtemple (talk) 01:27, 28 May 2021 (UTC)

Change filetype of one-sided PDFs

PDFs aren't really the best file format. They're hard to crop, hard to resize, they have certain privacy issues etc. I was wondering if there is support for a bot that extracts one-sided PDFs with only one image contained and saves that image in the filetype that it is. If the file inside the PDF is a JPEG, then save as JPEG, if it's TIF, then save as TIF etc. A few years ago User:718 Bot enhanced thousands of GIF files and saved them as PNGs since the latter is a better format, you can see the results here. I was thinking that this bot would do the same. Please elaborate further whether this is a good idea or not down below! I found this neat tool which extracts images from PDFs automatically.Jonteemil (talk) 10:47, 27 May 2021 (UTC)

I now learned that images inside PDFs aren't really stored as JPEGs, PNGs or etc. but rather it is the binary data for the pixels, the colorspace used for the image, information about the Image. The tool I found that extracts images from PDFs only seem to find JPEGs and PNGs but I don't know how it determines what is one or the other. For example I put File:Example.tif inside a PDF and but the tool extracted the image as a PNG, not a TIFF.Jonteemil (talk) 23:24, 27 May 2021 (UTC)

I support the proposal. How about LaTex? --NaBUru38 (talk) 18:25, 29 May 2021 (UTC)

NOWIKI

As a bot-author, link-rot saver, plain-text -> CS1 converter etc.. I am often aghast by the creative ways editors deploy nowiki and in the process create link rot, badly formed citations, and trip-wires for bots and scripts to snag on. Maybe it's just me, but I rarely see legitimate reasons for nowiki vs standard citation tools and templates. Suggest we could benefit from tracking categories and cleanup crews or tools for migrating these when it makes sense, which is probably at least 80% of the time. -- GreenC 18:29, 29 April 2021 (UTC)

I actually use nowiki a lot when in combination with <code> (I also used it here) so that it doesn't actually turn into Wikitext formatting. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 20:12, 29 April 2021 (UTC)

The {{code}} template works too, is less typing and is itself pure wikitext — <code>. Plain text without the background is also possible using the {{codett}} template — <code> — GhostInTheMachine ^{talk to me} 21:09, 29 April 2021 (UTC)

Example poor usage:

Last, First. Title. Publisher. <nowiki><http://example/com></nowiki>

(Note the surrounding <> which many tools pick up as being a part of the URL ie. http://example/com> ). They don't want the URL to be linked, yet to remain visible in full, sort of like paper. It's not a style exactly, typically found in pages mixed with other styles. Maybe it is a usurped domain (most cases not) - there are better systems for that too |url-status=usurped. It's rarely a good idea to nowiki in mainspace citations, there are better options. -- GreenC 21:21, 29 April 2021 (UTC)

Why... why do people do that? Yeah, of course we shouldn't. Elli (talk | contribs) 23:37, 29 April 2021 (UTC)

User:GreenC, some actual diffs of this would be useful, so we can see what's going on. I'm familiar with nowiki tags, but I've never seen them as having any connection with citations. Is this possibly something done by the visual editor, which I have often seen introducing unnecessary tags? Phil Bridger (talk) 21:47, 29 April 2021 (UTC)

I've been under the impression that nowiki should be avoided in articles the same way directly invoking modules is. Is that wrong? I do think it'd be reasonable to track that, if we don't. Elli (talk | contribs) 23:37, 29 April 2021 (UTC)

GreenC, as usual, WP:Visual Editor is to blame. [2] [3] [4] [5] — Alexis Jazz (talk or ping me) 02:45, 30 April 2021 (UTC)

User:Alexis Jazz, Ack for type 1. This looks like an active bug as there are some old closed Phab tickets from 2015 that address a similar problem. Solution might be convert to "link", or simply plain text URL. It would be an easy enough search-replace, could be AWB. Guess first step is open a Phab and verify it's a bug (known or not). Do you know any further info? -- GreenC 03:38, 30 April 2021 (UTC)

GreenC, here's type 2: [6] [7] [8]. As usual, VE is to blame. I use Wikiblame. For type 3, some uses are valid (like examples on pages about HTML) and 290 or so had empty nowiki tags. (nowikitag opened and immediately closed again) The only semi-valid use of that was on McCune–Reischauer and a related page where t' was written as ''t'<nowiki></nowiki>''. — Alexis Jazz (talk or ping me) 18:49, 30 April 2021 (UTC)

Alexis Jazz. This got waylaid, just opened a Phab with your diffs: T282322 -- GreenC 19:40, 8 May 2021 (UTC)

4 types:

<nowiki>http = 6,432
<nowiki>' = 8,715
<nowiki>< = 705
<http = 5,165

More to be discovered. -- GreenC 00:56, 30 April 2021 (UTC)

Filter 550 logs can be used to see all the nowiki's getting constantly put in to articles if anyone wants to see what is current. — xaosflux ^Talk 01:00, 30 April 2021 (UTC)
I will throw in that {{'}}, {{'s}}, and similar templates can probably be used to resolve most of the instances of Type 2, though I think part of the problem may just be that these templates are not very well known (or at least, I had no idea of the templates' existence when I made the same mistake a year and a half ago). — TheHardestAspectOfCreatingAnAccountIsAlwaysTheUsername: posted at 17:19, 17 May 2021 (UTC)

GreenC, Alexis Jazz: I can replicate type 1 in VE by entering a URL, then tapping the "remove link" button. Thus http://example.com/ ... When I paste <http://example/com>, it immediately nowikis inside the <>, which is different from type 3. If type 1 is due to users unlinking URLs on purpose, then why are they doing that? ⁓ Pelagic ( messages ) – (13:33 Sun 30, AEST) 03:33, 30 May 2021 (UTC)

Syncing of Reading List Across the App and Website

On the iOS and the Android Wikipedia apps, there is a "Reading List" feature. Would it ever be possible for this to sync with the website too, and not just other apps? A new "reading list" button on the website would be very helpful! Squid45 (talk) 14:44, 22 May 2021 (UTC)

There are some browser extensions that allow you to save articles to the apps' reading list. I don't know how well these work, or if they work the other way round (i.e. view articles in the apps reading list from your desktop browser). the wub "?!" 14:29, 23 May 2021 (UTC)

Tehehe, when I said the same thing up above, I wasn’t aware of this section! If logged in the iOS app seems to sync the reading list to your Wikipedia account, so it must be in the MediaWiki database somewhere? ⁓ Pelagic ( messages ) – (15:15 Sun 30, AEST) 05:15, 30 May 2021 (UTC)

Report a page

Can you create a button "Report this page to the administrators" like on other sites? It was very hard to find the page to call administrators.Tint Last (talk) 04:24, 28 May 2021 (UTC)

Could you give us examples of those "other sites"? Nardog (talk) 04:27, 28 May 2021 (UTC)

On https://www.reddit.com/r/pics/comments/nmy9sd/at_the_salt_lake_city_farmers_market_a_few_years/ there is a small flag and the word "report" to report the post. On Twitter I can use "Report Tweet". Tint Last (talk) 17:23, 28 May 2021 (UTC)

If you see an error, just fix it. Sungodtemple (talk) 17:24, 28 May 2021 (UTC)

More often than not, new users don't know what the role of administrators is on Wikipedia. The rule of thumb is that any normal process starts with editors who are not administrators, and only when a decision is made are administrators called to implement it. There are ways administrators find such pages and usually don't need to be specifically alerted for them. It's quite rare for administrators to be called to act straight away without some editor-driven process preceding it. – Finnusertop (talk ⋅ contribs) 08:23, 28 May 2021 (UTC)

{{sofixit}} or send to CSD are "expected" responses for the most obvious "problem pages" - but these are not necessarily intuitive for brand new editors. (c.f. why edit requests get sent to OTRS by brand new editors) -- ideas for improvement could be useful. — xaosflux ^Talk 12:43, 28 May 2021 (UTC)

I'm sorry. I thought I had found the page to report to administrators:Wikipedia:Administrators' noticeboard and the dispute on Bob Coronato was settled by the administrators. But the other administrator told me I should have reported List of songs about Alabama by email? With a button to report pages to the noticeboard it would be easier to make a report. Tint Last (talk) 17:35, 28 May 2021 (UTC)

@Tint Last: comparatively few of the issues you might want to report are really "something for the admins" - unlike most sites, there is little that admins can do unilaterally that any regular editor cannot also do, and in the field of content, admins don't have any special authority. The majority of what we do is execute what the general Community (or the little bit of it interested in a particular article) decides, if that needs any of our broader tools. There's a few bits where that's not true - e.g. I can and do unilaterally block an obvious vandal while a normal editor would report to The board for vandalism, if I wasn't "involved". Nosebagbear (talk) 13:27, 30 May 2021 (UTC)

Watchlisting a specific user’s contributions

Tracked in Phabricator
Task T2470

I have an idea I'd like to suggest. So recently, InedibleHulk commented on my talk page. I absolutely LOVE the sense of humor he frequently uses during discussions and in the edit summary, whatever the circumstances are he somehow has me laughing my ass off all the time whenever I encounter him. I realized that if I have a bad day, I can just go to his contribution hostory and see posts of his that are guranteed to make me laugh. This made me think, why not make it possible to watchlist contributions? Primarily it can be used for legitimate purposes (like monitoring a new user's contributions for mentorship purposes or a recently unblocked or otherwise scrutinized user to monitor their edits and behavior, or to keep track of edits and improvements for a particular topic if the user specializes in that topic), but it also has the potential to be used for personal pleasure too such as in the case I provided. Would this be a good idea to extend watchlist abolities to a specific user's contributions? DrewieStewie (talk) 03:17, 18 May 2021 (UTC)

DrewieStewie, m:Community Wishlist Survey 2021/Admins and patrollers/Watchlist of users — Alexis Jazz (talk or ping me) 03:29, 18 May 2021 (UTC)

phab:T2470 has been opened for this since 2004! — xaosflux ^Talk 15:36, 18 May 2021 (UTC)

See also phab:T33105. — xaosflux ^Talk 15:37, 18 May 2021 (UTC)

It's not quite what you want in this particular situation, but you can set up RSS feeds for individual user contributions as well as page histories. Not many people regularly use RSS readers any more, but I think I had a couple of these set up back when I did do so. Andrew Gray (talk) 16:47, 18 May 2021 (UTC)

Anyone who actually wrote a script for this would have a very high likelihood of being SanFranBanned and having the source code oversighted, unless the person you want to follow has to approve you running such a script on them (and I can't imagine many people giving such approval, except in a few very limited training/mentoring situations). To quote the WMF on exactly this proposal:

Following and being followed must be a mutual agreement. The idea would be to have a way to give agreement on the fact that you can be followed. On the watchlist, when you add a user, that user will receive a notification to agree (or not). That notification would gather a message from the follower and a link to the follower's talk page. Resume that following may be possible on the watchlist or into preferences page.

‑ Iridescent 19:04, 18 May 2021 (UTC)

This WMF statement sounds incompatible with the CC-BY-SA license that writers here agree to. The right to copy someone's work, must surely also include right to the awareness that the work exists. And the knowledge of each individual piece of work implies being able to know everything a user does under that license, from the time they release the copyright, ie when they save. Graeme Bartlett (talk) 23:12, 18 May 2021 (UTC)

The licence does not include a requirement to notify the authors of all copies or derived versions, to have a central registry of all copies or derived versions, or other comprehensive awareness mechanisms. It would be a significant burden and potential privacy concern for distributing or modifying works in a free (libre) manner. That being said, the recent changes feed and the watchlist are awareness mechanisms for changes made on Wikipedia. User contributions are already fully visible, either through the special contributions page or through the recent changes feed. Anyone can build an interface to display them as they wish (they can create a client that tracks which contributions they have already clicked through to see, for example) and make use of it on their own computer. isaacl (talk) 02:25, 19 May 2021 (UTC)

Um... no? I thought we discouraged hounding. Seems like this would just provide an easy tool to make it worse. 🐔 Chicdat ^{Bawk to me!} 10:41, 19 May 2021 (UTC)

It's as was the result from the Community Wishlist - no-one thought it had been requested in bad-faith, or that the supposed positives weren't, in fact, completely possible. It was just that the ease of negatives that can come from this are also obvious and not really viable enough to avoid to make it worthwhile doing, or even enabling. It'd be a bit OTT for a SFB if someone did this unless there was evidence of serious misuse or they duplicated the work after having it removed once, but it would certainly not be wanted. I would not advise creating a method of doing so. Nosebagbear (talk) 22:22, 30 May 2021 (UTC)

Making Wikipedia More Welcoming To The Modern User

I may be wrong, but in 20 years, Wikipedia's design has not changed much. The design was great for the online innovations of 2001, but... not so great now. Websites nowadays have simple, user-friendly buttons, accounts systems that have cross-platform "read later" lists (or better yet, folders too), personalised feeds, etc. Wikipedia still has a fairly limited UI, while the rest of the internet has moved on. The app has some modern intergrations, but these don't sync with the website so it's still limited in scope.

Now obviously a "For You" feed would include countless data and privacy concerns but surely there could be some sort of opt in system for a user-data driven, modern UI? Like a personalised feed that simply recommends new articles based on ones you have read would do wonders for this. Is there any reason why this can't happen? Squid45 (talk) 17:38, 17 May 2021 (UTC)

In your user preferences, you can change your skin and even create your own. There is even a list of cool skins. 'Read later' lists can be bookmarked in-browser. And note that Wikipedia is an encyclopedia, not a social media website or dictionary. A personalized feed would defeat the purpose of Wikipedia. Sungodtemple (talk) 17:53, 17 May 2021 (UTC)

One of the attractions of Wikipedia is that it doesn't make silly suggestions of what we might like in the way that many other web sites do. It is a way of selling you more or telling you what you should think rather than anything that benefits the reader. If that's modern, then I'm proud to be old-fashioned. Phil Bridger (talk) 18:10, 17 May 2021 (UTC)

Can I also say that one of the positive attributes of Wikipedia is that, unlike many other websites, it does not ask us whether we want to accept cookies? Rollo August (talk) 20:12, 17 May 2021 (UTC)

I'm really not too keen on the idea of a "For You" feed, or user data driven navigation. For starters there's the privacy issues alluded to in the op. Tracking and storing user movement around the site so that an algorithm can guess what readers might be interested in would be a massive divergence from current policy where even stuff like checkuser data is only kept for 60 days for user privacy, and if it's an opt-in system you'll never get enough data to produce meaningful results (most of our readers do not have accounts, and I imagine only a fraction of registered users would be happy with the WMF tracking their reading). How do you propose to separate user data from reading from user data from editing? Any tracking of where our registered users go is going to be massively polluted with nonsensical page jumps from things like Auto wiki browser, new page patrol, anti-vandalism work, sorting through cleanup categories, etc.

Fundamentally though the idea of driving user navigation by page views should be unnecessary - navigation should be built into articles. If a paragraph mentions something that a reader might be interested in it should be a wikilink, if there's a series of articles on a topic that make sense to read together they should be presented together in a navbox, if there are articles that are a natural follow on from the article a reader has just read they should be listed in the "see also" section, and all articles should be sorted into appropriate categories to make it easy for editors to find related content. We also have a huge number of volunteers working on maintaining the front page as a showcase of high quality content from around the site, which has enough variety to serve\ well as a list of recommendations for things readers might be interested in reading. 192.76.8.91 (talk) 22:41, 17 May 2021 (UTC)

“

The term "modern" makes sense from a descriptive perspective – for instance, solely to distinguish newer periods and ways from older ones.

It becomes a problem when it carries the presumption that older ways are "old-fashioned"; that is, presumed to be worse. In technological fields where businesses make the choices and impose them on users, the reverse is often true.

”

— Richard Stallman

When the "modern user" gets used to something which is 'convenient' but not actually in their interests and asks us to implement it too, our best option is to politely say "We won't give you that, but we're not refusing out of malice; here are the reasons why this change is actually not in your interest". It's a good opportunity to try to teach people to respect themselves, actually. DesertPipeline (talk) 05:53, 18 May 2021 (UTC)

I do like the reading lists feature in the iOS app, and wish that was available in the browser version. ⁓ Pelagic ( messages ) – (14:07 Sun 30, AEST) 04:07, 30 May 2021 (UTC)

Minerva and Timeless skins have a "related articles" widget which works in mysterious ways, but I don’t see it "driving user engagement" the way YouTube's suggestions do. When I'm reading articles, I tend to use navboxes and the See also section, though sometimes Related Articles does surface something pertinent. ⁓ Pelagic ( messages ) – (14:07 Sun 30, AEST) 04:07, 30 May 2021 (UTC)

@Pelagic, the "Related articles" feature is available on the desktop site (just not here, because editors didn't want it). It's just the top three search results, preloaded for convenience. Put morelike:Article_title into the regular search box, and you'll get the same effect. Click here to see the results for morelike:fish.

(You can manually control the search results if the results are poor. This sometimes happens with very short articles (e.g., "Joe Film is an actor known for once voicing a My Little Pony character", which can rate pretty high in searches related to the only thing linked in that substub). Whatamidoing (WMF) (talk) 02:55, 3 June 2021 (UTC)

Citation needed tagging in VisualEditor

Moved from Village pump (proposals)

– Tol | Talk | Contribs 05:10, 25 May 2021 (UTC)

I think the ability to be able to select and place "citation needed" through the cite feature in the visual editor with a single click would be helpful. Not needed but it would save time. TigerScientist Chat > contribs 21:05, 18 May 2021 (UTC)

Copy the following text and paste it in any article: {{cn}} This will simply work with the visual editor in the way you're requesting. ~ ToBeFree (talk) 21:09, 18 May 2021 (UTC)

ehh I guess maybe. TigerScientist Chat > contribs 15:10, 19 May 2021 (UTC)

You may want to post this on Phabricator if you really want this, however I think that just using the template is easy enough personally. EpicPupper (talk) 19:00, 19 May 2021 (UTC)

@TigerScientist: If you'd like, I can see if I can put together a user script which could add another button to to this. Tol | Talk | Contribs 05:28, 25 May 2021 (UTC)

Tol not needed but if it doesn’t take much time or effort go ahead. Thank you for even suggesting this. TigerScientist Chat > contribs 05:30, 25 May 2021 (UTC)

@TigerScientist: No problem. I haven't worked with VE before, so I don't know how long it'll take, but I'll try to get something to you within about two weeks. Tol | Talk | Contribs 18:24, 26 May 2021 (UTC)

Done: The script's documentation is at User:Tol/VECN, including installation instructions. Let me know if you have any questions! Adding stuff to VE is remarkably simple. Tol | Talk | Contribs 20:36, 26 May 2021 (UTC)

WOAH thank you Tol! TigerScientist Chat > contribs 16:01, 27 May 2021 (UTC)

@TigerScientist: You're welcome! Tol | Talk | Contribs 20:19, 27 May 2021 (UTC)

@Tol, you are the only person I have ever heard say that adding a script to VisualEditor is easy. Would you please put mw:VisualEditor/Gadgets, mw:VisualEditor/Gadgets/Creating a custom command, and mw:VisualEditor/Gadgets/Add a tool on your watchlist? They're very low traffic pages, and Flow/Structured Discussions will ping you in Echo/Notifications if anyone ever posts anything to their talk pages. Also, you might be interested in mw:New Developers. Whatamidoing (WMF) (talk) 03:07, 3 June 2021 (UTC)

@Whatamidoing (WMF): Wow; alright! I still don't fully understand VisualEditor, but I'm more than happy to watchlist those pages. Thank you for the resource! Tol | talk | contribs 05:48, 3 June 2021 (UTC)

Suggestion: reverts should be sourced as well

In recent months I've seen my edits being reverted more and more often. I'm not saying all of my edits were good, but I *am* saying some of them were proper new knowledge into the encyclopedia. Some of them were—also, I believe—reverted because of partisan bias, always by the reason that I don't source well enough.

True enough, this is my sin. I don't source well, because of how my memory works. But isn't it also a sin to revert without reason as well?

Especially since in the philosophy of science I'm a follower of Karl Popper, i.e. a falsificationist. From that standpoint it seems kind of trite to just revert stuff which hasn't been duly falsified. Such a thing doesn't seem to lead to accumulation of knowledge. Especially since this encyclopedia *tries* to follow broadly Popperiean principes; does it really, anymore?

Why not require a cite for a substantial revert, as well as an edit, for symmetry? I mean, a revert is as much of a removal as a removing edit. Both of them should be sourced. Evenmoreso the removal and the revert, than the addition, in fact: they destroy knowledge added by the community, for the Sake of an Arbitrary and Often Useless Rule. I believe the better option would be to make destroying edits and reverts as hard to do, and well-sourced by standard, as an addition is.

And by the way, that sort of change of rules would revitalize the community as well. *Everybody* is in pains with how the editorial culture here is turning. It's harder and harder to just wiki-edit, because the learning curve and editorial culture has become so steep. You just can't get your stuff in, evenwhile you know what you're talking about. In the lesser known wikipedias such as my Finnish one, you can barely step in still. But in en-pedia, it's almost impossible, unless you're a (semi-)professional editor.

That is then fully counter to the original mission of Wikipedia. You cannot collect all of the encyclopedic knowledge out there if you bring up this sort of barriers to the common expert just writing it up. Of course the rules make it easier for the editorship to keep standards up, and stake their ground, but the accumulation of knowledge then suffers. For example via those constant, formalistic, unsourced reverts I and everybody else suffers.

Please put a stop to them by rule. If not by the rule I'm suggesting—in sourcing reverts and amissive edits—then otherwise. Because otherwise the development of this encyclopedia is going to hit a serious case of diminished returns. We will stagnate, quite like DMOZ once did. Decoy (talk) 20:56, 6 June 2021 (UTC)

Verifiability is Wikipedia policy, not "an Arbitrary and Often Useless Rule". Schazjmd (talk) 21:00, 6 June 2021 (UTC)

And most of the above is addressed in WP:BURDEN specifically. — HELLKNOWZ ▎TALK 21:07, 6 June 2021 (UTC)

It's actually perfectly in line with the original mission of Wikipedia. Back in the day we used to say that "on the Internet, no one knows you're a dog". Wikipedia's idea is that rather than focusing on the old paradigm where we trust an "expert" to write an article based on their knowledge of the subject, we allow anyone (even dogs) to edit but make trusting them irrelevant with very strict sourcing requirements. So, when you're reading Wikipedia you don't have to trust the Wikipedia editors who could be dogs. You just click on the box with the number in it and look at the original information.

If you don't like the founding principles of Wikipedia then go to Citizendium. Chess (talk) (please use {{reply to|Chess}} on reply) 21:21, 6 June 2021 (UTC)

@Chess: I'm not sure Citizendium will exist anymore by the time Decoy gets there. 🏳️‍🌈 Chicdat ^{Bawk to me!} 10:33, 7 June 2021 (UTC)

Decoy… I do sympathize (it sucks to be reverted). My advice: take a "longer term” approach to your editing. If you want to add something to an article - WAIT! Assume that whatever source you have is not good enough, and spend a few days searching for an even better source before you attempt to add it. You will find that you will be reverted a lot less. Best Blueboar (talk) 12:15, 7 June 2021 (UTC)
I wonder whether we should consider one thing the German Wikipedia does well: their "edit summary" field is called Zusammenfassung und Quellen, "summary and sources". While the edit summary isn't a great place to stick sources long term, this reminds people to always say where their content comes from, and just from looking at their Recent Changes feed, it seems to help a little. Of course, more research is needed. —Kusma (talk) 12:54, 7 June 2021 (UTC)

If you want a source for reverts, I'm going to use [9] to source this revert. This was poor paragraph, with an unsourced quotation because it apparently isn't a real quotation! Please keep a formal encyclopedic WP:TONE without such opinionated or essay-like wording. Reywas92^Talk 19:07, 7 June 2021 (UTC)

Net worth values in IBs

I find the net worth estimates in IBs (eg at Bill Gates) to be very problematic and confusing. How can we actually provide the reader with an accurate estimate when Bloomberg and Forbes often conflict? Which one do we choose? Do we average? Should it be a weekly or monthly average? How often should it be updated? What do the accompanying red or green triangle indicate? (An increase/decrease in the past day, week, month, year, etc) It opens up a whole can of worms. In similar situations, like the values of elements or drug prices, we avoid including monetary values. I'm starting to think that we should do the same and save an explanation of net worths for the prose where it can be better explained. What do you think? ~ HAL333 04:31, 8 June 2021 (UTC)

(edit conflict) Use both. 🏳️‍🌈 Chicdat ^{Bawk to me!} 10:38, 8 June 2021 (UTC)

Use neither. As noted, where appropriate it can be explained more completely elsewhere. Nikkimaria (talk) 12:07, 8 June 2021 (UTC)

We had a discussion somewhere (but I don't recall where) recently about "net worth". I'll note that I hate the term "worth" in this context as if someone's worth was determined by what they own, but we seem to be stuck with it. I am in the fairly normal position of a middle-class Englishman approaching retirement age in that my net worth consists of a house and a pension fund and little else, but I would struggle to tell you my net worth to closer than about 20% either way, so how on Earth can we consider any published guesses to be in any way accurate? The very rich tend to have assets in large shareholdings and property, the monetary value of which can only be properly assessed when they are sold - the current share price of a company does not determine what a large stake can be sold for. Of course Bloomberg and Forbes often conflict, because thay both make wild guesses and then pretend that their figures are in some way objective. Phil Bridger (talk) 15:39, 8 June 2021 (UTC)

Link to RfC on this: Template talk:Infobox person#Deprecating the net worth parameter?. Cheers. ~ HAL333 17:05, 8 June 2021 (UTC)

New user right (edit request reviewers)

This snowed at VPR and it's going to snow here as well; there's no point in dragging it out. {{u|Sdkb}} ^talk 17:41, 8 June 2021 (UTC)

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.

Moved from WP:VPR

I propose the creation of a new user right: "edit requests reviewers" who have the ability to accept/reject edit requests that are proposed in the talk of protected pages (except PRC protection and full protection) This right is automatically assigned to administrators and PRCs who have extended confirmation.

I make this proposal because I believe that only trustworthy users can accept/reject edit requests following the same logic that led to the creation of the PCR user right. Dr Salvus 23:11, 5 June 2021 (UTC)

Oppose because this doesn't seem to make sense or solve a problem, and is technically infeasible. The permission to edit a semiprotected page is limited to autoconfirmed users. It follows that any autoconfirmed user can make the same edit independently, and thus should also be able to process the same content when requested on talk. Where the content is in dispute, it is resolved by the usual WP:DR processes to build consensus. This proposal is also technically unforceable and cannot be a user right as proposed, because it's technically indistinguishable whether an edit is implementing a request or is an independent edit. Finally, Wikipedia does not need to limit editing in this manner, and there is no evidence of a problem with autoconfirmed users responding to edit requests. Actually, the real problem is that PCR shouldn't be a separate user right. It should be bundled in with autoconfirmed or extendedconfirmed. An autoconfirmed user is sufficient to implement an edit request via talk, and is sufficient to edit a pending changes page directly and have their changes go immediately live, and thus should be able to approve a change as well. ProcrastinatingReader (talk) 01:28, 6 June 2021 (UTC)
Oppose, appears to be a solution looking for a problem. Can you give us some examples of autoconfirmed or extended-confirmed editors wrongly accepting/rejecting edit requests? Sungodtemple (talk) 01:48, 6 June 2021 (UTC)
Note @Dr Salvus: I've moved this from VPR to VPI. This really would need a lot of work shopping before it is ready for a proposal discussion. If you strongly disagree, go ahead a move it back - but it will likely get snow closed there. Here it could be developed more. — xaosflux ^Talk 03:15, 6 June 2021 (UTC)
No. Any experienced editor in good standing may review an edit request. That is policy. 🏳️‍🌈 Chicdat ^{Bawk to me!} 10:09, 6 June 2021 (UTC)
Oppose, as ProcrastinatingReader states above and far better than I could this makes no sense from a technical viewpoint. Furthermore I see no reason why this should be implemented, the reason almost all edit requests are made is because the editor can't currently edit the page because of the circumstance outside of their control, and normally we wouldn't have some special usergroup checking their edits eiter. -- Asartea ^Talk ^| ^Contribs 15:20, 7 June 2021 (UTC)
Oppose, reviewing an edit request shouldn't require any more technical capability than editing an article, which is basically the base level of competence expected of all editors. Creating a userright for this would just be a hat to collect: it wouldn't improve anything, and would make responding to edit requests much more bureaucratic than it needs to be, which is actively harmful to content creation. Ivanvector's squirrel (^trees/_nuts) 15:13, 8 June 2021 (UTC)
Comment: I've notified WikiProject Edit requests of this discussion. Happy editing! ---Another Believer _(Talk) 15:19, 8 June 2021 (UTC)
I agree that sometimes there's a tendency to go straight for the easy templated XY or RS response on edit requests – answering the letter of the request, rather than taking the two extra minutes to dig out a source or suss out what the requester is trying to say. I've been guilty of that myself on occasion. However, doing it via userright is not the way to address that, for the reasons stated by others (technical infeasibility being a big one). If you see a request declined that you would've completed, there's nothing saying you can't still work on it, and if you see someone doing it a lot, discuss it with them. If it's something that's more widespread, that's something that should be demonstrated with diffs and addressed, but for now I agree that this is a solution seeking a problem. ‑‑ElHef (Meep?) 17:22, 8 June 2021 (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.

formating article export

Tracked in Phabricator
Task T167956

Hi, I would like to set the page format for article export (PDF, Book and/or print, whatever)? Can't find such options (my fault?). I am thinking about simple stuff like font size, position of tables and widht of the outer frame of the pages. No idea how that could be implemented, probably not too hard. Would be cool if someone took care of that. Thank you — Preceding unsigned comment added by Hennk von Muspelsheim (talk • contribs) 12:51, 8 June 2021 (UTC)

Not at the moment. This should really be at technical. Someone please move the dicussion accordingly, I have no idea how to do it. Sungodtemple (talk) 12:02, 9 June 2021 (UTC)

@Hennk von Muspelsheim: on the left sidebar pane there is a "printable version" button example you may click - however keep in mind this feature is deprecated; if you use the "print" function in your browser (including options it may have to "print to pdf") you will likely have better results. If you have other general questions on how to use Wikipedia, please see Wikipedia:Help desk - if you think you have identified a technical problem you can post at WP:VPT. — xaosflux ^Talk 15:51, 9 June 2021 (UTC)

Watchlist folders

Tracked in Phabricator
Task T3492

I've been wanting to bring this back up for some time but never got around to doing it until now. The watchlist is a very useful tool designed to help us users keep track of recent changes, but I find the current A-Z listing system a bit tedious. As I write this, I have 188 articles on my watchlist. I don't think that's such a huge number compared to other experienced users, but it's big to me, and I often find myself going through my list and asking myself, "Why is this article still here? It hasn't been vandalized for months. I don't need to keep an eye on it anymore." The problem is with a long list, I often miss a page or quickly get tired of checking it. With watchlist folders, users such as myself would be able to have an easier time locating articles.

I've searched through the archives and found three discussions about topics like this (1, 2, 3), but none of them really lifted off the runway. I want to keep my watchlist private (so no subpages), and bookmarking watchlisted pages seems redundant. The latest entry is from 2013, so maybe we've come far enough to make this possible. Perhaps watchlist folders could be part of our Preferences as a Beta feature. I'm not a very technical user, so I'm not sure if this is possible, but I'd like some feedback on the idea of watchlist folders. It'd certainly make my Wikilife easier if this is utilized, and the only reason I'm not watching more articles than I am now is because they'll just get lost in the long, long list. Regards. ResPM (T🔈 🎵C) 01:32, 2 June 2021 (UTC)

@ResolutionsPerMinute: it sounds like you want to have more than one watchlist for different things (in this case organized in to "folders" of some sort) correct? If so, this is phab:T3492 (now celebrating its 15th year of not being implemented!). — xaosflux ^Talk 01:49, 2 June 2021 (UTC)

@Xaosflux: This does look like what I'm talking about, but 15 years in the works without being implemented? Am I hearing that right? ResPM (T🔈 🎵C) 02:05, 2 June 2021 (UTC)

@ResolutionsPerMinute: yup - seems there are a couple of problems: (a) no one can decide on what exactly it should be, (b) no volunteer wants to take over actually managing it, including the software developement, to completion. — xaosflux ^Talk 02:10, 2 June 2021 (UTC)

@Xaosflux: Drat. Well, I'll take solace in the fact that its foundations exist. I wish I could help, but I'm a citer, not a developer. I would if I could. Thanks for filling me in. ResPM (T🔈 🎵C) 02:16, 2 June 2021 (UTC)

User:MusikAnimal/customWatchlists exists, but with watchlists being publicly visible. It's also possible to implement private watchlists in JavaScript (thus bypassing phab hurdles) by using mw.user.options, though no one seems to have done this yet. You could file a request at WP:US/R. – SD0001 (talk) 08:21, 4 June 2021 (UTC)

ResolutionsPerMinute, I'm desperately trying not to comment on how big your watchlist is (mine is 12,929) and I won't comment on the folder proposal but I want to make sure you are aware that there is a timed option now available. Click on the star, note the dropdown box and pick an option other than permanent. I work on a lot of copyright situations and I want the related article on my watchlist for a little while case they don't know to contact me but I don't want it on forever, so I used one of the temporary options. Believe it or not that's helped keep my watchlist from getting completely out of control. That option sounds like it might apply when you decide to watch an article that has had some vandalism. S Philbrick (Talk) 01:08, 11 June 2021 (UTC)

@Sphilbrick: I've known about the timed options since they were first implemented, and I've decided to utilize this option as a substitute for now. I'm not my ideal solution, but it works. ResPM (T🔈 🎵C) 01:17, 11 June 2021 (UTC)

Adding new language option as Indian English

Tracked in Phabricator
Task T212313

Moved from WP:VPR

A new language option should be given to users known as Indian English. It is important not only as a new language but also all Indians use their own numbering system known as Indian Numbering System which uses lakhs and crores instead of millions and billions where 100,000= 1 lakh(1,00,000) and 1 million(1,000,000)= 10 lakh(10,00,000). Most of the websites and apps convert values to the Indian Numbering System when English(India) is selected and I think Wikipedia should do the same. — Preceding unsigned comment added by Sreeganesh M R (talk • contribs) 10:58, 9 June 2021 (UTC)

Is there a recognized, formal standard for Indian English? And, if so, how does it differ from those of British English, Australian English, Irish English, etc? We really don't even need all the "_______ English" tags we already have. Note that colloquialisms and terms for things not really found outside of India don't count for these differences. Your suggestion of automatic converting of numbers seems like something similar to the idea of automatic conversion of units. Such things have been rejected in the past. --Khajidha (talk) 11:17, 9 June 2021 (UTC)

I am sure this has been discussed at length previously, but my take is that the differences between various varieties of English are small enough to mean that we don't need any automatic conversion. The number system is one of the major features that is different in Indian English from that in other varieties, but I think that all that needs to be done is for editors to be aware that others, even though pretty fluent in English, may not be very familiar with terms such as million or crore and to bear that in mind when deciding whether to link them. Phil Bridger (talk) 12:07, 9 June 2021 (UTC)

What exactly do you mean by new language option, Sreeganesh M R? It's already a policy that articles can be written in any variety of English including Indian English, so for example topics related to India should already write large numbers in lakhs. – Joe (talk) 12:17, 9 June 2021 (UTC)
The manual of style discourages use of lakhs and crores even when writing in Indian English. Usedtobecool ☎️ 13:47, 9 June 2021 (UTC)
@Usedtobecool: It does? The only above I'm seeing at WP:CURRENCY is for non-country specific articles. {{u|Sdkb}} ^talk 14:13, 9 June 2021 (UTC)

According to MOS:INDIA the use of lakhs/crores is allowed provided that million/billion equivalents are provided in parentheses, and that lakh/crore is linked at the first mention. Narutolovehinata5 ^tccsdnew 14:16, 9 June 2021 (UTC)

MOS:LAKH: We are the Borg. Usedtobecool ☎️ 15:20, 9 June 2021 (UTC)

@Sreeganesh M R: this proposal isn't actionable and would need much development, including for you to be much more specific about what you want changed (and then how you want that to happen) - I've moved from the VPR forum here to the idea lab so it doesn't just get declined and closed. — xaosflux ^Talk 13:42, 9 June 2021 (UTC)
For use in the software, please see phab:T212313. — xaosflux ^Talk 13:45, 9 June 2021 (UTC)
There was a discussion I think several years ago now (I can't find it) about merging all the different "use ____ English" templates and directives down to only those which are actually functionally unique, which would have left us with only {{Use American English}}, {{Use British English}}, and {{Use Canadian English}}, with every other existing template redirected to whichever one applied to that variant (between US and UK; Canadian is unique). It evidently did not reach consensus. I can see the case being made here that Indian English is a variant that's unique enough to also be treated uniquely in this scheme. However, if the proposal is to create a separate Indian English Wikipedia (akin to Simple English Wikipedia) then no, strong oppose. Ivanvector's squirrel (^trees/_nuts) 14:29, 10 June 2021 (UTC)
One problem with Indian English is defining it. At the academic level it loses most of its distinct characteristics, and as it is a second language for the great majority of its users, very many make grammatical "choices" that would not be found in the better Indian newspapers (which are probably the best choice for a "standard"). But are these "mistakes"? Who is to say? An Indian schoolteacher I suppose, but we have few such editing. One of the most conspicuous differences is use of "the", which Indian writers tend to omit (like Polish ones). Is that wrong or not? The Times of India wouldn't do it, or not often. Johnbod (talk) 15:08, 10 June 2021 (UTC)

Exactly. I would think that true language variants would be set by native speakers. If the distinctiveness of "Indian English" is mostly due to usage by secondary speakers, I would not count it as valid. In English language sources from India, academic sources and major news sources are probably going to be indistinguishable from British English. --Khajidha (talk) 16:10, 10 June 2021 (UTC)

Well, major news sources are certainly not indistinguishable in their references to large numbers. Indian sources nearly always use lakh and crore, which are unknown terms in British English. Phil Bridger (talk) 16:32, 10 June 2021 (UTC)

True, but that could be handled with a "use British English, but provide lakh/crore numbers" option. Are there any other differences in high-level, formal sources? --Khajidha (talk) 18:12, 10 June 2021 (UTC)

Yes, I agree that there are very few things that are unique to formal Indian English, hence my statement above, but we should acknowledge those that do exist, and hope that our readers will learn about them. Phil Bridger (talk) 20:03, 10 June 2021 (UTC)

I certainly don't agree that "there are very few things that are unique to formal Indian English" - actually there are rather a lot (depending on how you define that dialect). If Khajidha believes "major news sources are probably going to be indistinguishable from British English" this suggests to me he doesn't spend much time reading them. Johnbod (talk) 21:52, 11 June 2021 (UTC)

Hide custom signatures for new editors

I recently wrote User:Enterprisey/signature rfc drafting. Might formally propose it at some point. All feedback welcome (here or there). Enterprisey (talk!) 22:20, 9 June 2021 (UTC)

Adding on a bit to what I wrote there, I think right now it's tricky, because we need to find an impossible balance between having readable wikitext (because talk pages are still edited in wikitext) and having enough syntax for programs to be able to tell what's a signature, so that they can do things like the variable display you're proposing. This is quite similar to the problem we have with references filling up the wikitext and the debate about list-defined references. Long-term, I hope the solution to both of these will be the same: make VisualEditor (or, in the case of talk pages, discussiontools) so effective that almost no one looks at wikitext, at which point it will be able to become as complex as needed. {{u|Sdkb}} ^talk 22:44, 9 June 2021 (UTC)

Yeah, I'm hoping the proposed syntax, or whatever people come up with, will be acceptable. If the community's position is indeed zero-tolerance for any changes, the situation looks pretty dire. Enterprisey (talk!) 22:58, 9 June 2021 (UTC)

I think it's a great idea, personally. SportingFlyer T·C 23:01, 9 June 2021 (UTC)

Excuse my ignorance, is there a wave of new editors complaining about how confusing signatures are? Is this really a problem? HighInBC ^{Need help? Just ask.} 23:03, 9 June 2021 (UTC)

Yeah, a few. Just looking at comments currently on WT:SIG, I found WT:SIG#A reader's perspective, Special:Diff/1025529507 (from the previous thread), Special:Diff/1027705784, and Special:Diff/1027480740. Unfortunately, due to survivorship bias, the lack of further examples isn't an argument for or against new editors finding signatures confusing. Enterprisey (talk!) 23:22, 9 June 2021 (UTC)

Seems like some confirmation bias there, as the only people involved in that polling are ones that had a complaint. — xaosflux ^Talk 01:12, 10 June 2021 (UTC)

I figure new editors are equally as likely to find their way to the discussion whether they did or didn't have a complaint. Sure, people who had a complaint are more motivated to share it, but surely someone without one would've seen the 4+ responses and wanted to make their side heard? Enterprisey (talk!) 03:40, 10 June 2021 (UTC)

Given that the current, WP:CENT-listed RfC at WT:SIG is currently showing an avalanche of opposition to even restricting the use of custom signatures, what is the point of even asking this? – Joe (talk) 10:18, 11 June 2021 (UTC)
This doesn't restrict their use, so it might have an easier time passing. Enterprisey (talk!) 22:40, 11 June 2021 (UTC)

Dealing with off-wiki campaigns with the power of upvotes

WP:AN#Possible new tool/technique/procedure (permalink) gave me a bad idea. The goal is dealing with the stream of visitors so that Wikipedia's operations are affected little as possible. So let's make an off-wiki page to send them to. I propose we make something that looks like Reddit, where the "posts" are either questions (for us, the editors) or edit requests. Comments can be made, and posts and comments can be voted on by visitors, in the usual way (maybe we require an account to be created, maybe we offer Google/whatever sign-in). Why, Enterprisey, why?!, you may be asking. I think a Reddit-style platform is the optimal solution to this situation: lots of incoming visitors/attention, most of it bad - so we use the wisdom of that crowd to sort the most popular items to the top, and then deal with them in a public way. The idea being people want to be heard, and hopefully they'll be satisfied with upvoting the posts they would've made instead of writing them yet again in an edit request, on our talk pages, or on articles. By way of responses, maybe Wikipedia editors can post with a special tag, or even under the name "Wikipedia" itself, and their posts could automatically sort to the top ("stickied", in Reddit terms). Yes, this is really anti-egalitarian, but our systems break down above a certain amount of load anyway (recent example: the "fifth caliph of Islam" brouhaha), and the alternative is just using page protection on everything.

Goszei suggests using a Twitter-like model instead of a Reddit-like model - actually, using Twitter itself: create a hashtag, like #WikipediaSuggest, and then people post using both that and some "incident"-specific hashtag. While this is a great idea, and addresses some of the (massive) moderation problems we'll encounter, I think people are already wise to the tactic of dumping people onto Twitter and then not responding to them. Heck, even UserVoice gets that sort of reaction these days. So I think Reddit on an original-ish site has the best chance. Enterprisey (talk!) 08:55, 6 June 2021 (UTC)

This is stark raving bonkers, and I think it could work. It’d need a lot of careful thought, but it’s far from the worst idea to deal with this issue. firefly ( t · c ) 09:10, 6 June 2021 (UTC)
Note: I mentioned this on the unofficial Wikimedia Discord server (WP:DISCORD). I was not around 8 years ago, but I was drawing from the Article Feedback Tool, which was piloted here on en.wiki in 2013. This RfC that stopped its widespread rollout is good reading ([10]). The big takeaways from the experiment were thus: (1) Vast majority of posts were not actionable (WMF reports placed this figure at 12%); and (2) Moderation of BLP violations, nonsense, etc. puts a workload on editors. It was useful as a engagement tool, however: it engaged readers, gave a voice to those who are not comfortable with editing or posting on talk, and converted some number of readers into editors (at a 2.7% registration rate, per reports).

Any proposal that can eliminate the problems of the AFT and keep the benefits would be a good one. I think just making the problems someone else's, namely Twitter's, is one way (perhaps the only way) of solving this. The moderation would be their problem, and their algorithms are crafted to sort out junk. It would also serve as an outreach and appeal to pick up editing that extends beyond Wikipedia. The suggested Reddit-model is more "controlled" than just dumping to the open sea and seeing what floats, but that control comes with a significant moderation burden. — Goszei (talk) 20:43, 6 June 2021 (UTC)

Both Q&A sites like Stack Overflow or Quora and upvote/downvote free-posting sites like Reddit have the same problem -- the more popular your topic, the more moderation you need. Neither platform solves the repost (same question) problem with upvotes -- it simply makes popular things more popular and offloads burden of filtering/removing content to moderators. And of course most popular stuff gets reposted most often to be the bane of moderators. The readers upvote goal ("I like this!") is not the same goal as Wikipedia's goal ("This improves encyclopedia!"). For example, Reddit's default view buries niche topics and it takes conscious effort to navigate to specific content. Stack Exchange style boards best work when you have a specific question in mind you can search and does not work at all for general questions. These platforms have their benefits and work for specific use cases, but I am not convinced either can improve the sort of discussions Wikipedia wants without a lot of extra off-site effort. — HELLKNOWZ ▎TALK 21:01, 6 June 2021 (UTC)
What a bold yet controversial proposal. I like how you actually went out and said we're just going to make new editors "someone else's problem" unlike most proposals that just imply it. The problem with this proposal is that it won't actually make any of this 'someone else's problem". If we just dump everyone on a subreddit or some Reddit like platform what happens is that we still have to moderate the subreddit as we've officially endorsed it and it's an extension of the Wikimedia platform. If we just decide to abdicate any responsibility for enforcing the rules I would give it around a week until it turns into /pol/ (4chan's containment board). That's if the WMF doesn't shut it down via office action. e.g. it'll just be shitposting about how our article on the holohoax is wrong and people requesting that the primary topic for the BBC be something other than the news agency. That and a bunch of Blp vios.

Then of course the media will get alerted and we'll get endless flak (which in all honesty we will completely deserve) for having this platform. At which point the WMF will step in.

Of course if we do moderate this new platform to avoid all of the /pol/ shit we've done basically nothing to address the problem beyond just shifting the workload around. :I'll paraphrase this from Ratatouille and say that the meaning of "anyone can edit" isn't that anyone can be a good editor, but that a good editor can come from anywhere. While the vast majority of new contributors aren't good we need to treat everyone with respect and give them the opportunity to be on the same level as any "established" Wikipedian, because our most important job is to find the 10% of people who actually will be good editors and keep them editing productively.

Also the fifth caliph of Islam thing isn't even our fault. That's Google and Bing's fault for having a paradigm based on surfacing anything regardless of actual accuracy. When you search for it on Wikipedia we give the right results. Chess (talk) (please use {{reply to|Chess}} on reply) 21:08, 6 June 2021 (UTC)

I think editors will still come to Wikipedia and do what they do, so I'm not sure any net benefit will be seen on Wikipedia. Also my personal preference would be for editors to be able to participate fully solely through contributions on this site, and thus I would prefer that upvoted comments on Reddit only be advisory. This would of course make Reddit less effective as a place to hold a discussion or vote, but I feel to do otherwise would give the opinions of Redditors undue weight with respect to the rest of the English Wikipedia community. isaacl (talk) 21:47, 6 June 2021 (UTC)
I like the idea. RationalWiki does have something similar, whose code may be able to be adopted. Elli (talk | contribs) 05:29, 8 June 2021 (UTC)
While I can't think of any comment on the proposal itself I will at least mention two concerns I had while reading your post:
1. "Google sign-in". Let's not entertain such a thought for even a moment, thank you. Wikipedia should be committing more to freedom and ethical technology, not less. We cannot offer people the ability to sign in with a service actively hostile to their online rights, not here on Wikipedia itself and not anywhere related to it. It's bad enough that the Wikimedia Foundation had people use [a non-libre video communication platform which shall not be named] during some sort of community discussion a while ago.
2. "Make it look like Reddit". It would be preferable not to do this. Not only could less computer-literate people get them confused, isn't it kind of promoting Reddit to make a site that looks like it? Reddit, too, is hostile to online rights.
Anyway, those are my thoughts. DesertPipeline (talk) 07:08, 15 June 2021 (UTC)

minor edits in watchlist

This is first time I am posting here so not sure whether this is the right place. I read few weeks ago that there was discussion to restrict marking "minor edits" to auto/extended confirmed user.There was no consensus. That proposal was made because many new users misuse it and the editors who have "hide minor edits" filter on watchlist are not able to see it. So I propose that a new filter be added to watchlist which shows minor edits from new users but hides minor of 30/500 users. -- Parnaval (talk) 12:26, 12 June 2021 (UTC)

(For reference, the discussion is here: Wikipedia:Village pump (proposals)/Archive 179#RfC on limiting minor edits.) It looks like there is a filter for removing all minor edits, and for removing all extended confirmed edits, on your watchlist, so this would just be about removing edits that are in the intersection of the two. I'm not sure if Wikipedia:Customizing watchlists advice gives any way that you could bodge this together yourself. I think this is quite a specific and esoteric use case and not necessarily worth the developer time it would take. We have more major watchlist issues, like not being able to watchlist a single section of a talk page, or watchlist a talk page without watchlisting the article. I'm pretty sure we got this new watchlist filter system from a Wishlist, though I can't locate which year or proposal it was from, so I would imagine this would take a lot of WMF developer time (and it takes a huge amount of community effort to get the WMF to do even the smallest development change). — Bilorv (talk) 12:12, 14 June 2021 (UTC)

@Bilorv: are you talking about the default watch list? Which specific option are you referring to for "hide extendedconfirmed" ? — xaosflux ^Talk 23:32, 14 June 2021 (UTC)

@Xaosflux: you need to re-add a ping if you miss the signature—this one didn't go through. Yeah, in the default watchlist under "Filters", you can choose which edits to view out of ones made by people who are IPs/registered/autoconfirmed/extended-confirmed. There's also a filter for hiding minor edits. But no (combination of) filter(s) that will exclude only the intersection of extended confirmed and minor edits (only the union). — Bilorv (talk) 10:34, 15 June 2021 (UTC)

@Bilorv: ah ok this is on the javascript-interface watchlist; at a quick look I'm not seeing these parameters being outputed such that a userscript could take advantage of them - so an upstream software enhancement would likely be needed here. — xaosflux ^Talk 11:01, 15 June 2021 (UTC)

That makes sense, and thanks for looking. — Bilorv (talk) 12:48, 15 June 2021 (UTC)

Article talk pages

Most article talk pages are ghost towns, filled only with assessment templates. A lot of article related discussion happens on user talk pages, wikiproject talk pages or in edit summaries instead of on the article talk page. In the rare case where people come and try to discuss actual article content on article talk pages, they tend to get ignored for years, as nobody notices their contribution to the talk page. Should we encourage people to try to find out who the actual page authors are and ping them when they try to write a new talk page post? The suggestion to do so would need to be in {{talk header}} and/or the editnotice to have any chance of being seen. Or should we try to encourage people to go to a more widely watched forum when they want to say something about an article? —Kusma (talk) 10:12, 29 May 2021 (UTC)

@Kusma: If the users never go to the talk page, then how, if I may ask, would a notice on the talk page help? 🐔 Chicdat ^{Bawk to me!} 10:42, 29 May 2021 (UTC)

@Chicdat: I am trying to solve the problem that people who have managed to use the talk page are being ignored. The alternative is to change the talk page header to discourage people who have found it from using the talk page. —Kusma (talk) 11:12, 29 May 2021 (UTC)

@Kusma: Can you give me a few talk page examples with years-old, unnoticed posts? 🐔 Chicdat ^{Bawk to me!} 11:15, 29 May 2021 (UTC)

@Chicdat: From my own contributions: Talk:Leningrad Cowboys Go America, Talk:Ursula von der Leyen (although this is an article with 1.2 million views per year, none of the talk page posts get actual discussions). Additionally, I have noticed that I don't go to article talk pages to discuss the article. I think I should have posted this at Talk:Lynching of John Carter, with a ping to Drmies and Uncle G. I posted at a user talk instead because I'm used to ignoring article talk pages. I think that is a bad habit, but it is a common habit. I am trying to propose we all use article talk pages more, and use pings to make sure the right people get notified of the discussion. —Kusma (talk) 12:05, 29 May 2021 (UTC)

@Kusma: Wow... you're right! I never noticed any of this before. The Talk: namespace really is quite inactive. Thank you for noticing this problem. 🐔 Chicdat ^{Bawk to me!} 12:08, 29 May 2021 (UTC)

Ok, so TLDR: Article talk pages are dead. Should we bury them or revive them, and if we want to revive them, should we try to use pings to do so? —Kusma (talk) 13:07, 29 May 2021 (UTC)

First, yes - I agree it's a problem. Often if something I wrote sits more than a day or two then I'll check history and go to one of the recent editors to discuss. I like the idea of notifying the original author, but I'd include the editor with the most edits as well. Also, should it be a "ping" on user talk, or just an email that someone has posted to the article talk and it hasn't been responded to in x hours, or x days? — Ched (talk) 13:25, 29 May 2021 (UTC) edited: revived implied by my response. — Ched (talk) 13:27, 29 May 2021 (UTC)

To expand a bit on the why notify the most prolific editor as well: There are a TON of articles where the original author simply isn't editing wiki anymore. Even the most prolific editor of that article may be long gone. At that point, I guess you just look at page history and try to find someone still active. (which doesn't really solve the problem, I know.) — Ched (talk) 13:33, 29 May 2021 (UTC)

The question is whether we can/should have some automation for the task of "find the people most likely to be interested in a talk page query". Could be something like "from the article statistics, check who has been active in the last month, and then take the top two of those". Once I have to personally look through the history page, it is easier to just post on a user talk page. —Kusma (talk) 14:01, 29 May 2021 (UTC)

Ummm .. ok? "Yes"? - I'm agreeing with you Kusma. The "can we" - I don't know. Sorry, I'm not familiar with the actual coding of such things. The "should we" - yes, I think so. I wasn't trying to restate anything, I was just agreeing with you. Apologies for the confusion if I wasn't able to express myself more clearly. — Ched (talk) 14:33, 29 May 2021 (UTC)

Oh, I also thought I was agreeing with you, and just tried to clarify who should be notified. :) —Kusma (talk) 14:40, 29 May 2021 (UTC)

I suspect that editor participation in talk page discussions varies greatly from article to article. I could certainly point to articles that currently have very active talk pages, and lots of people watching and replying to new comments. Others (as you have noted) have no one watching them. Blueboar (talk) 15:29, 29 May 2021 (UTC)
Kusma has identified a genuine problem here. I don't think the solution is to use user talk pages, because that excludes other interested editors from any discussion. I think we need to get better at telling people who post about specific articles on user talk pages that that is the wrong place, and the discussion should take place on the article talk page, and at encouraging people to watchlist articles that they contribute significantly to (I don't know what the default of the "add pages and files I edit to my watchlist" preference is, but I certainly have it set). I admit that I tend to respond to queries on my user talk page rather than tell people to go to the article talk page. I'll try not to do so in future to encourage good practice, but I can't guarantee to be perfect. Phil Bridger (talk) 16:33, 29 May 2021 (UTC)
I watchlist all articles I have significant contributions to, but I often don't notice edits to the talk page (there's too much other drama on my watchlist). The namespace filter helps a bit, but I would still prefer to get a ping whenever possible. —Kusma (talk) 17:18, 29 May 2021 (UTC)
I disagree. I don't think there should be any "pinging", or other features that have been only introduced to Wikipedia because of some wish to emulate "social media" sites. Then there wouldn't be any expectation that people would use them. I recently culled my watchlist from many thousands to a few hundred. I suggest that you do the same so you are not flooded with updates. Phil Bridger (talk) 18:02, 29 May 2021 (UTC)
I don't understand this comment about social media. Pings are much faster, easier and less disruptive for both sides than user talk page messages, and one of the best innovations I have seen here in a long time. —Kusma (talk) 18:29, 29 May 2021 (UTC)
@Kusma An upcoming feature in MediaWiki will let you "subscribe" to talk page sections for getting ping-like notifications on new comments (phab:T263820 - in progress). There is also a planned feature for enabling notifications when new sections are added (phab:T263821 - not yet prioritised). The tracking ticket is phab:T273920. – SD0001 (talk) 19:13, 29 May 2021 (UTC)
That's great, especially phab:T263821. If this gets implemented (and widely used), it would provide another approach to solve the problem I describe. Thank you for telling me about this! —Kusma (talk) 19:27, 29 May 2021 (UTC)
hi @Kusma . @Whatamidoing (WMF) alerted me of this conversation. It sounds like we – the Editing Team and you all in this conversation – share an interest in exploring changes that could encourage people to discuss edits to a given article in places where, as @Phil Bridger noted above, increase the likelihood that other interested editors will see, and potentially participate in.

With the above in mind, a couple of questions for you all:
As @SD0001 mentioned, the Editing Team is actively working on new functionality to help people increase their awareness of activity in conversations they deem interesting by enabling them to elect to be notified when new comments are posted in the specific section(s) they subscribe to. Would you all be up for trying an early version of this feature when it's available in the next couple of weeks and sharing what you think of it?

@Kusma, in this comment, you entered the idea of the interface doing more to suggest to people starting a new discussion topic on a talk page who they might consider pinging about said discussion topic. This intersects with functionality we've been thinking about and leads me to wonder: what do you see as the risks of assuming that people who have participated in a conversation on a particle article's talk page at some point in the past would be interested to know about a new conversation that is started on said article's talk page?

And by the way, I'm Peter! I work as the product manager for the Editing Team. Right now, we're focused on the Talk pages project. PPelberg (WMF) (talk) 01:15, 11 June 2021 (UTC)
Hi Peter, nice to meet you! It's a difficult question, as you need to make sure that people don't get so many pings that they start turning Echo off. For active talk pages (more than 10 people editing in the last 6 months, numbers pulled out of a hat), I'd oppose such a notification as I think they could quickly become overwhelming to the Echo system. For less active talk pages, the issue is whether any of the relevant people have even used the talk page. From my own articles, let's look at Story in Taipei. I may be the only person aware of this article with subject matter knowledge, but the talk page gives zero indication of that. Other conversations may be invisible in the wikitext. Consider Talk:A Voyage Round the World, which tells you that you could ask me or possibly my GA reviewer a question, but the wikitext doesn't show it. Or Talk:1773 Phipps expedition towards the North Pole. Sometimes the people who have used the talk page are people who ask questions about the article topic, and not people who can answer such questions. I'm very happy that devs are looking at the issue, but I don't see any super easy solutions, especially not easy technical ones; anything good would need to be combined with some social change. —Kusma (talk) 10:45, 11 June 2021 (UTC)
This context is helpful, @Kusma – I appreciate you sharing it.

It sounds like you are raising two points we need to consider in the context of T277357 :
Changes that could lead people to receive more pings, the flow of which they cannot manage/control, is risky

People who have commented on article talk pages are not necessarily people who are equipped to answer questions about said articles

I may be the only person aware of this article with subject matter knowledge, but the talk page gives zero indication of that.

Great point and well put. I've created a T285068 to think about what approaches we could take to making it more clear which other editors might be capable and motivated to answer questions about a particular article. PPelberg (WMF) (talk) 21:46, 16 June 2021 (UTC)

Oh and @Kusma, would you be interested in experimenting with the new functionality (see: T273920) and sharing what you think about it once it's ready in the next couple of weeks? PPelberg (WMF) (talk) 21:47, 16 June 2021 (UTC)
@PPelberg (WMF): I am generally interested to try out and experiment with these features. One warning against my ideas above is that just directing people's questions to one "main author" could encourage wrong ideas about ownership. See deleted Template:Maintained and its TfD discussion for some community thoughts on the issue. —Kusma (talk) 22:13, 16 June 2021 (UTC)
I am generally interested to try out and experiment with these features.

Excellent. I will comment here when they are ready for testing.

One warning against my ideas above is that just directing people's questions to one "main author" could encourage wrong ideas about ownership.

Mmm. I'm glad you brought my attention to this TfD discussion this discussion; it's the first time I've come across it. I've added links to it to T285068 to ensure we've fully understood the consensus, and considerations raised within it, before we move forward with an approach.

Note: I do not imagine the team will have room to work on in the next couple of months. I share this to ensure we have shared expectations about when/if this work would begin. PPelberg (WMF) (talk) 23:58, 16 June 2021 (UTC)

The existence of such a feature leads people to believe that they can ignore everything that doesn't use it, with the consequence being the problem that you have identified. And I thought that my reference to social media was pretty self-explanatory. Phil Bridger (talk) 19:46, 29 May 2021 (UTC)

Radical reform of DYK

I start from the premise that, from a reader-perspective, WP:DYK is fundamentally broken, in that very many of the entries on it are just plain boring. I'm thinking about starting a proposal to have us conduct a trial in which we eliminate all the eligibility requirements and instead allow facts from any page to be nominated but require !voting on all proposals such that only the ones judged most interesting get selected.

I anticipate that this would draw quite a bit of opposition just by virtue of being such a radical departure from the status quo. Per the idea lab's instructions, I'm not looking for supports/opposes here, but I would like to get a bit of a sense of just how likely this would be to get snowed and if there's any way I could set it up that might reduce the chances of that or more generally any big considerations I should have in mind. Cheers, {{u|Sdkb}} ^talk 07:24, 4 June 2021 (UTC)

The real question is what the goal of DYK is and should be. Is it supposed to be fun and exciting to read? Then why limit to new articles, the vast majority of which is about obscure topics? From a reader's short term perspective, why should it be on the Main Page at all?

What I like about DYK is that it encourages new articles to be of a decent standard. Which is useful for readers, and more so than reading the articles while they are on the Main Page.

Anyway, back to your idea: I don't really see voting as a viable way out unless there is massive participation. And DYK is already quite process heavy, so perhaps we would need to reduce complexity elsewhere. —Kusma (talk) 07:59, 4 June 2021 (UTC)

For me the purpose has always been to casually highlight some of our more obscure articles of non-FA quality for readers and editors alike by making use of a specific style form (DYK) which might spike their interest. I never understood why we limited it to new articles. —TheDJ (talk • contribs) 10:01, 4 June 2021 (UTC)

We don't quite limit to new articles: 5x expansions (so stub->real article) and freshly promoted Good Articles are also eligible. —Kusma (talk) 15:38, 4 June 2021 (UTC)

DYK in its current form definitely fills a role as an editor incentive. It's a little hard to balance that against readers losing out on more interesting hooks. Part of what appeals to me about a trial is that it'd allow us to be more clear-eyed about what the tradeoff is. If we see hooks getting significantly more pageviews, we'll know that's a possibility; same with the converse. {{u|Sdkb}} ^talk 15:39, 4 June 2021 (UTC)

I think we should consider clearly what we want. Should all hooks appeal to everyone? [I think that rules out too many subject areas.] Or is it OK that there are some articles about topics of limited appeal (Latvian mariachi band conventions, extinct amoebae, Peruvian radio stations) in the mix? We have some diversity criteria for prep builders that make sure we don't have eight buildings in New York or eight Catholic hymns or eight politicians on at the same time. If that isn't enough to find two or three interesting ones every day, maybe we need to recruit more nominators with more mainstream interests. —Kusma (talk) 15:51, 4 June 2021 (UTC)

I'm not sure I buy that there's that strong of an inverse relationship between obscurity and interestingness. Much of the appeal of Wikipedia as a place for entertainment comes precisely from the fact that it contains so much on obscure topics, and several of the top DYKs of all time are on quite obscure topics. {{u|Sdkb}} ^talk 16:40, 4 June 2021 (UTC)

I agree that many entries are boring. My reaction to most of the hooks is "so what?" The satisfaction of editors should be in creating something that is exciting for readers, rather than in the mere fact of "their" creation being on the main page. Many subjects are simply boring, so however well-written the articles they shouldn't qualify for this section. Phil Bridger (talk) 08:27, 4 June 2021 (UTC)

If I can tell from the hook that an article is about a boring topic like baseball or cricket, I just ignore it, no matter how interesting the hook sounds. But a lot of people will care and actually enjoy the very same article. I guess we need some variety. —Kusma (talk) 09:07, 4 June 2021 (UTC)

Kusma, almost all of my hooks have been about historic buildings in Scotland. A niche interest perhaps, but they mostly garner 5-10,000 views - I like to think that some of the readers must have found a few of them interesting... GirthSummit _(blether) 16:06, 4 June 2021 (UTC)

The point is not whether the general topic interests a particular person, but whether the hook is interesting. For example yesterday's hooks included "... that concert pianist, composer, and opera librettist Leonard Liebling was the editor-in-chief of the Musical Courier from 1911 to 1945?" and "... that the principal of Big Tree Elementary read a book from a hot-air balloon to honor her students for having collectively read more than 2.5 million minutes in 2006?". Isn't it obvious which would be the more interesting hook to over 99% of our readership? That is true for me even though I happen to be more interested in reading about Leonard Liebling than Big Tree Elementary. Surely someone had to be editor of a published journal, so that hook is very definitely a "so what?". Phil Bridger (talk) 18:40, 4 June 2021 (UTC)

Yep, this. The fact that hooks like the Liebling one aren't being insta-rejected illustrates just how low our standards are. No other fun fact list on the internet would look themselves in the mirror after publishing that. And readers can seek out any other list they want. We can't compete when we're tying our hands behind our back by limiting our scope to new content, which is why I think we need to consider removing the eligibility requirements, even if it totally upends the way DYK has traditionally worked. {{u|Sdkb}} ^talk 19:20, 4 June 2021 (UTC)

There's two things I'd like to say here: (a) DYK currently has more submissions than people are happy about (many would prefer DYK to update only once in 24 hours, not once in 12) so widening eligibility may not be necessary and (b) why should we compete with fun fact lists elsewhere? What's in it for us if we try to do that? —Kusma (talk) 19:36, 4 June 2021 (UTC)

Well, as Wikipedians I think we want people to read Wikipedia, which includes our Main Page. And if so, that means we have to compete for their attention, which means competing against other places they might go instead to find trivia facts. In the sense I mean it, it's not really a choice, it's something we're already doing and have to do if we continue having DYK. {{u|Sdkb}} ^talk 21:27, 4 June 2021 (UTC)

It comes down to what are the primary goals people feel should be met by Did you know? Going by what others have said, learning trivia might not have consensus support. On a related note, I once engaged in discussion about having featured content on the main page with an editor who couldn't understand why I was raising goals from a reader's perspective. To them, the primary objective was to act as an editor incentive. I agree though that in addition to thinking about editor goals, we ought to consider the value to readers for items on the main page. isaacl (talk) 22:05, 4 June 2021 (UTC)

This. Infinity times THIS. A hook that combines "Music dude does music stuff" and "published journal has editor" is boring. If the editor of the music journal was an auto mechanic or if this noted musician edited a science fiction magazine, that would be interesting. --Khajidha (talk) 12:39, 7 June 2021 (UTC)

"The internet encyclopedia distinguishes itself from other web resources because it strives only to include information from reliable journalistic sources. That’s the value of the project: sticking to its own boring processes even if it means the encyclopedia version is less dramatic than the tabloids." - Stephen Harrison, Slate Gråbergs Gråa Sång (talk) 09:53, 4 June 2021 (UTC)

I take a similar view to Kusma above - what I like about DYK in its current form is that it celebrates content-creation. It encourages editors to write new articles up to a decent standard, and it gets others to come along and review, copy edit, tweak those articles. Newer editors can learn a lot by watching the changes experienced reviewers make in the short time their creation is in the preps and queues. I think that kind of encouragement can only be a good thing, both for editors, and for readers who benefit from the new, decent-quality articles. Whether the DYK hooks themselves are of much benefit to the reader is a slightly different question, but the difference between boring and fascinating is very subjective. I've clicked on a few DYKs and thought 'so what?', but they probably made other people think 'wow, really?' or 'cool - I didn't know that'. Tens of thousands of people click on our hooks every day - are those numbers declining, indicating that regular readers are losing interest in them because they find they're usually boring? I'm also slightly worried that by raising the bar on how interesting/surprising a hook has to be, we might be encouraging sensationalist writing, which we don't want. (Also: Change? Argh, I fear change!) GirthSummit _(blether) 10:21, 4 June 2021 (UTC)

That's a very good point about encouraging sensationalist writing. {{u|Sdkb}} ^talk 15:40, 4 June 2021 (UTC)

If the chief complaint is the OP's personal interest in the hooks (they describe them as "boring"), then this is a non-issue for me. We have no way of knowing what excites the OP and why a particular DYK blurb may or may not bore them, but changing around the entire section just to entertain one person seems like an unwise thing to do. Furthermore, being "not boring" doesn't seem like a particular goal of DYK. The section is supposed to highlight the fact that Wikipedia is being constantly updated and expanded by directing readers to the newest such expansions. While I do believe that we should do our best to find the most interesting thing to say about an article once it is eligible for DYK, the blurb itself is of secondary concern to me. I am more interested that the article is new or recently expanded; the blurb is entirely incidental. If you can write an interesting hook, then go for it. But if the expanded text doesn't contain anything that someone finds interesting (again, where "interesting" can only be a personal preference, and that there is nothing objective or universal around what one person may or may not find interesting), then whatever, that should NOT be a disqualifying thing from appearing in DYK. If we reform DYK, in my mind, it's that we widen and allow more blurbs through, not less. --Jayron 32 16:02, 4 June 2021 (UTC)
99% of readers have absolutely no clue that DYK is limited to new/recently expanded articles, so I have to strongly disagree with you that it somehow highlights for them that Wikipedia is being expanded/updated. I also think the fact that DYK hooks have a severe interestingness issue is utterly self-evident; Goszei mentioned the other day on WP:Discord that it's something they've heard non-editors say. We can sometimes be so deep in the weeds that our sight becomes blinkered; let's try to rise above that. {{u|Sdkb}} ^talk 16:19, 4 June 2021 (UTC)
Sdkb, wouldn't the answer to that be to have a short snippet of text on the main page explaining that? 'Did you know... a few interesting facts from recently written or expanded articles'. Or something like that. And FWIW, I just surveyed today's DYK, and found four hooks that I would want to click on because they look interesting, and four that I thought I wouldn't bother because they look boring. That's not a bad hit rate, in my view; I can't see how we could expect to make them all interesting to the same person, unless we were trying to cater to a very homogenous audience. GirthSummit _(blether) 16:27, 4 June 2021 (UTC)

Once upon a time, under "Did you know . . ." it used to say, "From Wikipedia's newest articles:". It would solve the problem that Sdkb points out above if we reinstated that or similar language, such as, "From Wikipedia's new and recently expanded articles:". ~ ONUnicorn^{(Talk|Contribs)}problem solving 16:31, 4 June 2021 (UTC)
What was the reasoning for removing it in the first place? IMO "newest content" might be more parsimonious, including both new articles and new content added to old ones. And my view of the boringness is about the same Girth Summit, right now there are only 3 hooks I don't personally find particularly interesting and even then none of them strike me as obviously tedious. —Nizolan ^{(talk · c.)} 18:39, 4 June 2021 (UTC)
In 2015 someone mentioned that having that line directly below "Did you know..." before the hooks interrupted the flow of the sentence. They wanted to move it to the bottom. A discussion on the DYK talk page settled on replacing that clause with a link at the bottom that read, "Recently improved articles". I don't know when or why that link got removed, but at present it seems to have been replaced by the archive link. ~ ONUnicorn^{(Talk|Contribs)}problem solving 22:48, 4 June 2021 (UTC)
I think reinstating that line would definitely be an improvement over the status quo. I'm not sure it'd do to solve the interestingness problem we're considering here, but I'd love to see a separate discussion proposing to bring it back. {{u|Sdkb}} ^talk 23:54, 4 June 2021 (UTC)
Absolutely we should restore the explanatory text, in fact I brought up this very issue at WT:DYK just a week or two ago, I believe it's essential that readers understand what the DYK section represents. Gatoclass (talk) 03:28, 8 June 2021 (UTC)
One other half-baked idea to make DYK more interesting would be to discard noms that are so boring that nobody has reviewed them in a month or that haven't been promoted to queue for a month. But I'm not sure how unhappy that would make people. —Kusma (talk) 16:04, 4 June 2021 (UTC)
Kusma, I actually don't think that's a bad idea. If a nom has been hanging around for a month and nobody has reviewed it, it's probably because (a) the hook is boring, but nobody wants to be mean enough to say so, or (b) the article is long and boring, and nobody can be arsed to review it properly. Either way, it should probably be allowed to fall off the edge of the conveyor belt after a certain period, and a month feels like the right sort of ballpark to me. GirthSummit _(blether) 18:18, 4 June 2021 (UTC)
That is just a guess. I think it is equally likely that many reviewers look for DYKs that they think would be easiest/quickest to review just to get a QPQ credit for their own hook. MB 17:09, 7 June 2021 (UTC)
We could also allow reviewed noms to time out, moving the pocket veto from reviewers to prep builders. —Kusma (talk) 17:40, 7 June 2021 (UTC)
I think we're slowly getting to a point where most "interesting" topics have already been written about. I'm not saying we're running out of topics at all - I'm basing this on new page/AfC patrolling. I haven't really noticed DYK getting "more boring" but I have noticed there's a lot of hooks which don't adequately describe why someone is notable. For instance, there's one on the front page right now: ... that Richard Hatherill survived a mutiny and a shipwreck, only to die from an illness at the age of 35? That's all good and fine, but who the hell is Richard Hatherill anyways? (It doesn't help that article has only one source which looks to paraphrase the three sentences I have access to.) I've noticed a couple of these recently, and I think this is a fixable problem. I'm not entirely sure DYK needs a re-think, but I'd be open to listening to a proposal to change it. SportingFlyer T·C 18:34, 4 June 2021 (UTC)
I'm not sure that we're running out of interesting topics per se—Wikipedia's still very skewed to the kinds of things Wikipedia editors like writing about and there are huge gaps in coverage of certain fields with plenty of interesting things to say about them (my IRL research field of history of political thought is one of them), not to mention huge swathes of non-Western history. But I do agree that hooks ought to give some basic degree of detail introducing the things they're talking about where it's not otherwise obvious. That was one thing I looked out for in my brief spells reviewing at DYK in the past. —Nizolan ^{(talk · c.)} 18:49, 4 June 2021 (UTC)
That's true - there's lots of notable topics we haven't touched yet. My argument's that the easy ones have been done. But this is all a tangent. SportingFlyer T·C 21:57, 4 June 2021 (UTC)
I'm still constantly amazed how many things we don't have articles about yet (including reasonably easy ones where free sources in English exist). Anyway, I'm not sure that the availability of topics really affects DYK much. Look through the archives of Wikipedia:Recent additions. Was DYK more interesting 15 years ago, when not everything was written? —Kusma (talk) 22:51, 4 June 2021 (UTC)

The function, as per WP:DYK, is to showcase new or expanded articles. It is, as Jayron put it, supposed to highlight the fact that Wikipedia is being constantly updated and expanded by directing readers to the newest such expansions. It is also, practically speaking, a motivator for contributors. When I work with a newbie on a new article, the DYK process is always intimidating but when it finally gets to be the main page that feeling of "look at what I did!" is extremely powerful. For people who contribute because they want to have an impact on the world by contributing to a free knowledge resource, the spike in readership reassures them that yes, people are indeed reading what you're writing. It's a big deal to be on the main page.
...But, I think Sdkb has a good point that by framing it simply as "Did You Know," we're priming readers to expect a list of weird, wild, interesting, and exciting facts from across Wikipedia. Maybe adding a line contextualizing the section would help, but it seems at least worth talking about other options.
What I think is not going to work well is to try to write rules which seek to accomplish the goals of DYK but attempt to qualify what is/isn't interesting. We risk marginalizing whole topic areas, and invite endless culturally relative debates over what is/isn't "interesting enough."
In the end, I think a main page section dedicated to new/newly expanded content is important, but there are possibilities to clarify/contextualize or even, I don't know, splitting that main page real estate into two sections or something. — Rhododendrites ^talk \\ 22:05, 4 June 2021 (UTC)

Rhododendrites nailed it. I am ambivalent on the re-addition of a "from Wikipedia's recently created or expanded articles" tagline, but I am curious where the community stands. That tagline itself may be a good "hook" for the others, or even an interesting meta-"did you know". — Goszei (talk) 02:44, 7 June 2021 (UTC)
I think adding a from Wikipedia's recently created or expanded articles tagline to contextualise DYK is a fantastic solution with zero downside. firefly ( t · c ) 10:51, 7 June 2021 (UTC)

The last slot in DYK should always be "...that the above facts were taken from Wikipedia's recently created or expanded articles?", with "recently created or expanded articles" linking to the description of how to nominate an article for DYK. --Khajidha (talk) 12:36, 7 June 2021 (UTC)

@Firefly: Clarifying the scope of the DYK section is great. The downside is that a tagline (or Khajidha's idea of a final DYK) will take Main Space screen estate, which isn't as infinite as it may look. Going from 8 to 7 DYKs might be part of such a change. I guess it's worth it, but others might disagree. —Kusma (talk) 12:46, 7 June 2021 (UTC)

The only problem with "Main Space screen estate" is that we have chosen to give this one page a two-column layout unlike any other page on the site. This forces us to add and subtract items from various sections to maintain "balance". Which everyone complains about, but it seems that most of them find the obvious answer of "make the **** thing a single column and the problem goes away" even more objectionable. --Khajidha (talk) 13:07, 7 June 2021 (UTC)

@Kusma: I've had a go at including the explanation without affecting anything else. It's a crude first-approximation, so please only take it as proof that it's possible and nothing more! :) firefly ( t · c ) 13:15, 7 June 2021 (UTC)

Thanks @Firefly! The small font size might not fly for accessibility reasons, but perhaps we can merge this with some of the links. Here's a variation that integrates the links into what @Khajidha said:

... that these facts are from recently created or expanded articles, and that you can start or nominate your own?

Or something like that? —Kusma (talk) 13:36, 7 June 2021 (UTC)

@Kusma: That's far better than my attempt from an accessibility standpoint, although we may get pushback on the grounds that it breaks consistency with other sections of the Main Page. I've added your idea into my sandbox so we can all see what it could look like in practice. firefly ( t · c ) 13:44, 7 June 2021 (UTC)

Might still need some fine tuning (tried an alternative, not yet convinced), but it should be possible to get this to work. —Kusma (talk) 16:31, 7 June 2021 (UTC)

FWIW Kusma, feel free to use the sandbox I linked to experiment if you wish. firefly ( t · c ) 12:19, 8 June 2021 (UTC)

Oppose It's the premise that is broken. DYK is not boring; it's one of the most interesting sections on the main page. Consider the alternatives:

FA – this usually goes on at length about a niche topic such as Interstate 69 in Michigan – today's conversation stopper. DYK is better because it is more varied, briefer and more focussed on being hooky.
ITN – this is usually quite stale with up to a week or more between new blurbs, whereas DYK is much more productive, running 8–16 new items every day. And the ITN blurbs focus on a narrow slice of what's actually in the news and seem utterly obsessed by death
OTD – a tired format with the same stuff recycling year after year
FL – the poor man's FA
FP – the pictures are often quite good but the attached blurbs are usually dire

And then there's all the main page boilerplate – dozens of links and slogans which may be useful but are hardly exciting

But, in any case, Wikipedia is an encyclopedia not a comedy, drama or thriller and so our readership will be expecting the content to have a comparatively educational tone – "worthy but dull". If you find it boring then you've come to the wrong place.

Andrew🐉(talk) 16:13, 7 June 2021 (UTC)

@Andrew Davidson, per both my initial post and the idea lab rules, please do not !vote here. Regarding your comment, the other sections of the main page each have their own issues, most of which have been discussed at length in other places. They are beyond the scope of this discussion, though; let's try to stay somewhat focused. {{u|Sdkb}} ^talk 18:09, 7 June 2021 (UTC)

So, the OP doesn't want !votes on their proposal to introduce !votes to DYK. WP:SAUCE!

And the other main sections are relevant because they demonstrate what happens when you have a peanut gallery of !voters. ITN is quite broken because it works in that way and so most nominations get shot down. The only part of ITN that is as productive as DYK is RD and that's because it was reformed to eliminate opinionated !votes about the worthiness of the subjects.

Andrew🐉(talk) 08:38, 9 June 2021 (UTC)

No idea what you're talking about. The entire point of the idea lab is discuss ideas, not vote on them, how much more explanation do you need? Aza24 (talk) 22:27, 9 June 2021 (UTC)

I agree with all the points made by Andrew Davidson. DYK is for new articles that are accessible to read, which makes it better than most content on the front page. "Interesting hooks" are totlly subjective, and if you don't like a couple of hooks, don't read them. It seems like Sdkb is trying to ignore all the valid points made above by wikilawyering over the use of the word oppose, instead of actually replying to any of the comparison to much worse front page content. I cannot for example remeeber the last time I ever read a FA/FL on front page, as they're too long and too niche topics. On the other hand, DYK reviewers are encouraged to make hooks accessible to a broad audience, which mostly they do. Joseph2302 (talk) 08:42, 10 June 2021 (UTC)

I don't think I like this proposal. DYK is a place that motivates editors, particularly new ones that want to have their work seen by more readers. If hooks are boring, I would like the reviewer or promoter to suggest ALT hooks. I am also in favour of increasing the 1500 minimum word count for DYK articles, as this will generate more text and possibly provide better hooks. I am concerned that "Allowing facts from any page" to be nominated will cause DYK to highlight popular articles instead of a diverse set of topics, as those are the articles that are frequented the most by readers and editors. If this idea was implemented, I would like a new rule set to be established for the trial run so that articles with tags, source problems, or have already been featured on DYK within the past few years are not eligible. I like the above conversation to add a sentence about what DYK is, and encourage more editors to get involved. Z1720 (talk) 00:00, 8 June 2021 (UTC)

Comment As the creator of the Leonard Liebling article, I find it a little disheartening to read that others think my hook is so boring that it's the prototypical example of what's wrong about DYK. Personally I thought it was interesting, simply because of the variety of different things mentioned in the hook. Concert pianist, opera librettist, composer, and music editor of of an important music publication for a long time. That's a highly varied skill set that is unusual, and I think its interesting no matter what other's say here. In the end, this sort of discussion is highlighting personal taste and personal opinion about what's entertaining to you personally, which is ultimately subjective. My personal opinion is DYK is working just fine as it is, and serves a useful purpose in encouraging positive editing. If it ain't broke, don't fix it.4meter4 (talk) 00:02, 8 June 2021 (UTC)

DYK has always been rather subjective, and what could be interesting to a nominator may not be so to others, or even vice-versa. To be frank, I sometimes think that there are times when a hook is just simply not going to raise much interest outside of a small niche, but the regulars, whether out of politeness or another reason, decline to reject the hook or propose alternatives. There are also cases where hooks are clearly flawed but nominators are insistent on them in spite of consensus against, which given how it's more often than not led to problems, is another issue that is worth considering. Narutolovehinata5 ^tccsdnew 00:15, 8 June 2021 (UTC)

As a contributor to DYK for years, my experience is reviewers are usually pretty objective, and the DYK rules for review provide enough structure to keep things that way. Frankly, the suggestions here are arguing for a greater degree of subjectivity than currently exists by encouraging editors to express their own biases about what’s interesting and allowing majority votes to determine content. Inevitably such a system will end up marginalizing certain kinds of content (particularly with a predominantly white straight male voting base doing the voting). I am not for creating a systemically unjust and unfair process, which the suggestions here will do. It will also create more work and more opportunities for conflict and stress. It doesn’t sound like an appealing change to me.4meter4 (talk) 02:03, 8 June 2021 (UTC)

The bias concern is something we'd certainly want to look out for, but we have no way of knowing whether or not it'd be much of an issue when we aren't even willing to run a trial. ITN operates with a very similar !voting system, and despite the perennial complaints from both ends, it seems to do okay at least in terms of globalizing its coverage. A cultural mindset of "don't just !vote yes on the video games hook just since you personally like video games" might be enough to minimize problems. And it's certainly not as if our current system is free of bias—it's heavily weighted toward subject areas that produce lots of pages and that have editors willing to make nominations. {{u|Sdkb}} ^talk 02:36, 8 June 2021 (UTC)

Actually we do have a way of knowing. Much has already been written about systemic white male heterosexual bias on Wikipedia that is based in research with data. Google it. Creating a voting system at DYK which further empowers the white male straight editing majority is not a solution. There’s absolutely no way that you can reasonably argue that a voting body made up of predominantly straight white men aren’t going to have their point of view dominate in a voting system. That’s codifying bias into our process. As for current issues, yes we do have biases towards western topics in our nominations and we ignore women. As a member of WikiProject Women in Red, I spend most of my time creating articles on women to help solve that. We can’t help what gets nominated, because this is a volunteer project, but we can create a system that isn’t going to shut out minority content. 4meter4 (talk) 02:45, 8 June 2021 (UTC)

Well there's an easy solution to that, which is for all the non–whitemaleheterosexuals to get off their asses and vote. I'm one myself so I know it can be done. E Eng 20:56, 10 June 2021 (UTC)

Sorry, I've been around this block so many times I'm not going to invest the time reading all the above in the hopes DYK will really change, but I'll repeat stuff stuff I've been saying for years:

The oft-repeated trope that "DYK's job is to highlight new articles" is bankrupt. Somewhere in the early days of WP someone said, "Hey kids, wouldn't it be fun if we gave a prize for new articles? That would really motivate people!" So they did that. It's not at all apparent that this is a good idea, or is the thing that really needs motivating, or what.
By continuing with the "new article" fetish we constantly, CONSTANTLY put in front of our readers our least developed, least impressive content -- often embarrassingly so. I used to think a new article's appearance on DYK would draw in new editors seeing an opportunity to improve all this inchoate junk, but I can recall that ever happening. As for encouraging and rewarding new editors, I'd like to see statistics on what proportion of DYKs are by first-timers -- I'm pretty sure it's shockingly small.
We should be running 1/4 to 1/3 as many hooks, of much higher quality -- quality of the article and quality of the hook.
- Instead of new articles, DYK should run GAs (only -- no "new" articles just because they're new). Imagine if all the DYK effort were directed at bringing articles to GA instead creating of these (mostly) mediocre to poor almost-stubs. If someone says that not getting a DYK credit means they're not going to bother creating new articles, then tough. (I get pleasure in seeing an article I've created at DYK, but that's not the reason I create articles.)
- By hook quality I mean interestingness, and the way to determine that is by voting: merciless ILIKEIT/IDONTLIKEIT voting, five highest vote-getters win, losers go back in the barrel and get, say, three more chances to win a day's vote. Arguments like, "Well, what interests those participating in DYK might not be representative of what interests our readers" are stupid. Right now we run whatever just a single editor (the nominator) thinks is interesting -- nominations are never rejected because there's no hook interesting enough; almost anything is better than that. We can only do the best we can do, and the best we can do is decide among ourselves what will best serve our readers. That's what we do in every editorial decision we make; in most cases it's by reasoned discussion and consensus, but hook interestingness is a gut feeling, so for that straight voting is better.

E Eng 02:57, 8 June 2021 (UTC)

As I've said to you many times before EEng, adopting your proposal would (a) add a great deal of overhead to the process, (b) mean that far fewer hooks get featured so there is less new content for readers to engage with on the main page on a daily basis, (c) disenfranchise most DYK contributors, and (d) in all likelihood, lead at best to a marginal overall improvement in hook quality. It just isn't viable in my view. Gatoclass (talk) 03:54, 8 June 2021 (UTC)

add a great deal of overhead – No, voting is fast and easy. And reviews and stuff will take place only on articles whose hooks win the vote -- 1/3 of the number of hooks running now -- so obviously that's a gigantic net savings in work.
far fewer hooks get featured – That's the idea.
less new content – That's also the idea: not new content anymore, but rather content of reasonably good quality i.e. GAs.
disenfranchise most DYK contributor – No, everyone can vote.
marginal overall improvement – 1/3 the hooks, drawn from GAs instead of random new stubs, would be a BIG improvement.

E Eng 04:40, 8 June 2021 (UTC)

Firstly, when I said "disenfranchisement", I was referring to the reduced number of users who would actually get their articles featured on the main page under your system. Nobody cares about the number of times they get to vote on somebody else's nominations. Secondly, the notion that confining DYK nominations to GAs would somehow improve the overall standard of DYK hooks is a fantasy. Common sense alone should tell you that reducing the overall number of nominations would correspondingly reduce the total pool of hooks and therefore the overall hook standard. There is no correlation between the size or quality of an article and the quality of its associated hook. Gatoclass (talk) 05:10, 8 June 2021 (UTC)

reduced number of users who would actually get their articles featured on the main page – So what? This isn't the Special Olympics, where everyone gets a trophy. Fewer editors' work should be on the main page because relatively few editors' work is worthy of the main page.
reducing the overall number of nominations would correspondingly reduce the total pool of hooks – Sure, but from that smaller pool we'll be drawing proportionately fewer hooks (or, ideally, more than proportionately fewer). GAs contain more information than our current DYK candidates -- new articles -- so contain more potential hook material.
improve the overall standard of DYK hooks – I should have been clearer that the aim is to improve the quality both of hooks (which means their interestingness) and of the articles the reader sees when he clicks.

There are really three independent proposals here: run fewer hooks, so you can skim the best off the top and leave the dregs in the barrel; use voting to determine which we deem best; improve the quality of the articles run by running GAs instead of stubs aborning. These three proposals can be adopted, or not, pretty much independently. E Eng 12:35, 8 June 2021 (UTC)

I don't hate the idea of voting on hooks, but like 4meter4 I am very concerned about white & male bias in such voting. Also, right now we allow up to half of hooks to be US-related. If we go to a voting format, are we going to end up with the kinds of arguments we see at ITN over that, with pointy votes that appear to be motivated by making sure we don't have "too much" coverage of the US? —valereee (talk) 11:33, 10 June 2021 (UTC)

DYK does not need "radical reform" so much as it needs to enforce a rule already in place — hooks must be "interesting to a broad audience". Reviewers just need to put their feet down and refuse to approve hooks that fail this criterion, just as they would refuse hooks that are unverified or taken from stubs. – Teratix ₵ 09:30, 8 June 2021 (UTC)

Pretty much this. While DYK is subjective, there is a line between a hook that would catch the attention of even people unfamiliar with the subject matter, and one that only appeals to a small niche. It's not uncommon for it to happen that a hook was approved because the reviewer didn't have the drive to decline what was clearly an unsuitable hook, and perhaps addressing this would help address complaints about DYK. As for the concerns above about DYK having certain biases, that has more to do with the makeup of DYK's regulars rather than the structure of DYK itself. Remember that DYK is a volunteer effort, it's not compulsory, so the articles featured are at the mercy of the editors who nominate. And while I would absolutely support broader representation of articles on DYK, lowering our standards probably isn't the way to go, but perhaps there are other ways to encourage outside contributions instead. Narutolovehinata5 ^tccsdnew 10:26, 8 June 2021 (UTC)

I have rejected hooks I felt boring, both as a direct reviewer and while scanning the approved list. However, it's very hard to establish some sort of enforceable standard to hold reviewers to account on. There has never even been agreement among DYK regulars about what makes a hook interesting, and all hooks go through at least 3 gates, so presumably someone somewhere in the chain found them interesting. CMD (talk) 10:37, 8 June 2021 (UTC)

People are encouraged to review the oldest noms or to promote the older accepted noms, though. We'd need to stop doing that to strengthen any gatekeeping effect, and just discard anything that has not seen action in a month. Currently I think anyone with a rules-compliant article can more or less expect that it will hit the Main Page at some point. —Kusma (talk) 12:49, 8 June 2021 (UTC)

In my experience, the oldest noms typically take longer because they're controversial or otherwise tricky, not since they're especially boring. {{u|Sdkb}} ^talk 16:06, 8 June 2021 (UTC)

Although this post is partly in response to EEng, I'll put it here as the discussion has moved on a tad.

The first point to make is that it's a fantasy to imagine that one is going to get a substantially higher quality of hooks by having !votes on every nomination. Apart from the sheer impracticality of trying to do that given the number of nominations, there are actually very few real standout hooks. EEng talks about reducing the number of featured hooks to a third or a quarter of the current number, but one in three or one in four hooks are not noticeably better than the rest. If you look at either nominations page on any given day, you might find 5 or 6 standout hooks out of a hundred or more, if you are lucky. That's more like cutting the number of featured hooks to one in 20 or less. This doesn't mean that the vast majority of hooks are not up to scratch, it just means that you are not going to get Ripley's Believe-It-Or-Not-level hooks without really radical nomination pruning, and probably not even then.

The problem then as I see it, is not so much one of radical reduction, since most hooks are of an acceptable standard, it is rather how to eliminate that relatively small number of hooks that are substandard. It would surely be considerably easier to create a process for doing that than to try and evaluate every single nomination by consensus. One might, for example, have a regime where any user can flag a hook as substandard. There would then be some sort of process for trying to improve on the hook or replace it, and perhaps a small permanent panel to make a final judgement. It would surely be a lot simpler than some of the proposed alternatives above. Ultimately though, there is no substitute for engagement. If you think a hook is not up to scratch, tweak it, propose an alternative, or start a discussion about it. A substandard hook can only make it to the main page because nobody along the way saw fit to challenge it. Gatoclass (talk) 13:51, 8 June 2021 (UTC)

!votes on every nomination – I'm not proposing a separate vote on each nomination. I'm proposing that each nominator come up with the best hook he can for the article he's nominating; these all go into a pool. Each day, 20 hooks are randomly selected from this pool and listed, and everyone gets to vote for the 10 they think are most interesting. The 6 vote-getters pass on to the next stage, for review; the next 6 go back in the pool to be voted on another day (each hook gets, say, three chances); the bottom 7 are dropped. Easy, and completely automated except for the 60 seconds that each voter puts into marking his favorite 10.
There are all kinds of ways to tweak the exact voting formula, of course. For example, if your hook fails maybe you can submit up to two more hooks for the same article before the article is permanently out of the running.
Note that no review effort at all goes into a nom until its hook passes this initial voting stage, so right there there's a tremendous reduction in labor.
some sort of process – Some sort of handwaving. I've explained my process. What's yours?
a small permanent panel to make a final judgement – Great idea! That would definitely avoid suspicions of bias because such a panel would inherently represent a wide range of tastes and opinions, unlike my system where everyone votes.

Paging Wugapodes so he can say how excited he'd be to code the voting machinery. E Eng 14:20, 8 June 2021 (UTC)

I've explained my process. What's yours? – Well no, you've explained the bare bones of a process, which IMO is little more than my "handwave". Sorting out the details of such a process would be a major undertaking. Apart from which, of course, you are in the difficult position of trying to persuade the DYK community to adopt a system that would radically reduce the amount of their content that reached the main page. Gatoclass (talk) 14:45, 8 June 2021 (UTC)

Sorting out the details of such a process would be a major undertaking – Sure, but that's a one-time job; after that, carrying out the process, day to day, is quite easy, and that's what counts.
trying to persuade the DYK community to adopt a system that would radically reduce the amount of their content that reached the main page – And there we have, in fact, the thing that has blocked DYK reform for years and years and years. "The DYK community" (i.e. the regulars who dominate the process and submit most of the nominations – not the mythical "new editors" that we pretend are being motivated by DYK) have their egos tied up in seeing their stuff on the main page.

E Eng 16:36, 8 June 2021 (UTC)

Well I don't know that it's about "ego" EEng, but whether a DYK community member is new or old, none of them are likely to be keen on seeing less of their work promoted. But we've had so many contributors over the years, I sometimes wonder if it wouldn't be more accurate to simply say "Wikipedians" rather than "DYK community". Gatoclass (talk) 17:04, 8 June 2021 (UTC)

Sorry, too late. You had it right when you said "DYK community" -- those with an investment in the current process which supplies the growing line of little icons on their user pages. It's ego. E Eng 17:11, 8 June 2021 (UTC)

"Ego" is a highly fungible word that can mean just about anything depending on context. Yours seems to be along the lines of getting a big head or fancying oneself as special. I can't speak for others, but on the increasingly rare occasions that I've been in a position to nominate a new article for DYK, the payoff for me has always been just to have a few people click on my article and hopefully appreciate the hard work that went into it. So I would say it's about getting a little recognition for one's contributions - there are very few of us, I think, who can manage with none - it's just a pretty basic human impulse. Gatoclass (talk) 17:31, 8 June 2021 (UTC)

(Gc, I know we like each other, so you won't mind when I say that you need to look up the word fungible.) Bottom line, you said it, no getting around it: reform of DYK is blocked by those who won't abide anything that might reduce the amount of their content that reache[s] the main page. E Eng 18:59, 8 June 2021 (UTC)

I don't think the entire Wikipedia community can be considered to be involved with the Did you know... process. Even just looking at those who created/expanded the articles with associated DYK items: I wrote one such article; I only learned about the DYK item when I got a posting on my talk page about it on the day it appeared. I had (and still have) no involvement at all in the process. I will say that regarding ego, it was a pleasant surprise to see that the article attracted someone's attention. I think that would be a nice goal for DYK: strive to recognize some articles created/expanded by editors who have never had an associated DYK item before. isaacl (talk) 18:10, 8 June 2021 (UTC)

@Isaacl, I'd like that, too. When I see good pages by new editors with interesting facts as I'm patrolling, I sometimes encourage them to go to DYK. But due to bad design, the process is often too intimidating for them to do so on their own. That means that I have to co-nominate with them. And when I recently sought clarification about whether or not QPQs are required for co-nominations, most editors seemed to feel they are. Decisions like that are what make me feel most hopeless about DYK—not only are we actively disincentivizing the sorts of nominations we most need, we're so wrapped up in our own processes that we're blind to how much of a problem we have (see also: all the comments here along the lines of "it's all subjective, so there's no such thing as a boring hook"). {{u|Sdkb}} ^talk 18:50, 8 June 2021 (UTC)

Amen, brother. E Eng 19:09, 8 June 2021 (UTC)

I think it would be nice to solely nominate an article that had been created or expanded by another editor, without approaching them to ask them to nominate the article or do a co-nomination, as this would enhance the serendipitous nature of the event. Rather than use the carrot of "nomination without cost of an obligatory review", I suggest setting a target quota over some period of time (week, month, year). It might not get achieved, but it would set an objective to strive for. (I don't particularly like the concept of quid pro quo reviews, but as I'm not familiar with the culture of the DYK process and participants, I don't have any suggestions as to what else could be done.) isaacl (talk) 19:38, 8 June 2021 (UTC)

If we want less of the negativity involved in "that hook sucks" perhaps encouraging people to post additional hooks for some wikibrownie points (nomination credits or whatever) might also help. Basically encourage {{sofixit}} for boring hooks. —Kusma (talk) 14:07, 8 June 2021 (UTC)

One issue with this is that it's not uncommon for the nominator to complain about hooks written or modified by other editors, and while at times they are for legitimate reasons, other times it feels more like a case of "I don't like it". Narutolovehinata5 ^tccsdnew 14:17, 8 June 2021 (UTC)

I haven't done many DYK noms myself (see a comment I will make later as to why) but the few I've done I've welcomed the feedback. My skills are more suited to technical writing (financial statements, standard operating procedures, process manuals, real exciting stuff) and frankly I suck at creative writing, and every hook I've written has been modified by a reviewer. I do understand why a different editor might get attached to the exact hook that they wrote, though. Maybe if it was made more clear up front that hooks might be modified before going live, it would save some of that drama? Ivanvector's squirrel (^trees/_nuts) 15:23, 8 June 2021 (UTC)

You don't WP:OWN your DYK hook any more than you own any of your created pages. Listening to the nom / page creator is important because they know the subject matter and context best, but it is quite unwiki to allow them too much say over the hook. —Kusma (talk) 16:24, 8 June 2021 (UTC)

Quite unwiki perhaps, but it does happen and it's a tricky position to put a reviewer in. Easy enough to say that a reviewer should be hard-nosed and reject the DYK, but it is a decision that will invariably generate strife with those nominators, which is not pleasant. CMD (talk) 02:30, 9 June 2021 (UTC)

I strongly disagree with the premise that DYK is fundamentally broken, but certainly there are opportunities for improvement. I find myself largely agreeing with Andrew Davidson (don't tell him I said that) about DYK routinely being the most interesting of all the featured content on the main page, and I also agree with the editors who have said that "interesting" is subjective, and a poor reason to completely overhaul the process. Each of the hooks visible at any given time is likely to be "interesting" to some readers while others visible at the same time are not, and some readers won't be interested by any of them, but DYK rotates often enough that I don't see why this should be a concern. For me, modifying the criteria for DYK would be more helpful. I don't nominate many articles for DYK because the sort of writing that I do tends not to fit into any of the criteria. Aside from GA promotions DYK rewards bulk, not quality. I really dislike the 5x criteria for article expansions: what about articles that are already quite large? For example I've participated recently in a broad endeavour to include Indigenous history in articles on Canadian cities, where often there is no information at all or just a very brief mention. This is the sort of info that would make good DYK hooks, but there's no way I'm expanding those articles by five times with that info. If we want DYK to reward article improvement, rather than rewarding mass creation of stubs, then that criteria needs tweaking. Ivanvector's squirrel (^trees/_nuts) 15:48, 8 June 2021 (UTC)

Thus my proposal that we eliminate the new/expanded criteria and run only GAs. Get people to focus on that. There's a huge GA backlog waiting to be addressed. E Eng 19:07, 8 June 2021 (UTC)

I don't think that limiting DYK to just GA noms would do anything to improve the quality of DYK noms, nor to help the GA backlog. It would just lead to more poor quality GA noms and tie up reviewers from promoting actually good content. My point was that the current criteria leave DYK a huge gap between 1) creation of new, stubby dreck, and 2) doing the work necessary to promote a good article. If we want DYK to promote incremental improvements to content (maybe we don't, idk) then there needs to be some middle ground. Or, if we just want DYK to be a list of recently-promoted good articles, then just drop the pretense of "interesting hooks" altogether and just have a bot auto-fill a flat list of new good article titles in its place. That would free up DYK reviewers to review GAs instead. Ivanvector (^Talk/_Edits) 21:18, 8 June 2021 (UTC)

Your concerns are all valid. But at least DYK effort would be expended toward something lasting i.e. GAs, instead of the current, essentially meaningless DYK reviews, which are a dead end. But at this point I've expended my annual quota of effort wasted advocating DYK reform. E Eng 23:03, 8 June 2021 (UTC)

Gatoclass, I think your math here is a little off, since it ignores the likelihood that removing the new page requirement would make the hook nominations much more interesting. We'd start getting nominations because someone came across an interesting fact while browsing, rather than that they wrote a page they want to promote. {{u|Sdkb}} ^talk 16:10, 8 June 2021 (UTC)

That sounds like you're picturing a DYK that encourages reading (to find cool facts), not writing (to add those cool facts). —Kusma (talk) 16:31, 8 June 2021 (UTC)

Maybe, but right now we have tepid facts in crappy "new" articles. Here's an idea: require that the fact be new. But I still say we should divert all this review labor to GA reviews, by running only GAs. E Eng 16:39, 8 June 2021 (UTC)

I sometimes wonder if anyone in the DYK process does read the articles in question. I have often seen hooks on the Main Page that were blindingly obvious ("DYK... that this fish lives in water?" type things), but when I click on the article there is some amazing, spectacular, mind-blowing thing just begging to be used. --Khajidha (talk) 16:47, 8 June 2021 (UTC)

Certainly it's true that some folks don't seem to be very good at identifying good hook material in their own articles. But you are perfectly welcome to propose alt hooks when you find them Khajidha. Gatoclass (talk) 16:54, 8 June 2021 (UTC)

And I have. Both complete alternate hooks and improved phrasing (grammar, tone, flow) of existing hooks. But I don't have the time to concentrate on the project, so my contributions are fairly minor. Some one above said it before, there seems to be a reluctance to call a spade a spade and tell the nominator flat-out "that hook is completely boring and will not be allowed to run, you need to find something better in the article. Have you considered <other thing from article>? " I also question why people who nominate 327 virtually identical articles on butterflies/mushrooms/railroad stations/etc aren't told that they can only pick ONE, the others will not be used. --Khajidha (talk) 17:07, 8 June 2021 (UTC)

You may have meant "327" as an exaggeration, but we actually had 314 nominations on creeks and streams in Pennsylvania [11] -- some of the most stupendously dully hooks (and articles) ever. My attempt to suggest that maybe readers might have been getting just a teensy bit tired of all that dreck was shouted down. E Eng 17:19, 8 June 2021 (UTC)

Not really meant as an exaggeration, I had come across examples before. --Khajidha (talk) 18:18, 8 June 2021 (UTC)

(edit conflict) Oh heck no, I would be totally opposed to a model that eliminated the requirement for new content and substituted it with "here's a cool fact I came across somewhere on the Wiki." I also think it would have absolutely zero chance of getting adopted, since there probably isn't a single DYK contributor who would agree to it. Gatoclass (talk) 16:48, 8 June 2021 (UTC)

Why? What the fuck is the value of featuring new content, specifically? It constantly, constantly steers our readers to our worst -- often embarrassingly bad -- content. I keep hearing it over and over: "The purpose of DYK is to feature new content, The purpose of DYK is to feature new content, The purpose of DYK is to feature new content" -- as if it's self-evident that DYK makes no sense unless that's true. But it's not. E Eng 18:59, 8 June 2021 (UTC)

Embarrassingly bad? How so? We don't promote articles which are not within policy. They must be: 1. Notable; 2. More than a stub (i.e. bigger than 1500 characters); 3. Thoroughly referenced to reliable sources; 4. Neutral; 5. Free of Copyright Infringement. The main issue here seems to be that you simply don't like the topics being proposed, but yet they do satisfy WP:GNG in order to pass DYK. The other complaint is article size, but I don't see that as an issue. A 1,500 character minimum is perfectly fine for many encyclopedia entries. The print editions of encyclopedias like Encyclopedia Britannica include entries shorter than 500 characters. Our threshold for inclusion in terms of length is reasonable. Lastly, I personally think GA review is a joke. More than half the time GA articles come to DYK with policy issues that require fixing (i.e. plagiarism, NPOV problems, other sourcing issues, etc.). Our DYK reviewers seem to be more astute at reviewing articles for policy issues than what gets done at GA. I am more confident that a DYK article on the main page is within policy than an article with a GA stamp.4meter4 (talk) 23:49, 8 June 2021 (UTC)

The main issue here seems to be that you simply don't like the topics being proposed, but yet they do satisfy WP:GNG in order to pass DYK. – No idea where the fuck you get that idea. My problem is with the quality of the articles themselves, and their hooks.
"Within policy" is a pathetically skimpy fig leaf. Among the things GA requires but DYK doesn't are that an article be clear, concise, and understandable; address the main aspects of the topic; and stay focused on the topic without going into unnecessary detail. DYK has no such requirements, so the articles it presents are allowed to be badly written, confusing, woefully incomplete, and/or bloated and discursive – and they often are. Of course, if you're saying that's not true, then DYK's article's already meet GA and no one should have any problem with making GA the gating requirement for DYK. Which is it?
There's no question GA reviews are often shoddy, but so are DYK reviews often shoddy. What saves DYK is the second- and third-stage checks that occur at prep building and Q promotion. If GA became DYK's gating requirement then GAs would get the same benefit.

E Eng 03:10, 9 June 2021 (UTC)

If I wasn't already convinced that there's a disconnect between what regular Wikipedia editors consider interesting and what normal people (i.e. readers) do then this discussion would have convinced me of it. I find many of the comments above, including those from editors with which I usually agree, simply incredible. The section is called "Did you know ...", not "Boring facts that we have decided to put on the main page to boost a few editors' egos". Phil Bridger (talk) 18:04, 8 June 2021 (UTC)
But unfortunately there's no truth-in-advertising regulation for Wikipedia main-page features. E Eng 18:59, 8 June 2021 (UTC)

DYK has multiple objectives, not just one, it's never been solely about highlighting interesting facts. With regard to my comments above about how certain proposals here are likely to be received by DYK contributors, I am not making value judgements about those responses, I'm simply trying to inject a note of realism into the discussion. There is little point in coming up with radical reform proposals that are almost certain to fail. Gatoclass (talk) 01:30, 9 June 2021 (UTC)

One thing that should be noted here is that proposing that DYK be limited to GAs has been brought up in the past, but has never gained traction. There are some good enough reasons for that, and I very much doubt that doing this would solve the complaints others have had about DYK (such as boring hooks or biases). In fact, I'd argue that limiting DYKs to new GAs would worsen the bias issue, because bringing an article to GA is already difficult and thus it's mostly more common among either more niche topics, or Anglocentric subjects. At least with the current requirements, the barrier for entry for overlooked regions is low so they have a good chance of being featured. And besides, not all GAs have hook-worthy information in the first place, no matter how long they are. One thing that even regulars at DYK tend to forget is that not all articles are meant for DYK, especially when the material simply isn't there, so there are other ways to resolve the issue of boring hooks without the need for such a radical and flawed idea. Personally I still think that some of the editors above like Kusma and CMD have a point that regulars should be more willing to decline hooks and even articles if they're simply unsuitable, and while the wishes of nominators can be taken into consideration, they should not be dogma and can not be followed if it's for the better good, given that nominators don't own their nominations or their hooks. Narutolovehinata5 ^tccsdnew 05:34, 9 June 2021 (UTC)
I'd support a proposal for radical reform along the lines discussed above, generally shifting the purpose of DYK from editor-focused ("encourage new articles") to reader-focused (interesting, high quality articles). Reducing the number of DYKs posted is a good first step--at least down to once per 24hrs instead of 12 (half the world never sees half the hooks with 12 hr rotation). The GA-only requirement is another interesting idea, though Ivan has some good points about the concern that this will flood GA with low quality noms. Another idea: limit the total number of DYKs any one editor can submit in a particular time period (per month, per year), which will stop or slow down some of the repetitive narrow-topic hooks we see. Generally speaking, DYK should be reformed to reduce volume and increase quality. Levivich 14:47, 9 June 2021 (UTC)
Having a numerical limit on how many nominations an editor can make sounds like instruction creep and honestly sounds unfair. Narutolovehinata5 ^tccsdnew 15:04, 9 June 2021 (UTC)
I don't understand what WP:CREEP or fairness have to do with it? Levivich 15:07, 9 June 2021 (UTC)
There is nothing wrong with the quality of DYK articles. Most of them are well presented, attractive, and reasonably well written. Just looking at yesterday's sets, a majority of both look to be GA quality and probably headed that way. Some of them are probably too short for GA, and that's fine, not every article on every subject has to be substantial, and a mix of long and short articles adds variety and attracts different readers. Too many articles on Wikipeda, including both GAs and FAs, are "kitchen sink" style articles that discourage engagement. Apart from the length, the typical DYK and GA would be indistinguishable to the average reader anyhow, only Wikipedians would ever notice, for example, the finer points of MOS compliance. And there would be absolutely zero benefit in cutting the overall number of DYKs by half. Gatoclass (talk) 16:33, 9 June 2021 (UTC)
I think we can all agree that maybe 1/2 of DYKs are "well presented, attractive, and reasonably well written". (You, I gather, think it's more.) What we're talking about is how to get rid of the other 1/2. E Eng 16:40, 9 June 2021 (UTC)

They have nothing at all to do with it, of course. E Eng 16:37, 9 June 2021 (UTC)

What I like: Restoring some brief line giving context for the DYK section. Making an effort to make hooks more consistently "hooky" (but not necessarily funny or sensational). I think that in the review process, and in prep assembly, it would be reasonable to be more insistent that the hook be clearly interesting, or enticing to read more about it, even if that means that some nominations end up failing. Still, I agree with some other editors that DYK is often the most interesting part of the Main Page. What I don't like: instituting any sort of voting process, or changing the kinds of pages that are eligible for DYK. --Tryptofish (talk) 20:52, 9 June 2021 (UTC)
Your mother wears army boots.{{country data {{{1}}}

| flaglink/core | variant = | size = | name = | altlink = national football B team | altvar = football | class = B }} Well, could you get on board with the two principles below? E Eng 22:04, 9 June 2021 (UTC)

For those playing along at home, Old Army Boots (you should see what I'm wearing, by the way), attempted to put {{fbdb}} there, but only put "fbb", poor fella. But anyway, I already commented below. (Spoiler alert: No.) --Tryptofish (talk) 22:13, 9 June 2021 (UTC)

I meant to do that. 😜 E Eng 23:47, 9 June 2021 (UTC)

Two concrete proposals, do or die (IMHO)

I will now assert:

DYK Reform Principle 1: DYK quality (of hooks, of articles) requires ~~a substantial reduction of volume i.e. no more than 1/2 of the current volume, and quite possibly 1/3 or even less~~ [modified 22:08, 9 June 2021 (UTC)] some kind of reduction in the number of hooks presented per day.
DYK Reform Principle 2:A limit of X DYKs in any Y months, per editor, is quite enough. (I'm not sure whether X counts nominations made, or authorship/expansion credits, or the sum, or what; and X and Y remain to be determined.)

If we can get these two principles enacted, then we may be on our way to real reform of DYK, because it mark the end of the tyranny of those who cry that it's somehow unfair to reduce the amount of their content that reache[s] the main page (see way up in this thread); it will force us to find ways to make choices about what DYK features, instead of essentially everything nominated being pumped down the sludge pipeline no matter what. If not, then there will never be reform.

DYK nominations in the pipeline

E Eng 16:37, 9 June 2021 (UTC)

@EEng: If you're looking for !votes on these, you might want to move to VPR or another place where that can happen. {{u|Sdkb}} ^talk 16:43, 9 June 2021 (UTC)

No, just talking about it for now. E Eng 17:02, 9 June 2021 (UTC)

So the Two concrete proposals are not concrete proposals? :-) Anyway, I've been warned if I write "I agree with EEng" one more time, they're going to create a new edit filter. Levivich 17:28, 9 June 2021 (UTC)

I'll also reiterate that I'd love to see someone make a concrete proposal to bring back the "from Wikipedia's newest content" message. I don't think that person should be me given my reputation from this, but I'd support it and frankly I think it has a much higher chance of passing than either idea above. {{u|Sdkb}} ^talk 16:55, 9 June 2021 (UTC)

Except that would re-engraves in stone probably the worst thing about DYK: its "new content" fetish. However, if you wanted to say, "From new articles that have been slapped together in a hurry to meet the arbitrary and inexplicable DYK 7-day deadline", I'd be on board with that. E Eng 17:02, 9 June 2021 (UTC)

The 7-day deadline encourages me to start all possible DYK candidates in userspace so I have time to complete them. A shorter deadline would work even better. I admit it is a bit weird to have a 7 day limit until nomination followed by a 1-100 day wait until the article actually reaches the Main Page. —Kusma (talk) 17:59, 9 June 2021 (UTC)

start all possible DYK candidates in userspace so I have time to complete them – Thus neatly defeating one of WP's more cherished principles, collaborative work. E Eng 20:47, 9 June 2021 (UTC)

We increased the deadline because people complained about the deadline being too short. The C of E God Save the Queen! (talk) 20:23, 9 June 2021 (UTC)

I remember various discussions of increasing the days-to-nominate, and the most common objection was, "But then we'd have too many nominations! We'd have to run four sets a day!" In other words, the tight deadline is an arbitrary way of throttling the input to the DYK system, which has no rational way -- indeed does not attempt -- to choose among submissions. For its sheer arbitrariness and irrationality, the seven-day deadline is perhaps the most ridiculous aspect of the DYK system (and that's saying a lot). E Eng 20:47, 9 June 2021 (UTC)

I don't follow your logic. What is the goal, and why do these things help? I would understand the principle "stop guaranteeing a Main Page appearance for rule compliant articles with boring hooks", but why is choosing from 30 boring articles better than choosing from 300 boring articles? —Kusma (talk) 18:09, 9 June 2021 (UTC)

why is choosing from 30 boring articles better than choosing from 300 boring articles – Choosing from 30 boring articles isn't what's being proposed. What's being proposed is to choose 30 (or more likely 100) articles from 300 articles. The 300 range from boring/badly written to fascinating/well written, so by taking only the best 100 you're probably getting a pretty good group, and certainly better, on average, than average of all 300 (which is what we present now). E Eng 20:47, 9 June 2021 (UTC)

Comment. Reducing the number of submissions per editor doesn't necessarily guarantee overall improvement. In fact, the reverse may be true. Editors who contribute regularly are often more skilled at crafting more interesting hooks and articles than those who don't participate often. Thus such a limitation may have the opposite effect of what you are intending. Further, policing the number of nominations per editor is going to be a headache. I'm not seeing a strong argument as to how this improves DYK's quality. If this were to come to a vote on another page I would not support it.4meter4 (talk) 19:58, 9 June 2021 (UTC)

Comment. Reducing the submissions per editor is nothing more than penalising the regular contributors who do much of the work to make DYK tick. We have already (sadly) lost one of our main contributors earlier this year, we do not need to lose more. Plus it won't improve content, if anything its more likely to make it workse/ The C of E God Save the Queen! (talk) 20:23, 9 June 2021 (UTC)

In order: EEng proposals, no and no. Add something to the Main Page to make it clear DYK isn't a random sample of articles and is showcasing the new-n-improved, but actual wording is complicated -- I agree with EEng about the new-article fetish, just disagree about the degree, and so don't support having a NEW NEW NEW hyperfocus in the wording. Not sure it's come up here, but I broadly concur with prior "broaden the seven-day range", although perhaps a little symbolic because I suppose most DYK regulars are working in sandboxen? Vaticidalprophet 20:26, 9 June 2021 (UTC)

It might be good to have only one rotation of DYK per day, unless that causes a backlog. Maybe. Otherwise, this strikes me as water under the bridge. --Tryptofish (talk) 20:42, 9 June 2021 (UTC)

Well, duh, of course it will cause a backlog unless we bite the bullet and start rejecting nominations. Right now we run as many sets per day as are needed to shovel everything -- everything submitted, whether good, bad, or indifferent -- out the door. And it looks like we'll keep on doing that, because ya know, this is the Special Olympics and everyone gets a trophy! E Eng 23:50, 9 June 2021 (UTC)

I think there are (at least) three different goals associated with the Did you know... initiative, including the following:

Encourage editors to create new articles or expand existing ones.
Highlight new content for readers, which gives them a sense of Wikipedia being an active site, and thus may encourage them to engage further in the community
Encourage readers to explore articles by listing an interesting fact from them

Overlaid upon this is the priority placed upon these goals. For example, the obligatory review system is a consequence of placing a more urgent priority on presenting more items (it's a circular dependency: when there are more submissions, then people want to present more items; but in order to present more items, you need more submissions and throughput).

It may be easier to achieve these goals separately with different initiatives, rather than trying to stretch Did you know... to cover all of them, never mind adding another goal of highlighting articles rated as good article quality. isaacl (talk) 20:43, 9 June 2021 (UTC)

I think the elephant in the room is people don't like to have their DYK nom rejected. For example, I was a bit nonplussed about Fremlin's Brewery and LattePanda not making it to DYK because they had issues, but after I'd stopped grumbling about it a day or two later, I thought "yes, Wikipedia is not going to fall flat on its face if these articles don't make the main page - get over it". Ritchie333 ^(talk) ^(cont) 09:51, 10 June 2021 (UTC)
In hindsight, perhaps DYK could have done without some of my less well performing noms. 700, 800, 1800. But 4000 and 9000 didn't seem THAT much more exciting at nom time. Not sure whether that tells me anything. —Kusma (talk) 11:03, 10 June 2021 (UTC)
I think it's heard to tell sometimes. Some of my more mundane hooks have got way more views than hooks that seem more interesting and unusual. We can't presume to know what people will want to read. Joseph2302 (talk) 11:05, 10 June 2021 (UTC)
- Which I find strange; my first DYK nom I was nervous about whether it would meet standards, if people would like the hooks! I think it passed quite easily, and got the image slot, and I was surprised. Perhaps attitudes have changed and nominators feel entitled and possessive; though this only comes out when there are problems they don't want to solve? But the DYK process can also help nominators improve some of the basic infrastructure of their articles even if they don't pass muster. I've had noms rejected for technical issues or hooks, and it doesn't bother me - I still contributed to the encyclopedia, I only nominate articles I think have a good hook fact so it's not like I feel articles "deserve" MP spots. I have over 70 DYK credits and I don't take any new nom for granted, and always welcome hook suggestions because I really think fresh eyes are better at landing on the most interesting facts. I think that attitude still prevails. Kingsif (talk) 11:19, 10 June 2021 (UTC)
- That's where I think being more focused with the goals can help. For example, there can be a "new content" feed that is more broad in accepting submissions, a "good reading" feed that highlights well-written articles, and an "interesting fact" feed that would focus on articles with good hooks. isaacl (talk) 16:13, 10 June 2021 (UTC)
Suggestion 2 is counter-productive in my opinion: more submissions by the same people generally leads to people producing better hooks. Therefore, I believe discouraging good editors would just make DYK quality worse, not better. Joseph2302 (talk) 11:04, 10 June 2021 (UTC)
And not at all sure how Suggestion 1 is enforceable, as running fewer hooks would just lead to a backlog. If you want to reduce number of submissions, you would need to change eligibility criteria (with consensus of course). Joseph2302 (talk) 11:04, 10 June 2021 (UTC)
Well, DUH. E Eng 11:16, 10 June 2021 (UTC)
My (not very clear) point was that you should change the eligibility criteria of articles, rather than putting caps on how many nominations a user can make. Joseph2302 (talk) 11:38, 10 June 2021 (UTC)
I wasn't putting a cap on. I was asking people if they could get agree to the principle that a lot less material should be run. If they can agree to that, then we can start talking about what we do to the criteria/process that will effect that reduction. If we can't get people to agree to that very simple idea, we can quit right now and save a lot of time. E Eng 20:15, 10 June 2021 (UTC)

I would support anything that would encourage people who think they have to nominate every article they write for DYK, whether or not they can actually create an interesting hook.

People seem to try to reverse engineer it. If while you're writing you come across something that makes you think, "Wow! That is so interesting! That would make a great hook!", great. Nom it. But people seem instead to be thinking "Okay, check, article created. Now, what can I use for the hook?" So really, all we need to do is change fundamental human nature. —valereee (talk) 12:18, 10 June 2021 (UTC)

From my experience, it varies. If I've created or improved a DYK-able article and I can think of a good hook, I'll put it forward (often while pinging EEng for a better hook ;-D). In other times, like A719 road, the hook has leapt out at me and I've scrambled to try and improve the article sufficiently to meet the other criteria.

"So really, all we need to do is change fundamental human nature." - Brilliant, Val, you've just outlined exactly how we can fix RfA and a whole bunch of other problems! Ritchie333 ^(talk) ^(cont) 13:20, 10 June 2021 (UTC)

Yep, this is very well put—that's the root of the issue. I'm not too confident about changing human nature, but a different system could incentivize different behavior. There have been so many times where I've come across a super interesting fact on an established page and thought "this would make an excellent DYK hook if only it were eligible". I don't think it'd be impossible for us to create a situation in which the most active DYK nominators are not editors promoting their own page but rather editors scouring the encyclopedia for the most interesting facts. {{u|Sdkb}} ^talk 14:29, 10 June 2021 (UTC)

Smaller reform suggestion: split the review

A slightly different proposal: the technical side of the review is done as normal, and when approved, the hook goes to an intermediate page (between noms and approved noms) where each nom has its hooks voted on by the general community. The more eyes the better, and will hopefully work because the voting body don't have to put in the hard work reviewing. Hopefully it will decentralize the "hook is interesting" aspect enough that the nominator doesn't get offended with "oppose" votes, or feels that it's just their one reviewer who doesn't like it. And the decentralized nature will hopefully mean that reviewers don't feel obliged to approve a hook they don't feel is interesting (one-on-one as it is, it may feel personal when you say no). The slightly more extreme version is to just go full ITN, where it's completely decentralized and everyone gets a vote on if it meets technical spec and is interesting, but given how much must be met for the technical side of DYK, I think that's too much of an ask. So, one person reviews the technical side as is normal, then a voting system; some ratio of support:oppose can be decided on for a hook to go through, and this stage would also allow other alt hooks to be proposed. Kingsif (talk) 11:33, 10 June 2021 (UTC)

Too cumbersome. EEng's proposal actually makes more sense than that, and it doesn't make enough sense either. Gatoclass (talk) 12:47, 10 June 2021 (UTC)

I'm very concerned about voter bias, both unintentional and pointy. Are we going to end up with only those hooks that are interesting to white men? Are we going to get voting designed to ensure we aren't US-ipedia? —valereee (talk) 12:29, 10 June 2021 (UTC)

Voting on individual hooks could actually worsen some biases we have, and is a bit clumsy. Perhaps we could have a system where decent articles with insufficiently hooky hooks can be flagged up for the Hook Rescue Squadron? —[[User:|Kusma]] (talk) 12:37, 10 June 2021 (UTC)

I am currently toying with the idea that a voting process may be useful as a backup, where the interestingness of a hook becomes disputed. That way it isn't used for all hooks, (and hopefully not for many at all,) but it provides a clear path forward on interestingness debates and takes some of the personality out of results. CMD (talk) 12:40, 10 June 2021 (UTC)

I echo the concerns about diversity of hooks. A lot of editors will be American or British, and I think that would lead to an unconscious bias towards hooks from these countries. Similar to on WP:ITNC, where we get way more proposals for US articles than any other country. Also, if anything, DYK process needs to be made simpler, not more complicated. It's already the most complex process a newish editor gets involved in. Joseph2302 (talk) 12:43, 10 June 2021 (UTC)

Also, it doesn't solve the issue I mentioned above somewhere: what we the editors think might be "interesting" doesn't always match with what readers end up deciding they want to read. So we could exclude hooks as boring, when readers may have found them interesting, or vice versa. Joseph2302 (talk) 12:50, 10 June 2021 (UTC)

(edit conflict) Yes, I agree with you and Valereee that maintaining hook diversity would likely be a major challenge in any !vote-based system. There are certain topics that are perennially fascinating to human beings and others that almost invariably are not. How, one wonders, would hooks about obscure sea sponge species fare in a !voting system? Or hooks about opera or ballet? We are an encyclopedia, not a tabloid, and hooks should reflect the full diversity of encyclopedic topics, not just those likely to attract the most attention. Gatoclass (talk) 13:07, 10 June 2021 (UTC)

I still believe that an interesting hook can be written about any topic (provided there is something interesting there), nominators just need to give up on trying to force all the specialist knowledge into the hook - interesting to them, boring to people who don't know about sponges/opera/ballet. Either find something universal about the item, even if it seems unimpressive to the experts, or keep the specialist hook simple enough. Kingsif (talk) 18:17, 10 June 2021 (UTC)

I do think this is an issue. We have noms who think it's a shame that the person's major accomplishments are sidelined by the fact they did something surprising. Maybe we need to discuss the fact that "Writer wrote book" is much less interesting than "Writer learned to skydive at 89" or whatever. —valereee (talk) 22:00, 10 June 2021 (UTC)

I very much agree with this sentiment. There should probably be a change in the thinking of DYK contributors that the hooks they write are not for them, but for the greater readership, and that hooks need to be written with that audience's interest first, even if it may not be favorable to the specialist. For example, a hook about an opera singer performing a role may be of interest to opera fans, but it may be less so to the hoi polloi, whereas if the opera singer did something surprising for an opera singer (for example, if they also sang rap or another completely different genre), that may be more likely to catch the attention of even non-opera enthusiasts. I understand we all have our biases but we don't own our articles or hooks and we should always keep that in mind. Narutolovehinata5 ^tccsdnew 01:38, 11 June 2021 (UTC)

This is something I've noticed a lot. And sometimes the contributor is so close to the subject that they don't see that something that they find interesting (and needs no explanation to them) would be greatly intriguing to the general public with just a little expansion, but comes off as incredibly dull without it. --Khajidha (talk) 11:43, 11 June 2021 (UTC)

@Valereee, Kusma, Chipmunkdavis, Joseph2302, and Gatoclass: Prep promoters seem to do a good job building diverse sets, I'm sure a group of users - or maybe the technical reviewer? - could be going through the noms to basically rule out any supports and opposes that seem biased (e.g. "support - California is cool" or "oppose - I've never heard of Petrovic" would just be discounted). But this would be contingent on everyone giving a reason for their !vote. Kingsif (talk) 18:22, 10 June 2021 (UTC)

I don't think that's workable. Discount "math sucks", but keep "our readers are put off by having to see advanced mathematics"? Discount "oh no not another radio station" but keep "radio stations only have a very local impact"? If you have to develop criteria about what votes to toss out, shouldn't you just develop better criteria for the hooks? —Kusma (talk) 18:37, 10 June 2021 (UTC)

What I'm concerned about are !votes like "Oppose. There are too many US hooks. This isn't US-ipedia." Also whether heavy support for a certain hook is because that hook is about a subject which typically is of high interest to white men, and vice versa. Are we going to end up with every footy hook sent through because, duh, footy is inherently interesting, and one about feed sack dresses yawned at because of our editor demographics? —valereee (talk) 18:49, 10 June 2021 (UTC)

For what it's worth, to both of you, I would personally discount all of those comment examples (and anything just saying "footy is interesting"). Who cares that radio stations are local? And it's already written into DYK that there's a lot of US hooks (they're usually quite reliable filler so I don't want to lose them). I suppose I should have been clearer that it would be the bias content, not bias phrasing - !votes counted on quality, as per the rest of Wikipedia. I don't know if you still think it's unworkable, though, with all the thought behind the count. Kingsif (talk) 22:56, 11 June 2021 (UTC)

But @Kingsif, it doesn't have to be that blatant. These are inherently !votes that are opinions. How do you count a !vote on whether something is "generally interesting" as a "quality vote" or not? Someone could say, "Oppose. Clothing was made of cloth...ho-hum." Is that a "quality vote" opinion? I can't argue with it. It's a reasonable opinion. And a ton of white men might have that same opinion about most of my articles and hooks because I often write about things of interest to women. I also try to write about things I suspect might be of interest to people of color and especially to women of color. Those things may not look "generally interesting" to most of my fellow editors. —valereee (talk) 13:18, 14 June 2021 (UTC)

There are lots of topics that I am not interested in, but I can still see a difference between a boring hook and an interesting one. Take opera. I have no interest in opera. A hook that is basically "opera singer sang opera" is boring. But a hook like "opera singer sang in both East and West Germany before the wall fell" or "opera singer sang multiple lead roles in a single weekend" or even "16 year old sang role usually reserved for mature singers" has something interesting about it, even if you hate opera. So, while I (a white man) may not be personally interested in the topics you write about, I can still appreciate your hooks if you give me a reason to. --Khajidha (talk) 20:36, 14 June 2021 (UTC)

Evaluating page quality

Editors have commented above that there can be a problem when a new page of poor quality gets highlighted. Short of limiting DYK to GAs only, there are other ideas that might be worth brainstorming on. Currently, DYK requires that new and newly-expanded pages conform to basic policies, meet some standards for citing sources (mainly for the hook), and not be stubs, but also says that the pages should not be expected to be at the level of a GA (I assume that the GAs are GA-level, wink, wink). There is room in there for some potential tweaking of the standards.

I recognize that one has to be careful not to open the door to, in effect, making DYK review almost the same as GA review, because that would make a lot of nominations far too protracted and difficult. Simply asking reviewers to confirm that the page satisfies core policies is a necessary but low bar. We could also stipulate that pages should have no conspicuous formatting problems, and have the same requirements for inline citations that we currently require for the hook, throughout the main text. We could say that the page should be written well enough that it is understandable to any reader who comes to it from the main page. Maybe require more than one or two sources. I would think of it as setting the bar a little higher than Start class, but lower than GA. Also more like "Wikipedia's best new content" instead of "Wikipedia's newest content". If some careful thought were to go into the wording, this would eliminate some nominated pages from eligibility, but in a beneficial way, without making the review process insurmountable. I don't think there will be consensus to limit DYK to GA only, but this is a less drastic step that is worth evaluating. --Tryptofish (talk) 18:52, 10 June 2021 (UTC)

I issued the following challenge (slightly reworded here) somewhere above but (surprise!) it went unanswered:

Among the things GA requires but DYK doesn't are that an article be clear, concise, and understandable; address the main aspects of the topic; and stay focused on the topic without going into unnecessary detail. DYK has no such requirements, so the articles it presents are allowed to be badly written, confusing, woefully incomplete, and/or bloated and discursive – and they often are. Of course, if you're saying that's not true, then DYK's article's already meet GA and no one should have any problem with making GA the gating requirement for DYK. Or do you admit that DYK articles are often badly written, confusing, woefully incomplete, and/or bloated and discursive, but since that's OK we shouldn't apply the GA standard? Please say which. E Eng 20:20, 10 June 2021 (UTC)

Yes, such criteria are good. I wouldn't like for us to reinvent the ~~wheel~~concept of article assessment, though, and would suggest to stay close to existing things like WP:B? or WP:C?. —Kusma (talk) 20:58, 10 June 2021 (UTC)

I think raising the standards a bit (length, sourcing) is fine. For the lazy who want to click instead of reading, something like "if mw:ORES says B, pass, if it says Stub or Start, fail, if it says C, look more closely" could work as a proxy for a real review. —Kusma (talk) 20:40, 10 June 2021 (UTC)

Oh yes, by all means let's substitute automated evaluation for human review. That would let us run twice as many -- three times as many -- five times as many DYKs every day with no additional human effort!

More seriously, no one's yet answered my challenge here just above. Maybe you'll be the first. E Eng 20:50, 10 June 2021 (UTC)

I'm not sure whether this hasn't already happened (some folks seem to think "not copyvio" is the same as "Earwig doesn't find a copyvio"). Some human review (ideally coming with suggestions how to improve the article) is always good to have if you ask me (I prefer constructive feedback to just a tick). Just need to be careful not to make it too daunting for new reviewers. —Kusma (talk) 21:09, 10 June 2021 (UTC)

I have low, very low, enthusiasm for anything that would be automated. I'd prefer to look at it in terms of improving the wording of the DYK rules (and preferably not the supplemental rules, except to make them consistent). Something near to B-class, but not as high as GA, seems approximately right to me. As for EEng, I want to challenge you to stop changing the subject to your own earlier comments, and to focus instead on the ideas here. --Tryptofish (talk) 21:17, 10 June 2021 (UTC)

If we're going to stick with reserving DYK for new pages, I don't think there's anything terribly wrong with our current standards. Most new pages aren't super high-quality—article development takes time—and that's reflected in DYK. My view is that we ought to ditch newness as the (usual) requirement, but that's already been discussed (at great length) above. {{u|Sdkb}} ^talk 21:29, 10 June 2021 (UTC)
Perhaps there are ways to address some of the concerns that underlie the desire to ditch newness, without actually ditching it. Such an intermediate approach will not satisfy editors who "want it all", but wanting it all rarely gets consensus. --Tryptofish (talk) 21:44, 10 June 2021 (UTC)

But DYK is not reserved for newness. It can feature any article, no matter how old, so long as it has recently been brought to GA standard. So I wish people would stop saying it's only for new articles. You can already take any article on Wikipedia that isn't already an FA or GA and get it featured by bringing it to GA standard. So the only barrier is that you must do a bit of work on an article you want to nominate to improve it. That is good for the encyclopedia and in my view is an appropriate requirement. Gatoclass (talk) 06:52, 11 June 2021 (UTC)

Taking an article to GA status is not just "a bit of work", especially if it's a big article for an important topic, which is also where the most interesting DYK hooks are likely to be found. And regardless of your personal view about whether people ought to be willing to put in more work, the reality is that they don't—90% of DYKs are for new articles, not GAs, and a giant collective mindset shift isn't going to just happen because we decide on it. The only way the current nomination dynamics will change is if we're bold enough to change (or at least experiment with) the rules. {{u|Sdkb}} ^talk 07:25, 11 June 2021 (UTC)

Well maybe some of you guys need to spend a little more time trying to figure out exactly what you want from DYK, because one minute the discussion seems to be about better quality hooks and the next it's about better quality articles. But certainly you are not going to get better quality articles by dumping the GA requirement and just going with any hook you happen to find somewhere that tickles your fancy. Apart from which, I would dispute the claim that there is a lot of work getting articles to GA standard - it depends entirely on the state of the article beforehand, and the rigorousness of the reviewer. But even if there was considerable work in the average GA, so what? Shouldn't you be expected to do a little work for the privilege of getting a DYK on the main page? Part of DYK's purpose is improvement of the encyclopedia, and the GA requirement achieves that. Gatoclass (talk) 09:40, 11 June 2021 (UTC)

Regardless, I think it's pretty clear that the main complaint about DYK over the years has been about hook quality, but I think most hooks these days are actually of an acceptable standard. The problem is a relatively small number of hooks that just aren't up to scratch, and if we solved that problem, we would probably eliminate 90% of the complaints.

So for what it's worth, here's my proposal for improving overall hook quality, that doesn't require radical makeovers of dubious benefit or feasibility. Basically, we just give people an incentive to work harder on hooks. One way to do this would be to have some sort of DYK credit for identifying a substandard hook and coming up with a better alt. Let's call it the "Eagle Eye" credit or something. So, if you challenge a hook as insufficiently interesting, and come up with an alt hook that makes it to the main page without substantial changes, then the challenger gets a DYK "Eagle Eye" credit. That gives reviewers and other users an incentive to start paying more attention to hook interest to see if they can come up with something better. It's a simple, low overhead solution that would be easy to test and which could conceivably result in a significant improvement in overall hook quality. Gatoclass (talk) 09:46, 11 June 2021 (UTC)

I like it. Crowdsourced and carrot instead of stick. —Kusma (talk) 10:30, 11 June 2021 (UTC)

Template:The DYK Medal is already available for use in the meantime! CMD (talk) 11:52, 11 June 2021 (UTC)

I like this idea a lot! I've certainly done that for hooks in the past, and I could certainly see myself doing more of it if it counted as a QPQ. It won't solve the problem of some articles being nominated because the nominator wants to see their work on the main page rather than since the article contains any fact of interest. But it would help address the problem of nominators being too close to the subject to know what's actually interesting about it (what Narutolovehinata5 and Khajidha discussed above; search for "change in the thinking of DYK contributors"). {{u|Sdkb}} ^talk 20:42, 11 June 2021 (UTC)

I've been doing this for the sake of DYK, you mean to be saying I could've gotten credit this whole time ;) Kingsif (talk) 23:00, 11 June 2021 (UTC)

I like this idea, too. I think treating it as a QPQ is worth doing. It gets more sets of eyes on noms, which can only be a good thing. —valereee (talk) 13:27, 14 June 2021 (UTC)

Encouraging editors to denigrate each other's work is a bad idea. It would turn DYK into a battleground, cause much bad feeling and decrease productivity. We have already seen what happens when someone revels in the role of "Eagle Eye" – rushing to find fault by nitpicking anything and everything. They drove off many contributors to DYK, such as the Women in Red stalwarts, and were then topic-banned from DYK! Andrew🐉(talk) 10:05, 17 June 2021 (UTC)

Absolute/Perfect Pitch

Eddy Chen, a Youtuber famously part of the duo channel TwoSetViolin (alongside Brett Yang) has a rare ability where he can recognize any note solely by hearing the note being played (on any sound device). He alongside Charlie Puth and other famous musicians have this great ability, and Eddy Chen should take him place on the wikipedia page alongside them. — Preceding unsigned comment added by 24.236.123.253 (talk) 23:54, 17 June 2021 (UTC)

If you have suggestion to improve an article, start a discussion on that article's talk page. RudolfRed (talk) 00:01, 18 June 2021 (UTC)

Talk page not accessible to unregistered, mobile users?

Tracked in Phabricator
Task T54165

Like the title says, unless you have a registered account there's no link for the talk page on mobile.

Is there any ongoing discussion/effort to fix this? Is it intentional? There's no issue for unregistered desktop users.

I see a lot of editors say "go to the talk page" but it's a little tricky if a user can't access it. Plus if someone wants to browse and see issues, you can't without logging in.

Cheers, Fredlesaltique (talk) 01:25, 17 June 2021 (UTC)

@Fredlesaltique: I found Wikipedia:Editing_on_mobile_devices#IP_editing which mentions the limitation. Since it doesn't say there is a fix being worked on, I assume it is either intentional or cannot easily be fixed. RudolfRed (talk) 23:57, 17 June 2021 (UTC)

There is discussion at Wikipedia:Village_pump_(WMF). RudolfRed (talk) 00:00, 18 June 2021 (UTC)

@RudolfRed: Thanks for the links. The first looks like just an essay, but I'll check out the second one. Cheers, Fredlesaltique (talk) 07:37, 18 June 2021 (UTC)

This appears to be phab:T54165 which has been getting passed around for 8 years. — xaosflux ^Talk 11:03, 18 June 2021 (UTC)

Help provide thoughts and ideas about the formation of the Movement Charter drafting committee in advance of Global Conversations on 26 and 27 June

Hey all! First a bit of news - good, bad, or neutral, depending on your perspective: I'll now be working on additional topics as a Movement Strategy and Governance Facilitator. Xeno (WMF) (talk) 02:00, 18 June 2021 (UTC)

It's definitely good news, @Xeno (WMF)! I'm glad that they're keeping you around. Whatamidoing (WMF) (talk) 15:05, 18 June 2021 (UTC)

For now, I was hoping to conduct an information gathering exercise about what the upcoming committee to draft a movement charter should look like. The ideas shared here will be included alongside those gathered in other local conversations happening now to inform Global Conversations scheduled for 26 and 27 June.

The Movement Charter drafting committee is expected to work as a diverse and skilled team of about 15 members for several months. They should receive regular support from experts, regular community reviews, and opportunities for training and an allowance to offset costs. When the draft is completed, the committee will oversee a wide community ratification process.

Some context is included below the questions; see further details about these conversations and a recently updated overview of the Movement Charter initiative. Feel free to ask questions, and add additional sub-sections as needed for other areas of interest about this topic.

If anyone is interested in having a live round-table call for this, please let me know about ideal dates and times. Xeno (WMF) (talk) 02:00, 18 June 2021 (UTC)

Xeno (WMF): I understand that you do not get to decide the timeline for these initiatives, but since you're a facilitator I feel duty bound to point out a major issue here. Namely, as I've heard Nosebagbear talk about thoughtfully, the foundation is trying to do tons of things simultaneously and it is spreading thin the volunteers who may be interested. I have a lot of energy for Wikipedia but even with-in that energy I feel exhausted between my existing volunteer commitments including the UCoC Drafting Committee, a different major initiative going on. I semi-seriously like to say that the foundation trying to accomplish all of the 2030 Strategic Plan goals as though it were a 2025 Strategic Plan. Specifically in terms of "too much going on simultaneously" I will point out that June 26 and 27 are days that have already been "taken" for UCoC consultations. So would I love to participate in something that I think will establish a constitutional order to the Wikimedia movement and perhaps be the best defense against a future WP:FRAM? You betcha. But unfortunately due to other commitments I've already made to the Wikimedia Movement I will be unable to attend. Best, Barkeep49 (talk) 02:23, 18 June 2021 (UTC)

Thanks for mentioning the scheduling overlaps Barkeep49, and I understand the pacing concerns. For this round, the local and global calls are being considered as a whole, so if there are other double-booked contributors, it's completely possible to talk about the the charter drafting committee on a different day: just let me know when works for people. Xeno (WMF) (talk) 03:07, 18 June 2021 (UTC)

1. What composition should the committee have in terms of movement roles, gender, regions, affiliations and other diversity factors?

There is broad agreement on the diversity and the expertise that the committee needs to have as a team (see Diversity & Expertise matrix).
Some believe that there should be specific seats or quotas assigned to members with specific qualities (affiliation, region, gender…), some believe that the composition should be flexible as long as it meets the diversity and expertise requirements.

2. What is the best process to select the committee members to form a competent and diverse team?

There is broad agreement on the need to form a diverse and competent team, but opinions differ about how to achieve this.
Some believe that self-nominations, invitations and appointments are the best way to form the team, some believe that it is better to have a majority of seats elected by the communities and the affiliates.
In the case of appointments, some believe the decisions could come from a self-appointed group with participation of the Foundation, some prefer a selection committee that would be elected.
In the case of elections, there are different opinions about the distribution of seats elected by communities, elected by affiliates, and appointed by the Foundation.

3. How much dedication is it reasonable to expect from committee members, in terms of hours per week and months of work?

There is broad agreement that committee membership drafting a Charter is serious work, but too demanding requirements are likely to affect the diversity and competence of the team.
The default expectation of committees is that members stay for the entirety of the project and they carry most of the work.
Some ideas have been suggested to reduce the burden, like rely on professionals for certain tasks, organize volunteer groups to work on certain questions, or include a process for membership renewals.

Sometimes AIV is too slow.

I’ve reported a lot of vandals to administrator intervention against vandalism, and while I think AIV is great for most cases, I think that it can be too slow in some serious cases. Last night was one of those— there was a group of trolls attacking Waiuku; I took them on with the help of two others, but the edits kept coming. LizardJr8 reported them, but I knew it would be a while before an admin came to help. The vandals were destroying the page quicker than we could fix it. Then I decided to cut the AIV line and go straight to Liz. She speedily dealt with it. What I think we should do is create a new template. It will serve as a kind of Bat-Signal to quickly get an admin’s attention for cases of vandalism that need to be dealt with immediately, not to be dealt with at the whim of anyone that’s just passing by. Of course, I recognise there would be an issue with new users thinking that their cases of vandalism trump all other cases in importance, and admins would be flooded with requests. I’m not sure if this is possible, but perhaps we can make it so that only more experienced editors have access to the template (maybe as a part of Twinkle?). That way, they have enough experience under their belt to know what cases are high priority and what cases aren’t. It would work like this— once a user finds an admin, they go the the admin’s talk page, open the Twinkle menu, and select the template. Maybe there’s one or two boxes they should fill out, such as the name/IP address of the vandal or amount of disruptive edits they made. In summary, this feature would help users in an active vandalism crisis quickly get hold of an admin. A Twinkle template would allow them to quickly get the information conveyed instead of creating a lengthy plea for help (like what I do, LOL). I would love to hear your thoughts on the matter. 🐍Helen🐍 20:27, 28 May 2021 (UTC)

HelenDegenerate, See Wikipedia:Requests for comment/Responder role for a proposal (which doesn't appear to be making any progress) from ProcrastinatingReader for one way to deal with this. -- RoySmith (talk) 21:46, 28 May 2021 (UTC)

I think we had a few more things to figure out, but to some degree I don't think it would pass if it went live now. It's probably better to try it if/when a greater portion of the community feels there is a problem here. ProcrastinatingReader (talk) 21:57, 28 May 2021 (UTC)

Oh yeah, this problem. I think we should have a chat room (IRC, Matrix, Discord, whatever) where some admins hang out, and there could be a command that'll ping one of them, rotating among the admins in the room. There should be either a Twinkle button or a separate user script that'll send the command with a link to a specific AIV case. We can figure out access control later. I've been meaning to slap together a prototype for a while now - we don't even need to ping anyone for starts, just post a message - and thanks for the reminder. Enterprisey (talk!) 03:22, 29 May 2021 (UTC)

Did you know that... believe it or not, we need more administrators? The solution is actually things like: a) making RfA more active. b) making RfA less toxic. c) making RfA more encouraging. If we could do that, then this thread never would have started. 🐔 Chicdat ^{Bawk to me!} 12:16, 29 May 2021 (UTC)

What is the difference between (b) and (c), between making RFA less toxic and making RFA more encouraging? Robert McClenon (talk) 22:53, 30 May 2021 (UTC)

From what I have heard, d) be more circumspect before reporting things to AIV might also help. Anecdotally, there are a lot of questionable reports. Jo-Jo Eumerus (talk) 13:06, 29 May 2021 (UTC)

What about having the bot move to the top reports where the user has fresh reverted edits after the report tinestamp? –xeno^talk 13:15, 29 May 2021 (UTC)

Xeno, that sounds intriguing S Philbrick (Talk) 19:17, 29 May 2021 (UTC)

@Xeno:, I like that idea. I wonder— would we create a new bot to do the job, or would a preexisting one be in charge of moving the reports? If we used a preexisting one, maybe we can make ClueBot NG do it— it is an anti-vandal bot, after all. And one other thing: to draw extra attention to serious vandalism crises, perhaps the bot puts some kind of brightly-coloured symbol by it to show it is a high-priority case. What do you think? 🐍Helen🐍 23:56, 29 May 2021 (UTC)

HelenDegenerate: it would probably just be a new feature request for the AIV helperbot, but the first step would be confirming with AIV regulars to ensure it's a desirable change. –xeno^talk 00:27, 30 May 2021 (UTC)

This is interesting. The bot would need to be running every minute or two to be useful, but I'd have no objections. I can't see any way to avoid a large proportion of the vandalism reports wanting to use the special template. IRC obviously has requests for this. Discord has informally - you can just ask if someone is free to help, but we are not a semi-formal adjunct like the IRC and we like to keep stuff on-wiki where it belongs Nosebagbear (talk) 13:30, 30 May 2021 (UTC)

@Nosebagbear:, I think I have the solution to that: simply restrict the use of the feature to extended confirmed users. Or if we’re talking about Xeno’s idea, there won’t be a problem with that, as only one entity would be able to use it— AIV Bot. 🐍Helen🐍 22:08, 30 May 2021 (UTC)

While I like the idea of sorting the reports, I am a bit afraid of edit conflicts. Constant bot edits will make it difficult to annotate reports. —Kusma (talk) 22:44, 30 May 2021 (UTC)

@HelenDegenerate: the vast majority of AIV notices are already done by EC-editors. It's not that I think they'll spam it to be annoying, I just think that anywhere up to a third of AIV reports (given that by the time someone does that it's already the 3rd (or more) issue) are going to make individuals "this is a bad, rapid case, I should use this" or "they've vandalised after being reported to AIV, we should use it now". Limiting it in that way will not avoid the issue. Nosebagbear (talk) 22:12, 30 May 2021 (UTC)

@Nosebagbear: True. I myself am staring to lean towards Xeno’s idea, because it’s up to the bot when to move certain cases to the top. Perhaps we can program it like this: if a particular vandal edits x or more times after the report, or has made over x amount of disruptive edits in the past 24 hours, then the program moves to the top and tags it as priority. 🐍Helen🐍 22:17, 30 May 2021 (UTC)

Yeah, a separate sub-section that things that had been bumped to the top a certain number of times would be good. However, this (and, to be fair, any solution) is still contingent on someone being around to process it. Dire emergencies are occasionally dropped on AN/ANI, but I suspect most admins are like me and are mildly unhappy if the request is not a standout issue, lest it become the norm. Could also add a bot task to drop a notification onto ANI if something had been in the "uber-crit" box for, say, 3 hours? Nosebagbear (talk) 22:25, 30 May 2021 (UTC)

@Nosebagbear: That could be fixed by having the AIV bot figure out which admins have made edits in the past minute (so they'll probably still be online), then leaving an automated urgent help message on their talk page. Same criteria still apply-- vandal must have edited x or more times after the report, or has made over x amount reverted edits in the past 24 hours. If the admin doesn't respond to the request within, say, 10 minutes, the notice is removed from their talk page and AIV bot chooses the next admin that makes an edit. I know this sounds complicated, but it might be able to solve both problems that you've brought up. 🐍Helen🐍 17:56, 31 May 2021 (UTC)

So, you'd need this to be opt-in by admins, and I'm not sure how many you'd get given the problematic bit is 0200-0800 UTC. I also suspect that this system wouldn't be able to remove the notifications, and the wiki equivalent of deleted Discord pings are really annoying, because I have to go investigate the history every time to figure out what it was. Nosebagbear (talk) 18:21, 31 May 2021 (UTC)

A concept for a possible notification. Anarchyte (talk)

I really like this idea in theory, but I would hate having a dozen messages posted on my talk page each day. What would be perfect is if we added a way to push a notification (example on the right) when various pages (AIV, RFPP, etc) reach n outstanding reports. It would of course be opt-in and would only ping people that have made an edit in the last 30 or so minutes. Anarchyte (talk) 16:03, 7 June 2021 (UTC)

@Anarchyte: Without any software changes, there could be a mass ping template like Template:@MILHIST containing a bot-maintained list of currently active admins that have opted in to "attention to AIV" pings? —Kusma (talk) 16:10, 7 June 2021 (UTC)

@Kusma: Interesting. I'd hope that only a bot could ping the list though, or we'll get some very cranky admins. Anarchyte (talk) 16:14, 7 June 2021 (UTC)

@Enterprisey The #cvn-wp-en and #wikipedia-en-help channels already exist on IRC --Ahecht (TALK
PAGE) 16:35, 7 June 2021 (UTC)

@HelenDegenerate: This might be a bad idea but what if we give Rollbackers (or another role) permissions to ban new/IP users for 10-20 minutes in the case of blatant vandalism after 4/4im warning so that an admin has time to respond? -Justiyaya (talk) 06:57, 19 June 2021 (UTC)

@Justiyaya: I like your idea very much. Another editor, RoySmith, mentioned this proposal called Wikipedia:Requests for comment/Responder role. That would create a new group of users. I felt that the criteria for becoming a “responder” was way too narrow, and would only allow for a handful of users to access it. I think your idea is much better— possibly something the rollbackers can do. They’ve already been trusted with a very powerful tool (the revert button). Getting rollback means that you’re very experienced in counter-vandalism, and probably know when there’s a serious crisis going on (for a great example of a crisis, look at the edit history of Let them eat cake). Would there be a limit to the number of times a rollbacker could block someone? Helen (let’s talk) 15:26, 19 June 2021 (UTC)

@HelenDegenerate: I looked at the request for comment and that probably is better than mine in some ways, the main problem I have with mine idea is that giving rollbackers that right probably also means making rollback harder to get. Maybe adding limitations to the blocking will help, like if the blocking is allowed only if the user is warned by at least 2 different users that are extended confirmed (including the user that issues the blocks), and by making the blocks be really short and practically painless if some rollbacker decides to go rogue (like 15-minute ones). I probably have a COI issue proposing this idea because I'm a rollbacker myself. I think the responder role is genuinely a good idea, I would vote for it. It might be too narrow, but it keeps the most dangerous/destructive tools to more experienced/trusted editors. Justiyaya (talk) 16:13, 19 June 2021 (UTC)

How about changing the conditions under which the page reports that it's backlogged? at the moment the conditions are that the page reports a backlog when there are more than 4 entries, and removes the notice when this is reduced to two. What if instead it reported a baklog if there are more than 4 open reports, or a report that's been open for more than, say, an hour (not sure on the exact time to use)? 192.76.8.91 (talk) 16:34, 19 June 2021 (UTC)

Good articles and Featured articles

Moved from Wikipedia:Village pump (proposals) § Good articles and Featured articles

– Sungodtemple (talk) 13:21, 21 June 2021 (UTC)

I once nominated an article for good article, then those editors who made maximum edits were angry as they made more edits. I have seen another case with editor Krish! who was also very upset when he was working on an article, he improved the article, and another editor took it for featured article nomination.

If there are no rules or policy about this then, then only those who have worked to improve the article, they should nominate the article, not some random users. I withdrew the nomination, when other editors objected.

I have seen that those who are improving the article, they want to take credit for nomination, and I agree with them. --2402:3A80:1112:E680:845C:FD63:6888:BB7A (talk) 06:30, 21 June 2021 (UTC)

The instructions at WP:FAC state that "Nominators who are not significant contributors to the article should consult regular editors of the article before nominating it." As a practical matter, only significant contributors nominate to FAC today. There was a time, in the early days of the process, say around 2004, when this was not the case.--Wehwalt (talk) 10:18, 21 June 2021 (UTC)

User:2402:3A80:1112:E680:845C:FD63:6888:BB7A, I don't see the problem. Sungodtemple (talk) 13:21, 21 June 2021 (UTC)

It would be a problem if the "rules" say you can do X, and then people yell at you for doing X. WhatamIdoing (talk) 22:01, 22 June 2021 (UTC)

WP:GAN/I#N1 already states: Anyone may nominate an article to be reviewed for GA, although it is preferable that nominators have contributed significantly to the article and are familiar with its subject and its cited sources. Nominators who are not significant contributors to the article should consult regular editors of the article on the article talk page prior to a nomination. —El Millo (talk) 22:06, 22 June 2021 (UTC)

Make mobile version article segments closeable from the bottom

Moved from WP:VPR

On mobile, article sections pose a few problems. The best example of this is that you might be midway through an article, then go to a new page, then press back to go back to the article, and find you have lost your place. Frequently it positions you at the top of a previous section or midway through it.

Scrolling on mobile is also fairly time consuming.

So instead the idea is to let each segment be closed from midway through it or from its bottom. This way you can read a section, and then close it once you're done without having to scroll up. Another idea would be to be able to close the section from any point up or down it.— Preceding unsigned comment added by 108.3.163.12 (talk • contribs) 14:50, 13 June 2021 (UTC)

Interesting suggestion. BusterD (talk) 15:39, 13 June 2021 (UTC)

I moved this to Idea lab, as it isn't an actionable proposal - it is a request to invent a new UX control. From a UX perspective, how would you see this working? Consider there are things you can click on "in the section" already - like links, images, etc (not to mention copying text). — xaosflux ^Talk 20:52, 14 June 2021 (UTC)

Not quite what the OP is asking, but a simple CSS solution:

.collapsible-heading.open-block {
	position: sticky;
	top: 0;
	background-color: #fff;
}

will make headings stick to the top when open. Nardog (talk) 21:15, 14 June 2021 (UTC)

I think i have a better proposal. Let's implement the same feature recently released for Fandom's mobile display: a floating TOC that can be used to navigate all sections quickly. So if a user want to close/collapse the current section, they can open the TOC, select current section, then close. This doesn't require tediously scrolling up. You guys should check it out. enjoyer -- talk 23:01, 14 June 2021 (UTC)

Let me know when you've found an int-admin willing to edit MediaWiki:Common.js/css to implement this proposal please. 🏳️‍🌈 Chicdat ^{Bawk to me!} 10:01, 15 June 2021 (UTC)

I would be in on this as well. ~ HAL333 13:55, 18 June 2021 (UTC)

I've wished for this many times as well! Would love to see implementation of something along these lines. Retswerb (talk) 02:52, 23 June 2021 (UTC)

GnomeHome

I admit I shouldn't do this, but in search of harmless amusement, I couldn't help looking at the administrator's noticeboard (incidents). It's actually addictive. The more you read it, the more compulsive it becomes: a fixation on finding out how our fellow human beings get themselves in such appallingly upset states about things that really shouldn't cause crises. After a while, it stops being amusing, and gets sad, because of the suffering it causes individuals, and the harm that these spats do to the encyclopaedia at large. But there is one class of argument that makes me particularly sad: quite often, WP seems to suffer from misguided WikiGnomes, people whose life-work is to remove split infinitives or convert all templates of one sort into templates of another sort that render the same text. At the moment there seems to be a spat about someone determined to change the format of all fractions. Gnomes should be a force for the good. They should be clean-up gardeners, behind the scenes, sorting out all sorts of minor irritations and inconsistencies that the rest of us can't be bothered to fix. Good gnomes are great people. But a misguided gnome is a hazard, leaving a (barely-visible, until too late...) trail of mess behind them. I wonder whether we need a place for gnomes? A GnomeHome, where gnomes can confer, and agree on good gnomic practice; even perhaps a Gnome task-force, with lists of appropriate, useful jobs for the wannabe gnome to tackle. If they were pointed in a useful direction, it would reduce the risk of go-it-alone gnomes latching onto a Bad Idea. Or is there such a place already? Elemimele (talk) 13:48, 22 June 2021 (UTC)

@Elemimele, people who want to contemplate split infinitives will find friends at Wikipedia:WikiProject Guild of Copy Editors. People who want to deal with more technical gnoming may be interested in Wikipedia:WikiProject Check Wikipedia. I expect that there are several more homes for gnomes. WhatamIdoing (talk) 22:00, 22 June 2021 (UTC)

@WhatamIdoing: thank you, I will remember those links, if my gnome-tendencies start to express themselves, or in case I meet an unhappy gnome in search of useful activities. Elemimele (talk) 05:54, 23 June 2021 (UTC)

Also, I think there's a pharmaceutical now to treat those with gnoming tendencies. Possible side effects include hair loss, broccoli allergy, and gambling addiction, but then they have another pill to counteract those. That pill makes your teeth come loose. E Eng 14:23, 23 June 2021 (UTC)

They should just take Jeremiah Peabodys polyunsaturated, quick dissolving, fast acting, pleasant tasting, green and purple pills. They're the wonder drug that cures all your ills. They're guaranteed to be just what you need for quick, fast, speedy relief. --Khajidha (talk) 16:18, 23 June 2021 (UTC)

Jeremiah's Green is people! E Eng 16:28, 23 June 2021 (UTC)

WP and Youtube stats cited to Youtube

This concerns Template:Infobox YouTube personality and inclusion of YT-cited stats like subscribers and total views in article text, not necessarily in articles with that template.

IMO, including such primary-sourced data is for the most part WP:PROMO-ish. One specific example, Niki and Gabi. It can be ok include stuff like "more than 7 million views as of 2009" if a decent independent source bothered to notice it, but including updated YT (and similar) stats is not in my opinion something WP should do, that's YT:s job.

So, the idea I want to laborate is

Remove subscribers and total views from Template:Infobox YouTube personality
Add to a relevant MOS or guideline something like "Do not include YT-sourced (or Instagram, Tik-Tok, etc) statistics like subscribers and total views. If a YT-channel (etc) is relevant to the article-topic, it can be added as an external link, which provides such info." Similar to "Do not include user ratings submitted to websites such as the Internet Movie Database, Metacritic, or Rotten Tomatoes (including its "Audience Says" feature), as they are vulnerable to vote stacking and demographic skew."

What say you, Wikipedians? And if it's a good idea, what's a good way to proceed? Gråbergs Gråa Sång (talk) 10:35, 19 June 2021 (UTC)

I'd just leave it be. Subscriber and viewer numbers are relevant for YouTubers, and are noticed by secondary sources, but those sources just take their information from YouTube anyway. I don't see how avoiding to have updated information if the primary sources exist is helpful. WP:NOTPAPER says we can update more quickly than other sources. —Kusma (talk) 11:04, 19 June 2021 (UTC)

put in Wikidata This sort of information is welcome there. After there is a process in place for managing it there then it would be easier discussing its including in Wikipedia. Otherwise English Wikipedia is unlikely to be able to manage this. Blue Rasberry (talk) 14:05, 19 June 2021 (UTC)
I don't have a strong feeling on whether we should have it, although I think I agree with Kusma more than the OP. However, I do feel that Wikidata is the place for this sort of thing. firefly ( t · c ) 14:09, 19 June 2021 (UTC)
One reason why these statistics get mentioned in WP articles is to establish Notability. The idea is that having high viewer/subscriber numbers distinguishes the few notable YouTube personalities from the millions of non-notable YouTube personalities. The problem is that, to properly establish notability, we really should cite an independent source (ie not YouTube) that takes note of, and comments upon, these statistics. Blueboar (talk) 14:29, 19 June 2021 (UTC)
I don't think we should ever use number of subscribers as a proxy for notability, which should only be established by coverage in secondary sources (fifty million subscribers, no RS coverage: delete). Just if we do display the number, we might as well take it from Youtube. —Kusma (talk) 14:41, 19 June 2021 (UTC)

Its been determined that subscriber counts to YT are not a sufficient indicator for notability, alone, since they can be gamed. A high subscriber count will likely be noticed and reported by 3rd parties, at which point we can looked to those sources for significant coverage, but a sub count alone from a YT page is definitely going to fail notability allowance.

Also, I generally do not like using YT page numbers themselves for sub counts once notability is established, since again, this is gameable. It is better to use a third-party source and go "As of (date) this Youtuber had X million subscribers", even if that date is off. We are likely going to provide a link to the Youtube channel page and a reader can see what the current count is, but sticking to the third-party source avoids situations when a number has been gamed. --Masem (t) 15:02, 19 June 2021 (UTC)
If there are third party sources that have access to subscriber / view counts that are more accurate than Youtube's, by all means use those. Just if other sources report on subscriber numbers using Youtube's numbers, there's nothing gained by us avoiding Youtube. —Kusma (talk) 19:18, 19 June 2021 (UTC)
I'm not aware of a different source, but what I do think that we are getting by a reliable third-party source is the recognition of a viewer count number w/o the possible inflation. Eg the New York Times reporting on PewDiePie's subscriber count, we'd not be questioning here that NYTimes is reporting those numbers because it was reasonably sure about that number. We'd want to avoid case which may go unreported like the PewDiePie vs T-Series where both channels were gaming for sub numbers to "win" - in that situation we could document that, but there's plenty of similar informal sub-gaining competitions that don't, and we have to be wary about those. --Masem (t) 20:47, 19 June 2021 (UTC)
I agree with Masem. If secondary sources make note of a particular subscriber count or video view we can not that {{As of}} that date. However, these numbers can be and are regularly manipulated. This has gone on for years. A quick search, for instance, reveals this 2020 article from Wired. Using them for reasons of notability or the like is letting the YouTube equivilent of UPE gain traction on a different site. We shouldn't let us ourselves be susceptible in that way. Best, Barkeep49 (talk) 17:16, 19 June 2021 (UTC)
Youtube views and subscribers should never be cited anywhere on Wikipedia, because they may indicate actual people watching the videos or they may indicate that the person posting the videos has enough money to buy views and subscribers. Just do a Google search for "buy youtube views". The going rate is roughly $500 USD for 100,000 views. At that point Youtube starts putting your videos on the suggested videos page and they naturally rise. A boring video will level out at a couple of hundred thousand and interesting/clickbait videos can easily top a million. --Guy Macon (talk) 17:37, 19 June 2021 (UTC)
YT subscriber counts are significant info for YouTubers, and YT is an RS for YT subscriber counts. It doesn't matter if the counts are "real," it matters that it is the reported count. But the count shouldn't matter for notability. Levivich 20:17, 19 June 2021 (UTC)

Gråbergs Gråa Sång, I am responsible for adding the automated citation. This was to make sure Fram wouldn't have to add a cite to every single use of {{Infobox YouTube personality}}. See Wikipedia:Administrators' noticeboard/IncidentArchive1069#Unjustified warnings for "unconstructive edits" and "edit war". I think inclusion of the stats is useful, but moving them to Wikidata (and transcluding them from there) sounds reasonable. That way other language Wikipedias could also use them. — Alexis Jazz (talk or ping me) 22:07, 19 June 2021 (UTC)

YouTube statistics should stay in the articles. They are easily verifiable and not subject to original research. YouTube subscriber number have never been and should never be signifier of notability, but they are a significant enough piece of information that they should be in the infobox. For people who are notable enough to have Wikipedia articles, the amount of "subscriber fraud" is likely to be negligible. Hemiauchenia (talk) 02:06, 20 June 2021 (UTC)

And you know this... how? --Guy Macon (talk) 01:27, 21 June 2021 (UTC)

I have no idea what value this adds. OK so Barry has 1 million subscribers, would this put them in the top 100, the top 10? That is what matters, not raw subscribers (and as I have said before, a TV with a potential audience of 100's of millions will get canceled if it only gets 1.5 million viewers. So why would a Youtube show (with a potential audience of billions) matter (see my point about placement)? Tuis is just puffery.Slatersteven (talk) 10:02, 20 June 2021 (UTC)
It is an interesting number for Youtubers - the approximate count is often mentioned in external coverage. Youtube is the source for Youtube subscriber counts. I'm not a fan of weekly updates, but if the number has changed a lot since the last update then I think it's fine to change it sourced to Youtube. Wikidata can do that, too. --mfb (talk) 07:23, 24 June 2021 (UTC)

Extended confirmed users group management

Moved from WP:VPR

This is one of the user groups that are automatically granted after a certain amount of time and edits. An administrator has no ability to revoke someone's autoconfirmed status, but has the authority to revoke someone's EC status. I would like to know what the community thinks about putting EC into the Implicit member box. Interstellarity (talk) 12:08, 23 June 2021 (UTC)

Venue change

You've mentioned a very specific technical proposal, that I'm certainly ready to oppose on multiple technical grounds. Perhaps this proposal could do with some more development and should move over to idea lab? — xaosflux ^Talk 13:11, 23 June 2021 (UTC)

@Xaosflux: OK. I agree that it should be moved over to the idea lab. Could you please move this over so that people can get ideas on how to do this? I appreciate that. Thanks, Interstellarity (talk) 13:30, 23 June 2021 (UTC)
@Interstellarity: done. — xaosflux ^Talk 13:39, 23 June 2021 (UTC)

@Xaosflux: I apologize for getting bogged down in the technical configuration. I thought it would be something that we could improve. It sounds like you are saying messing with the technical configurations would be the wrong thing to do. Would you recommend closing this discussion or leaving it open for other editors to comment? Interstellarity (talk) 20:09, 23 June 2021 (UTC)
@Interstellarity: I put this part here in the collapsed section, Idea Lab is very flexible, we can continue to discuss below. — xaosflux ^Talk 22:35, 23 June 2021 (UTC)

@Interstellarity: what problem are you trying to solve here? Unless you are sure of something, it might be best to not get bogged down in the technical configuration (e.g. how the specific $wgGroupPermissions or $wgAutopromote configuration will be deployed yet). — xaosflux ^Talk 13:41, 23 June 2021 (UTC)
Can you clarify why you think your proposal is an improvement? As Xaosflux asked, what is the problem that you feel should be addressed? isaacl (talk) 20:40, 23 June 2021 (UTC)
Hi Isaacl, I think it is an improvement because extended confirmed is one of the groups that is granted automatically and when a person gets desysopped for any reason, it would be easier for the bureaucrats to not worry about granting extended confirmed to any person that is desysopped. The autoconfirmed user group doesn't have this issue. Interstellarity (talk) 21:17, 23 June 2021 (UTC)
I would have thought that we would want the extended confirmed group to be able to be added or removed by administrators/bureaucrats - those functions get used on a fairly regular basis. You often see people having extended confirmed rights revoked for gaming the system (like doing hundreds of pointless edits to their user page) and the user right is given out on a fairly regular basis to alternate accounts and the like. Is bureaucrats forgetting to re-add the user right after a desysopping a major problem? It could be fixed in under a minute by any administrator on the site and there aren't many desysopings compared to the number of normal editors. If it happens often perhaps it would be better to add an edit notice reminder to the special page where user rights are added or removed? 192.76.8.91 (talk) 22:11, 23 June 2021 (UTC)
^-- agree with alot of that. — xaosflux ^Talk 22:40, 23 June 2021 (UTC)

As a 'crat who probably deals with the most desysopings (since I usually process the inactives report) I can say that putting that checkbox on when taking off the sysop checkbox has never been something I've been concerned was too bothersome for me. From an editing perspective, we could just leave +ec on when adding +sysop (just like we could leave +rollbacker or anything else that is redundant), but we normally remove it to make certain statistical queries easier. — xaosflux ^Talk 22:40, 23 June 2021 (UTC)
This is one of those things where if this was the way we did it from the start, no one would have any objections, but since the current system has been in place for so long with very few problems, we would need a much more compelling reason to spend the time developing this technical change than the bureaucrat convenience one. Mz7 (talk) 03:31, 24 June 2021 (UTC)
I do not think this is something worth the effort to change. The OP has mentioned desysoping, lets take a few recent examples and see if it is a problem. When RexxS was desysoped, he was given EC and a bunch of other rights he had that were removed when getting the sysop bit. When Carlossuarez46 was desysoped, he was not given EC, because he did not have it when getting the sysop bit (EC user group didn't exist at that time). But this is not a problem since all he has to do is make one edit and automatically get upgraded. Also Autoconfirmed user group exists in all WMF projects whereas EC is an opt-in user group that exists only in a few big wikis. This might be the reason why it is not there as an implicit member right. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 06:50, 24 June 2021 (UTC)
When I present some proposal to Wikipedia, sometimes others link to me WP:SLOP. Well, that's just what I'm thinking now. WP:SLOP asks you: What problem does this solve? @Interstellarity: Please answer. --🏳️‍🌈 Chicdat ^{Bawk to me!} 10:00, 24 June 2021 (UTC)

[waiting for answer] --🏳️‍🌈 Chicdat ^{Bawk to me!} 10:00, 24 June 2021 (UTC)

@Chicdat: After reading the comments above, there seems to be an agreement that it is not something worth doing. I thought what I was proposing would make sense in the long run, but I guess it’s not. Interstellarity (talk) 11:41, 24 June 2021 (UTC)

@Interstellarity: Welcome to the club! 🏳️‍🌈 Chicdat ^{Bawk to me!} 12:19, 24 June 2021 (UTC)

Could someone explain what adding the user right to the 'implicit member box' would do? Sam Walton (talk) 15:53, 24 June 2021 (UTC)
Samwalton9 Implicit user groups are user groups that are automatically assigned to users by the software which cannot be added or removed by administrators or bureaucrats. There are currently three implicit user groups - (All), User, and Autoconfirmed, covering all editors, all registered accounts and all accounts 3 days old with 10 edits respectively. Adding autoconfirmed to this group would mean that everyone with 500 edits and 30 days tenure would get the user right as usual, but it would be impossible to remove or add the user group manually. This could come in handy in a few edge cases (like the aforementioned removal of administrator rights leaving an account unable to edit extended-confirmed pages) but would prevent us from being able to revoke access or add it to alt accounts. 192.76.8.91 (talk) 16:11, 24 June 2021 (UTC)
Firm no. There are plenty of instances of people, LTAs and sockpuppets gaming the system to try and go around ECP (ex. a recent example still at ANI - Wikipedia:Administrators'_noticeboard/Incidents#New_user_gaming_ECP_to_edit_on_Indian_caste_related_articles...). There are also instances of good-faith but inexperienced editors doing some repetitive form of good-faith-but-not-helpful-editing and racking up EC having the right removed thereafter (usually of mutual accord, but still, it had to be done). Removing the possibility for this is not an improvement. At the very worst, having EC be manually removable and also keeping the possibility to add it manually for legitimate alts does no harm. At best, it is obviously helpful. The proposal removes human oversight, and likely adds some form of unnecessary complexity to the situation (by requiring, likely, that we create an EC equivalent of the "confirmed" user-group, and that all edit filters and restrictions which have some criteria based on EC be updated to add this new EC-equivalent group): which is also unhelpful as there are more pressing technical issues than this, which does not impact our readers or most editors anyway. RandomCanadian (talk / contribs) 13:39, 26 June 2021 (UTC)

entry's satisfactory?- fluid document component

1.ask reader if they found the entry useful 2.compartmentalization like new fluid office document https://www.theverge.com/2021/6/17/22538144/microsoft-fluid-components-documents-office-teams-onenote-outlook-whiteboard bi (talk) 17:16, 28 June 2021 (UTC)

Baratiiman, I'm not following. are you proposing a concept (or two)? Are you identifying something that may be of interest to us or something else? S Philbrick (Talk) 19:24, 28 June 2021 (UTC)

@Baratiiman Regarding 1: there used to be an article feedback tool but it was discontinued following a request for comment. The feedback received was often low-quality, and created a lot of moderation work. Regarding 2: I'm not fully understanding how this would be relevant to Wikipedia. Probably the closest thing is the mw:Wikipedia Preview project which allows 3rd-party websites to include a preview on their links to Wikipedia. the wub "?!" 20:28, 28 June 2021 (UTC)

Add the ability to add a profile picture

Tracked in Phabricator
Task T128953

I'm aware that Wikipedia is not social media, but many websites that are not social media allow you to add a profile picture to uniquely identify yourself. Many people put pictures of themselves on their user page, so this would give a better option. Félix An (talk) 14:05, 29 June 2021 (UTC)

@Félix An: see phab:T128953 for development on that idea. — xaosflux ^Talk 14:44, 29 June 2021 (UTC)

Draft talk pages that should be Draft pages

I had been editing Draft talk pages to remove lint errors, in some cases noticing and ignoring that the pages were properly Draft pages and not Draft talk pages. Finally I decided to act. I reviewed all Draft talk pages in my contribution history. When the Draft talk page seemed newer or better than the corresponding Draft page, or where the Draft page didn't exist, I copied the Draft talk page into the corresponding Draft page, with edit summary something like "Copy Draft talk version"; then, whether or not I updated the Draft page, I blanked the Draft talk page with edit summary something like "Blanked; Draft talk pages are for discussing the corresponding draft page, not a second place to make drafts". I did this on about 18 Draft talk pages. I assume that what I did is not controversial, but if anyone wants to say that any of this work was in error, this would be a good place to do so.

Assuming that this work is good for Wikipedia, my question is, "Does Wikipedia have anything to help find Draft talk pages that are likely not discussions of their corresponding draft pages?" If not, is there any interest in creating something? If a Draft talk page has one or more Wikiproject templates, it's probably legit; if it doesn't, it might be mis-categorized. If a Draft talk page has a user signature (identifiable by a Wikilink to a User page or a User talk page), it's probably legit; if it doesn't, it might be mis-categorized. So, one way to start this project would be to create Category:non-blank Draft talk pages without a WikiProject template and without editor signatures. There are other templates that might be used to remove pages from the category, including {{Connected contributor}} and {{Connected contributor (paid)}}. So maybe it should be something like Category:Draft talk pages that might be versions of Draft pages. If there is support for proceeding, steps might include discussions about

criteria for suspecting that a Draft talk page is likely to be a Draft page
construction of a bot to identify such pages
whether such pages should have a template on them
whether there should be a category and what it should be called
whether this should be part of an existing Wikiproject, and if so, which one, and if not, should it be a new Wikiproject

—Anomalocaris (talk) 08:02, 30 June 2021 (UTC)

@Anomalocaris: the only problem I see with your process is that it was a copy-paste content move, when it could have just been a page move that would maintain attribution of the contributors. Some history merges may be needed now. — xaosflux ^Talk 10:57, 30 June 2021 (UTC)

Amending 3RR to ensure that the status quo stands

If editor A makes a bold edit and editor B reverts this until they reach 3RR, the contested bold edit stands. How can the 3RR be altered so that the WP:STATUSQUO is not disadvantaged? Should editor B be allowed an extra edit to make sure the status quo remains, or is there a better way? ~ HAL333 15:53, 29 June 2021 (UTC)

Usually there are more than two editors working on a page, and if there are only two you can go to a noticeboard and ask for a third opinion.

Also, in the real world if for your last edit instead of reverting you go to a past version that was stable ror a long time and restore it with a comment such as "Per WP:STATUSQUO restoring last stable version from before the edit war", your edit is unlikely to get you blocked for edit warring, whereas reverting it is likely to result in a block. Maybe we should document that somewhere --Guy Macon (talk) 16:37, 29 June 2021 (UTC)

@HAL333 you might want to read m:The Wrong Version -- RoySmith (talk) 16:49, 29 June 2021 (UTC)

This is a really tricky question. There is substantially more de facto support for WP:STATUSQUO than there is guidance-based support for it (it's located with WP:Reverting, which is one of those essays that probably ought to become a guideline but never made it there). Our guidance-based advice is WP:BURDEN, but that fails to work when the question isn't so much an addition/removal as choosing between A or B, or when inclusion is the longstanding status quo and a removal attempt is unlikely to succeed but we have to wait out the duration of a RfC. I think it would help reduce edit warring quite a lot to give status quo guideline status and better define what exactly is required to constitute status quo status. I'd suggest 3RR might be the wrong angle to approach this from, as ideally good editors shouldn't be reaching 3RR anyways (I only rarely ever get to 2RR); the question instead is directly "when something is disputed, which version should stand while debate happens?" Raising the status of WP:Reverting might be trickier than adding something about status quo to the WP:Edit warring policy, as I raised last July. Good luck if you decide to take this on. {{u|Sdkb}} ^talk 18:44, 29 June 2021 (UTC)

I also know a bit about 3RR (when i was an admin i constantly was in the trenches with 3RR and Edit warring, ensuring that right wingers didn't spread their garbage onto female blp articles) and I have the exact same thoughts on 3RR and statusquo as Sdkb does and Sdkb's opinion on this subject - Sdkb is practically taking the words right out of my mouth. I would also say that Sdkb's proposal is probably the only example of a true hybrid system in this case that uses both lines of debate on this and combines them.

Its refreshing to see a post that actually understands the logic behind the scenes the way an actual 3RR insider would. signed Seven 60rmen (former admin ,former WIR)

The entire point is that things shouldn’t get to a 3rr. Stop the reverting and counter reverting before you get to that stage. There are other options. Use them. Flag the section as “disputed”, go to the talk page and discuss. Call in other editors for third opinions. File an RFC if you need to. Etc.

Yes, the article may be at “the wrong version” for a short period of time while you sort out the dispute… that’s not the end of the world (especially if you have flagged it so readers know that the currently visible version IS being disputed). Blueboar (talk) 19:40, 29 June 2021 (UTC)

There is no satisfactory way to deal with this: 3rr (or 2rr or 1rr , or any similar procedure) will always favor either the original version or the change, and sometimes that will be the right thing to do and sometimes not. I do not likethe p[resent ambiguities, as many disputes never do get sorted out, but I don't see an easy satisfactory alternative. DGG ( talk ) 01:10, 3 July 2021 (UTC)

A kink in AfC workflow

In Wikipedia:Teahouse#etiquette_about_comments_on_draft, DGG raised an issue concerning the WP:AfC workflow: he finds it disruptive when drafts that are in the AfC review queue are moved into mainspace:

AfC is a difficult , cumbersome, and greatly overloaded process, and it is only manageable at all because there's a standardized procedure. Therefore, I personally, I get somewhat annoyed when people move their own drafts to mainspace. There are a number of tracking categories, and to get them right, it's necessary to follow the old manual process as described the afc page, which is a thorough nuisance. It's very difficult keeping up with the new drafts and those that need review or deletion , or rescuing from deletion; I and the other people who work at afc all have our own established routines, and going out of the usual process tends to get things confused.

This seems like a very technical problem. It occurs to me that there might be a technical solution. I am not very familiar with the AfC workflow, so I am not exactly proposing anything concrete, but I am wondering if this is problem that deserves attention? — Charles Stewart (talk) 18:16, 2 July 2021 (UTC)

I find it disrupts my routine, but other reviewers consider it permissible. It also happens (rarely, but it happens) that something gets so screwed up in the afc proces that this is the only way accept an article. I was not intending to suggest we eliminate the possibility. There's a variation in how the dvarious reviewers review--though I hope we converge towards some standard for what we accept or decline, I would not advocate we all use an exactly uniform procedure--especially because atthis point there is no completely satisfactory procedure to standardize on. There are many technical fixes at AfC that would help, but what we really need are more reviewers. DGG ( talk ) 01:04, 3 July 2021 (UTC)

Plus one to DGG's. I would not want to restrict this - not least, because given the current backlog, an editor who shouldn't use direct mainspace when submitting could well be good enough to do so 4 months later. Nosebagbear (talk) 11:13, 3 July 2021 (UTC)

@DGG and Nosebagbear:- What I was wondering is possible, excuse my having been unclear, is whether it would be possible to continue to have this freedom, but have tools that allow us to see where the most expected thing is not being done.

For example, DGG was unhappy that behavioural assumptions made by tracking categories can be violated if drafts are moved into mainspace. However, templates can be written so that they behave differently in different namespaces: we could have the templates put such moved pages in a new tracking category, say Category:Tracked drafts outside draftspace instead of the usual tracking category. This would only be a good thing if the new tracking categories were actually watched. — Charles Stewart (talk) 07:24, 5 July 2021 (UTC)

User library

I have recently noticed that some users have a library subpage where they have a list of what books and papers they have, I've stumbled across User:Peacemaker67/library and User:Tomobe03/Library but they likely are not the only ones. I thought of the creation of a special page with such user libraries, headings on the page would be names of the Wikipedians and below the heading, there would be a sentence about what the said Wikipedian can/is willing to do (scans, verification, looking up info, etc.) and of course a list of books and/or papers that user has. Someone who is looking for a source or wants to verify something could just ctrl+f on that page and see if any Wikipedian has a book/paper they're looking for and if someone does they would leave a message on their talk page. This page would serve as a place where they'd go before WP:RX, if they find what they are looking for on that page they'd most likely wait less than they do on WP:RX. I have not been on WP for too long so something like this might already exist and if it does I'd be grateful if someone would provide a link. If it doesn't then I'd love to hear what do you all think about this idea and if it's good, how could it be implemented. OakMapping (talk) 12:52, 5 July 2021 (UTC)

Have you seen Wikipedia:WikiProject Resource Exchange/Shared Resources (there's a link to it on the Wikipedia:WikiProject Resource Exchange/Resource Request page to which you referred)? Is it what you have in mind? isaacl (talk) 15:17, 5 July 2021 (UTC)

Yeah, that's pretty much what I had in mind. I can't believe I missed that link. Thanks, OakMapping (talk) 17:35, 5 July 2021 (UTC)

Wikipedia:Village pump (idea lab)/Archive 36

Warning for users when potentially unreliable sources are used

IP address confusion fix

Tags

A link bot

Recommendation for file (re)naming

Bot that updates net worth

Why the separate tags?

Change filetype of one-sided PDFs

NOWIKI

Syncing of Reading List Across the App and Website

Report a page

Watchlisting a specific user’s contributions

Making Wikipedia More Welcoming To The Modern User

Citation needed tagging in VisualEditor

Suggestion: reverts should be sourced as well

Net worth values in IBs

New user right (edit request reviewers)

formating article export

Watchlist folders

Adding new language option as Indian English

Hide custom signatures for new editors

Dealing with off-wiki campaigns with the power of upvotes

minor edits in watchlist

Article talk pages

Radical reform of DYK

Two concrete proposals, do or die (IMHO)

Smaller reform suggestion: split the review

Evaluating page quality

Absolute/Perfect Pitch

Talk page not accessible to unregistered, mobile users?

Help provide thoughts and ideas about the formation of the Movement Charter drafting committee in advance of Global Conversations on 26 and 27 June

1. What composition should the committee have in terms of movement roles, gender, regions, affiliations and other diversity factors?

2. What is the best process to select the committee members to form a competent and diverse team?

3. How much dedication is it reasonable to expect from committee members, in terms of hours per week and months of work?

Sometimes AIV is too slow.

Good articles and Featured articles

Make mobile version article segments closeable from the bottom

GnomeHome

WP and Youtube stats cited to Youtube

Extended confirmed users group management

entry's satisfactory?- fluid document component

Add the ability to add a profile picture

Draft talk pages that should be Draft pages

Amending 3RR to ensure that the status quo stands

A kink in AfC workflow

User library