Wikipedia:Village pump (idea lab)

IBM 7094 registers
	Data registers
Accumulator	AC
	Index registers
	Instruction counter

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, note:

Discussions of technical issues belong at Village pump (technical).
Discussions of policy belong at Village pump (policy).
If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

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, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60

Merging mass-created village stubs into district articles

Initial ideas, village stubs

There are a lot of mostly formulaic (though that's not necessarily bad) stubs of villages with 60-100 people that will probably never be significantly expanded, at least beyond one or two events happening there. I know that under the the guideline on geographical features all inhabited places are considered to be notable, but what if very small villages were by default merged into district articles? I'm thinking of a section "Villages" or something similar with a subheading for each village and a few sentences with the population/location (what's already in the leads). Villages that had enough coverage to need their own article would be split; it could be done based on the categories "Rural localities in X district" that already exist.

For example, Basovo and Timonovo in Valuysky District, Russia. The second has 1 event happening there, and the 1st none listed; both are very small towns with a couple hundred people. It's possible Timonovo could be expanded with a description of the event, but that would be rather WP:1E-style and deserve its own article.

I'm posting this here because I don't know the history & policy details sufficiently to put it into proposals (or the 300-vote discussions), but I wanted to see what people thought and if this had been proposed before. Mrfoogles (talk) 04:00, 15 August 2024 (UTC)[reply]

It depends on what the guidelines are agreed to. I'd say if a location only cites census tables and maps (gonna use Hashemabad, Kerman as an example), they should be merged with the above-class subdivision. All these location articles only have maps and census tables, could possibly violate geographic feature Notability. Roasted (talk) 04:22, 15 August 2024 (UTC)[reply]

I would support this. BilledMammal (talk) 04:40, 15 August 2024 (UTC)[reply]

I would cautiously support this as long as it was done carefully so no information was lost, was explicitly without prejudice to later expansion and excluded places with significantly more extensive articles on another language wiki. Of the three places here, only Timonovo has more information elsewhere (ru:Тимоново (Белгородская область)) but that is borderline. My ballpark suggestion would be that any article with circa two paragraphs of prose of non-census information excluding a description of it's geographical location on any language edition of Wikipedia should not be merged in without an individual discussion. I'd also say that before any merge takes place there needs to be a list of all the merges proposed laid out in a fashion easy for humans to check (separate lists or separate sections for each destination article would probably work well). Thryduulf (talk) 10:25, 15 August 2024 (UTC)[reply]

Section break 1, village stubs

I support the concept… Wikipedia should continue to cover all noteworthy geo locations, but we can be more flexible in how we cover them. Not all locations require a stand alone article to be included. Blueboar (talk) 11:49, 15 August 2024 (UTC)[reply]

The ru.wiki versions of the villages are not much longer unfortunately, and the length of the longer one comes from quite generic information that would likely apply to the district. Your method of merging to the district article sounds like one in which no information would be lost, although I would leave room for a bit more than what is currently in the leads. CMD (talk) 12:00, 15 August 2024 (UTC)[reply]

I doubt anyone will stop you but I think it's a waste of time. For some reason some editors have strong feelings about the existence of stubs vs. redirects to entries in lists but, from the reader's perspective, they're pretty much the same. I can't tell anyone how to use their time but if all the collective hours we've wasted on merging or talking about merging stubs were instead put into expanding them, the encyclopaedia would certainly be better off. – Joe (talk) 07:13, 16 August 2024 (UTC)[reply]

As a reader, they are not the same. Hunting through various pages to try to glean info takes up time. The reader of ru:Валуйский район will not see the climate information in ru:Басово (Белгородская область). A mobile reader does not even have a way to get from Valuysky District to the information in Timonovo. CMD (talk) 15:26, 16 August 2024 (UTC)[reply]

I don't think we should be making content decisions based on known bugs in the mobile theme. – Joe (talk) 05:47, 17 August 2024 (UTC)[reply]

There's the rest of what I wrote, and if your counter-proposal is to treat the nav boxes as great article content then I don't think that's very helpful to the reader either. CMD (talk) 12:31, 17 August 2024 (UTC)[reply]

I might come to the same conclusion ("As a reader, they are not the same") but in the opposite direction: Hunting through a merged-up page to try to glean which info is relevant and which is about other villages takes up time. With a stub like Timonovo (five sentences, 75 words, five sources, plus the infobox), you know that all the information is what you're looking for, and you know that's all there is. WhatamIdoing (talk) 22:19, 18 August 2024 (UTC)[reply]

List articles don't have to be tabular data with no prose, nor do they have to be internally consistent as to whether or not the list items they contain are bluelinks or not. The GA Infrastructure of the Brill Tramway is basically a list article that contextualises borderline notable information beautifully.

I should disclose that I'm strongly in favour of contextualising stubs into their container topics wherever possible. Folly Mox (talk) 16:18, 16 August 2024 (UTC)[reply]

Somehow I doubt the result it this will be a load of GA-level lists. It'll be the existing stubs, pasted in one after the other. – Joe (talk) 05:49, 17 August 2024 (UTC)[reply]

I agree that the implementation of contextualisation is likely to resemble pure concatenation, and would prefer that outcome to the status quo. JMO. Folly Mox (talk) 15:59, 17 August 2024 (UTC)[reply]

I was more thinking of a policy allowing people to merge such things if they felt like it: because there are so many village articles it's never worth it for any one person to start a discussion about merging the villages of one district, because who cares about this one random district in particular. And no one has the hours and hours you refer to to just go do it for all of them. With a pre-consensus it could ideally happen piece by piece? If there was a policy on this I might merge the villages of that district just because I ran across them, but I wasn't planning to spend 900 hrs on trying to do all of them.

As for expanding them: 60 people live in most of these village, and it's unlikely someone's written a book about most of them. Not going to say it's not a little bit of a waste of time, but having a list of villages in a district in its article seems useful: it was helpful to me finding some village list in district articles on the German Wikipedia I think when I was trying to figure something out. I think name+whatever small details exist could be somewhat helpful, if not the most important task. Mrfoogles (talk) 18:54, 16 August 2024 (UTC)[reply]

We already have such a policy. – Joe (talk) 05:51, 17 August 2024 (UTC)[reply]

Be bold, but also be WP:CAREFUL. When you know the community's practice is to split the subject into small stubs, then boldly merging the articles up without discussion might result in WP:DRAMA. WhatamIdoing (talk) 22:21, 18 August 2024 (UTC)[reply]

section break 2, village stubs

@BilledMammal put together a sample of 10,000 articles so we could try to find out some basic information about what the community's actual practices are – the revealed preference, if you would like to use that language, rather than the aspirational goals. So far, we're finding facts like these:

90% of articles have between 2 and 95 sentences, heavily skewed towards shorter articles. The most common number of sentences in an article is two. Half of articles have 13 or fewer sentences. A quarter of them have 5 or fewer.
If you define a stub as having ≤10 sentences, then 43% of Wikipedia's articles are stubs. If you define is as ≤250 words, then 41% of articles are stubs.
Half of all articles have 4 or fewer (detectable) inline citations. A quarter have 2 or fewer. Only 21% have more than 10. Having more than 20 (about 10% of them) is a statistical outlier.
Compared to longer articles, stubs tend to have about twice as many citations per sentence.

The reason I bring this up is because when we compare articles against our ideals, it's very easy to think "What garbage. It 'only' has five sentences. It 'only' has five sources. It 'only' has 75 words." We ought to be thinking "Huh, that has more sentences than 25% of our articles. It has more refs than 60% of our articles. It has more words than 16% of our articles. Maybe it's not too different from normal, actually." WhatamIdoing (talk) 22:40, 18 August 2024 (UTC)[reply]

I recently ran a new scan, of 100,000 pages, where the talk page categories are also provided. I’m not sure how to upload it yet - it’s a far larger dataset than all the others I’ve uploaded put together - but it should be helpful as it will allow us to determine which topic areas have abnormal articles.

We’ve already identified species as one of those areas; I think we’ll find that places is another. BilledMammal (talk) 23:37, 18 August 2024 (UTC)[reply]

Maybe consider uploading that as c:Commons:File types#Tabular data? ORES can automate identification of the main subject area.

I suspect that the size of places will vary by location. Most US census places have longer than median articles (e.g., Mulberry, Kansas has 25 refs and almost 1,000 words) but were largely written by bot/script.

Getting the numbers for FAs and GAs would also be interesting to me. WhatamIdoing (talk) 23:49, 18 August 2024 (UTC)[reply]

I totally support the idea to reduce village stubs. here is one possible way to do so; make articles consistently named "villages in ___ County", or "Villages in ___ Oblast," or "Villages in ____ Arrodinsement," and so on, and make these into list articles.

doing so is more efficient, and actually will enable more people to view this information, not less. Sm8900 (talk) 14:07, 19 August 2024 (UTC)[reply]

I think that the fact that these articles are close to the status quo doesn't necessarily mean they wouldn't be improved by merging them, though. The point is that they have very low potential (only have 50-200 people or so), which is not true of all stubs. Mrfoogles (talk) 17:20, 20 August 2024 (UTC)[reply]

Some time back (we're talking at least 15 years), I wanted to have an article on every inhabited place in Ethiopia. This aspiration was foiled by the fact that information on even sizable towns in that country can be hard to get ahold of -- at least at that time. In many cases all the information I had about the village was the population statistics. Moreover, at the time I was not interested in adding to the large number of stubs on Wikipedia; this is why you'll find a lot of red links in those articles.

I considered addressing this problem exactly as proposed above: create a section in the article that provided the stats on those towns/villages. However by that point I was tired of working on Ethiopian topics & decided to move on. -- llywrch (talk) 18:18, 27 August 2024 (UTC)[reply]

Rename and/or Combine Content Assessment classes

Currently Content Assessment is named arbitrarily at Featured, A, Good, B, C, Start, Stub. Looking for ideas as to what A, B, and C classes should be renamed? And if B and C classes were combined into one, what would that be named?

Following on from some ideas slightly touched on here. DimensionalFusion (talk) 21:41, 18 August 2024 (UTC)[reply]

I would merge B, C and Start together and call them all "start". Anything checking criteria of article like DYK would not solely rely on WikiProject content assessment anyways. ~ 🦝 Shushugah (he/him • talk) 21:51, 18 August 2024 (UTC)[reply]

Interesting! DimensionalFusion (talk) 22:13, 18 August 2024 (UTC)[reply]

I’d definitely be opposed to lumping B and Start into the same bucket, the resulting rating would cover a really wide range in quality. There is a difference between “often not used and superfluous in many cases” and “totally unnecessary”. ― novov (t c) 01:57, 19 August 2024 (UTC)[reply]

The names aren't really arbitrary. They're basically American letter grades, plus two existing review processes (FA and GA), the separate {{stub}} system, and a squeamishness about rating anything with a "bad grade". C is a relatively recent innovation; back in the day, it was realistically Stub–Start–B, and anything else required extra effort. In 2008, editors basically decided to divide the Start class into two groups (C and Start).

As a first approximation, we started with:

Stub: Less than ~10 sentences.
Start: More than 10 sentences but not yet B-class.
B class: Meets all six specified criteria.

and we decided to have:

Stub: Less than ~10 sentences.
Start: More than 10 sentences but still kind of short and not B-class.
C-class: Kind of long but not quite B-class.
B class: Meets all six specified criteria.

Your question is basically "Shall we reverse the decision that split Start class into two groups?" WhatamIdoing (talk) 23:09, 18 August 2024 (UTC)[reply]

It's bigger than that. It's "if we were to reinvent the wheel, and repaint the bike shed, what would it look like and what colour should it be?" The answer to that is "it'd still be a wheel and the shed is fine as is". The criteria are well-established and clear, and short of a clear actionable problem supported by the whole community, they should remain as they are. Headbomb {t · c · p · b} 23:53, 18 August 2024 (UTC)[reply]

Merging classes was only part 2 of the question. I was asking about whether A, B, and C classes should be renamed DimensionalFusion (talk) 09:21, 19 August 2024 (UTC)[reply]

I would consider using something other than the A-B-C convention. I noticed that an inordinate number of editors were adding A class to India articles. Apparently people think it's like self-grading a homework assignment. I think A-class should either become a universal process like GAR or FAR, or go away entirely. That I know about, only WP:MILHIST, WP:USROADS and WP:HIGHWAYS have a process to review A-class articles. WP:WikiProject Biography and Wikiproject Cyclones had a process, but the latter turned out articles that in no way represented the best of Wikipedia. Schierbecker (talk) 02:40, 19 August 2024 (UTC)[reply]
Yeah I agree. Given how few WikiProjects actually have a process for reviewing A-Class articles and how difficult it would be to create them given how many of them are small and/or semi-inactive. Standardising it to a universal process or eliminating it would probably be better. Although there is always the idea that "it's there if people need it" DimensionalFusion (talk) 09:04, 19 August 2024 (UTC)[reply]

What's A class? Why does it even exist? I always thought there's B class, better than that is Good Article, and the very best is Featured Article. A class seems to have no good place in this scheme of things. Gawaon (talk) 11:23, 19 August 2024 (UTC)[reply]
A class exists because there is a broad gap between GA (B class with a review by a single editor - a low grade) and FA (A class with a comprehensive review by at least three editors - a high grade). B class is the minimum acceptable standard, which is why it would be destructive to merge with lower classes. Starts and stubs are unacceptable quality. FA is not generally available. Our very best is A class (comprehensive review by at least three editors from the project). Hawkeye7 (discuss) 11:16, 21 August 2024 (UTC)[reply]
A class (comprehensive review by at least three editors from the project) isn't necessarily correct. The majority of WikiProjects don't have any specific assessment criteria for A-Class articles, and WP:Content assessment just lists some generic criteria. In contrast, GA gives much more solid criteria.

It may be because GA is a site-wide standard but A-Class criteria is handled by WikiProjects, though this is a bit confusing given the majority of articles have multiple WikiProjects. Am I missing something here? DimensionalFusion (talk) 21:49, 22 August 2024 (UTC)[reply]
The majority of WikiProjects don't use A-class at all, so of course they haven't wasted their time setting up a process and criteria for using it. WhatamIdoing (talk) 04:19, 23 August 2024 (UTC)[reply]
Under the rubric suggested by Wikipedia:Content assessment/A-Class criteria, A-class reviews closed as successful by WikiProjects without a formal A-class review system should be supported by two uninvolved editors, with no significant opposes. The number of articles that were made A class using the informal process is basically zero. For a while WP:Cyclones was promoting subpar articles based on discussions held on IRC, but they were the rare exception. Schierbecker (talk) 21:38, 26 August 2024 (UTC)[reply]
If most WikiProjects have no formal A-class review and almost no A-class reviews are carried out using the criteria at Wikipedia:Content assessment/A-Class criteria, how are most articles supposed to get A-Class DimensionalFusion (talk) 16:05, 27 August 2024 (UTC)[reply]
They aren't expected to be rated as A-class. Most groups would rather have them rated as either GA or FA instead. WhatamIdoing (talk) 22:36, 30 August 2024 (UTC)[reply]
Other than a topicon, why? DimensionalFusion (talk) 11:25, 31 August 2024 (UTC)[reply]
Because as someone not involved with MILHIST, I am not familiar with A-review. I cannot name a single other WikiProject off top of my head that does A-reviews though they exist. On other hand, most editors understand what GA standard is, which isn't custom to any Wiki projects. If there was a proposal to introduce A-class as a universal standard, I would reconsider my position, but as it stands, it adds more confusion than anything else to rest of the project. This is why project banner shell has been simplified to rate class of an article on behalf of all WikiProjects. ~ 🦝 Shushugah (he/him • talk) 14:42, 31 August 2024 (UTC)[reply]
The problem here is that making A-Class a universal review like FA or GA is that GA already has a big backlog, but as A-Class is above GA it would make reviews take longer due to the higher quality requirements. Potentially leading to an even longer backlog.

But what is your position on A-Class because I’m not entirely sure what your suggestion is DimensionalFusion (talk) 15:27, 31 August 2024 (UTC)[reply]

@DimensionalFusion, do you mean why do WikiProjects generally prefer FA and GA? It's because they don't want to bother with A-class. Think about it: Either you can do a whole bunch of extra optional work for very little value, or you can just... not. WhatamIdoing (talk) 01:36, 1 September 2024 (UTC)[reply]
That doesn’t really make sense./Why/ does A-Class offer seemingly little value compared to GA and FA DimensionalFusion (talk) 01:56, 1 September 2024 (UTC)[reply]
We could rename start to D class, and stub to E class to make the system more consistent. Graeme Bartlett (talk) 10:00, 19 August 2024 (UTC)[reply]
Although stub is listed in WP:Content assessment I'm told it's technically a seperate thing(?)

and D and E classes apparently suggest an article is "failing" DimensionalFusion (talk) 10:35, 19 August 2024 (UTC)[reply]
I agree; that would go against the spirit of WP:BITE. If my first articles were rated as "D or E"(even if it was deserved) it'd have demotivated me. Ca ^{talk to me!} 06:24, 21 August 2024 (UTC)[reply]

Their current names seem fine enough. Gawaon (talk) 11:22, 19 August 2024 (UTC)[reply]

There definitely isn't a pressing problem here, but I do agree that we're being overly precise with content assessments, both in terms of the capacity of WikiProjects to review and re-review them (way, way down from 2008) and what they're actually used for (does the difference between C and start and B actually change anything, anywhere?) That the current situation works okay shouldn't stop us trying to refine it.

I like the simplicity of Stub > Start > GA > FA. A stub is a potential article, that might still end up being merged or redirected. GA and FA are well-defined standards with dedicated review processes. The GA criteria in particular are way lower than most people think: we could aim for most articles being GAs one day, and a lot of things that are being rated B or A are already there. I don't see the point in differentiating the mass in the middle---articles that have established themselves but that nobody has really whipped into shape---perhaps just call them something like "satisfactory" or "average" instead of "start" (which implies some deficiency). – Joe (talk) 07:29, 21 August 2024 (UTC)[reply]

I see a big difference between articles like for example Mode conversion (start) and Atom (B). Start class articles are short articles that probably cover the basics but there is a lot more they could say and improvements to writing style, referencing, etc are almost certainly possible. B class articles are (mostly) comprehensive and generally well written but haven't been through any formal processes. Whether there is a need to differentiate B and C is the only question in my mind, but retaining the distinction between them and start is useful.

When looking for examples though I did find MXenes which is tagged as start class but is clearly higher quality than that, especially if someone who understands the subject expands the lead. Thryduulf (talk) 10:28, 21 August 2024 (UTC)[reply]

There is absolutely a difference between Start articles and B-rated articles in the abstract, but the goal remains the same with either article; keep improving them. And at the same time, there are a ton of improperly classified articles, because editors are either too stringent or self conscious and either way, the energy should be focused on improving them. Heck, editors are reluctant to downgrade a B article to a Start article and prefer to fix issues (which is probably the right spirit), but makes the ratings exaggerated in their helpfulness across our 6 million articles here. ~ 🦝 Shushugah (he/him • talk) 00:36, 23 August 2024 (UTC)[reply]

The goal remains the same but the implied method is different. A Start article implies great adding work is needed, a B-class article implies curating and refinement is needed. This difference is why you don't really go from a B to a Start, as it's rare that much content leaves articles. CMD (talk) 04:19, 23 August 2024 (UTC)[reply]

> does the difference between C and start and B actually change anything, anywhere?

Yes. It changes the likelihood of the article being selected for an offline release by the Wikipedia:Version 1.0 Editorial Team. WhatamIdoing (talk) 04:20, 23 August 2024 (UTC)[reply]

Note that this project was recently marked as historical. ― novov (t c) 08:56, 23 August 2024 (UTC)[reply]

Thanks for the note. I've pinged the person who was coordinating it to the 1.0 talk page to see whether they're actually inactive. WhatamIdoing (talk) 20:38, 23 August 2024 (UTC)[reply]

Offering to link.

Is it possible to have links offered when any page is created in mainspace (or moved from say draftspace). So if Grand Poobah Association is created, as part of the creation in mainspace, it brings up a list of article (and clips of the article) containing the phrase "Grand Poobah Association" unlinked. Basically, I am trying to somehow staple https://edwardbetts.com/find_link/ to the end of the creation/move to mainspace process. Absolutely fine if this is optional.Naraht (talk) 18:55, 20 August 2024 (UTC)[reply]

This sounds like a useful tool/gadget that editors could install if they want. Posting at Wikipedia:User scripts/Requests is most likely to attract the attention of people who can make it happen. Thryduulf (talk) 21:29, 20 August 2024 (UTC)[reply]

Save Changes

If someone's computer crashes or for some another reason they close the tab, their changes while editing will be lost. I think we can have a 'save changes' button so that the changes can be saved without finishing the edit halfway. Please provide your inputs. Anonymous1261 (talk) 14:36, 21 August 2024 (UTC)[reply]

In your Preferences > Editing, select Enable the Edit Recovery feature. Schazjmd (talk) 14:42, 21 August 2024 (UTC)[reply]

Thank you! Anonymous1261 (talk) 14:45, 21 August 2024 (UTC)[reply]

You're welcome.

Schazjmd (talk) 14:46, 21 August 2024 (UTC)[reply]

This happens automatically in the visual editor. WhatamIdoing (talk) 04:23, 23 August 2024 (UTC)[reply]

Bit numbering in field descriptions

Articles on computers and software frequently display fields labeled by bit number in, e.g. instructions, registers. Tables are a convenient means to do this, but involve a good deal of manual editing to consistently align field descriptions with bit labels. It would be helpful to have tools that automated the creation of such tables.

As an example, the IBM 7094 registers table might be generated from the templates

{{dbitdef|S|Q|P|AKA|0|1-35}}
{{dword|S|Q|P|1-35|content=Accumulator|label=AC}}
{{dword|S|1-35|content=Multiplier/Quotient|label=MQ}}
{{dbitscale|0-35}}
{{dword|S|1-35|content=Sense Indicators|label=SI}}
{{dlabel|Index registers}}
{{dbitscale}|3-17}}
{{dword|3-17|content=Index Register 1|label=XR1}}
...
{{dword|3-17|content=Index Register 7|label=XR7}}
{{dlabel|Instruction counter}}
{{dbitscale}|3-17}}
{{dword|3-17|content=Instruction counter|label=IC}}

Examples such as the PSW layout in Program status word § S/360 would require additional templates.

An alternate or supplementary approach would be for VisualEditor (VE) to provide tools for building such layouts. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:54, 23 August 2024 (UTC)[reply]

When you look inside these templates, is this ultimately just a fancy way of formatting a wikitext table? WhatamIdoing (talk) 20:39, 23 August 2024 (UTC)[reply]

Pardon my pragmatism, but it doesn't seem viable unless you can do it yourself. Even with community consensus, you're not likely to find a template-qualified editor willing to spend the necessary time without a personal interest in the product. Many far smaller proposals have failed for that reason.

If such an editor exists, they can Just Do It™ as normal bold editing; prior community consensus is not required.

Re "personal interest in the product", it doesn't get much more arcane. I say this as a retired system software developer very familiar with the S/370 PSW and its descendants. Sadly, I'm not template-qualified. ―Mandruss ☎ 01:55, 24 August 2024 (UTC)[reply]

Easier-to-read Article Font when Editing

When editing a page in Wikipedia it can be difficult to read the actual article because of the code, i.e. brackets, urls, citations, references etc. My suggestion is for all code to be in either a different font colour, theme (e.g. Times Roman) or style (e.g. bold), with the published words, numbers etc., clearly legible and distinct from the code, such that what the reader will see on the published page will be seen on the editing page. Protestnt (talk) 08:34, 25 August 2024 (UTC)[reply]

@Protestnt you can enable syntax highlighting. See also: WP:SYNTAX —TheDJ (talk • contribs) 08:50, 25 August 2024 (UTC)[reply]

I don't use it myself (I'm old-fashioned and small-c conservative in that way) but I am told that the visual editor provides a more WYSIWYG interface. Phil Bridger (talk) 11:43, 25 August 2024 (UTC)[reply]

VisualEditor's primary design characteristic is not displaying wikicode, so it's not an ideal solution for this user story. As mentioned, the Syntax highlighter gadget at Special:Preferences#mw-prefsection-gadgets under "Editing" is probably a good start, or the 2017 wikitext editor. Those will handle the colour changes (well, not in Minerva, but it looks like Protestnt edits in desktop view). Font family changes could likely be handled with custom CSS.

I feel like User:Alexis Jazz/Factotum might have rich enough and configurable enough syntax highlighting to be a one-stop option here, but I only used it for a brief time around a year ago (too much javascript for my phone) and I can't remember all the options in that package. Courtesy ping Alexis Jazz. Folly Mox (talk) 16:32, 25 August 2024 (UTC)[reply]

I think it might be a great answer to this User story. If the problem is "it can be difficult to read the actual article because of the code, i.e. brackets, urls, citations, references etc.", then "get that visual clutter out of sight" is a great solution. A lot of FAs get copyedited in the visual editor precisely because it's easier to "read the actual article" without brackets and templates in the way.

@Protestnt, click this link: https://en.wikipedia.org/w/index.php?title=Australian_Football_League&veaction=edit and see if you like this style better. A lot of experienced editors use both editing environments, depending on the kind of change we want to make. WhatamIdoing (talk) 23:12, 25 August 2024 (UTC)[reply]

Measures of editor experience

Is there a better way of assessing an editor's experience? This is something one might (should?) do before interacting with another editor. (And also something to apply to oneself, now and again.) At present we have (1) edit counts and (2) number of articles created (3) date of first edit (have I missed one?). It seems hard to get an opinion on how much of an editor's work is in writing new encyclopaedia content of articles – which is the job we are here to do (yes, just like, e.g., a car manufacturer being all about building cars, we do need a lot of support functions to achieve that job).

The problem with edit counts is that this includes:

lots of short edits because the editor does not prepare a considered piece, check it with a preview, and then add it.
interminable discussions/arguments on talk pages.
a focus on page curation (example:[1]) or other "maintenance" activity.

The problem with number of articles created is that an editor may be working in an area where most subjects have an article on them already. Some of these may need improvement (sometimes radical improvement), updating or simply expanding from a stub. So this measure favours those who edit in rapidly changing subjects where new topics arise frequently.

Date of first edit has some use, but there are still editors who started years ago who seem to be unaware of some of the basics, and quite new editors who seem to have got a real good grip of how everything works and produce quality article content.

In searching for a useful set of measures, I suggest something that looks at activity in main namespace (i.e. encyclopaedia content). This could be, as a single group of information:

the total number of characters added
the number of edits
the number of edits grouped in size bands

I feel this would give a more useful view of an editor's activity. What is important is that this should be easily visible to anyone (without needing knowledge of some little used method of getting this data).

Any thoughts would be welcome. ThoughtIdRetired _TIR 11:16, 27 August 2024 (UTC)[reply]

My first thought is to back up a step and ask why you think we need a measure of editor "experience" in the first place? Anomie ⚔ 11:19, 27 August 2024 (UTC)[reply]

Agree with Anomie, especially since "experience" doesn't really translate linearly, someone could be very experienced at writing content but not familiar with "backend" or administrative tasks. Or someone could be very good at writing templates and maintaining code. Or doing mostly WikiGnoming. Etc.
Yes, one could say that only the first one is "pure" editing, but this doesn't mean they're inherently the only one doing valuable work, or that they should be higher in some kind of hierarchy of experience. Chaotic Enby (talk · contribs) 11:43, 27 August 2024 (UTC)[reply]

In addition to the points made by Anomie and Chaotic Enby (with which I agree), your proposed metrics are not reliable indicators of anything relevant: a highly skilled copyeditor will have fewer character additions to their name than someone who writes long, terrible prose. Which of these two edits of mine is the greater addition of encyclopaedic content +220,030 bytes or +759 bytes? Is making the same improvement in one edit better or worse than making it in two edits? My recent gnoming contributions have ranged in size from -167 bytes to +220,030 bytes, almost entirely overlapping with my non-gnoming edits (other than deprodding and BLARing). The number of edits in each band tell you nothing about the sort of editor I am. Thryduulf (talk) 12:04, 27 August 2024 (UTC)[reply]

I thought the brief analogy (above) with a car factory was clear – sticking with that analogy, yes the main task may be building cars, but you still need accountants, cleaners, a marketing department, etc., etc. So I am well aware that Wikipedia would not function without lots of tasks other than "pure" editing. What I find a problem is that in the example I gave above, [2] the edit count (as the only readily available metric) does not make clear that the editor has done very little writing of encyclopaedia content, yet they are welcoming new editors, have offered themselves (on 11 July) for multiple feedback services and are active on approval of draft articles. There is very little editing of actual article content and even less of finding some sourced material and adding it to an article. So from this I conclude that the measure of edit count is misleading and that the editor in question does not really have the experience to be judging other editors' efforts. Hence the need for more better quality information. With that information available to all, it might make an editor ask themselves "am I the right person for this job?", so providing a self-policing element. ThoughtIdRetired _TIR 12:42, 27 August 2024 (UTC)[reply]

On Wikipedia:Page Curation, we find Page Curation is a suite of tools developed between March and September 2012 by the Wikimedia Foundation, and greatly improved in 2018 in collaboration with the Wikipedia community, to help experienced editors review new pages on the English Wikipedia.[bold added] The thoughts here are all about determining what is an "experienced editor" – hopefully with that largely being self-policing if the right info is available. ThoughtIdRetired _TIR 12:48, 27 August 2024 (UTC)[reply]

What is it about extensive writing of article content that makes someone uniquely qualified to welcome other editors, offer feedback on articles or determine the quality of a draft? In the passage you quote, "experienced" means "is familiar with Wikipedia's policies, guidelines and norms", someone who spends most of their time on Wikipedia reading a broad range of existing articles and discussions is very likely going to have a much better grasp of what page curation entails than someone who has spent twice that amount of time adding sourced content to a narrow topic area. Two people who spend the same amount of time making the same number, size and type of edits to the same type of articles can be very differently suited to page curation - for example if editor A's edits are almost all accepted as good by others while editor B's are reverted and/or require extensive fixing by others. Editor B is arguably more experienced because they will likely have been directed to read more policies and guidelines and had more talk page interaction regarding their editing than editor A (whose talk page may consist only of a welcome message). There is no simple metric that can capture this. Thryduulf (talk) 13:03, 27 August 2024 (UTC)[reply]

Large numbers of edits that welcome new users make a correspondingly large increase in the edit count of a user. These are not edits that increase an editor's knowledge of Wikipedia. This is something that devalues edit count as a useful measure of experience. ThoughtIdRetired _TIR 16:25, 27 August 2024 (UTC)[reply]

Respectfully, I don't think we need more metrics and ratings and hierarchies of editors. I'll also note that the Wikipedia:New page reviewer user right (which gives access to the Page Curation tools) is only granted by administrators, most often at first for a short trial, so there is already every opportunity to check if the user has the experience needed.

One does not simply walk in and start patrolling new pages. (Although NPP always needs more people!) Chaotic Enby (talk · contribs) 14:27, 27 August 2024 (UTC)[reply]

I think it’s helpful to know whether someone is a [[WP:Young editor]] when giving them feedback on potentially problematic edits. But when people are able to communicate adequately, none of the metrics about previous edit count, areas of expertise concern me. I can be convinced that having certain about edit count, user permissions can be helpful when looking at someone’s diff and to ascertain what kind of question to ask someone; but again with emphasis on being kind and effective communicators. In the past, I’ve been chided as a “new editor” when I had 500 edits by someone who was abusing their seniority status. Needless to say, they were also blocked frequently for problematic behaviours. ~ 🦝 Shushugah (he/him • talk) 14:46, 27 August 2024 (UTC)[reply]

From my experience (and I am talking about positive experiences) the most helpful of editors are those who have added a lot of encyclopaedia content. I attribute that to their understanding of some of the problems in sourcing and explaining an article, and also in how to interact with some of the more difficult people in this community. I suspect that many editors, whether they know it or not, have learnt most of their knowledge on Wikipedia from other editors with a substantial track record behind them. What worries me in this case is: who will a new editor go to for assistance/guidance? If they go to someone who was their new page reviewer, but that person does not have any depth of experience, that new editor is being short changed.
In the example given, the editor in question apparently does not read the articles too closely – I have no idea what they are doing, but tagging a short article that says when some died (20 years ago, at a good age) with a BLP warning suggests a superficial approach, as does immediately sticking an orphan tag on everything that comes out of draft, which will obviously be the case on making that transition.
To answer I don't think we need more metrics and ratings and hierarchies of editors: I think I am trying to make a closely related point, that the metrics we do have can mislead. Perhaps we just need a warning that the existing measures can mislead. ThoughtIdRetired _TIR 16:14, 27 August 2024 (UTC)[reply]

Angela (enslaved woman)

On June 4, 2024, I moved the article Angela (enslaved woman) to Angela (slave), for homogenization. It was reverted by @CaroleHenson on July 3, in which they cite Slavery#Terminology. I attempted to reach them 6 days ago (as of August 30), but they are currently inactive.

The following is from User talk:CaroleHenson#Angela (slave):

The terminology section itself describes the naming as "dispute". I thought the (slave) disambiguator would be a better choice due to WP:NOTCENSORED, similarly to changing "passed away" to "died".

Second, only Angela's page was moved. I can easily find other pages still using the (slave) disambiguator, including John Punch (slave), Abigail (slave), Fortune (American slave), William Gardner (former slave), John Brown (fugitive slave), William Grimes (ex-slave), William Green (former slave). You also didn't move Caesar (slave), which I based my move off of.

The only other pages I could find using the (enslaved man/woman) disambiguator are Acme (enslaved woman), Ana Cardoso (enslaved woman) and Peter (enslaved man).

Should (enslaved man/woman) replace (slave) as a disambiguator? Roasted (talk) 22:13, 30 August 2024 (UTC)[reply]

VPI is for broader idears. You should be opening a WP:RM. Aaron Liu (talk) 22:28, 30 August 2024 (UTC)[reply]

Also, I suggest reading WP:OTHERSTUFFEXISTS before writing your explanation for the requested move process. You will want to write something that doesn't sound like "It's more important for this article to match the others than to avoid language that I've been told is potentially offensive".

Wikipedia should generally avoid needlessly offending people. We want people who read that article to be thinking about the historical subject. We don't want them thinking about whether Wikipedia uses outdated or offensive language. WhatamIdoing (talk) 22:52, 30 August 2024 (UTC)[reply]

There was a recent discussion that, while not formally closed, basically came to the conclusion that both "slave" and "enslaved person" are acceptable ("slave" is not "outdated language") but that one might be preferable to the other depending on the specific context. In such situations it is almost always a bad idea to change from one to the other without consensus. Thryduulf (talk) 23:03, 30 August 2024 (UTC)[reply]

So should the other pages with “(slave)” is the title should be moved? Roasted (talk) 23:08, 30 August 2024 (UTC)[reply]

Certainly not without discussion. It's clear that the title is not uncontroversial so a requested move discussion needs to be initiated to determine consensus before any title is changed. Thryduulf (talk) 00:22, 31 August 2024 (UTC)[reply]

@Thryduulf It might be a good idea to put that one on WP:RFCL. I'd do it, but I have 2 pending ones there already. Wikipedia_talk:Manual_of_Style/Archive_228#MOS:SLAVE? didn't go anywhere. Gråbergs Gråa Sång (talk) 06:21, 31 August 2024 (UTC)[reply]

I don't think that (non-RFC) discussion needs a formal closing statement. We probably need to have multiple conversations like that, until more editors become familiar with the subject matter. A formal summary tends to discourage future discussions.

In particular, "both are acceptable" summaries tend to get misused this way: "The rules say that both are acceptable, so my preference is acceptable, and so the rules say we have to do it my way (and never, ever your way)".

As linguistic practices in scholarly and other high-quality sources have just started changing enough for editors to be noticing this, this is probably an area where we need people to keep their brains turned on instead of just trying to find a simplistic rule. I think the best approach will be more obvious in, say, five years. For now, we just need to avoid carving a rule in stone. WhatamIdoing (talk) 01:44, 1 September 2024 (UTC)[reply]

In the specific topic of article titles, OTHERSTUFFEXISTS may be a valid argument, as consistency is one of the titles policy's criterions. Aaron Liu (talk) 02:33, 31 August 2024 (UTC)[reply]

The policy requires Neutrality in article titles, so if editors decide that they have to match, they might need to make them match on the one that won't create an opportunity for complaints about offensiveness.

NB that I'm not saying anyone should be offended; I'm just saying that we already do get complaints about "slave" being offensive, so we can reasonably predict that we will get complaints about offensiveness if we choose the (slave) convention. Similarly, we currently don't get complaints about "enslaved person" being offensive, so I think we can reasonable predict that we won't get complaints about offensiveness if we choose the (enslaved person) convention. WhatamIdoing (talk) 01:50, 1 September 2024 (UTC)[reply]

Proposed temporary solution to the "remember me" function bug

Here is the thread on the bug -> Wikipedia:Village pump (technical)#"Remember me" not working as intended for me Basically, "remember me" would forget about you sometimes, for whatever reason. Now, I have no idea how wikipedia works under the hood, so this idea may be absurd or even stupid. I would like to suggest that a check is done every time an IP edits wikipedia to see if it is associated with an account, and a banner be displayed if the check returns a positive result, promoting to user to log back in before publishing their edit. —Mint Keyphase (Did I mess up? What have I done?) 02:57, 31 August 2024 (UTC)[reply]

A warning is displayed every time you edit with IP address about editing under an IP address. I would say that's already a warning enough if one has been editing while logging in. – robertsky (talk) 01:55, 1 September 2024 (UTC)[reply]

@Mint Keyphase, Wikipedia runs MediaWiki software under the hood, and if you are interested in that, please go to mw:How to contribute on our sister site (same username/password; it'll usually log you in automagically).

Robertsky is correct that we already post a warning for every IP. It's in a yellow box at the top of the page and says:

You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to a username, among other benefits.

Additionally, there are privacy problems around doing things with detecting logged-out editors. Here be dragons, or at least lawyers. This might be solvable, but it's not likely to be quick.

The practical problem is bitter. Imagine what would happen if we did this, and you were using a shared internet connection, e.g., at school. Everyone in the school building would get 'warned' because one person logged out. This is probably not solvable. WhatamIdoing (talk) 01:59, 1 September 2024 (UTC)[reply]