 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 sound 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 unclear 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 bogged 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 Non-linux deployments, chart hosting, 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 a 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 Deployments and the fact that moving to services that are written in another language might mean That more and more of MediWiki's functionality wouldn't work on a 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 Turn into dependencies for MediWiki 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 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 find 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 going to 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 weekies 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 share hosting users compared to the amount of people We're running weekies So if we're talking about tens of thousands of people running weekies 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 media we 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 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 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 something we could do as well is 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 parentheses. 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? You kind of run a single host machine in the form of a grant or install 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 decide that 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 then 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 short 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 short 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 short hosting because if you look at what we've released in the last couple of years in media wiki core itself as In the release notes, there's very little new features if at all 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 there is there is a proposal and you're looking to get consensus on this one proposal It's more consensus on what we need to do. This is just an idea and 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 did 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 farms. 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 works 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 it's 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 to Mike's 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 We're gonna make a decision. They're 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 our 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 our 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 a 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 plane 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 and 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 burnt ones 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 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 both grass On windows and stuff like that and they try and they have a terrible experience Or as he 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 Um, so I'm looking for an experience where I can upgrade more easily than I can today Um and going to a service oriented architecture is a little bit Worrisome 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 It makes sense. So there's a lot of overhead right now. Yeah So, um, the the solution you had suggested up there, uh 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 parsoid 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 going to drop this and you know 129 So 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, uh It implies a lot of coordination. This isn't making that doesn't we have structure at the moment um But then I think we I think 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, but To we need to have a really good reason to do this We shouldn't do it just because it's new and Uh, it might make things a little easier for wikimedia developments It has to bring a lot of value to what's going to 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 about 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 I say well media wiki, but yeah When 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 think that might be your government's Yeah, governance issue there 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 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 But why does this need a separate foundation would say commons need one too? Because years well, maybe Or 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 Smaller wikis that don't have a chapter at the moment That 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 Um, 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 fold 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 the 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 An over focus on english wikipedia, which is unhealthy But uh, this question is more extreme because it's so far removed from the day-to-day problems of the wiki media But no 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 about 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 visual editor is not part of media wiki core. Um, I should know that because I'm a visitor developer So I'm just trying to figure out why are we having hypothetical scenarios where we drop pure php support because of extensions um Is media wiki core We're trying to add something to media wiki core that wouldn't currently work because of Pure php or 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 ve 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 would 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 do 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 wikimedia 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 And is it 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 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 Yeah, let him speak and then I 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. We're 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 100 years In all 8,000 languages and 200 countries main languages as universities So if that could contribute to this conversation Um, 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 open courseware Yale open Yale course degrees for A 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, um, 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 landfier. Um the The reason why is because of Normalizing where the funding for our projects come from Relative 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 sort of the extreme of things, but Um, generally that's that's the problem that we're trying to address Go ahead. You were there first. Okay. Hi. Um, like 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 a 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 um, 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 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? um, scott mcclode Is that how you say name? I just want to make sure um He 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 It 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 uh 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 um There's two parts one is um as I said earlier. I think features that we develop Um require some services and I think there are good reasons uh software uh architectural reasons why those are using services and um 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 um 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 um so there are big benefits in it for us and users want to have the same experience and but but uh 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 Spend a lot of resources trying to um Be compatible with all kinds of combinations of php Environment whatever there's a lot of uh 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 um I think there are technologies that uh enable that they are fairly new but um already support in all the major distributions like containers and um Also, the other development is that um virtual machines have become fairly ubiquitous and cheap So you can get a recently checked, uh, 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 Um, I think we 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 um, 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 switched to service oriented architecture, we would probably lose the tens of thousands whatever of shared hosting people because Whatever we might hope for they're 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 it get switched 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 of how easy you 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 mission 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 Some of the world's knowledge is not in our projects. They still need media wiki some of the open knowledge like Even open wiki usually does what fandom whatever All sorts of open 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 going to 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 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? Yeah I linked to an announcement that I made just before christmas And there's a three step install process for media wiki with visual editor on a 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 um brian davis not to be entirely antagonistic to that point was the link at the top or 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 vm's 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 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 to this 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 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 and 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 met 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, they 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 Media wiki 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 um 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 um We could also consider The idea of being a host for open content wikis and By 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 um 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 um, 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 uh purely javascript Pathway creator They used to rely on people uploading. Oh, wow, you don't have permission They used to rely on people uploading. I think gifs or fs svgs, but now they've developed uh javascript Uh that let's let's you do that um and added it entirely on the website instead of Uh, you know 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 person, 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'd immediately realize when we're breaking their extensions. So but but I also wonder how much how much of this Uh, 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 Uh, and this you know control is relative if you're bringing all these users that are going to be part of the fold So to speak and that are going to be working with us on What the direction of the software should be Um, you can also argue that China is a democracy No To brian's point, um about not basing a decision like this on on prototype software. I totally agree Um, I think timeline Uh that we have in mind here might be slightly different. I think um might be good to clarify when You actually think this might happen. I don't know. 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 um I think the urgency is to have a clear path forward that um 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 um 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 assume that you're going to be able to do lots of things That you actually can't you find out quite late that that's the case And we waste our own time by helping people on the rc 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 um 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 um And let's just talk about like what does you know, what's a what's our plan for a plan? Um, 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? 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 um 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 going to 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 um if we we should get serious about doing this now And if we see this is working then we can make that decision um Really, I 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 is 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 um I probably didn't even type into fabricator because I'm a horrible horrible lazy person um 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 womf 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 gill 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 pad steak and wine We had We 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 end Continuous integration. Similarly It's a lot simpler to use a sequel light back end and and 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 usual if you could scroll up in the ether pad 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 might 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 Um, 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 Uh, it's hard for me to read from here. Let me let me let me read them out loud. Okay, so um So, uh, 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? Um, can we decide some version in the 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 a 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 me non wikimedia use cases be funded? Does is visual editor and part of the core media wiki experience? If so should the media wiki core requirements be changed to reflect that or could part so I'd 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 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 produce 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? Um, I think is the next step to get the answer to So I think those are excellent excellent excellent questions Um, and I do want to thank everybody here for participating in the discussion Um, we've had some really really really good stuff both today and earlier or both right now and earlier today um 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 um Yeah, the the one thing I was going to 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 uh 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 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 Uh, my personal opinion is that we should be striving to make the media wiki core as clean and modular as possible Uh, 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 uh, 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 going to have time to get into the rest of them Uh, 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 Thanks for you on that list So I just want to add from talking to people earlier today one big one is Uh extension compatibility across versions Uh, so a lot of times uh 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. Uh, 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 Uh, it I think would be very reasonable for So to offer that as a service Uh, I think the ideas of uh, 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 and school's perspective, uh Sort of three or four main questions. Um, how can we be part of the governance process? What um test case possibilities are there to kind of uh 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 In in brief Well, I think I articulated some of the um 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 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 um 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 um having wikimedia operated wiki farm 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 this off for 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 um 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 um One of the things that we find that when we upgrade it's not just um 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 What if 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 table's all munged up Or whatever because or you know for us for semantic media wiki the query format has changed directly 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. Um, 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 site. So I guess there's also a case to be made for um continuous integration Stuff to be made easier for people to take and apply to their own wikis Uh, I just want to talk about upgrading a little bit since Brian brought it up And one of the things um, I'm concerned about is that we are making these decisions on the premise that people are using Newer media 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 uh, 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 case is 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 rce's 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 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 uh, part side and uh, so it's just so people don't have unrealist unrealistic expectations Porting part side to php is a really non trivial problem And that's not going to happen anytime soon simply because php for example does not even have a html 5 parser And if we 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 through the bus? All right. Thank you everyone