 All right, I guess it's time, so So to give you a bit of background of why I'm interested in this topic I work for the foundation and I've been assigned recently to rewrite our so nailing code to turn into a service and so Yeah, yeah, but I mean this part is it's not gonna be the meat of it And and as part of that of course the question comes of How much are we going to still support the old way of making thumbnails? and Every time I brought this up the old debate of Is it the foundation's job to support third-party installs etc. Comes up very often It's not critical for what I'm doing, but I think It's a bit Annoying that this argument is used and comes up very often blocking projects or Making people not even think about doing specific things just because it's kind of in the way and it's really nebulous and clear And people don't really know What the consequences would be To make changes such as moving heavily to service-oriented architecture, for example for core so I'm gonna So we've explored really in-depth specific topics in the previous RSC discussions in the last few months That led to this but this time I'm gonna stick to The overall bird's-eye view and not get hooked down into the details which unfortunately tends to happen with this because it's a very broad topic and people tend to get rabbit-holed into specifics So I think it's fair to say that right now the foundation doesn't support properly or doesn't support at all No Linux deployment, share posting, etc and optional software that's not used in production basically anything that's not used in Wikimedia production That's how Greg summed up in the previous session, and I think it's pretty accurate So that's a problem for a lot of people And so this problem is often framed as service-oriented architecture versus a lamp stack Deployment and the fact that moving to services that are written in another language might mean That more and more of midi-wikis functionality wouldn't work on the lamp stack anymore I think this particular Battle so to speak comes up very often because it's the most prominent one as of late Shared hosting as it so it came up in the discussions that we had that shared hosting is very Different depending on which provider you're dealing with there's not really a Pattern or typical set of software that people in chart hosting have access to and in Common perception that we hear is that people are stuck with lamp and that's all they get And it doesn't seem to be true. I mean we've talked to Shared hosting providers as well as users who mentioned that It's quite common for them to request software to be installed when they need it And to kind of expand the horizons of what they can run on share hosting And I think in that area we really haven't tried to kind of make the needle move towards things that we might want to Turning to dependencies for midi-wiki That being said there's a cost to those hosts making more software available to their share hosting users and It might be impacting the price that people pay for the share of hosting like for instance If you go to provider and the cheapest option will be some basic PHP hosting with just my sequel And suddenly as a user you ask them to have Cassandra for example They might tell you fine will provide it, but it's going to be an extra five dollars a month And and that obviously is going to be a barrier to entry for some people And Something I think was very important is that the the audiences that we're dealing with in terms of third-party installs are very diverse Sure shared hosting it seems like from discussions we've had is that the the main reason why people pick shirt hosting is the cost performance ratio which is pretty much impossible to match with VMs for reasons that are due to the nature of shared hosting where a host typically will Pool different kinds of users on the same machines put like putting for example one heavy user with lots of light users Meaning that that heavy user actually gets more Performance out of their subscription and they still pay the same amount of the other ones Which is not something that's possible with containers or VMs or VPS is etc. Which means that when we Consider telling folks who are in shant hosting. Well, you know, just move to VPS or to Amazon web services or whatever So that you can install whatever you want The cost performance ratio is not comparable and it means that they're gonna have to put more money To serve the same traffic basically which means that even though new technologies that containers are coming up that might make Set up easier to people are willing to deal with the common line Those shared hosting users are not going away. They're still gonna have small we keys for those reasons and They're in the tens of thousands. So We have to take that into account into our decision-making So one easy thing that I think we could improve is the feedback loop which is Almost non-existent in the moment and there they can be several reasons for that So at the moment, it seems that we're getting very few bug reports from shared hosting users compared to the amount of people We're running we keys So if we're talking about tens of thousands of people running week is that way and it's so rare that we get bug reports from them There's a problem because Especially since they're running older versions of me you keep quite off like quite rare on in a lot of cases We should be getting more reports And I think something where we are not doing great is documentation especially if you consider Like the issue of software dependencies like we don't have a template to tell you which dependent which software dependencies your extension has You have to read the whole page to figure out what you need to do and how you need to configure it Etc. All that stuff should be a lot more simple and the other issue is that if you're Non-technical user and you've like clicked on a wizard on your hosting provider to install media wiki and That hosting provider has stripped off the media wiki logo, which is totally possible and replace it with theirs For example, and then you really have no way to figure out where to go to get help if you have a problem with wiki Unless you know what media wiki is etc. Which might require a level of technical knowledge that's beyond Going to a website and clicking I want to create a wiki So it's something we could do as well as having regular meetings with hosting providers, especially shared hosting providers They seem to show interest in that Thanks to the stakeholder group several of them showed up on the task for that debate And I think we should have the communication on an ongoing basis because we're making a lot of assumptions about what's possible and what's not possible And what the consequences of making big changes to core could be when we could just ask them Even though it's still very difficult to get in touch with the users directly at least we can get in touch with their providers All right so I think we need to start thinking about the different types of hosting because they're very different and especially in the context of For example Gabriel recently working on containers and making it a lot easier for people to deploy media wiki on containers Honestly given that historically The only thing we support is things that we have in production If we want to support more ways of hosting things we need to have them in production as well Even like the little the minimum we should have is test that run an environment that's similar and Verifies that our changes don't break that So that's why between parenthesis I put the ideas about where we could use things or where we might use them Now that are similar, so I think we kind of getting away with single hosts being Kind of supported Okay, just because most developers who work on media wiki Kind of run a single host machine in the form of a grant or instill on their machine So as a side effect that gets supported, but it's not a goal right now It's more like it happens that the easiest way to work on media wiki is to have a single host set up And so that means that this way of doing things is kind of supported But we clearly don't have anything resembling short hosting at wiki media and we could it's just a matter of Should we build tests for that or should we find some piece of infrastructure that we have that could be set up that way? But the question is should we and what would the benefits be to be doing that? and so my last slide is going to be Kind of provoking proposal, but I'm going to try and explain why I got to that point of my thinking So it seems to me especially given today's discussions with you guys who run wiki farms that the issue of staying with a lamp stack Doesn't really affect you in the sense that you have control over your servers and The main attraction for you to be on media wiki are the newest features and you're really interested in what's coming next so I assume that A transition to service-oriented architecture wouldn't impact you other than making it difficult to upgrade And that's really the area where the foundation can work the most and so This is a what-if slide So if if we wanted to get rid of that blocker that we have at the moment of The lamp stack and the fact that core has to run on it What if we decided at some point in the future to say that Media wiki stable version 1.2 whatever is going to be the last lamp compatible pure PHP implementation, but the trade-off being that we're going to support it for a lot longer than the Like recent stable versions that we do And the reason why I put that up is that when you look at what so the then The consequence of that is well, we're leaving shirt host users in the wind With the version that comes after that But if you look at the statistics statistics about The versions that people are running on shirt hosting a lot of them and actually the majority of them are running outdated media week installs and So far the main theory has been well It's that way because it's so hard to upgrade for them You know, they don't necessarily have SSH access So they have to export all their stuff go through some wizard on their hosting platform Hope fingers crossed that things things work and they have to upgrade that way, which is Risky and so they don't do it, but I think Something that should be studied and confirmed is might be that they're satisfied with what they have and That the incentive to upgrade isn't really there when you're running a very small wiki on shirt hosting because if you look at what we've released and the last couple of years and media wiki core itself as In the release notes, there's very little new features if at all like we've changed them defaults With done some tweaks with brought some small extensions into the fold But really there's no huge incentive to upgrade for them. Yes, I'm just gonna interrupt just a second for a point of process So the you've actually this is a consensus meeting. Yes, basically There is a proposal and you're looking to get consensus on this one proposal and it's more consensus on What we need to do this is just an idea and it's it would fall into different types of yeah I would I would say then this is more of a brainstorming meeting at this point I mean, I think but if you know if it's basically the sort of nebulous what what should we do? But maybe it's field narrowing and I think we can make it into a field narrowing conversation, but yeah Let's let's keep going. I'm almost done with speaking and then I'm gonna let everyone in the room have their say about that So my impression is that People on short hosting wanted they want a wiki They're not they mostly need want media wiki that we don't know and if we were to tell them that Version X is the last one they'll ever get on the lamp stack and then if they want to upgrade We offer a simple as simple as possible upgrade for them to move to a bit more expensive hosting So they could get all the nice new features It might not be as big of a problem as we think Because there might not be as wedded to media wiki as they're wedded to a cheap way to run a wiki In which case a cheap way of running media wiki 1.29 for example might cover Most of their needs if not all Which are different from people running wiki forms That's my points. And so what I think is really important that we could do is To work really hard on our upgrade Experience because Right now for wiki media. It means Making sure that the upgrade worse in production once for us and then that's it, you know There's no there's no follow-up work to make sure that this reproducible for other people that it's easy, etc and Especially for transition to a service-oriented architecture that specific Transition has to be built with third-party users in mind first and it should make things easier for us as well So that's where I'm at and now I'm turning the mics back to you about that general topic not necessarily So what what what so what is the thing if you want to do consensus? What is the what is the so? There should be an answer to that that we're trying to get consensus on yes What is the answer that you want to consensus on? What is the level of support that wiki media should provide and for what types of that's a question So if you have a question and you're not proposing an answer, that's not a consensus meeting. That's a that's just that's basically a brainstorming meeting Okay, and that's that's fine. We can have that kind of meeting I just want to make sure one of the things that reasons why is because like this Will be a mess if what you're trying to drive for is like get a consensus like decide and by the end of this meeting There's definitely not enough in the room to do that Okay, and that then that's my point is like let's make sure that that we're we're talking about like So basically this is more of an earlier stage meeting at that point. Yes I mean, you know such a big decision can't be made with The people who are in this room I think But we could have ideas about what we could do I think one Topic that came or theme that came up repeatedly in conversations with third-party users is that one of the big attractions of media wiki Is that it's the same software package and user interface as is used on Wikipedia? Lot of people that's their first contact with wikis. That's how they know to to use it And they want to use the same thing. That's very powerful features in there, too Now the feature the problem is as we develop new features like visual editor This is no longer part of the plain PHP install so a lot of third-party users don't benefit from all this new development work And so this these two experiences diverge For third-party users, and I think that's longer term right in the short-term that might be people who are okay with that But I think in a longer term Media wiki might lose this attraction of being the same thing as what they experience on Wikipedia There will be more one more features that are that they expect that are not there out of the box And so I think we need to find a way to provide keep providing people with the experience that they like on Wikipedia And have them participate in all the development work. We are doing the thing that they a lot of third-party users don't want us to spend a lot of money and maintain their own servers and Have a complex installation experience and Upgrades especially are a very painful topic. So a lot of them just don't bother because it's They've been burned once or twice and don't try again And so I think if we can address those things and give them the full experience I think then from a high level I think that we can Serve a lot of these third-party users pretty well. So I think I'm That is count that as a vote for your proposal, okay so last year Tim basically said that We're not at the point where we need to fork and I don't think like we haven't reached the point where it's like you absolutely We have absolutely features that you need non php stuff to run like Basic vanilla media wiki still works fine up your PHP and I don't think there's like some Critical feature that we want to implement that will require people to have not PHP and I don't think like I Don't see a set the point of like we have to fork now or Because there will be a significant amount of people who will still support the fork and that will lose developer traction for you know Whatever we continue with and I also think there are like There are a lot of things we don't support at all well like that could be dropped significantly earlier before you say like We're gonna drop shared hosting support like we support media weekend windows like that I think that would be like one of the first things to go before we like cut all ties on like pure PHP hosting Well, one thing I that was on the documentation slide is that I think we should be more explicit about what we do and don't support right now Because for people who are not in touch with the community they show up and they think it's gonna work fine with Buzz grass on windows and stuff like that and they try and they have a terrible experience Or as we could we could be really explicit about it and say this is Volunteer maintained and it might not be in good shape when you show up on the page and try to figure out how to make postgres work For example. Yes, definitely. I agree. I Can only talk to my experience, but it might be helpful. So I maintain a bunch of wiki farms Both within our corporate firewall as well as outside for partners to share information We create a lot of small Community wikis that are organized around a particular topic for a particular customer and So we provide the infrastructure and we provide We never provide just an empty blank page wiki. We also go through a modeling exercise We most of our wikis use semantic media wiki So we go through a semantic modeling exercise where we come up with using semantic forms forms for data entry different namespaces for different types of material so we Provide not just a wiki, but But a whole Infrastructure a whole something to hang their information off of to jump start their process of contributing content So I found myself spending quite a bit of time maintaining the infrastructure We do use a Custom-grown wiki farm approach where we share the media wiki code as well as the extension directories Across a number of different wikis on the same VM. So at least we don't have to upgrade individual wikis one by one But we so we're not in a shared hosting environment. We have our own VMs But I am responsible for maintaining, you know, making sure the OS is upgraded Maintaining and we do keep up to date with well, I have to say we're at 125 now I haven't quite gotten to the time to do the 126 upgrade yet, but we have developed a number of custom extensions that we use and That we have open-sourced that we have available to the community And so we spend time making sure that those extensions are updated. So this, you know, the last version Supporting lamp isn't going to work for us because we want to continually keep up to date with changes We contribute things to core. So we're obviously going to want to be able to take advantage of those Improvements to the infrastructure So I'm looking for an experience where I can upgrade more easily than I can today And going to a service-oriented architecture is a little bit Worrysome to me and I know that I will get benefits and I know I will love it when I'm there But please help me to make sure that that upgrade or the installation and upgrade experience is easy So that I spend less of my time maintaining our infrastructure and more of my time doing What is necessary and I love which is developing new extensions that can help our material really shine and that we can contribute to the community so I find Increasingly I'm spending time on infrastructure maintenance and less time on creative use of the technology and helping the community grow Makes sense. So there's a lot of overhead right now So The the solution you had suggested up there Drop support for pure PHP after 120 whatever Assumes that you have something that you don't have and that is a vision a roadmap for where media Wiki will be and Really the the way media Wiki Has developed is it's all based upon what the individual developer Wants to do has motivation to do sure there's features that you know wikimedia wants to implement like visual editor and partial but When it comes to core media wiki what really happens is whatever an individual developer whether it's wikimedia foundation or a volunteer has the stamina to do so It kind of makes me wonder about that, you know, oh, we're good. We're just gonna drop this and you know 129 How how would that work because we don't have that sort of governance model or anything? Yeah So, yeah, I think that's a question that needs to be settled first Yeah, that's true. I mean It implies a lot of coordination. This isn't making that doesn't we have structure at the moment But then I think we It was Kunal that had a Interesting point about what's the upside and then maybe we can turn to Gabriel for that. Well, I don't want to cut you off To we have we need to have a really good reason to do this We shouldn't do it just because it's new and It might make things a little easier for wikimedia developments It has to bring a lot of value to what's gonna happen after like right now Media wiki core is not moving at all in terms of features and maybe that could kickstart It moving again through the services that will be extracted from it, but I'm not sure so then again I think that comes back to we need a roadmap to say where this is going and why it's worth it Whereas right now. It's just a general idea of we should do that but without strong arguments of why we need that Okay, so basically the actual problem that we have up here is How it should be supported, but where is the problem? The problem is that we only wikimedia only supports what wikimedia has in production which is only a small subset of What people use media wiki for in the wild in the way they use it But why is that if you're looking at media wiki in the sense that it's another wikimedia project? Or did I say well media wiki that yeah If you look at a lot of the other projects that are also not the English wikipedia They don't get any real support for their users either So maybe it's just the same sort of thing as that is there's just no emphasis on it That's true, and I'm thinking there might be a government's a government. Yeah, right There's no vision for the other ones that don't know where they want to be because they don't really care about it so how do we get people who would Put more resources into this and the like to actually do that is Is that even possible? Do you want to speak to that? I mean in the previous session there was talk of Trying to start a media wiki foundation that would focus on those issues That why does this need a separate a separate foundation would say commons need one too because years well, maybe Or a chapter in that sense Because we have the example of the German chapter Having good independence and found a way to develop technology that I thought was needed and now we have wiki data Right and so that means that the same thing is probably possible for commons or for Small wikis that don't have a chapter at the moment. It seems very drastic But it it needs the thing is it needs people who are courageous enough to start the effort. I mean, it's it is you know, it's kind of far fetched to expect the foundation to Set up all these external things and then try and find people. I Don't run the foundation. I don't have an answer to that For you know, there definitely is charm case to be made for wikis that are officially part of wiki media for for sure The fact that commons doesn't get enough support as it is But then this is even further away from the state admission of the foundation media supporting media wiki the software is Not, you know for so that governments can run private wikis or Corporations is definitely not part of the state admission of the foundation What is part of it is all wikis that are part of the wiki media fold? So I totally agree with you on that and that there's a there's a No over focus on English wiki pedia, which is unhealthy But this question is more extreme because it's so far removed from the day-to-day Problems of the wiki media, but note not postgres support for example. We don't run postgres anywhere So, you know Sorry, go ahead. Um, could you move the slides back one to your suggestion? Which one do you want to see? The one with the hypothetical scenario. Oh, yeah, dropping support. Yeah so I Suppose I'm I'm just trying to get a clearer picture of exactly what problem we're trying to solve for here because a Couple of the examples I've heard brought up were about the visual editor and as far as I know visualizer is not part of media wiki core I should know that because I'm So I'm just trying to figure out why are we having hypothetical scenarios where we drop pure php support because of extensions Is media wiki call We're trying to add something to media wiki core that wouldn't currently work because of your php I guess there's also a big question. Which is where do you draw the line between the basic media wiki experience and Is that the tarball or is it core and the bundled extensions of the basic media experience? But then then there's a big question that's been going around for a while Is that should we make the part of the default experience even though it's a separate extension in terms of you know? Repository etc. It could be in the tarball. Well, it's still been optional extension So it really be a requirement to run media wiki So you wouldn't need to drop pure php support But I think for the issue is more with core and this is and I'm just Channeling things I've been hearing and I'm not affected by that problem So I cannot answer to why it would be useful to break down core into more parts Maybe some other people would someone else like to address that I mean I guess that's the biggest point to figure out whether that's a big problem or not in the long term Right. Yeah, right, but that means you basically you're proposing merging all wiki meter extensions into core Sure. Okay, sure Well, I think what's what's the agenda for this meeting like what is what is it just discussion or is It is just this one or like how how do you want the discussion? This is it? This is the agenda. I guess so I mean it is a very nebulous topic So it's really difficult to narrow it down specific proposals and I don't really want to do that You know and assume that whoever was in the room today was enough to make a decision about one of those things because I don't think that's the case But I think it is important to see how people feel about those ideas and that's why I thought it was useful to put Provoking suggestion up there to see what the general reaction is And then I've got something after Yeah Thanks for this interesting presentation. I I guess having I'm speaking on behalf of World University in school right now Which donated itself to wiki data this past autumn kind of through our own Organizational process were creative commons also But we're in a sense not wikimedia and we would conceivably want to develop a roadmap for wikimedia far-reachingly or be part of that process Out 10 20 50 hundred years in all 8,000 languages and 200 countries main languages as universities So if that could contribute to this conversation That would be my response to this query that would be part of this consensus process of us all speaking into this microphone at different times Beyond the we don't have monies yet and beyond the question of monies that you're raising World University in school has this kind of creative commons core side and Where revenue streams would come from a variety of different sources for free MIT OpenCourseWare Yale Open Yale course degrees for Universal translator for a 3d interactive film realistic virtual world with languages in it and then a commercial side And how that unfolds is a question, too But that could be part of this non wikimedia deployment question that could inform the wikimedia software Development ahead if we were part of this conversation as another contribution so Let me let me speak to Why the question of media wiki foundation comes up, especially because I've frequently raised it so the So by the way, this is Rob Lanfier the the reason why is because of Normalizing where the funding for our projects come from Relatives and where our fundraising drive comes from Relative to what we're trying to accomplish. So for wikimedia projects are excuse me for Yes, for wikimedia projects. It is a very straightforward thing People are generally don't especially for wikipedia because generally speaking when people donate to wikipedia they're donating because of Our mission and because of what wikipedia represents and as We move away from the mission or as we move away from our core sites Then it becomes harder to Justify the spending associated with what we're doing. It's not impossible to justify it It's just harder and so Part of what this session I would hope results in is in us sort of articulating a fundraising model and figuring out how to You know if the wikimedia foundation is the right foundation to raise money for For example intranet software for big Corporations on their intranets right like that's that's that's the that's sort of the extreme of things but Generally, that's that's the problem that we're trying to address Go ahead you were there first. Okay. Hi Honestly, I feel like this Like it needs more justification about why the status quo is Like not okay from where I'm sitting like it doesn't seem like I Can know this is this sort of idea has support for a lot of people and vaguely like it's felt that service architecture It doesn't work with the current situation, but ultimately for like this proposal feels like in some ways lacks justification of What the problem we're currently getting into with supporting these groups are like I don't know it feels like We're talking about taking a rather significant step without really Starting from the beginning and talking about like what sorts of thing benefits this would bring and Why we really want to do it if we wanted to do it like obviously that's up in the air, but I Don't know it feels like it needs some kind of foundational Like what is wrong currently kind of needs to be more fleshed out. I Totally agree with you Brian that this really needs to be fleshed out But again, this goes back to governance. How do we make decisions and what do we you know? How do we drive the development? Scott McCleod Is that how you say name? I just want to make sure He said that His organization could be involved in that discussion and that would be great because then we would have more voices in the You know what happens with media wiki and how do we make those decisions instead of just well media wiki is Wikimedia's baby that Wikimedia does whatever damn well pleases so there So I've heard a lot of people asking What is the problem that we have to suddenly have to decide this and My take on that is that there's kind of two things going on we've got the Defining the core media wiki experience We're really kind of pushing towards having visual editor be part of that, but visual editor depends on parsoid and There's They would take a lot of work, but it would be possible to make a PHP version of something like parsoid that visual editor could use but nobody wants to put in that work and And the second thing is that internal in the Wikimedia foundation there seems to be more and more of a push towards doing things outside of the traditional PHP stack pushing them into external services and Not really thinking about well, what would somebody can we provide this? Maybe not at the level that the WMF requires for their cluster But for smaller third-party wikis could we provide something that they could use? In PHP and that question is just no we don't want to put the work into that either so this question seems to come up just because We have a lot of things that would take extra work and WMF developers that are doing these services don't want to put in that extra work So they want to instead drop the support for Anything that's not the WMF cluster well, I think There's two parts one is as I said earlier. I think features that we develop Require some services and I think there are good reasons software architectural reasons why those are using services and Putting in the effort to also provide a parallel Implementation and PHP of everything that we do has a significant cost We can't basically using services allows us to use third-party existing third-party solutions like for thump nailing for example or for other tasks where other Organizations have the same needs we get to use math jacks for math rendering for example another foundation is maintaining that we don't have to do that work so there are big benefits in it for us and users want to have the same experience and but but I Think personally think that we can actually solve this problem if we take this seriously that we provide the same Experience with all the interesting features to third-party users at a reasonable cost and very simple right now I think we spent a lot of resources trying to Be compatible with all kinds of combinations of PHP Environment whatever there's a lot of complexity in there And I think the most if we want to optimize for given limited resources Provide the best possible third-party experience I Think we have to cut down on this all all these variables You have to limit the number of combinations we have to support because I think it's just impossible given the small number of resources we have and I think there are technologies that Enable that there are fairly new but already supported in all the major distributions like containers and Also the other development is that Virtual machines have become fairly ubiquitous and cheap So you can get a recently checked. I think two gigabytes Ram and 20 gigs of storage or so for three bucks a month Definitely five bucks a month. So it's it's no longer out of reach for most people and that's not that different from shed hosting so I Ultimately think that if we focus on providing a basic set of features that mirrors what they people expect on Wikipedia and Target the next generation of what people now use for for hosting I think we provide users with a better service There's also overlap with developer needs So this is not just for out of love for third-party users because we also need to set this up for continuous integration we need to set it up for development and So a lot of the work we can't be put into this can be used for our own purposes as well so it seems like the trade-off we'd be making if we did this is If we got rid of if we switch to service oriented architecture, we would probably lose the tens of thousands whatever of shared hosting people because Whatever we might hope for that probably not all that they're probably, you know a bunch of very non-technical people who for the most part are not going to go out and buy a buy a switch to a VM host and install a bunch of services even if we made a Ridiculously easy install because it's a clear technical difficulty step up regardless how easy to make it So it seems like the trade-off to think about is on one level What do we get from these shared hosting users? What rate do they turn into people who provide useful contributions to to media wiki itself? How often do they find it to be a gateway to contributing to us? to becoming core contributors to writing extensions that we find useful and This is all kind of from a you know what the foundation wants and its missions standpoint Obviously, it would be upsetting to a whole bunch of community people if suddenly they couldn't use it But you know from a what the foundation itself wants to do that's probably the the trade-off to consider Isn't the goal to collect the world's knowledge and yada yada all the world's knowledge is not in our projects open Open some of the open knowledge like even an open wiki. I usually does what fandom whatever All sorts of open it like there's an argument to be made that supporting media wiki for allowing people to set it up very easily is Part of the goals of our mission at least you can make an argument for that Because it's a form of collecting knowledge and it's enabling people to collect knowledge including those who have limited technical skills although that argument taking to its natural conclusions as we start like Be a hosting company, which I don't think is a good idea Yeah, so to to Brian's exact point that the right across the street here is the Gladstone Institute that runs wiki pathways Which puts and it's a public website So this is public knowledge and it's very useful knowledge It's biological pathways for like how an organism handles insulin for example But that's never gonna be on any wiki media site But it's still part of the sum of human knowledge. So if we're talking about you know a Mission Connectedness that is that is a big part of you know That is a benefit that you get Jill could you pull up the either pad? Oh, yeah I linked to an announcement that I made just before Christmas and that's a three-step install process for Media wiki with visual editor on the VM and it's basically you purchase a VM You paste command into the command line press enter and then you answer two questions And the first question is which domain is your wiki going to run on the other is should it update every night? so it is possible to Do this with modern technology on very cheap Hosting in very cheap hosting environments in a way that only requires the ability to copy and paste and click enter and answer Two questions. That's a screencast too if you want to Check it out Not not to be Brian Davis not to be entirely antagonistic to that was the link at the top or I don't know How many hundreds of active users and bug reports do you have on that and how many different Media wiki major version upgrades. Have you supported it through? That's a rhetorical question since it was announced just before Christmas But I think We've gone through one version upgrade that added slash API slash rest underscore v1 automatically overnight on all the labs VMs that followed the upgrades and It is definitely possible. Yeah, and I'm I'm I'm honestly not trying to be antagonistic But I am I guess trying to emphasize the point that it's a very new concept and to to base a a major decision change point on on a concept that's approximately Two weeks old and experience that I know that we've been talking about it for years, but That that's and then maybe it's 15 years from now, but we'll have debate about should we drop container support? So yeah, we have to be careful about the decision I guess and it goes back to my point that if we play with new things like that We really need to dog food it to a serious extent Otherwise and might suffer the same fate as shared hosting support in the long term. I think Kim asked why do we need a separate foundation to do this and I think and I think mark also said that it's in the foundations for the wikimedia foundations purview to support Shared hosting and like some of all knowledge But I think also third-party media wikisers have gotten frustrated at the foundation's lack of support and have entirely given up on the wikimedia foundation supporting it and now have basically come to the only solution being having a separate foundation and in some cases in like in my mind, it would be really nice if the wikimedia foundation actually decided to Support third-party users, but it's like I think we've given up on that entirely that it'll ever happen Yeah, I mean there's also a case to be meant for that and you know with the if the scope is Support third-party open content users, you know and and be in touch with all the people that we invite You know with that, you know, you guys are coming. So obviously we could do more than just invite you to those events And we know who those first partners would be, you know, we know which are the biggest Mijiriki deployments for open contents other than us So yeah, we could also make a case for Fighting for a team to be built to deal with those issues Focusing specifically on the needs of the organizations that we know Because we have you know, we have to focus still on open content and not And not focus on making it easier for a corporation to have a private wiki, which is really far from What people donate money to us for? Another way to look at it is So the mission is to help people host open content and Right now. So if you have another project, like you said that doesn't seem like it would fit in wiki media sites We could also consider the idea of being a host for open content wikis and I that would be a huge project, but if we if we venture into that area It would naturally make us work on Tools that support wiki farms because we would be essentially running our own wiki farm for whoever can justify their content is open knowledge and then that would be dog-fooding what you guys need basically and then kind of Solving that problem of helping third-party users who have similar needs But don't want to jump on the bandwagon of that farm that we're running ourselves Because obviously that can't be the only option possible But yeah, I think that's also something that we could justify as a project for the foundation that would as a side effect support third-party users by having A setup that's really similar to what farms are doing at the moment So it that that's an intriguing point But if you if you look at that wiki right there wiki pathways They have a ton of customizations done on an old version of media wiki click on create they they've done a Purely javascript Pathway creator they used to rely on people uploading. Oh, well, you don't have permission They used to rely on people uploading. I think Jeff's or S SVGs, but now they've developed javascript That let's let you do that And added it entirely on the website instead of You know on an offline tool And if you're if you were to develop Promote your idea of a wiki farm sort of thing you would have to To make it first, you know to make it really good. You'd have to say, okay Well, these people can deploy their own software on On the wiki farm, which maybe you know, that's fine, but But it will also give us some visibility into when we're breaking things because if that happens on our servers And we are responsible for the upgrades and rolling them out on that farm Then we immediately realize when we're breaking their extensions. So but but I also wonder how much how much of this? Oh, we're gonna control all the uses that we care about How much of that really fits in with the open source or even free knowledge? Mindset because why should you control all the uses? Well, this, you know, you could argue that it's still an open source project and And this you know control is relative if you're bringing all these users that are gonna be part of the fold So to speak and that are gonna be working with us on what the direction of the software should be You can also argue that China is a democracy To Brian's point about not basing a decision like this on on prototype software, I totally agree I think timeline That we have in mind here might be slightly different. I think Might be good to clarify when You actually think this might happen. So you said you said the urgency that this always comes back to that decision What's the urgency to? Move the line on what the core experience is I Think the urgency is to have a clear path forward that That we know we will be able to solve this problem and Have a way to prioritize these solutions so that we can actually make headway with limited resources Because otherwise we just kid ourselves and say hey, we support everything but actually we support nothing That's why I think in the short term it should really improve the documentation about how honest we are about what we support because we're not right now and there's a lot of kind of False promise and unsaid things on the pages where you just assumed they're gonna be able to do lots of things that you actually can't And you find out quite late that that's the case and we waste our own time by helping people on IRC that Encounter the same problems all over again having to deal with the same configuration mistakes repeatedly and We we waste other people's time. So I think we have to be very focused and how we want to solve this but I think we Have to get clarity soon about how we're going to solve this. It doesn't have to be solved For every very very soon it doesn't this decision on dropping support doesn't have to be made prematurely I think we should cross that bridge when we get to it But I think it would be good to have clarity on this is direction. We are moving and we need a solution for this and Be serious about actually making that happen So I would propose that If we if we are going to be clear about this then we need to be clear about this so in other words Like I think one of the things we're having is a game of chicken going on where where nobody wants to actually make a proposal with a date on it or And and because they don't want to be held to like well, yes We have to get these x amount of things done I think we can actually have a goal. We could come up with a goal today for When are we gonna? What what is our goal for when we should make a decision? by and And let's just talk about like what does you know, what's a what's our plan for a plan? Because right now we don't even have a plan for a plan Yeah, and I guess we need to a plan for how we're gonna make a roadmap If that's a dependency to making this happen in any shape or form or we're not making this happen How like what group of people should work on that and how should that happen? Mm-hmm, and I'll just throw something out there six months like okay, so by July 1st Like we're gonna have a plan for a plan. Okay? All right, and I think one of the other issues is we keep saying okay Well, we're gonna plan to make a decision, but the question is who is making the decision? Who is if we're going to decide we're going to support these platforms? We are gonna support these operating systems Who is going to decide that we're going to do that and the problem? I think right now is we don't really have any particular Particular governance structure where someone a committee or somebody or something can sit down and decide okay? well, we're going to drop windows support for the official media wiki fork and We need to come up with some sort of Idea that we're going that either the foundation is going to Set down as this is it or that the community comes to a consensus on and that we're going to follow this governance structure Where this group of people decides? What the future of the project is going to be? Regarding the timeline, I would actually propose to First demonstrate that we have a solution and then make a decision because I think that's a precondition for making this decision We shouldn't just make a decision. Oh, we said so half a year ago. We don't have a solution yet But we will drop support nevertheless. I think if we we should get serious about doing this now and If we see this is working then we can make that decision Really, I think it needs a concrete proposal here Before we start talking about who can make a decision a concrete Proposal that's discussed on wiki tech L as a prerequisite to any of that stuff like Some people are apparently interested in doing this. Well, they should make a proposal and Send it out with concrete Like it's up to the people who want this to make the proposal In my opinion so So for me a key thing that I don't know that I've I've actually heard said allowed here and I Probably didn't even type into fabricator because I'm a horrible horrible lazy person We have Perennial debates within the wikimedia foundation within the product development teams within the The architecture group within the developer community that lives within the foundation around the fundamental topic of Will new features that we're using Foundation money donor provided money to create Will will those features be Built with an eye towards usage anywhere other than the WMF production cluster and for me, that's the the root This is the root question behind that perennial debate And and I Thank you to Jill and and everybody else who brought some actual third-party voices into this discussion because I've I've played devil's advocate a lot of times on on IRC and in person about like well But no this guy who can't do this or or this this company that can't do that But to me that's the the point of the urgency is that every time we have that debate yet again When we're building a new piece of software We're wasting donor funds and we need to one way or the other either rip off the band-aid and say That all they all the work that the foundation pays for to go into the product Does not need to care about third-party concerns in use and can be focused on the foundations projects or That this is fundamentally a use case that always has to be present in everything we build and Then we don't have to debate it 25 times a quarter so In in our session, which is on the ether pads steak and wine we had We talked about and actually had people put skin in the game to start developing The way to rip off the band-aid which is creating the media wiki foundation Which we've all sat around and be asked about endlessly, but here we have people who are actually willing to do things To make a separate organization one that we don't have to worry about all these money issues So it can focus on media wiki for everyone and the foundation can focus on English Wikipedia To Brian's comment. I think the there's not actually such a big gap between What we need for developers for example and what third-party users need Developers don't want to run large clusters on their laptops to to test some simple feature They are very happy to use a sequel light back and Continuous integration similarly It's a lot simpler to use a sequel light back and then in testing and don't spin up like a huge Replicated my sequel cluster for example, so we are doing this work already and Doing it for our own reasons, but it also turns out to benefit third-party users So I don't think there's always this Big gap between what we need and third-party users need I see the biggest Gap really and how do we get this into the hands of users? Like how do we package it? How do we make it easy to install and upgrade? All right, I guess I'll fill the gap Um, so if you could scroll up in the etherpad and just look at the list of questions I've tried to I've tried to like keep this tight So between lines 15 and 35 There you go So this is the list of questions that I think we've explored so far, but there's still questions And I think one of the things that may be a good next step after this session is going to be to to Sort these questions figure out which ones are the important questions which ones are distractions and then and then Make a decision as to which you know what the answer should actually be But that would be what I would propose is a way forward on this is to it And do we have the complete list of questions here or not is my question to you It's hard for me to read from here. Let me let me read them out loud. Okay, so So this is this is basically what I was taking in real time as we were talking through this and Granted, I think I only started taking some of these notes a little bit into the session So I may have missed some of the things we've explored here But so which so starting at line 15 which hosting platforms are or should be supported Do we need to stick with a lamp stack? Can we decide some version and not too distant future be a quote last pure PHP implementation? Can we drop support for shared hosting? How do we make sure that non wikimedia users benefit should wikimedia fork? Media wiki if we if we move to requiring so a should we invest in supporting? non wikimedia installs and migrating is it worth Maintaining PHP versions of non PHP software for wikimedia deploys Does media wiki need a governance structure outside of wikimedia does wikimedia need to support? Non wikimedia use cases better does there need to be a quote media wiki foundation? What problems are we trying to solve by dropping pure PHP support? What's wrong with the status quo? What constitutes the quote full media wiki experience? How do we make the experience of installing media wiki result in something like editing wikipedia? How should non wikipedia works to be non wikimedia use cases be funded? Does is visual editor and parsoid part of the core media wiki experience? If so should the media wiki core requirements be changed to reflect that or could parsoid be ported to PHP? Can VM based hosts be a low budget solution that replaces shared hosting? Can we remove the delta between the setup for new wikimedia developers and the setup for low budget hosting? Should we put greater support behind Gabriel's media media wiki containers project? Should we put more effort behind other non wikimedia open content efforts and improve outreach to other open content efforts? Should wikimedia operate a wiki farm to improve wikimedia support for wiki farms? What's the urgency to move the line? What is what is our plan for a plan who gets to make the decision and our use cases off of the wikimedia foundation? Production cluster important. So those are the questions that I've captured now Now I think maybe the next step is You know partly just making sure does is that the list of questions? Is there anything missing from there and then which are the most which are the most important questions? I think is the next step to get the answer to So I think those are excellent excellent excellent questions And I do want to thank everybody here for participating in the discussion We've had some really really really good stuff both today and earlier or both right now and earlier today and I really would like everybody to Continue discussing as we work on this stuff and try to actually Sort of narrow things down into some real action points Yeah, the the one thing I was gonna add is should we operate a wiki farm, but it's already in there I'm very happy with these. I would love to actually Distill this a little more Maybe we actually want to Run a survey. I hate to say survey, but getting a better idea of What's the opinion out there both within you know our our core developers our third-party extension developers? And some other people running those wiki farms some of which we've spoken to today many of which we have not So yeah, I'm really happy with this set definitely the question of How to deal with services is sort of the core technical question the human question is how do we continue to Develop media wiki for third parties in a way that is both good for wiki media and good for everybody else My personal opinion is that we should be striving to make the media wiki core as clean and modular as possible I really like the idea that services can be Swapped out and replaced so if we have something that's very very popular like visual editor We want to be able to support it for many many people not just for ourselves Maybe that does mean that we'll have to make some changes to parsoid Maybe it means that we'll sort of recommend those people move towards the You know off-table idea of an all HTML wiki which would not require parsoid Another possibility of course is just you have providing parsoid as a service There's there's so many technical details. We're not gonna have time to get into the rest of them But I think we have a really good start here I would actually be interested to hear from third parties is here about their opinions and needs What's your take on this What are the biggest things for you on that list? so I just want to add from talking to people earlier today one big one is extension compatibility across versions So a lot of times because our extension interfaces aren't super great It's very easy to write an extension that digs into parts of the code base That maybe it shouldn't and they become very fragile So one thing that I want to think about is better extension interfaces To allow for cleaner compatibility so you don't have to go through and fix a million things as an Alternative or to go along with it, of course helping people to identify and fix their problems would be really good It I think would be very reasonable for To offer that as a service I think the ideas of For instance commercial support is additional funding for additional media wiki support is something we should explore Maybe that has to be outside WMF. There's lots of people talking about stuff where that could dovetail in So I will stop talking now and leave it to other people So from World University in schools perspective Sort of three or four main questions How can we be part of the governance process? What Test case possibilities are there to kind of question by question Identify which are most relevant as we move forward In the third aspect interlingually especially Planning for potentially all eight thousand languages and major universities in all countries main languages And in brief Well, I think I articulated some of the Our concerns earlier So certainly ease of keeping up to date with With core as as it progresses and I Was trying to think of how to articulate one of the other nagging points that I had and and Brian raised it Perfectly, which is you know, we do have a suite of extensions that we've developed and in addition So every time I need to upgrade media wiki version I also need to go through our extensions and update them in Ways that don't necessarily improve their functionality at all but keep them consistent with core and I have several Authentication extensions out there that are going to have massive changes coming up that That I'm going to have to invest time in figuring out how to do that. So and that's again not necessarily Giving us any benefit Aside from just keeping up with changes in media wiki core And I guess I'm not really complaining about that in the sense that I know that media wiki core has to progress And I know that this is necessary but when you add up the amount of time that I spend maintaining the infrastructure and In upgrading when a new version comes out and then making sure that the ripple effect of all of our extensions upgrading Again, I come back to my wine from earlier I want to be doing new innovative cool things and I'm spending a lot of time just Making sure that things continue to work the way they did before and I thought that the idea of Having wikimedia operated wiki farm what was interesting in the sense of yes, you know You certainly get you you to experience some of the issues that we have although I would argue that you've got a Suite of highly trained people that you know their bread and butter is keeping the software running and that's you know What you need to do is take somebody like me who's also trying to do another job and have them maintain the wiki farm And then you'll feel our pain But you know certainly having that infrastructure and I spent some time recently working on ansible scripts to So I can now point at an empty VM and spin up our wiki farm Infrastructure and if anybody would like to see those just to get a sense of how we construct our wiki farm I'd be more than happy to provide that One of the things that we find that when we upgrade it's not just So yes, we have to install you know upgrade the core media wiki software We have to upgrade the extensions, but then we need to go through all of our content and See how the content it's there's no Without visiting every page in every one of our wikis. You don't necessarily know that something broke So your your comment before was a very good one, but I would argue Having you host a wiki farm Does not necessarily mean that it will be immediately obvious to you when something breaks because unless somebody happens to visit The page where all of the sudden your tables all munged up or whatever Because or you know for us for semantic media wiki the query format has changed slightly and all of a sudden everything looks weird Or doesn't give you the results you expected Unless you happen to visit that page you're not going to know that it's broken And that's another thing that we've been struggling with trying to figure out a good way To test all of our wiki so that when we're going to do an under the hood Upgrade across all of our wiki farm infrastructure for all of our wikis for all of our users We would like to minimize the amount of screaming that's coming back to us afterwards With things as minimal as when we went to I want to say 1.25 somebody was really upset about the font change You know and if they're upset about something as minimal as that You know when their math formulas stop rendering correctly, that's going to be even worse. So So it's a multi-layered problem. That's the kind of things that I deal with on a daily basis All right, thank you It's true that our continuous integration Stuff is not is not really reusable by others So we have tests that check that kind of thing for wikipedia and other wikis that we run, but it's so like Buried inside all our infrastructure that you can't just it's not easy for you to take and adapt to your own side So I guess there's also a case to be made for our continuous integration Stuff to be made easier for people to take and apply to their own wikis. I Just want to talk about upgrading a little bit since Brian brought it up and one of the things I'm concerned about is that we are making these decisions on the premise that people are using near immediate wiki versions but if we look at things like wiki apiary we see that there's a large number of wikis still stuck on 1.16 and We don't have a very strong incentive for people to upgrade because a lot of the features are wikipedia centric And not necessarily for whatever their personal use cases and as a side thing that Tim pointed out was that Looking at he looked at like 1.13 and we haven't had any major RCEs in media wiki Since then so there's really no incentive from a security perspective for people to upgrade Which is a good thing, but also a not so good thing Yeah, I think it would be good to get to make it to do a survey about that like to figure out why people are sticking to the old Versions because we have different explanations, but we don't know what the main reason is Lots of theories, but no real data about it one quick comment about Parcyde and So it's just so people don't have under list unrealistic expectations Porting parcyde to PHP is a really non-trivial problem and that's not going to happen any time soon Simply because PHP for example does not even have a HTML5 parser And if you had to do it in PHP, we wouldn't have happened either. So I mean there are practical constraints as to why it's not in PHP and I have mentioned this on the fab task as well As on mailing this thread so just to be clear That I wanted to record it on the as part of this. Thanks All right, should we wrap this up and go to the bus? All right. Thank you everyone