Page MenuHomePhabricator

E1. Personal feed v1 (spike)
Open, MediumPublic3 Estimated Story PointsSpike


For sprint E: This is a 3-point spike, looking into how to build the v1 personal feed.

The main question is: How do we bring together topics from different boards?

Goal for v1: Show the user all of the topics that he is currently subscribed to.

For this v1, we're only doing threads you're currently subscribed to. There are a couple UI issues we have to clean up before we add new topics from boards that the user is watching, see below.

For Wikimania: we need a super-simple stripped down v1 of a personal feed, so that we can show people the possibilities that Flow offers, compared to wiki talk pages.

This feature is a special page -- Special:UserFeed -- that brings together all of the conversations that the user is currently subscribed to. (Note -- formerly known as FlowFeed. Spec:UserFeed gives us more naming options.)

It looks like a normal Flow board, with the following differences:

  • No "start a new conversation" entry field.
  • Current version of the side rail, with x to close. Instead of the current "About this discussion" and "Edit description", it should say: "Welome to your personal feed! This Flow board shows all of the topics that you're currently subscribed to." That's all for now in the side rail, it doesn't need any special bells and whistles.
  • The topic header adds an additional line at the top, which says Namespace:BoardName. The name of the board is a link to that board. See mockups below. (Note: Mockups don't show the namespace, but we decided to include it.)

non-interest-feed-literal.png (1×1 px, 289 KB)

We discussed including new topics on boards that the user is watching. It's a good idea, but there are a couple things we need to figure out.

  • The line in the topic header will say "New on Namespace:BoardName". We don't currently have a way to define when a topic is "New", relative to when you look at it on your UserFeed. So we could be looking at topics that you've already seen, and still calling them "New".
  • We don't have a way to dismiss topics from your feed yet, so if you're not actually interested in these New threads, then you're stuck with them.
  • Most important -- if you unsubscribe from a topic you're subscribed to, the topic might stay in your UserFeed anyway. This would be a very unsatisfying experience.

So that's stuff to think about...

non-interest-feed.png (1×1 px, 288 KB)

See also: T100858: Flow: Personal feed v1 (design)

Event Timeline

DannyH raised the priority of this task from to High.
DannyH updated the task description. (Show Details)
DannyH moved this task to Team discussion on the Collaboration-Team-Triage board.
DannyH subscribed.

That's the design ticket -- we're still discussing design there, so I made a clean ticket that I can talk with the developers about in a meeting today.

Quiddity set Security to None.
DannyH renamed this task from Personal feed v1 to Personal feed v1 (spike).Jun 30 2015, 5:50 PM
DannyH renamed this task from Personal feed v1 (spike) to E1. Personal feed v1 (spike).Jun 30 2015, 9:02 PM

Change 223321 had a related patch set uploaded (by Matthias Mullie):
Duplicate workflow_last_update_timestamp to page_props

Instead of duplicating relevant watchlist data to Flow cluster, we're probably better off duplicating relevant Flow data (only update timestamp, I think) to page_props in core db.
We can then execute a query to core's slaves to get the exact topics we want to see, like:

$user = \User::newFromId( 1 );
$timestamp = wfTimestampNow();

$dbr = wfGetDB( DB_SLAVE );
$res = $dbr->select(
	array( 'watchlist', 'page', 'page_props' ),
	array( 'wl_namespace', 'wl_title' ),
		'wl_user' => $user->getId(),
		'pp_sortkey < ' . $dbr->addQuotes( $timestamp ),
		// join conds
		'wl_namespace = page_namespace',
		'wl_title = page_title',
		'pp_page = page_id',
		// pp_sortkey is a float & imprecise, it's useful since it's indexed,
		// but we need to sort on pp_value as well for accuracy for where
		// pp_sortkey is too imprecise to distinguish individual values
		'ORDER BY' => 'pp_sortkey DESC, pp_value DESC',
		'LIMIT' => 10,

And with those results, we can load the rest of the details from Flow storage.

Won't this query filesort because you're ordering by pp_value which is unindexed?

I assumed it would still use the index, but looks like it doesn't.

I've submitted a patch to change pp_sortkey from FLOAT to DOUBLE, which would have the precision to store full timestamp, so we wouldn't need the additional pp_value sort in there.

This is a spike. The outcome is generally knowledge rather than code.

Do you want the patch above to be merged? Is it still relevant if we don't end up doing the personal feed?

We're definitely going to do the personal feed, unless the spike revealed a fatal flaw.

My question is not if we want the personal feed but if the patch is relevant without it. It informs where the patch belongs and when it should be merged. If the patch is the first step in implementing the personal feed then it should be attached to the first task in implementing the personal feed and the spike could be moved to done.

I'm just trying to keep the board clean with actionable tasks.

For the spike to be done, we need the core DB change to go through, otherwise this approach won't work.
But I mostly dragged this to "needs review" to see if the rest agrees with this proposal ( & patches), or get feedback if I've missed something obvious.

The Flow patch is mostly a by-product of trying out to see if it could work and doesn't have to be merged right away. We probably shouldn't merge that one until we actually start working on this.

Looks good to me, but we need a DBA to agree to do the pp_sortkey schema change (

DannyH lowered the priority of this task from High to Medium.Aug 11 2015, 5:21 PM

Change 223321 abandoned by Matthias Mullie:
Duplicate workflow_last_update_timestamp to page_props

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald Transcript