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

IRC meeting 2013-09-24
&lt;StevenW>	there are many use cases listed in RFC, but if it is approved/implemented we could use it for GettingStarted for sure. &lt;brion>	so i generally like this proposal &lt;brion>	i think UX needs to be considered; this is a very low-level proposal &lt;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?) &lt;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) &lt;Elsie>	Oh, there are attached bug reports already, they're just below. &lt;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 &lt;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) &lt;StevenW>	brion: on the UX side, I was hoping that it could be disconnected from requiring immediate changes to the watchlist UI itself. &lt;RoanKattouw>	MatmaRex: Looks like that Gerrit change corresponds fairly closely to the RFC &lt;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. :) &lt;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. &lt;parent5446>	We should consider making RFCs restricted to more design-level comments. Having a code API inside an RFC is just asking for problems. &lt;ori-l>	brion: yes, but I've switched roles, which wasn't entirely expected &lt;Elsie>	parent5446: APIs aren't designed? &lt;brion>	ori-l: ah true &lt;RoanKattouw>	MatmaRex: Mind putting that link on the RFC somewhere? &lt;Elsie>	That explains so much... &lt;TimStarling>	ok, so reading this RFC now, it is somewhat different to what I had assumed, talking to ori on IRC &lt;MatmaRex>	RoanKattouw: it is there &lt;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)" &lt;RoanKattouw>	parent5446: It could be moved to an == Implementation == section, along with the Gerrit link &lt;brion>	StevenW: my main worry there is that users *love* to build workflows on top of half-done UX &lt;brion>	and then they whinge when we change it &lt;Elsie>	TimStarling: Do you agree with the general idea? &lt;StevenW>	brion: gotcha. &lt;TimStarling>	the watchlist is mostly read by Special:Watchlist, and that is a huge join with recentchanges &lt;ori-l>	TimStarling: sorry -- did I misrepresent it? &lt;Elsie>	http://xkcd.com/1172 &lt;RoanKattouw>	MatmaRex: Right. Missed it, sorry &lt;brion>	:D &lt;MatmaRex>	(it could be in a more visible place, though) &lt;TimStarling>	if you only want to add tags to the regular view of Special:Watchlist, and not filter by tags... &lt;MatmaRex>	(but i didn't read through the RFC nor the patch in the past, not sure how relevant it is) &lt;TimStarling>	or at least don't make the ability to filter by tags very prominent &lt;Elsie>	I think tags are the whole point of the RFC. &lt;TimStarling>	then it has quite a different performance profile &lt;StevenW>	Tags is perhaps a bad word here. We don't actually want to necessarily add user-visible tags to the watchlist UI itself. &lt;Elsie>	Tags are supposed to be the user-specific lists, as I understand it. &lt;TimStarling>	the expensive thing about the watchlist is the massive intersection it does &lt;Elsie>	StevenW: Then how will users create lists? &lt;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 &lt;brion>	these tags would be internal -- how they'd map to UX is left unsaid so far (to be determined...) &lt;StevenW>	Elsie: that ^ &lt;Nemo_bis>	MatmaRex: I think that comment is not more visible because its whole point is that the author feels nobody is interested &lt;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) &lt;Elsie>	I don't see how you keep them internal. &lt;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 &lt;TimStarling>	well, the RFC has things like: &lt;TimStarling>	Tags could be used to create a to-do list for editors (using structured data, as opposed to a simple wiki page). &lt;TimStarling>	Tags could be used to create a "read later" or favorites list. &lt;TimStarling>	Tags could be used to create reminders about pages (bug 582) &lt;TimStarling>	Tagging a page to be saved for offline reading could create a cached list for users on desktop or mobile devices &lt;bawolff>	Because ToDo lists you probably wouldn't show things by last edit &lt;Elsie>	bawolff: I'm not the correct person to ask. :-) &lt;Elsie>	I'm confused about this as well. &lt;Elsie>	I think this RFC needs further thought and consideration. &lt;TimStarling>	those applications are all pretty cheap, they don't require massive recentchanges joins &lt;bawolff>	In any case, if we're not showing by last edit, the performance concerns become moot &lt;ori-l>	right. &lt;Elsie>	Presumably monitoring the pages on a user-list is a goal. &lt;Elsie>	Okay, we should move on to a different RFC. &lt;Elsie>	sumanah: What's next? &lt;ori-l>	hang on &lt;bawolff>	Of course if we're doing that, we should consider if people want things alphabetical using a collation &lt;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. &lt;sumanah>	== Retained account data self-discovery == &lt;sumanah>	* https://www.mediawiki.org/wiki/Requests_for_comment/Retained_account_data_self-discovery &lt;brion>	shall we mark that down and continue? &lt;brion>	yes :D &lt;TimStarling>	sumanah: please ignore Elsie &lt;ori-l>	sorry, give me a minute to form a sentence, I'm a bit slow &lt;TimStarling>	we should spend another 5 minutes on this, I think &lt;brion>	fair enough &lt;sumanah>	TimStarling: done. &lt;StevenW>	Would it help if I explained the genesis for this? What problem we encountered? &lt;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 &lt;StevenW>	ah, go for it ori :) &lt;ori-l>	it ensures users always have a low-level ability to modify / remove / edit tags &lt;manybubbles>	ori-l: this raises my leaky abstraction warning bells &lt;ori-l>	but it's not expected to be the interface that actually delivers added value &lt;TimStarling>	ori-l: the massive intersection in Special:Watchlist will probably ultimately need to be moved to some other storage backend &lt;cscott>	brion: +1 &lt;AaronSchulz>	probably &lt;TimStarling>	so it probably makes more sense to provide a unified UI for editing lists which is independent of storage backend &lt;TimStarling>	and can edit lists whether they are in the watchlist table or not &lt;StevenW>	potentially &lt;StevenW>	watchlists as they exist are extremely confusing to many users, including otherwise experience people. &lt;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. &lt;TimStarling>	the modify UI, or the read UI is confusing? &lt;sumanah>	I would say both. &lt;StevenW>	creating many hand-edited lists may turn out to be a bad idea for all but a tiny few. &lt;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 &lt;TimStarling>	StevenW: you mean as opposed to sharing, watching categories, etc.? &lt;sumanah>	http://mw-watchlist.tumblr.com/ has some additional thoughts for those who want to read them, on watchlist UI stuff &lt;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 &lt;Elsie>	Or a coherent path forward to address the users' needs. &lt;TimStarling>	ok, let's resolve to expand this RFC somewhat &lt;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. &lt;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? &lt;TimStarling>	and I will add some comments about the potential need to abstract the backend &lt;StevenW>	yes to both cscott and Tim &lt;TimStarling>	ok, next RFC &lt;brion>	+2 &lt;ori-l>	yeah, that's good. &lt;ori-l>	thanks &lt;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 #topic support for user-specific page lists in core
 * 22:25:33 This is Ori & Steven's RfC.
 * 22:25:34 #link https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_page_lists_in_core
 * 22:25:42 #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 fwiw, this work is probably getting rolled into an EducationProgram rewrite
 * 22:26:20 #info TimStarling said "I will add some comments about the potential need to abstract the backend"
 * 22:26:30 #info Adam Wight relates: "this work is probably getting rolled into an EducationProgram rewrite"
 * 22:26:36 awight: around whennish?
 * 22:27:06 sumanah: I don't know if that's on the roadmap yet, currently the work is focused on generalizing Campaigns
 * 22:27:24 AaronSchulz: perhaps you can speak on behalf of your performancey colleague ;-)
 * 22:27:29 But the big picture is that StevenW wants to add functionality like the user page lists as components.
 * 22:28:37 i like the basic idea; there’s some open question about how tags would be managed though
 * 22:29:07 looks like we won't have ori or StevenW in this chat today. That's ok
 * 22:29:08 …and someone might have to take a flamethrower to some existing watchlist code to clean it up
 * 22:31:22 awight: do you need Tim to follow up on making comments re abstracting the backend?
 * 22:31:41  brion: it could work, though it inherits all the sorting problems watchlists have now
 * 22:31:48  though brad already mentioned that it seems
 * 22:31:51 *nod*
 * 22:31:57 sumanah: I'm pretty far from that work, but mentioning the complications would be a good idea.
 * 22:32:13  reminds, we figured out a fix for the externallinks thing he mentioned...someone should do that :)
 * 22:32:40 #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 (sounds like we can move on pretty soon to Nonlinear versioning which will be candy to some folks)
 * 22:33:52 #action someone should consult AaronSchulz and anomie re how to fix the externallinks issue
 * 22:34:02  well that's not actually related, it just reminded me
 * Sharihareswara (WMF) (talk) 11:24, 10 April 2014 (UTC)