Wikipedia talk:Signatures/Archive 14

This is an archive of past discussions about Wikipedia:Signatures. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 10

←

Archive 12

Focus on: non-Latin script

I want this section to focus on the use of non-Latin script in signatures. This could be a stylistic decision, or a reflection on the language spoken by the editor, or a way to indicate ethnicity, or a similar reason.

How does a signature with non-Latin symbols break current guidelines? Is forcing changes on an editor in this situation necessary? And how do we balance the right to use a first language with the guidelines on signatures and usernames?

doktorb _words^deeds 18:34, 26 May 2021 (UTC)

It is generally helpful to have a signature that has parts that others can ctrl-F for. And for non-Latin usernames, it is helpful to have a Latin nickname for the user. However, if a signature with non-Latin symbols breaks current guidelines, we should fix the guidelines, as there is nothing wrong with non-Latin symbols. —Kusma (Кузьма · कुस्मा · 𐌺) 19:00, 26 May 2021 (UTC)
I will personally fight until I am a bloody nub to prevent any policies that limit non-Latin characters anywhere in the interface.--Jorm (talk) 19:22, 26 May 2021 (UTC)
Non latin characters are fine, considering that many people's usernames are made of non-latin characters. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:30, 26 May 2021 (UTC)
I don't see any way in which non-Latin symbols cause any problems or break any guidelines. Take two example cases:

User:Example Hassan wants to also display the Arabic version of their name: حسن‎. They can have a sig: Example Hassan (حسن‎)
User:Example حسن‎ wants to also display the latin-alphabet version of their name: Hasan. They can have a sig: Example حسن‎ (Hasan)
And if User:Example حسن‎ just wants to display their username, then they can sign as : Example حسن‎

Where is the issue or problem that needs discussion? --BrownHairedGirl (talk) • (contribs) 23:12, 26 May 2021 (UTC)

The question is the other way, whether a user with a non-ASCII username can have an entirely-ASCII signature. This is more appropriate for Hebrew/Arabic/Indic usernames, but as an example; could I have lì in my signature in lieu of my username? (not that I would, but 等等) User:力 (power~enwiki, π, ν) 23:23, 26 May 2021 (UTC)

@力: I don't see that as a character set issue. It's just a specific instance of the general problem of some editors choosing to mislead their colleagues by displaying as their username something which is not their username. If the two don't match, then the problem is the non-matching, not the character sets. --BrownHairedGirl (talk) • (contribs) 23:30, 26 May 2021 (UTC)

And but this is why I think the consensus is not with you. You need to represent your name in your signature, not specifically your username. So long as Praxicidae and other active editors view everything ending with -cidae as Praxicdae's name, everything is fine. While I might support an RFC requiring an exact username (without HTML markup) in the signature text, I doubt it would find consensus. User:力 (power~enwiki, π, ν) 23:34, 26 May 2021 (UTC)

力: as i replied above, creating readily-avoidable types of "insider jargon" like this is a well-known type of barrier to new entrants. The very fact that you qualify your comments by referring to "active editors" describes a problem in the shape of an In-group and out-group. --BrownHairedGirl (talk) • (contribs) 23:42, 26 May 2021 (UTC)

This is correct, but as with everything, there are costs and benefits. Our jargon and our many implicit behavioural norms must be a nightmare to navigate for a newbie. That makes it good practice to avoid jargon, but forbidding experienced editors to use shortcuts when talking to each other clearly isn't an option. Enforcing uniform signature rules seems unlikely in my opinion to have a measurable positive effect on the editing environment for new users. Allowing people their small quirks seems more useful to me in welcoming a diverse editing community. I actually believe it is good practice to have the username in the sig, but I don't believe that requiring this is a good rule. Certainly enforcing such a rule is going to have far higher social costs than there are technical benefits. —Kusma (Кузьма · कुस्मा · 𐌺) 08:32, 27 May 2021 (UTC)

I am telling you, right now, that 100% of the data and studies that I have seen and personally conducted say the exact opposite of what you just claimed. Moreover, one merely needs to look at historical examples of how various communities have survived and thrived to see that.

Signatures and talk pages are the Number One barrier to entry for new editors. Everything else is a fart in the wind. Jorm (talk) 17:24, 27 May 2021 (UTC)

@Jorm: OK, I think I'd like to know more about what exactly you are referring to here (it is always good to learn when I am wrong). I know that talk pages are difficult (having to indent and sign manually is bizarre, not to mention that it is very difficult to even figure out where to discuss things. That article talk pages aren't a good place to talk about the article probably isn't obvious) but I'm intrigued to hear that they and signatures are more effective at turning away newbies than, say, seeing their 100% factual and accurate edit reverted because they did not cite a source and someone thought it might be vandalism. Or waiting 4 months for the AFC review of their article and then getting an incomprehensible "not notable" decline. Anyway, I'm getting a bit offtopic so if you want to reply on my talk page please do so :) —Kusma (Кузьма · कुस्मा · 𐌺) 18:20, 27 May 2021 (UTC)

This is totally a tangent but it's relevant to this discussion so I'll put it in here.

I dunno if you're familiar with who I am or my work in the past but for like five years I was senior designer at the WMF and my entire raison d'etre was talk pages and communication systems and editor retention. I have literally spent thousands and thousands of hours researching and watching how these things work on Wikipedia and across all its many languages and the difficulties inherent in there.

At one point I was structuring this problem in a "1 to 100" view, which was thinking about the edit count journey, the goal being to remove as many obstacles between a user making their first edit and their 100th (that being when we saw that being a Wikipedian either took or it did not take).

First, we need to distinguish between those we consider "constructive" users and those who are not. This has to do with edit motivation. It's not about vandalism - many, many great editors started as vandals. Think a POV pusher vs a gnome. A gamergator who is only here to shout "BIAS" isn't going to be constructive but they'll jump through hoops to figure out how to yell. We don't care about those people; they'll be blocked soon and never, ever become productive. So we focus on people trying to help.

The first and largest obstacle (edit "zero") was even knowing that it was possible to edit the encyclopedia. The second largest was finding something to fix. The third largest to edit zero was finding the edit button. Parsing wikitext was surprisingly not difficult (and anyone who says "women don't get it b/c they're not technical" is a fucking idiot because at the time we were doing these studies women made up like 75% of the blogger population and blogging software sucked).

Anyways: getting reverted is not the killer to productive editors. People are good with that. They don't mind it. At first, they are really worried that they are doing something bad, or going to harm the encyclopedia. They will often try to find out if they're doing bad by looking up stuff on their own but that's rarely useful. It is important to understand that at this point in their heads, Wikipedia is still a "system" or a "program" and decidedly not a "community".

Usually it was around edit number 10 than a new user comes in contact with another Wikipedian. It is at this point that they learn about the existence of talk pages and have to understand how to use them.

(Side note that the Mobile Interface is a terrible travesty and should be burnt with fire. Mobile does everything in its power to hide the existence of talk pages, and new users never, ever understand pings or see "you have new messages" and interpret that correctly. So there's that to chew on.)

(I could fill the Mariana Trench with things that can kill a user at this point, mostly about templates and the like, but we want to stay looking at the software)

Talk pages, even though they are the exact same software as the editor, are bafflingly hard to use. They have so many counter-intuitive systems and broken metaphors that new, productive users splatter against them and are ground to a paste. This is, without a fucking doubt, the single largest hurdle to gaining and keeping new users.

Talk pages do not resemble any other communication method in use in any other software ever written in reality or fiction. There simply is no mental model that they can be mapped to in order to increase the likelihood of understanding. There is never a "oh, it's like email" or "oh, it's like instant messenger" or "oh it's like a forum" or "oh it's like talking to R2-D2" moment.

This is because of a shit ton of reasons which are really obvious but the number one - with a bullet - most confusing thing to any new user is the signature. Why is the signature different between these two people? Does that connote status, or permissions? What do the red ones mean? Are those moderators? What's "contribs"? Why is it at the end of the comment? Why isn't it called out more clearly?

That's before they even open the editor. That's just reading. This has an incredibly high kill value. Users find the signature system so utterly confusing that they decide that they don't want to have anything to do with these crazies. Right here. This is the point of inflection.

Let's say they get past that, though. Let's say they think "oh, there's some code to this, and I don't understand it now, but I'll figure it out later." (I know that's how it was for me).

If they then manage to figure out how to edit the talk page (and holy shit do not get me started about how shitty Monobook and Vector are with regards to that discoverability but spoiler it starts with "why are there two selected tabs") - if they manage to even get into the technical side of the conversation, there will, indeed, be an "ah-ha!" moment because they will see that it is "like editing the page" so that's good at least but then we come to Wile E. Coyote's Wild West Fun Ride and all of the misery inherent in trying to figure out what the colons mean or stars and what's the fucking difference between wait what the fuck this is a hashtag now? And all this is before we even have to read, parse, and sign the post.

(This is a very high kill ratio point; roughly half of the people just stop right here. They close the window and move on.)

Most people assume that the software will sign the message for them. Because why wouldn't you? Every other software in the world signs posts for you automatically. (Take a look at the number one bot with edits and you'll see that it's SineBot. That should tell you something right there.)

Watching someone discover that Wikipedia doesn't automatically sign their posts is soul-crushing thing to watch. It's just the Price Is Right's sad trumpet noise on repeat.

Okay so now they know they need to sign their posts. Usually because a "helpful" Wikipedian yelled at them.

The most common thing people do in this case is scan backwards and look for wikitext that most resembles what they think is a "signature" (and the key marker here for nearly everyone is actually the "--") and then cut and paste that and make changes. They get this part right a lot, actually. But no one - no one - knows to type ~~~~~~~~~~, click the "signature" button (because of ton of reasons, not the least of which is that the icon is terrible), or read the "Remember to sign your posts" message (This knowledge doesn't creep in until around edit 75 or so).

(And yeah, before some jamoke comes in and says "I figured it out right off it was easy" yeah yeah yeah tell your story walking maybe get a cookie or something yer a fuckin' geeenyous" <wank motion>)

Anyways. They're scanning for a signature to copy. Finding one is also incredibly difficult because in Wikitext Mode they're a blob of gobbledygook. So what they do now - always - is try to search for a User Name that they recognize.

It is at this point, nearly every time, that people quit. They just throw their hands in the air and walk away, never to return. It had a kill ratio of something like 97%. It's probably worse now.

So the tiniest of changes here - the absolute smallest of consistencies - will reduce that kill ratio by a lot. We need to be doing absolutely everything we can to reduce this kill point.

The tiniest thing we can do right now is enforce signature readability while the user is first encountering talk pages (also make all user page links blue, regardless of whether or not there is a page there).

It has to be the community that fixes this. You cannot count on the WMF ever doing anything for this. You cannot say "oh, there's a gadget". You must always assume the user has a stock system with Vector and Vector is terrible and a source of Many Woes. The Foundation does not have the courage to push software changes to fix it. It has to be the community.

(Another thing that could be done locally is move the signatures to the top of the posts with some clever css. Maybe I'll get high one night and write that; see if I can get it to work.) Jorm (talk) 19:27, 27 May 2021 (UTC)

Thank you for sharing your perspective (and for your work), this is full of great points to think about. I never thought about newbies believing that signature colours could mean something (fancy sigs only just started to become fashionable back when I was a newbie), but now that you point it out it seems very reasonable. I have now changed my signature back from something mildly clever to something rather plain. From your description of a newbie's journey above I infer that custom colours, signatures not matching the username and irrelevant fanciness all cause problems for newcomers, and while I disagree that newbie conversion rate is the only number for us to look at, a campaign for simpler signatures ("do it for the newbies!") could actually be helpful. If 90% of users have plain blue signatures, do you think that will help? —Kusma (talk) 20:57, 27 May 2021 (UTC)

Will 90% solve the problem? I don't know. It would have to be studied, maybe. it definitely won't hurt, and it will almost certainly help but I wouldn't think it a silver bullet.

There are a lot of things that can be done. A good thing would be for there to be an obvious visual marker (like an icon) to tell the user that they are looking at a signature. Most software uses an avatar image for this, but Wikipedians go apeshit if you suggest such a thing. There might be a way to inject an icon visually using a :before css rule or something.

Moving signatures to a consistent spot is probably the best thing to do. That would aid in scanning and recognition of the affordance as well as aiding the user to neural map that they're looking at a conversation. Jorm (talk) 21:18, 27 May 2021 (UTC)

I've made a tree-hugging hippie proposal at WP:VPR. —Kusma (talk) 22:22, 27 May 2021 (UTC)

It's a reflection on changing times. Signature files come from a Usenet/email/Unix tradition, and is a place for creativity; however with Usenet/email, the actual username is conveyed separately in metadata to establish identity. Today, web-based bulletin boards and social messaging apps are widespread methods for group conversation, where colour and icons associated with the user name can carry meaning. As Levivich alluded to earlier, if we want to mandate that certain information be associated with each signed post, then it would best for the software to provide the info, or provide user interfaces or tools that provide the needed functionality. (For example, in addition to the pure wikitext methods of pinging, we could also have tools allowing you to look up users to ping using auto-complete, so you'd never have to copy and paste a whole user name. If the software were extended to support an alias as part of user profiles, then you could search users by alias, too, and users could set it to match their signatures.) Of course, in the meantime, it may be desirable to provide more encouragement to follow specific conventions. isaacl (talk) 22:01, 27 May 2021 (UTC)

A thing to think about when making comparisons to Usenet or Email is that people read posts there already knowing who the sender is. You know who is speaking before you reach the signature.

Further, the way quoting in those mediums works also lets the user know who is speaking before the gist of the message. Jorm (talk) 22:31, 27 May 2021 (UTC)

Yep, as I said, in all of the other methods I listed, the username is conveyed separately, and as you've noted previously, in standard locations where it's easily accessible before reading the message. If the reply tool from the talk pages project becomes sufficiently popular, then it may become possible to associate more metadata with each comment and provide greater functionality. isaacl (talk) 23:29, 27 May 2021 (UTC)

I'm curious as to if you have a study that says custom signatures are the number one barrier? It seems more likely to me that 1) the study likely didn't differentiate between different problems with signatures, and 2) if it did, it's probably having to manually sign at all that's the problem - along with having to indent manually and things like that - not the fact that some people have customized ones. But again, curious if you can link to the study so we can see for ourselves. -bɜ:ʳkənhɪmez (User/say hi!) 18:42, 27 May 2021 (UTC)

To a new users there is no difference between a custom signature, a red signature, a blue signature, or any other signature. They are all an impenetrable code. They do not care because there is no consistency.

I don't work there anymore and the last time I tried to find any of my research or anything it had been moved or deleted or whatever. You need to understand that I'm talking about a lot of studies and questions, many videos and observations. Statistics grinding. There was a whole team at one point who would answer questions like this.

I know for a fact that the distinction between customized and non-customized signatures was explored and researched because one of the things I was excoriated by the community for was saying that custom signatures were not going to appear in Flow. There were many reasons behind that (and I talked about that just above). Jorm (talk) 19:40, 27 May 2021 (UTC)

By the way, even if I dropped seventeen gigabytes of studies about this on your lap, it wouldn't mean shit. The community has never cared about what data has to say about these things. It only ever looks for reasons to ignore findings and keep doing what it's doing. Jorm (talk) 19:43, 27 May 2021 (UTC)

Jorm, well, I care. And I know we don't agree on everything here, but I'd certainly like to see the evidence for what you're saying is true. Something not appearing in a planned feature doesn't mean it was actually studied - if it was, you should be able to show us the result that says custom signatures specifically (not just the quad~ markup) is a barrier to entry for new folks. I think you'd sway a lot of people away from custom signatures if you could actually show a study that shows it's a barrier to entry - many people do care what the new user experience is like, and in fact I've done what I can to make it easier for new folk - and if well-done studies show that custom signatures (like mine) are a barrier for them, then dog-gone it I'll remove mine (or at a minimum I'll put the default Username (talk) back at the beginning). -bɜ:ʳkənhɪmez (User/say hi!) 19:47, 27 May 2021 (UTC)

Quod est demonstratum. Jorm (talk) 19:48, 27 May 2021 (UTC)

You've demonstrated nothing, and you still haven't linked the study. If it truly exists as you're claiming, it should be trivial for you to find and link it. The fact you're refusing to do so (when you've had more than ample time) and instead trying to paint me as the bad guy doesn't help your case here. -bɜ:ʳkənhɪmez (User/say hi!) 19:49, 27 May 2021 (UTC)

I just told you that all that shit was deleted or moved, or it was never made public, or a million things. You are demanding that I produce some magic fucking artifact before you will even consider the idea that you are wrong.

I haven't worked there in six years. When I did, I had to be your work monkey. I'm not anymore. Jorm (talk) 19:52, 27 May 2021 (UTC)

It's quite odd to me that the WMF, an organization based on transparency and open access to information, would intentionally delete data that's relevant to its projects. But I accept that since you don't work there anymore it may be harder to find for you. Showing the actual study that said that custom signatures instead of default was a barrier to entry would sway at least one mind (mine) and I suspect quite a few others. So if you really want to sway minds, that's the way to do it - not just saying "believe me when I say it is so". Maybe someone else will just take you at your word with this - but in my field, we don't believe until we see with our own eyes. -bɜ:ʳkənhɪmez (User/say hi!) 19:56, 27 May 2021 (UTC)

You think the WMF is transparent? My sweet summer child. Jorm (talk) 19:59, 27 May 2021 (UTC)

Generally it is because of attitudes like yours that the WMF has such a bad reputation amongst users here. So if your goal is to distance yourself from them, you are going the wrong way about it. Either provide the details requested above or cease the bloviating. Only in death does duty end (talk) 19:02, 28 May 2021 (UTC)

I'm going to clock in for a few minutes and respond to a few things here, since I have some information.

@Jorm said earlier "This is a very high kill ratio point; roughly half of the people just stop right here. They close the window and move on." If you look at the number of people who open the wikitext editing window in a discussion namespace vs the number who post a comment, I believe it's more like three-quarters of new editors, at least if they open the entire talk page rather than a section. (Accurately detecting a reply vs non-reply edit inside a section turns out to be harder than a non-MediaWiki dev would expect, especially when most of them don't sign their posts.)

If you are interested in re-arranging the page with CSS, I think you can hope to achieve ~99% success. The mw:New requirements for user signatures work is slowly improving matters, and the mw:Reply tool (try it now!) only fails to detect a signature in about 1% of edits.

@Berchanhimez, "the data" is video recordings of humans trying the software. Back when most of that research was done, the WMF didn't usually get permission to release the individual user testing videos. So you can't have all of the raw data, because privacy. However, you can have some of it, such as this screencap recording in which a new user says things like she can't figure out who wrote anything on the talk page or even be certain what the talk page is for (around the 7-minute mark). Notice that she is only reading the page at that point; there cannot be any question about how many tildes to type to create her own signature, because she is just reading the talk page at the point that she says she can't figure out who posted the contents.

Unrelated to the raw data-vs-anonymized reports question, a few years ago, they set up the corporate cloud to auto-delete everything six months after an employee quit (unless there was manual intervention, which pretty much only seemed to happen for Legal and HR). It's arranged better now, but, due to one of those unfortunate who-left-when happenstance things, a good deal of design research work seems to have gotten lost, and that's not counting the stuff that never made it into the cloud in the first place, which included pretty much all of the original user research data from a decade or more ago. I think that nearly all of the original data collected by Steven Walling and the old mw:Growth team was lost to the "dusty hard drive" problem, except for content that was uploaded to Commons or posted on the wikis.

BTW, I think you can rely on Jorm's recollections. I've never known him to be dishonest, and he's been saying the same things about these studies since they happened. (Caveat: You should not trust him on the question of whether Chili con carne should be served with rice. ;-) Whatamidoing (WMF) (talk) 00:22, 13 June 2021 (UTC)

Back to the original subject

Both these sections - and any more I think of starting - were intended to streamline the discussion into manageable chunks, given that the above conversation is such a sprawling mass of threads and tangents. I think that having focused sections helps in deciding what is working and what is not. As detailed in this section, above, we can see how having hard and fast rules about non-Latin characters is a non-starter. I like Kusma's line about enforcing hard and fast rules will have a "far higher social cost than...technical benefits". As ever throughout this discussion it is clear that the winning argument, the stronger argument, is with those of us who don't agree that the guidelines should force all of us to have the same drab boring generic signatures. doktorb _words^deeds 09:08, 27 May 2021 (UTC)

I don't think anyone's seriously proposing removing the colour and fonts and HTML code from signatures and forcing everyone to use the default signature, which I've managed for five years. Adding two letters to a signature should not be that big a deal. If editors are after a bit of pizzazz and individuality, they can achieve that very easily through HTML (and frankly would be far more successful). Sdrqaz (talk) 08:58, 28 May 2021 (UTC)

As someone with a non Roman username, I am against anything that would require me to display Roman transliteration in signature. That would more confusing to new users as to which one is the actual username, confusion when pinging and the like. I spend most of my time on Wikipedia fixing Lint errors, which among other things involves fixing bad html in signatures. See the stats in Firefly Linter count. Most of the Lint errors in discussion namespaces are because of signatures. Custom signatures cause unnecessary maintenance overhead in future, so I don't use anything other than the default signature. Anyone curious about how to pronounce my username can see it in my userpage. Link to talk page will be in English, so no problem if anyone wants to communicate. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 12:59, 29 May 2021 (UTC)

The focus here was on the opposite concern: if we require the full username to be present in a signature, won't that create problems with non-Latin usernames, such as it being hard for other users to keep various users with the same non-Latin scripts apart, or such as that other users won't know how to address them, etc. (it's largely a non-problem though, since requiring the full username doesn't entail disallowing extra text containing a Latin-script nickname; the main thing would be that they would perhaps not always have the necessary space to include the username along with the nick) Those who argue that such problems will arise actually want to be less restrictive, i.e., they want to allow all kinds of variations instead of the username, not require them. ☿ Apaugasma (talk ☉) 19:25, 29 May 2021 (UTC)

DOS attacks?

Perhaps Redrose64 would like to give a substantive reason for their revert per WP:PGBOLD (Consequently, you should not remove any change solely on the grounds that there was no formal discussion indicating consensus for the change before it was made. Instead, you should give a substantive reason for challenging it and, if one hasn't already been started, open a discussion to identify the community's current views.), however, more importantly I'd like to see a diff from a WMF sysadmin saying that images in signatures constitutes unbearable load for the WMF servers and are akin to DOS attacks. The claim appears highly dubious at best. ProcrastinatingReader (talk) 20:47, 2 June 2021 (UTC)

While I no longer work for the Foundation, when I did we had a policy (if unwritten) that local Wikis should not make policy decisions based on expected load.

Technically, an image in a signature will not affect the servers much (if at all); the server sends the HTML for the link, the slow-down is going to be on the client side (rendering lots of images, especially if the html for the image doesn't include height and width tags). Emoji images are... nothing. They're air. The client and the server won't care in any way about them. Jorm (talk) 21:22, 2 June 2021 (UTC)

Re first sentence, I think there's also an equivalent community essay at WP:PERFORMANCE. A sound principle IMO. ProcrastinatingReader (talk) 21:27, 2 June 2021 (UTC)

Client-side performance and bandwidth usage should be taken into account, though. Trimming down the number of server requests is important for responsiveness, and reducing the amount of data transferred is helpful for lower throughput/capped data environments. (I realize this does not apply to the specific edit in question, but would be a new reason to add to the rationale.) isaacl (talk) 22:44, 2 June 2021 (UTC)

Honestly the real killer here is going to be someone linking a 50 megabyte file in a 32x32 pixel square. --Jorm (talk) 22:56, 2 June 2021 (UTC)

It's an established principle that you don't make unilateral changes to agreed policies. You discuss them first, either on the associated talk page or at WP:VPP. Whichever venue is selected, you should ideally leave a note at the other one directing people to the discussion. When the policy change is agreed, the change may be made, and the edit summary should include a link to the discussion concerned. Notice how in this edit, HJ Mitchell (talk · contribs) used a URL (now archived to Wikipedia talk:Signatures/Archive 9#Promotion to policy). That edit was made more than seven years ago, and whilst the two templates preceding the line "Images of any kind must not be used in signatures for the following reasons" have both been amended since then, the eight-point bulleted list following has not changed by even one character. Indeed, one of those two templates explicitly states Changes made to it should reflect consensus and I saw no consensus for ProcrastinatingReader's edit. --Redrose64 🌹 (talk) 23:32, 2 June 2021 (UTC)

Your assertion directly contradicts the community established policy at WP:PGBOLD. Although most editors find prior discussion, especially at well-developed pages, very helpful, directly editing these pages is permitted by Wikipedia's policies. Consequently, you should not remove any change solely on the grounds that there was no formal discussion indicating consensus for the change before it was made. Instead, you should give a substantive reason for challenging it and, if one hasn't already been started, open a discussion to identify the community's current views. The claim -- that images in signatures will DOS the WMF servers -- is just not true. ProcrastinatingReader (talk) 23:47, 2 June 2021 (UTC)

Since you have been quoting from PGBOLD (twice now), you will also be aware of WP:TALKFIRST, which precedes it on the page: Talk page discussion typically precedes substantive changes to policy. Changes may be made if there are no objections or if discussion shows there is consensus for the change. Minor edits to improve formatting, grammar, and clarity may be made at any time. Your edit was not made to improve formatting, grammar, and clarity, it was a substantive change to policy. This subsection begins with a link to Wikipedia:Be bold#Wikipedia namespace where we find: Wikipedia does not "enshrine" old practices: bold changes to its policies and guidelines are sometimes the best way to adapt and improve the encyclopedia. In this case, "bold" refers to boldness of idea; such ideas are most commonly raised and discussed first to best formulate their implementation. The admonition "be careful" is especially important in relation to policies and guidelines, where key parts may be phrased in a particular way to reflect a very hard-won, knife-edge consensus—which may not be obvious to those unfamiliar with the background. In these cases, it is also often better to discuss potential changes first. So: suggest a change by all means; but if you do make an undiscussed change, don't expect there to be no objections, and when an objection does occur do not word your counter-objection in a way that implies that the objector (me) is in the wrong. --Redrose64 🌹 (talk) 07:37, 3 June 2021 (UTC)

Technical note, it is not just about the servers. Users without much ram may experience issues rendering on their browsers also. Pages with hundreds of small images can grind a browser on a low resource system to a halt. HighInBC ^{Need help? Just ask.} 23:50, 2 June 2021 (UTC)
I agree, and I mentioned this here, but issues for certain users due to their device capability or internet speed/reliability (something not mentioned in the current list, but probably should be), is distinct from the alleged damage to WMF servers, currently mentioned in the list. ProcrastinatingReader (talk) 00:04, 3 June 2021 (UTC)
In the context of Wikipedia, denial-of-service refers to the ability to misuse MediaWiki features to unduly waste server or network resources. For example, we used to be able to view up to 5000 contributions for an editor, but that was reduced to 500 to avoid DOS attacks. Similarly, Lua modules are limited to 10 seconds and 50 megabytes. Those limitations are imposed by the WMF but I guess that whoever added the DOS rationale for no images had that in mind because replacing an image with a massive file then purging a hundred pages would degrade services. Johnuniq (talk) 09:19, 3 June 2021 (UTC)
The key here seems to be "expected load". Forums that allow custom images in user profiles on posts generally display about 20 at a time (by default). Wikipedia, on the other hand, has talk pages with hundreds of unique editors having posts that haven't yet been archived. Some pages (certain RfAs) have over 500 unique signatures. Imagine if all of these users had a picture in their signature. That's no longer "expected load" - that's insanity in my opinion. And yes, unless any image used in a signature was automatically protected, it could be a way for a denial of service attack. Just upload a much larger file in the place of one that's used in a signature, and instantly increase server load anytime anyone loads a page that user had ever signed. Do that enough, and it would potentially overload the connections and cause a denial of service. Furthermore, while colors can give the appearance of prominence, images can imply more prominence - as an example, a user recently attempted to add the WHO flag to their signature. That's more prominence than any set of colors could ever give. While I agree with the fact that we shouldn't worry about performance, that doesn't mean we can't include that as a reason images aren't allowed - it just means that if it were the only reason, we should reconsider. I disagree with the changes made and think the policy is fine as is. -bɜ:ʳkənhɪmez (User/say hi!) 08:11, 3 June 2021 (UTC)
$300 million and we're worried about server load from images in signatures? Ahem. I just want to remind everyone reading this that for many years, other websites like Facebook and Twitter (and MySpace and Geocities and Wordpress and so many more), have been able to allow their users to post images, even in hi-res, even embedded video, even with infinite scrolling, for millions of simultaneous users, without crashing their servers or their users' browsers. The technology has been out there for many years; we're using sticks and stones here (aka MediaWiki). (And I agree with the removal of the server load and DOS reason.) Levivich 16:00, 3 June 2021 (UTC)
There is a somewhat related problem described on mediawiki.org’s Recommendations for mobile friendly articles on Wikimedia wikis § Limit number of images in a page:
Ideally, a page should have no more than 100 images (regardless of how small). Note if you have more than 10,000 images in your page, the page will be inaccessible on mobile.
I believe this number is counting image tags (file declarations), and not separate images. stjn 20:54, 3 June 2021 (UTC)

Accessibility concerns

For all the recent talk here, I could find only one mention of web accessibility on it. I believe this issue needs more exploring, the notes below attempt to do so. Some of the notes below are directly inspired by signatures/discussions here, but I made an effort to not name and shame anyone. (Note about words: ‘users’ in the following text means everyone, and not just registered users.)

For colour-blind users and users without an ability to use the mouse, having a consistent and distinctive colour for links is critical because Wikipedia is only distinguishing links by their colour. Without actions like hovering, the only colours for this to our users are blue and red. User signatures usually use more colours, so if the only signatures on the page are custom, some users might not be able to tell that you can go to a user/talk page. This is especially bad for links that are in black, as that makes them indistinguishable from the page text colour. That means that a custom-coloured user signature should have some other way of recognising it as a link, specifically an underline. Not having one on those links is an accessibility violation (link to WCAG 1.4.1 info page).
Similarly, blue or red should not be used in a signature for text as a courtesy to keep the expectations of users consistent and to stop people without a mouse from expecting it to be a link.
For colour blind users, if a link employs a background colour (also known as highlighting), the contrast of link text needs to be checked with a background colour, as already described by contrast guidelines in the Manual of Style.
For screen reader users and users without an ability to use the mouse, custom signatures frequently do not describe the link targets understandably without having to hover or inspect their URL. This is an accessibility violation (link to WCAG 2.4.4 info page). All links in a signature should a clear description of their purpose, so while u-t-c meaning links to ‘user’, ‘talk’, ‘contributions’ might be understandable at least to some from the link context, it is pretty much impossible that ‘clubs symbol’ and ‘spades symbol’ would be understood as ‘contributions’ and ‘email this user’.
For screen reader users, but not limited to them, the previous point also means that if a user goes to the link saying ‘wingardium leviosa’, but arrives at the user page of a user called ‘Stream Levitating by Dua Lipa’, they might be a bit confused about whether they were lead to the right page. While some changes to them can be fine, user links should not be entirely different from their username (‘Kendoll’ → ‘KenDoll’ is fine and might be actually preferred for screen readers, ‘Kendoll’ → ‘KENSINGTON DOLLARBILLS’ or ‘ꓘ∈И’ are not), unless you also insert the username, preferably somewhere in the link itself.
For screen reader users, the most problematic custom signature would not be the one using non-Latin characters (or at least it shouldn’t be one using them), but the one employing many graphic symbols or various text substitute symbols. Accessibility expert Adrian Roselli describes how misuse of some Unicode characters imitating the various typefaces (usually valid for use as math symbols etc.) can be harmful for screen reader users in tweets, but it applies to us as well. (While there are no uses of this on this page, I have noticed some on village pumps.) More generally, use of various Unicode characters will either lead to your signature being too verbose (as in the previous link) or lead to it not being read out for some at all. Accessibility expert Leonie Watson tells that this can be the case for emojis.
For users with low vision, as well as anyone increasing standard font size, signatures should have any text size changes relative to the original font size, as already described by text size guidelines in the Manual of Style. 16 out of 66 uses of font-size (thankfully, by just one user) on this page make it harder to increase font size of their signature to readable levels, with the same signature also having a smaller font size than is recommended there as a baseline for content.
For users on autistic spectrum, it is sometimes recommended to have simple and consistent layouts that use simple colours. We need the opinion of those users to know for sure whether they had issues with the way our talk pages are structured to know more, but it is something to keep in mind.
Not in English Wikipedia, thankfully, but for wikis generally: images should have alternative text, especially if they link to other pages (including file pages). If they link to other pages, alternative text should describe the purpose of a link, for example |alt=Talk page.

There might be more issues that might be listed, these are just the ones that I can remember off the top of my head. Some issues above can be fixed in some cases if users applied more WAI-ARIA text in their signatures, used underlines in their links, did not abuse Unicode symbols, etc. But I think that having those issues in the first place is a strong argument that if you want your signature to be inclusive and accessible (as, I think, most of us should), you should just keep it simple and straightforward. And I hope that this write-up will persuade at least some to do so. (And I sure hope that no one thinks that these are the issues that needs to be fixed by the users that experience them, and not us.)

For years, I have used a user script unformat.js (links to Russian Wikipedia) that removes most of the custom signature code for me, leaving only their text. To be honest, I have made it not because I wanted our talk pages to be more accessible, but because I considered most of custom signatures ugly and attention-seeking. Now I am more and more of an opinion that the best way forward is the opposite: to have some means for Wikimedians to customise signatures without them showing up in page code and without the explicit consent of a user. There must be some ways to write a script for that.

(Please ping me when replying to this section.) stjn 20:54, 3 June 2021 (UTC)

For the lack of anything better to say, this, times 100. I like the idea that custom signatures ought to be an opt-in enhancement, maybe a gadget. I'm envisioning a world where custom sigs are an opt-in preference, but we opt in every existing account. Logged-out users shouldn't see them. Enterprisey (talk!) 22:00, 3 June 2021 (UTC)

I wrote up User:Enterprisey/signature rfc drafting. Probably a dead-end but I hope it moves the conversation forward. Enterprisey (talk!) 22:34, 3 June 2021 (UTC)

Yes! And thank you for writing this. Aesthetic preferences might be important but accessibility must be the Foundation's #1 priority. Le Loy 01:13, 5 June 2021 (UTC)

I agree that it'd be a good idea to give all users an option to view all signatures with plain formatting, and I even think that making custom sigs opt-in would be mostly fine. That said, as someone to whom the above accessibility concerns apply, I can say confidently that I don't give a hoot about what color someone's talk page signature is, or if the font is ugly, et cetera. I may think less of their graphic design skills, but it certainly doesn't bother me to the extent that I think they should be forced to express themselves in a way I find acceptable. jp×g 02:03, 6 June 2021 (UTC)

Text for not having images

Can someone explain this text to me? Given that here we give people the exact CSS needed to make an obnoxious orange signature, and here the CSS for obnoxious purple signatures. Perhaps we should extend the policy to username colours too, such that colour may not be used to give undue prominence to a given user's contribution ProcrastinatingReader (talk) 08:21, 2 June 2021 (UTC)

As with images, there are an awful lot of people who talk about bright signature backgrounds being obnoxious/distracting/whatnot, but when it actually comes down to an RfC people seem loath to prohibit much of anything. If anything, we should ditch orange/purple examples. Just because there's not an appetite to prevent it doesn't mean we should encourage it. — Rhododendrites ^talk \\ 12:54, 2 June 2021 (UTC)

Yes. Maybe we can give examples in a different font, or in dark green or something, but nothing that is super flashy. PR's second example, however, is about user CSS, which is a topic that might be better to be covered elsewhere altogether. Perhaps the "Customizing how you see your signature" and "Overriding custom signatures" should be moved to the bottom of the page, or to a different page altogether. (This page needs to decide whether it is a guideline or a howto). —Kusma (talk) 13:08, 2 June 2021 (UTC)

While I agree that people should be able to set an option in their preferences to see plain signatures, I nonetheless resent the implication that my signature is "obnoxious".

.

^×158
.x88888x.

:8**888888X.  :> .d`` uL ..
f `888888x./ @8Ne. .u .@88b @88R uL
' `*88888~ %8888:u@88N '"Y888k/"*P .ue888Nc..
\. . `?)X. `888I 888. Y888L d88E`"888E`
   `~=-^ X88> ~ 888I 888I 8888 888E 888E
   X8888 ~ 888I 888I `888N 888E 888E
488888 uW888L 888' .u./"888& 888E 888E
.xx. 88888X '*88888Nu88P d888" Y888*" 888& .888E
'*8888. '88888> ~ '88888F` ` "Y Y" *888" 888&
   88888 '8888> 888 ^ `" "888E
   `8888> `888 *8E { u s e r } .dWi `88E
   "8888 8% '8> { t a l k } 4888~ J8%
   `"888x:-" " { c o n t r i b s } ^"===*"`

05:42, 6 June 2021 (UTC)

Surely if you're making an audacious joke sig, it should have user rights in it too? Vaticidalprophet

x9 EM MM Rv ECo 05:48, 6 June 2021 (UTC)