Seems reasonable.

Not sure I see a rationale for limiting passwords on the top end... denying a DOS situation from new accounts making lots of long passwords? Preventing users from entering a password they never have a hope of remembering (well, maybe not, depends on if 'character' means Unicode codepoint or ASCII character)? (No-one will realistically enter a long password without the use of a password holder, so maybeeee it doesn't matter.)

Given T260456#6965237 and response, this is probably T230013: LanguagePicker's handling of script suffixes is broken.

(I am not the right person, to respond to the email poke.)

Opened T284997: Warn users when the sidebar generates multiple of the same ID for that.

This seems like a special case of T9356: User-specified HTML IDs can be the same as interface IDs

Alternatively, I see in the log that this was switched to wikitext temporarily, so this may be a case of the DB needing to be cleared or something?

Ah, then there are two implementation paths.

Providing the replacement CSS in this task prior to discussion would probably go a long way to making this a gentle change over.

Listing out the categories onwiki in a MediaWiki namespace page is probably more flexible for wikis with non-free media, but a PHP config seems fine too.

Yeah, how it used to be on the left.

T145604: RFC: Future of magic links and related seem of some relevance.

In T283980#7136114, @stjn wrote:

In T283980#7135209, @mmodell wrote:

Several of Phabricator's users and long time contributors are coming together to fork phabricator, with @epriestley's blessing and under a new name. I hope that Wikimedia will be a part of that effort, at least by sponsoring some of my time towards it, however, I intend to contribute in a personal capacity as much as I can.

Please name it Phork. Please name it Phork.

This is a pain point for me not just with the content block itself but also the warning that TemplateData exists on the /doc page (which I guess is even the worse problem for me).

In T248034#7132710, @Jdlrobson wrote:

And once a task dies, no-one is going to find it

I don't really understand this. If a task is resolved, or declined it is still very much searchable.

You and I know how to find closed tasks, but I don't think as I suggested earlier that the default MO of anyone is "has this been reported before and closed without fixing?". The average bear definitely doesn't know, even if they have the MO to show up to Phabricator. (Phabricator is not welcoming, though as task managers go, it's the most welcoming I've had to deal with; I evangelize it and participation on it onwiki whenever I get the chance).

feasible

The proposed path "leave a note -> no activity and close" would be overwhelming to try to keep up on tasks that matter for volunteers and WMF developers alike. On any repeated basis. And once a task dies, no-one is going to find it. If it manages not to die the first go-around, the cycle repeats until either the volunteer who knows That Task is a problem or the developer or project manager on the team who cared about That Task moves to another team. And that's ignoring internal reorganization above and beyond the casual movement of engineers from group A to B. Even if none of that happens and you end up with the happy case, at that point you're adding spam "does it still matter" "yes of course it still matters" on for potentially years until someone comes to talk to the bugmeister about the fact a task has been up for questioning 10 times in 10 years. That's all assuming that that person isn't already gone and has stopped caring....

In T252432#7130889, @Jdforrester-WMF wrote:

@Izno: Not sure what you're doing? Please don't remove blockers like this, especially without any comment justifying the change.

I might be thinking of the other citation tool that is now no longer available? I know there was one :^).

Since there are some eyes from people who know things, I have an idiot's question that echoes one not really answered above.

In T282265#7109752, @bd808 wrote:

We do, but we also try very hard not to disrupt existing tools unless they are egregiously in violation of a term. Shutting down an otherwise functional tool for an undeclared or non OSI-approved license would not be an initial step. First we would try asking nicely and pointing to the policy. Shutdown would be an absolute last resort.

At the end of the day, someone has to say, "What is the license? We're kicking you off otherwise." So I guess you are saying that's how that works today?

Was the border in the description meant to be the border on the <img> or the full thumb? As someone pointed out to me today on Discord, the border on the <img> itself could use total removal without re-implementation in skins expecting it today. (Not sure how I feel about such removal for transparent images? Maybe some design thought needed there if removing that border is a path of interest.)

In T248034#7032036, @Aklapper wrote:

To me the elephants in the room are ownership, workflows and capacity...
In an open environment, anyone is free not to care about a ticket created five years ago, and anyone else is also free to care....