Talk:Requests for comment/Support for user-specific page lists in core

IRC meeting 2013-09-24

<StevenW> there are many use cases listed in RFC, but if it is approved/implemented we could use it for GettingStarted for sure.
<brion> so i generally like this proposal
<brion> i think UX needs to be considered; this is a very low-level proposal
<MatmaRex> there was a GSOC project last year implementing something similar, it's still in gerrit: https://gerrit.wikimedia.org/r/#/c/16419/ (might be useful to look at?)
<bawolff> I wonder if there's any extensions that do magic with watchlists, that would break if the schema was changed in such a way (I guess that's a minor concern, extensions can be updated)
<Elsie> Oh, there are attached bug reports already, they're just below.
<ori-l> TimStarling: that's an issue, yes. My hope is that developer resources be allocated to this by Steven or whomever, but whether that happens will be influenced by whether there's a clear implementation path with your / brion's endorsement
<ori-l> I'm happy to at least do some more investigation (i.e., poke Domas and see if I can flesh out the specs a bit more)
<StevenW> brion: on the UX side, I was hoping that it could be disconnected from requiring immediate changes to the watchlist UI itself.
<RoanKattouw> MatmaRex: Looks like that Gerrit change corresponds fairly closely to the RFC
<brion> ori-l: so generally I like to expect that the people making a proposal intend to pitch in… when that's WMF folks we need to consider who actually has time to do it. :)
<StevenW> But I would be happy to help get input from design team and shepherd things on the UX/UI side to make sure it works out.
<parent5446> We should consider making RFCs restricted to more design-level comments. Having a code API inside an RFC is just asking for problems.
<ori-l> brion: yes, but I've switched roles, which wasn't entirely expected
<Elsie> parent5446: APIs aren't designed?
<brion> ori-l: ah true
<RoanKattouw> MatmaRex: Mind putting that link on the RFC somewhere?
<Elsie> That explains so much...
<TimStarling> ok, so reading this RFC now, it is somewhat different to what I had assumed, talking to ori on IRC
<MatmaRex> RoanKattouw: it is there
<MatmaRex> "Instead of implementing a new simple tagging system, why not just finish https://gerrit.wikimedia.org/r/#/c/16419/ ? Eran (talk) 05:27, 21 June 2013 (UTC)"
<RoanKattouw> parent5446: It could be moved to an == Implementation == section, along with the Gerrit link
<brion> StevenW: my main worry there is that users *love* to build workflows on top of half-done UX
<brion> and then they whinge when we change it
<Elsie> TimStarling: Do you agree with the general idea?
<StevenW> brion: gotcha.
<TimStarling> the watchlist is mostly read by Special:Watchlist, and that is a huge join with recentchanges
<ori-l> TimStarling: sorry -- did I misrepresent it?
<Elsie> http://xkcd.com/1172
<RoanKattouw> MatmaRex: Right. Missed it, sorry
<brion> :D
<MatmaRex> (it could be in a more visible place, though)
<TimStarling> if you only want to add tags to the regular view of Special:Watchlist, and not filter by tags...
<MatmaRex> (but i didn't read through the RFC nor the patch in the past, not sure how relevant it is)
<TimStarling> or at least don't make the ability to filter by tags very prominent
<Elsie> I think tags are the whole point of the RFC.
<TimStarling> then it has quite a different performance profile
<StevenW> Tags is perhaps a bad word here. We don't actually want to necessarily add user-visible tags to the watchlist UI itself.
<Elsie> Tags are supposed to be the user-specific lists, as I understand it.
<TimStarling> the expensive thing about the watchlist is the massive intersection it does
<Elsie> StevenW: Then how will users create lists?
<parent5446> Basically I think the idea is that you can have multiple, independent watchlists.
* Nemo_bis always keeps in mind 1172 when complaining about something
<brion> these tags would be internal -- how they'd map to UX is left unsaid so far (to be determined...)
<StevenW> Elsie: that ^
<Nemo_bis> MatmaRex: I think that comment is not more visible because its whole point is that the author feels nobody is interested
<bawolff> Elsie: So would this be user creates list, and then mediawiki shows all things in this list, or does it show recently editing things in the list? (or both, or up to specific use case)
<Elsie> I don't see how you keep them internal.
<ori-l> TimStarling: I think most features built on top of this implementation would use their own interface. Having tag management functionality in Special:Watchlist ensures that users are not dependent on incomplete APIs to manage tags but always retain the ability to manage their items
<TimStarling> well, the RFC has things like:
<TimStarling> Tags could be used to create a to-do list for editors (using structured data, as opposed to a simple wiki page).
<TimStarling> Tags could be used to create a "read later" or favorites list.
<TimStarling> Tags could be used to create reminders about pages (bug 582)
<TimStarling> Tagging a page to be saved for offline reading could create a cached list for users on desktop or mobile devices
<bawolff> Because ToDo lists you probably wouldn't show things by last edit
<Elsie> bawolff: I'm not the correct person to ask. :-)
<Elsie> I'm confused about this as well.
<Elsie> I think this RFC needs further thought and consideration.
<TimStarling> those applications are all pretty cheap, they don't require massive recentchanges joins
<bawolff> In any case, if we're not showing by last edit, the performance concerns become moot
<ori-l> right.
<Elsie> Presumably monitoring the pages on a user-list is a goal.
<Elsie> Okay, we should move on to a different RFC.
<Elsie> sumanah: What's next?
<ori-l> hang on
<bawolff> Of course if we're doing that, we should consider if people want things alphabetical using a collation
<brion> so it sounds like people generally like the low-level idea here, but it needs more work on how it'll present to users.
<sumanah> == Retained account data self-discovery ==
<sumanah> * https://www.mediawiki.org/wiki/Requests_for_comment/Retained_account_data_self-discovery
<brion> shall we mark that down and continue?
<brion> yes :D
<TimStarling> sumanah: please ignore Elsie
<ori-l> sorry, give me a minute to form a sentence, I'm a bit slow
<TimStarling> we should spend another 5 minutes on this, I think
<brion> fair enough
<sumanah> TimStarling: done.
<StevenW> Would it help if I explained the genesis for this? What problem we encountered?
<ori-l> so, Special:Watchlist would be augmented to have tag management functionality as a form of insurance against crappy features that would otherwise stick users with tags they can't get rid of
<StevenW> ah, go for it ori :)
<ori-l> it ensures users always have a low-level ability to modify / remove / edit tags
<manybubbles> ori-l: this raises my leaky abstraction warning bells
<ori-l> but it's not expected to be the interface that actually delivers added value
<TimStarling> ori-l: the massive intersection in Special:Watchlist will probably ultimately need to be moved to some other storage backend
<cscott> brion: +1
<AaronSchulz> probably
<TimStarling> so it probably makes more sense to provide a unified UI for editing lists which is independent of storage backend
<TimStarling> and can edit lists whether they are in the watchlist table or not
<StevenW> potentially
<StevenW> watchlists as they exist are extremely confusing to many users, including otherwise experience people.
<cscott> fwiw, i suggest that user-mutable tags are prefixed (with something like 'user/') to reserve the rest of the name space for tags defined by extensions, etc.
<TimStarling> the modify UI, or the read UI is confusing?
<sumanah> I would say both.
<StevenW> creating many hand-edited lists may turn out to be a bad idea for all but a tiny few.
<StevenW> But in general it seems like we need a way to associate pages with users beyond just the binary watch/unwatch function as it exists now
<TimStarling> StevenW: you mean as opposed to sharing, watching categories, etc.?
<sumanah> http://mw-watchlist.tumblr.com/ has some additional thoughts for those who want to read them, on watchlist UI stuff
<ori-l> I think that editors already have different use-cases in mind when they watchlist a page, we just don't have any support in the software for it
<Elsie> Or a coherent path forward to address the users' needs.
<TimStarling> ok, let's resolve to expand this RFC somewhat
<ori-l> there's watch this page because i am its primary author and want to see how it grows, there's watch this talk page to know when someone replies, watch this page because it gets vandalized often, etc.
<cscott> is it fair to say that no one dislikes the basic idea, but that it's large enough that it's hard to sign off on it completely without further work?
<TimStarling> and I will add some comments about the potential need to abstract the backend
<StevenW> yes to both cscott and Tim
<TimStarling> ok, next RFC
<brion> +2
<ori-l> yeah, that's good.
<ori-l> thanks
<StevenW> yes thank you

April 9th update

This RfC is due to be discussed briefly on April 9th; join us! Sharihareswara (WMF) (talk) 02:31, 8 April 2014 (UTC)

From yesterday's meeting:

22:25:21 <sumanah> #topic support for user-specific page lists in core

22:25:33 <sumanah> This is Ori & Steven's RfC.

22:25:34 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_page_lists_in_core

22:25:42 <sumanah> #info Ori and Steven last updated this in September 2013. When we discussed it then, we agreed "to expand this RFC somewhat" and that "no one dislikes the basic idea, but ... it's large enough that it's hard to sign off on it completely without further work"

22:26:18 <awight> fwiw, this work is probably getting rolled into an EducationProgram rewrite

22:26:20 <sumanah> #info TimStarling said "I will add some comments about the potential need to abstract the backend"

22:26:30 <sumanah> #info Adam Wight relates: "this work is probably getting rolled into an EducationProgram rewrite"

22:26:36 <sumanah> awight: around whennish?

22:27:06 <awight> sumanah: I don't know if that's on the roadmap yet, currently the work is focused on generalizing Campaigns

22:27:24 <sumanah> AaronSchulz: perhaps you can speak on behalf of your performancey colleague ;-)

22:27:29 <awight> But the big picture is that StevenW wants to add functionality like the user page lists as components.

22:28:37 <brion> i like the basic idea; there’s some open question about how tags would be managed though

22:29:07 <sumanah> looks like we won't have ori or StevenW in this chat today. That's ok

22:29:08 <brion> …and someone might have to take a flamethrower to some existing watchlist code to clean it up

22:31:22 <sumanah> awight: do you need Tim to follow up on making comments re abstracting the backend?

22:31:41 <AaronSchulz> brion: it could work, though it inherits all the sorting problems watchlists have now

22:31:48 <AaronSchulz> though brad already mentioned that it seems

22:31:51 <brion> *nod*

22:31:57 <awight> sumanah: I'm pretty far from that work, but mentioning the complications would be a good idea.

22:32:13 <AaronSchulz> reminds, we figured out a fix for the externallinks thing he mentioned...someone should do that :)

22:32:40 <sumanah> #action TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend

22:32:56 * sumanah hopes AaronSchulz or someone else will phrase the externallinks fix thing as an #info

22:33:26 <sumanah> (sounds like we can move on pretty soon to Nonlinear versioning which will be candy to some folks)

22:33:52 <sumanah> #action someone should consult AaronSchulz and anomie re how to fix the externallinks issue

22:34:02 <AaronSchulz> well that's not actually related, it just reminded me

Sharihareswara (WMF) (talk) 11:24, 10 April 2014 (UTC)

Supporting metadata for lists

The implementation should make it possible to associate metadata with a list. For example I might want to name a list "Articles to edit May 2015", "Article stubs I want to expand" or even "My favourite ten articles". In theory it should even be possible to rename your Watchlist to something more meaningful if you have multiple watchlists (e.g. Soccer article watchlist) With the wl_tag and wl_user I should be able to inspect a collections/pagelists table and find information such as a description,title. Jdlrobson (talk) 21:18, 12 January 2015 (UTC)

List vs. page

The current text of the proposal is a mess. In particular, the use cases seem to assume that "a list of pages" can be created, with some content; while the technical proposal says this is about having (watchlisted) "pages with a list" (of tags), the opposite. The difference is huge, because if something lives in my watchlist nobody other than me can edit it and every feature depends on each page being added to my watchlist. --Nemo 20:07, 13 January 2015 (UTC)

Schema progress

According to minutes for the 2015-01-14 architecture meeting, there is an action point:

#action jdlrobson to propose schema

is that in progress? --Nemo 09:36, 11 February 2015 (UTC)

Ping. I see a new RfC meeting is scheduled about this proposal, but previous action items have not been completed yet? --Nemo 23:28, 10 March 2015 (UTC)

I've had my head down building this with Yuri. I will report back when that work is completed which should be hopefully in 3 weeks time. Jdlrobson (talk) 22:01, 12 March 2015 (UTC)

Thanks for the update. --Nemo 06:57, 13 March 2015 (UTC)