Wikipedia:Village pump (idea lab)

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

Just for completeness, I chanced upon [3] recently. I have no idea how meaningful its results are, but it certainly appears better than just edit count. ThoughtIdRetired _TIR 18:04, 8 September 2024 (UTC)Reply

Heh, my net byte count is negative. —Tamfang (talk) 18:35, 10 September 2024 (UTC)Reply

And that's no reason to think that you're a better or worse editor than anyone else. User:ThoughtIdRetired, is there any page that gives the impression things like edit count, number of articles created, and date of first edit are meaningful measures? Phil Bridger (talk) 19:53, 10 September 2024 (UTC)Reply

That's one of the points that I am trying to make: that measures of editor experience can mislead. I have in mind an argumentative editor who questioned my edits (to "their" articles, of course) based on the fact that I have only created x number of articles (whilst they have created very many, one of which I am currently looking at proposing for deletion as it is a complete work of fiction). At the other end of the scale, as described above, we have a relatively new editor whose edit count consists of a large number of welcomes to new editors – so perhaps misleading them on their knowledge of Wikipedia, when a new editor might go to them for help (due to the welcome message). Based on comments here, I am coming to the conclusion that we need some sort of health warning on anything that could be construed as a measure of editor experience. Whilst measures do have value (like spotting the new editor, or realising that you are dealing with an editor with a huge amount of experience), they are only indicators. Both new editors and very experienced editors can surprise with characteristics we might not expect. ThoughtIdRetired _TIR 13:55, 11 September 2024 (UTC)Reply

ThoughtIdRetired, I usually check xtools's Edit Count tool available at the bottom of an editor's contribs. Here's yours. There's no perfect method, of course, but it combines enough information that I find it genuinely helpful. The namespace breakdown pie chart can be particularly illuminating. YMMV. Folly Mox (talk) 11:21, 11 September 2024 (UTC)Reply

I do wonder (partly in jest) if the best measure of an editor is the number of times that they have been thanked as a proportion of their total number of edits. In reality, this might be a function of the other editors that they interact with. More seriously, all of these methods of assessments are useful only if we all remember their limitations. ThoughtIdRetired _TIR 13:55, 11 September 2024 (UTC)Reply

Do note that on some devices (e.g. my smartphone), an editor's edit count is prominently displayed when looking at an edit, whilst it is not on the computer that I am using now. I think we need to take this into account. ThoughtIdRetired _TIR 13:55, 11 September 2024 (UTC)Reply

I don't think that any automatically-generated process can give any meaningful measure beyond knowing that an editor with only a few edits probably hasn't read all the policies and guidelines that old-timers have. I don't use a smartphone to edit Wikipedia, but know that there are many more important things than edit count, so I wouldn't have decided to display it prominently. I would probably do reasonably well on the "number of thanks" measure but that's probably just a function of the pages that I tend to edit. There's no real substitute for looking at someone's contribution history and deciding for yourself who the good editors are. Phil Bridger (talk) 18:51, 11 September 2024 (UTC)Reply

I like User:PleaseStand/User info. Both account age and number of edits is useful.

The thing about the number of edits is you have to remember how few edits is normal. Of the registered editors who edited at all last year (calendar year 2023), half of them had five or fewer edits. Not "five in 2023", but five total, for the whole lifetime of the account. Someone who has just reached Wikipedia:EXTCONFIRMED is in the top 1% of all time. We tend to think "Oh, three thousand edits – practically a baby", but almost nobody reaches that level. WhatamIdoing (talk) 22:28, 11 September 2024 (UTC)Reply

That's an interesting viewpoint. Doing a very small sample of all recent edits in Wikipedia (just 20 – we would need a higher level of automation to get past my patience level), we get:

Automating such an enquiry is beyond me, but it would be informative to see the results of a bigger sample. This snapshot suggests that there is some equality between the number of inexperienced editors (less than 1,000 edits), moderately experienced editors (1,000 to 10,000) and highly experienced editors (10,000 and above). ThoughtIdRetired _TIR 08:53, 15 September 2024 (UTC)Reply

Automating is also beyond me, but I have patience enough to look at the edits for the most recent 100 registered editors making non-bot edits (from 10:13 UTC 15 September 2024).

Sample of recent edits

Number of edits	editors
0 to 10	9
11 to 100	8
101 to 1,000	14
1,001 to 10,000	25
10,001 to 100,000	29
100,001 to 1,000,000	14
1,000,000 and above	1

Three editors were making their first edit, 1 editor (Jevansen) was making their 2,863,752nd edit, only two other editors were above 500,000. The average was 82,933 edits (excluding the top 10: 23,597), the median 6,550 edits. Thryduulf (talk) 10:49, 15 September 2024 (UTC)Reply

Automating it is not beyond me. 😀 Caveats: I can't get edit counts for IP edits, and I have to bucket by total current edit count rather than edit count at the time of the edit.

Breakdown of edits for 2024-09-14 (UTC)

Bucket	Editors	Edits	Edits per editor
IP	7365	19515	2.6497
0–10	1797	3511	1.9538
11–100	1841	6305	3.4248
101–1000	2427	12467	5.1368
1001–10000	2881	22996	7.982
10001–100000	2206	37833	17.15
100001–1000000	480	30027	62.5563
>1000000	32	29498	921.8125

Something to consider is whether you're talking about edits or editors. In this sample, the 32 editors in the last bucket made an average of 921.8125 edits each, while the 1797 in the lowest non-IP bucket averaged less than 2 each. If you pick a random editor who edited during the period you're more likely to get someone in the lower buckets than if you pick a random edit during the period. It gets more pronounced if we look at a longer time period:

Breakdown of edits for September 1–14, 2024 (UTC)

Bucket	Editors	Edits	Edits per editor	Edits per editor per day
IP	97888	280695	2.8675	0.20482228
0–10	23486	53038	2.2583	0.16130582
11–100	16730	92157	5.5085	0.39346341
101–1000	14742	177328	12.0288	0.85919724
1001–10000	9940	344981	34.7063	2.47902414
10001–100000	4464	559417	125.3174	8.95124488
100001–1000000	650	450341	692.8323	49.48802198
>1000000	36	432235	12006.5278	857.60912698

Running the query for the first half of September, the number of editors in the lower buckets increases much more, while the number of edits in the higher buckets increases much more. Anomie⚔ 12:30, 15 September 2024 (UTC)Reply

That's fascinating. Is there an "interesting facts about Wikipedia" place for this sort of thing to go? I've just sorted the month to date list on "edits" and put percentages on each line of the total number of edits. What that show is that if you have an interaction on a "random edit", it is most likely with an editor in the 10,000 to 100,000 band (23% of all edits).

But thinking of interactions, that doesn't seem to be my experience. (Latest interaction is reverting some terminology put in by an editor with 261 edits, being reverted, then having to explain on the talk page that the article's source is not an RS and list three high quality sources that support the preferred language.) I suppose that says that the more experienced editors do work that does not really need any attention from the likes of me.

The month to date table also shows that 9% of the editors do 75% of the work. ThoughtIdRetired _TIR 13:08, 15 September 2024 (UTC)Reply

See Template:Registered editors by edit count for percentage/ranking by edit count.

Pages such as Wikipedia:Statistics#Edits per editor and Wikipedia:Wikipedians#Number of editors would also be suitable repositories for this kind of information.

There are also qualitative differences in edits by volume. The 5th edit is more likely to be adding content than the 50,000th edit. High-volume editors tend to be doing semi-automated edits – a Twinkle tag here, an AWB run there, a reference formatting script... WhatamIdoing (talk) 16:52, 15 September 2024 (UTC)Reply

This is a practice request rather than a feature request.

When looking at diffs, it's a pain to scroll through a paragraph taller than my screen to find the one changed word (or comma), not to mention the similarly long paragraphs shown before and after it for context.

I would urge editors to insert single line breaks – which are invisible on the page – between sentences, especially after complex refs. Or at least not to go out of your way to remove such breaks! —Tamfang (talk) 19:10, 3 September 2024 (UTC)Reply

That will converse the bots as to where the paragraph ends. Hawkeye7 (discuss) 06:06, 4 September 2024 (UTC)Reply

I wouldn't want to converse anyone unnecessarily, but can't bots detect a blank line? —Tamfang (talk) 23:11, 4 September 2024 (UTC)Reply

It's fine to put linebreaks inside templates, such as the citation template. If one is really concerned about losing something in the underlying html, then one can enclose a linebreak within an html comment <!-- -->. These may or may not help with alleviating the diff display.

The html for a single line break in plain wikitext appears as a newline character within a <p> element, which is not rendered by default, but may be picked up accidentally by a bot (not sure for example if AWB's regexp tools default to stop at newlines, or else match "^" to newlines, but imo regexp is inherently a trial-and-error tool, and people who have been using it on WP for a while will have tested their code on newlines already).

As for whether it impacts something more important like commercial accessibility tools (like screen readers), I don't know. But OP's issue is an important accessibility issue as well, since as most of the emerging and young world is operating exclusively on mobile devices, we want to address their UX concerns. (I enjoyed the essay Wikipedia:Editing on mobile devices.) SamuelRiv (talk) 18:41, 6 September 2024 (UTC)Reply

I would concur it's worth considering a habit of single linebreaks following elaborate citations. Remsense ‥ 论 12:55, 11 September 2024 (UTC)Reply

As it happens, there's already an essay advocating for this exact practice: Wikipedia:Newline after references. jlwoodwa (talk) 22:54, 12 September 2024 (UTC)Reply

See, the issue is that shortcut isn't memorable, so how can I possibly make the same point as this essay two weeks from now if I can't remember what letters to link the guy? Remsense ‥ 论 22:57, 12 September 2024 (UTC)Reply

Teach the controversy: WP:NEWLINE —Tamfang (talk) 15:56, 16 September 2024 (UTC)Reply

A TP message I woke up to, this morning, combined with User:Cullen328/Smartphone editing, got me thinking this morning, of how many mobile diffs must be getting thrown up on-wiki every day, and causing the interface changes that Gray flagged up with me.

So why don’t we have a bot, that sweeps edits for en.m.wikipedia links, and changes them to en.wikipedia? I’m not a coding guy, so I couldn’t build this myself, so I’m bringing it to the Idea Lab, if anyone likes the look, and fancies having a go. MM (Give me info.) ^(Victories) 10:57, 11 September 2024 (UTC)Reply

One options is for editors to use something like User:Þjarkur/NeverUseMobileVersion. I use it because I use the desktop site on mobile. Editors who then do click on a mobile diff are just auto-redirected to the desktop site. -- LCU ActivelyDisinterested «@» °∆t° 20:16, 11 September 2024 (UTC)Reply

User:Aveaoz/AutoMobileRedirect is a better version that checks if you're using a desktop browser. Aaron Liu (talk) 21:02, 13 September 2024 (UTC)Reply

Changing other people's comments is probably a non-starter. That is guaranteed to upset people (e.g. see IndentBot's BRFA). Plus, CONTEXTBOT. — Qwerfjkltalk 20:30, 14 September 2024 (UTC)Reply

It seems to me that the root problem you're identifying is that when people in mobile browsers copy-and-paste their url from (some) mobile sites, they get the mobile version of the url, which they then post to some permanent outside forum (and then a desktop user clicks, which takes them to the mobile version of the site, which can be intended behavior on something like wikipedia because we want easy ways to force the mobile version for slow browsers e.g., etc.). The problem then is the copy-and-paste step -- the bare url on your browser's navbar can be the same for both mobile and desktop users if site preference (passed through "m.wikipedia.org") is preserved (which I think it is anyway? I'm not a web dev). For me this can be a minor annoyance on, say, reddit, where many links are posted to the mobile site (I like the mobile site on desktop quite a lot, but having both urls has minor inconveniences like with sorting browsing history). SamuelRiv (talk) 21:19, 14 September 2024 (UTC)Reply

This isn't a perfect match for VPI, but it's not concrete enough for VPPROP and isn't a policy proper yet, so can't be on VPP. This page is a result of WP:RFA2024, but being familiar with the RFCs isn't required (and, as a matter of fact, fresh eyes are encouraged). In short, we had an RFC to determine the specifics of the policy (proposal) which isaacl has summarized here. The page tries to convert the sparse bullet points into a proper proposal.

Though none of the bullet points may be changed without a strong consensus, there are obviously gaps to fill (the templates, for example, are a new addition and need refinement) and sentences to be made clearer and more concise. Sincerely, Dilettante 23:25, 16 September 2024 (UTC)Reply

The title sounds like Wikipedia:Perennial proposals#Reconfirm administrators but the contents are more like Wikipedia:Perennial proposals#Community-based process for removing adminship. WhatamIdoing (talk) 21:57, 18 September 2024 (UTC)Reply

That's a good point. A few others raised the issue of the name, but just cited personal preference. Sincerely, Dilettante 01:26, 19 September 2024 (UTC)Reply

I feel like I've been left behind, forgotten, invisible. I made a post then it got removed. See the page Wikipedia:Village pump (idea lab): Difference between revisions - Wikipedia. Blackbombchu (talk) 15:19, 19 September 2024 (UTC)Reply

It was removed by Remsense with the summary "can't make any sense of this post, unfortunately.", an assessment with which I agree. Thryduulf (talk) 15:25, 19 September 2024 (UTC)Reply

I guess it's just my tiny little seed. It will add that very little tiny bit. They will all add up and get us there eventually. Blackbombchu (talk) 15:29, 19 September 2024 (UTC)Reply

@Blackbombchu, I've left a message on your talk page out of care for you. I hope you read it and see it comes from somewhere authentic. Remsense ‥ 论 15:31, 19 September 2024 (UTC)Reply

In the spirit essays like WP:WTF? OMG! TMD TLA. ARG! and WP:ALPHABETTISPAGHETTI and WP:UPPERCASE, I'm trying to do a lot more lowercase fullnaming when referencing policies like WP:OriginalResearch or wp:competenceisrequired. I've personally found this less likely to be cognitively associated with shouting or lawyering, more self-explanatory without needing a hover, and much easier on the eyes. Hopefully newer editors have felt the same.

Two things I'd like to address:

1. Not all subpolicies have redirects in both lowercase and camelcase. I just want to make sure they can all be made without controversy.
2. On the policy pages themselves, the shortcuts to subpolicies are always uppercase. So we have (in RS) both WP:UBO and USEBYOTHERS as shortcuts in the box, but as only UBO is an acronym, why can't we have the second shortcut suggestion be WP:UseByOthers? (Similar across the P&G.) It's just an indicator that other shortcuts besides UPPERCASE exist.

Relatively minor thing that won't change the actual functionality of anything. It just makes the replaces the suggested full-name spelling (not acronyms) of P&G shortcuts from uppercase to camelcase. SamuelRiv (talk) 19:26, 19 September 2024 (UTC)Reply

To pre-empt the objection that editors should pipe plaintext to P&G as suggested in the essays I linked: I agree, that's great, if editors actually did it with any regularity. For my own part, piping is an extra bit of typing that may not be as clear that I'm referencing P&G in discussion in the first place, which is often important, since I've found people rarely click links anyway. SamuelRiv (talk) 19:32, 19 September 2024 (UTC)Reply

I don't think you're likely to get any pushback on point 1. It has long been my practice to refer to such things in whichever case makes most sense in the sentence I am writing (usually lower case or with a capitalised first letter) and, if "show preview" shows it as a red link, create a redirect. I don't think I've ever had anyone revert this. I'll have to think a bit more about point 2 - there's a danger of bloat there. Phil Bridger (talk) 19:50, 19 September 2024 (UTC)Reply

To be clear on #2: in the box in the P&G that gives the shortcuts in bold blue text: one is an acronym and one is the fullname, so in my linked example, the box says Shortcuts: WP:UBO WP:USEBYOTHERS. I suggest replacing the fullname shortcut in the P&G from allcaps to camelcase, so the box now says Shortcuts: WP:UBO WP:UseByOthers. I'm not sure where you're seeing bloat, as not a single byte is being added or subtracted, and functionally nothing is changed. SamuelRiv (talk) 20:01, 19 September 2024 (UTC)Reply

I see one possible point of contention: in many skins including legacy vector, the search includes all redirects, and some might be annoyed to see a ton of redirects preemptively clog up the suggestions when they want to find something else after typing the first word. Personally, I like point 2-style redirects much better. Aaron Liu (talk) 23:29, 19 September 2024 (UTC)Reply

Legacy Vector search is case-sensitive? So if I start searching "mrna", it brings up a list including "Mrna", "mRna", "mRNA", all of which link to the same thing? If that's the case, and someone is still using such software, then the adding or removing of case-sensitive redirects has surely long since stopped being a cause of heartache for that person. SamuelRiv (talk) 07:26, 20 September 2024 (UTC)Reply

There are a great many ways of searching Wikipedia, some of which are case-insensitive and display a list of possible results as you type. This includes the internal search engine, which is independent of which skin you use (you see the same results in vector, vector legacy, monobook, etc). Thryduulf (talk) 11:29, 20 September 2024 (UTC)Reply

I don't think the internal search engine brings up multiple results to the same page due to redirects. Aaron Liu (talk) 11:51, 20 September 2024 (UTC)Reply

That makes sense. Still, I like the CamelCase redirects better since it's very clear where the words separate. Aaron Liu (talk) 11:52, 20 September 2024 (UTC)Reply

You know what separates words more clearly than CamelCase? Anything spaces. "You're violating our policy about WP:BiographiesOfLivingPeople" vs. "You're violating our policy about WP:biographies of living people." Also easier to type; mostly doesn't need new redirects; and looks way less weird to everyone but programmers. (WP:biographiesoflivingpeople is even worse.) —Cryptic 12:37, 20 September 2024 (UTC)Reply

I don't advocate for redirects like that and merely repeat the title. The UseByOthers example goes to a section with a different name. Aaron Liu (talk) 12:45, 20 September 2024 (UTC)Reply

As could WP:Use by others. —Cryptic 12:55, 20 September 2024 (UTC)Reply

CamelCase is a tiny bit less effort to type and still indicates that the link is a shortcut. I think the reason everything caps is precisely to differentiate them as redirects, and some of that differentiation should be preserved. Aaron Liu (talk) 12:58, 20 September 2024 (UTC)Reply

Personally I don't feel that the visible link text should be differentiated as redirects. This primarily serves to codify a term (in allcaps or camel case) as jargon. There are times when this can lead to greater concision, but most of the time the gain is small, with a cost of greater confusion for those who don't already know the title of the destination and the corresponding text. For example, often non-neutral points of view get labelled as being WP:NPOV. I appreciate the point of view that learning a community's jargon is part of joining that community. I feel, though, that English Wikipedia has plenty of jargon already without every shortcut being used as jargon. isaacl (talk) 15:55, 20 September 2024 (UTC)Reply

The reason I'd advocate camelcase as the second suggested redirect (in the little redirects box in the P&G sections), as opposed to spaced-out prose versions (which I'd also like to see used more by editors), is that camelcase is also at least a little suggestive that there is an acronym people use, or i.e. that a newbie following a discussion might more readily deduce 'WP:UseByOthers ↔ WP:UBO'. If everyone here would prefer listing 'WP:Use by others', that's fine by me; one could also put three shortcuts instead of just the two: 'WP:UBO WP:UseByOthers WP:Use by others'. SamuelRiv (talk) 17:38, 20 September 2024 (UTC)Reply

I’m not sure what others will think of this, but I accidentally had this thought: how would it be if we added a verified badge, similar to Instagram or Facebook’s verified badges, to admin signatures when they comment? It would make it easier to identify that the editor is an admin, instead of having to check their profile, contributions, or diffs, which is a lengthy process and not ideal. Similar to how Discord groups use a green name for admins. What are your thoughts on this? GrabUp - Talk 13:03, 22 September 2024 (UTC)Reply

@GrabUp, there's a script for that: User:Mdaniels5757/markAdmins. Schazjmd (talk) 13:46, 22 September 2024 (UTC)Reply

Schazjmd, GrabUp: there's quite a few, actually. — ClaudineChionh (she/her · talk · contribs · email) 13:47, 22 September 2024 (UTC)Reply

My personal favorite is user:Bugghost/Scripts/UserRoleIndicator. Aaron Liu (talk) 15:30, 22 September 2024 (UTC)Reply

Admins who care to do this can do so, and users who care to see this can do so. But in general this needn't be and shouldn't be the default. We've all seen how sometimes editors seem to show unusual deference to known admins in discussions on non-admin-related matters, such as content and meta-content. This may be unconscious or conscious, but it's counterproductive to discussion and counter to the spirit of the project either way. SamuelRiv (talk) 14:14, 22 September 2024 (UTC)Reply

Agree on this one. Admins are just users trusted with some tools, they don't have any special authority on content or anything else. Chaotic Enby (talk · contribs) 19:26, 22 September 2024 (UTC)Reply

If I use my administrator's tools to block an editor or delete a page or protect or unprotect an article, any one who is looking closely will know that I am an adminstrator because only adminstrators can do those things. On the other hand, when I write a new article or expand an existing article or give an assessment on an article talk page or offer advice at the Teahouse, nobody needs to know that I am an adminstrator because those are not administrative functions and I am just another editor at that moment. I did all those things long before I became an adminstrator. If I tell another editor that I am an administrator, that is in the context of a warning. I see no benefit to a badge. Cullen328 (talk) 08:52, 24 September 2024 (UTC)Reply

It's technically impossible to enforce with traditional wikitext discussions anyways. Structured discussions as used on other wikis might be able to support it, but in that case, why are admins given the blue check and other users not?--Jasper Deng (talk) 09:00, 24 September 2024 (UTC)Reply

(It's actually possible, you just query members of a CSS class and show them the same way you may in structured discussions.) Aaron Liu (talk) 10:57, 24 September 2024 (UTC)Reply

(That is not impersonation-proof.)--Jasper Deng (talk) 11:03, 24 September 2024 (UTC)Reply

Yes it is? The API always tells the truth. By query CSS class I mean all userpage links next to timestamps. There are scripts above that do the exact same thing.
A more efficient implementation would be automatically adding a new CSS class to admin userpage links along with sanitizing signatures against manual addition of the class. That said, I'm not convinced this is something we should do. Aaron Liu (talk) 12:48, 24 September 2024 (UTC)Reply

I don't think this is something we should do either (if users really want it, there are already several user scripts doing that and allowing for custom CSS). I'd say the only place where it isn't impersonation-proof is if someone goes out of their way to fake another user's signature, but at this point it's just saying that our signatures themselves aren't impersonation-proof, and a quick check in the page history is enough to spot and revert it... Chaotic Enby (talk · contribs) 14:02, 24 September 2024 (UTC)Reply

No it's not. The user can completely fake the badge visually by not even querying the API, since inline styles are possible in wikitext, and users control their own signatures.--Jasper Deng (talk) 18:51, 24 September 2024 (UTC)Reply

At present, Wikipedia addresses vandalism in India through IP and host blocks. However, a significant issue is that most Indians access the internet via mobile connections, where mobile providers assign NATed IPs. As a result, when administrators block a host range, it inadvertently affects a large portion of mobile users. Consequently, individuals within these ranges are unable to create accounts or make IP edits. There have been reports of a decline in editors from India, which coincided with the shift towards mobile-based internet access.

To address this challenge, I propose introducing a requirement for users accessing Wikipedia from suspicious networks to provide a verified email address when creating an account. The email should be from a trusted domain, such as Gmail or Outlook, which require mobile number verification as part of their sign-up process. This would help ensure that new accounts from these networks are legitimate.

Additionally, there is room to improve how Wikipedia handles repeat vandals. Currently, when a user is flagged for vandalism, they receive a temporary block, but once the block expires, their account is restored to its previous status without further consequences. It has been observed that some users take advantage of this by making constructive edits for a period, only to revert to vandalism later, perpetuating a cycle of temporary bans. Over time, certain users have accumulated considerable edit counts and status, which they leverage to manipulate factual data—such as box office figures—or prioritise certain sources to skew rankings. The high edit count often discourages other editors from reporting them, despite their history of disruptive behaviour.

To curb this, I suggest implementing additional measures when reinstating users after a block. First, users should be required to provide a verified email address from a reputable domain before their account is reactivated. Second, they should be reinstated in a limited or "safe mode," regaining full editing privileges only after completing a specified number of good-faith edits. This would slow down organised vandals and disrupt their timing, as many appear to operate on a carefully coordinated schedule.

Lastly, to further safeguard the platform, IP edits from suspicious domains IP-Ranges should be permanently blocked, as these are often used for repeated abuse.W170924 (talk) 21:50, 23 September 2024 (UTC)Reply

Addition To address the issue of unreported vandalism, which often remains only as an edit description, I suggest implementing an Email Required Block Filter (ERBF) for moderators. This tool would allow moderators to temporarily freeze a user account until the user provides a valid email address from trusted domains like Google or Outlook, which require phone number verification in India for account activation. Additionally, the user should not be allowed to change the email address for a month.

Furthermore, users who are temporarily blocked for vandalism should be reinstated in 'safe mode,' meaning they will only have the permissions of a newly created account. In this mode, they must complete 100 edits to regain their previous status. If the user is blocked again for similar behaviour, the required number of edits could be doubled for subsequent reinstatements. This approach encourages responsible editing while providing moderators with more effective tools to prevent repeated disruptions.W170924 (talk) 07:21, 24 September 2024 (UTC)Reply

Minor nit: neither Gmail nor Outlook require mobile number verification to create an email account. Schazjmd (talk) 21:56, 23 September 2024 (UTC)Reply

@Schazjmd:I am not sure about other regions, but in India, they won’t allow access to their service until phone number verification is completed.W170924 (talk) 22:04, 23 September 2024 (UTC)Reply

I didn't know that, @W170924, thanks! In the U.S., there's no phone verification requirement to set up an email address. Schazjmd (talk) 22:07, 23 September 2024 (UTC)Reply

I'd rather we just make accounts with a verified phone number get IP-block exempt by default unless the rangeblock specifically requests to block them as well. Wikipedia's software has no such functionality yet though.

IP edits from suspicious domains

what does that mean lol Aaron Liu (talk) 23:23, 23 September 2024 (UTC)Reply

@Aaron Liu:I wrote 'IP edits from suspicious domains,' though I intended to say 'IP edits from suspicious IP ranges,' which was an unintentional mistake. Using a verified phone number is a best practice, but it would significantly increase costs for Wikipedia.W170924 (talk) 04:22, 24 September 2024 (UTC)Reply

Currently, when a user is flagged for vandalism, they receive a temporary block, but once the block expires, their account is restored to its previous status without further consequences. It has been observed that some users take advantage of this by making constructive edits for a period, only to revert to vandalism later, perpetuating a cycle of temporary bans.

Citation needed on this one. Repeated vandalism is nearly always met with escalating blocks for registered users, and the third or fourth block is usually indefinite. For IPs, blocks are usually temporary (although increasing in duration) rather than indefinite, as they are often reassigned to new unrelated users. Nearly all indefinitely blocked IPs are open proxies rather than personal IPs.

Over time, certain users have accumulated considerable edit counts and status, which they leverage to manipulate factual data—such as box office figures—or prioritise certain sources to skew rankings.

Again, do you have any evidence? A user with repeated temporary blocks wouldn't have a lot of "status", whatever that means, and changes aren't trusted based on the reputation of the user who makes them, but on their quality of sourcing. Chaotic Enby (talk · contribs) 23:52, 23 September 2024 (UTC)Reply

@Chaotic Enby:You acknowledge that a permanent ban is only imposed after the third block. This means a person can create an account, commit acts of vandalism, receive a temporary block, then contribute positively for a year before repeating the behaviour. Essentially, the user is given three opportunities to engage in such actions, with their edit history remaining intact throughout. This process can be drawn out, as most vandalism only results in a warning. Recently, there has been a more lenient approach to vandalism, such as using unreliable sources to cite information or editing a range without providing proper references. In some cases, the user's behaviour may go completely unnoticed. My intention was not to single out individuals but to highlight this ongoing issue. I believe systematic vandalism requires a systematic approach. Also, for a new user, the edit count matters as they may not yet be familiar with how Wikipedia operates.W170924 (talk) 04:43, 24 September 2024 (UTC)Reply

So an editor will "contribute positively for a year", and after that the engage in systematic bad-faith editing (however many weeks or months this may take to discern, it is a function that scales with the number of bad-faith articlespace edits)? I echo users above in asking for examples in which this is happening systematically, because... if people are editing WP positively for an entire year just to game the system later, I would hypothesize (awaiting examples) that WP comes out ahead. SamuelRiv (talk) 06:10, 24 September 2024 (UTC)Reply

@SamuelRiv:I still reiterate that the scope is not to name anyone, but you can check my history.W170924 (talk) 07:23, 24 September 2024 (UTC)Reply

• @W170924: I know you mean well, but as someone who has worked extensively in countervandalism, including work as a Wikidata CheckUser dealing with many Indian IP's, your ideas are rather misguided. Firstly, accounts which clearly only vandalize are always indefinitely blocked even on the first instance, and that's the vast majority of cases of vandalism. Requiring verified phone number or email addresses is something the foundation categorically will not do, as they have stated repeatedly, not the least (in part) because it poses a serious inclusivity and accessibility issue for users. "Suspicious IP ranges" does not fly well in India in particular, especially with IPv6, because Reliance Jio and other ISP's stupidly allocate all addresses from one giant, monolithic, block, so (analogously to disk fragmentation) abusive users are highly interspersed with legitimate users. Verified email address obtaining is also very trivial with disposable email services and we will not allow particular providers such as Gmail and Outlook.com to gatekeep our editing access. I must reiterate what others say: you have made these claims of patterns, but have not satisfied the burden of proof since you have not provided any data to support your claims.--Jasper Deng (talk) 08:32, 24 September 2024 (UTC)Reply

@Jasper Deng:I had sent feedback on this to you. Do you think my ideas are misguided?W170924 (talk) 13:37, 24 September 2024 (UTC)Reply

For context, they sent an email. Aaron Liu (talk) 14:19, 24 September 2024 (UTC)Reply

@W170924: Please do not email me unless privacy is absolutely required, which it is not here. What you sent me shows you don't understand what vandalism is; please read WP:NOTVAND. Cases where subtle vandalism are missed would not be helped by your suggestions, either.--Jasper Deng (talk) 19:57, 24 September 2024 (UTC)Reply

@Jasper Deng:So, does that mean people are allowed to do so if the threshold is not met?W170924 (talk) 22:19, 24 September 2024 (UTC)Reply

• W170924, to give a current example, can I point you at Asian News International#Lawsuit against Wikipedia where you can see for yourself why editors would not want to be compelled to hand over personal info, and why the WMF would not want to be in possession of that info. Cabayi (talk) 11:22, 24 September 2024 (UTC)Reply

@Cabayi:It would be inappropriate for me to comment on the example as I am strongly biased being Indian. I will only say this: if that matter escalates, Wikipedia may lose all Indian editors in the process.W170924 (talk) 13:37, 24 September 2024 (UTC)Reply

Which is why editors shouldn't be required at all to submit personally identifiable information: nobody should be prosecuted. Aaron Liu (talk) 14:20, 24 September 2024 (UTC)Reply