ArchCom: defer due to lack of availability of Adam Wight.

Wondering what this is blocked on... this is something mobile is keen to explore.

Unless anyone objects I'm keen to have a good at implementing this cc. @brion @ori

I'm kicking this off in https://gerrit.wikimedia.org/r/#/c/183370/ after a chat with @ori

So the Gather extension is currently in the process of being built. I'm hoping through that we can develop requirements and a proposal for how to structure a Watchlist 2.0 table at the end of this quarter.

I think iterating within the Gather extension is far safer than iterating on established stable code. We are hoping to build Gather with a database table that is compatible with the existing watchlist table with the view that in future we could import existing watchlist entries over to it. Does this sound a sane approach?

Do we have a list of the existing list-like things in the MediaWiki universe? What comes to mind:

• watchlists
• Collection (uses internal links on arbitrary wiki pages, examples)
• Gather (custom DB backend, API and UI)
• MassMessage lists (cross-wiki, structured wiki page with its own content handler, example)
• PagePile (external tool on Labs)
• dynamic lists (categories, DynamicPageList, semantic whatever, wikidata phase 3)

This RFC seems to be stalled. If there is currently no interest in driving this further, it should for now be removed from the RFC work board.
If there is interest in continuing the RFC process, please let us (TechCom) known who will be working on this RFC, and who commits to implementing it if approved, and in what time frame.

Perhaps it would be more useful to discuss how this relates to T164990: RfC: Reading List service, especially considering that reading lists is intended to allow offline pages to be updated when needed - which is equivalent to watchlist functionality (notification of edits).

The reading list service is cross-wiki and as a consequence it does not deal with "pages" in a way that would be meaningful for MediaWiki, just title strings. It would be nice to have a concept of remote pages but it's blocked on a large number of things (wikifarm support in MediaWiki sucks; most Wikimedia projects are not interwikis of each another; things like title validation are hard-coded to use the config for the current wiki etc) so I don't think it's a good idea to complicate this discussion with it.

@Tgr To me, what you just said is a very good reason to have that complicated discussion and remove those blockers. There doesn't seem to be enough "drive" behind the request for multiple traditional watchlists. Perhaps synergy with offline reading capabilities would fix that.

@Tgr do you think it is useful to keep this in the RFC process as it is now? Is there any commitment to work on a solution? If not, the RFC should be removed from the process for now.

In T1352#3887896, @daniel wrote:

@Tgr do you think it is useful to keep this in the RFC process as it is now? Is there any commitment to work on a solution?

If someone is interested in figuring out what exactly would be needed to cover both this and cross-wiki lists like the reading list service, I can work on that. If you mean commitment for actually developing that functionality, I don't think so (although maybe easier to say once we know what it is).

I still think a separate RFC about foreign pages or wikifarm configuration management would be easier to handle though.

In T1352#3888362, @Tgr wrote:

I still think a separate RFC about foreign pages or wikifarm configuration management would be easier to handle though.

Which have significantly more opportunities for synergy as well (shadow namespaces for global templates / gadgets / whatever in the first case, third-party wikifarm management in the second).

The Growth-Team is moving this to external as this seems to belong to TechCom

This RFC was marked as stalled last year. The old RFC above is from 2013 and describes a specific implementation in fine detail. What's lacking is someone to drive the proposal and/or the implementation, starting with picking one or two use cases that it unlocks so that we contributors here on the task can work together towards making that possible (with that implementation or with something else).