Topic on Talk:Flow Portal/Archive2

Is this the new LiquidThreads?

No. LiquidThreads will live or die on its own. The lesson learned from LQT is that it was too aggressive in what it supported and was supposed to do.

Unlike LQT, this is only targeted at User:Talk, not Talk pages and discussions in general, and addresses modalities that hurt user interaction (especially new users). Current wiki conventions to, for instance, replying to a talk message are quite unlike any other web affordance currently in use for user-user/user-group communications. Flow wants to address that while following the core values of a wiki (if you want private talk, take it to e-mail. That would not change).

It's not necessarily a complete replacement to User:Talk. The two might coexist indefinitely and that is not addressed yet in the Echo spec (currently its mostly a design spec with mostly high level engineering). Though the hope is that it will supersede it—at least in usefulness. And some "upgrade path" for those who want to move a user talk discussion to flow or "upgrade" their user talk should be provided.

Note: "upgrade" in quotes because on one hand while you gain some features esp. Echo integration, you do lose things like the free form format of Talk pages.

I hope this clarifies things.

Still, does it consider all the wishlists and problems with LQT (filed in bugzilla)? I don't see most of them here but they'd seem to apply, I hope I don't have to re-file/list all of them on this page. Cheers,

It does not consider all the wishlists/problems. However the lessons learned does apply.

There is no need to re-file/list those bugs because LQT is not killed off (just unsupported at the moment due to resource issues). Flow is a separate project from LQT/LQT3.

My fear is, and I believe it is a lot of other peoples fear, that one day LQT will be incompatible with some future version of MW. This would be an end of story for the wikis utilizing LQT.

However, my impression is that there are quite a lot them around and still counting. This is due to the fact that even the current life supported version of LQT is far better for talk pages than any other solution around (including plain talk pages with no thrills). Besides, LQT was and still is one of the coolest things that came out of development during the past five years.

Basically the problem is, and this is the major cause of emotions here, that all these wikis do not know what to expect with regard to LQT and are being left alone for quite some time now. They are stuck in the darkest uncertainty regarding their wikis.

LQT is beyond the point of no return. We know it, WMF knows it and this is the very big dilemma.

I won't go so far as to say that it is "beyond the point of no return," but I understand your fears and it's reasonable to have them.

I don't think the goals of messaging can replace LQT. In determining editor engagement and features goals, it was clearly obvious that user-user messaging is broken so a project was put in 2012-13 goals to address that. This has been named "Flow" and according to planning will not be worked on directly until early 2013 (all work beforehand is infrastructural, and UI/UX resources are prioritized around notifications).

I want to emphasize that improving User Talk (user:user messaging and discussion) is a fundamentally simpler structure of interaction and requirements than Page Talk or LQT which is many things to many wikis (from a Talk replacement to a full blown forum and discussion system). At some point, things move beyond user-user to discussions, and I (personally) think that LQT rework to incorporate the core architectural and feature changes (Echo/Flow/Global Profile) is closer to a solution here than upgrading/changing a user-user messaging system like Flow.

There are no formal resources for LQT development in this year's planning (there are no formal resources on Flow for half the fiscal year). However, the same people involved with Flow are the ones who have worked on LQT which means that there might be some design guidance and bug prioritization for what needs to be done here and it can be kept up-to-date. (I've tried to give the developer the freedom to update LQT code under the auspices of working on Echo and Flow.)

Be aware mediawiki.org currently uses LQT without any plans on that changing. So while it doesn't mean you'll see LQT on English Wikipedia any time soon, this should keep LQT tracking some of the new features being developed (notifications, at least). Finally, probably the best bang for the buck on LQT improvements would be after the new Visual Editor is integrated in MediaWiki. That won't happen until sometime in 2013 anyway.

As for the WMF resources and the mediawiki community at large. This is part of a large discussion on what is and isn't working with respect to integrating changes coming from the developer community, which is broken far worse with more extensions than LQT. I'll follow whatever comes up from that.

It's my hope that by placing the same people on both Flow and LQT, the developer of LQT will get some guidance on the the LQT bugs/features that should be dealt with.

The LQT developer is left alone without any support from community feedback, infrastructure/ops, and product design and development when it comes to LQT and LQT3 (which was a deferred project before I even joined the WMF). In the past, we've found that when left without support, projects have a tendency to runaway and/or never see the light of day. The WMF plans to not repeat these past mistakes in features (PendingChanges, LQT, LQT3) by providing that support on formal features going forward (AFTv5, Page_Triage, Article_Creation_Workflow, and the VisualEditor being examples of this new approach which will be applied to Flow and Echo this fiscal year).

My understanding is many mediawiki installs like LQT and would love to see some movement here. I have to squeeze this in with the reality of the resourcing here and other priorities. This is the best I can offer. (In terms of developers who know LQT, we are talking about a single part-time student developer.)

meh perhaps we should make a (maintinance) script allowing people to deconvert from LQT (dump all the LQT threads on talk pages), I imagine that would help stop the lock-in fears people have (which from what I can tell seems to be where most of the frustration is coming from). Even if people don't use it, its nice to know one has the option to disable LQT if need be.

Maybe we should just try to really re-energize development! I really would like to help. Maybe there could be somewhere a test instance be installed. I'm trying to setup a debug server at the moment. Maybe there could be done something with jenkins that at the moment is only runnig with mediawiki. It's just the point to do something and not to complaine and to think about what could be done and so on!

I believe there already is a test instance of LQT3 on Labs. Talk to User:Werdna.

"There is no need to re-file/list those bugs because LQT is not killed off". This is not a very satisfactory answer, bugs and feature requests have to be considered now for Flow, not just postponed to a mysterious future, or no, Flow won't incorporate the "lessons learned" at all. LQT has so far 121 "enhancement" bugs besides 141 bugs and many others nobody bothered to file. Please don't waste the time people spent on filing them hoping in the future. Thanks,

Flow is just a step caused by the laziness of developers somehow like "let's make a fast temporary solution to show results" instead of make things right

So instead finishing one project there are others started. That's really bad. I love LQT and it's really accepted on my wikis. The only problem is, that it's still extremly buggy. But the concept and the base to build on is good. Flow is bullshit. Sorry. --DaSch (talk) 12:40, 14 July 2012 (UTC)

Yes, it's frustrating. :-(

But in addition to the bugs, LQT was built without considering the fact that as it is, it can't scale to the size/traffic to a major Wikipedia (for instance, English). That, among other reasons, is the reason that Flow is what it is.

The same people who worked on LQT and LQT3 will be working on Flow, so there is no reason they can't revisit LQT and back port those changes and give LQT some love.

…

One point of clarification. Messaging was determined as a "must have" by Product's 3-year plan to deal with Editor Engagement. Flow came out from that, not a determination to keep or abandon LQT. For the 2012-13 planning/goals, we added Flow at the last minute which is much more aggressive planning that normal (I felt we can safely do Notifications & Global Profile. The latter was pushed out and Flow was added.)

The worry is to continue or repurpose LQT to solve messaging goal would jeopardize actually accomplish that goal to within the aggressive timeline. I felt that it was more likely to accomplish some sort of messaging this fiscal year with the option of backporting to LQT or gradual improvement of Flow would be better than to try to shoehorn LQT and its baggage into the messaging problem.

Perhaps I was wrong, but scalability issues in LQT means that there's a lot more going on there that isn't as simple as addressing reported bugs.

…

Concerning your specific needs. Given that LQT has no official support this fiscal year, we should loop back into discussion concerning some way where community dev contributions on LQT can be incorporated without requiring oversight from the WMF. Theoretically the WMF could freeze on the current version of LQT.

Of course, since it's now all in Git, you can easily fork LQT or LQT3 and know that we can merge those changes back in when the WMF revisits LQT.

>Concerning your specific needs. Given that LQT has no official support this fiscal year, we should loop back into discussion concerning some way where community dev contributions on LQT can be incorporated without requiring oversight from the WMF. Theoretically the WMF could freeze on the current version of LQT.

Last time I checked, LQT was scary, and hence had essentially no volunteers working on it. (Or perhaps that's an artifact of the mysterious LQT3 that will in theory replace LQT which everyone is waiting for, and thus people don't want to work on the "old" version)

That's the point. One day Wikimedia announced LQT3 so everbody thought they will finally make it really great. And after over a year Wikimedia is cancelig the project and what is left is a non-working git-branch and nobody left for maintaining LQT2. That's a bit like walking half the way and then turning back to take the car and drive somewhere else. And we are standing here and no chance to get away. Somehow it's Wikimedia's fault that there is no further development. They took it and killed it.

I don't think its Wikimedia's fault neccesarily. They do not have a responsibility to develop every extension in existence. (I do think they have a responsibility (with in reason) to support volunteers doing LQT development (or more generally any development aimed at Wikimedia wikis)), but the fact of the matter is, with exception of a commit to make LQT work on postgress, nobody in the broader community is developing LiquidThreads whatsoever.

It's not a matter of developing, it's not even maintained at all: «one day LQT will be incompatible with some future version of MW», no it already is.

Is there someone planning a LQT-to-Flow conversion server-script? Even if not, would it be technically possible to implement such feature, in case LQT becomes truly incompatible with the MediaWiki version installed here?

Yup, that is planned. There's no ETA, but it's definitely on the to-do list. :)

Thanks, I'll be waiting for later updates :-)