Topic on Talk:New requirements for user signatures/Flow

A few existing (and not blocked) editors probably have signatures that don't meet these criteria. The current proposal is to ignore those signatures. Do you think that's a good idea?

Opinions I've personally heard so far are:

• Leave them alone
• Leave them alone now, and remove them later (maybe next year)
• Remove them later

(If your signature got removed, then the software would use the default sig instead.)

What option do you prefer?

Leave them alone for now. Notify editors with invalid signatures, and set a fixed date after which their invalid signatures will be replaced with plain uncustomized signatures.

Before doing this, make sure that resources are available to enforce each of these steps.

I like this idea. Basically phase them out. Start by forbidding new invalid signatures, put warnings in preferences for old ones (alongside maybe site notice / watchlist notice for logged in editors with custom sigs / invalid sigs) and give some time for people to voluntarily update. Then after 3/6/12 months, kill the stragglers.

I'd say don't invalidate them. Why force people to change if they don't want to?

Re "Why force people to change if they don't want to?"

Because every time someone adds an invalid signature to a talk page, it creates a new error that someone else will later need to fix.

Support idea but be cautions. I'm copying a copying this edit here where it belongs:

Great idea, but allow projects and third-party users of MediaWiki software to opt out. For example, if the English Wikipedia or WikiData or some third party web site that uses the software wants to keep the current behavior, they should be able to do so. For community-run Wikimedia projects, it would presumably be a community decision to accept any software that imposed requirements stricter than existing ones. For the English Wikipedia and others where the software would merely be enforcing the existing requirements, this change should be accepted as routine. I say it should be routine for the English Wikipedia, if any existing users have grandfathered-in exceptions that would break under the new code, then an en-wiki discussion would have to be held before accepting the changed code.

Davidwr (talk) 18:37, 4 March 2020 (UTC)

Are you aware of any community that prefers looser requirements than these? (These changes are less restrictive than the English Wikipedia's.) Most small wikis don't bother writing rules about signatures, but if any community actively prefers something different from this, then I'm sure they'd want to accommodate them, too.

(Changes to MediaWiki core (which this is an example of) are the purview of the MediaWiki community, rather than any of the user communities.)

I am not aware of any. However, announcing it on each project's equivalent to the English Wikipedia's Village Pump or Centralized discussion should give you an answer in short order if the answer is "yes." Davidwr (talk) 20:03, 4 March 2020 (UTC)

i honestly have no idea why.... people can fork the software if they want to maintain something difficult for their own enjoyment.

It usually causes less hassle to let the projects make their own choices rather than having changes thrust upon them. Even with things that are an obvious improvement to most people. If they really are an improvement, the projects will probably accept them

less hassle on who ? Im hassled as a dev every week by having to account for everyone wanting their own little sandbox to play around in.

Just because people dont experience my hassle nor rly care about the sanity of their developers. Its a world of two truths. We just need to decide which one is more important.

Less hassle as in less pushback from those people who will get the impression that this is another thing that WMF has arbitrarily decided they will have whether they like it or not.

If you are saying this is a thing that is broken and must be fixed, produce a convincing explanation of what is broken and why it must be fixed. The communities are more likely to accept the proposed solution if it can be shown to be both necessary and desirable.

I personally don't see any need for fancy formatting of sigs at all, and would not have a problem with default only, but I may be in a minority on that point. All I look for is the ability to easily spot my own sig on a page without having to do a search, which can be done by highlighting.

Here's a demonstration of what an unclosed font tag, an unclosed s tag, and an unclosed pre in a signature can do to a talk page:

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox3&oldid=944557608

This is a dramatic example, but unclosed tags exist in WP by the millions (literally; see https://tools.wmflabs.org/fireflytools/linter/enwiki for a count that is a lower bound due to undercounting), and they break the formatting of talk pages.

Give users with grandfathered signatures a limited time to change their signature to a different non-compliant signature. You don't want everyone trying to "get in under the wire" though, so limit this "limited change window" to people with non-compliant signatures by some cutoff date, say, March 1, 2020. Davidwr (talk) 18:40, 4 March 2020 (UTC)

I agree with Davidwr: Notify editors with non-compliant signatures and allow them a limited amount of time to modify it. I don't think it makes any sense to allow them in perpetuity. (adding manual timestamp since sig isn't working) Schazjmd (talk) 19:12, 4 March 2020 (UTC)

@Schazjmd: To clarify: The proposal on the table says editors CAN keep a non-compliant signature in perpetuity, which I agree with. My proposal goes further and says that IF you have such a signature today and the software will change, say, in June, you will have a few months, say, until the end of the year, to change it to a different non-compliant signature without the software stopping you. After that, you can either keep the one you had at the end of the year or change it to a compliant one.

Of course, some languages and some projects may prefer the proposal as-written, in which case the this additional leeway can be disabled.

Thanks for the clarification, I did miss that subtlety. My opinion is the same, it's just not the same as Davidwr's. :) ~~~~

@Davidwr: I think disallowing to set a non-compliant signature should happen in one step. It’s highly confusing if a user complains that they can’t set a non-compliant sig, and another user answers they can. As for the disabling existing non-compliant signatures: I support having a notification (e.g. using Echo) and giving users some time, probably a month or two. I don’t think the past cutoff date is important as long as the non-compliant signatures will be disabled anyway (and especially if even non-compliant ones can be changed only to compliant ones after deploying this feature); but it doesn’t seem to be possible, either—I don’t think the date when a preference has been set is stored anywhere, so it cannot be queried whether this date is prior to March 1.

@Tacsipacsi - if the choice is limited to the three things in the list, I would say that on the projects I participate in heavily (English Wikipedia and Commons), "leave them alone" then wait a year to see if it's a big enough problem to force grandfathered users to change their signatures.

I agree with the others (not David) in favoring something like option 2, with notification/warning on talk pages or similar. I am 0% a fan of "never change/remove these". I am a fan of 6 months to a year, but one to two months is also reasonable. No more than a year of grandfathering, however.

In any case, a notification for affected users would be beneficial. (I think the vast majority of the affected users have non-compliant signatures by accident, so notifying them would probably significantly drop the count of non-compliant users.)

Warn first, then if still not valid, reset them to the default signature instead of them having a custom signature (also do this for 'no longer active' users).

@TheDJ, have you thought about how to identify who to notify about non-compliant sigs? Most editors are inactive, so most invalid sigs are likely to be inactive, so I don't think we want to notify everyone with a non-compliant custom sig somewhere in the database. If we could get a list of active editors with non-compliant sigs, it might be possible, as @Tacsipacsi suggests, to use Notifications to alert them. Otherwise, we could send MassMessages to their user talk pages (SUL-style).

I got bored today and wrote a script to go through the signatures of enwiki editors that have edited in the last and approximate the proposed new rules. It identified 8308 editors with problematic signatures, but I know that there are false positives and false negatives in that dataset. The most common error is not linking to a user page, with 7193 problematic signatures. Most of these errors are caused by editors ignoring the warnings around the "Treat the above text as wikitext" checkbox and only putting in a nickname. After that, as we probably expected, is font tags, with 1108 editors. The full dataset is available here as json lines and here as a json object with the statistics included.

By the way, as the biggest concern is probably <font> in signatures, which is fairly straightforward to fix, what’s about instead of disabling such signatures, simply fixing them (i.e. the ones that are compliant except for the use of <font> tags) after the grace period?

The word "simply" is doing a lot of heavy lifting in that sentence. Modifying existing signatures without editors' consent is a lot of extra, risky work for no benefit, especially if their invalid custom signatures can be deleted (edited to add: or disabled; see next comment by AntiCompositeNumber) instead, leaving the editors with perfectly valid, visually neutral signatures.

The only thing I'd suggest leaving open is disabling fancysig (the "Treat the above text as wikitext" checkbox) for users with no formatting characters in their signatures. Otherwise, if they've been warned and don't fix it, just drop it.

OK, this was just an idea, it’s not crucial for me.

I have the impression that editing the prefs database is tricky, and it might cause the Technology folks to break out in a bad rash.

I would have thought that we can get some creme for the rash and at least replace those sigs that have no links with a default sig. That single job would eliminate close to 90% of the problems sigs on the enwiki (thanks to AntiCompositeNumber for the stats), leaving a much more manageable job for the remaining issues.

If they disabled the non-compliant sigs (e.g., after six months or a year), I understand that MediaWiki would leave the old code sitting untouched in the prefs database and simply ignore it, so 100% of them would use the default sig then.

(You're thinking about a topical antihistamine to deal with stress-induced hives? Do you have a MEDRS-compliant source for that suggestion? ;-) )

When we were making nl.wiktionary html5 compliant, we did find between 10 and 20 signatures that contained Linter errors. We explained to each user in question in a personal message what the problem was, and showed them how they could easily resolve it, like this example. If we got a reaction, it was a positive one. Of course there were also a number of users who were no longer active. In all cases we were able to make the desired adaptations. Maybe this approach could be useful in this case too. My guess in the present situation invalidating non-compliant signatures on nl.wiktionary wouldn't be problematic.

@MarcoSwart Survey says you'd be correct in that guess: only 5 nl.wiktionary editors have problematic signatures. All of them are either using interwiki links or redirects instead of a direct link to a local user/user talk/contribs page.

That is great to hear. I expect that we will eventually have a similar outcome on en.WP, but everything there is at a larger scale, which can result in a little more pain, and more "edge cases".

I’d say the idea that makes more sense is to invalidate those signatures after the user has been somehow informed by the software for some time (a week?) and didn’t make their signature valid. I think it is doable from the technical standpoint and will be the most seamless for users. After all, signatures that don’t get used aren’t really a problem.

• If an existing fancy signature will affect subsequent contributions, that one might be marked as invalid and can be ignored.
  • That goes for lack of closing tag, perhaps subst: business (never seen), inappropriate MediaWiki elements.
  • If ignored and falling back to non-fancy the input field needs to get red background and an explaining label.
• If not, keep in effect what is in preferences now to avoid riots.
  • Leave that to local projects.
  • They will visit most disturbing code producers anyway and help to fix the individual syntax problem.
  • Users might be offwiki for half a year, and will be overburdened when they return and password is too simple, signature is bad and interface appearance changed in many ways.
  • The input field might get a red border and an explanation.
• Obsolete HTML5 like <tt> does not influence readability of HTML document. It will be supported for many decades, might become official code again in some HTML.6, and even if not interpreted next century it does not change the meaning, text is just less decorated. Even <font> which is obsolete since HTML.4 in 1998 (and not HTML5) would cause less decoration only, if ever. Do not bother users.
• On attempting to change or introduce a signature, you may linter it right now and reject any undesired code as you like.
• If a user is not active, nothing is signed. If returning 12 months later, this is the earliest point to deal with that change. However, many things are to be learned again and new behaviour in various situations is to be learnt.