Page MenuHomePhabricator

LiquidThreads: code stewardship review
Open, MediumPublic

Description

LiquidThreads has been live for a long time, however we have some potential replacements candidates now (e.g. StructuredDiscussions), and having to maintain 2 alternatives is wasteful for our limited resources.

Maintainers
Developers/Maintainers says "translatewiki.net staff (de facto)"

Number, severity, and age of known and confirmed security issues
Nothing in particular.

Was it a cause of production outages or incidents?
None documented.

Does it have sufficient hardware resources for now and the near future (to take into account expected usage growth)?
Yes.

Is it a frequent cause of monitoring alerts that need action, and are they addressed timely and appropriately?
No.

When it was first deployed to Wikimedia production
2009?

Usage statistics based on audience(s) served
Actively used on enwikinews and enwiktionary, abandoned on huwiki (last thread modification dates back to May 2017).

Outside Wikimedia, it's actively used on several large or mid-sized recently upgraded wikis such as translatewiki.net, UserBase KDE, elinux.org, TTP, thwiki.cc and wikiskripta; it still stores significant history on bayernflora, wikimini.org, PortlandWiki, PC gaming wiki.

Changes committed in last 1, 3, 6, and 12 months
1 month: 1.
3 months: 8.
6 months: 14.
12 months: 30+.

Reliance on outdated platforms

  • jQuery UI

Number of developers who committed code in the last 1, 3, 6, and 12 months
1 month: 1.
3 months: 7.
6 months: 9.
12 months: 10.

Number and age of open patches
3, dating back to July 2017

Number and age of open bugs
200+, dating back to 2008

Number of known dependencies?
None

Is there a replacement/alternative for the feature? Is there a plan for a replacement?
There is Structured Discussions (Flow). We don't need to maintain two things that do the same.

Event Timeline

MaxSem created this task.Feb 15 2018, 7:13 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 15 2018, 7:13 PM

We can sunset, but I'd disagree Flow is a replacement. Actually I'd prefer LQT over Flow (wouldn't use any of them but if I had to choose...). Thanks.

Krinkle updated the task description. (Show Details)Feb 15 2018, 8:39 PM
Nikerabbit added a comment.EditedFeb 17 2018, 11:29 AM

LQT has caused multiple production issues for translatewiki.net:

While it used to be that I was fixing LQT errors earlier, now there aren't anymore that many UBN!s or log spam, so it's not really maintained by translatewiki.net staff anymore either. Mostly it's just keeping up with core changes.

I also disagree that SD is currently a replacement. SD also has technical debt (based on what I have heard), and it has not been shown that it can replace our Support page workflow fluently: assigning threads to people and supporting querying them semantically, e.g. to provide per project or per assignee listings of open threads. Last time migration was attempted at translatewiki.net the migration scripts weren't robust enough and there were issues about maintenance status of SD. I believe some more work on SD is needed for us to migrate away from it.

Nemo_bis updated the task description. (Show Details)Feb 17 2018, 1:51 PM

LiquidThreads currently doesn't have any replacement which would respect the basic requirements of a freely licensed and collaborative wiki project, such as the right to fork (which requires functioning export/XML dumps). This is probably one reason why it's still used on hundreds of wikis.

Based on the process description I don't see any practical effect of "sunsetting" LiquidThreads, given it was already mostly disabled on all wikis, unless it's about some additional investment to deal with the problems which arose in consequence.

The other option would be an investment in its ongoing maintenance, which I would support: to sustain the usage of MediaWiki by third parties, it makes sense to maintain the compatibility with MediaWiki core and maybe to fix some of the smaller well-known bugs which have been prioritised across the years. If among the 50 (?) third party wikis which use Flow there are some who would like to go back to the more widely used LiquidThreads, e.g. to make sure that their dumps are complete, it would be fine to fund such migration mechanisms too, so as to reduce our technical debt overall.

Liuxinyu970226 added a comment.EditedFeb 22 2018, 4:49 AM

@Nemo_bis If you don't hate either non-wiki interface or introducing 3rd party services, then IMHO the Discord extension would have worth to be a candidate of LQT replacement. Because as far as I've tested, it's 1. VisualEditor compatible; 2. SemanticMediaWiki compatible; and 3. CLDR accessable.

@Liuxinyu970226 Can you elaborate? That extension I wrote doesn't make sense as a replacement - it just allows embedding a Discord widget showing who's online in a Discord server. That widget doesn't actually allow embedding a Discord chat where you can directly chat into it. IMO, discussion through live chatting and through on-wiki threads are two different things. With Discord you're going to have to create a separate account as well (since of course it's a 3rd party service).

If you really want live chatting within a wiki interface, there's the MediaWikiChat extension (as an example), but I'd say that would be out of scope for this ticket.

(Personally I'm not going to comment on the actual sunsetting of LiquidThreads, but I did just find to happen that the extension I wrote was mentioned here, thus my reply here. I also need to re-release the extension's source code as I was cleaning up my GitHub repos, it'll be back up soon)

Liuxinyu970226 updated the task description. (Show Details)

@Nikerabbit I'm trying to get a better sense of the stewardship status of LiquidThreads. The work that you were/are doing on this is from a volunteer perspective (Translatewiki.net) vs as WMF staff correct? From what I've gathered from the discussion thus far, LiquidThreads doesn't have active Stewards, Translatewiki.net or otherwise correct?

I keep translatewiki.net running. This means, among other things, that the error log should be quiet and the most important extensions must work acceptably. LiquidThreads is one of those extensions. I will report new issues that affect translatewiki.net and if they are severe and nobody reacts to them, then I must attempt to fix them myself. That is not a stewardship as it does not entail helping others, having a product vision or doing any new development.

Whether that is volunteer or paid work mostly depends on when the issue surface (I am on call 24/7/365 for translatewiki.net) and whether it is something I can fix in a short time.

Thanks @Nikerabbit. That helps me better understand the current state of things.

Nemo_bis updated the task description. (Show Details)Apr 13 2018, 8:02 AM

@Jrbranaa

That helps me better understand the current state of things.

Why on earth you think keeping maintaining the source of server errors can also give you benefits? (please, consider my case, that I still sometimes been stucked due to CSRF token errors when visiting https://translatewiki.net/wiki/Support)

@Liuxinyu970226: How is your question related to the sentence that you quoted, and to the topic of this task?

Tgr added a subscriber: Tgr.May 23 2018, 12:05 PM

I've heard some people say that they rely on LQT's "mark as read" ability to use it as a makeshift TODO list (I found that convenient myself, although I've interacted very little with LQT) so SD is not a suitable replacement to them as it is now.

Also SD has some very basic functionality gaps (no export, no search, no human-readable topic names...) which is probably a blocker for transition to many. Probably not too much work to fix though.

Liuxinyu970226 added a comment.EditedMay 23 2018, 4:07 PM

@Tgr But keeping development even twn only would also be less and less benefit, as I still can't see which code part resulted my face-to-face to CSRF errors (@Aklapper really I'm not sure if there's benefit to create separated task for my CSRF errors meeting, as staffs fixed once, another coded CSRF error happened just after 3 or 5 days, I really wanna cease this unfair do...loop).

Details of my CSRF errors can also be found at T178242

greg added a subscriber: greg.May 29 2018, 9:40 PM

Usage statistics based on audience(s) served
Actively used on enwikinews and enwiktionary,

Can someone link any relevant discussions on those wikis regarding the status of their use of LQT (or potential migration away from it)?

Pinging enwikinews sysops @Bawolff @Bddpaux @Blood_Red_Sandman @Brian @Brian_McNeil @Cspurrier @DragonFire1024 @Gopher65 @Gryllida @Microchip08 @Mikemoral @Pi_zero @RockerballAustralia @SVTCobra @ShakataGaNai @Skenmy @TUFKAAP @Tom_Morris @Tyrol5 @William_S._Saturn to answer greg's question

Pinging enwikinews sysops @Bawolff @Bddpaux @Blood_Red_Sandman @Brian @Brian_McNeil @Cspurrier @DragonFire1024 @Gopher65 @Gryllida @Microchip08 @Mikemoral @Pi_zero @RockerballAustralia @SVTCobra @ShakataGaNai @Skenmy @TUFKAAP @Tom_Morris @Tyrol5 @William_S._Saturn to answer greg's question

You should really ask on [[WN:WC]], most active wikinews admins are not active on phab.

Last i heard, wikinews was fairly anti-flow and very much pro continuing using lqt (lqt is used for a forum for non editors to discuss news items on wikinews. It is not used as a talk page replacement). However i have not been active there for many years so im not sure what current sentiment is

@Tgr But keeping development even twn only would also be less and less benefit, as I still can't see which code part resulted my face-to-face to CSRF errors (@Aklapper really I'm not sure if there's benefit to create separated task for my CSRF errors meeting, as staffs fixed once, another coded CSRF error happened just after 3 or 5 days, I really wanna cease this unfair do...loop).

Details of my CSRF errors can also be found at T178242

This is an unfair criticism of lqt. CSRF checking is a centralized part of MediaWiki that is entirely separate from lqt (or any other extension). Unless lqt is reinventing the wheel here (im pretty sure its not) csrf/session errors are not its fault.

Nemo_bis updated the task description. (Show Details)Jun 11 2018, 12:51 PM
Liuxinyu970226 added a comment.EditedJun 15 2018, 11:05 AM

@Bawolff Umm, aren't those the reasons that Wikinews should have benefit by dropping LQT too? (By clicking F12 on Comments:Ireland votes to overturn 35-year-old constitutional ban on abortion)

  • This page is using the deprecated ResourceLoader module "jquery.ui.widget".
  • This page is using the deprecated ResourceLoader module "jquery.ui.position".
  • This page is using the deprecated ResourceLoader module "mediawiki.api.options". Use "mediawiki.api" instead.
  • jQuery.Deferred exception: elms.button is not a function TypeError: elms.button is not a function...
  • This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use OOUI instead.
  • Your skin is incompatible with VisualEditor. See https://www.mediawiki.org/wiki/VisualEditor/Skin_requirements for the requirements.
  • (red marked) Uncaught TypeError: elms.button is not a function
  • Use of "skin" is deprecated. Use mw.config instead.
Nemo_bis updated the task description. (Show Details)Jul 26 2018, 7:50 AM

@Bawolff Umm, aren't those the reasons that Wikinews should have benefit by dropping LQT too? (By clicking F12 on Comments:Ireland votes to overturn 35-year-old constitutional ban on abortion)

  • This page is using the deprecated ResourceLoader module "jquery.ui.widget".
  • This page is using the deprecated ResourceLoader module "jquery.ui.position".
  • This page is using the deprecated ResourceLoader module "mediawiki.api.options". Use "mediawiki.api" instead.
  • jQuery.Deferred exception: elms.button is not a function TypeError: elms.button is not a function...
  • This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use OOUI instead.
  • Your skin is incompatible with VisualEditor. See https://www.mediawiki.org/wiki/VisualEditor/Skin_requirements for the requirements.
  • (red marked) Uncaught TypeError: elms.button is not a function
  • Use of "skin" is deprecated. Use mw.config instead.

For the record, only one of these relates to LiquidThreads. This one:

This page is using the deprecated ResourceLoader module "jquery.ui". Please use OOUI instead.

The other warnings and errors are from Wikinews's Common.js, site scripts, gadgets, and/or other extensions.

Liuxinyu970226 added a comment.EditedMar 22 2019, 2:19 AM

@Krinkle OK, but that said, I vote support for archiving this, the entire MediaWiki-extensions-LiquidThreads now looks like a ground of mass, it only has a large number of too simple actions without significant changes-to-code, e.g. Simply changed priority back to Normal and High, without any (even one second) consideration of https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels and https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette, or even, without even one Gerrit patch to fix them and assignments.

Liuxinyu970226 removed a subscriber: werdna.

@Liuxinyu970226: Archiving requires first a plan to uninstall from enwikinews, enwiktionary, huwiki, ptwikibooks, svwikisource...
The priorities of open project tasks are off-topic for this very task.

greg triaged this task as Medium priority.Jul 16 2019, 9:34 PM