Talk:Architecture focus 2015
Add topicLate assembly
[edit]Another possible use case for late assembly: sometime in the next 5-10 years I'd hope we can deliver pages tuned to user interests. (ref Lila's last strategy sheet: serving content "personalized for language, location, preference"). Nowadays the reading experience is 'one page content fits all'. Other social knowledge sites (Khan, Coursera) do a much better job in monitoring each person's needs and progress. *Wouldnât it be great if content could be offered based on a person's self asserted knowledge and interest level?* I would love to be able to tell Wikipedia that I want math/physics articles on a medium level of difficulty, without too much in depth coverage, and without loads of formulas (even for math), and at the same see history/geography articles with plenty of detail. That would require tagging paragraphs by level of depth, but also would require a smart cache. Erik Zachte (WMF) (talk) 13:06, 24 June 2015 (UTC)
Comments
[edit]Since I'm, as usual, not likely to make the IRC meetingSince I wasn't around to even see the announcement of this being discussed for last week's RFC meeting, I'll throw some comments here.
- Re late/edge assembly of content (you have this discussed in at least two places): See phab:T99088#1342340 for some comments.
- Re trying to pull stuff like categories out of wikitext: This sounds good, although I worry that it wouldn't be able to support stuff like template-added categories that depend on the parameters passed to the template. For one simple and widespread example, enwiki's {{citation needed}} adds a subcategory of en:Category:Articles with unsourced statements depending on the
|date=parameter.- In other words, a disadvantage of separating such stuff out from wikitext is that you may have to reimplement parameterized transclusion and conditionals (including everything Scribunto gives us!) in each separated thing.
- Re change propagation: See phab:T102476#1410026 for some comments.
- Re testing: Another big problem is that we have a lot of code with no tests, because we didn't really start caring about tests until we had a huge code base.
- Re TitleValue in particular: I've seen it be less than useful in practice (which hiders adoption) since it was specifically created not to be able to handle all kinds of Titles that existing code needs to handle. Let's avoid making that mistake again, shall we?
- Re the idea of requiring anyone using MediaWiki to run it out of a VM of some sort: Oh please no. Untarring/cloning core + skins + extensions + libraries (or using composer) is already bad enough along with setting up externally-supported software that's usually packaged by the distro such as MariaDB and Apache. Let's not force everyone who wants to use MediaWiki to either have the ability to run everything from a VM, or to somehow "unpack" the VM onto bare metal that might be wanted to be used for stuff other than MediaWiki too, or to figure out how to install and configure all sorts of custom services that are being included in the VM because setting them all up right is complicated.
- That's not saying that the ability to use all sorts of extra services for improved performance or advanced non-essential features shouldn't be an option. After all, WMF needs that sort of thing. But let's not kill the ability for third parties without our Ops team to be able to use MediaWiki at all.