Moving (even part of) the presentation layer outside of MediaWiki raises quite a few questions we have to make important decisions about.

But in the case of Wikidata, I can see how an exception could be made:

• It's not part of the core functionality of MediaWiki
• Its UI is notably different from everything else MediaWiki does, to the point we could argue it's a completely distinct UI from the main one

So I think it's justifiable to choose to go in the direction of a separated frontend in this case, from an architectural point of view, without the need for further discussion.

Personally, I'd like to get a more detailed description of how you plan to integrate parts of the UI you will still get from MediaWiki itself - the original plan I saw considered ESI, which is not a solution we (SRE team) like much.

A quick note on how Wikidata is different, particularly from Wikipedia:

The Wikidata website is primarily an editing tool. It doesn't really have readers, the information is mainly displayed elsewhere, e.g. in Wikipedia articles.

This means the performance trade-offs are completely different from those of Wikipedia: making things cacheable for anonymous readers is far less important, Wikidata relies far less on the CDN layer cache. I don't have any numbers though, it would perhaps be useful to have some measurements on this, to make informed decisions.

UPDATE: my math is so very wrong below, it should be 0.24% of pageviews, not 24%, sorry

A few quick stats to contextualize @daniel's point above. Wikidata has (rounding for simplicity) 400 million edits [1] and 900 million pageviews [2] over the past 2 years. This represents 43% of all edits and 24% of all pageviews. So Wikidata definitely skews more towards editing. It's possible most of the pageviews are actually part of the editing workflow, indeed you'd expect at least a couple of pageviews for each edit. We could confirm this by looking at actual requests in the webrequest table. I'm happy to do that if I could pair up with someone who knows wikidata urls.

[1] https://stats.wikimedia.org/v2/#/wikidata.org/contributing/edits
[2] https://stats.wikimedia.org/v2/#/wikidata.org/reading/total-page-views

24% of all wikimedia pageviews are for Wikidata? I find that extremely surprising. Is that on the app servers, or does it include CDN cache hits?

It's even more surprising since most edits on Wikidata are done by bots (which don't trigger page views), and since you can make many edits to an item without reloading the page. Wikidata having twice as many views as edits sounds about right, but Wikipedia has a few hundred times more views than edits, right? So the number of Wikidata page views should dwindle compared to Wikipedia page views... Am I reading the numbers wrong?

According to the linked url (total-page-views) Wikidata had 900M views in the past year, vs 183B of English Wikipedia in the past year. Not including the other wikis, that would mean Wikidata could at most be ~ 0.4% of page views. Right?

@Krinkle Honourable Mr. addshore did some back-of-the-envelope math here https://phabricator.wikimedia.org/T212189#4838090

oh man, revoke my arithmetic license, classic off by 1000 error, sorry about that, edited my comment above, it's 0.24%

So, in conclusion, Wikidata has a lot of edits, but several magnitudes fewer views than a Wikipedia of comparable size. So, while MediaWiki generally optimizes for heavy read loads, the Wikidata UI should be optimized for frequent edits, but doesn't have to worry about performance of reads too terribly much. It may for instance be feasible to entirely bypass or ignore varnish caching for Wikidata.

In T213318#4885332, @daniel wrote:

So, in conclusion, Wikidata has a lot of edits, but several magnitudes fewer views than a Wikipedia of comparable size. So, while MediaWiki generally optimizes for heavy read loads, the Wikidata UI should be optimized for frequent edits, but doesn't have to worry about performance of reads too terribly much. It may for instance be feasible to entirely bypass or ignore varnish caching for Wikidata.

Sounds of DBAs screaming in horror

Jokes aside:

• we do caching at the edge for client-side performance, not just to alleviate the load on the servers. Our non-cached performance is already abysmal, I would add to it
• unless there is a strong reason not to, we do not want to avoid caching to reduce the server-side load, which in the case of wikidata doesn't come from its own pageviews alone
• Wikidata is already an unicorn, let's not make it even more different from anything else

In T213318#4880414, @Joe wrote:

Personally, I'd like to get a more detailed description of how you plan to integrate parts of the UI you will still get from MediaWiki itself - the original plan I saw considered ESI, which is not a solution we (SRE team) like much.

Sorry for the possibly disappointing answer: From Wikidata dev team perspective, we're not really have a particular opinion on what would be the best way of integrating/building up the UI together (i.e. to move away from doing it from inside MW): whether it would be ESI, the other node-powered solution you've mentioned @Joe, or something else. We are really agnostic to the actual way, clearly we see a reason to not have the Wikidata UI service called from inside PHP MW process as a permanent solution. We are happy to participate in discussion on coming up with the better front-end solution. At very least, we could provide input on what would be important features from Wikidata's perspective (as we see Wikidata use case is surely a bit different than e.g. Wikipedia one). That seems to be a topic for another RFC, though :)

Also, regarding skipping caching or not. We are not suggesting either way in scope of this RFC. Caching seems out of scope here. Of course, it is obvious to us that if metrics show that adding caching layer to any components makes sense, that seems like a great thing to do.

Do I understand this correctly, that this would add a mandatory Nodejs service to run a Wikibase installation? Is there no client side rendering support planned initially? As an sysadmin for couple of third party wikis (some of which use Wikibase) I am hoping that when Parsoid is ported to PHP, there would be no need for Nodejs for a "basic" installation.

@Nikerabbit The node service is only needed for server-side rendering. Client-side rendering should work without it.

@Nikerabbit so, if you don't have the node service, you have no support for clients that can't do the client side rendering, and no optimization for anon visitors. But it would still work.

In T213318#4888367, @Nikerabbit wrote:

Do I understand this correctly, that this would add a mandatory Nodejs service to run a Wikibase installation? Is there no client side rendering support planned initially? As an sysadmin for couple of third party wikis (some of which use Wikibase) I am hoping that when Parsoid is ported to PHP, there would be no need for Nodejs for a "basic" installation.

I would hardly define Wikibase as "part of a basic installation".

I think it would be fair for Wikibase to require a more complex software setup than running a simple wiki.

In T213318#4895739, @Joe wrote:

I would hardly define Wikibase as "part of a basic installation".

That's not what I wanted to say. It meant something like "meeting the user expectations of a modern wiki" which includes Visual Editor and these days, in my opinion, something for structured data as well (usually one of Cargo, SMW or WikiBase).

I think it would be fair for Wikibase to require a more complex software setup than running a simple wiki.

The setup (configuration) is already more complex, especially if you include the query service. Though, that kind of thing has a clear justification for needing an extra service, unlike the case of providing the primary user interface.

The non-nodejs fallback (even with limitations) addresses my concerns. I still wouldn't want this to become one of a kind, but rather have this architecture to be an example solution that also others can and will use.

The non-nodejs fallback (even with limitations) addresses my concerns. I still wouldn't want this to become one of a kind, but rather have this architecture to be an example solution that also others can and will use.

I agree that we shouldn't end up with a zoo of different front-end solutions. I wouldn't want to commit to this being the future, but I think it's a useful test case for one approach we might try out (namely, isomorphic JS for rendering).

Apologies for being impatient, but may I ask what is the status here (in terms of the RFC process)?

There has been some discussion in this ticket but questions raised seem to me to be either resolved during discussion, or not really in the scope of RFC (in which case this has also been pointed out).
I might simply be failing to parse some comments and notice the actual questions etc that need answering from WMDE side. Please point them out again, should this be the case.

We've also noticed that Technical Committee's meeting minutes from Jan, 9th mention that members of the committee are looking into the RFC (the non-really-RFC ticket being referred though).
Minutes from Jan, 16th and Jan, 23rd do not mention this RFC. There are other urgent topics, this is understandable. But as there is no Committee session this week (today), and there is not much movement on the ticket itself, we're feeling a bit lost on what's the status.

Is there anything we should still provide as requesters for comments? Is there any estimated timeline for processing the RFC that we could expect for?

Ping toward @daniel @Joe @kchapman @Krinkle 1 week on from the last ping to see if we can get some update :)

re above: We've managed to reach to @daniel through non-phabricator channel and are awaiting an update on the ticket after today's Technical Committee's meeting.

TechCom is moving this to Last Call ending on 20 February 1pm PST(21:00 UTC, 22:00 CET) with the caveat that this is an opportunity for Wikidata to experiment with this approach while TechCom discusses out to do Front End Architecture in a more universal/organized way. Also noting this introduces a circular dependency that should be resolved at some point.

Would this affect how SDC works? Wikibase's editing is already weird, with JS-based editing on the view page, and seems unlikely to truly fit in with a future core MCR editing model. This proposal seems like it might extend that weirdness to viewing too.

Other than that, T213318#4880414 seems to adequately summarize my opinion here. I'd be pretty skeptical of this as a general plan for MediaWiki, but since Wikibase is already very weird (and hard to set up) I find I don't care too much.

In T213318#4938904, @Anomie wrote:

Would this affect how SDC works?

SDC being Structured data on Commons?
If so then this should not affect commons at all right now. The initial part of the page for the JS based SSR only exists on Items and Properties, which right now are only on Wikidata.
The MediaInfo entity type on commons does its own thing.

Wikibase's editing is already weird, with JS-based editing on the view page, and seems unlikely to truly fit in with a future core MCR editing model. This proposal seems like it might extend that weirdness to viewing too.

I'm not sure how this RFC alters the future of possible MCR and Wikibase integrations? These changes to the frontend (at least for the foreseeable future) are not going to change the editing or viewing patters of wikidata at all.

In T213318#4939014, @Addshore wrote:

SDC being Structured data on Commons?

Yes, sorry.

The MediaInfo entity type on commons does its own thing.

[...]

I'm not sure how this RFC alters the future of possible MCR and Wikibase integrations? These changes to the frontend (at least for the foreseeable future) are not going to change the editing or viewing patters of wikidata at all.

I was only peripherally involved in SDC, my work was mainly on the MCR side of things.

We didn't have to create an MCR editing interface yet because SDC was planning to use Wikibase-UI-style editing, via JavaScript on the view page making API calls to edit the structured data. I don't know whether MediaInfo wound up reimplementing all the UI or if it uses Wikibase's UI classes and such embedded via MCR in the larger page. If the latter, it seems likely that it would be affected by this proposal to change how that UI is created and displayed.

Similarly, only one piece of SDC (captions) are currently deployed on Commons. I don't know what plans are for UI for the planned further use of structured data on Commons, whether it's more of the same as what's currently deployed or if it will be more like what's on Wikidata (with, potentially, more reuse of UI classes and such) but embedded via MCR's view logic in a larger page.

Thus, I raised the question here for discussion after I saw this mentioned in the TechCom Radar email, since it seems like a major change to code that the SDC project may be using or planning on using in ways that may not be compatible with those plans.

In T213318#4938904, @Anomie wrote:

Would this affect how SDC works? Wikibase's editing is already weird, with JS-based editing on the view page, and seems unlikely to truly fit in with a future core MCR editing model. This proposal seems like it might extend that weirdness to viewing too.

My understanding is that for now, as Adam points out, it does not. However, if the same technique is in the future used for rendering statements, this would likely also apply to statements on file description pages. Similarly, the captions UI may be changed to use the same technique as the termbox in the future, if this experiment looks promising.

As for the general plan for MediaWiki - I'm planing to set up a working group to discuss the future architecture of our frontend. This will certainly be one of the options to be discussed, but there are others, and several more angels and wrinkles to consider.

In T213318#4939014, @Addshore wrote:

... this should not affect commons at all right now. The initial part of the page for the JS based SSR only exists on Items and Properties, which right now are only on Wikidata.
The MediaInfo entity type on commons does its own thing.

True, but in a fairly superficial way. Duplication of rendering logic affects all wikibase entities including MediaInfo. We've implemented our own UI for captions for now (and are in the process of doing so for statements), but any re-architecting of the Wikibase frontend must consider MediaInfo/commons, and be flexible enough to allow different UXs for different user-facing applications

For reference: https://www.mediawiki.org/wiki/Wikibase/DataModel/Primer#Statements

In T213318#4895739, @Joe wrote:

In T213318#4888367, @Nikerabbit wrote:

Do I understand this correctly, that this would add a mandatory Nodejs service to run a Wikibase installation? Is there no client side rendering support planned initially? As an sysadmin for couple of third party wikis (some of which use Wikibase) I am hoping that when Parsoid is ported to PHP, there would be no need for Nodejs for a "basic" installation.

I would hardly define Wikibase as "part of a basic installation".

FWIW, this sentiment is very quickly changing. The biggest request/ask I got at Wikimania 2018 was to make it trivial to install your own Wikibase. (The context is that I was explaining to people how apt install mediawiki works, and the feedback I got back was whether it would also include Wikibase.)

Regarding the Structured Data on Commons topic: as per what's been stated in the last point of the "Solution proposal", we intend to move the whole of Wikibase entity page UI towards the new architecture. So that would include statement part of the item and property pages.
We want to stop using the old front end code and infrastructure, and finally, stop maintaining it/delete it. With how the current SDC UI is built, as @Cparle states, using the some "components" from the old Wikibase UI code this would indeed mean changes required to the SDC part as well.
There is no intention to drop the old UI "framework" over night of course. It will only happen once all relevant uses are moved to the new architecture, starting with the complete item and property page. This is definitely not going to happen in 2019.
We are quite convinced that once item pages have switched fully to the Single Patch Application approach, transition for other users should be easier. The server side renderer service would be there, handling what is required by non-item-page cases (e.g. statements).

BTW, we (WMDE) also intend to use the new architecture for the UI of lexeme pages, which currently party (i.e. statements) use the old framework. That's seems a pretty similar change as the one related to MediaInfo pages.

Also, re the MCR points above. I admit I am not an expert on MCR topics, but if I am not completely wrong, this proposal here does not change much when taking MCR into account. As long as there is an API which acts with the storage layer as MCR wants/defines, all would work.

Move towards implementing Wikibase/Wikidata UI as a Single Page Application (SPA) - written in TypeScript to mitigate the downsides of using an otherwise untyped language

This might be slightly pedantic, but I want to point out that JavaScript is not untyped it's just, like PHP, not strictly typed.

I would also like to point out that TypeScript does not provide runtime type assertions like PHP 7, it only provides static type checking at compile time.

The distinction might not make a difference to you, but I wanted to make it clear to anyone not familiar with TypeScript what it does and how it works. Personally, I don't find static typing as valuable as people claim it to be, and I therefor do not use TypeScript, but I'm not going to stand in the way of people who want to use it. :)

Also, I really appreciate that you would be preserving the HTML output with Server-Side Rendering (SSR). I think it's important that machines are able to read the page without JavaScript.

In T213318#4943828, @Legoktm wrote:

FWIW, this sentiment is very quickly changing. The biggest request/ask I got at Wikimania 2018 was to make it trivial to install your own Wikibase. (The context is that I was explaining to people how apt install mediawiki works, and the feedback I got back was whether it would also include Wikibase.)

A useful Wikibase (with query service etc) can already not simply be installed on a LAMP stack.
Getting Wikibase up and running with a blazegraph query service is in my opinion trivial (we provide basic docker images, that naturally also document the setup if you want to set it up without docker).
The SSR should not be a hard service to setup and configure (you can already give this a go).
Also somewhere in the plan we will have the client side rendering all hooked up, but this is not needed for our initial deployment, so naturally we are not currently working on it.
Edit: client side rendering using the newstuff is actually already implemented, i just missed it... So you will still be able to use and install Wikibase without the SSR service.

In T213318#4944035, @WMDE-leszek wrote:

Also, re the MCR points above. I admit I am not an expert on MCR topics, but if I am not completely wrong, this proposal here does not change much when taking MCR into account. As long as there is an API which acts with the storage layer as MCR wants/defines, all would work.

Doesn't a "single page application" mean that when the user clicks a link within the "page" it hits an API and updates the content without reloading a page? What happens when the Wikibase SPA is embedded in a larger page, which presumably wouldn't be updated when the SPA navigates?

In T213318#4947904, @Anomie wrote:

What happens when the Wikibase SPA is embedded in a larger page, which presumably wouldn't be updated when the SPA navigates?

Where does that happen? and by what mechanism?

Doesn't a "single page application" mean that when the user clicks a link within the "page" it hits an API and updates the content without reloading a page?

We are building an application that focuses on displaying and editing (in the next milestone) individual entity's information. Navigation from entity to entity will happen through traditional hyperlinks resulting in full page reload. The SPA idea consequently results more from different incarnations of the same "page", e.g. actions (view, edit) and status (e.g. editable, protected), implemented inside of it as opposed to different "pages".

What happens when the Wikibase SPA is embedded in a larger page, which presumably wouldn't be updated when the SPA navigates?

The SPA (if we want to keep focusing on this name) we are building is responsible for diplaying (and soon editing) of a specific part of wikidata entities' information. As no other part of the page it is embedded in shows this information no updates to it are needed because of the user journeys possible inside the SPA. This may or may not change in the future.

@Pablo-WMDE so to clarify (for my own sanity) this proposal is about unifying the existing logic (by rendering JavaScript on the server)?

@dbarratt Yes. But while it is the "existing logic" from a domain perspective it is indeed rewritten (in typescript).

In T213318#4948197, @Pablo-WMDE wrote:

Doesn't a "single page application" mean that when the user clicks a link within the "page" it hits an API and updates the content without reloading a page?

We are building an application that focuses on displaying and editing (in the next milestone) individual entity's information. Navigation from entity to entity will happen through traditional hyperlinks resulting in full page reload.

Ok, so not what https://en.wikipedia.org/wiki/Single-page_application describes. My concerns with respect to MCR don't apply to what you described (or at least not any more than they apply to the current Wikibase UI).

The SPA ... we are building is responsible for diplaying (and soon editing) of a specific part of wikidata entities' information

@Pablo-WMDE is implementation already in progress? If so do you have a phab task (or tasks) that I could take a look at?

@Cparle The implementation is underway, hence the service request (T212189) which in turn led to this RFC. The (sub) project board can be found here: https://phabricator.wikimedia.org/project/board/3620/ (completed tasks may not be shown by default)

Thanks @Pablo-WMDE

A useful Wikibase (with query service etc) can already not simply be installed on a LAMP stack.

Well, obviously you need Java for running WDQS, but otherwise it can be pretty easily installed on any common LAMP machine. Of course, assembling all configuration and service runners might be a bit more effort - but I think it is expected that if you want additional service, you have to actually run additional service :)

So you will still be able to use and install Wikibase without the SSR service.

Can we make it an explicit requirement? I frankly have a bit of a hard time imagining an IT person of the kind that commonly installs smaller wikis being able to efficiently maintain a zoo of services that we're now running in WMF. I think the model of "unpack the code, start httpd, welcome to the wiki world" should still be supported. Maybe not at 100% functionality, but at least basic things (like editing Wikibase) should work.

P.S. ideally I'd be also happy to make apt install wikibase-query-service work but that's a topic of a different conversation :)

Can we make it an explicit requirement?

I am not sure what requirement you refer to, to be made explicit.
I have an impression, we might be mixing multiple dimensions in the discussion here (happened multiple times in the internal conversations at WMDE, hence I am trying to be clear to differentiate between these).

1. For Wikimedia wikis (i.e. Wikidata, soon Commons) it seems required that users with no JS enabled in their browsers have a chance to read, and edit (with possibly limited experience, i.e. no fancy editors etc). To support this requirement, we provide server-side rendering service that renders the item/property page and sends HTML to the browser (of course currently via MediaWiki etc, but in the end this is what it is about).

2. Maintainers of non-Wikimedia running Wikibase might want/need to run their installation on "LAMP stack". That is, they will not be running node SSR service. Readers and editors will still be able to perform all the activities on the such wiki under the condition they have JS enabled in their browsers (with a certain "inconvenience" that they might not see parts of the page/just a placeholder until the JS load in and renders the UI). In this case we're leaving out possible readers and editors of non-Wikimedia wikis that are disabling JS in their browsers. This is the trade off we've found acceptable based on our understanding of non-Wikimedia users (here as in wiki maintainers, not readers/editors).

In T213318#4953461, @Smalyshev wrote:

I frankly have a bit of a hard time imagining an IT person of the kind that commonly installs smaller wikis being able to efficiently maintain a zoo of services that we're now running in WMF. I think the model of "unpack the code, start httpd, welcome to the wiki world" should still be supported. Maybe not at 100% functionality, but at least basic things (like editing Wikibase) should work.

Another solution to this problem would be to require Docker and Kuberneties which are both free and trivial to setup (especially if we distribute MediaWiki and all of it's services with Helm)

In T213318#4954262, @dbarratt wrote:

Another solution to this problem would be to require Docker and Kuberneties which are both free and trivial to setup (especially if we distribute MediaWiki and all of it's services with Helm)

Wikibase could require that. MediaWiki may require that at some point in the future, but for now, the minimum required platform is a vanilla LAMP stack with no root access.

Note that moving from "good old shared hosting" to a Kubernetes environment is not at all trivial to people who run a wiki for their kid's school or their sports team in their spare time. They may not be the target audience for Wikibase, but they are for MediaWiki.

In T213318#4954278, @daniel wrote:

Note that moving from "good old shared hosting" to a Kubernetes environment is not at all trivial to people who run a wiki for their kid's school or their sports team in their spare time. They may not be the target audience for Wikibase, but they are for MediaWiki.

I wasn't aware of that. Could we update the Principles page to reflect that?

In T213318#4954287, @dbarratt wrote:

I wasn't aware of that. Could we update the Principles page to reflect that?

I suppose so. That page isn't really authoritative, and hasn't seen substantial updates since 2013 as far as I can tell.

The platform requirements are defined by https://www.mediawiki.org/wiki/Manual:Installation_requirements. That page is not just descriptive, any substantial change to the platform requirements is a breaking change.

Another solution to this problem would be to require Docker and Kuberneties which are both free and trivial to setup

I am not sure setting up and maintaining a set of Docker containers would be "trivial" for a person we're talking about. It's not targeting a seasoned DevOp, but a likely part-time IT person probably on limited hosting, possibly with no root access and may even never have heard of things like "docker". LAMP stack comes preconfigured on most hosting solutions or Linux distros. But I am not sure docker is in this package now. I've skimmed through the docs at https://hub.docker.com/_/mediawiki/ and it didn't appear to be that trivial for a person with no docker experience, and I assume we're talking about adding many more moving parts to that.

In T213318#4955516, @Smalyshev wrote:

It's not targeting a seasoned DevOp, but a likely part-time IT person probably on limited hosting, possibly with no root access and may even never have heard of things like "docker".

Are our target demographics (and the reason why we are targeting them) documented somewhere?

I am not sure what requirement you refer to, to be made explicit.

Well, I now realize I am actually looking at two requirements:

1. Being able to run Mediawiki with basic functionality (reasonably defined by us) on a common LAMP stack, without root access. Does Wikibase fit into "basic functionality"? I'd like it to be. This obviously includes editing, since Wikibase install without editing is probably useless.

2. Being able to consume most of Wikimedia content (including Wikidata) with any HTTP client that understands modern HTML. Including ones lacking (or disabling) JS support, screen readers, bots, lynx fans, http-to-mail gateways, HTML->interpretive dance converters, whatever.

Having both 1 and 2 at the same time would be awesome, but I guess I'd also be fine with saying "you can have 1 but lose support for 2 or you can have 2 but then you need to have install beyond 1". By which I mean, if the install runs only minimum LAMP stack, basic functionality supplied may not necessary include all necessary for supporting 2. That would not be perfect but I think still OK.

Are our target demographics (and the reason why we are targeting them) documented somewhere?

I am of course speaking out of my personal experience with (some) people running small wikis (including myself many years ago). It may be we're not targeting them or caring for their needs currently. But I'd like to raise this question so if we forgo support for this category, we do it with open eyes and not by accident.

In T213318#4955529, @Smalyshev wrote:

Having both 1 and 2 at the same time would be awesome, but I guess I'd also be fine with saying "you can have 1 but lose support for 2 or you can have 2 but then you need to have install beyond 1". By which I mean, if the install runs only minimum LAMP stack, basic functionality supplied may not necessary include all necessary for supporting 2. That would not be perfect but I think still OK.

This is exactly the compromise we arrived at when we (the Wikidata team, which at the time included me) first discussed SSR for Wikibase a couple of years ago. From what I'm seeing, it still seems to be the basic assumption behind the proposed architecture.

In T213318#4955519, @dbarratt wrote:

Are our target demographics (and the reason why we are targeting them) documented somewhere?

I'm not aware of any concise and authoritative documentation of this, no. There are tons of discussions around this, on wikitech-l and other places. The most recent one I am aware of is at https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2018/Session_notes/Choosing_installation_methods_and_environments_for_3rd_party_users

In T213318#4955539, @Smalyshev wrote:

I am of course speaking out of my personal experience with (some) people running small wikis (including myself many years ago). It may be we're not targeting them or caring for their needs currently. But I'd like to raise this question so if we forgo support for this category, we do it with open eyes and not by accident.

It seems like there are a lot of Product questions related to MediaWiki that I don't have an answer to (and maybe someone here does?). Like, who are our target demographics? Why are these targets important to us? What does their adoption of MediaWiki gain us?

I do mostly look at software as art so I completely understand the perspective that: "This is art, and everyone should be able to use it!" and in some ways, I completely agree with that.

On the other hand (at least for those employed by the Foundation), this is real money that is being used by our "customers" (our donors), so I think it's important to know what our Product strategy is (I assume we have one, but I'm not aware of it). Without that, I don't know how we can make informed decisions about the platforms we should or should not support.

In T213318#4955592, @dbarratt wrote:

On the other hand (at least for those employed by the Foundation), this is real money that is being used by our "customers" (our donors), so I think it's important to know what our Product strategy is (I assume we have one, but I'm not aware of it). Without that, I don't know how we can make informed decisions about the platforms we should or should not support.

Congratulations, you have arrived at one of MediaWiki's central dilemmas. We have been pushing around that question for a decade.

Another thought about docker and similar technologies. PHP applications - and Mediawiki in particular - can be used on stacks way beyond Linux. I've seen PHP run on HP-UX, AIX, in mainframe containers, other weird setups. As long as our base requirement remains more or less only "PHP" (database is separable, so it's not a big issue), we may not be officially supporting this diverse category but we are serving them. There's a long tail of "weird" cases that our relatively low requirement footprint enables. If we ever changed it to "you need to run docker now" that would cut off some the "long" part of this long tail - all those weird cases that nobody would bother to support explicitly but that "just work" because requirements are low. Raising requirements has costs, we should be always mindful of it.

@Smalyshev again, it's impossible to justify (or not justify) a platform, because (afaik) there is no product strategy for MediaWiki. There's no "business case" to support a platform

Although, it is clear there is a business case (from the Foundation's perspective) to not support a platform (since supporting a platform the foundation does not use is a cost to the foundation without a justified product strategy behind it).

In T213318#4954262, @dbarratt wrote:

In T213318#4953461, @Smalyshev wrote:

I frankly have a bit of a hard time imagining an IT person of the kind that commonly installs smaller wikis being able to efficiently maintain a zoo of services that we're now running in WMF. I think the model of "unpack the code, start httpd, welcome to the wiki world" should still be supported. Maybe not at 100% functionality, but at least basic things (like editing Wikibase) should work.

Another solution to this problem would be to require Docker and Kuberneties which are both free and trivial to setup (especially if we distribute MediaWiki and all of it's services with Helm)

While it is a long-term plan to allow third-parties to use our own helm charts (yes, we're already using them in production, see https://gerrit.wikimedia.org/g/operations/deployment-charts/+/refs/heads/master ) I think that's a bit far in the future, and not our main focus in the effort of transitioning to kubernetes.

I do think that both in the short term and in the long term, having a single application written in PHP being able to do the basic job of a wiki is a must.

Now, I've been asking over and over to interested parties to come to a definition of what is we consider "the basic job of a wiki".

For instance, my definition would never include wikibase, but could include VisualEditor - and @Smalyshev's defintion is clearly different from mine. We need some on the product side to come up with such a definition so that we can make our tech choices accordingly. I would've opposed the creation of this service if I considered wikibase part of a basic installation.

In T213318#4956647, @Joe wrote:

I do think that both in the short term and in the long term, having a single application written in PHP being able to do the basic job of a wiki is a must.

By what metric are you using to come to the conclusion that this is a must?

In T213318#4957191, @dbarratt wrote:

In T213318#4956647, @Joe wrote:

I do think that both in the short term and in the long term, having a single application written in PHP being able to do the basic job of a wiki is a must.

By what metric are you using to come to the conclusion that this is a must?

@dbarratt, I think this is starting to get off topic for this particular task. As @daniel noted earlier, this is a central philosophical issue that "we" have been not-resolving for a decade or so.

For the purposes of this task, I think we can safely say that there's a strong current supporting @Joe's statement, and also a strong current that's more along the lines of "WMF staff should only spend effort on Wikimedia's use case", and leave trying to debate which one of those is "right" to a different discussion elsewhere.

With the Last-Call period ended on Feb, 20th 1:00 PM PST, and Technical Comittee having approved the RFC on the same day (per https://lists.wikimedia.org/pipermail/wikitech-l/2019-February/091589.html), I guess this RFC ticket should be marked resolved, or maybe moved to TechCom-RFC (TechCom-RFC-Closed) ? I don't know what is the process, please advise. Thanks!

Sorry about that. This is TechCom approved.

Can this be marked as Resolved?