Wikipedia:Village pump (idea lab)/Archive 41

• 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, 57, 58, 59, 60, 61, 62

Creating a mode for infoboxes (abstract/full)

Hi, an infobox is the source of structured data about a concept and is both for humans and machines (in semantic web). For humans, infoboxes should be as abstract as possible and convey only main information to render them to humans "at the first glance". And for machines, it should be as complete as possible, so that machines can answer semantic queries. These purposes seem contradictory. But I have an idea for infoboxes that makes them ideal both for humans and machines

I think the correct policy is: 1-Infobox of an article contains full data as complete as possible (that is for machines), 2-All infobox items are integrated with an additional property, that is, "only for machines"/"only for humans"/"for both" 3-Infobox of an article is shown in "for humans mode" in the default way, to be abstract enough, but it has the capability of changing its mode: i.e. a human can read full infobox data by changing its mode to "for machines mode". When an article is loaded, a full infobox is loaded too, but only some of its items are visible to humans (i.e., those with "only for humans" or "for both" property) at the default mode, but there is an option for viewing it in the "for machines mode".

This way an infobox is appropriate both for humans (convey only main information at first glance), and for machines (contain complete data to answer their queries in semantic web). Please discuss that idea. Thanks, Hooman Mallahzadeh (talk) 10:02, 14 April 2022 (UTC)

@Hooman Mallahzadeh, take a look at the information at Wikidata and Wikipedia:Wikidata. Wikidata is a database for such information and each Wikipedia article has an entry. Just click on Wikidata item in the menu at the left of the article. StarryGrandma (talk) 20:00, 14 April 2022 (UTC)

• I have some quibbles about the premise to this question… while the way information is displayed in an infobox might make it easy for machines to scan and compile our information, that definitely is not the “purpose” of an infobox. I would disagree with saying that our infoboxes are intended to be “for machines”. Blueboar (talk) 21:27, 14 April 2022 (UTC)

An infobox is one source of structured data, but Wikidata usually provides it in a more machine-readable way, especially if you want to consider large numbers of articles (or even topics with no article on English Wikipedia). Tools such as SPARQL can query Wikidata efficiently to produce, for example, a list of German-speaking composers with an OBE. Certes (talk) 21:48, 14 April 2022 (UTC)

@Blueboar@Certes@StarryGrandma These semantics are metadata about that article data, and according to

These embedded semantics offer significant advantages such as reasoning over data and operating with heterogeneous data sources.

and

Specifications such as eRDF and RDFa allow arbitrary RDF data to be embedded in HTML pages.

Structured data should be «««embedded»»» within non-structured data, and ««not be redirected»» (e.g., from Wikidata). As I know Tim Berners Lee (the inventor of web) says "embed" metadata for machines within data for humans. Because this convention is not only for Wikipedia articles, but also for the total Web, to promote it to Web 3.0 or Semantic Web. Hooman Mallahzadeh (talk) 03:11, 15 April 2022 (UTC)

In addition, Wikidata item of an article is not always for a single concept. In current Wikipedia, some articles have more than one concept, e.g. Sine and cosine article. This way, "Wikidata metadata fetching" policy, should be for one of them either Sine or Cosine, and not both of them. But by infobox approach, we can create two infoboxes for each of these concepts, and show/hide one of them (or merge their "for humans" data into a a new infobox). Hooman Mallahzadeh (talk) 03:32, 15 April 2022 (UTC)

Wikidata solves that problem more simply, by having separate sine and cosine items. It also deals neatly with topics such as archaeologist, where the link to Wikipedia is a redirect to an article on a related topic. That article has no infobox and, if it did, it would describe the topic of archaeology, not of archaeologist. Certes (talk) 10:48, 15 April 2022 (UTC)

@Certes Does there exist a mechanism in Wikipedia to fetch Wikidata information and embed that data in a machine readable way (e.g., via "Web Ontology Language" (OWL)) in the articles written in different languages for the same concept? Hooman Mallahzadeh (talk) 11:01, 15 April 2022 (UTC)

Wikipedia:Wikidata#Infoboxes describes the current use in general, and Category:Infobox templates using Wikidata lists the relevant types of infobox. The code tends to be complex, calling subtemplates such as {{Wikidata entity link}} or Lua modules. However, the complexity is mainly aimed at display formatting; the pure data is easily accessible directly from Wikidata via tools such as SPARQL via the Wikidata Query Service (tutorial). Certes (talk) 11:15, 15 April 2022 (UTC)

@Certes Aside from embedding problem, do you agree with me that, till now, Wikipedia writers are not eager to fill Wikidata items? For example in Factorial Wikidata item, that is, https://www.wikidata.org/wiki/Q120976 there exists no item for «parity, date of invention, growth, approximation, its extensions, and related sequences and functions» that there exists in a unstructured way in the main article. We should use a mechanism to make users eager for filling these parts. Today these items are not filled, so we should alarm users fill these parts in Wikidata as complete as you can, to make the article machine readable.

Let me correct the above scenario, at each article, a machine readable infobox is shown from Wikidata to the user that some of its parts is not filled, and the users easily inspect them and make the machine readable infobox as fill as he can. That is we create a "machine infobox" different from "User infobox" that is hidden by default but users can view that, extract the information they need and fill empty parts, and possibly modify incorrect data. Hooman Mallahzadeh (talk) 11:49, 15 April 2022 (UTC)

Yes, Wikipedia writers are not eager to fill Wikidata items. But Wikipedia is not a database and, if it were, we wouldn't want to duplicate the information in every language with all the gaps and discrepancies. One way forward is to create a tool to scrape information from infoboxes of English and non-English wikipedias and add it to Wikidata with appropriate attribution. That way, Wikidata will be up to date for everyone, including any infobox designers who wish to draw on it for English Wikipedia. (Such a tool may already exist: this idea is unlikely to be original.) Certes (talk) 11:55, 15 April 2022 (UTC)

@Certes You are right, "Machine readable infobox" should have items with "label" and "data" parts. Label part is in English or is translated to other languages, but its data part should be some "id" or "url" (not in English).

If you agree with the benefits of creating a separate infobox for "machines" and embedding that machine readable infobox in articles of the same concept in different languages, please alert that to the developers, to implement that. Thanks, Hooman Mallahzadeh (talk) 12:05, 15 April 2022 (UTC)

@Blueboar@Certes@StarryGrandma As a conclusion, a sperate Machine readable infobox is created and added to all existing articles that its purpose is:

Convert «unstructured data» into «structured data» by that infobox, as much as you can.

Hooman Mallahzadeh (talk) 13:27, 15 April 2022 (UTC)

Meh. Adding a second infobox would just confuse our editors with no benefit for our readers. I don’t really care about the machines. Blueboar (talk) 13:35, 15 April 2022 (UTC)

@Blueboar No, it has many benefits for human readers. They know: "what parts of the infobox is free", and "what parts are wrong to modify that". Additionally a normal person (not a machine) may only want, for example, domain of the factorial function and nothing else, which exists only in the second infobox not the first infobox (after making it human readable by a simple process). Note that redirecting to Wikidata is a bad solution becasuse they are not in an infobox and is hard to read, also is not embedded to articles for machines, discussed above. Hooman Mallahzadeh (talk) 13:47, 15 April 2022 (UTC)

@Blueboar Note that second infobox is «hidden» by default, but the user can view that, so makes no confusion. Hooman Mallahzadeh (talk) 13:50, 15 April 2022 (UTC)

Um… The entire point of WP is that our editors can modify anything (as long as there is consensus to do so). This includes the information in infoboxes. Blueboar (talk) 14:09, 15 April 2022 (UTC)

Asides from d:Main there is also DBpedia which tries to structure Wikipedia infoboxes. Hope that helps ~ 🦝 Shushugah (he/him • talk) 20:07, 29 April 2022 (UTC)

Simple English Wikipedia.

m:Proposals for closing projects/Closure of Simple English Wikipedia (3). And the two proposals before it. They happened, they did not find consensus, but there were some good ideas in there.

One idea I had (or may have accidentally stolen, I don't know) is to add some sort of ambox or other notice to articles with simplewiki translations - similar to what Uncyclopedia does about us. (Yes, I did just unironically suggest we emulate Uncyclopedia for something.)

Thoughts? Is this even within the scope of Village Pump? casualdejekyll 00:37, 30 April 2022 (UTC)

Worth noting that LangCom said that they "certainly likes the idea of Simple English content being more accessible from English Wikipedia" but that it was a "matter for the communities to decide, not LangCom."

I don't know of any followup to that? casualdejekyll 00:49, 30 April 2022 (UTC)

For more context, I think this is the most recent proposal along these lines: Wikipedia:Village pump (proposals)/Archive 165 § New approaches to "Simple English Wikipedia". isaacl (talk) 01:00, 30 April 2022 (UTC)

A proposal which gained a good two or three opposes with almost everyone else supporting at least in concept - before magically fizzling out, as these things tend to do. Soumyabrata's merge idea also addresses most of the concerns but it would require consensus from simplewiki, which is unlikely to be attained from what I can gather. casualdejekyll 01:06, 30 April 2022 (UTC)

3RR warning

Do we have anything to warn an editor when they've reverted a page three times in 24 hours and are about to edit the page again? I realise that there would be false positives (fourth edit not a revert, fourth reversion of vandalism, etc.) and false negatives (fewer edits can still constitute a war) but it might still be a useful warning. Certes (talk) 12:25, 5 May 2022 (UTC)

Just the warning templates. A popup warning that shows when you're editing a page where you already have three edits tagged "Manual revert" or "Undo" or "Rollback" in the last day is probably technically feasible, but I wouldn't hold my breath waiting for it. —Cryptic 12:51, 5 May 2022 (UTC)

Thanks. I now see that my words "warn an editor" were ambiguous. I didn't mean one editor manually warning another after the fact with {{uw-3rr}} or similar (though that's a perfectly reasonable interpretation of what I wrote.) I meant that when I open a page I've already reverted three times today, it might be nice if something similar to an editnotice popped up to ask if I really want to do this. It shouldn't actually stop me reverting someone who replaces an article by "poop" for the fourth time, but a warning might be helpful. Certes (talk) 19:20, 5 May 2022 (UTC)

Your initial proposal wasn't very clear. But I think a popup asking "are you sure you want to revert again?" after n number of reverts in a certain time frame might help people stop for a second and think twice before starting an edit war. Usually some ways to de-escalate are always possible. {{u|Gtoffoletto}}  ^talk 12:06, 6 May 2022 (UTC)

@SGrabarczuk (WMF), @Trizek (WMF), which Product team do you think would be most interested in this idea? I'm not sure if it would be small enough for CommTech, so maybe Growth or Editing? Whatamidoing (WMF) (talk) 20:00, 6 May 2022 (UTC)

Sounds like a case for the abuse filter to me... SGrabarczuk (WMF) (talk) 20:29, 6 May 2022 (UTC)

Oh yeah something like this was tried at Wikipedia:Edit_filter_noticeboard/Archive_7#Filter_1053 using the edit filter. One thing that would be nice is if edit filters could see tags (phab:T206490), otherwise this isn't quite possible to implement yet. Galobtter (pingó mió) 20:36, 6 May 2022 (UTC)

I feel like any implementation of this would be counterproductive. If this ever fails, people would argue that they shouldn't be blocked because they didn't get a warning that they had already reverted thrice (or perhaps that they didn't get warned that an article is actually under WP:1RR). Edit warring is also very much possible without violating 3RR, and in fact that's the more important and harder form of edit warring to avoid. To be honest there probably already is too much emphasis on WP:3RR rather than the need to discuss rather than revert regardless of the number of reversions made (and this would further that notion). Galobtter (pingó mió) 20:12, 6 May 2022 (UTC)

Perhaps it could be a user script that people can install to show they like to edit war. —Kusma (talk) 14:24, 9 May 2022 (UTC)

I'm thinking of cases like Lanka Premier League. There, an editor with dynamic IP (and on mobile, so THEYCANTHEARYOU) repeatedly adds bad links in good faith. I fixed them three times but, as it's not vandalism, I've now given up. However, the links appear on daily reports I work from, so I must carefully remember not to fix them again. Certes (talk) 14:54, 9 May 2022 (UTC)

Namespace aliases

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.

---

I'm thinking of proposing an RfC that would add more aliases to Wikipedia. Aliases are shortcuts to namespaces that automatically become the full name. The one you probably use the most is WP: (WP:xyz becoming Wikipedia:xyz once typed). The currently existing aliases are the following: WP, Project, WT, Project talk, Image, Image talk. The main alias I want to propose is T: for the Template mainspace. This would also require deletion of the "T:" pseudo-namespace, which currently exists to create shortcuts for templates. They would still serve the same purpose though, for example: T:DOC currently leads to Template:Documentation, but under the change to alias, would lead to Template:DOC, which still leads to the same place (Template:Documentation).

I would also like to propose C: and CAT: as aliases of Category. "CAT:" is also an existing pseudo-namespace; it would be repurposed like "T:". Some more ideas to throw out for aliases: M: for Module; D: for Draft; or U: for User.

The reason I'd like to propose these is because they would be used for namespaces untouched by the casual reader, so would never inhibit usability for readers. As well, they're extremely useful as a short form and aid in typing forum messages. Anyone currently wanting to use the full namespaces names would be unnafected since the aliases are only a shortcut. Please let me know your thoughts! — PerfectSoundWhatever (t; c) 03:47, 9 May 2022 (UTC)

You cannot use C:, D: and M: because they are sister project prefixes for Commons, Wikidata and Metawiki respectively. U: is unnecessary, User is already short with just 4 letters and does not need be to shortened further. Regarding T: for templates, there will inevitably be confusion about whther it links to Template: or Talk: namespace. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:22, 9 May 2022 (UTC)

See first, Wikipedia:Perennial_proposals#Create_shortcut_namespace_aliases_for_various_namespaces. — xaosflux ^Talk 09:45, 9 May 2022 (UTC)

My bad haha, I should have checked that before posting. I'll close this thread now. — PerfectSoundWhatever (t; c) 17:00, 9 May 2022 (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.

Draft RFC: Bot to blank old IP talkpages

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.

---

This would be an RFC to propose blanking old IP talkpages and replacing it with {{OW}}, which I am planning to do using MalnadachBot. Considering that this will affect at least 1.5 million talkpages, I thought it is better to hold an RFC to find consensus before submitting a WP:BRFA. I guess this would be the RFC text -

Should a bot be used to blank old IP talkpages which:

• Have not received any messages in the last 5 years
• The IP is not under active blocks
• There have been no edits from the IP in the last 5 years

Pages that meet this criteria will be blanked and replaced with {{OW}}, which reads

Background

There are millions of IP talkpages with vandalism warnings received since the earliest days of Wikipedia. Recent vandal warnings serve a useful purpose, but warnings from very long ago are detrimental as there is a high chance that the IP address would have shifted to different users. Stale warnings and other messages will confuse legitimate new editors editing from that IP seeing it apparently directed at them. Blanking the page and replacing it with {{OW}} template will avoid confusing legitimate editors, while still allowing access to potentially useful edit history. Other benefits of this task will include uncluttering the Special:WhatLinksHere data for articles.

This will involve the bot editing at least 1.5 million pages. If consensus is found for this proposal, I (or anyone else) can submit a Bot request for approval to carry it out subject to the usual WP:BAG approval. --ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 15:30, 5 May 2022 (UTC)

---

I guess I can exclude pages that have a block notice or give different options for how long ago to consider messages as stale. Feedback is welcome. --ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 15:30, 5 May 2022 (UTC)

I would add to that that previous discussions have yielded a reasonable time frame of around five years of inactivity by the IP or on the talk page as a threshold for which it is safe to template the page (it is not entirely blanked, as the template notes the existence of a page history). Also noted in previous discussions, templating old IP talk pages reduces a lot of "What links here" clutter, making it easier for those pages to be searched for relevant links. BD2412 T 15:38, 5 May 2022 (UTC)

Seems like a good idea to me. Since this is the idea lab, may I suggest creating a new specific template for this purpose? I feel like since part of the point of the proposal is to be more welcoming to new users, it would be good to workshop the language a little bit so it is very clear to newbies what it means. Maybe something like "This is the talk page for an IP address. Users of this IP address have been warned for inappropriate behavior prior to (DATE). Since IP addresses change and current users of the IP address are likely not the same individuals, these warnings have been archived to (LINK)." CapitalSasha ~ talk 15:53, 5 May 2022 (UTC)

I think this can be a good idea, but implementation is the key. Some things to consider:

• Do we want to archive based on how old the warnings themselves are, or how old the most recent warning is, or how long it has been since the IP has been active?
• Under what circumstances would we not want to archive such pages? Pissing off stable IP users, who may be editing under the same IP for years and having some random bot show up to blank their talk page seems unwise. Do we need to enact an "opt-out" system, or will the bot be able to be smart enough to recognize the subtleties of stable vs. dynamic IPs, and stable IPs with one user (like a home computer) vs. stable IPs with many users (like a library or school)
• We need to be careful to archive only warnings and other discussion threads; we don't want to blank the page and remove things like SharedIP headers and the like
• Do we want to start archive subpages like logged in users do, or do we want to just blank and let the page history serve that purpose?

• I'm not opposed in principle to such a bot task, but I do think you can do this well, or you can do it very badly, and I wouldn't want to try to clean up the messes of the latter. This is the kind of thing we need to get right going into... --Jayron32 16:13, 5 May 2022 (UTC)

  Archival of IP talkpages is rarely done. Most of them do not have any content worth preserving. We can just point users to page history to read old contents. I think shared IP headers can be removed if it is older than 5 years as anything older than that can be assumed to be outdated. As for opting out, that can be done by making the bot exclusion compliant to {{nobots}} template. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:35, 6 May 2022 (UTC)

• Good idea, but let's use a carefully worded new template. The existing one tends to be added manually when an IP repeatedly blanks warnings, and may have become associated with wrongdoing despite its "or other comments" disclaimer. Certes (talk) 20:32, 5 May 2022 (UTC)

Does this really matter with IP masking coming down the pipeline? No real objection, however. ScottishFinnishRadish (talk) 20:53, 5 May 2022 (UTC)

Nobody knows. One of many unanswered questions is where an IP ends up when they click the Talk link at the top to visit their "own" talk page. Certes (talk) 21:43, 5 May 2022 (UTC)

• Given the comments here, I should repeat what I had said to BD2412, and Malnadach earlier: the blanking should be based on the combination of latest warning, and/or IP's latest contribution. —usernamekiran (talk) 21:55, 5 May 2022 (UTC)
• Not sure I like this, if it has things like active blocks why remove the notice? If it has things like known shared ip notices, school notices, etc - prob not best to remove either. — xaosflux ^Talk 22:26, 5 May 2022 (UTC)

  Also this is already a bit confusing - do you want to only replace some "old warnings" or do you want to blank the entire page? — xaosflux ^Talk 22:28, 5 May 2022 (UTC)

  This should not affect any IPs under active blocks. The page would be blanked if the IP was inactive for over five years and there was no activity on the page itself for over five years. In this context, shared IP notices and school notices should be removed. If there has been no activity in that amount of time, those notices may be out of date and no longer accurate. However, my larger concern is with links to articles from those pages. BD2412 T 01:03, 6 May 2022 (UTC)

  @Xaosflux: Good point about IPs under active blocks. I want to blank and replace the entire page, not just the warnings. If an IP is not currently blocked, has not made any edits in 5 years and has not received any messages in 5 years, its reasonable to assume it is stale and not used by the same person for whom warnings and other messages were directed at. The idea is to remove all stale messages to improve new IP user experience. Say if an IP that was school blocked once 10 years ago has not made any edits in the last 5 years, I think it is safe to remove the notice as well since it is likely outdated. Uncluttering WhatLinksHere data is not relevant to improving new user experience, but will be another benefit of this task. I have modified the text to adress this. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:21, 6 May 2022 (UTC)

  So in talking about uncluttering things like whatlinkshere - why do you want to add 1.5million links to file:ClockIcon.svg and all the parts of that template and its possible modules as well? Wouldn't plain text suffice here? — xaosflux ^Talk 12:46, 6 May 2022 (UTC)

  The difference is this will unclutter WhatLinksHere data for tens of thousands of articles and pile it on one template. FWIW File:ClockIcon.svg already has 619k links [3]. Alternately we can create a template with new wording as others have mentioned above and make it text only. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:11, 6 May 2022 (UTC)

  I don't think we need an included file, but moreso I'm suggesting we don't need a template at all, just use plain text if this is going to happen. — xaosflux ^Talk 13:15, 6 May 2022 (UTC)

  Using the template allows for tracking which pages have been templated. There does not need to be an icon on the template. BD2412 T 02:55, 7 May 2022 (UTC)

One thing I would be worried about is that this is going to essentially trigger a wave of "you have new messages" for readers on those 1.5m IPs, which will be a bit confusing for them (and the number that follow the link will then find they don't have a message, confusing them further). Is there any way to suppress that for this cleanup task? I don't see a problem with it itself, but the side-effects might be a headache. Andrew Gray (talk) 20:06, 6 May 2022 (UTC)

I think minor bot edits are ignored for talk page notifications. Galobtter (pingó mió) 20:13, 6 May 2022 (UTC)

Ah - that makes sense! I had a vague recollection there was some way to suppress it but couldn't find a ref and hadn't realised it was as simple as bot+minor. In that case, no objections, all sounds a decent idea. Andrew Gray (talk) 20:32, 6 May 2022 (UTC)

• Considering the comments above, I have created {{Blanked IP talk}} to be used instead, which displays

Unregistered editors using this IP address received messages on this talk page years ago. Since users of the IP address have likely changed, these messages have been removed. They can be viewed in the page history.

Since the plan is to remove all stale messages and not just warnings, I have not used the word "warning" in the template. Courtesy ping to Certes and CapitalSasha. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 12:26, 7 May 2022 (UTC)

That template looks good. It's a little verbose, but I can't see how to shorten it significantly without losing useful meaning. Certes (talk) 12:33, 7 May 2022 (UTC)

Shortened wording in a way I think makes sense, feel free to revert if you dislike. — PerfectSoundWhatever (t; c) 04:09, 9 May 2022 (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.

A solution to the template graveyard of retired users

The other day, I was reading Ritchie333's essay, Don't template the retirees. The essay rang true; I've seen it happen far too often for retired users. As Wikipedia's standards increase, and old articles and files don't make the cut, the talk pages of retired users contain Twinkle notification after Twinkle notification about images and articles being proposed and nomination for deletion.

I think that we should be able to place a box on the talk pages of users who haven't edited in, say, two years. It'd be a small box. If the box exists, instead of Twinkle leaving a large new message at every new PROD and XfD, it would simply add the nomination page to a bulleted list, maybe separated by category. Something like this:

{{Twinkle box|
 ;AfD
 * [[Wikipedia:Articles for deletion/Article 1]]
 * [[Wikipedia:Articles for deletion/Article 2]]
 ;CSD
 * [[Article 3]]
 }}

and so on. Users would still get a "you have a talk page message" notification, but the template graveyard would shrink significantly because closed nominations would be removed from the box. Thoughts, suggestions? theleekycauldron (talk • contribs) (she/they) 22:13, 4 May 2022 (UTC)

I think anyone templating Neelix (talk · contribs) probably needs to stop - all they're doing is filling up server disk space. Ritchie333 ^{(talk) (cont)} 22:47, 4 May 2022 (UTC)

I'm not sure I like the solution, though the problem certainly should be solved. How about implementing the retiree status somehow into twinkle (since it's the main source of the problem, as you don't have to visit the page to send the warning). I don't know if this is technically possible, but if twinkle could check for Category:Retired Wikipedians, it could automatically uncheck the box that says "notify page creator if possible" (e.g. during a PROD nom), and put a "(retired user)" notice next to that. Also, if you decide to click the checkbox, maybe a yes/no alert could come up like: "this user is retired, are you sure you want to send a talk page message?" — PerfectSoundWhatever (t; c) 04:14, 9 May 2022 (UTC)

Why does this problem need solving? There are some retired/blocked/dead users who still have talk page stalkers that can (and sometimes will) react to notifications. —Kusma (talk) 14:14, 9 May 2022 (UTC)

I do not see this as a problem that requires a formalized solution. Some retired editors seem sincere and if they depart for years or forever, who cares if notices pile up on their user talk page? But many times, these "retirements" are temporary and revocable, like the five year "retirements" of major rock stars who cannot resist the urge to "return from retirement" to earn umpty-ump millions of dollars on a world tour. Our retiree editors return for ego and attention more so than money, but it amounts to the same thing. I oppose, on principle, any policy or guideline that recognizes "retired editor" as a formal status in any way. Cullen328 (talk) 06:31, 10 May 2022 (UTC)

(undo | discuss | thank) next to all edits

Tracked in Phabricator
Task T287833

We give users an easy way to revert edits in each article's history. Why not add the ability to quickly open a new discussion regarding an edit with a reference to it already included? Might help encourage the WP:BRD cycle. {{u|Gtoffoletto}}  ^talk 19:25, 3 May 2022 (UTC)

This seems like an interesting idea. It might be technically a bit odd with respect to how we handle redirected talk pages in some of the non-article mainspaces, though this feels like something that can be pretty easily overcome. — Mhawk10 (talk) 19:32, 3 May 2022 (UTC)

I really like this idea. I think that the devs could implement this rather easily, and it would really help. The button simultaneously could do any number of things, such as starting a talk-page section, pinging or notifying the relevant user on their user talk page, etc. etc. If it was clearly visible next to every edit in both the diff view and article history view, it may encourage users to use the talk page rather than edit summaries for communication, and may cut down on revert wars. I dig it. --Jayron32 12:37, 4 May 2022 (UTC)

I like this too. Right now it is more "convenient" to hit the undo button and discuss using the edit summary, so making it easier to discuss edits, especially for new users would be great. Could be done as part of the whole mw:Extension:DiscussionTools thing. Galobtter (pingó mió) 20:21, 4 May 2022 (UTC)

I adore this idea as it encourages dialogue, something we need more of. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 20:23, 4 May 2022 (UTC)

hi y'all – what a wonderful idea! While I don't have much to add in this moment beyond linking a relevant Phabricator ticket , I wanted to stop by to express/communicate the interest the Editing Team has in the discussion y'all are having here ^ _ ^ PPelberg (WMF) (talk) 00:28, 5 May 2022 (UTC)

Without wishing to hijack the thread, another place that (undo|thank) would be very useful (with or without |discuss|) is in Special:Contributions. With popups and similar tools, I've often assessed the edit already but have to click (diff) and load a whole page purely to get the undo or thank link. Certes (talk) 00:39, 5 May 2022 (UTC)

Half of that is here: phab:T51541 — xaosflux ^Talk 01:11, 5 May 2022 (UTC)

@Gtoffoletto Is there a particular edit/talk page discussion that brought this idea to mind for you? If so, are you able to share a link to that exchange so that I can more clearly imagine the scenario(s) you could see this functionality be useful in?

Also, @Mhawk10, @Jayron32, @Galobtter, and @Ixtal, a similar question for y'all: are you able to share a particular scenario when you could imagine yourself valuing the ability to start a discussion directly from the history page? PPelberg (WMF) (talk) 15:23, 5 May 2022 (UTC)

From my point of view, when viewing a diff or when viewing the history page, if there is something one doesn't like, agree with, or perhaps understand, there is an impetus to respond in some way. Right now, when you're looking at the diff/history page all you see is edit summaries and the only option your really given is to undo the other person's edit. The interface in this way almost encourages people to manage disagreements through revert wars, as it doesn't obviously present another option. I posit that it would be an interesting psychological effect to have the "discuss" option sitting right next to the "undo" option... it wouldn't necessarily fix every edit war, but I think that would give enough people just long enough of a pause to consider more civil ways to solve disputes. If even a few of them click "discuss" instead of "undo", it will have headed off a lot of potential problems and I think would be considered a success. --Jayron32 16:06, 5 May 2022 (UTC)

A specific situation in which I saw an edit and made a discussion about that edit occurred after this edit was made to Lakewood Township, New Jersey. I opened a discussion on the talk page in response, specifically citing the edit and pinging the editor who made it. — Ⓜ️hawk10 (talk) 16:14, 5 May 2022 (UTC)

This would help with any edit war, since per WP:BRD the general rule is to discuss after one revert, but right now that can be a bit of a hassle to do. Specifically in controversial areas like American politics where I did a decent amount of editing, "copy the diff to the talk page and ping the other user" is something that already happens and something people do, but that happens more because it's basically mandated in that area. I myself have thought it would be nice to have a way to automatically discuss an edit while editing that area, every time I have to manually start a discussion (the urge to just hit the undo button is strong lol). I think having a discuss button would satisfy the urge to respond as Jayron mentions, and make discussing edits "endorsed by the software" while currently undoing is the software endorsed way of handling an edit, and the talk page is relegated to a secondary role. Galobtter (pingó mió) 18:49, 5 May 2022 (UTC)

@PPelberg (WMF): Agree with what was said above and I'm glad people like this idea. The point is: let's make it easy for people to start a discussion. Users will often prefer the "easy way" to the "right way".

• Right now reverting an edit requires one click and is very easy.
• Discussing an edit is a long and complex process (I need to copy the link to the edit, go to the talk page, open a discussion, tag the user, etc. etc.).

Most people will lazily revert instead of discussing an edit and this leads easily to edit wars. -- {{u|Gtoffoletto}}  ^talk 11:20, 6 May 2022 (UTC)

In general I think reverting has a very negative impact on the author of the edit. It is very demotivating and frustrating. If we can encourage dialogue good things will happen. This feature would encourage constructive criticism of edits instead of total rejection of an editor's work.

Typical scenarios:

• Someone makes and edit. Someone reverts it with a long motivation. The temptation is to revert again and reply with an edit description. Usually this leads to another revert and an edit war. Why not start a discussion straight away?
• Someone makes and edit. Someone reverts it with an unclear motivation. Asking for more information is a hassle so the temptation is either to counter-revert or to just give up on the edit. With one click discussion you can just ask for an explanation.
• I notice an edit with some problems (maybe it's a big one). It's easier to just revert all of it rather than start a discussion and maybe prompt the author to make some improvements. {{u|Gtoffoletto}}  ^talk 11:36, 6 May 2022 (UTC)

I also mention some new editors may not even know where the talk page is or how to get there, maybe even how to start a discussion. Yes the buttons are there and feel kind of obvious to us but I know many more friends that don't participate in the wiki that know about the history tab (stuff like "It's cool how you can see all instances of an article, like see what Obama's article was in 2006") than know about the talk page. Having the button there would avoid instances of edit-warring by newbies and IPs that may not even know there is an alternative to warring. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 12:18, 6 May 2022 (UTC)

• I like the idea a lot, though I feel like it should only exist in mainspace articles (since you usually don't discuss edits like that in any other namespace, except maybe Wikipedia) — PerfectSoundWhatever (t; c) 04:17, 9 May 2022 (UTC)
• Next steps: I think the feedback has been pretty positive on this idea and no major objections have emerged. @PPelberg (WMF): does the Phabricator ticket you linked above mean that this feature will be considered for development or should I move this discussion to the WP:TECHPUMP? Thanks! -- {{u|Gtoffoletto}}  ^talk 13:28, 9 May 2022 (UTC)

  @Gtoffoletto the tickets related to this (e.g. phab:T51541 and phab:T287833) indicate that the change you want to see would require upstream software development. As such, it is not something the English Wikipedia can fix directly, so forking this to WP:VPT isn't going to make it happen. There are many, many, many software feature requests open - some for over 10 years. See mw:How to contribute for more information on how to contibute, even for how you can volunteer to work on this yourself. You could also list it at meta:Community Wishlist Survey/Sandbox to work on trying to getting support during the next (2023) Community Wishlist process. — xaosflux ^Talk 13:40, 9 May 2022 (UTC)

  Thanks! Just wanted to make sure some support for this feature had been recorded somewhere. I looked at the Community Wishlist Survey but couldn't figure it out fast enough. I guess the comments in the Phabricator ticket will do some good. If anybody knows of any way I can help push this forward let me know! Would be a neat little feature to have. {{u|Gtoffoletto}}  ^talk 17:38, 10 May 2022 (UTC)

Improving redirects to sections of a page

One problem with redirecting text to a specific section of another page is that it's possible for an article to be restructured, changing the names of sections - and thus where the redirect links. As such, I propose we make it policy to have some form of {{anchor}} template be linked to instead of a section name, and have a bot update pages (and creating lists for manual editing. Anchor templates make it clear that a section is linked to, and, if we're clever, we can add a list of the redirects that link to the anchor by adding a linked from= property that was bot updated. It wouldn't need to do anything, it'd just be a reference for if the page got edited. Adam Cuerden ^(talk)_{Has about 7.8% of all FPs} 17:11, 10 May 2022 (UTC)

See WP:TARGET and MOS:SECLINK. We already have such guidance. Note that the existence of any guideline or policy has next to zero effect on people knowing about its existence. New users will always exist who don't know about those policies, and they will edit in good faith, sometimes for a very long time, before someone points them out. More policies will never change that, indeed more policies make it harder for people to keep track of any of them. --Jayron32 13:21, 11 May 2022 (UTC)

Cewbot 6 tidies up many such problems. Certes (talk) 13:32, 11 May 2022 (UTC)

A different approach from Cewbot 6 would be to periodically scan redirects with # in the target, check to see if # is an anchor name or a section title, and if it is only a section title change the section title to hold an anchor. Thus

==Section title==

becomes

=={{subst:Anchor|Section title}}Section title== <!--- please do not remove or rename the anchor, which is the target of redirects-->

Adding {{anchor}} code to many articles would help teach editors about the functionality. Aymatth2 (talk) 14:25, 11 May 2022 (UTC)

Would it be better to put the anchor on the line under the section title rather than next to the section title? Code is arcane for many users, and it can be confusing to edit articles if it is cluttered up with template code like this. I would rather see the anchor tag under the title rather than buried on the same line next to it. --Jayron32 15:46, 11 May 2022 (UTC)

WP:TARGET shows it coded this way. If it goes under the title the title will not show in the viewing window after a rename, e.g. (in a small viewing window) #Improving redirects to sections of a page renamed, which could be confusing. It could go before the title.

{{subst:Anchor|Section title}}<!--- please do not remove or rename the anchor, which is the target of redirects-->

==Section title==

Aymatth2 (talk) 17:07, 11 May 2022 (UTC)

I do like that guidance better. Parsing the edit window is hard enough as it is. If you have obscure code like that placed inside the header text, it can be really hard to figure out what is going on. Placing it before the header on its own line seems like a better solution. --Jayron32 17:36, 11 May 2022 (UTC)

Agreed. Do you think the anchor should be named the section title, or should it be the name of the redirect (where possible)? It might lead to a clustering of anchors, but it'd make it clear exactly what the incoming redirects were. Mind you, do you mean to have the subst: in there? It says to do that in section titles, but not necessarily in lines below them.

One possibility might be to have a dummy parameter, e.g. {{Anchor|Section title|linked from=Redirect1, Redirect2, Redirect3}} Adam Cuerden ^(talk)_{Has about 7.8% of all FPs} 17:47, 11 May 2022 (UTC)

Technically, the anchor should have a different label than the section title, so that they will have different underlying HTML IDs, as every instance of an ID on a web page is supposed to be unique. (In practice, I imagine all browsers will jump to the first instance of the ID, but I don't know if anyone's tested this.) isaacl (talk) 20:04, 11 May 2022 (UTC)

That has been tested and the browsers do all go to the first occurrence of the anchor. But it is technically bad HTML. I personally like short all caps anchors like IMPREDIR for this discussion, because other editors are unlikely to "correct" them. Aymatth2 (talk) 20:51, 11 May 2022 (UTC)

I should have put it another way: there's a risk in depending on undocumented behaviour of browsers for invalid HTML, since it could in theory change in future. Personally I don't like short all-caps anchors; I find them more difficult to read. isaacl (talk) 15:14, 12 May 2022 (UTC)

If the same id occurs twice in the same HTML doc, and a link containing a matching fragment is followed, all browsers that I've tried will jump to the first instance of that id without either offering a choice or indicating an error condition - I know of none that behave differently. This doesn't change the fact that duplicate ids are forbidden. --Redrose64 🌹 (talk) 15:35, 12 May 2022 (UTC)

Sure, all the browsers I've used behave the same way. Yes, I already said that duplicate IDs are disallowed. isaacl (talk) 15:39, 12 May 2022 (UTC)

A problem when the anchor is placed before the section title is that when someone uses the section edit link, they won't see the anchor. On the one hand, that means they won't change it, but on the other, it disconnects the anchor from the corresponding section, and someone might change it when they edit the preceding section. When it's a user space or Wikipedia space page I think it's manageable, but for a mainspace page I feel it's better to put the anchor within the corresponding section. isaacl (talk) 19:57, 11 May 2022 (UTC)

@Aymatth2: Please don't suggest that HTML comments should be placed after the section title markup. This breaks the auto-generated edit summary should that section be subsequently edited. --Redrose64 🌹 (talk) 15:12, 12 May 2022 (UTC)

The markup

==Section title==

emits the HTML

<h2><span class="mw-headline" id="Section_title"><span id="h-Section_title"></span>Section title<span></span></span></h2>

(the section edit links and the data-... attributes are omitted, because neither has any bearing on the matter). This has two id= attributes, and they are different; whereas the markup

=={{subst:Anchor|Section title}}Section title==

emits the HTML

<h2><span class="mw-headline" id="Section_title"><span id="h-Section_title"></span><span class="anchor" id="Section_title"></span>Section title<span></span></span></h2>

with three id= attributes, two of which are duplicates - this is invalid HTML where ids must be unique within a document. If there is a perceived existing problem, please don't suggest solutions which create problems of their own. --Redrose64 🌹 (talk) 15:34, 12 May 2022 (UTC)

WP:TARGET suggests =={{subst:Anchor|anchor name}}Section title== and notes that

"When a section title is known to be the target of incoming links, the Wikipedia Manual of Style suggests creating a redundant anchor with the same name as the section title, so that such links will continue to work even if someone renames the section without creating an anchor with the old name. Technically, the redundant section and anchor names result in invalid HTML. However, when a document contains multiple tags with the same id value, browsers are required to return the first one, so in practice, this is not a problem.".

I had no idea a comment on the heading line would cause problems. It could follow the heading line:

=={{subst:Anchor|Section title}}Section title==

<!--- please do not remove or rename the above anchor, which is the target of redirects-->

Aymatth2 (talk) 17:08, 12 May 2022 (UTC)

This is just an aside, but the cited reference regarding browsers being required to return the first element with a specified element ID is for Javascript code. I'm not aware of a specification for how browsers should behave when accessing an URL with a fragment ID that isn't unique for the returned HTML page. isaacl (talk) 19:58, 12 May 2022 (UTC)

Before this goes too far down the "where to place it" road, or why it should be substd, participants should review the several previous discussions on the matter that have led to the present guidance at Template:Anchor/doc. These include (but are not limited to): Template talk:Anchor; Wikipedia talk:Manual of Style; Wikipedia talk:Manual of Style/Accessibility; Wikipedia talk:WikiProject Accessibility, also the archives of all of these. --Redrose64 🌹 (talk) 17:17, 12 May 2022 (UTC)

Genuine question (and suggestion): I've seen automatic categorisation of several pages if they satisfy certain properties. Can we create such an automatic categorisation if the section found in the redirect is not found in the target page? For example a Redirect page "Loren Ipsum" redirects to the page "Foo#Bar". If section "Bar" is edited or eliminated, the page is automatically categorised for manual review. This may eventually lead to retargeting or RFD. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:06, 12 May 2022 (UTC)

That sounds like a job for a bot, possibly something for Cewbot or similar to do when it detects a problem that it can't solve automatically. Certes (talk) 18:01, 12 May 2022 (UTC)

I think, if possible such a list in a * {{no redirect|Lorem ipsum}} → [[Foo#Bar]] format would certainly help manual reviewers. —CX Zoom[he/him] ^{(let's talk • {C•X})} 10:47, 13 May 2022 (UTC)

References

Drafting of stand-alone page criteria for WP:NGEO, based on feedback at recent RfC

Hi! From the recent RfC at WP:VPP that I started, it seems to me editors would find it helpful for me to propose a specific criteria to be voted on. To draft this I'll need help from other editors as I've never really proposed notability policy changes before. Pinging editors previously involved in this discussion that were (IIRC) in favor of or willing to discuss changes: @Uncle G, Mhawk10, Theknightwho, Donald Albury, Redrose64, North8000, BilledMammal, and Aymatth2. Also pinging JPxG as someone whose work exemplifies why I think the notability of geographical features itself makes sense, and who can provide a useful perspective on taking geostubs to FA level articles.— Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 00:24, 3 May 2022 (UTC)

@Jayron32: as they indicated interest in helping out here in their RfC vote. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 00:26, 3 May 2022 (UTC)

Per WP:N:

A topic is presumed to merit an article if:

1. It meets either the general notability guideline (GNG) below, or the criteria outlined in a subject-specific notability guideline (SNG) listed in the box on the right; and
2. It is not excluded under the What Wikipedia is not policy.

The wisdom built into this is that things can be notable and still not be fit for their own article—provided that there is something about the article (or article subject) that runs afoul of WP:NOT. Unless we are to alter the core substance of what amounts to be Wikipedia's inclusion criteria (i.e. modifying point 1 or point 2)—which I am extremely hesitant to support—it might be wise to start thinking about common use cases where WP:NOT might apply to articles about geographic features (or if such use cases exist). — Mhawk10 (talk) 00:59, 3 May 2022 (UTC)

My concern is that we don't create articles that can never be expanded beyond (or much beyond) stub level. For example, while we may have names for a number of different streams in a river basin, it doesn't make sense to create a new article on every one of them, most we won't have more than 2-3 sentences to say. It would make more sense to just include all of these in one article on the main river or river basin in question. Similarly for unincorporated places in a township, county, or equivalent division, peaks in a mountain range, etc. etc. Information is actually easier to find in these ways; creating a new article on ever minor feature creates a fragmentation of text that can actually make it harder to follow. The criteria should always be "do we have enough reliably sourced text to create a decent-sized article about this subject". If so, do it. If not, then it should be included in a larger concept... --Jayron32 11:56, 3 May 2022 (UTC)

What is a good indicator for "enough"? Keep in mind that a wide range of things fall under NGEO, including villages, streams, and train stations. The "larger concept" seems a bit different between them, as well as how much information is needed for the article to be considered decently-sized. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 12:09, 3 May 2022 (UTC)

I think one good metric for "reliably sourced text" is the number of and significant coverage in sources that are not databases. It is also true that This guideline specifically excludes maps and tables from consideration when establishing topic notability (emphasis my own, from NGEO) is almost never enforced, really. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 12:13, 3 May 2022 (UTC)

It also excludes GNIS and GEONet ("WP:GNIS and GEONet Names Server do not satisfy the "legal recognition" requirement and are unreliable for "populated place" designation.") We should consider expanding that to include any database. As it stands, we have a lot of articles that do not meet the current GEOLAND requirements. If we want to tighten up the requirements for creating new articles about geographical features, I think we also need to clean out all the articles that do not, and likely never will, meet the minimum notability requirements. I did successfully prod Hasan, Florida last year. It was created in 2008 and had been edited 72 times, but when I prodded it, it consisted of the sole sentence, "Hasan, Florida is an unincorporated community in Alachua County, Florida, United States." The only source cited was hometownlocator.com. Yet, I spent considerable time searching unsuccessfully for any reliable source that mentioned it before I felt comfortable prodding it. I would be happy if we could make it a little easier to remove articles about places that are unlikely to ever meet the GNG. That would also help in preventing such articles from being created in the first place. - Donald Albury 13:37, 3 May 2022 (UTC) — Preceding unsigned comment added by Ixtal (talk • contribs)

It also excludes GNIS and GEONet ("WP:GNIS and GEONet Names Server do not satisfy the "legal recognition" requirement and are unreliable for "populated place" designation.") We should consider expanding that to include any database. As it stands, we have a lot of articles that do not meet the current GEOLAND requirements. If we want to tighten up the requirements for creating new articles about geographical features, I think we also need to clean out all the articles that do not, and likely never will, meet the minimum notability requirements. I did successfully prod Hasan, Florida last year. It was created in 2008 and had been edited 72 times, but when I prodded it, it consisted of the sole sentence, "Hasan, Florida is an unincorporated community in Alachua County, Florida, United States." The only source cited was hometownlocator.com. Yet, I spent considerable time searching unsuccessfully for any reliable source that mentioned it before I felt comfortable prodding it. I would be happy if we could make it a little easier to remove articles about places that are unlikely to ever meet the GNG. That would also help in preventing such articles from being created in the first place. - Donald Albury 14:02, 3 May 2022 (UTC)

The part that you are quoting is a top level statement of the entire wp:notability system. I don't think that you are proposing changing that. I thought that you were proposing tightening up the NGEO SNG a bit which I think would be a good thing. Sincerely, North8000 (talk) 13:11, 3 May 2022 (UTC)

North8000 what part am I quoting, or do you mean Mhawk10? — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 13:12, 3 May 2022 (UTC)

Thanks for the catch. I mistakenly thought that you wrote that so I struck that part of my comment. Sincerely,North8000 (talk) 14:16, 3 May 2022 (UTC)

North8000 tightening the notability criteria is something that could be explored, but I find it both unlikely to gain traction and be highly complicated to carry out. If you have any ideas, however, feel free to share :) — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 14:23, 3 May 2022 (UTC)

I thought that was what you are proposing developing/doing. If not, what do you have in mind? North8000 (talk) 14:28, 3 May 2022 (UTC)

North8000 the notability criteria in my mind is more of a theoretical ideal than a practical manual. The issue is not that we have many articles about villages, but rather that we have too many of them, cited too weakly (e.g. only to a single database), and too few editors to address that issue. Changing the notability guideline to something more strict is likely to be of detriment to our readers if it leads to mass AfDs of villages, but by encouraging merging information to parent articles (as NOPAGE does), we can reduce the unmanageable number of geostubs through a constructive rather than destructive method. Then, when an editor wants to expand the redirect into an article and has enough sources to do so, they do not have to pass through extra hoops. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 14:51, 4 May 2022 (UTC)

The essence of this discussion seems to be whether we can provide guidelines on when notable geographical topics should have standalone pages and when they may be better part of a broader article. I suggest we should add a section to Wikipedia:NGEO:

== Whether to create standalone pages ==

As stated in WP:NOPAGE, "Sometimes, understanding [of a notable topic] is best achieved by presenting the material on a dedicated standalone page, but it is not required that we do so. There are other times when it is better to cover notable topics, that clearly should be included in Wikipedia, as part of a larger page about a broader topic, with more context." For example, a river may have several tributaries that are technically notable meet the notability criteria defined in WP:NGEO, but where there is little to be said about some of them. The article on the river may include a list of tributaries, and there may be standalone articles for some tributaries and redirect articles pointing to the list entries for other tributaries. A similar approach may be followed for hamlets in a municipality, shopping malls, railway stations and so on. This does not preclude expanding the redirects into standalone pages if more information comes to light, and also allows us to hold information on sub-topics that are relevant to the main topic but not notable in themselves.

Aymatth2 (talk) 15:26, 3 May 2022 (UTC)

What do you mean by "technically notable". GEOLAND does not automatically make all geographical features notable. It does say, Geographical features meeting Wikipedia's General notability guideline (GNG) are presumed, but not guaranteed, to be notable. Therefore, the notability of some geographical features (places, roadways, objects, etc.) may be called into question. Donald Albury 16:50, 3 May 2022 (UTC)

I have tweaked the wording to be more precise. This approach may help us avoid long discussions about geographical features where notability may be questioned. If there is not much sourced information, put what there is into the parent article, with a redirect to that article. Aymatth2 (talk) 17:46, 3 May 2022 (UTC)

Notability and whether a geographic feature should have a standalone article are only partially overlapping issues. In general, I would say that a geographic feature, even if it is presumed notable, should not have a standalone article until someone has found sufficient reliable sources to write more than a short stub. Geographic features for which sufficient reliable sources have not yet been found can almost always be mentioned constructively in a relevant higher level article. And yes, redirects to such mentions are cheap. Donald Albury 18:06, 3 May 2022 (UTC)

I dislike one-line stubs, but think it will be impossible to get agreement that they should be eliminated. The above proposed wording is probably as far as we can go. It legitimizes merging stubs into parent articles, but does not mandate it. Aymatth2 (talk) 18:32, 3 May 2022 (UTC)

That's kind of the best we can hope, and what I wished to encourage with my original proposal. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 18:35, 3 May 2022 (UTC)

One thing in creating list pages to be aware of: There are going to be particular tributaries and municipalities that can't easily get lumpted into a notable list. WP:NGEO is something that relates to notability of particular features, while WP:NLIST requires lists to have coverage of a group as a whole. Any change to WP:NGEO that directs users to start making lists is going to need a parallel change in WP:NLIST to support it, unless the community desires to create a backdoor to deletion for geostubs through listification. I don't think anybody wants to see weird procedural loopholes created to delete valid content, so it might be wise to more deeply consider how changes to WP:NGEO would intersect with other guidelines before proceeding. — Mhawk10 (talk) 18:41, 3 May 2022 (UTC)

WP:NLIST is pretty fuzzy and really doesn't require coverage of a group as a whole.....it merely says that that is one way "in". Plus it takes work to even organize merge proposals and so I'm not fearing a deletions binge, especially with a "soft" change/addition. I'm not worried about as much about the current geostubs, I'm worried that the low bar used could allow 5 million more to get added. North8000 (talk) 19:00, 3 May 2022 (UTC)

One thing to remember about lists is that, per MOS:LIST, they do not need to be stand-alone. Many of the geographical topics that have been discussed (like tributaries, and also the oft-discussed boroughs) "belong to" an obvious parent article. The best practice might be to create lists as parts of parent articles until a given list reaches some length threshold, rather than defaulting to standalone lists.

As a separate issue, it is probably worth pointing to the potential strengths of annotated lists and searchable lists, in any guidance that is developed here. Newimpartial (talk) 19:07, 3 May 2022 (UTC)

I was thinking maybe Lake Rouge pointing to MacDonald River (Côte-Nord)#Lakes could be given as one example. Aymatth2 (talk) 19:12, 3 May 2022 (UTC)

I was thinking of Alachua County, Florida#Historic communities in Alachua County as an example of one way of incorporating topics of questionable notability in a parent article. Donald Albury 19:21, 3 May 2022 (UTC)

I like the idea. North8000 (talk) 17:02, 3 May 2022 (UTC)

• I like Aymatth2's proposal above. I might also add something to the effect of

For topics which are not in-depth enough to merit a stand-alone article, some better ways to organize the information: 1) Include the information in a relevant related article, for example including a section on tributaries in the article on major rivers, and capturing relevant information on minor tributaries of that river in that section. 2) If the main article is too large already, or may be overwhelmed by such a section, then as another option, one could create a separate article titled "Tributaries of River Foo" and collect the information on various tributaries there. In general, this guidance favors collecting such information in fewer, but larger, articles rather than many tiny articles, and only splitting articles when the larger article becomes too long or too imbalanced. See Wikipedia:Summary style for more guidance on this style of writing.

As always, I am open to editing, changing, eviscerating, or ignoring my proposal as well. --Jayron32 12:34, 4 May 2022 (UTC)

I think we need to discuss how to provide guidance on when topics are not in-depth enough to merit a stand-alone article, without making it longer than people are willing to read. Donald Albury 12:48, 4 May 2022 (UTC)

Let.s not try to do too much. If we can extend the guideline to say that notable topics do not require stand-alone articles, but can be included in larger articles (with examples), that is progress. Then we can turn to the trickier questions of how small is too small and how large is too large. My guess is that many geo-stubs are very short indeed and can easily be merged into the natural parent without making the parent unwieldy, so these questions will often not arise. Aymatth2 (talk) 13:04, 4 May 2022 (UTC)

I agree with Aymatth2. In my opinion how we should expect this to go is to first get the NOPAGE section into NGEO, wait for a few months or half a year to see how it is being applied in practice, and then based on that draft guidance on sizes and whatnot. Like that the draft would be more descriptive than prescriptive, something I see as beneficial. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 13:48, 4 May 2022 (UTC)

I disagree. Unclear guidance is exactly the sort of thing that consumes large volumes of editor time for things where there are no right answer. Rather than eating that cost every time there is a contentious geographical feature article merge or AfD, it is going to be a much better use of editor time if the guidelines are clear when they are proposed—biting the bullet and dealing with hard questions early is better than creating vague guidance that will inevitably lead to an increase in ANI threads and deletion reviews over what we have now. — Mhawk10 (talk) 13:54, 4 May 2022 (UTC)

The problem with specificity is that you invariably run into some variation of the Sorites paradox for defining proper length of articles. I mean Nile is a clearly long enough article about a river, and Fifteenmile Creek (Potomac River tributary) is clearly too short to be useful. How many words do I add to the Fifteenmile Creek article until it is acceptable? If it just crosses that line is it allowable as a stand-alone article? If someone comes along and edits it to remove 2-3 words must it now be merged? Editorial decisions do need to be made around necessarily fuzzy edges, and often depending on non-quantifiable standards, but that doesn't mean that there aren't articles which are clearly better served as being part of larger articles. --Jayron32 14:06, 4 May 2022 (UTC)

How about something like, If a preliminary search does not find at least two reliable sources that will support at least three or four sentences on a topic, then consider adding the topic as a section in a relevant article of larger scope. Donald Albury 14:20, 4 May 2022 (UTC)

I would hope we could do better than that. In particular, I think mentioning redirect creation - which has the potential to support the category system, highly relevant for geographical features - is worthwhile. It also seems to me that sortable lists and list articles should be explicitly mentioned as alternatives. Newimpartial (talk) 14:31, 4 May 2022 (UTC)

I think we need to avoid encouraging lists as an explicit alternative to articles; not all articles can be lists nor all lists be articles. In fact, I don't think that things like villages are equally or most useful to our readers as part of lists nor do I want to give that impression. For example, Pelliceira (parish) and Ibias (its parent administrative division, a municipality) show the limitations of lists without additional information or graphics. In this case the Spanish article provides a great idea: the use of maps and other graphics to allow the list information to be contextualized as part of the parent article. If we are going to mention lists, I really can support it if we explain how best to create these lists, even if its by creating a explanatory supplement on best practices regarding geographical lists. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 14:44, 4 May 2022 (UTC)

Lists are not an alternative to articles; they are either a type of article or an element in a larger article. A sortable list - or for that matter, a "presorted list" based on a hierarchical structure, which is often available for geographical topics - does actually provide information to the reader with less "friction" than a text mention can provide. And there is nothing in a sortable list that inhibits annotation, either. As these comments imply, though, I entirely agree that we need to offer best practices for geographical lists (starting with the recommendation that short lists should typically be contained within the parent article, as well as advice about redirects and the categorization thereof. Newimpartial (talk) 15:02, 4 May 2022 (UTC)

An article may be nothing but a list, a list with a long preface, or just contain a few lists. The lists could be in tables, bulleted text, or with headings for each entry. The best choice depends on how much text and images each entry has, whether sortability would help and so on. A useful discussion seems out of scope for this proposal. Aymatth2 (talk) 15:23, 4 May 2022 (UTC)

In my first two sentences I meant the type of article and in the rest I meant all lists (both stand-alone list articles or elements within an article), Newimpartial. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 18:02, 4 May 2022 (UTC)

The effect of requiring multiple independent RS will do little more than impose WP:GNG as a requirement for standalone GEO articles. If this is the intent, why not just propose to modify the existing text of NGEO? It seems far more straightforward and it would paint a clearer picture of what editors would be deciding on if this were to become a proposal. — Mhawk10 (talk) 14:52, 4 May 2022 (UTC)

I, for one, would oppose any such proposal, particularly if applied to populated places. Newimpartial (talk) 15:02, 4 May 2022 (UTC)

An article that says "Khryzk is a hamlet in Ruritania" followed by ten citations may be better merged into a parent. An article with two citations that says "Khryzk is a hamlet of about 50 people in Zaproz muncipality, Starzynck, Ruritania, on the Priztikh River. The main occupation is viticulture. The poet Stepan Khryskiv was born in this hamlet in 1843.", with a location map and a couple of interesting photographs, may not fit comfortably into a parent. I don't see how we can give rigorous rules for when stubs should be merged into parents. Aymatth2 (talk) 15:23, 4 May 2022 (UTC)

I am not saying that I would support such a proposal either, but I am saying that it is much more clear as to what the question is. — Mhawk10 (talk) 15:44, 4 May 2022 (UTC)

Why do we insist on creating stand-alone articles for which there is next to no verifiable information we can include in said article? If all we have to say can be summed up in a line or two of text, why do we need an entire page to contain that text? --Jayron32 15:56, 4 May 2022 (UTC)

What is so terrible about applying GNG to stand-alone articles about geographic features? What is so terrible about saying that stand-alone articles should be more than one- or two-sentence stubs? I also will note that my proposal was not a hard-and-fast rule, but rather would advise editors to consider adding topics to an existing article rather than creating a very short, poorly sourced, stub. Donald Albury 16:35, 4 May 2022 (UTC)

You seem to be conflating the GNG issue with the content issue. I think Aymatth2 is right about this: the question of how much encyclopaedic, reliably sourced information is available is more relevant to the standalone article decision than the number of GNG sources. Newimpartial (talk) 16:37, 4 May 2022 (UTC)

Your statement makes it seem like you don't understand GNG. When you say "the question of how much encyclopaedic, reliably sourced information is available is more relevant to the standalone article decision than the number of GNG sources.", GNG is literally about "how much encyclopaedic, reliably sourced information is available" That's 100 % GNG, but if we need to quote it to make it clear "A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject." Significant coverage means that there is enough verifiable text for us to build an encyclopedia article from. That's the point of GNG; if you can't create a long enough stand-alone article from the sources, then don't. Instead, find other ways to include the information. --Jayron32 16:54, 4 May 2022 (UTC)

No, I think I understand GNG pretty well (as one of the drafters who produced the text that was incorporated in WP:N as WP:SNG last year, I had to get to know GNG). I agree with you when you say that Significant coverage means that there is enough verifiable text for us to build an encyclopedia article from. But there is also a Bingo-card approach to GNG/SIGCOV, which is typically used to promote deletion of articles an editor wants deleted - by arguing that not enough of the sourcing is in depth, or that not enough of it is secondary, so that their aren't enough "GNG sources". My sense is that Donald Albury's original proposal for at least two reliable sources that will support at least three or four sentences on a topic would support this "ratcheting-up" approach in terms of dismissing sources and in terms of how much text is required. I took Aymatth2's point to be that it is the sourced information (and how well it fits into tabular format, etc.), not the number of sources, that should be the deciding factor in this context. While I don't think GNG discussions ought to devolve into nitpicking and source counting - I agree they are supposed to determine whether there is enough encyclopaedic information for an article - in reality they often do devolve into nitpicking. One of the purposes of SNGs like NGEO is to preempt that kind of nitpicking, so I wouldn't promote changes the main result of which would be to encourage it. Newimpartial (talk) 18:28, 4 May 2022 (UTC)

Would you say it was nitpicking when I tagged Dalkeith, Florida for not meeting GEOLAND? How about when Gulf Hammock, Florida was tagged for not meeting the GNG and being unsourced.? (Note that the latter tagging spurred me to find several sources and expand the article almost 6 times.) Exempting geographical features from GNG does not help improve the encyclopedia. Donald Albury 19:46, 4 May 2022 (UTC)

Exempting geographical features from GNG is already done in certain provisions of WP:GEOLAND; I did not understand the OP to be proposing to change that status. On the other hand, I haven't understood anyone in this discussion to suggest loosening any of the NGEO provisions around Notability. If you think the encyclopaedia would be "improved" through a radical overhaul of GEOLAND, I think that would involve starting a new discussion somewhere.

And of course people tagging articles that do not meet relevant criteria - like GEOLAND - or tagging (or better yet, improving) unsourced artickes, are not nitpicking. I am not suggesting that any participants in this discussion are engaged in nitpicking. What I have said is that proposed text like at least two reliable sources that will support at least three or four sentences on a topic would enable nitpicking: not as a goal, but as a predictable effect. I would therefore oppose any similar approach. Newimpartial (talk) 20:00, 4 May 2022 (UTC)

Drafting of stand-alone page criteria for WP:NGEO break

An attempt at a revised version is given below. This too long, but tries to cover some of the points made above. It is only concerned with notable topics under the present definition, and avoids the issue of how how big a stub should be to be kept stand-alone.

== Whether to create standalone pages ==

As stated in WP:NOPAGE, "Sometimes, understanding [of a notable topic] is best achieved by presenting the material on a dedicated standalone page, but it is not required that we do so. There are other times when it is better to cover notable topics, that clearly should be included in Wikipedia, as part of a larger page about a broader topic, with more context." For example, a river may have several tributaries that meet the notability criteria defined in WP:NGEO, but where there is little to be said about some of them. The article on the river may include a list of tributaries, and there may be standalone articles for some tributaries and redirect articles pointing to the list entries for other tributaries. A similar approach may be followed for hamlets in a municipality, shopping malls, railway stations and so on.

The target article may be a list-type article if the list is notable in itself or all the list entries are notable(see WP:STANDALONE), or may be a list or sub-section within a broader article such as a river with a list of tributaries or a municipality with a list of communities. The list may be formatted as a sortable table, as bulleted text, as paragraphs or sub-sections depending on the type of content. Examples: MacDonald River (Côte-Nord)#Lakes and Alachua County, Florida#Historic communities in Alachua County.

Merging a short stub about a notable topic into a parent article may improve the reader experience if it presents the topic in a broader context, as long as a redirect from the stub title is maintained. See WP:PRESERVE: a merge should not be done if the resulting reader experience is significantly poorer, for example if it causes loss of relevant text, location maps or pictures. (But {{Location map+}} may be used to show a number of related locations on one map.) A merge does not preclude expanding the redirects into standalone pages if more information comes to light, and also allows us to hold information on sub-topics that are relevant to the main topic but not notable in themselves.

Aymatth2 (talk) 22:48, 4 May 2022 (UTC)

dig it! --Jayron32 12:01, 5 May 2022 (UTC)

The target article may be a list-type article if the list is notable in itself or all the list entries are notable poses a bit of a SYNTH problem. I can make a “list of villages in Kurdistan containing at least one Kazakh” article under this guidance, provided that all of its list entries contain notable villages. Is there a way to clarify the language to exclude these sorts of synthesized lists?
Also, I don’t think Merging a short stub about a notable topic into a parent article will be often be uncontroversial is true. These often seem to be controversial, so it seems unwise to make a proposal that makes a descriptive judgement that is out-of-line with community practice. — Ⓜ️hawk10 (talk) 13:31, 5 May 2022 (UTC)

• I have tweaked the wording to point to WP:STANDALONE, and removed "uncontroversial". Aymatth2 (talk) 17:34, 5 May 2022 (UTC)

I have two comments on this last point: (1) I think it worth adding something like "as long as a redirect is maintained", because this is substantially true, and because of the benefit of redirects for Wikipedia's category system. (2) I also think the guidance should reference WP:PRESERVE, one of the most important principles in this context. Newimpartial (talk) 15:49, 5 May 2022 (UTC)

• Have added "as long as a redirect is maintained" and added a link to WP:PRESERVE. Aymatth2 (talk) 17:34, 5 May 2022 (UTC)

• I dispute that Wikipedia articles should necessarily be capable (a word that is always used in practice to mean "capable on the basis of free online sources available to everyone at the click of a mouse") of being expanded beyond a stub. Most articles in most of the print encyclopedias that existed before Wikipedia put them out of business would be classed here as stubs: only the largest multi-volume encyclopedias had longer articles. If I look up a small location in an encyclopedia it is usually because I just want to know where it is, without wading through a lot of irrelevant information about the wider area. This information is better presented in a sentence or two in a separate article, with a link available for the few occasions when I also want to know about the wider area. Phil Bridger (talk) 17:54, 5 May 2022 (UTC)

  So your argument is because other encyclopedias in the past did this badly, so we must do it badly too? --Jayron32 18:00, 5 May 2022 (UTC)

  I don't think that Phil is saying that stubs are a bad thing in old encyclopedias, so I really don't think that your summary of his argument is faithful to Phil's words. — Ⓜ️hawk10 (talk) 18:03, 5 May 2022 (UTC)

  No, that's not what I'm saying. As a reader if I want to know about a small location I want the information we have about that location. Why make me wade through content about a wider area to find it? Phil Bridger (talk) 18:08, 5 May 2022 (UTC)

  There's no need to wade through anything. The information is there, even if it doesn't have it's own page. Creating a one sentence article about everything that exists is not the best way to organize information at Wikipedia. --Jayron32 18:13, 5 May 2022 (UTC)

  Yes, it's there, but it is a bit more difficult to find when it could be very easy. Who are these readers that many people invoke who prefer things difficult than easy? Phil Bridger (talk) 18:21, 5 May 2022 (UTC)

  But it is easy … Redirects are cheap… and someone searching for a less-than-notable location or geographical feature can be redirected to a section of a larger article where it is mentioned. Blueboar (talk) 18:49, 5 May 2022 (UTC)

  Okay. Let's try this. I want to find information about my nextdoor neighbor. She's a nice lady. Works nights as IT support. Always is friendly. Why should I expect Wikipedia to have information about her? --Jayron32 18:26, 5 May 2022 (UTC)

  I struggle to see the relevance of this example. Does WP:BLP apply to geographical locations? Newimpartial (talk) 18:52, 5 May 2022 (UTC)

  @Newimpartial: BLP applies everywhere that living people are mentioned. So, in an article about Footown that lists people "from" (whatever that means) Footown, each entry that names a living person must either be supported by a reference, or link to an article about that person which verifiably shows their association with Footown. Unless your next-door neighbour is notable enough for a Wikipedia page, they probably shouldn't be listed. --Redrose64 🌹 (talk) 10:35, 7 May 2022 (UTC)

I am aware where BLP applies, but I believe you have misconstrued Jayron's example. Newimpartial (talk) 12:38, 7 May 2022 (UTC)

• Now you're moving the goalposts. We were talking about topics that you agree we should have information about. The only issue was whether it should be in a separate article or combined with loads of other locations in the larger area. Phil Bridger (talk) 18:59, 5 May 2022 (UTC)

  I think that this sort of argumentation might best be reserved for discussion of the proposal rather than discussion of the proposal's brainstorming. — Ⓜ️hawk10 (talk) 19:23, 5 May 2022 (UTC)

  The redirect can take the reader straight to the information that would have been contained in the stub, thanks to the magic of {{anchor}}. So Lake Jumbo (MacDonald River) goes straight to the information on Lake Jumbo in the MacDonald River (Côte-Nord) article. A print encyclopedia could not do that. The advantage (sometimes) is that the information is presented in the context of the parent, so in this case the reader can readily see information about other lakes that drain into the river, and about the river and its environment. But the proposal is only to point out, in line with existing guidelines, that a stub may be treated in this way. An editor may also choose to present the information in a short stub – nothing wrong with that. Aymatth2 (talk) 22:49, 5 May 2022 (UTC)

• I support the concept here. Wikipedia should cover small geographical places and features, but we can be flexible on how we cover them. It is not necessary to have a stand-alone article on every feature/place. Merging into articles on larger features/places is definitely an option. If all we can say about a small river is that it is a tributary of a larger river, then we probably shouldn’t have a stand alone article on the small river… it can be covered in the article about the larger river. As for searching, redirects and creative structuring of article sections and lists can handle this. Blueboar (talk) 12:59, 7 May 2022 (UTC)

I support this, although I would add some sentence to the tone of "Particular discretion should be taken with merging pages to make sure no or minimal information is lost and that redirects lead to the desired target (through the use of the {{anchor}} template, for example). Merging should happen through consensus via an AFD for existing pages." — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 22:46, 8 May 2022 (UTC)

An attempt to cover the above comments by Ixtal. I have pointed to WP:MERGE rather than WP:AFD, because this is about notable topics. I made further edits to reduce length. Still too long:

== Whether to create standalone pages ==

As stated in WP:NOPAGE, "Sometimes, understanding [of a notable topic] is best achieved by presenting the material on a dedicated standalone page, but it is not required that we do so. There are other times when it is better to cover notable topics, that clearly should be included in Wikipedia, as part of a larger page about a broader topic, with more context." For example, a river may have several tributaries that meet the notability criteria defined in this guideline, but there is little to be said about some of them. The article on the river may include a list of tributaries, with standalone articles for some tributaries and redirect articles pointing to the list entries for other tributaries. A similar approach may be followed for hamlets or shopping malls in a municipality, stations on a railway line and so on.

Merging a short stub about a notable topic into a parent article may improve the reader experience if it presents the topic in a broader context, as long as a redirect from the stub title is maintained, with suitable categories to assist navigation. The redirect target may be an entry in a stand-alone list or an entry in a list or sub-section within the parent article. The information may be formatted as a sortable table, bulleted text, paragraphs or sub-sections depending on the type of content. The redirect should point to the position in the parent article that holds the merged content, which may be identified by an {{anchor}} template. Examples: MacDonald River (Côte-Nord)#Lakes and Alachua County, Florida#Historic communities in Alachua County.

Wikipedia:Merging describes the process to follow. It should include a proposal discussion since merging a geographical stub may well be controversial. In line with WP:PRESERVE, a merge should not be done if it causes loss of relevant text, location maps or pictures. A merge does not preclude expanding the redirect back into a standalone page if more information comes to light, and also allows us to hold information on sub-topics that are relevant to the main topic but not notable in themselves.

Aymatth2 (talk) 12:44, 9 May 2022 (UTC)

Proposal 3 for wording

I have amended some of the wording proposed by Aymatth2 above:

== Whether to create standalone pages ==

As stated in WP:NOPAGE, "Sometimes, understanding [of a notable topic] is best achieved by presenting the material on a dedicated standalone page, but it is not required that we do so. There are other times when it is better to cover notable topics, that clearly should be included in Wikipedia, as part of a larger page about a broader topic, with more context." For example, a minority of a river's tributaries may meet the notability criteria defined in this guideline, but there is little to be said about the other tributaries. In this case, we may include a list of tributaries in the river's article, with standalone articles for some tributaries and redirect articles pointing to the list entries for other tributaries. A similar approach may be followed for hamlets or neighborhoods in a municipality, stations on a railway line, and other geographical features.

Merging a short stub about a notable topic into a parent article may improve the reader experience if it presents the topic in a broader context, as long as a redirect from the stub title is maintained, with suitable categories to assist navigation. The redirect target may be an entry in a stand-alone list or an entry in a list or sub-section within the parent article. The information may be formatted as a sortable table, a bulleted list, paragraphs or sub-sections depending on the type of content. The redirect should point to the position in the parent article that holds the merged content, which may be identified by an {{anchor}} template. Maximum care should be taken to preserve the information that was part of the stub. Examples: MacDonald River (Côte-Nord)#Lakes and Alachua County, Florida#Historic communities in Alachua County.

It is important to follow the process described at Wikipedia:Merging when merging articles, with particular care to publicising controversial proposals at relevant WikiProjects. A merge does not preclude expanding the redirect back into a standalone page if more information comes to light.

— Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 11:31, 10 May 2022 (UTC)

I am ok with this version. Aymatth2 (talk) 12:04, 10 May 2022 (UTC)

Pinging previous participants in the discussion to see if this should be the wording for the RFC: @Blueboar, Mhawk10, Newimpartial, Redrose64, Jayron32, Phil Bridger, Donald Albury, and North8000. If there is consensus this wording is good enough for the RFC, I'd appreciate help in wording the actual RFC question/presentation as well. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 12:49, 10 May 2022 (UTC)

I'm OK with this wording. I will not be using my regular account for a while, and will not be particpating much. Alt.Donald Albury (talk) 15:20, 10 May 2022 (UTC)

What's there looks good to me. But people are going to want to understand what the net changes are. For that you'd need to specify exactly what would be removed and replaced with this.North8000 (talk) 15:40, 10 May 2022 (UTC)

North8000 this is a new section to the guideline. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 16:24, 10 May 2022 (UTC)

I would keep the RFC wording very simple. Something like:

RFC to clarify that notable geographical topics do not have to have stand-alone articles
See Wikipedia:Village pump (idea lab)#Drafting of stand-alone page criteria for WP:NGEO, based on feedback at recent RfC
Wikipedia has many very short geographical article stubs. This proposal is to add a section to WP:NGEO that will clarify, in line with the existing WP:NOPAGE guideline, that information on notable geographical topics may sometimes be best included in parent articles. The draft wording of the addition to WP:NGEO is given below:

Aymatth2 (talk) 15:54, 10 May 2022 (UTC)

One suggestion: I've often found that redirects link to a section, and then editing happens that changes the name of a section. It might be a good idea to create a method for linking to a section from a redirect that we recommend, like templates that set an anchor point and one for the redirect that notes an anchor point should exist, so we can use a bot to flag up broken redirects. Adam Cuerden ^(talk)_{Has about 7.8% of all FPs} 16:34, 10 May 2022 (UTC)

I'm pretty sure there is a bot that does that for sections only renamed (or should be), but I don't think fixing redirects is in the scope of the proposal. I do suggest you start a new thread so that idea can get attention tho, Adam :D — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 16:41, 10 May 2022 (UTC)

Just feels like something that we can suggest in this part of the guideline. But, aye. Adam Cuerden ^(talk)_{Has about 7.8% of all FPs} 17:04, 10 May 2022 (UTC)

The thing is that would be a good improvement for all redirects, so if it is something that the community believes in I think you should propose it at a wider scale. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 17:08, 10 May 2022 (UTC)

IMO, go with a very brief explanatory statement and then an even more direct statement of the proposed change: "Add the following section at this location XXXXX in the xxxxx guideline. You might want to also be the the first respondent where you make your case for the change. But don't put non-neutral stuff in the RFC itself. North8000 (talk) 17:08, 10 May 2022 (UTC)

• RfC started at Wikipedia:Village_pump_(policy)#Reworded_RfC_on_the_addition_of_a_stand-alone_page_creation_criteria_to_the_geography_notability_guideline.— Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 10:34, 15 May 2022 (UTC)

Confirmed versus autoconfirmed

I happened to find myself looking at Wikipedia:User access levels#Table after an attempt to edit a page while logged out was unsuccessful. While there, I realized that confirmed users lack the autoreview and movestable permissions that are associated with autoconfirmed. Is there a reason I am unaware of for this discrepancy, given that confirmed and autoconfirmed are supposed to grant the same levels of access? If not, is there any reason why this should not be changed? HouseBlaster^talk 21:03, 15 May 2022 (UTC)

Special:UserGroupRights claims that confirmed users do, in fact, have autoreview and movestable rights. So either Wikipedia:User access levels is wrong, or there's some weird bug in the Pending Changes extension. Suffusion of Yellow (talk) 21:16, 15 May 2022 (UTC)

They just happen to be the same, on this project at least. Seems like that project page is outdated, feel free to fix it. — xaosflux ^Talk 21:54, 15 May 2022 (UTC)

Fixed it. HouseBlaster^talk 22:14, 15 May 2022 (UTC)

Community thoughts on "Recent deaths" section of Main Page

What are y'all's thoughts on the "Recent deaths" section? Does it have much encyclopedic value? What is the purpose of it? Is it successful in its purpose? What is the latest discussion on the section? — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 23:04, 16 May 2022 (UTC)

@Ixtal as part of "In the news" this section has had a lot of discussion, see Wikipedia talk:In the news and its archives for more information. — xaosflux ^Talk 12:58, 17 May 2022 (UTC)

Wider pages on new vector skin

Tracked in Phabricator
Task T306660

When you read a page on the new 2022 vector skin, the page looks... Compressed. WikipediaNeko (talk) WikipediaNeko (talk) 02:03, 12 May 2022 (UTC)

@WikipediaNeko There's an experimental gadget you can enable in your preferences to restore the wider screen. If you go to Special:Preferences#mw-prefsection-gadgets and scroll down to "Testing and development" you can enable the gadget called "wide-vector-2022". 163.1.15.238 (talk) 11:34, 12 May 2022 (UTC)

Not seeing this......problem is the new toc on the left takes up 33% of the space. Moxy- 12:00, 12 May 2022 (UTC)

@Moxy You will only see the gadget to enable if you are using vector-2022 skin (as it only works with vector 2022 skin, you can force it to appear with this link). For more on why the TOC is so wide on narrow screens, see phab:T306660. — xaosflux ^Talk 14:06, 12 May 2022 (UTC)

Note: that gadget doesn't try to move the TOC, just to free up a bunch of other wasted horizontal space mostly seen on wide resolutions. — xaosflux ^Talk 14:11, 12 May 2022 (UTC)

If someone wants to code up something to "restore old TOC style" on vector-2022, we can certainly test it as an experimental gadget as well, but someone needs to write it. — xaosflux ^Talk 14:10, 12 May 2022 (UTC)

Hmm that seems to work. WikipediaNeko (Leave me a note!) 21:01, 12 May 2022 (UTC)

That's a deliberate feature, by the way. – Joe (talk) 13:10, 12 May 2022 (UTC)

It is, but I don't think anyone really loves it. If we had a referendum way of doing things, pretty sure it'd loose by a heavy margin. —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:45, 15 May 2022 (UTC)

I dread to think what a UI designed by referendum would look like. We're a community of encyclopaedia editors; frontend changes are something we've always left to the professional designers in the WMF and MediaWiki developer community, as it absolutely should be. – Joe (talk) 08:02, 17 May 2022 (UTC)

Anyone who wants narrower text can just resize their browser, making the freed space available for other windows. But we're not consulted on such changes; the WMF just decides what's good for us and imposes it. The one possible advantage is "compatibility" with websites which plaster the right side of the screen with advertising. Making Wikipedia waste that space too allows readers to obscure the right side of the browser window with something useful (or just have it bleed off the edge of the screen) knowing that everything they can no longer see is junk. Certes (talk) 12:02, 15 May 2022 (UTC)

Mandatory link. Daß Wölf 23:24, 17 May 2022 (UTC)

It's generally considered better UX to not have too many characters per line (see [4], the people behind the redesign wrote a whole doc about it too at mw:Reading/Web/Desktop Improvements/Features/Limiting content width) - about 80 characters per line is supposed to be good. At least viewing on my laptop, current vector has 150+ characters per line which is way too much. My eyesight isn't bad but the current font in default vector is a bit small too. I support the efforts in the redesign to reduce the characters per line and I definitely don't think people without UX knowledge (i.e. the community) should be deciding this. No one is forcing people to use the redesign anyhow.

I personally use Timeless which squishes the article even more and like that a lot honestly. (though it does make good use of the right space, putting all the page tools on the side.) Galobtter (pingó mió) 22:35, 15 May 2022 (UTC)

@Galobtter you may not be following tech news, (e.g. meta:Tech/News/2022/19) where indeed vector-2022 is being forced on to people, just not here on the English Wikipedia, yet. — xaosflux ^Talk 23:34, 15 May 2022 (UTC)

@Xaosflux I did notice, but I meant more that logged-in people can switch back easily if they want to. Galobtter (pingó mió) 23:42, 15 May 2022 (UTC)

Am I missing something? When I try view a page on my phone (or with the window narrowed down) in vector-2022, there is no table of contents at all that I can find. That, at least, can't be deliberate. Suffusion of Yellow (talk) 02:46, 16 May 2022 (UTC)

@Suffusion of Yellow with vector-2022 there are basically 2 layouts:

1. Narrow Screens: No Table of Contents at all, left side bar containing tools can be collapsed or not collapsed
2. Not-narrow screens: TOC is in the left side bar, the side bar itself can't be collapsed, but the tools part of it can be collapsed "up".

IMHO, the former is a disservice to users as now they have no TOC at all (and yes it is deliberate, some feedback is being looked at in phab:T306660); the later is a disservice to those with slightly larger screens because they can't collapse TOC "left" to be able to use more of their screen for accessing content. For those with very wide screens, the forced narrow body can be annoying as well (we have a gadget to help with that - but it doesn't fix the huge space used by the forced sidebar TOC). — xaosflux ^Talk 13:39, 16 May 2022 (UTC)

Thanks for the phab ticket Xaosflux. Currently, I'm using a narrow skin, and Vector 2022 simply thinks that I don't need a TOC at all. Not even when I've deliberately used __FORCETOC__ on my talk page and it's subpages. This is certainly not what I wanted to get. On longer pages, like 2022 United States House of Representatives elections, if I need to go to, say, #Wyoming, I now have to scroll for an eternity. Because of the page size, it's really very slow now, earlier, a single click would've gotten me to the targeted section. —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:59, 16 May 2022 (UTC)

• I've forced myself to use the new Vector skin in case I can provide useful feedback and I have to say that while at first I hated the compress feel it has very quickly grown on me and feels fantastic. My computer screens are 1920x1080. It makes for easier reading in my opinion. Hopefully the gadgets for wider screens are improved such that users are able to fully enjoy the new look, though. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 10:41, 17 May 2022 (UTC)

  Gadgets are only available when logged in, though. The new Vector doesn't affect my editing experience; I use MonoBook. But I should not have to log in from every device, and every private window, just to read Wikipedia, and nor should anyone else. Not to mention, most people don't bother changing settings. If the site is aggravating to read, they'll just go somewhere else. Suffusion of Yellow (talk) 18:02, 17 May 2022 (UTC)

  There is one upside of a bad default skin: it makes it more obvious whether you are logged in. —Kusma (talk) 18:13, 17 May 2022 (UTC)

Wiki E-Books

Wiki Books logo

Proposing a new WikiProject for E-books publishing. E-books should evolve and embrace data such as pictures, videos, tables, graphs, linked data, in line references, (wikilinks/hyperlinks). Basically E-books written using the Wiki Markup Language using a new MediaWiki platform. Books are written and look like they did 150 years ago and a lot has changed since then. Maybe "Wiki E-Books" since Wikibooks is already for open textbooks.

See also: History of writing

Wikideas1 (talk) 02:27, 18 May 2022 (UTC)

For those wanting to share their views about the proposal may visit meta:Wiki E-Books, a request for new project already initiated by the proposer. —CX Zoom[he/him] ^{(let's talk • {C•X})} 10:52, 18 May 2022 (UTC)

@Wikideas1: The place to propose new WikiProjects is Wikipedia:WikiProject Council/Proposals. --Redrose64 🌹 (talk) 09:26, 19 May 2022 (UTC)

Their inention was to propose a new Wikimedia Project, not a WikiProject, as is evident from the above meta link. —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:36, 19 May 2022 (UTC)

The first sentence links WikiProject. --Redrose64 🌹 (talk) 17:15, 19 May 2022 (UTC)

MoS/Mathematics: Adding guideline on colon before equations

Many guidelines on mathematical writing say that equations should be treated as any other part of the sentence they belong to (When writing in math, do you use a comma or colon preceding an equation?). Thus, the rules for when to use colons in front of equations should be similar to when to use colons in general English writing. The general rule in English is that colons can only be used after what would constitute a full sentence (see the Wikipedia article about colon that confirms this). So for example in

The definition of f is:

$$f(x)=x^{2}.$$

the colon shouldn't be used because it separates the verb from the object of the sentence. So my suggestion is to add a guideline that a colon can't be used in front of an equation if what precedes the colon is not a full sentence. Morgr2 (talk) 05:45, 19 May 2022 (UTC)

@Morgr2 This should probably be proposed in Wikipedia talk:Manual of Style/Mathematics, not here. --Ahecht (TALK
PAGE) 15:13, 20 May 2022 (UTC)

Undisclosed Paid Editing

Some editors have been discussing how the English Wikipedia should strengthen its efforts against Undisclosed Paid Editing. I will suggest that at least two steps should be taken against UPE that are similar to those taken about Sockpuppetry. First, a formal system should be introduced for the tracking of UPE reports that is comparable to the system of sockpuppet investigations. Second, a duck test should be introduced for undisclosed paid editing. Sometimes sockpuppets are blocked based on Checkuser data, but sometimes they are blocked based on their quacking and swimming. Sometimes undisclosed paid editors are blocked based on a proved connection, but sometimes they should be blocked because they quack and shed duck feathers.

Comments? Robert McClenon (talk) 04:27, 7 May 2022 (UTC)

The thread on Barkeep's talk page offered a bit of a myopic view of what we're currently doing to fight UPE. It's not only a few editors and it's not just happening at COIN. For one, most UPE can't be discussed on-wiki because it involves nonpublic evidence that would fall afoul of WP:OUTING. The paid-en-wp@wikipedia.org VRT queue has been used for these cases for over three years now and because it logs tickets serves as a kind of tracking system – with the obvious major caveats that it is only accessible to CheckUsers, and even for us it's completely disorganised and difficult to navigate (VRT is not good software). Serial UPErs are also tracked on-wiki at Wikipedia:List of paid editing companies, which for example MarioGom has been diligently keeping updated with a list of WP:ABTACH socks. And for that matter all of them are also (prolific) sockpuppeteers, so to an extent the "SPI for UPE" is just SPI. Finally, nobody's yet mentioned WP:NPP, which is by far our most important process in fighting COI and paid editing, since new page patrollers are usually the first and only people to spot it.

That said, I can see the benefit of pulling these streams together and making more information available to non-CUs. For us admins working on this, it would also be helpful to have a more specific set of block templates that can specify and link to the type of evidence used, as opposed to the current system where we (or at least I) have to arbitrarily pick between {{uw-soablock}}, {{uw-upeblock}}, and {{checkuserblock-account}}, and dump some links to VRT tickets or COIN threads in the block log. Any new process for UPE would have to be very carefully designed to avoid outing, though. – Joe (talk) 09:14, 7 May 2022 (UTC)

The duck test for UPE does exist in practice (see {{uw-sblock}}, {{uw-adblock}}) and a few admins do apply them. I agree with Joe Roe that block templates could be improved to include some optional parameters to include type of evidence though.

I don't think we should introduce yet another noticeboard to report UPE accounts. We already have a few of them:

1. WP:COIN, which is a safe fallback if no other venue applies.
2. WP:SPI, where socking is reported, and it's where the most prolific spammers are usually handled.
3. WT:WPSPAM, where linkspam is reported, and dealt with quite effectively.
4. WT:PAIDLIST, for discussion about WP:PAIDLIST listings.
5. m:Wikiproject:Antispam, a global noticeboard to deal with cross-wiki UPE once their accounts have been blocked in, at least, one project.
6. paid-en-wp@, for reports with off-wiki and private evidence.
7. WP:WPOP, which is not explicitly about UPE, but happens to deal with proxy/VPNs often used by UPE.
8. Wikipedia:WikiProject Integrity, de facto superseded by WP:COIN and WT:WPSPAM.

But if there's some functional need that is currently not covered by any of these venues (some come to my mind, like post-block clean ups), it might be worth to discuss how and where it should be covered. MarioGom (talk) 09:36, 7 May 2022 (UTC)

• Joe Roe, As the editor who initiated the topic on Barkeep49's TP I do not necessarily disagree with you and for the record MarioGom is an excellent editor in dealing with unethical practices, in-fact, unbeknownst to them it was via their aid I was able to destabilize a prominent UPE ring in Nigeria.

Lest I digress, I believe what I was trying to say is a faster and more effective manner of dealing with UPE should be introduced, for example, the duck test should be exponentially strengthened and should be used as a 'slam-dunk' that is, if it quacks loud enough we need not technical data or days and days of investigation to handle effectively. I understand you Joe and you do make a reasonable point, but just how effective is COIN in dealing with UPE? Just how effective is SPI, take a look at [5] it has been open for 7 whole days, does that look effective or efficient to you? I guess in the end we do need a stronger avenue that tackles undeclared paid editing effectively and efficiently. However, Joe & Mario, I do appreciate your input. Celestina007 (talk) 17:32, 7 May 2022 (UTC)

• I was the person who probably triggered this suggestion, and it was prompted by the current ANI discussion on Celestina007. My feeling as an outsider was that UPE-hunting currently looks like a rather Wild West activity, carried out by strong-willed individuals making strong accusations based on what appears to be personal intuition, and it's carried out in the talk-pages with no obvious structure. The difficulty is that even if those who do it have a genuine instinct for spotting a UPE, the process has to be seen to be fair. Otherwise, UPE-hunters are going to be dragged to ANI all the while, accused of harassment. In this particular case, Celestina is being accused of making wild claims about what tools and capabilities she has. I don't want to recreate ANI here, but my point is this: if we knew what tools and rights were available to UPE hunters, and what procedures they follow, Celestina wouldn't have needed to make any claims, everyone would know what was going on, and the whole rather horrible ANI discussion would not have happened. I do think formalising UPE-hunting would avoid a lot of unpleasantness and make it clear that UPEs are zapped by a community consensus, fairly, rather than hounded by individuals who have a flair for spotting them. Timtrent made the point that it would help the AFC people, giving them a clear approach to bad new articles produced by UPEs. Yes, the UPEs overlap strongly with SPI, but maybe that can be acknowledged in the procedures and duck-response strategies. In any case, SPI is an excellent precedent. We don't tend to have aggro over socks, and that's largely because the procedure for dealing with them is so clear. Elemimele (talk) 06:08, 10 May 2022 (UTC)
• Between this and Wikipedia:Village_pump_(proposals)#A_Proposal_to_formalise_and_centralise_the_control_and_reporting_of_Undisclosed_Paid_Editing I'm wondering if what we need more than anything is better documentation of the existing process. Few people seem to be aware of the full range of resources MarioGom listed. Instead we have a handful of people investigating UPE using techniques they've built up from experience, and a smaller number of admins and CUs who respond to these reports in an ad hoc way. But anyone interested in joining that effort has to figure it out for themselves through a mess of fragmented instructions on multiple pages. This also hinders wider discussion amongst the wider community about what we're doing, e.g. when something goes wrong, or there are calls for improvement. It would be great to have a single guideline page that documents: a) how to spot and investigate UPE (bearing in mind WP:BEANS of course); how to draw it to the attention of administrators; and how to document the evidence for accountability and future reference. – Joe (talk) 12:14, 10 May 2022 (UTC)

  I agree with User:Joe Roe that better documentation of existing processes is needed. I thank User:MarioGom for providing a list of processes, some of which I had not known about (and I have been concerned about UPE for years). We have COIN. Sometimes it works well, and sometimes it doesn't. I think that it should be improved somehow, and do not have specific ideas. We have two policies that interfere with each other, the rule against Undisclosed Paid Editing, and the rule against outing; I think that, unfortunately, we have allowed the rule against outing to take priority over the rule against undisclosed paid editing. That is my opinion. I still think that we need to establish clearly that the duck test does apply to UPE. I see many editors who say that they are "just a fan" or that they think that a company should have an article, and they write one that reads like spam. COIN needs to be improved. I don't have a specific idea. Robert McClenon (talk) 17:54, 10 May 2022 (UTC)

  It might be that better documentation is enough. Definitely something's needed; Celestina's ANI is evidence of that. A duck-test would make sense. I'll admit that UPE isn't something that I spend much time worrying about, because my personal view is that biased and unsourced articles are unacceptable whether someone paid for them or not. It's not popular to say this, but we almost certainly have a lot of UPE and COI editing here that is causing no trouble whatsoever. How many of our articles on universities and academics have been edited by employees of the university, even its PR department? But these are often people who have deeply ethical attitudes to accuracy, very akin to WP's own philosophy, and they're people who understand referencing and the importance of sources, and they're also used to adapting their writing style to match requirement, so the material they produce is basically indistinguishable from editing by a non-COI editor. I also feel that every time we revert a badly-supported, promotional junk edit that's been written by a UPE, we are making the UPE look like a fraudster in the eyes of their customer (which is exactly what they are, and what we want them to look like). But the duck-test is very much a necessity if it's going to reach a stage of accusing someone on a talk-page of being a UPE. You can tell anyone that their edit is promotional, unsourced etc. because the evidence is there to be seen; but if you tell someone they're a UPE, they can just deny it, and without any defined standards of what constitutes a UPE-duck, it just looks like a bad-faith accusation. The same applies to tools: if you're going to use any special tools to check the identity of a UPE, it has to be done using tools we all know exist, according to protocols we know will keep us safe from misuse. If all UPE special identification is basically exactly the same as SPI stuff, then maybe it's enough to make it clear that there is no special checkuser for UPE, but any accusation of UPE that involves sock-puppetry will be handled by the SPI people and checkusers in the normal way? Sorry, this has been a bit of an ill-thought stream-of-consciousness reply. Elemimele (talk) 12:41, 11 May 2022 (UTC)

  My attitude is pretty similar to Elemimele on this. UPE is only a problem when it becomes a problem. Bad editing is bad editing, and if it is caused by UPE or if it is caused by noobs without a clue or it is caused by someone with an axe to grind, or whatever, it is what it is and it needs to be dealt with. Given the real technical and policy issues with being able to identify pseudonymous users, there's no practical way to head off UPE problems before they start. We should definitely have a policy against it, but in terms of enforcement, you enforce it by enforcing the same editing and behavioral standards you do against all users. --Jayron32 13:26, 11 May 2022 (UTC)

• Looks interesting to me. I came here through scope_creep's talk page and found some interesting notes there as well. Likely I'll make some observations during the day time and share my ideas as I happen to work with the Global Anti-Spam team. Regards, ─ The Aafī on Mobile ^(talk) 19:09, 11 May 2022 (UTC)

For Example

I invite non-admin editors to look at Draft:Chris Barrett (interior designer) in the next few days to see if this gives them any thoughts about how to deal with UPE. This draft was deleted as G11, and has been temporarily restored at Deletion Review because the author appealed, saying that it was neutrally written and had multiple sources. What occurs to me is that, fortunately for the good of the encyclopedia, paid editors often have a different concept of what they are trying to write than we are looking for. Robert McClenon (talk) 22:17, 14 May 2022 (UTC)

An interesting case. I'm no UPE expert, but several behaviours which I probably shouldn't name explicitly raise suspicions, quack loudly and form strong circumstantial evidence without actually proving anything beyond reasonable doubt. Certes (talk) 22:59, 14 May 2022 (UTC)

This is one of these cases that can be plausibly plain WP:COI/autobiography rather than UPE. If it gets disruptive, some admins would block as a spam / advertising-only account or WP:NOTHERE (rather than ToU violation). Anyway, COI/autobiography cases often have a laser-focus on a single BLP, and if that gets deleted, the user eventually stops editing, making it a non-problem. MarioGom (talk) 08:40, 15 May 2022 (UTC)

For Example, again

Thank you for commenting. I invite you to look at my week-old COIN report of IntDesign. This should have been a slam-dunk. The author did not answer the question when asked whether they have a conflict of interest. However, one week later, no action has been taken. I have known that COIN is inconsistent, and often doesn't accomplish anything, and this latest incident illustrates that COIN is inconsistent, and often doesn't accomplish anything. This illustrates why I think that we either need new ideas for dealing with conflict of interest including undisclosed paid editing, or need better use of the mechanisms that we have. This inconsistency of COIN is why the editors on User:Barkeep49's talk page said that they are a lonely group of superheroes trying to fight UPE. This inconsistency of COIN is why User:Timtrent proposed that the community create a group of superheroes to fight UPE. Maybe I did something wrong in making the report at COIN. If so, maybe better instructions are needed for COIN. Maybe small-time COI or UPE isn't the purpose of COIN. If so, does that mean that we ignore small-time UPE, or is there a different mechanism for small-time UPE?

This is the Idea Lab. Ideas? Comments? Robert McClenon (talk) 14:32, 21 May 2022 (UTC)

Robert McClenon, I think the reason that no action has been taken about the WP:COIN report is that a deletion review is open, which, incidentally, appears to be heading for an endorsement of deletion. We shouldn't be discussing the same thing in more than one place. I would add (to Certes in the section above) that, as far as I am aware, the standard of proof applied to such cases here is somewhat less than "beyond reasonable doubt". Phil Bridger (talk) 16:21, 21 May 2022 (UTC)

User:Phil Bridger - I agree that we shouldn't be discussing the same thing in two places. I will say, first, that the deletion review is about the article, and the COIN report is about the editor. I will say, second, that the editor started the deletion review, and it doesn't seem like a good idea that a paid editor should be able to avoid accountability by filing a report. Robert McClenon (talk) 03:29, 22 May 2022 (UTC)

TBH I'd like it if our COI policies were more endorsing of giving admins the ability to block these accounts from relevant pages. As it stands though, the intersection of anonimity and COI disclosure ideals mean that is highly unlikely to happen. So all we have is a chihuahua noticeboard with a bit of bark but no bite. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 17:14, 21 May 2022 (UTC)

Create VIP right

Moved from WP:VPR

Should we create a grant called VIP which allows editing pages as "Restriction level edittrust"? Mirhader (talk) 09:34, 8 June 2022 (UTC)

What is the purpose of this? 331dot (talk) 09:42, 8 June 2022 (UTC)

@Mirhader: I moved this to the idea lab, there is about 0% this will happen - but maybe some idea could come of it. — xaosflux ^Talk 10:00, 8 June 2022 (UTC)

To help us understand how this idea might be useful, how would the VIP concept differ from Wikipedia's existing confirmed, extended confirmed and admin privileges? Certes (talk) 11:39, 8 June 2022 (UTC)

There is a wiki with that grant which allows editing pages as "restrictionlevel-edittrust". 197.207.222.211 (talk) 15:13, 8 June 2022 (UTC)

Yes, huwiki uses edittrustedprotected as a protection level (they have 4 levels, just like we do); their "level 2" is "edittrustedprotected" whereas ours is "extendedconfirmed". They use a manual process that has their bureaucrats manage their group, we use an autopromotion process and allow administrators to additionally manage our group. Projects can have lots of bespoke protection levels, for example srwiki has 6 levels. To do something like this here, a good place to start is: What is the problem that you want to solve? Why is this the best way to solve it? — xaosflux ^Talk 15:30, 8 June 2022 (UTC)

Why is this archived? discussion has barely started! Graeme Bartlett (talk) 22:04, 8 June 2022 (UTC)

@Graeme Bartlett: Mirhader and 197 are both sockpuppets of CafeGurrier66, who was blocked in part for their history of poorly-thought-through timewasting village pump threads. In the spirit of WP:SOCKSTRIKE, speedy archival seemed the best way to keep CG from further wasting constructive contributors' time. But if you think there's a useful discussion to be had here, feel free to unarchive. -- Tamzin^{[cetacean needed]} (she/they) 22:33, 8 June 2022 (UTC)

Rough Idea: Word Links Box

Option to include a modifier in any given article.

If included, and another article makes mention of it and has a special collapsible "Word Links" box, that word will appear in the Word Links box in alphabetical order with a link to that article.

If article Fruit makes mention of article Apple and article Banana, and both article Apple and article Banana have WordLinks = True, and article Fruit has a Word Links box embedded at the bottom, the Word Links box will have Apple and Banana in that order with links to both those articles.

This avoids sea of blue, doesn't have issues with see also (because if an article mentions a specific kind of handcuffs and is about a famous person, that wouldn't normally be in see also), and allows users to in some ways still look up the information through linking.

Lede or Follow (talk) 17:36, 25 May 2022 (UTC)

@Lede or Follow perhaps I'm just being dumb here, but I don't understand what it is you're proposing, how it would work or what issue it aims to address. As I understand your proposal you tag an article with "wordlinks=true" then any article that links to it will have a link appear in a box at the bottom? Or are you proposing to remove inline links entirely and move them all to one giant box based on mentions?

I don't see what the point of duplicating/moving an articles' links to a box is? If you introduce a term that is unfamiliar to the reader then surely it's better to link it in the article text, in context, rather than expecting a reader to remember what they just read and find it somewhere else?

Whether a link is useful or not depends on the article you are reading, doesn't it, not what the other article is? A link to something like February would be useful in an article on months, but including it in the article of every event to take place in that month would be excessive.

What are the issues with Sea of blue you are trying to solve? Wouldn't a box full of links be much worse from a usability/readability standpoint? What issue do you see with "see also" sections?

Does Special:WhatlinksHere do some of what you are suggesting? A list of articles that link to this one? 192.76.8.78 (talk) 18:16, 25 May 2022 (UTC)

Wikiacademy, Wikividhyalaya, Wikischool

Bonjour touts! The youth of the world is facing an educational crisis. Many are not able to access education, and for many school fees is too much. Following COVID-19, and online education, I request that we start a Wikimedia School, for students from Class 1-12 and even university topics. This proposed school will follow a curriculum that is well understandable, and will also instigate scientific temper in students. It will bring out the talents of students, and allow people, who might not have received an education, to live a much more prosperous life, helping the community and be a global citizen.

It can also act as a platform for existing schools to utilise, to improve education in their own schools. This, if started must have teachers (qualified enough) from all over the world and can also help in cultural exchange.

Not all can access the internet or has access to smartphones and other website recepting devices, some do not have any at all! Electricity is also scarce in many regions.

Thus, we should make sure that it is flexible, to cater to the electricity shortages many face, along with doing humanitarian aid like improving electricity and providing a device to those who truly need it.

All this must be done free of cost, without ads.

I hope this rough proposal can be taken to the next level and actually done.

Narutmaru (talk) 09:19, 27 May 2022 (UTC)

This is covered by Wikiversity. Dege31 (talk) 13:50, 27 May 2022 (UTC)

Option to change/edit "edit summaries" once published.

Occasionally due to touch errors or some oversight, editors (including me) may fail to provide adequate edit summaries or edit summaries that are focused on the point; I believe an option that allows for editing the "edit summaries" would be extremely useful.

Also, this feature can be useful if the editor accidentally leaves out the edit summary before publishing, so having the option to add or edit the edit summary is a sound idea in my opinion.

Fenharrow (talk) 10:55, 16 May 2022 (UTC)

If you're going to edit an edit summary, then you need to be able to supply an edit summary for the edit of your edit summary. That edit summary would need to be editable too. Further, we'd need people to be able to see the history of an edited edit summary, and to patrol edit summary edits and deal with bad edits that someone might make to an edit summary. All this seems more work than would be worthwhile when you could just make a dummy edit to enter a corrected summary into the page history. Anomie⚔ 11:04, 16 May 2022 (UTC)

Yes. I have often wished that I could change an edit summary in order to pretend that I never make a typo, but have realised that this would lead to the infinite regression mentioned by Anomie. Most of the time we should be more relaxed about such things and just let them go, and on the odd occasion where the meaning is not clear then the dummy edit method works fine. Phil Bridger (talk) 13:26, 16 May 2022 (UTC)

After the edit is saved, only two things can be done with the edit summary, and both of those may only be done by admins: hide it in its entirety, or restore it to exactly what it had been before it was hidden. Both actions show in the deletion log for the page - see for example this log. --Redrose64 🌹 (talk) 12:52, 17 May 2022 (UTC)

If you make a mistake in an edit summary, make a dummy edit with the correction. --Ahecht (TALK
PAGE) 00:08, 18 May 2022 (UTC)

Fenharrow. Go to your Preferences and click on the Editing tab. Scroll down to Editor and check Prompt me when entering a blank edit summary (or the default undo summary). Never forget an edit summary again. CambridgeBayWeather, Uqaqtuq (talk), Huliva 08:33, 29 May 2022 (UTC)

Special:CreateAccount accessibility

The accessibility of Special:CreateAccount is no good. I created phab:T306314 for that which was just closed by Tgr as invalid. The way I see it, the "Request an account" link should be titled "I can't solve this CAPTCHA" instead of "Request an account" and link straight to https://accounts.wmflabs.org/. A "Request an account" link could be placed elsewhere (top or bottom probably) of the form to link the hostile Wikipedia:Request an account for, I don't know, vandals or something.
It's already uneasy for people to be forced into asking for help because we failed to determine they are human beings, the very least we can do is not make them jump through stupid hoops. If for some reason we aren't capable of that (too many vandals frequenting accounts.wmflabs.org? but they won't be stopped by the hostile on-wiki wizard, will they?), we should just omit the link entirely. Being plain inaccessible is marginally better(!) than throwing walls of text at people who are visually impaired. Which is what we do. — Alexis Jazz (talk or ping me) 20:51, 27 May 2022 (UTC)

I agree that WP:Request an account is too long and offtopic for someone who can't see well and/or is using a screen reader. It's also (unintentionally) a little condescending to visually impaired users, as able users are expected to behave without having to listen to the username policy and related warnings. We should have separate landing pages for people who can't create an account due to CAPTCHA and people who can't create an account for other reasons (IP block etc). Daß Wölf 23:20, 27 May 2022 (UTC)

@Alexis Jazz I'm pretty sure our editors have been trying to be useful and helpful, not "hostile" to people, so maybe focus on a few things that could address some of your other concerns: Wikipedia:Request an account can certainly just be edited, and the button moved to the top, that should be an easy thing if there is some agreement. We could also make adjustments to the system messages at MediaWiki:Createacct-imgcaptcha-help and or MediaWiki:Createacct-captcha-help-url. I think the former is a better option instead of dumping someone at that external tool first, but I'm don't feel very strongly on that. Would need to test using an external link there - but that's doable. — xaosflux ^Talk 13:56, 29 May 2022 (UTC)

Xaosflux, I wasn't referring to any editor with the word "hostile", I was referring to Wikipedia:Request an account itself. It must have grown to become the monstrosity it is today, Wikipedia:Request an account (revision from 2008) was frankly better than what we have today. For people who were blocked and try to re-register it's perfect, but that's not what it's used for. If it was just the landing page my fury would be misplaced, but if only.. It keeps pushing to "just create an account yourself, you're not trying hard enough!", on the next page the second-to-last option is "I cannot read the CAPTCHA due to accessibility issues" and when you finally get to the bottom of the last page it gives you a trap button to leave first and a destructively styled button to ACC second. How welcome would that make you feel? Yes, I could edit those pages, but there's nothing there to salvage. If there ever was something that just defines WP:TNT, I'd say this is it. An external link on the system message works fine: [6]. — Alexis Jazz (talk or ping me) 23:07, 29 May 2022 (UTC)

@Alexis Jazz Good news on that test, I don't have a strong feeling on this, but think we land that on a project page - but then make the link to have someone else make that account for you right at the top. Primary reason, if that external tool is down for any reason I don't prefer one of our highly visible messages going directly there. But you are right, it is far from ideal for someone to follow in that situation. — xaosflux ^Talk 23:18, 29 May 2022 (UTC)

Xaosflux, that's a very good point, downtime just happens. A project page with the link at the top would be better in that regard. From a UI standpoint I'd prefer going straight to https://accounts.wmflabs.org/. Are there some useful stats on the uptime of that page? — Alexis Jazz (talk or ping me) 00:52, 30 May 2022 (UTC)

Make every word/term able to be defined.

In Wikipedia, it should be that while RightCtrl is pressed every word/term would become colored and clickable (with underlines for terms) and a link (if there is) to a Wikipedia page opens and if there's no page a short definition is shown for the word/term with the ability of showing more about it and its acronyms and everything. — Preceding unsigned comment added by AdamMichaels784 (talk • contribs) 16:03, 30 May 2022 (UTC)

Wiktionary. You're describing, essentially, Wiktionary. casualdejekyll 17:20, 30 May 2022 (UTC)

I think they are defining something more like an interface that lets you click any word to get to the Wiktionary entry. BD2412 T 17:24, 30 May 2022 (UTC)

The way that they've described sounds extremely annoying from a user perspective, but perhaps some kind of right-click option? I'm not sure how workable that is with the current set-up. Theknightwho (talk) 23:59, 30 May 2022 (UTC)

I believe that control+click (or a similar combination) does this on most web browsers. See also Wikipedia:Wikipedia doesn't use Allwiki. Whatamidoing (WMF) (talk) 00:02, 31 May 2022 (UTC)

Outstanding 'to-do' notifications.

Tracked in Phabricator
Task T88781

I have an idea I would like to put forth to add a new tab of a page one can edit, or some form of flagging option one can activate and deactivate, to appear on the interface to remind regular Wikipedia account users of outstanding things to do on Wiki. they may otherwise forget. Basically, some form of notification to inform the user of his/her/their outstanding commitments of things they either wish to do themselves, or have agreed to do at the request of another user, but have not yet committed to.

The sandbox, in my opinion, is insufficient for this, not least because no visual notification exists to inform the account holder of something outstanding. (Maybe some form of check box like exists in the developer tab in Microsoft Excel?) Regards, --Kieronoldham (talk) 22:59, 29 May 2022 (UTC)

@Kieronoldham can you describe that workflow a bit more? As far as what can be done already: editors can make a page, such as Special:MyPage/ToDoList, and you can use a script to make a tab point to that page. What type and in what conditions would you be looking for "visual notifications" to fire? — xaosflux ^Talk 23:23, 29 May 2022 (UTC)

Sure, Xaosflux. Basically, when you have a talk page message, or something is reverted, or you are mentioned in a comment, you get the color "visual flag" that something is for your attention at the top of your user page and you need to read the notification; what I think would be beneficial is when you intend to commit to something (e.g. add references to an article or warrant removal of a tag etc.), some notification can be "flagged as outstanding" on your interface. Maybe something one can tick or otherwise mark as done as opposed to not done, and the color "visual flag" disappears or decreases from 3 to 2 if you have honored one outstanding to-do commitment, but, for example, have two remaining as outstanding? (Happy to expound further if required.)--Kieronoldham (talk) 23:43, 29 May 2022 (UTC)

Just something automated that one cannot fail to miss/forget to see when logged in as opposed to relying on memory, Xaosflux. I did not know about the script.--Kieronoldham (talk) 23:47, 29 May 2022 (UTC)

I use User:SD0001/W-Ping, which lets me mark a page for a future notification via watchlist. Certes (talk) 23:58, 29 May 2022 (UTC)

That is intriguing, Certes. Would help many, for sure. My concern is just how many of the registered editors worldwide are this savvy, though. Would be ongoingly fruitful for Wiki. if editors had the "constant recap" I am suggesting atop their user page by default. I believe (and obv. this is just my own opinion) something of the nature I am putting forth as an idea should be default on the interface. Just my opinion, obviously.--Kieronoldham (talk) 00:06, 30 May 2022 (UTC)

@Kieronoldham: I think phab:T88781 describes some software functionality that may be needed for this to be able to work. Another avenue would be bot-based, Wikipedia:Bots/Requests for approval/RemindMeBot thought about this but the operator never went to trial. — xaosflux ^Talk 00:11, 30 May 2022 (UTC)

This is a rather interesting idea, and I currently have (as far as I'm aware) a monopoly on non-WMF echo notifications, but I'm not sure yet how exactly to implement this. Xaosflux, I got reminders for a while: User talk:Alexis Jazz (Diff 1038415593) but at some point I just stopped getting them. Not sure if it works now. — Alexis Jazz (talk or ping me) 01:02, 30 May 2022 (UTC)

@DannyS712: is Wikipedia:Bots/Requests for approval/DannyS712 bot 68 still in operations? — xaosflux ^Talk 09:24, 30 May 2022 (UTC)

@Xaosflux @Alexis Jazz it should be - I've scheduled a reminder for myself that should be posted in an hour. I won't be around then, but when I'm back later today if it wasn't posted I'll spend some time investigating DannyS712 (talk) 11:05, 30 May 2022 (UTC)

I got the reminder, so it should still be working DannyS712 (talk) 00:26, 31 May 2022 (UTC)

@DannyS712 thanks, my test worked too. Don't think this is the most user "friendly" system for someone like Kieronoldham to take advantage of, but it would work. (I am not complaining here - your bot, your rules - and thank you for following back up!!). I don't think Alexis_Jazz option with T306211 would work - since it relies on a continuously running script (though I suppose it could be turned in to some sort of crontab processor that runs on every page load via your user/common.js). So seems like there are 3 possible options:

1. phab:T88781 gets done one day and new workflows could be built (don't hold your breath)
2. phab:T306211 gets done one day, and get coupled with (a) a userscript/gadget that runs on page loads and (b) a crontab type per-user file (e.g. User/cron.json) that
3. A bot based option that does this stuff in batch in the background. Someone could build a userscript that would help manage the file that DannyS712 bot task 68 uses to make that a bit simpler to use maybe.

If anyone else has ideas, we'd love to hear them! — xaosflux ^Talk 13:33, 1 June 2022 (UTC)

@Xaosflux what would make the script be more user friendly? I'm open to suggestions, though I may not have time to implement them DannyS712 (talk) 19:05, 1 June 2022 (UTC)

@DannyS712 will follow up on your usertalk :) — xaosflux ^Talk 19:13, 1 June 2022 (UTC)

Sources collecting / Further reading

What is the best way to "collect sources" such as all related and reliable articles from websites? I can use browser bookmarks or user space but my idea is to have a list of sources close to article to use not just by myself but others as well. Personally I don't like "Further reading" section in the article and it can list only few works due to limited space. Is this a good idea to add "Further reading" section at the top of talk page? Maybe Talk:Article example/Sources is better idea (I assume it's less noticeable and may be missed)? What is the best way to arrange such list? Chronological order and division by language or website? It would be helpful especially if Google search not show up all results anymore and search is a lottery by algorithms or page is deleted (in some cases without link you can't find the article in Wayback Machine especially if website has more than 10,000 pages - you can't search in archived version inside of Wayback Machine). It's similar idea to "Reliable sources" section of wikiprojects just more detailed with direct links to articles stick to article/group of articles. Eurohunter (talk) 14:37, 4 June 2022 (UTC)

{{refideas}}? Jo-Jo Eumerus (talk) 16:28, 4 June 2022 (UTC)

@Jo-Jo Eumerus: Interesting. Is it good in case if you have 100, 200 or 400 links? Eurohunter (talk) 17:15, 4 June 2022 (UTC)

Maximum is 21, and I kind of doubt that a list of 100, 200 or 400 links would be of much use. Jo-Jo Eumerus (talk) 18:10, 4 June 2022 (UTC)

@Eurohunter: See Template talk:Refideas#22 refideas limit. --Redrose64 🌹 (talk) 18:20, 5 June 2022 (UTC)

Gambling section needs a cleanup

The entire gambling section is a mess; the citenotes are filled with spam. The reason for this is that there's good money in spamming your blog all over, since this gets you good SEO, which is the name of the game when you're competing with two entirely undifferentiated skins over the same backend software.

Take the Asian Handicap article, for instance. How do we know that Joe Saumarez Smith coined the term? The only primary sources I could find for it are Vegas Insider and BetAsia, which are both owned by one Joseph S. Smith. And yet this claim has undergone citogenesis, being found all over the web.

Also in the same article, two out of six citations are obvious spam.

I know that in cryptocurrencies, there is a strict moratorium on adding new shitcoins. Why isn't there some rule against adding links to new domains for gambling articles?

98.128.180.201 (talk) 00:55, 6 June 2022 (UTC)

Redesigning the About page

Hello, I am currently working on redesigning our about page. I started a draft at User:Interstellarity/sandbox where we can improve on the page and was hoping to get some ideas on how to redesign the page. I welcome anyone to edit my sandbox to improve the page. Interstellarity (talk) 15:40, 30 April 2022 (UTC)

Hi, I was wondering if and when I'll get a response to this post. Interstellarity (talk) 15:57, 3 May 2022 (UTC)

To get the discussion started can you explain the background to this proposed change? What issues you see with the current page? BilledMammal (talk) 16:03, 3 May 2022 (UTC)

Hello @BilledMammal,

The current About page is too long. I would like to make it more user-friendly especially for newcomers since many newcomers aren't willing to read that long of a page. I would like to shorten it like many about pages you see online. Many of the sections can easily be explained using links. Interstellarity (talk) 17:14, 3 May 2022 (UTC)

This. The current page reads like an article, not where some readers might be looking for out "About" information. — xaosflux ^Talk 15:51, 6 May 2022 (UTC)

The current page is here. It is pretty obviously far too long, but shortening it will require a lot of effort, as it suffers from the same problem that everything designed by a committee does: everyone wants to keep "their" bit in. Does anyone really think that anyone reads it? I certainly never have until now, and I've been editing for fifteen years. Phil Bridger (talk) 17:11, 6 May 2022 (UTC)

That’s exactly what I thought, but then I looked the page information and apparently it gets about 20,000 page views a day. I like the redesigned page, we need a simpler layout for it. Bluealbion (talk) 05:34, 15 May 2022 (UTC)

Yeah, I was about to say that no one even reads this. But then I realise that it has never had less than 10k views in the past 12 months and going as high as 40k views on certain days, averaging 20k daily pageviews. Obviously, a bunch of sections don't really belong to an "About" page. Take the "feedback and questions" section for example. I really like the new, shorter page, but I think some of that 20k daily viewers visit the page to read the sections that are about to be removed. Where do they go now? —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:48, 15 May 2022 (UTC)

The viewership is because this page is linked prominently on the site UI, in both the site sidebar and (at least in Timeless) the site footer. IznoPublic (talk) 18:40, 28 May 2022 (UTC)

Views ≢ readership. Phil Bridger (talk) 18:21, 7 June 2022 (UTC)

comments section

@Interstellarity: I think you have some interesting ideas. how is this proposal going? --Sm8900 (talk) 15:08, 20 May 2022 (UTC)

@Sm8900: I’m not sure what you mean by how the proposal is going. Perhaps if I make the change, more people will comment. Interstellarity (talk) 23:00, 22 May 2022 (UTC)

I see you've done that; good idea. The content is good, but I wonder if a more standard format would be better, as it is quite different from standard article format. BilledMammal (talk) 03:50, 23 May 2022 (UTC)

Let's try a format that is readable for all platforms. Just make a normal page. Moxy- 04:10, 23 May 2022 (UTC)

Help:Introduction to Wikipedia is in the format of the proposed About page. It is directly linked to home page and is right here:

Welcome to Wikipedia

the free encyclopedia that anyone can edit. Narutmaru (talk) 09:03, 27 May 2022 (UTC)

• Hi there ! I think a change like the one are your proposing needs a RfC to get community approval. I personally oppose the change, the original version has more information and gave a better glimpse of what Wikipedia is about. Alexcalamaro (talk) 04:51, 23 May 2022 (UTC)

  @Alexcalamaro: I respectfully disagree with you. While I'm not against an RfC to get community approval, About pages on many websites tend to be short and sweet. We should not provide more information than what is necessary for an About page to function to its original purpose. If we need to provide more info, we can use links to link to the appropriate page. The original About page is too long and not everyone has the time to read everything about it. We should provide at most 10 paragraphs of what Wikipedia is about so that people are more willing to read it. Interstellarity (talk) 11:59, 23 May 2022 (UTC)

Maybe we could reframe the discussion as a content v.s. title issue. I mean, the original article could be move to a new one titled "Introduction to Wikipedia" or "Wikipedia overview", and link it from a "see also" section in the "about" article you have created. Alexcalamaro (talk) 12:56, 23 May 2022 (UTC)

I agree. Narutmaru (talk) 07:52, 7 June 2022 (UTC)

We should also shift here to somewhere else if we turn the first article to this. I propose "Introduction to Wikipedia Edting" or somewhat to hold the content in here. Narutmaru (talk) 07:56, 7 June 2022 (UTC)

Ideas for revisions to Template:Basic information

I would like to propose some changes to Template:Basic information. this is based on valuable feedback and comments that I received on a prior proposal. this new proposal leaves most of the existing template in place. it mainly adds two new groups, at the bottom. I did relocate some links; I have highlighted these by using a label "MOVED" to highlight their new locations.

I welcome any and all comments, feedback, ideas, etc on this proposal. thanks!!

{{User:Sm8900/templates/template basic info two|state=expanded}}

--Sm8900 (talk) 14:35, 20 May 2022 (UTC)

Section for comments (revision to Template:Basic information)

• The Help Desk link in "Getting Assistance" is redundant to the "Requests for help" link, which does a better job of explaining which requests go where. Everything in the Research row except the Reference Desk should be in the "Sourcing and referencing row". I fail to see the difference between "Wikipedia community" and "Community groups", and don't understand why the Data section belongs in the latter. I would instead propose:
  • Move the Signpost link to Wikipedia community
  • Move the Wikipedia Library and Resource Exchange sections to Sourcing and Referencing, and add the Library Newsletter inside the parentheses after Wikipedia Library
  • Move the Data section to "About Wikipedia"

The rest would be left as it is in the original template. --Ahecht (TALK
PAGE) 15:08, 20 May 2022 (UTC)

thanks for your helpful input. Based on your comments, I renamed the section for "Community groups, news" to simply "Groups,news." the existing section for "Community" is for standing resources, under this proposal. the new section for "Groups" would be for group efforts which are intrinsically fluid in nature.

for that reason, the links for news are also included, as the news sources here illustrate new efforts, events and projects being carried out on a continuous basis by the community. the data section fulfils a similar role; it is for fluid databases and resources which provide updated data to reflect current and recent activity and changes in wikipedia.

I feel the two new sections at the bottom are useful as an addition; the point is not topical consolidation, the point is to highlight these resources due to their role as interactive and/or fluid resources for individual editors. the role of the library, the reference desk, etc is to serve as a current resource for current needs. the existing section for "reference and sourcing" highlights links to procedures for referencing, not interactive community resources. so in my opinion, that is why these new sections would be useful. I do appreciate your insightful comments on this. thanks. Sm8900 (talk) 15:14, 20 May 2022 (UTC)

• I think the organization could use a bit of work. The "information" section, for example, is sort of like a catch all and contains a real mix of stuff, there's reader facing stuff, editor facing stuff, bits of policies and guidelines etc. I would get rid of that section and move the links elsewhere, e.g. I would move the manual of style to the "policies and guidelines" section and delete the duplicate link to the simplified version. Plus it doesn't make a lot of sense to have an "information" section in an "information" template. Do you have a sandbox of this where other people can make changes? 192.76.8.78 (talk) 16:43, 20 May 2022 (UTC)

  {{ping|192.76.8.78}}, that is an excellent idea. Based on your very helpful comment, I have set up a sandbox at the page below. please do absolutely feel free to edit this in any way that you wish. and to anyone else, I can set up multiple additional sandboxes for anyone else's use; please feel free to let me know, if you wish. thanks!

Sandbox page: User:Sm8900/templates/Sandbox draft template basic info 

Sm8900 (talk) 16:50, 20 May 2022 (UTC)

Thanks, I'll make some edits in a couple of hours when I get some free time! 192.76.8.78 (talk) 17:00, 20 May 2022 (UTC)

that's terrific! by the way, I absolutely agree with all of your specific points entirely, in your comment above. please feel free to go ahead and fully make every one of the edits and revisions that you suggest above, to the fullest extent. thanks! Sm8900 (talk) 17:01, 20 May 2022 (UTC)

Now that we are at 74% using mobile view and only 25% of normal view scrolling to the bottom of the page...these templates are basically not used anymore.....thus dont care about them anymore. That said less is more....I Would recommend trimming of links not more.Moxy- 17:17, 20 May 2022 (UTC)

@Moxy, I would be totally glad to implement your suggestion to trim some parts of this template. especially since I feel that the grouping of the various pages in the existing template is not necessarily intuitive, or easy to use for the average user, editor, etc. however, i would still want to add the links that i have suggested to add, in my currrent proposal above. I would be glad to consider some other areas elsewhere in the existing template, where the overall size of this template could be trimmed. so if you wish, if you have some existing links in the current template that you think that you might wish to trim, reduce, etc. feel free to elaborate. i do appreciate your comment here. thanks! Sm8900 (talk) 17:22, 20 May 2022 (UTC)

What, is this happening again? We have had Wikipedia:Village pump (idea lab)/Archive 40#New: Template:Introductory pages for pages helpful as introduction, Help talk:Contents#Proposal for changes to nav box and Template talk:Basic information#Proposal for changes to nav box (possibly more), and I smell WP:MULTI. --Redrose64 🌹 (talk) 22:29, 20 May 2022 (UTC)

Well, I think I was pretty clear that I had a prior proposal on this item, in my opening comments above, when I said this is based on valuable feedback and comments that I received on a prior proposal. thanks. Sm8900 (talk) 02:26, 22 May 2022 (UTC)

Note on proposal

hi all. I am currently working on a revised version of this proposal at the sandbox link above, using some valuable edits provided by the IP User who has commented above. Since one commenter has alleged WP:MULTI on my part, I may try to use this existing section to achieve some kind of consensus for the proposed changes. I will resume discussion once the sandbox version is fully ready for discussion.

just for the record: for my prior initial proposal on this way back, my steps were as follows: (1) I first introduced the idea here at Village Pump for general brainstorming; then (2) I formally proposed the changes at the talk page for this navbox, and then made the changes to that navbox; then (3) the changes were reverted by a highly-respected and experienced editor, who asked me to propose the channges at the talk page for Help:Contents, which I was glad to do. when the proposal did not achieve consensus there, I waited for quite some time, and then came here to offer a totally new and alternative proposal.

In general, I am always open to all comments and viewpoints, on any proposal. I think the whole point of WP:Assume good faith is to reserve any blanket criticism for actual misconduct. any good-faith effort to bring this to the community in a fair-minded, open, and positive way, does not fall under WP:MULTI, even if one disagrees somewhat with any, or even most, of the interim steps; since the whole point of WP:MULTI is to deter people who seek to present a wholly-rejected proposal in a separate forum, without any connection to previous presentations. in the case of a proposal where one venue leads directly and positively to the next one, then any such concerns would be less relevant or applicable.

I truly appreciate the kind attention that I have received here from the community, and the valuable input above. thanks! --Sm8900 (talk) 14:44, 23 May 2022 (UTC)

NEW PROPOSAL

I would like to submit the revised navbox below as a new proposal. I have adopted some suggestions from comments here by other editors, as specified below;

• I have withdrawn any proposal to add new sections.
• We have removed over ten links, due to being overly technical/obscure or not needed for new editors. the list of removed links is at this page section.
• As a result of the above, the total size of this proposed navbox is smaller than the existing active version.

I would welcome any comments. Thanks! --Sm8900 (talk) 16:17, 23 May 2022 (UTC)

(Previous link to draft template: {{User:Sm8900/templates/Sandbox_draft_template_basic_info|state=expanded}} )

just a quick placeholder comment, to keep this talk page section active in order to enable any comments to be made, and to prevent it from being archived prematurely. thanks! --Sm8900 (talk) 13:11, 24 May 2022 (UTC)

one more reply, just to leave this topic open for feedback for just a little while longer. thanks. Sm8900 (talk) 23:53, 3 June 2022 (UTC)

ok, this change has now been done.  Done. I plan to discontinue any commments here very soon; however, with this current reply, this talk page section will now remain for at least 14 days from today, in case any further questions or comments may arise. I truly appreciate the help, input, and feedback, of all of the valued fellow members here of our editing community. thanks! Sm8900 (talk) 17:23, 8 June 2022 (UTC)

comments on new proposal

section for comments.

PROD-like function for flagging articles in urgent need of resuscitation

Tracked in Phabricator
Task T310185

Given the recent consternation at ANI over the prevalence of PROD and AfD activity, and the use of these tools to nudge articles unsuitable for deletion, I've been wondering if what is really needed is another tool, something far softer than a PROD, designed specifically to coax page improvement. Because, at the moment, a lot of old content avoids the same scrutiny as new content and enjoys, in effect, a double standard.

The use case is this: Say there is an established article that is not suitable for deletion, because it has, say, one good source. However, the article, despite being on the Wiki for more than a decade, is barely a start class, has multiple cleanup tags and is frankly a mess. It says it has two dozen editors watching it, but there has been little or no activity for many years. You are not at all knowledgeable about the subject and it is outside the types of article you are focused on editing anyway. What do you do? Quite possibly nothing, right? But what if we had a different kind of PROD, a much softer PROD of sorts, to stimulate page improvement?

This could, for instance, be a tool to actively hail all of the editors watching that page on their talk page, flagging the poor state and need for maintenance on that page. I think this would be a great first step. The articles could also be automatically fed into a a feed at WP:CLEANUP, much like AfD articles get sorted via a feed. (Not sure if there is some reason why the listing at cleanup isn't already automated by means of a tool-based feed function.) Another feature could be something akin to a PROD, with the function setting in motion a period of, say, one month, where, if no significant cleanup is managed, the article is eligible to be returned to draft.

Anyway, these are just ideas that I'm throwing out. What are people's thoughts? Has anything of this nature been considered or suggested before? Is the idea just totally unworkable? I just see a situation where the volume of content is growing tremendously and a lot of old and often highly degraded content just passes under the radar because so many editors are absorbed dealing with new page reviews and AfDs. But a lot of old articles are actually as bad if not worse than many new page submissions, and, were they submitted today, would clearly not pass AFC and would certainly remain in draft. Iskandar323 (talk) 08:02, 8 June 2022 (UTC)

I think that there might be some cleanup listings by project around. But there are so many on the list that attention is unlikely. If you post a note on a project notice board about one article you may stir up some help for that one. Graeme Bartlett (talk) 11:15, 8 June 2022 (UTC)

We already have many such processes: cleanup tags, WikiProject templates that have an |attention= parameter, WikiProject talk pages, noticeboards, user talk pages, pings, etc. They obviously don't always lead to immediate attention—because this is a huge project, people are free to work on what they like, and we have no deadline—and I don't see how a new process like this would be any different. If new articles are getting more scrutiny than old articles, I'd suggest that the problem there is the non-policy-based gatekeeping that has crept into our new page review processes, not the old articles. For example, if AfC is declining drafts that couldn't be sent to AfD if they were in mainspace, then AfC is broken, because it's sole purpose is sifting drafts that aren't like to pass an AfD. – Joe (talk) 11:42, 8 June 2022 (UTC)

It is technically impossible to send talkpage notifications to users watching a page. Information about who watches a page is not available to any wiki editors, only developers have access to it. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:17, 8 June 2022 (UTC)

And it should stay impossible for privacy reasons. —Kusma (talk) 13:29, 8 June 2022 (UTC)

However -- that doesn't mean that a means to generate echo notifications to page watchers couldn't happen. It would preserve privacy of the watchers. Would likely need a permission to prevent abuse of such function - and of course people could opt out of that echo type. Thoughts? — xaosflux ^Talk 14:00, 8 June 2022 (UTC)

Some "generic" types of these are in subtasks of phab:T125653 - but perhaps a "Send free-form notification to all watchers of a page", Allow a short message (edit summary style) - log that it happens publicly, including what the message says (similar to mass message sending), require some permission to do so (that then we could issue to say extended confirmed users, bots, admins). — xaosflux ^Talk 14:06, 8 June 2022 (UTC)

I think the message should just be posted on the article talk page, and perhaps some people can flag their message as "ping all watchers". We don't need an additional way to send text to people already watching a page where text can be added. —Kusma (talk) 14:13, 8 June 2022 (UTC)

@Kusma hmm so perhaps what I was thinking above above, but no free-form text - it would just send a notification of the diff? — xaosflux ^Talk 14:26, 8 June 2022 (UTC)

@Xaosflux: Exactly. This also avoids sending a secret message to talk page watchers without a permanent public record. —Kusma (talk) 14:37, 8 June 2022 (UTC)

@Kusma in my idea above the message content would have been public, the destinations would have been secret. But this sounds much simpler in any case. I'll try to open a feature request on it soon, but don't hold your breath that it gets implemented without maybe the 2023 wishlist pushing it up! — xaosflux ^Talk 14:43, 8 June 2022 (UTC)

@Xaosflux, @Kusma: Cool idea, and potentially a good way to leverage existing page watchers. Thanks for giving it your attention. Iskandar323 (talk) 14:52, 8 June 2022 (UTC)

If I understand correctly, you are proposing there be a logged notification to page watchers of a new diff, without identifying the recipients of the notification? isaacl (talk) 14:54, 8 June 2022 (UTC)

phab:T310185 yea, log could either be a revision flag (Z = include watcher notification) or a log like (User:Isaacl sent an edit notification to page watchers in edit Diff/x) or the like. — xaosflux ^Talk 14:56, 8 June 2022 (UTC)

The reason why it could be a useful function is that page watchers are a demographic that at least presumably are marginally interested in the material in the first place, compared to other forms of listing that might target a broader, but more general and less interest-specific demographic. The key advantage of a notification directly to the talk pages of watchers is that for less frequent users the notification would have more permanence and be more likely to generate awareness than a rather more transitory watchlist status update. Iskandar323 (talk) 14:31, 8 June 2022 (UTC)

The one problem with using their talk pages is that "who is watching a page" is secret, and that would reveal the list. — xaosflux ^Talk 14:57, 8 June 2022 (UTC)

Yes, I understand now that there's a fundamental privacy problem there. No matter, the less intrusive ping is likely a better idea anyway. Iskandar323 (talk) 15:05, 8 June 2022 (UTC)

A "ping all watchers" function for talk page messages isn't a bad idea either though - that would obviously also be more 'alerting' than watchlist. Iskandar323 (talk) 14:35, 8 June 2022 (UTC)

Yes. One of the problems with watching talk pages is that most of our page archiving bots do their best to hide the existence of new threads. Far too many pages have automated archiving even where that does more harm than good. —Kusma (talk) 15:01, 8 June 2022 (UTC)

We could probably get a Quarry query to identify aggressively archived Talk: pages, and see about removing/slowing archiving from them. WhatamIdoing (talk) 16:05, 8 June 2022 (UTC)

I don't think we need a new process, we need new people who do the actual work... —Kusma (talk) 13:28, 8 June 2022 (UTC)

I don't think we need a new process, we need new people who do the actual work.. North8000 (talk) 13:41, 8 June 2022 (UTC)

We have 3.7 million stubs. Out of all content articles with an assessment (excluding lists), fully 90% are stub or start class. We have lots and lots of ways to say "this is a stub", lots of ways to tag pages for cleanup, lots of ways to try to involve WikiProjects, etc. It's hard to prod people into action based on "this article I just stumbled upon is a more urgent than the other millions of articles on our collective to-do list". There needs to be a better reason (something in the news, a vital article, a core topic, etc.). As someone with a 5-figure watchlist, I would not be up for pings flagging problems with articles on my watchlist -- there are just too many with problems. Fix what you can, tag if necessary, coordinate improvement drives, etc. if you have the time. — Rhododendrites ^talk \\ 17:03, 8 June 2022 (UTC)

@Rhododendrites: The obvious follow-up to that is: then how would you feel about using such a tool for degraded or neglected vital articles or core topics? Iskandar323 (talk) 17:14, 8 June 2022 (UTC)

Even if the notification option I suggested gets built above were done, it would certainly be able to be disabled like other notification types. — xaosflux ^Talk 19:02, 8 June 2022 (UTC)

RfA Reform.. Again

We've had an RFA reform last year and the signpost article suggested that change was imminent. Is it good timing to start another one this year? I would like to participate but don't have the experience needed to start the entire thing. 0xDeadbeef 08:35, 24 June 2022 (UTC)

question re options for threaded group conversations

is there any way to create or utilize some kind of threaded discussion format, i.e. similar to the internal messaging app that would be available for users of Facebook, LinkedIn, Twitter, etc? I think that maybe that might be highly useful here.

I guess that maybe one thing I am thinking of is having some sort of an in-box for individual messages as well as group meesage threads, available to users here, similar to what a user at facebook would routinely utilize? please feel free to let me know. thanks! --Sm8900 (talk) 17:03, 8 June 2022 (UTC)

@Sm8900 you may be thinking of something like WP:FLOW. For an example of a page using Flow see mw:Talk:Talk pages project. High-level, it has a bunch of technical problems with the way we use many of our pages. A new set of tools (Wikipedia:Talk pages project) are being worked on right now, and you can enable some in your preferences to try them out. — xaosflux ^Talk 18:59, 8 June 2022 (UTC)

@Sm8900 I think private group chats are a really bad idea. Wikipedia is fundamentally a very open website governed by consensus, having groups of editors discussing things behind closed doors creates all sorts of problems related to consensus building, distrust and canvassing. For an example of this have a look at the recent guerilla sceptics or wikiproject tropical cyclones arbcom cases which demonstrate many of the problems related to private chat groups. You also have to consider how these private groups will be moderated - who's going to remove illegal or grossly inappropriate content? How do you enforce policies like BLP? How do you stop wikipedia being misused as a free private messaging app by people who have no intention to contribute? We had a lot of issues moderating the semi-private "collections" feature that was introduced a few years back, moderating tens of thousands/hundreds of thousands of private chat groups would be a massive job. 192.76.8.78 (talk) 15:03, 10 June 2022 (UTC)

@Sm8900 You should have gotten a notification in your inbox that I had replied to you here. The ping notification system and your talk page basically are "some sort of an in-box for individual messages". Also, if you enable the new reply tool feature in your preferences, you will see a link to "subscribe" to individual discussions, so you get notifications whenever someone replies to them. I wouldn't say it's "similar to what a user at facebook would routinely utilize", because Wikipedia is not Facebook, and discussions here serve a different purpose and need different tools. ~ ONUnicorn^{(Talk|Contribs)}problem solving 15:16, 10 June 2022 (UTC)

these replies are all extremely helpful. I want to take some time to give these some real thought, and then reply further in a little while. thanks! Sm8900 (talk) 16:02, 10 June 2022 (UTC)

CfD backlog and closing instructions

We are hosting a discussion of ideas at Wikipedia_talk:Categories_for_discussion#Backlog_reduction to reduce the notorious CfD backlog, and why it is far worse than other XfD pages.

Marcocapelle (talk · contribs) has suggested at Wikipedia_talk:Deletion_process#Attempt_to_make_instructions_for_closing_CfD_discussions_better_readable that one reason for the perennial CfD backlog is that the closing instructions at Wikipedia:Categories_for_discussion/Administrator_instructions are unclear; they have a rewrite drafted at User:Marcocapelle/sandbox2. See the relevant pages for further discussion.

At the main backlog reduction, I have suggested that WP:CFD/W should be reorganized and linked from a more visible place on the main CfD page. A planned feature for XfDcloser seeks to bypass this subpage for closures that can be implemented automatically. –LaundryPizza03 (dc̄) 05:12, 18 June 2022 (UTC)

• Thank you for posting this here. I should add that the rewrite is not a revolutionary rewrite. One thing I have focused on in particular is to reduce the amount and depth of bulleting, because imho that makes the current text very overwhelming. Other proposed changes are commented in the proposed text. Marcocapelle (talk) 05:25, 18 June 2022 (UTC)
• Also, if it is useful to move the proposed text to somewhere outside user space, please ping me to let me know to where. Marcocapelle (talk) 05:29, 18 June 2022 (UTC)

Personal censoring as an option for an account

If you log in, you can select certain kinds of articles that contain material you might consider objectionable. So the article would have a tag or maybe even images would have a tag which would cause them not to be displayed unless you chose to view them. This allows individual users to prevent themselves from seeing material they find objectionable. It doesn't prevent anyone else from doing so.

2600:6C4E:1200:1E85:28F3:C4B0:B9A8:3958 (talk) 14:39, 19 June 2022 (UTC)

See Help:Options_to_hide_an_image If you create an account, there are several options to hide images. RudolfRed (talk) 19:14, 19 June 2022 (UTC)

See also m:Image filter referendum/en. Basically, enough people opposed it in 2011 that it's unlikely to happen. The opposes had a variety of reasons; offhand, common objections included:

• Someone would have to tag that.
• If I decide to put an image in an article, then anyone who refuses to look at my picture is violating my sacred free speech rights.
• Nobody will ever agree on which categories to implement, even though everyone knows that sex, disgust, and violence are the main subjects that produce complaints. (Think: stills from porn films, disgusting medical situations, and violent rapes. Complaints about spiders – the usual example given – pale in comparison to complaints about unexpected or unnecessary nudity [from Africa, most of Asia, and the US] or about violence [Europe]. As for disgusting pictures, have a look at Talk:Smallpox. Requests to remove images are probably the single most common question on that page.)
• People should not live in countries (or schools, or families) in which they can get arrested or beaten for having pictures of naked bodies and/or sex acts on their computer screens.
• "Strictly optional" means the same thing as mandatory.

I've written these in a possibly provcative style, but these are not all entirely unreasonable objections. Someone would have to tag the images, and whenever anyone tags anything, we argue over it, and we can expect vandals to abuse it. If you build a system that permits optional blocking, then someone (e.g., a school system) might be able to find a way to make it mandatory. It's a matter of balancing rights, and the editors who participated in that discussion were not generally sympathetic to the readers' rights to read only what they wanted, and many of them were very concerned about ways such a system could fail. WhatamIdoing (talk) 00:32, 20 June 2022 (UTC)

I remember responding to a similar suggestion a long time ago. The gist of my response was that this is straightforward to implement as an add-on service. Build a system which lets a person view images and apply tags to them, which you then store in your database. You could publish a bit of javascript, perhaps as a gadget so it's easy for people to enable, which gets loaded each time you view an article. The gadget would find all the images, look them up in your database, and do some trivial DOM manipulation to hide the ones which match whatever set of filters the user desires.

This seems like it would fit under the umbrella of WMS Cloud Services, so it wouldn't even cost you anything. You'd need to write the software, but nothing I described is terribly difficult. You'd also need to crowd-source people to do the tagging, but that's how everything works here.

Just because you haven't been able to sell the community on doing it as an official part of the project doesn't mean you can't do it yourself. The hard part (by a long shot) will be finding enough people willing to do the tagging. But at least if you do it as a side project, you and your fellow taggers can agree amongst yourselves on the tagging criteria. I may not agree with your criteria, but nobody's saying I need to install your gadget. -- RoySmith (talk) 00:57, 20 June 2022 (UTC)

That (the image blocking option described in the help page) works well enough for me. Thank you.

2600:6C4E:1200:1E85:28F3:C4B0:B9A8:3958 (talk) 07:59, 20 June 2022 (UTC)

See Wikipedia:Village pump (technical)/Archive 186#NSFW project for wikipedia on Phabricator under construction. One person's "offensive, how dare they" ia another person's "meh". To my mind, you can block all images, or none. You can't find a happy medium that allows all the nice ones through but denies all the nasty ones. There's just been a TV prog on BBC1 about the responsibilities of social media regarding kids getting to see pics of knives. --Redrose64 🌹 (talk) 19:31, 20 June 2022 (UTC)

Idea: Add affiliates to WikiProject banners

Hello! I noticed that {{WikiProject Australia}} has a note about Wikimedia Australia as an option for non-editorial help. Does anyone have any thoughts on adding a default option for such in {{WPBannerMeta}}? Thanks! 🐶 EpicPupper ^{(he/him | talk)} 01:14, 22 June 2022 (UTC)

Overzealous archiving

I've noticed a lot of article talk pages have "|minthreadstoarchive =" set to "1". If you are like me and want your watchlist to be actually remotely useful and not fire hose of ANI replies, you have the "latest edit" filter turned on. This has the unintended effect of hiding any new discussion threads opened on the talk page. That is, if "|minthreadstoarchive =" is set to one, any new topic to a talk page will be obscured from my watchlist when a bot comes by 12 hours later to archive the oldest thread. In my watchlist, I can only see that a bot archived one discussion thread. I cannot see that Randy in Boise has proposed to delete the main page.

I can't think of a legitimate reason for discussion pages to be archived on a one-for-one basis. Solution: "|minthreadstoarchive =" must always be set to ≥ "3". Thoughts? Schierbecker (talk) 00:41, 3 June 2022 (UTC)

Schierbecker, I think you're expected to exclude bot edits from your watchlist. (which I don't because reasons) But with the "latest edit" filter enabled that won't help IIRC. It bugs me too, but what can you do. — Alexis Jazz (talk or ping me) 04:22, 3 June 2022 (UTC)

I don't exclude bots either for the same reason as above. My only solution has been to nuke half my watchlist and to check more diligently. Schierbecker (talk) 04:32, 3 June 2022 (UTC)

I think it's best if most pages are set to |minthreadstoarchive=4. I thought that used to be the default, but it appears that unless you explicitly state more than 1, it will remove all except the most recent. WhatamIdoing (talk) 20:07, 7 June 2022 (UTC)

I think that in addition to the above, archive bots should mention the topic of the last human post in their edit summary. For pages that only have edits every two weeks, bots should also not archive anything when the most recent human edit is less than a week old. —Kusma (talk) 12:17, 19 June 2022 (UTC)

I don't think you've thought this through. What if the last human post was talk-page vandalism? I'm sure you don't want that memorialized for all time in the un-editable edit summary. WhatamIdoing (talk) 23:50, 19 June 2022 (UTC)

Adding a new section already generates an edit summary with the new section title. So I am not so concerned. Can be oversighted the normal way if it is really that bad. Schierbecker (talk) 03:03, 20 June 2022 (UTC)

I was imagining that the vandal would change an existing section heading, rather than adding a new section. I'm not sure that we need edit summaries that contain vandalism even if they aren't bad enough to oversight. WhatamIdoing (talk) 04:18, 20 June 2022 (UTC)

Would this not just make the problem happen once every 3 talk posts rather than every new talk section. So you would still miss 1 every 3 posts. This doesn't really fix your issue and will just create longer talk pages since when a section is ready to be archived it will need to wait until another 2 are also ready to archive. This is not a great solution to a minimal problem since it is not arduous to check a talk page which has just been archived by a bot. Terasail^[✉️] 12:42, 19 June 2022 (UTC)

It may not be arduous, but 98% of Wikipedians don't do it. Very often, new posts to an article or Wikiproject talk page that don't get an answer in the few hours until a bot edit is top of the watchlist will not get an answer for weeks. —Kusma (talk) 12:47, 19 June 2022 (UTC)

If you have two memory sticks to rub together, I promise the three extra posts on the talk page will not destroy your computer. :) Schierbecker (talk) 03:09, 20 June 2022 (UTC)

Another option that may be better could be a userscript that detects and shows the summary for the previous edit before the archive in the watchlist? Terasail^[✉️] 12:49, 19 June 2022 (UTC)

or the last section created.. Terasail^[✉️] 12:50, 19 June 2022 (UTC)

The problem I want to solve is that others don't see my edits, not that I don't see the edits of others, so I don't see how userscripts will help. —Kusma (talk) 13:01, 19 June 2022 (UTC)

I'd bet that 98% of editors don't check their watchlists at all. Most editors are inactive. Even among active ones, many don't use their watchlists or even know that they exist. Only 22% of the accounts watching this page have visited Special:Watchlist during the last 30 days, and this is a popular, high-traffic page.

If your problem is that the default prefs setting hides bot edits from the watchlist, why don't you just see about changing that prefs setting to show bot edits? Or to show every single edit separately, so that bot edits can be hidden without the previous edits being hidden? (I personally loathe that style, but it had its supporters while they were working on mw:Help:New filters for edit review – for all I know, they might have changed the default years ago, and we're talking about a problem that only affects old-timers like us.)

It still won't do you any good on a page like Talk:750 Seventh Avenue (number of page views that weren't you or the GA nom during the last month: likely zero, definitely less than six), because almost nobody else is watching that page in the first place, but at least on higher traffic pages, you'd see more. WhatamIdoing (talk) 00:03, 20 June 2022 (UTC)

My frustration mostly comes from pages like Wikipedia talk:WikiProject Germany having become ghost towns (and I am aware that archive bots making watchlists suck is just a small piece of the reasons for that). There were a few years when topic-related noticeboards and WikiProject pages used to work, but they no longer do. Now the best ways to find people who know something in a topic are what they used to be before WikiProjects: either look through article histories to find experts or to ask in a less targeted place like on IRC or Discord and hope for the best. —Kusma (talk) 13:41, 20 June 2022 (UTC)

Two quick things, @Kusma. The first is: @DannyH (WMF), remember your ideas about "neighborhoods"? We could use some thriving ones, and I wondered if you had any ideas here.

Second, have you all tried to WP:REVIVE the group? You've got 33 people watching the page who have checked their watchlists during the last 30 days. That's not a lot, but it's probably enough. Can you ask the experienced or semi-experienced people listed at Wikipedia:WikiProject Directory/Description/WikiProject Germany#Active Subject-Area Editors to put the WikiProject's talk page on their watchlists? This is a small favor that can bring renewed activity. Also, can you get a little 'chatter' going? It could be personal information ("Anyone visiting a new part of Germany now that travel restrictions are being lifted?", it could be talking about what you're doing ("Just cleaned up this article..."), it could be a simple project like addressing one of the smaller backlogs (start small, because you want it to be successful), it could even be a new collaboration (may I invite your group to come play at Wikivoyage for a day? Would you like to have an informal meeting at Wikimania? How about finding friends at another WikiProject, like MILHIST or FOOTY and working on an article that overlaps?). I think you've got a lot of potential. A little bit of steady effort could bring the results you wish for. WhatamIdoing (talk) 02:46, 22 June 2022 (UTC)

No fair being constructive while I'm busy moaning! :) Yes, doing these kind of things would help. In fact, I spent a lot of time and effort doing that kind of things over a decade ago, but it became a chore at some point and contributed to me getting burned out. I didn't know the "Active Subject-Area Editors" listing, that is a neat idea but (as usual) defeated by the combination of gnoming and a too large WikiProject (I am pretty sure BD2412, BrownHairedGirl and Ser Amantio are on this list for every single WikiProject). —Kusma (talk) 09:00, 22 June 2022 (UTC)

And if they put every single WikiProject on their watchlists (and actually checked their watchlists), then anyone asking for help at those WikiProjects would get a reply.

I think groups work best if there are several people doing things like this. Then any individual can step back when it becomes a chore, and step up when it looks like fun again. WhatamIdoing (talk) 19:55, 22 June 2022 (UTC)

As an aside, I find the "Group results by page" option on the new watchlist system to be a useful compromise (I'm not sure if I first started using it for that reason but anyway) in that it normally has everything on a page collapsed to a single line, but it allows you to see all the edits if you wanted. Alpha3031 (t • c) 13:45, 19 June 2022 (UTC)

Idea: In policies and guidelines, place links to the discussion pages that shaped them -- so all Wikipedians can easily learn of the decision-making processes and rationales behind policies

Hi everyone.

• The "problem": When you lookup Wikipedia policies and guidelines it is very difficult to find out the decision-making that has shaped them.
  • In other words, there is a lot of deliberation and effort that has gone into shaping those policies, but those deliberations become hard to know about unless you were taking part in them.
    • When I look up policies, I often wonder: What were the pros and cons that were weighed in choosing a certain policy? What were the arguments made? How much support did the final decision get?
• Why it matters: Wikipedians more easily learning how a policy decision was made can:

1. Make Wikipedia policies more robust and stable because all the underlying argumentation is accessible to everyone
2. Conversely, it can also help update some policies by more easily knowing when a policy was decided based on circumstances or arguments no longer applicable.
3. Reduce potentially unnecessary discussions when new Wikipedians not privy to the original decision making repeatedly propose changes that may have been already repeatedly considered previously.
   1. This also helps avoid "biting newcomers" by not having to resort to "shutting down" well-intentioned proposals that seasoned editors from their vantage point see as redundant.
4. Make new proposals or changes to policies much more grounded, constructive, potentially productive, by the proponent and any others being aware of previous deliberations.
5. And maybe redundant but in other words: it creates a more transparent system of institutional knowledge, so that the deliberations and decision-making of earlier generations of wikipedians are visible to later generations of wikipedians.

• Idea: In the policy pages, near specific pieces of them, place small unobtrusive links to the discussion(s) that created or modified them.
  • Further, to be practical, I would propose this apply going forward (new decisions get linked to their policy outcomes), but without requiring reconstructing and linking all past discussions to all existing policies, which I understand would be a near-impossible task (which speaks to the system being opaque in having decision-making and outcomes quite difficult to connect after the fact).
    • And to be clear: I am not positing that the currently the policy-making discussions are completely lost; they do exist deep in the wiki and someone really motivated could dig into the years of history of conversations in the Village Pump to painstakingly reconstruct a specific decision. The point here is to make easy to find them by creating a link between the policy outcome and the policy deliberation process.
• Because this is the idea lab, I am not coming here with a ready-to-implement proposal, but a more general idea/rough draft so get a sense of whether I am going in the right direction with this. What does the community think of the general sentiment? And, do you have any ideas on how to better implement it? Thank you. Al83tito (talk) 18:19, 2 June 2022 (UTC)

@Al83tito the refernces system can be used, along with the project talk. For example see Wikipedia:Administrators#Notes - is something like that what you are looking for? — xaosflux ^Talk 18:54, 2 June 2022 (UTC)

@Xaosflux Yes! The footnotes of Wikipedia:Administrators#Notes are a good example, and more specifically footnote #7 links to the discussion where a decision was made. That is indeed a real-life example of what I'd wish we could consistently do going forward. And while somehow first I thought of placing links adjacent to each piece of policy, the footnote system is more natural since we usem them all the time in actual articles.

This certainly sounds like a good idea, if it's not already done for most policies and guidelines, in that it promotes transparency and avoids reinvention of the wheel. I haven't thought about this for long yet, so there may be downsides that I haven't thought of. Phil Bridger (talk) 19:34, 2 June 2022 (UTC)

• I like the idea, but I am not sure if it is practical. One issue is that most policy and guideline provisions have evolved over time.

A particular provision might have first entered a policy back in 2006 - but it might have been reworded in 2010, tweaked several times between 2013 and 2016, and then reworded again in 2020… etc. Each rewording and tweak has (or should have) a related talk page discussion - and sometimes more than one. So deciding which discussion(s) to link to in the footnotes would be difficult. Blueboar (talk) 00:03, 3 June 2022 (UTC)

@Blueboar if I understand you correctly you make two points: 1) it is too difficult now to go back in time and figure out all the multiple discussions that led to the shaping and reshaping of a piece of policy. And what I thinks is your larger point: 2) whether looking backwards or forwards, policies typically may be reshaped many times that it is too difficult to track all the decisions points even if we start from this point forward.

And you make good points that those are real hurdles to reckon with. I would like to brainstorm here , after identifying these challenges, if they are surmountable. I have some thoughts about potential remedies:

1. This proposal would only apply going forward, so no unreasonably exacting rule is retroactively applied on existing policies and guidelines today.
2. Wikipedia as a digital encyclopedia has the advantage that the space for footnotes is unlimited and mostly unobtrusive, so that multiple footnotes can be added to a piece of policy as it continues to evolve for a good number of years without creating clutter.
3. By placing in-line citations at the side of each piece of policy (each sentence of paragraph as appropriate), we can keep track of individual decisions at a more granular level. The more granular we go, the less likely is that a small piece within a policy page would be changed so frequently and therefore create a problem of a too-large a cluster of in-line citations.
4. I believe that many pieces of policy are quite stable, and therefore would not suffer from a challenge of "overcitation".
5. Conversely, if some piece of policy undergoes numerous proposals and modifications, I think that makes it all the more valuable to place citations there to point to all the arduous past work done by the editors to come to that policy, and so any additional modifications benefit from the knowledge of all the past deliberations. I think that in the long term it would foster more stability in the rules, and better informed new proposals.
6. And finally this potential a proposal could state that linking to policy bits to discussions would be a requirement only when the modification is significant (not trivial). Editors often make judgement calls on how much or little to reference a claim, for example, so I think this rule would go along those lines.

As I was pondering more about this I realized that another simplified way to put forth this potential proposal is that what this idea is about is extending the core principle of Verifiability to also apply to Wikipedia's documentation on its policies and guidelines. Since verifiability is so central and esteemed in Wikipedia, and we have plenty of experience implementing it through reasonable in-line citations, I think we could find a reasonable way to apply it to the documentation that governs the project.

Thanks! Al83tito (talk) 17:32, 3 June 2022 (UTC)

@Blueboar: My digging through old archives suggests that the more ancient parts of policies and guidelines tend not to have had extensive or explicit discussions that led to them, which complicates part of what's going on. The more ancient forms of WP:NPOV were (to some extent) created by Bomis employees for NuPedia without apparent extensive community discussion. NPOV is core to Wikipedia, but it's also something that (according to older versions of the page) partly predates Wikipedia itself. — Ⓜ️hawk10 (talk) 18:13, 3 June 2022 (UTC)

In the early days, most discussions happened off wiki (mailing lists and IRC). Talk pages – the entire concept of namespaces, in fact – did not exist until the English Wikipedia was about one year old; therefore, you will never be able to find an original talk-page discussion about anything that happened in 2001. See mw:Talk pages consultation 2019/Discussion tools in the past for more information. WhatamIdoing (talk) 19:39, 7 June 2022 (UTC)

• On reading through the comments here I would still support this proposal with the proviso (as should be the case with anything, whether policy, guideline, essay, procedure, or something else) that it should be treated with a bit of common sense. If it cannot be done in a particular instance then don't do it, but I would have thought that in most cases where it could be at all controversial it could be done. Phil Bridger (talk) 18:46, 3 June 2022 (UTC)

  @Phil Bridger Agreed, and thank you very much for your comments. Al83tito (talk) 17:20, 6 June 2022 (UTC)

• It's worth pointing out that we already do this, sometimes; see the notes on Wikipedia:Drafts, for example. RfCs and other discussions are also often linked in edit summaries. I think it's a good idea and I don't see any reason why you (anyone) couldn't add more "references" like this, if you find the relevant discussion. Although it's important to bear in mind that it's by design that most of our policies evolved without explicit discussion, and lack of a reference shouldn't be taken as lack of consensus. As Mhawk10 says, some of our most important principles were never formally discussed because they have been accepted from the beginning and shaped subsequent policy. – Joe (talk) 07:44, 4 June 2022 (UTC)

  @Joe I very much agree that in the policies and guidelines, lack of a reference shouldn't be taken as lack of consensus. Thank you.Al83tito (talk) 17:20, 6 June 2022 (UTC)

  I'm convinced that it will be taken as lack of consensus. WhatamIdoing (talk) 19:40, 7 June 2022 (UTC)

  In line with this, I back adding formation and "major change/controversial change" RfCs to the bottom of the policy pages to which they apply (with formation RfCs, that seems to be fairly common for new PAGs these days anyway). I'm not sure I would support adding a reference to each new discussion (assuming it got a discussion). Nosebagbear (talk) 08:34, 6 June 2022 (UTC)

  @Nosebagbear thank you for your comments. Al83tito (talk) 17:20, 6 June 2022 (UTC)

• @Xaosflux, @Phil Bridger, @Blueboar, @Mhawk10, @Joe,@Nosebagbear: Thank you all for your thoughtful responses to this idea; they will help it become a better idea. I will ponder on all you have said and I will try to develop a new iteration for your later consideration. Thank you very much. Al83tito (talk) 17:20, 6 June 2022 (UTC)

  Oh sure, in general, if you see some policies that have some especially important points that were discussed, you can add a reference to a past discussion, but it will take a lot of work to try to find everything. In some cases we document very extensively, but it can also make the text look complicated - see Wikipedia:Requests for comment/Arbitration Committee Elections/ACERFC decisions to date for an example of having almost everything point to a prior discussion. — xaosflux ^Talk 17:39, 6 June 2022 (UTC)

We have that now.....we can see what changes were made when and all of the discussion history. North8000 (talk) 17:43, 6 June 2022 (UTC)

@North8000 somewhat, sure the pages have histories - but the discussion that led to a specific revision may not be on the pages associated talk page, or linked to from an edit summary. — xaosflux ^Talk 21:45, 6 June 2022 (UTC)

For example, I can think of one sentence where the latest rev. took about 500,000 words, multiple RFC, spread amongst multiple archives, plus some at notice boards and Jimbo's talk page. Where would the link to that one go?  :-) North8000 (talk) 22:16, 6 June 2022 (UTC)

I'm not convinced by the rationale.

1. Make Wikipedia policies more robust and stable because all the underlying argumentation is accessible to everyone – except that Wikipedia:Nobody reads the directions, and they certainly aren't going to read the footnotes in the directions.
2. Conversely, it can also help update some policies by more easily knowing when a policy was decided based on circumstances or arguments no longer applicable – You can do this now. If a page is not giving advice that you believe is helpful and relevant to your situation, you should ask about changes, and you should do this no matter what someone said or thought in the past.
3. Reduce potentially unnecessary discussions when new Wikipedians not privy to the original decision making repeatedly propose changes that may have been already repeatedly considered previously – so long as newer folks are telling us about genuine problems that they're encountering, we want them to tell us about it. We don't want them to give up because it's the fifth time this has been discussed, or because a 15-year-old RFC was summed up in firm language.
4. Make new proposals or changes to policies much more grounded, constructive, potentially productive, by the proponent and any others being aware of previous deliberations – anyone who wants to do that can usually find out by (a) searching the archives or (b) asking the regulars on that talk page. This is a lot of work for limited additional value.
5. And maybe redundant but in other words: it creates a more transparent system of institutional knowledge, so that the deliberations and decision-making of earlier generations of wikipedians are visible to later generations of wikipedians – I agree that it is somewhat more transparent, but it will also have the very negative effect of enshrining our old decisions as The One True™ Decision.

Overall, I think this will discourage editors from updating and adapting policies. It will tend to carve decisions in virtual stone, including decisions that were meant to be experimental or small improvements. I haven't looked up how much experience you have with policy writing (which is hard, and a distinct skillset), but to give you an idea of my vantage point, just between Wikipedia:External links and Wikipedia:External links/Noticeboard and their talk pages, I've probably made more than 2,000 edits over the last 15 years. I think it's a very good guideline, and I think that I am one of the (two) best-informed editors about its contents and history, but I do not think that it would benefit from careful documentation of its history. Some changes I've made to it have been discussed; some changes have not. Some thoroughly discussed changes have been contentious and hotly disputed; some undiscussed changes have been embraced as obviously correct. Some changes we would have to describe as "undiscussed*", because the idea arose from a series of comments or situations, and having resolved individual disputes, I (or others) documented the pattern that we saw developing in these individual discussions.

And this leads me to say: The main source for most policies, guidelines, help pages, etc., is what editors are already doing. The ideal is "After some trial and error, everyone seems to have settled on _____ already, so let's write this down as a convenience for new folks". The ideal is not a major discussion creating rules out of nowhere. WhatamIdoing (talk) 20:05, 7 June 2022 (UTC)

Sure, but if we have had a major discussion (as we often do), what's the harm in documenting it more clearly? – Joe (talk) 21:06, 7 June 2022 (UTC)

As I said: "Overall, I think this will discourage editors from updating and adapting policies. It will tend to carve decisions in virtual stone".

If you look at a line in a policy or guideline today, and you think it could be improved, then you might try to improve it. However, if you look at the same line and see at the end, then you might decide that it's not worth bothering. You would probably expect someone to tell you that you have to overcome the heavy weight of four prior discussions; you might even tell yourself this story. I would also expect to see made-up rules like "There was an RFC eleven years ago about something in that paragraph, so you have to have an RFC before you can change anything in that paragraph" or "Since a total of 18 editors supported (some aspect of) the current version on those old discussions, then we should assume that all 18 of them still WP:SILENTly oppose all changes, so you have to get at least 27 editors to support your proposal, because 60% approval is really quite minimal for a change to a policy."

The English Wikipedia needs to be able to adapt its policies and guidelines. Wikipedia:Consensus can change, even about policies and guidelines. The overall effect of this proposal is to make it more difficult to make any changes to these pages. That will result in the policies and guidelines not accurately reflecting editors' normal practices. WhatamIdoing (talk) 03:36, 8 June 2022 (UTC)

I think it's a stretch to say editors care about how many reference indicators are at the end of sentence on a guidance page. We already have endnotes on some policy pages pointing to underlying discussions, and none of these negative effects you are listing have come to pass. (At the recent RfC for sports-specific notability criteria, we got the opposite: the closer used the current-day results to cast doubt on the consensus that had been affirmed repeatedly in the past.) Editors continue to make changes boldly, in the same way they edit articles boldly, even with their endnotes. isaacl (talk) 05:55, 8 June 2022 (UTC)

Unfortunately, I don't think it's a stretch to say that some opponents of a proposed change would do this. Many editors are unaware that WP:PGBOLD is a long-standing policy, and wikilawyers regularly invent bureaucratic requirements that favor "their side". WhatamIdoing (talk) 15:34, 8 June 2022 (UTC)

Personally, I think those who resist minor changes are going to do so regardless of the presence of citations. I don't think it should be mandatory to point to the underlying discussions. I see too much time wasted speculating about why a passage was added, though, and so think citations can be helpful to skip ahead and actually discuss the issues at hand to determine current consensus. isaacl (talk) 20:45, 8 June 2022 (UTC)

It sounds like you're describing the status quo. If you try to change a part of a policy that is based on an RfC or well-attended discussion, you'll be sharply reverted. At least with the footnotes, it's visible which parts are more or less difficult to change. – Joe (talk) 07:07, 8 June 2022 (UTC)

I think you'll find it's more complicated than that. I can make a substantive edit to a policy or guideline without it being reverted; a newbie can't. I can copyedit a policy or guideline without it being reverted; some others can't. Some of this is skill-based (e.g., I have a pretty solid grasp of English punctuation), and some of it is knowing the our culture and systems (e.g., I know that this fairly obvious edit will someday benefit from a paper trail to protect it from wikilawyers), but some of it is reputation-based: we are slower to revert admins, highly experienced editors, people we know, etc. Even for text that is based on your "RfC or well-attended discussion", some changes can be made boldly and others will require careful negotiations.

My concern with adding documentation is that some editors will be scared off from even attempting to make needed changes, and other editors will resist changes even more than they might now. Right now, if you try to make a change to a core policy like NPOV, it's probably going to be an uphill battle. This proposal will make it even harder than it already is. Is that what you want? WhatamIdoing (talk) 16:02, 8 June 2022 (UTC)

@WhatamIdoing @User:Al83tito, I'd strong oppose a "inline reference" system for the reasons WhatamIdoing mentioned. On the other hand, I would strongly be in favor of a "Past discussions" section convention which easily provides historic context for how a policy arose, without making any pretense to its validity/relevance. This strikes a balance between allowing users to be bold, and easily making historic context available, should users want to go digging. This is a very nice idea and discussion, thank you for raising it. ~ 🦝 Shushugah (he/him • talk) 11:41, 19 June 2022 (UTC)

Wikipedia:Core content policies contains a history section, and it might be expanded a bit without hurting anyone.

I've contemplated writing a separate page for some of them. @Blueboar might appreciate the opportunity to write down the history of ONUS once and be done with it, and I've looked up diffs for the history of a single (not very good) sentence in NOCON at least three times now. A separate page would let you explain it and draw the relevant connections between different discussions. If you click the link to the paper trail I mentioned above, you'll see that the discussions that triggered that my proposal are not the discussion that the other editors assumed I was thinking of. This is pretty typical: we make changes because of multiple incidents involving multiple editors. It's not all about the Official™ RFC (assuming there was one, which there mostly isn't). History pages would also let you explain about the sentence that used to be there.

That said, I don't think that we should do this for most changes. It just might be handy to have an expected place for the unusually interesting story. WhatamIdoing (talk) 02:07, 23 June 2022 (UTC)

Better coverage of internet addiction related to Wikipedia

There was recently a thread about this somewhere but I can't find it. It's a bit of a shame WP:ADDICTED only really exists as a humorous page and there's very little helpful guidance or explanation of the topic. What do? What's the best way a serious essay could be written on the topic? — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 22:33, 18 June 2022 (UTC)

There's tons of research on internet addiction. A quick search for reviews shows a lot of free pdfs. Also remember anything NIH-funded will have a free link. Could we be so lucky as to have research specifically on Wikipedia addiction? Click here to find out!

I've not written policy, but I imagine you could mock something up pretty quick from all this, similar to as you would write an article. I also imagine that it's best to keep it short and sweet. Everyone's heard of internet addiction, so maybe just give the rundown, note the research, and link related WP essays. As for me, I can quit anytime I want. SamuelRiv (talk) 18:10, 20 June 2022 (UTC)

Also remember anything NIH-funded will have a free link - feels like as good a time as any to recommend the excellent Unpaywall browser extension, too. I didn't find the article massively revealing, especially since its case report concerns itself with anormal reading rather than editing habits, and the four Cs of Wikipedia were also new to me. 5P I've heard about, but this link's red...

However, I agree with the gist of your comment, it would be well to have some kind of overview to link to. One problem that shouldn't be underappreciated, though, is designing such a page in a way that wouldn't lead to people routinely interpreting its linking as a personal attack. I imagine that many editors one could justifiably suspect of having a genuine addiction to this site are at least mildly controversial and used to having passive-agressive aspersions cast their way. Dr. Duh 🩺 (talk) 09:40, 21 June 2022 (UTC)

I think that any serious page would be an improvement over the current linking to a humor essay, so while the problem might still exist I think it will be minimized compared to the current state. Nonetheless, a very valid point to raise Doctor Duh. — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 10:25, 21 June 2022 (UTC)

@Ixtal, were you looking for Wikipedia:Village pump (proposals)/Archive 189#We should find a way to increase awareness of internet addiction among Wikipedians ? WhatamIdoing (talk) 02:14, 23 June 2022 (UTC)

• We have an article on Internet addiction disorder. Remember that our purpose is to provide information, not to increase awareness. Blueboar (talk) 12:56, 23 June 2022 (UTC)

• Talking of Int. Addiction, here s a proposal of mine a couple of months ago.[7] Cinadon36 13:09, 23 June 2022 (UTC)

GA and QPQ

Should the WP:GA process contain something similar to the WP:QPQ nominations for Did you Know? This would certainly help reduce the backlog that is currently at WP:GAN while also possibly giving nominators the opportunity to branch out and gain experience in different subjects. Thoughts anyone? CollectiveSolidarity (talk) 02:52, 21 June 2022 (UTC)

CollectiveSolidarity, as someone who’s reviewed 30 GANs and submitted one article for GA, this is certainly an appealing idea. We should be careful that inadequate GAs don’t slip through the cracks though as a result. ~ 🦝 Shushugah (he/him • talk) 15:56, 21 June 2022 (UTC)

I'd say the backlog (which I admit sucks) is preferable to people unwillingly and incompetently doing quick reviews just to satisfy the QPQ requirement. There are not enough eyes on GA reviews currently; any initiative that makes people who are not good at reviewing do more reviews needs to have something that guarantees quality standards are upheld. —Kusma (talk) 16:07, 21 June 2022 (UTC)

We could place recent promotions on a list, where a user with a track record of page quality control can do a quick skim (refs, images, prose, etc.) and decline the promotion if there are any outstanding issues. Think of it as similar to WP:NPR. Acting as a member of this “promotion patrol” could also count as an automatic QPQ. Perhaps a bit grandiose, but it could increase the efficiency of the system by giving prolific creators the ability to spend less time QPQ reviewing and more time improving their own GAs. CollectiveSolidarity (talk) 17:07, 21 June 2022 (UTC)

• No. I love writing Good articles, but I have no interest in reviewing articles submitted by others. If I were required to review other articles in order to nominate another for Good status, I'd be less inclined to expand and nominate entries. ---Another Believer _(Talk) 17:12, 21 June 2022 (UTC)

Does anyone know why we show at WP:GAN how many reviews people have, but not how many GAs they have? (Can we shame people into doing more reviews??) —Kusma (talk) 17:26, 21 June 2022 (UTC)

Given the crap that routinely gets through at DYK, it doesn't seem to be doing anything beneficial over there and I fail to see how it would work better for GAs.--User:Khajidha (talk) (contributions) 17:33, 21 June 2022 (UTC)

I'd be pretty wary about that for a few reasons. First, GAs should be one of the primary goals of the encyclopedia. Unlike DYKs, GAs are long lasting, and provide in-depth, well sourced, and neutral information to the reader. Second, the quality of GA reviews will likely be reduced, because the two skills are not the same. I feel qualified to write articles well enough where they make it through GAN fairly smoothly, but I am certain I would miss a fair amount that should be taken care of if I were to review an article. Third, each editor only has a certain amount of time and effort they can devote to Wikipedia. If someone is, for instance, writing GAs and doing NPP, are we willing to say that to have any more articles promoted to GA they have to cut back on NPP? ScottishFinnishRadish (talk) 17:47, 21 June 2022 (UTC)

In the past, I think I suggested this myself, but I've come around to the position that QPQ for GA would be a mistake. I've seen enough substandard GA reviews with the current process. If we required QPQ, that would just drive quality in the wrong direction. Yes, the backlog sucks, but cleaning up the backlog at the expense of quality would be worse. -- RoySmith (talk) 18:52, 21 June 2022 (UTC)

PS, what I would really love to see is some better reviewing tools. There's lots of good code (ie software) review tools that let you click on a line of code, enter a comment, and get an easy-to-follow threaded conversation. The current GAR process of manually editing a review document, manually pinging people, manually copy-pasting text you want to refer to, etc, is an impediment. It's what the software world calls "friction". -- RoySmith (talk) 19:02, 21 June 2022 (UTC)

Maybe something that says "Please fix ... due to criteria _____", with an easy way to flag "By the way, these parts are all just my personal opinion, since Wikipedia:Good article criteria doesn't even mention them (e.g., reference formatting, categories, templates) or says I'm not supposed to decline articles on these grounds (e.g., dead links, 95% of the MOS, details that I'm curious about)." WhatamIdoing (talk) 02:50, 23 June 2022 (UTC)

Yeah, the above replies show that this idea is getting thrown in the Bit bucket. A better process for reviewing is badly needed, but I doubt that a solution will ever be worked out. Apologies for not coming up with a more developed concept. CollectiveSolidarity (talk) 20:14, 21 June 2022 (UTC)

PS, I am at least going to take the high road for this and try to review a nom for every one I make myself. It should be at least encouraged to pay it forward for all the reviewers out there who don’t get a Green blob for all their unsung work. CollectiveSolidarity (talk) 04:08, 22 June 2022 (UTC)

• I've reviewed 18 GAn and written about 60. I'm sympathetic to those who want to the clear the backlog and yes, partly for selfish reasons I don't want this rule, but there are more consequences to a shoddy GA review (e.g. bad contest masquerading as good content) than an ill-considered DYK. I've often thought to myself, "I should do more reviews" but look through the noms and not really feel qualified to review any up for consideration at that moment. An exception for the QPQ for the first few noms would also be necessary in this scenario, since undergoing only one GAn is, in my opinion, not sufficient to train someone to perform a GA review. -Indy beetle (talk) 16:32, 23 June 2022 (UTC)

Private RevDel requests

Right all, we've all known for a long time that it makes zero sense that there's a quick way of making an Oversight request (the email), but RevDels either need to be: requested where everyone can counterproductively see them; be made on IRC; or emailed to an individual admin.

Unlike OS, it's likely not the case that all RevDel requests should ultimately be made privately. But certainly a somewhat more professional structure would be a positive.

That said, there are multiple options with corresponding negatives and positives. There is also likely scope for discussion on what advice we should give for when/how to utilise it (must/should/can/don't). Please feel free to add options. Nosebagbear (talk) 18:19, 23 June 2022 (UTC)

Options

1. A VRT channel - have a queue that anyone en-wiki admin can request access to, and just add an email address that individuals can email requests to. Possibly with a set-up that enhances the odds of being given the information needed to carry out a revdel.
2. Something in the same vein as UTRS - a private structure designed to handle it, again with access provided on request.

Discussion

• Personally, I'd prefer the VRT channel. It has some negatives, but would be familiar to many, and more user-friendly when set against the status quo. Nosebagbear (talk) 18:19, 23 June 2022 (UTC)

  To be honest, I normally just email OS and mention that it probably needs a revdel, rather than OS, and let them handle it. May not be the best way, but it keeps from advertising the content that needs a revdel on-wiki. ScottishFinnishRadish (talk) 18:22, 23 June 2022 (UTC)

• Would certainly want to make sure any new queues aren't encouraged for RD's that don't require privacy (like old copyvio revisions that have been reverted). — xaosflux ^Talk 14:01, 24 June 2022 (UTC)

Addendum to 10YT

The WP:10YEARTEST seems to miss an issue that is present on some current-events-related articles I've been scanning – where recent events far overshadow the coverage that was deemed most notable when written in the article several years ago. I borrow the trope name "Arson, murder, and jaywalking" (draft essay) to describe it (for now). It's difficult to address with bold edits because the fix necessarily means removing, condensing, and replacing a great deal of well-sourced content, often in articles about politically-hot topics. Therefore I think an addendum to the RECENTISM#10YT essay section is warranted.

In searching past VP discussion there is one on RECENT news media being UNDUE that makes a few relevant points to the topic, but it's a long thread and mostly unrelated. See also a somewhat-related counterargument essay and the notability subpolicy it counters. If the substance of this addendum is worthwhile I know the writing style, length, and title will have to change significantly. I am posting here prior to taking it to the essay's talk page because this is my first essay attempt, so feedback on all issues, including fundamentals, is welcome. Thanks all. SamuelRiv (talk) 21:11, 21 June 2022 (UTC)

@SamuelRiv, I'd suggest that you think about giving editors a path forward. You say they should think about whether the past matters. Maybe also suggest "do your best, and give grace to editors whose best guess differs from yours"? Maybe "mark your calendar and come back in a year to adjust things"? Sometimes it's obvious (we knew at the time that the most important thing that would ever happen to the Chernobyl Nuclear Power Plant was the Chernobyl disaster), but sometimes it's just not. WhatamIdoing (talk) 02:55, 23 June 2022 (UTC)

I don't think I understand. This draft would ideally be added to the RECENTISM essay following the 10YT section or as a subsection, and what you're talking about all seems covered in 10YT. The diplomatic caveats are usually at the beginning of the long-form essay (in this case, RECENTISM). Did I completely miss your point? SamuelRiv (talk) 04:00, 23 June 2022 (UTC)

Oh, I thought you wanted to create a new/separate page. If you want to add this to the existing one, then I encourage you to Wikipedia:Be bold. The worst possible outcome is that you will discover someone who is equally interested in improving the page. (You'll know who it is when they revert your bold addition.  ;-) WhatamIdoing (talk) 16:36, 23 June 2022 (UTC)

The entire WP:10YEARTEST probably needs to be better written too. The "comprehensive rewrites" paragraph already states that citations to breaking news reports written at the time of the event "could be replaced by those to more scholarly, historical, or retrospective references created later on". And the "Just wait and see" paragraph mentions "Editors writing today do not have a historical perspective on today's events" - and that's probably true with those that will be writing tomorrow's historical and retrospective references. Zzyzx11 (talk) 15:48, 24 June 2022 (UTC)

Talk pages, headings of new sections, and manually changing the edit summary so it says something else

Suppose I attack someone on their talk page like the following fake message where I poke fun at myself to do this demonstration

"NEWSANDEVENTSGUY you are a stinky nincompoop"

In the classic editor, that would show up in version history and my contribs as

NEWSANDEVENTSGUY you are a stinky nincompoop (new section)

By using visual editor I can manually put the section behind some civil camouflage simply by changing the proposed edit summary from the offensive section heading to something innocuous such as

Barnstar of Awesomeness (new section)

Anyone just doing a quick scan of my contribs will see this and won't realize I was a jerk to someone.

We'll never plug all the ways people can be jerks and get around rules, but that doesn't mean we shouldn't try. Would it make sense to turn off the ability to tweak the edit summary for newsections on talk pages? Yes, I can think of other ways to post insults but make contribs look pretty, too. Fact that OTHERSTUFFEXISTS really doesn't have relevance to pros/cons of this possible proposal. NewsAndEventsGuy (talk) 14:08, 1 July 2022 (UTC)

@NewsAndEventsGuy So you want to enforce putting personal attacks in edit summaries where they will be visible to everyone unless you get an administrator to do a revdel (as opposed to just on the page itself where anyone can blank it)? --Ahecht (TALK
PAGE) 14:38, 1 July 2022 (UTC)

I suppose that's a downside, but the overall idea is to increase the visibility of problem behaviors so its easier to establish patterns and get blocks that will reduce future problems. NewsAndEventsGuy (talk) 14:51, 1 July 2022 (UTC)

In the classic editor the "edit summary" box isn't exposed, the "subject" line is what gets put in to the edit summary. So if you use new section in the classic editor you can just put "Greetings" in the summary, then put your derogatory message in the body and it already has this same situation. — xaosflux ^Talk 14:39, 1 July 2022 (UTC)

This would change nothing. You can always just add a new section manually by editing the entire talk page. The text within /* */ is what makes the hyperlinked edit summary. Anarchyte (talk) 14:40, 1 July 2022 (UTC)

WP:BEANS, y'all. WhatamIdoing (talk) 01:44, 5 July 2022 (UTC)

Let's not use the phrase "convicted felon" as often in the start of a Wikipedia article, while still acknowledging and being clear about what actions they have taken and what courts of law have said

I don't edit Wikipedia often, and this is my first time posting to the village pump. However, I have a criticism about how some articles start in describing someone as a convicted felon. While this might be a true fact, I think it is on one hand vague and on the other hand stigmatizing.

There are things that people are, and there can be stigma associated with it. I don't know that Wikipedia has much of a mechanism to respond to this. In the United States for example, being a convicted felon is something that can be hard for people and prevent access to all sorts of social support and job support. The phrase convicted felon is rarely put into a hyperlink so we can know more about what that even means. Is it appropriate to come out and brand someone with as a convicted felon, especially if they are famous for other things?

I don't think it is right or just. But I don't know how Wikipedia deals with questions of rightness and justice. It is really great to try to be neutral and not necessarily be into something that is justice related. I wouldn't want people to not have stigmatizing truths about them on their page because it can hurt. But one thing I think Wikipedia does do is care about is being specific and relevant.

I don't know that "convicted felon" as a phrase means much. Is it unduly creating a negative perception in the mind of the reader? I don't know. But take the example of the wikipedia article for say Annie Dookhan. It starts like this, "Annie Dookhan (born 1977) is an American convicted felon who formerly worked as a chemist at the Massachusetts Department of Public Health Drug Abuse lab[1] and admitted to falsifying evidence affecting up to 34,000 cases.[2]"

Is the notable thing about here that she was convicted of the felony, or is it the falsifying evidence affecting up to 34,000 cases?

Wouldn't it make more sense to say, Annie Dookhan is an American chemist who formerly worked as a chemist at the Massachusetts Department of Public Health Drug Abuse lab who admitted to falsifying evidence affecting up to 34,000 cases. Dookhan was sentenced to three to five years of imprisonment and two years of probation by Judge Carol S. Ball in Suffolk Superior Court, after pleading guilty to crimes relating to falsifying drug tests.

I think this is more helpful because it says that she is notable for this thing, and it was something she was sentenced to prison for. Convicted felon doesn't mean that much. there are lots of ways to be a convicted felon. Why not be specific and more precise instead of using a somewhat load but ultimately more vague phrase like convicted felon?

Can I just edit articles for clarity if I see that, or is that not a good idea? — Preceding unsigned comment added by Hockeydogpizzapup (talk • contribs) 07:30, 23 June 2022 (UTC)

• These things should be decided on a case by case basis. In the Dookhan case, yes I think it's more informative to lead with "chemist" than with felon. Some people become notable (or otherwise very much-defined) by the crimes they commit. I do believe its better to substitute the word "felon" with more exact descriptive, for example saying "convicted fraudster" or "convicted murderer" to be more specific. Wikipedia is not concerned with American stigmas broadly speaking (or real world impact, per WP:CENSORSHIP), but yes, I think "felon" is often an unhelpful label which offers little in the way of information. -Indy beetle (talk) 16:23, 23 June 2022 (UTC)

  It might be better to put the "claim to fame" up front: "Annie Dookhan falsified evidence affecting up to 34,000 cases while working as a chemist at the Massachusetts Department of Public Health Drug Abuse lab". WhatamIdoing (talk) 16:38, 23 June 2022 (UTC)

I would agree that unless the absolutely only notable thing the person has done is for being a convicted criminal , this phrase should be avoided in the early part if the lede, favoring neutral terms of their occupation. How and why they were convicted likely still belong later in the lede. Masem (t) 16:53, 23 June 2022 (UTC)

You might find some arguments from a previous discussion on moralization in article leads interesting, though your point is probably better made on its own merits. You're right – "convicted felon" is pretty useless on its own. (To address EC above) Even if only the consequences of conviction are important, every jurisdiction has very different lifetime penalties for felons that have been changing over the decades, so specificity probably would still be essential in the lead. I'll start looking out for the phrase too. SamuelRiv (talk) 17:02, 23 June 2022 (UTC)

"Felon" on its own is not the best, though there are some people whose notability is simply that they are career criminals. For some people (like Bernie Madoff), it's easy to lump all of the sorts of crimes together by characterizing him as a "fraudster", but it might be harder for people like James Galante where there are 93 crimes that span a wildly large range of activity. I don't know else to lump together racketeering, racketeering conspiracy, Hobbs Act extortion, mail and wire fraud, witness tampering, tax fraud, and conspiracy to commit arson charges; surely we wouldn't start our articles off with "James Galante (born January 5, 1953) is an American racketeer, racketeering conspirator, extortionist, fraudster, witness tamperer, kidnapping and arson conspirator, and associate of the Genovese crime family" in the first sentence where "James Galante (born January 5, 1953) is an American convicted felon and associate of the Genovese crime family" works fine.

I do see problems in which this phrasing can be abused to attack living people who committed a felony like fifty years ago or as a child (provided that it's a relatively minor point in their biography), but also I don't really think that this phrasing is a problem at all for biographies on subjects who are notable principally for having committed a large number of felonious crimes. — Ⓜ️hawk10 (talk) 17:41, 23 June 2022 (UTC)

Easy: "James Galante is an American gangster/criminal/mobster (pick one), an associate of the Genovese crime family, and a real jerk." SamuelRiv (talk) 18:45, 23 June 2022 (UTC)

Doing such is a bad idea on several levels. First, using such as the "noun" that the person is is a huge POV choice. Second, putting it in the first sentence of the lead is also a huge POV decision. Third it can be a POV "spin up". The common meaning of the term is pretty bad / serious, but in various places (even limiting it to the US) adultery, throwing something at a bus station and cutting off more than half of a sheep's ear are felonies. North8000 (talk) 17:48, 23 June 2022 (UTC)

I agree with Hockeydogpizzapup. And I would add that people are rarely notable for having been convicted, but of having committed an offense. It's not as if for example no one knew who Annie Dookhan was until she was convicted of a felony. Also, the term felony is not commonly used in many countries outside the U.S. TFD (talk) 18:14, 23 June 2022 (UTC)

I like the idea in general that when using subjective or hostile terms, they should be spun up to explain why they apply. This is nearly always the case for successful/positive-labeled people, and should be same throughout. Masem (t) 18:58, 23 June 2022 (UTC)

The problem with trying to regulate "subjective" terms is that whether a term is subjective seems to be subjective. (Specifically, any word that I disagree with is merely the subjective opinion of whichever WP:BIASED sources you were reading.)

The problem with "hostile" is that sometimes hostility is actually warranted. Murderer, rapist, torturers, enslavers/human traffickers: there are people who will subjectively feel that these are all hostile terms and will try to tell us that it's far better to call them something "neutral". This is a kind of neutral that's unknown to the NPOV policy, but maybe we'll rename Category:Murderers to use the non-hostile term "non-consensual population control technicians". Or, you know, maybe we'll just Wikipedia:Call a spade a spade and stick with the "hostile" name. WhatamIdoing (talk) 21:43, 24 June 2022 (UTC)

Using the term "felon" seems to be too US centric to me: the term is rarely used outside USA now. For the majority of readers it will be difficult to understand what it means (except that this is something ugly). It should be replaced with "criminal" or dropped altogether from the lead. Ruslik_Zero 20:38, 23 June 2022 (UTC)

On this one count, 'convict' may be better, as this does not discriminate between US or any other terminology, e.g. 'murder convict' is clear to all I think. As to the prominence of such attributions, it must logically depend on the relevance to the biography. If the person is known primarily for their conviction, it should appear prominently, but if conviction is a minor part of their identity, not so much. Iskandar323 (talk) 06:55, 25 June 2022 (UTC)

Though I do see a problem with felony being a specific category of the crime, so perhaps it is appropriate in that the crime is specific to the US is outlined in US terminology. Iskandar323 (talk) 06:57, 25 June 2022 (UTC)

I think the phrase is problematic in its application. We could, accurately, say "Tim Allen is a convicted felon and actor..." Of course, we don't. What rule can be articulated to say where the cut-off is for convicted felon status to make it into the lede? BD2412 T 07:09, 25 June 2022 (UTC)

We do say Ted Bundy "was an American serial killer." That's because that is what he was notable for. And note we don't call him a convicted felon. TFD (talk) 13:40, 25 June 2022 (UTC)

Vital biographies

Hello, on the contents page, there doesn't seem to be a way to view the most important biographies for Wikipedia except vital articles or list of articles every Wikipedia should have. We do a good job at covering the other major areas of Wikipedia and was hoping to develop some ideas besides the vital articles projects to figure out how we can implement the biographies in our contents page. Interstellarity (talk) 00:24, 23 June 2022 (UTC)

How do you decide which ones are the most important? WhatamIdoing (talk) 02:57, 23 June 2022 (UTC)

@WhatamIdoing: If you go into the talk page of the vital articles project, WT:VA and WT:VA4, there has been a lot of discussion regarding which biographies are most important. The list is here. That might give us an idea on where to start with including biographies in the contents page. Interstellarity (talk) 16:33, 23 June 2022 (UTC)

Don't those conversations usually result in editors concluding that it's very difficult to identify "important" articles, and that the best we can really expect is "important to me"? For example, the list you linked has 27 politicians. It includes three monarchs from England, but it doesn't have Winston Churchill. From France, it has Napoleon and Joan of Arc, but it doesn't have Louis XIV. From the US, it has Washington and Lincoln, but it doesn't have anyone from the 20th century. There is only one person listed with Central or South America heritage; what about José Francisco de San Martín? Bernardo O'Higgins? Cesar Chavez?

It would not be especially difficult to build a list of 27 leaders that matter to people from my country. It is very difficult, and perhaps impossible, to build a list of 27 leaders that are equally important to everyone in the world. A list that sounds fair and balanced to someone from the US or the UK will not seem at all fair and balanced to someone from Africa or Asia. WhatamIdoing (talk) 21:27, 24 June 2022 (UTC)

@WhatamIdoing: Would you recommend against adding biographies to the contents page based on your statement above? Perhaps we could have 500 or 1000 people articles. Interstellarity (talk) 12:59, 26 June 2022 (UTC)

I don't think it makes sense to have a "List of People who are More Important Than Other People". It would make sense to have a "List of Articles That Probably Need Improving Now" (e.g., a copy of Wikipedia:WikiProject Biography/Popular pages), but I'm not sure what the point is of deciding which people are permanently more important than others. WhatamIdoing (talk) 21:19, 26 June 2022 (UTC)

Is your thought then to take, say, VA3 People and give them all a little blurb and some categorization (like the Contents-Tech page) and have that be another Contents page? Blurbs shouldn't be too terrible to write or even script-generate from the short summary or the lead sentence or two. One potential issue of course is representation politics, but obviously the other Contents pages (and VA itself) have dealt with it. Off the top of my head you could have 100 names drawn a from a pool of VA4 People under regular rotation, which might mitigate some foreseeable complaints. SamuelRiv (talk) 17:39, 26 June 2022 (UTC)

New Wiki Product

Originally posted on Commons:Village pump/Proposals

Hello,

I write today as I have an idea for a new Wiki service. Called "Wiki Archives" its main purpose would be preserving artifacts like Documents and Photos that others might not seen in saving. Wikimedia Commons is a great service, but I believe that some of what's in it should be split into this new product. When you search for something, you can find pictures in like old building plans and old photos which should be in an archive where they could be appreciated more. It would work like commons as people could upload things, but it would be stricter in what it lets in (e.g. New phots taken by users and other things). If you have any questions, feel free to contact me. Thanks! DiscoA340 (talk) 19:04, 25 June 2022 (UTC)

@DiscoA340: This is outside the remit of English Wikipedia. Have you heard of meta:? That is the place to suggest that kind of thing. --Redrose64 🌹 (talk) 22:22, 25 June 2022 (UTC)

Is our collection of old images and documents that are already uploaded to Commons not being appreciated? There are a number of issues that splitting the exiting repository would create, so I would suggest a lot of thought to the questions and comments posted on Commons already before taking this to Meta. Imzadi 1979 → 18:59, 26 June 2022 (UTC)

Unless someone thinks otherwise, I do believe that these old images and documents are not being used to their fullest extent. Wikimedia Commons is mostly meant to provide free and useable images the public, not act a dedicated archive. Doing a search on WM for images about "Bladen County", you will find in useful images like maps and pictures of landmarks, but then you will find images like this which would be hard to use and is ironically in the National Archives. WikiArchives would provide that research tool to people who want to find images lake that. DiscoA340 (talk) 20:29, 26 June 2022 (UTC)

So why not put the image in c:Category:Bladen County, North Carolina or even c:Category:Elizabethtown, North Carolina? --Redrose64 🌹 (talk) 22:15, 26 June 2022 (UTC)

I don't see where anyone else has mentioned it yet, but Wikisource sounds like what you are looking for. ~ ONUnicorn^{(Talk|Contribs)}problem solving 20:33, 26 June 2022 (UTC)

• This sounds like an unnecessary fork of Commons. It's explicit that Commons is not just for hosting images that are used on Wikipedia, though they are supposed to be of some potential use to the public. What problems you're encountering can be resolved by better categorization, not the creation of a new website. -Indy beetle (talk) 13:32, 27 June 2022 (UTC)

Catalogue numbers in {{cite}} templates

Hi all, am I the only person who finds the layout of catalogue numbers (eg isbn, jstor, oclc, doi) a bit intrusive? I came across James Leasor#Bibliography, which is a good example of how they can dominate the screen. I find that small caps ISBN 9780552105866 are much less wearing on the eye than ISBN 9780552105866, and are the same size as a standard url link. I'm sure no-one would advocate url links this size. Would there be a case for incorporating this into the {{cite}} templates? I imagine it would be trivial to implement, but what do others think? I should mention that my prefs/gadgets include "Disable smaller font sizes of elements such as infoboxes, navboxes and reference lists", but there is still an inconsistency in the relative 'importance' of the information. Cheers, MinorProphet (talk) 06:03, 27 June 2022 (UTC)

I believe you want to direct this suggestion to the Help_talk:Citation_Style_1 page (this is the combined Talk page for the Citation Template). It's a good suggestion fwiw. SamuelRiv (talk) 06:49, 28 June 2022 (UTC)

Done, thanks for the tip. MinorProphet (talk) 10:06, 29 June 2022 (UTC)

Outstanding 'to-do' notifications (userscript solution)

As a follow-up to Wikipedia:Village pump (idea lab)/Archive 41#Outstanding 'to-do' notifications. (participants in previous thread: User:Kieronoldham, User:Xaosflux, User:Certes, User:DannyS712)
As I said in that thread a month ago, I have a monopoly on non-WMF echo notifications. (echo emulation) I created a reminder scheduler using that some days ago. To activate it: first install Bawl. (needed because the echo emulation is part of Bawl, you can disable Bawl's main features if you don't like them)
In the settings for Bawl, enable "Notification scheduler (Memoria)" at the bottom of the "Advanced" tab. After the next page load you'll have a "Memoria" PortletLink. The reminder stores its entries as a global user preference.
Recurring reminders are possible. Only recurring every n days is available. (so not every month/year, though you could approximate that with 30 or 365 days)
You can also subscribe to reminders. This could function as a kind of mini-newsletter, possibly useful for WikiProjects. Documentation has not yet been written but here's an example JSON. — Alexis Jazz (talk or ping me) 15:07, 30 June 2022 (UTC)

Idea: Bot that tags "problem" user talk pages with {{whois}}, {{Shared IP}}, etc.

Summary: Bot adds whatever {{whois}} related notice it think's is most appropriate to the user talk page of users who are editing in bad faith. I've already written a good chunk of the code, most of this is based on how that code works now or how I expect it to work when done, but it can be changed.

Goal: It's my understanding that one of the purposes of templates like {{Shared IP}} is to deter vandalism by communicating something like "You are not as anonymous as you might think you are, here is proof that we know who to contact if you do something really bad." especially the {{whois}} template. I'm not aware of any automation to the process of using these template other than Twinkle having a form that needs to be filled manually similar to what it does for warnings and welcome messages. Manually finding and filling the information is tedious and, to my knowledge, rarely done. Automating the process within certain limits may deter vandals, especially those editing from a place like a school where the IP may be registered to the school.

Suggestions on all variables, timeframes, edit numbers, etc. below are appreciated

Determination of users who are editing in bad faith: There are many things that can be checked to make this determination. The bot currently "decides" a user is editing in bad faith based on if all these criteria are met:

• The user received a standardised user warning template on their user talk page which follows the format uw-warningname# and where # is 3, 4, or 4im. This indicates that someone warned the user in a way that assumes bad faith per Wikipedia:WikiProject User warnings/Design guidelines#Severity levels.
  • The warning user is checked to ensure they have made at least min_warner_contribs in the last warner_contribs_timeframe. This check helps prevent the bot from affecting users who are being vandalized using warning templates and users who may have been warned wrongly by less experienced users. This has not been implemented in my code yet, I am leaning towards 100 edits in the last 30 days.
  • The user is not warning themselves.
• The user has made a contribution in the last 7 days. A check like this helps ensure that warnings are valid, suggestions on the timeframe are especially appreciated.
• The user has made less than max_user_contribs in the last user_max_contribs_timeframe. Users with substantial contributions are probably much less likely to be receiving a valid bad faith warning and are probably very unlikely to be vandalism only accounts. This has not been implemented in my code yet, I am again leaning towards 100 edits in the last 30 days. Total edits cannot be used universally because of shared IPs but IPs and accounts can be handled differently.
• The bot has not edited the page in the last 36 hrs. This prevents edit warring while being short enough that if a shared IP removes a template it can be put back.
• A template from Category:Shared IP header templates does not exist on the current version of the page. The bot trusts anyone before it, including itself, to have done a better or equally good job.
• The user talk page can be edited per exclusion-compliance. Anyone who knows enough to do this probably knows enough to know what the bot is trying to communicate anyway.

Actions on IPs editing in bad faith:

• Perform a lookup to attempt to determine who the IP is registered to.
• Attempt to classify the registered owner to determine the best Category:Shared IP header templates. This code hasn't been written yet, I don't know how successful it will be but it will likely be based of regex rules in the bot's userspace which will be editable by administrators. Most rules will likely be made to match a specific ISP which has been manually classified.
• Add the determined template to the top of the user talk page. If classification fails, use a generic template like {{whois}} or possibly one made specifically for use by the bot. This code hasn't been written yet.
• Based on feedback here and consensus if proposed, perform actions on potentially related IPs

Actions on potentially related IPs: Nothing in this section has been coded yet.

• Do some checks based on the registration information and classification, maybe skip anything to do with potentially related IPs if there's some reason to think that nearby IPs might not be accessible to current IP's user.
• Scan an expanding range of the original IP, adding each meeting certain criteria to a list, until the range size reaches the registered range, the range is unreasonably big, or the list contains a certain number of IPs.

Example: 192.168.4.65 is the IP, 192.168.0.0/16 is the registered range in CIDR notation. Start at 192.168.4.65/31, or a sensible range based on the maximum list size, scan the range for user that meet the criteria for inclusion in the list, then scan the IPs added to the range when you increase the range to 192.168.4.65/30 or whatever until you hit the maximum list size, get to your range limit, or get to 192.168.4.65/16.

Possible limits:

• Max assigned range to do any scan: /20
• Max IPs to scan: 256 (note that these do not have to be each scanned individually, you don't need to make 256 requests to check 256 IPs)
• Max IP on list: 25
• IPv6, you can scan a whole range in one request but unless there's some way to unify 2⁷²+ talk pages and post just one message that they'll all see it's pointless.

Possible criteria:

• Has made w contribution(s) in the last year
• Has made less than x contribution(s) in the last 30 days
• Has a user talk page with at least one warning of any severity on it (limiting to bad faith warnings would likely be redundant)
• y of z most recent contributions have been reverted

• Once the list is done, tag the user talk page of every IP on the list with either the same template used for the original IP or with a new customized template specifically for this.

Actions on registered accounts editing in bad faith: Nothing in this section has been coded yet. Currently there is a check that excludes talk pages of all registered accounts. Having similar capabilities to what is done with IPs would require a checkuser bot and hopefully that's enough information to explain why I think it'd be a bad idea. An alternative would be to create a generic template basically saying that it is possible to connect you back to your real identity, allowing for real world consequences if you do something bad enough, but that probably won't have the same effect as seeing the name of your school, workplace, ISP, or whatever. I think it'd be worth trying that if someone was willing to analyze edits from before and during a test period to see what impact it has. PHANTOMTECH (talk) 11:16, 24 June 2022 (UTC)

Discussion (bot)

• I haven't thought much about the rest of proposal, but I think that a bot that watches a page to handle manual requests would also be a good idea. I'm thinking of the bot going through an IP range's contributions in a time frame and tag individual IPs with the suggested template. 0xDeadbeef 13:17, 24 June 2022 (UTC)

  @0xDeadbeef Just to clarify are you talking about a page where users would give the bot an IP range and template + data the the bot would go through the range tagging all IPs that have made contributions within a certain timeframe using the user provided template + data? PHANTOMTECH (talk) 14:15, 24 June 2022 (UTC)

  Yes, and the bot could also have a feature to actively monitor new contributions from that range to insert templates and/or notify editors if needed. Let me know if this is not something we would want. :) 0xDeadbeef 14:32, 24 June 2022 (UTC)

  I like that idea, thanks :) I think temporarily monitoring the range (for a day to a few weeks depending on circumstances) could be beneficial. Permanent monitoring would require more resources over time and might end up giving notices to unrelated users that could confuse them without much justification since, with permanent monitoring, it could be months or years since the range had problems. PHANTOMTECH (talk) 14:46, 24 June 2022 (UTC)

  I'm interested in working on that idea if you haven't started. 0xDeadbeef 15:06, 24 June 2022 (UTC)

  I haven't started work on anything specific to the manually being able to request the bot tags and monitors a range thing. PHANTOMTECH (talk) 15:45, 24 June 2022 (UTC)

• Any such bot would quickly become defunct when meta:IP Editing: Privacy Enhancement and Abuse Mitigation rolls out. — Preceding unsigned comment added by Ahecht (talk • contribs) 14:43, 1 July 2022 (UTC)

Idea: 3RR Bot

A bot that detects potential 3RR problems could work, although the bot might need an advanced algorithm for ruling out self reverts. 0xDeadbeef 05:06, 5 July 2022 (UTC)

@0xDeadbeef We have User:ProcBot/EW which does what you describe, though it is currently inactive pending a move to toolforge. 192.76.8.85 (talk) 11:46, 5 July 2022 (UTC)

Let's not go on fishing expeditions for 3RR disputes. If things resolve without escalation, even if some policy was violated somewhere, that's a perfect case of WP:IAR. Headbomb {t · c · p · b} 05:32, 7 July 2022 (UTC)

Idea: using JavaScript to display protection icons

A few years ago I wrote a script that automatically would insert protection icons to protected pages. This would completely eliminate the need for the addition and removal of protection templates from an overwhelming majority of pages.

Something similar is already used on Wikidata because for technical reasons you cannot have protection icons on data items. Here, you can have protection icons on Wikipedia pages through the addition of templates (which is okay), but it takes time to add these icons to articles that are protected.

I want to suggest using JavaScript to insert the protection icons into the corner. This would allow for these icons to be added to pages without the need to insert protection templates like {{pp}} or {{protected page}}. It would also allow for the icons to display in the "edit" and "history" modes. Finally, it would allow for the icons to be displayed differently if a user has permissions to edit. In my implementation I have it that if a user has rights to edit or move the page, the protection icons display in the unlocked state. I think this would be helpful so that new users can understand intuitively which pages they are almost certainly able to edit and which ones they cannot edit. Aasim - Herrscher of Wikis 04:38, 7 July 2022 (UTC)

Awesome Aasim, I think having javascript to display these icons is great, but only when used in addition to protection templates. There are noscript users and bots out there and we can't ignore them. 0xDeadbeef 05:22, 7 July 2022 (UTC)

Well yeah. I see the templates still a bit needed for categorization of the different protected pages. The goal of this though is so new users can know which actions they can make on a page and which ones are restricted. And about noscript, unfortunately almost all of the web relies on JS to work correctly. Bots can also ascertain that a page is protected through the API, not by screen scraping. All of the protected titles can be viewed in Special:ProtectedPages and Special:ProtectedTitles anyway~ Aasim - Herrscher of Wikis 15:39, 7 July 2022 (UTC)

Having dynamic page content just to read can be a problem for all sorts of caching, additionally there are pages where for whatever reason we don't want to display an icon on the page. — xaosflux ^Talk 15:47, 7 July 2022 (UTC)

I think resolving ancient (and since-renamed) phab:T12347 would be a more valuable expenditure of time. Izno (talk) 18:41, 10 July 2022 (UTC)

Year-denominated Currency Format

Hi there! First post in the Ideas board (or any board) so please let me know if I could improve anything. Feedback is much appreciated.

Problem:

Often I will be reading some historical entry and a currency amount will be mentioned (e.g. "Adam died in 1824 and left behind $230,000 to his niece.")

1. I do not always have an intuitive understanding for how historical amounts translate into today's currency. When reading these older entries, the currency amounts seem a bit meaningless (if the reader does not know the inflation-adjusted conversion) or unintentionally misleading/confusing (if the reader does not know to convert the amount at all).

2. Sometimes the currency amount is not clearly tied to a particular year in the text, and it is left ambiguous, so the reader can't convert it confidently at all.

How this is often partially solved already:

Sometimes authors will include a conversion themselves in the text. Here's an example:

> "On January 15, 1948, Redfield won US$2,300 (equivalent to $25,940 in 2021)."

This is much appreciated, but not an ideal solution. It requires authors to fill up the text with these conversions, and even then the conversions themselves are still tied to a particular year and will themselves require updating in the future. In 30 years the reader may not have an intuition for 2021 dollar values any more than they do 1948 dollar values.

Idea for improvement:

Could we add the year to the currency format and require/strongly encourage it? That would separate the concerns.

All the author would need to do is include the year the currency amount was originally tied to. Then automation could handle displaying that meaningfully to the user with clear reference to the original year as well as some smart UX for letting them view the equivalent amount in today's currency.

I suppose this could be done either on the markup side or the actual content side, so long as the formatting was standard and machine-parseable. However, I don't know of any existing standard for year-denominated currency so it seems a bit brittle to just make up a wikipedia-specific one. I believe this ought to end up in some ISO standard so any mention of a currency amount always includes the basis year, it just prevents confusion and manipulation (e.g. discussion of minimum wage gets warped when people do not understand that $7 in 1950 is much less than $7 in 2020). If it already is a standard then please let me know!

Thanks for reading this and considering, I'm looking forward to hearing what people think!

SmoothAmber (talk) 16:10, 15 July 2022 (UTC)

I'd think this should be in the prose. Inflation/deflation certainly do happen (in your example above I'm not even sure what you mean by 1950$USD$7 is "much less than" 2020$USD$7 - I'd think it is "much more" as it could be converted to more goods and services). — xaosflux ^Talk 18:12, 15 July 2022 (UTC)

I'm pretty sure in the past I've used the {{Inflation}} template for these purposes. It shows also how to do a currency conversion at the end if necessary (I'm not sure if there's a standalone wrapper template for that). The documentation also shows the date bounds for the datasets, though I would still be very cautious about portraying any value prior to the 20th century in modern currency as better than very approximate (I would suppress the cents output of precision for one thing), and anything before the 19th is just... well it depends on the region, social change, and quality of data. For pre-20th century I agree that simply "getting an idea" of what one thing was comparatively worth at one time is enlightening information, properly qualified, but just getting that base number to work from I think no matter what requires an RS. Past the 1920s or so, and certainly post-WW2, the conversion gets a lot better and the data table in the calculator should be relatively uncontroversial except when dealing with economies that are in utter crisis when you do your conversion. SamuelRiv (talk) 20:51, 15 July 2022 (UTC)

Yes, I think {{inflation}} does more or less the job that is being asked for here (including rolling over to current year if desired). However, I also very much agree with the comment that any automatic method can give a quite misleading result when used outside the context of "modern figures for reasonably small amounts", and we should definitely be cautious about applying it wholesale.

York Castle has a good example of how to handle figures like this - it contextualises by saying eg that repairs cost "£200, about the annual income of a baron". If you were to use the RPI-based template, or a similar automated method, you would get a figure of about £150k - a bit less than the price of an average flat in the city today, which gives quite a difference sense to "the entire income from a large estate".

Similarly, Economic history of the United States Civil War takes a nuanced approach by giving a modern equivalent for one value (income tax levels) where the conversion is reasonably meaningful, but omitting them for the larger ones (the total cost of the war, national debt, etc) where RPI-based conversions would be inappropriate. Andrew Gray (talk) 13:08, 18 July 2022 (UTC)