Page MenuHomePhabricator

Watchlist, LiquidThreads and Echo notifications need to be unified
Closed, DeclinedPublic

Description

Need to stick them in the same place so as not to confuse people.

Watchlist in general needs a rethink, but that's for another bug.


Version: unspecified
Severity: enhancement
See Also: T23610: Merge [[Special:NewMessages]] with "[[Special:MyTalk]]"

Details

Reference
bz20541

Related Objects

StatusAssignedTask
DeclinedQuiddity
OpenNone
OpenNone
OpenShivanshbindal9
ResolvedNone
OpenNone
OpenShivanshbindal9
ResolvedShivanshbindal9
OpenNone
OpenShivanshbindal9
OpenShivanshbindal9
ResolvedShivanshbindal9
OpenNone
DuplicateNone
OpenNone
OpenNone
OpenNone
DeclinedNone

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 10:55 PM
bzimport set Reference to bz20541.
bzimport added a subscriber: Unknown Object (MLST).
Jorm added a comment.Sep 10 2010, 1:51 AM

Design. Taking. (I'm typing that a lot today.)

He7d3r added a comment.Aug 5 2012, 8:56 PM

Now, mediawiki.org shows

... [My watchlist] [My notifications] [My new messages (N)] ...

on top of all pages when I am logged in.

We (me, Benny, Fabrice, Howie, Vibha, and Oliver) discussed this issue a lot over the past few weeks (while Brandon was in Hawaii). After much debate, we haven't solved the fundamental problems, but we did reach one important decision:
For now, we are not going to have any watchlist-type notifications in Echo (notifications about simple edits), with the exception of User talk page edits. Echo will only be used for high-importance/low-velocity type notifications, while low-importance/high-velocity information will still be handled in the watchlist. We may, however, turn on more of the watchlist preferences for new users so that they are more likely to be informed of edits related to their work. At some point, we will need to revisit this, and figure out how to better integrate Echo and the Watchlist. Echo + LQT is still an unsolved issues though (as are some aspects of Echo + Talk).

Brandon:
This report has been in ASSIGNED status for more than one year and you are set as its assignee. In case that you are not actively working on a fix, please reset the bug status to NEW/UNCONFIRMED.
In case you do not plan to work on a fix in the near future: Please also edit the "Assigned To" field by clicking "Reset Assignee to default", in order to not prevent potential contributors from working on a fix. Thanks for your help!
[assigned>=1y]

Andre: Well, the fix for this bug is replacing LQT with Flow, which Brandon is designing. That fix won't happen for a year or so though. This is one case where I would actually argue that 'LATER' is the correct resolution, although we don't have that option any more.

Qgil added a comment.Mar 21 2013, 5:37 AM
  • Bug 41972 has been marked as a duplicate of this bug. ***
Qgil added a comment.Jan 13 2014, 5:31 AM

(In reply to comment #5)

Andre: Well, the fix for this bug is replacing LQT with Flow, which Brandon
is
designing. That fix won't happen for a year or so though. This is one case
where I would actually argue that 'LATER' is the correct resolution, although
we don't have that option any more.

Pong! Now Flow starts to exist, and its notifications are indeed integrated to Echo.

As Kaldari explained in comment 3, Watchlist has still its own channel of notifications (by design), while LiquidThreads is on a clear way of deprecation at least in the Wikimedia context.

I wonder whether anything else is expected to happen in order to resolve this report in a way or another.

Echo and Flow are already unified (we're not going to do any further work on LiquidThreads, so that part is declined, but done in Flow instead).

Per @kaldari I don't think it's desirable for watchlist entries to show in the same place. There are just too many watchlist edits to show it in the same way.

Should we decline this?

Mattflaschen-WMF set Security to None.
Quiddity closed this task as Declined.Nov 28 2014, 7:53 AM
Quiddity claimed this task.

Seconded. Closing.

Do we have a task for disabling LQT on mediawiki.org and migrating to Flow on all pages where it was used?
The clutter on that project is beyond acceptable.

Do we have a task for disabling LQT on mediawiki.org and migrating to Flow on all pages where it was used?

I don't know if we have a task specifically for MediaWiki.org yet, but LQT => Flow migration (on all WMF wikis) is one of our key priorities. We just finished a trial run of sorts on OfficeWiki (a private WMF wiki), in which we converted all LQT pages to Flow.

We will be doing more wikis in the future.