In T40403#8291877, @karl-police wrote:

Sorting by alphabetical would be great.

Board descriptions are now much better visually distinguished from the button that lets you edit them. This is resolved.

This task is not actionable, and no longer serves a purpose.

I can no longer reproduce this. Maybe it got fixed at some point.

This was fixed by Mike's patch.

I don't remember whether we did this or not, but suffice to say, I doubt we have the data anymore, and even if we did, analysing a five year old A/B test is unlikely to be useful for anything.

This doesn't make much sense. It's a tracking bug that tracks nothing, and it has no details about why the page should be redesigned or what would be achieved by doing so. Undoubtedly the search page could use an overhaul, but there's nothing to go from with this bug.

This isn't relevant anymore; the prototype is gone, maps were since deployed, and many years on are barely supported now.

Five years on, this task is likely not relevant anymore, and the data generated by fixing the data collection would not be useful for anything.

I don't think Discernatron is used anymore, so this probably isn't a useful feature request anymore.

This is probably not relevant anymore, especially with the new media search that's being worked on.

This appears to be fixed now. Since people mentioned Volker, I will speculatively assign it to him retroactively. Thanks Volker! ;-)

I think this task has long since served its purpose. Language detection was significantly improved with TextCat and other efforts. Any future work to improve language detection can be put under another epic. Enough has been done to call this resolved.

I think this task has long since served its purpose. The zero results rate wasn't cut in half, but measures to reduce it did help, and it was determined that trying to cut it in half would probably ultimately be more harmful than helpful. Enough has been done to call this resolved.

Per the notice on https://discovery.wmflabs.org/ these dashboards are now in maintenance mode. This feature request is no longer relevant.

In T92432#6360105, @Valereee wrote:

@Barkeep49 I won't pretend to understand why a fix would be hard, but for heaven's sake the fact something might be difficult shouldn't be a reason to downgrade its importance. That just tries to hide the biggest problems by calling them minor.

In T92432#6350118, @Anomalocaris wrote:

disable the visual editor until this is done.

This shouldn't be assigned to me anymore.

Excellent. Thanks @Esanders!

I'm excited about reading this!

I see. So, this isn't about pasting HTML into the VisualEditor and having it convert it to wikitext, it's about the conversion done when you're switching back-and-forth between the visual and wikitext modes. I've retitled the bug. Prioritisation is up to the Editing team, I'm just a volunteer trying to help clarify bugs. :-)

@EFFemeer No problem. :-)

@TheROFL98 Please can you provide specific steps to reproduce? The specific HTML that you were trying to paste would be helpful, at a minimum.

In T131013#4933409, @alexhollender wrote:

What if we allowed people to edit descriptions, but instead of telling them not to capitalize we just automatically forced the first letter to be lowercase when we stored it in Wikidata? Of course this would be obscuring things from editors, however maybe it is the best compromise. The end result would be what's desired for both services: descriptions wouldn't be capitalized in Wikidata, and they would be in Wikipedia.

As one of the people behind capitalising the descriptions in the first place, I (reluctantly) agree that they shouldn't be capitalised any more. I stand by the original decision, and think it was the correct decision at the time, but circumstances have changed.

I fixed the typo in the message on translatewiki.net, so this should be fixed next time you do an l10n update.

Sorry. got the tags wrong there.

In T14896#4772335, @Pigsonthewing wrote:

A decade-old ticket reporting a backdoor to the spam blacklist? Remarkable.

This is very stale, and doesn't make much sense to do now.

I tested this on mediawiki.org which does not have Citoid enabled. Trying to reuse the reference whilst it is selected does not cause any issues—the reference remains selected, and no exception is thrown. It appears this was fixed at some point.

Yes, it does seem to. There could still be some polishing done to make it smoother, but it does work, so this task is resolved.

According to the release notes, this did get merged before the branch was cut, so will be live everywhere today.

Cool, thanks! That looks like a good enough improvement to call this resolved.

Cool, thanks! That looks like a good enough improvement to call this resolved.

Cool, thanks! That looks like a good enough improvement to call this resolved.

Can we add a screenshot here of the new test coverage, so that it can be compared to the old test coverage in the description? I don't know where the test coverage dashboard shown here lives, so I can't do that myself.

Can we add a screenshot here of the new test coverage, so that it can be compared to the old test coverage in the description? I don't know where the test coverage dashboard shown here lives, so I can't do that myself.

Can we add some screenshots here of the new test coverage, so that it can be compared to the old test coverage in the description? I don't know where the test coverage dashboard shown here lives, so I can't do that myself.

Can we add a screenshot here of the new test coverage, so that it can be compared to the old test coverage image in the description? I don't know where the test coverage dashboard shown here lives, so I can't do that myself.

I will assume that this fixes the problem.

Looks like this is still waiting for code review.