Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41


Redesigning the About pageEdit

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 • {CX}) 06:48, 15 May 2022 (UTC)

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

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 (talkcontribs)
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 breakEdit

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 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 wordingEdit

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)

(undo | discuss | thank) next to all editsEdit

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:T51541xaosflux 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)

A solution to the template graveyard of retired usersEdit

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 (talkcontribs) (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)

3RR warningEdit

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)

Draft RFC: Bot to blank old IP talkpagesEdit

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
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.

Undisclosed Paid EditingEdit

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 [email protected] 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. [email protected], 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 [4] 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 ExampleEdit

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)

Namespace aliasesEdit

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.

Improving redirects to sections of a pageEdit

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.[1] 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.[2]".
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 • {CX}) 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 • {CX}) 10:47, 13 May 2022 (UTC)

References

Wider pages on new vector skinEdit

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 • {CX}) 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 [5], 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 • {CX}) 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)

Confirmed versus autoconfirmedEdit

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? HouseBlastertalk 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. HouseBlastertalk 22:14, 15 May 2022 (UTC)

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

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)

Community thoughts on "Recent deaths" section of Main PageEdit

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)

Wiki E-BooksEdit

 
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.

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 • {CX}) 10:52, 18 May 2022 (UTC)

MoS/Mathematics: Adding guideline on colon before equationsEdit

Many guidelines on mathematical writing say that equations should be treated as any other part of the sentence they belong to[1]. 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:

 

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.