Schema-wise this seems similar to T96282. There should be a gather_list_follow and a gather_user_follow table with (gl_id/followed_user_id, following_user_id). (Alternatively the two lists could be shoehorned into one, with an additional type flag field.)

Another proposal: We make it possible to add a collection to a collection (mind blown)
The way this would work - we reserve a name space e.g. GatherList:<id> which you can visit and add to your collection.
On a collection itself we show the same "add to collection" button (watchstar) that adds this page.
When pages are rendered from the GatherList namespace they get slightly different render treatment.
When following a collection you simply add it to a special type of collection (we already have watchlist, maybe a collection with id -1 is the reserved follow collection and can only have pages from the GatherList namespace.

Pros:

• Reuse what we already have
• Can get collections you follow simply by querying all collection items with id -1 by the given user.
• Can get all people following a collection by simply asking 'get all collection items with title GatherList:<id>'

Cons:

• Could get confusing if we allow collections to appear in other collections
• Will this scale?

@Jdlrobson Mind blown. This seems like a creative solution. For the sake of simplicity let's assume we don't want to surface the ability to add collections to collections to the user. I think this should be evaluated on its' merits as a way to filter/present collections that are being followed...etc.

@Tgr would this be sane? It would also allow us to start experimenting with page like features by tying a collection to a page. Cc @Yurik

@Tgr ^

When pages are rendered from the GatherList namespace they get slightly different render treatment.

If by different treatment you mean some sort of template-style expansion, with arbitrary depth, that's very scary performance-wise. Definitely would not go there unless we decide we want that feature for its own sake. Without an expansion, there is not much use case for adding a collection to a non-special list as far as I can see.

As for special lists like "collections I follow" (maybe even "collections I flagged", it has the same structure)... not sure. Filtering/ordering lists based on the number of elements is not trivial and reusing the same structure for collections and follows (and maybe flags) would save us a lot of footwork, but it would tie together systems which are conceptually different and just happen to work the same way right now. If they evolve in different directions (extra fields, different filtering criteria, different scalability requirements) this will become increasingly awkward. My vote would be not to do it.

Yeh the different rendering is something further down the line. A following page would consist entirely of things that are collections. We'd need to do a query like ( select * from gather_list_items where id = -1 ) JOIN gather_list on gather_list_items.title = gather_list.associated_title

It would be a bit more complicated than that as you need a separate "follow collection" for every user, so instead of a special id you would have to add a type column and then set TYPE_FOLLOW for the special collections. Anyhow, IMO this would couple things the wrong way. Features should only share implementation if they are the same thing at a higher layer of abstraction and that's not really the case here. You have to move to a very high abstraction level for "lists of pages" and "lists of lists of pages" to be the same thing (basically, an abstraction level of "lists of things") and at that level the current implementation of gather_list/gather_list_items does not make sense anymore.

@Tgr do you think we have a solid proposal of what the backend looks like now and flesh out the details of https://phabricator.wikimedia.org/T97674 ?

• DB schema:
  • new table gather_list_follows(user_id, collection_id)
  • add ever_followed to gather_list
  • query does not need to be efficient for now, we'll check first how much following happens
• Hooks:
  • on deleting of a list, discard all follows
  • update user id on user merge/rename
  • on a user following a collection, if ever_followed is false for that list, set it to true and send a notification to the owner
  • on a collection updating, send a notification to all followers
• API:
  • mode=follow/unfollow for editlist
  • mode=followed option for the lists API
  • followed property in the lists API (current user followed this) (?)
    • this will disable caching, is that OK?
  • followCount property on the lists API (?)
  • sort=follows for the lists API
• Special pages:
  • do we need any?

Ever_followed should be removed in favour of follow_count which can be a null value

Follow count is null initially
Ever_followed = follow_count is not null

In T94243#1264748, @Jdlrobson wrote:

Ever_followed should be removed in favour of follow_count which can be a null value

Good idea! Updated.

In T94243#1264748, @Jdlrobson wrote:

Ever_followed should be removed in favour of follow_count which can be a null value

On second thought, I'd rather we didn't do that. It's hacky (by standard DB semantics null means the number of follows is not known; using it with a completely different meaning is going to be confusing) and ties us to a certain implementation. If we decide we need to store follow counts as a separate field, having both follow_count and ever_followed is not any worse than combining the two in a single field; but we might also decide to calculate the follow count on the fly (especially initially to get the feature out sooner since on-the-fly is a lot simpler).

Okay, instead of that can't we just rely on the Echo notification to avoid the edge case of "this collection got followed for the first time"? I'd rather not add this field if we can avoid that. If that means it's a vector for spam so be it.. i'd rather delay that decision to later.

Echo exposes no such functionality as far as I could tell. It would be possible via direct DB access to check whether a user has already been notified about follows to a collection, but directly relying on implementation details of a foreign extension is a bad idea.

Okay sounds like this is the way forward. Have updated card.

In T94243#1257898, @Tgr wrote:

• DB schema:
  • new table gather_list_follows(user_id, collection_id)
  • add ever_followed to gather_list
  • query does not need to be efficient for now, we'll check first how much following happens
• Hooks:
  • on deleting of a list, discard all follows
  • update user id on user merge/rename
  • on a user following a collection, if ever_followed is false for that list, set it to true and send a notification to the owner
  • on a collection updating, send a notification to all followers
• API:
  • mode=follow/unfollow for editlist
  • mode=followed option for the lists API
  • followed property in the lists API (current user followed this) (?)
    • this will disable caching, is that OK?
  • followCount property on the lists API (?)
  • sort=follows for the lists API
• Special pages:
  • do we need any?