Event talk:126

Raw transcript:

Bryan: Hey Lex, I've been meaning to ask that.

Lex: Hi.

Bryan: That photo you have in the background.

Lex: Yeah.

Bryan: Is a is there a good story behind it?

Lex: That is where can I see you mean this one?

Bryan: Yeah.

Lex: Yeah, and that's all my friends from the you know, I had flatmates I had

Bryan: Yeah.

Lex: I had 23 flatmates in eight years in a six bedroom apartment. And this is actually one of the best. I mean, we had three parties a year. and actually this is the can you see that?

Bryan: I can see there's something there. It's kind of hard to see I see like it almost looks like movie posters or something and then a

Lex: Yeah, these are but can you sort of recognize a little bit? This is Miss Piggy.

Bryan: can you can you bring it like up into the left a little bit and then angle it to the right because it's kind of like the whatever light is on it or maybe angle at the other way. slightly Oh, yeah.

Lex: Wait, maybe two Direct.

Bryan: that yeah, that light was like washing it out.

Lex: So these are the Flyers.

Bryan: before the parties

Lex: Yeah for the parties and these were

Bryan: I see.

Lex: invitation lists.

Bryan: Yeah, I see that.

Lex: Because you know, these were the parties between 1998 and 2005. And there obviously there was only SMS then there is no there's no, you know WhatsApp and all that. So we invitation lists.

Bryan: Yeah.

Lex: but these were honestly legendary

Bryan: that's

Lex: parties and Zuri.

Bryan: all

Lex: You know. And I can't ah, I can send you wait. Let me I know I've haven't got it here. I've got on the other computer. No, but it's oh Mark is here as well now. So this is you know, the final supper. When Jesus is gathering with his disciples, so this is a little bit of homage. You know, this looks like Caroline here is is Jesus and her disciples around her and she's

Bryan: what?

Lex: a Jack Daniels bottle.

Bryan: Which one are you? Are you on the just the right?

Lex: I know. I'm not on here.

Bryan: Oh.

Mark: He's the Judas.

Lex: but But Todd remember you met Todd. I mean sorry Mark you met Todd O'Brien in New York.

Mark: Oh, yeah. Yeah. Yeah, definitely.

Lex: You know that. He's up here.

Mark: Okay.

Lex: But you see this is 20. No, this is 9 this picture is 19 years old. Yeah. Let's have how far we got right?

Mark: now well What are those like Airline liquor bottles on top?

Lex: Yeah. No, these are Havana clubs.

Mark: Okay.

Lex: All right.

Mark: but their Airline size

Lex: Yeah, I think I the two little I mean my my Cuban friend. Gave them to me. to

Mark: So it's just us for now. What it what have you been doing? Lately Lex? I haven't heard much from you.

Lex: No, I'm I'm coding like mad. I'm I'm consolidating. You know sharing data structures between neo4j elasticsearch and then get up to speed with the react. Which there's great Merit to that, but it's a steep learning curve. Very steep, so that's why I'm still full. on that

Cindy: I was thinking the same thing too that I missed Lex I never chance to Get caught up with him.

Lex: Yeah, Lex has been reacting around.

Mark: He's a reactionary.

Lex: It's true. It's true.

Cindy: So

Lex: But I tell you it it's a fascinating technology, but you really have to

Cindy: yeah.

Lex: turn your your brain upside down. coming from node

Cindy: Yeah. For what it's worse. They did a analysis in the foundation. They to select between react and view.js and they went with you.

Lex: Yeah.

Cindy: but I know nothing about the two technologies so

Lex: Hey you're on. You're more and more look like George Clooney. No, I see I I just

Cindy: my

Yaron: Thank you. I was going to say the same thing.

Lex: No, you just move me.

Mark: Oh, I was thinking more Don Jr.

Lex: No. No with the beard.

Yaron: It's I know that's that's what Mike

Lex: Yeah, I've seen that movie.

Yaron: was saying too. I think.

Lex: Yeah.

Mark: Yes.

Yaron: Okay. Yeah, it's just you know, George Clooney is just a step on the way to I don't know Rip Van Winkle or I don't know. Mmm should have had an extra my joke

Mark: um

Yaron: beforehand.

Mark: So so good.

Yaron: Just step on the way to ZZ Top. Yeah. Oh that gonna be Rancher.

Mark: This is great.

Cindy: very good

Richard: you

Mark: This is great because Richard just joined us and and we have yarn here and I want to I want both of you to talk about the projects that you have can ask and and what it what is your project called Richard?

Richard: my project

Mark: Hello Wilson.

Richard: having holidays

Yaron: project Krampus

Richard: I don't. Know I don't have an current project.

Yaron: Oh.

Richard: It's there is an initiative. by Bayern which seems to be very similar to things we have discussed last year in our regarding that something like a sunflower distribution. Anyway, it's not the same thing, but I think it's similar and

Cindy: well to talk to the one with Wiki base that that's what Mark was referring to that joined after.

Richard: here so so it's funny because the last week says several. companies were talking about how they can

Yaron: and

Richard: cooperate and so we have had some contact with wikibay's.

Yaron: you

Richard: following that smwcon because wikipase is heading for something like they call a Content service. Providing system media Wiki base. So it's not a minute short name for that. So and the question was how week?

Cindy: finasteride

Richard: coordinate developments Standards and so then it in the same

Mark: so

Richard: minute yaran comes around with this idea. And what what I It's something together. and clearly not everything. But as long as people already find something to work on together, that would be already a great approach. So I don't know what we keep base. Is going to because we didn't go too deep in that project and so on but Yarns proposal can be followed in this I think there was a male. um in the invitation Okay, you find.

Mark: so so I I guess I guess what I was wondering is You it sounds like you are saying you want to collaborate on something. Whereas yarn is actually scoped out the little bits a little bit more of what once you want to do. Is that is that right that these efforts are compatible.

Richard: I don't know if that this compatible

Yaron: Hey, okay.

Richard: but for me one thing is clear if we have So if yarn so let me let's talk yarn about that. But if we talk about, how can we

Cindy: you

Richard: create products out of media Wiki

Ike: you

Richard: like media Wiki as an document management system media Wiki as and knowledge-based Medias something different. and then we need a common. Basis so that must be clear. Is it possible to get? To organize a common infrastructure. Is it possible? What are the technology technological basis? Is it do we use Docker or something different? and what's extensions can be used and

Yaron: you

Richard: what is if somebody says oh that's a nice extension, but I want to get money for that or I don't want to get money for that. And so and what is really usable and I think that the common thing behind that is that So everybody is lacking for support in development and quality assurance. And that's only possible. If we agree on a basic on a set on extensions and Technologies, but the people say, okay we can agree on that and we put our resources into those projects and get something back because we don't spend too much time

Yaron: you

Richard: in doubling efforts. So a good example is for instance

Mark: right

Richard: that if you look at Vicki works and if you look at Wiki-based and Hollow valves and you

Cindy: you

Richard: see there are three companies in every company. He has of course has their own approach how they deal with forms. So we have three forms extensions one is published the others not and so maybe they have different approaches and they maybe we need different approaches for that. But I think there are some

Ike: you

Richard: um features where I would say that

Yaron: you

Richard: it's really crazy that people are doubling that so for my for my perspective, we have a back end for blue Spice in administration for administration of users and rights. And and creating page templates and stuff or we have a privacy expansion. So why why not using that publicly so that's

Ike: you

Mark: the

Richard: And so we would be happy if that will happen in the future, but we know this is much easier said than we get some

Mark: so

Richard: then we will see results, but it will

Mark: right

Richard: take time.

Mark: So Robert Vogel has already done. I believe it's Robert Vogel who's already done a lot of work of releasing the blue spice stuff, but I

Ike: you

Mark: want to I I see y'all in nodding his

Yaron: you

Mark: head here a lot and and he is also working on this class the thing I want to hear what he has to say about collaborating on this with other

Richard: think

Ike: because

Richard: system

Mark: people.

Yaron: Yeah, sure. I'm just one.

Greg: I can you go on mute some back feedback.

Mark: That's Ike I can you go on mute you

Greg: I know.

Mark: we hear background traffic?

Yaron: You headphones, really?

Ike: sorry about that.

Yaron: Um, I'm surprised to hear that Hollow velt has a form distillation, but

Richard: if not published, but we have some

Yaron: can count by that later I guess.

Richard: yeah experimental things.

Yaron: Very interesting. Um, yeah, I mean, I'm happy to talk about anything. I I believe I was talking about this meeting before with Brian. I believe he was slated to give a summary of of Canasta the current

Richard: Sorry.

Yaron: know, what the the current steps and current status and the next steps and all that. So, you know. If if you're up for it if Brian, are

Mark: um

Yaron: you there?

Richard: right

Yaron: I mean he's there but if

Bryan: yeah,

Richard: Yeah.

Yaron: there.

Bryan: I mean good discussion. I can I in we had the meeting just before this and I pointed them to the notes, but I could give a little update maybe later if that works.

Yaron: Okay. Well so okay say

Mark: Yeah.

Yaron: so I can talk now or later Brian can

Mark: um

Yaron: or whatever.

Mark: No, no, I I think it would be better if you talk now or if I knows a lot

Yaron: alright

Mark: about this then then maybe he can if you don't want to.

Yaron: No, no. No, I'm fine. I'm and I just didn't want to step on Brian's Toes or whatever. Okay. So yeah. The basic idea with project Canasta is it's a two or three part. project two or three component project one is creating a system for for creating Docker images or whatever. It is. Given, you know, you say here this here the set of extensions I want here's the configuration for each of them and so forth and you you call the command and it creates this image that that anyone can then download or whatever the term is onto their system and then ideally it's really simple they just they just do it and Run the script or whatever it is and then all of a sudden they have a fully working Wiki with the database installed and all that stuff.

Richard: if

Yaron: And they then have the ability to download or Wiki Pages or maybe that has already part of the installation also, but that's this. That's the main second part which is creating different packages of Wiki pages that can be used for different purposes. Whether it's a CRM or anything else. And the third high level thing is a system for downloading those packages, but there's a few different things one is the page exchange extension. That's another thing that needs to be decided. But there's already some a few different options for that. Um, yeah, so we've had one official meeting and by the way, all of you are invited definitely not trying to exclude anyone. I'd basically just the current mailing list is basically all the people who agreed to you know, wanted to just said that they were interested which it's a majority of the people here, but not everyone. But yeah, I mean everyone here is definitely welcome to come and maybe I should have done or should do a better job of publicizing it. But we had one official we had a kickoff meeting and then one official meeting just yesterday two things it two days ago where we talked about the the docker stuff specifically and it looks like it's now boiled down to two main candidates one is Mezza from NASA and the other is the blue spice Docker image. Creator I don't think has a name.

Richard: Okay.

Yaron: And then potentially there's a third one Lex's data specs thing which we talked about less for some reason than those other two, but as a serious candidate, but we can also talk about that. But anyway back to what you were saying, what back to what Richard was saying about about, you know, coordinating and the whole thing that the sunflower distribution was about. I totally agree and I hope that's one of the side effects the big side effects of this project Canasta thing is that it'll create some opportunity for governance. I mean if everyone is if there's a central Repository or whatever for for all this functionality then and we can really start to think of it more as a product than the like a money making thing and if there's money coming in then there can be money going to development and to maintenance of all these extensions. Yeah, and and of course standardization of the technology. That's it.

Mark: So I pasted link to Brian's notes in there Cindy. I know had some really good thoughts about what we immediately was doing about infrastructure. You have anything you can add on that.

Cindy: Yeah, I have a few thoughts about this and you know, definitely having some sort of a containerized. Infrastructure is definitely that's the way lots of different groups are going for this type of thing. And what we're doing within the foundation is actually sort of at a level Beyond just merely containerizing but also orchestrating using kubernetes and the idea being that it's not just a matter of just having one media Wiki image container, but you need a little bit of infrastructure around that as well. And so it so I would encourage, you know, looking past just a single Docker this thing. I'm sorry a single containerization solution, but looking at also Orca orchestrating those containers and I think this is great and I think this is absolutely exactly what we need and it also helps to address one of the big needs that I've seen in that's been a roadblock to Media with the adoption. In that is the ability to install upgrade and maintain the infrastructure for for media Wiki in a repeatable way. So yes, I would absolutely and there's work going going on Within. The foundation first of all kubernetesizing our infrastructure, but also to create some standard. images they're not targeting at this point strictly third party usage, but I've been encouraging. Making it so that it does not preclude having a compatible solution that would give you a productionized as well as a development environment based on media Wiki, that's that's containerized and orchestrated. So so yeah, I think I think this is something I'm very interested in than something. I'd like to You know to help with at least. you know giving giving Feedback. The other thing I wanted to add I had some conversations with. Charlie from wiki-based Solutions about this joint project that Wikileaks Solutions is doing with halloweld and they've come up with a Proposal for what? The first work is going to be on that and so one of the key parts of that was page-based access control that they feel is very Necessary and that could be something that could also be complementary to this whole work is you know, if they were able to develop an extension that could be used. within this media would be infrastructure to get to give this and so I've gave some paid back on their initial proposal and there are of course a whole bunch of landmines involved in being able to implement page-based access control. So it's not a trivial task by any stretch of the imagination. I know that that I also put them in touch with Daniel Kinsler. Who's has he wrote the first lockdown extension and also is

Mark: but also

Cindy: on my team as a very knowledgeable about the media with the infrastructure one of the key architects of it. And so they're going to talk also about any additional technical aspects of that. So I know that they are moving forward with that work as well as far as that project and I think that that's very complementary to the goals of what what you're talking about with canastas. I understand it. So I think this is great. I really wouldn't think that I'm most excited about is the fact that there is coordination between these different. Individuals companies Enterprise users to move forward and to contribute expertise and and development resources to being able to move this forward. One of the things that we were talking about in the board meeting just before was Eric John from from wiki-based Solutions, you know, and something I felt for a long time is that you know, there could be so much more Market penetration of media Wiki usage for Knowledge Management for Content management. But there's a few roadblocks in the way that need to be cleared. And and I think this is a great way to go I could just I could definitely see this being very useful technology that would really have much more penetration than currently is and usage of media Wiki and Enterprise environments, and I'm excited about it. That's it.

Yaron: Cool. Yeah. Oh, yeah, I agree with all those things up. Yeah, I should have mentioned we also talked about I mean, I guess a fourth option for creating containers is using the Wikimedia foundations own code for doing it. I don't know what state that's in or whether that's possibly we didn't have any anyone to talk about it at our meeting on Wednesday, but

Cindy: Yeah. There's different aspects of it some usable some will potentially be usable in the future and some could be foundational for creating something that's usable for something like this. So there's there's nothing that's

Greg: Yeah, that's like you.

Cindy: ready.

Greg: There's like media Wiki Docker. There's you know like media Wiki vagrant this You know, there's like so many different options to choose from.

Cindy: Yeah. Well as well as this media Wiki on

Yaron: Yeah.

Cindy: kubernetes Project.

Greg: exactly

Cindy: That's that's does not. It's not currently a thing that one can like download and use but it's it's very much in in development. But yes the media Wiki Docker stuff, which is now part since 1.35 is part of media Wiki when you download Media Wiki, it actually has a Docker

Greg: a docker

Cindy: compose file. Yeah, but it's very much

Greg: Yeah.

Cindy: developmental it, you know out of the box it runs on sqlite and You know, it's really more for a development environment than for a productionized environment. but then there's also

Mark: so

Yaron: Okay.

Cindy: stuff that they use to run CI. So they've got a whole bunch of Helm charts that they use internally to build up. the environment that they can run all of their CI against against media wikis anytime code gets checked in. It's spins up a Docker environment or multiple Docker environments to validate to run all the tests.

Mark: So it sounds like as far as is far as a coordination, it sounds like Yarns project. NASA meetings are properly the best place to do that coordination then is that That sound about right to you.

Yaron: A coordinating what?

Mark: Work on all these things like I'm

Yaron: Oh, yeah, right.

Mark: Like I'm looking the project can ask to and it seems generic enough at this point that yeah, the people can get in there and nail down to specifics then.

Greg: yes, sort out sort out whether you know like we should grab some pieces of Richard's build system and Lex's build system and the foundations build system and the

Yaron: Yeah and your build system. potentially

Greg: yeah.

Yaron: the quality box. Sure. Yeah.

Mark: well now I'm gonna have to I see now

Yaron: Yeah.

Mark: you really need to get me involved because I have my own build system too. So, you know.

Richard: Yeah.

Yaron: Do you?

Cindy: You Max, right?

Mark: No, no, it's make files.

Cindy: Oh, that's right. That's right.

Richard: Cindy: Right right below Max in the higher.

Greg: he said he's use he's

Mark: Yeah, I got you know, I've got a Prioritized do everything the Unix way quit it Reinventing the wheels sort of thing. Anyway, um, Now this this is great.

Yaron: Yeah.

Mark: And I I think it would be good to have. a place to do all this coordination and I I'm glad that Yarns pushing that

Richard: Hmm. So what I would to contribute is

Yaron: Yeah.

Richard: One take away from the meeting before Christmas. So that is the people who were and at the first Canasta meeting agreed on. That this is not only a technological. Question, but it's also a question about use cases. So the approach of yarn was not a technological solution in that once he were looking for a use cases. So and many people agreed that we

Cindy: you

Richard: have to learn much more about yeah use cases and and user interfaces for instance or templates for instance. And so Brian Brian started a group

Yaron: Well, yeah.

Richard: for for documentation management for which I would like to join so where we Share ideas and experiences what can a document management system or Wikipedia be or should be or what? Does it need? And what does it needs and so and what are the requirements? I think that is a very interesting approach beyond the question. Do we need semantic or cargo or that

Yaron: you

Richard: the permission system of blue spice or something different so that Is a result of a discussion we have on on use cases.

Cindy: Yeah.

Yaron: Yeah, wait, what do you mean? What's this group?

Richard: I am so maybe Brian can tell more about that. So I I thought there are two. never two things. So one is that at yaron you will

Yaron: Yeah, right. Yeah.

Richard: arrange meeting every week. So one week is about packaging and one session is about packaging and other is about infrastructure and Brian said that he want to start a group about a document and management system use case, so, but I haven't heard more about that.

Yaron: Okay.

Richard: So maybe maybe it doesn't it's it's still an idea, but no, there is no meeting for that.

Bryan: All right, it's not something it still under the project Canasta Banner head but every every second

Richard: Yeah.

Bryan: But every every second week. We're going to have a meeting around the infrastructure kind of what we've been talking about previously. And then on the odd week, we're going to talk about specific packages in the kind of the use cases like you're mentioning and so this next week is going to be one of those meetings, but but the invite hasn't been sent out yet.

Yaron: Yeah. Okay, cool. Yeah. Yeah, I would just add you I just yeah, you said, you know, we have a lot to learn about use cases something. I'm I'm hoping that that it's actually not learning but rather the we are that Among Us they're already exists that knowledge. I'm hoping anyway to know what's best done for all the the different use cases. However many were handling five or two five 10. I don't know but there are people who have done projects relating to CRM or BPM or ISO 9001 and all these acronyms I don't really know that much about but there are people who have done that in the context of media Wiki who can you know? Give their expertise to at least create some kind of reasonable starting draft starting package for all these different things. This post having to do you know rest actual research. Which no wants to do. Yeah.

Bryan: I still think we could. Come up with a use case that would be relevant to all of us. Anyway, like a customer relationship management package is something that we could all probably be using and you know so-called dog fooding right like not just some Pine idea but something that we could start using internally for our own consultancies or companies or whatever.

Yaron: Yeah, and in some cases like riches file manager, it could be things that people are already using internally also.

Richard: Yeah.

Yaron: Yeah. Yes. I just this is just a random thought I don't know if I don't know if like having a meeting every week is too aggressive or not aggressive enough. I mean this elect to go over and if it takes, you know, 10 meetings each to decide on stuff then then that's like 20 weeks away and that's like five months from now. to make the decisions, but I don't know if people have this the tolerance for like didn't even two meetings a week or something, or maybe it should mostly be done via email instead of just face-to-face meetings. Like this. Yeah. I don't know. I mean for the case of like sorry, I'm thinking out loud, but for the case of like Docker images and deciding on Mesa versus blue spice versus Wikimedia versus quality box versus, you know, make files or whatever. maybe it makes sense to just have a big mailing list discussion about it and just hash it out instead of you know talking for an hour once every two weeks.

Richard: you

Mark: No, I agree that there's there's that Meme, you know, this whole meeting could have been an email. Um.

Yaron: Right.

Mark: so, you know,

Yaron: Yeah.

Greg: I'm

Mark: to go to the email when you when when possible emails a good tool. It's just abused too much, but it's a good tool.

Richard: Yeah.

Greg: but I I also like take a different perspective and feel like one way that we could get a lot of momentum and a lot of productivity would be to

Yaron: you

Greg: just like schedule a meeting about a specific topic and and maybe that schedule could be set up by email but then you know at the appointed time, you know, just like a 15 minute working session or a 30 minute working session where people can join video and and go edit a page on on mwstake.org about, you know, the build process or the use build up a use case or or do something because I just find that you know, like I can sit there and have my own thoughts but usually when I start to think about these things I have more questions than answers and I feel like when when if if Mark and yaron and Lex if if we're all on the room, you know. then all of a sudden is the discussion happens more quickly and the idea the idea is flow more freely and then we can like record that kind of like assessment in the Wiki page. is that

Yaron: Sure. Yeah.

Lex: Okay, I'm Greg.

Greg: I just crazy.

Lex: Can I? Can answer to that because then I have a suggestion. because if you look at my data spec system builder I or in a different context I restart my computers every day. Why because I want to make sure I'm not dragging some settings some credential some whatever for months that I forget and the moment I restart the system. I'm lost what I mean by that if you look at my data spec system builder, I build it from an absolute scratch and the scratch. I mean is the ISL file the ISO file. of course unboxing and a fresh laptop

Greg: Mm-hmm.

Lex: would be the best but that's too expensive. So I use Virtual machines. But why when I say now? You say we should you know exchange ideas and on how we do that. Well, then let's come up each of what each one of us with that solution for his or her own plane vanilla Builder. And plain vanilla is Media Wiki core

Mark: Okay.

Lex: on a Mariah DB Apache system. That's it. And then the questions are what are the abstraction layers? What are the components? What are the credentials? What are the environment variables and then we should run this until every single one of us feels comfortable. because you know when when I develop a system, I want to repeat itly do things and at the beginning it's brittle cumbersome ugly whatever but

Yaron: you

Lex: that's okay because that's how you develop stuff. But after two weeks or three weeks things pan out and they calm down and there's an and I'm fascinated that some aspects of my Builder. I haven't touched in months. Those are the healthy ones. The ones that are changing with every second commit are the unhealthy ones, but that's okay because they grow, you know, they have to pass tests. They go through kindergarten and they go through High School through college and so on but I I want I would like to avoid a brainstorming session about how to do things. We all know we all have ideas Mark as his make files Cindy as I very sophisticated miter based weekly Farm

Mark: but

Lex: Builders. I have a mixture of Docker files and ansible scripts and stuff like that. Richard has I think the commercially most vetted aspect, but if we all

Yaron: you

Lex: But if we all just the goal is the plane vanilla media Wiki And then let's compare the solutions and also, you know, let's send each other the GitHub links and say well try my word my my way of doing it. What do you think?

Yaron: It's it's seemed like you were alternating between talking about builds as builds and as metaphors for the process of talking about builds,

Lex: Yes, right building.

Yaron: but okay. Just wanted to make sure that

Lex: Yaron

Yaron: yeah.

Lex: Sorry I'm if I'm not using these whatever.

Yaron: yeah, just

Lex: words correctly.

Yaron: No, yeah, sorry. Yeah, my thought is and maybe it really does make sense to this isn't quite what you're talking about. Or maybe it is but just to have a central document or something Google doc or wiki page or whatever. It is etherpad where people just write about their different. Solutions and I guess proposals even for you know, we have a requirement and people can write in their proposals.

Lex: Right, but yaron, we we already have

Yaron: You know, these are the strengths.

Lex: implemented so many things. If we lose time.

Yaron: Yeah, I don't mean proposals in the sense of I'm going to develop this thing proposal in the sense of let's use Mesa or let's use product project product X and and it yes, it can fulfill all six requirements or it can fill five of them. But the other one is, you know in progress or it's not a big deal or

Lex: But okay and wouldn't you want to go,

Yaron: something.

Lex: you know quicker to more concrete steps?

Yaron: Like if it involves everyone trying out everyone else's software. If is that what you mean?

Lex: Well, you know we're not talking about. 40 Solutions, but one exact reason

Yaron: I know no.

Lex: one for one example, for example, the automatic installation of extensions. I remember that Cindy would you I think Cindy uses the simpler approach to mine. I split extensions into three groups one is composer based one is enable only and one is from repository. And then I have three yaml files where I can figure all these three groups and then I have a simple Ruby script that runs through. and now because the requirement is clear it is installing configuring extend maintaining and updating extensions, but I would be very interested in how Cindy's approach works and where it is similar to mine or different in mind and how Greg does it with quality bars and how Richard does it in you see and if we

Yaron: Yeah.

Lex: have to create Solutions because the requirements are clear, aren't they?

Cindy: Well, that was my question actually

Yaron: Yeah.

Cindy: are the requirements clear are the requirements for this documented somewhere.

Yaron: No, they're not.

Cindy: Yeah, okay. Yeah, because you said six requirements and that got me all

Greg: That's that's right one.

Cindy: excited. I thought

Greg: One. Is that kind of they're not documented and I think we need to get together and collaborate on the you know, just an outline of you know, like what is this system do in and it's what is this system do is

Cindy: yeah.

Greg: actually a lot if you if I don't even spend I I didn't spend enough time on quality box to like really Market it in profile it and say, you know, like with the big green checkboxes. This is what it does and compared to other products or something like that. But but that we kind of need that and and we need to discuss you know, the it because it turns out that Lex your system works the same way that Mesa works is same way that quality box works the same way that Cindy's system works is there's a yaml file that specifies the extensions and pegs of version and and also classifies. How does it need to be treated by the installer or the packager like this? Does this need to be a WF load or does this need to be a include like old style and does it need to

Richard: you

Cindy: really require ones

Greg: need to run composer?

Cindy: but I I'd argue that there's there's actually several different levels or categories of requirements that we need to Define. And when you're at the point that you're installing extensions, you're already assuming that you've got a media Wiki infrastructure that you've got your OS you've got it configured with the appropriate levels of you know, security configuration variables. Whatever your PHP is installed and

Greg: you

Cindy: dockerization that you know or containerization. Handles that infrastructure build and that the way that does it is very different from what Meza does which starts from, you know, a stock VM and then starts building things on top of it and that's fundamentally different. So what I'm saying is That those requirements need to be elaborated so that we're all talking about the same thing and that we understand because I do think I do think that Meza and containerization are fundamentally different. They are complementary But ultimately you're going to pick one and

Yaron: Oh.

Cindy: so at any rate, I think I think before we talk about specific Technologies and whether we're going to use, you know lexes or Groves or Richards, you know, or we need to talk about what the requirements are to see which of those actually fit with what we think

Mark: so

Cindy: and just to be able to have that discussion about what are the important requirements.

Mark: so at this point it seems like

Greg: of you

Mark: there's you know, we we have different ideas. We're aiming the same direction we kind of have The same idea about what needs to happen, but Cindy it sounds like you're you have much more fine-grained idea about the steps that need to be taken and some of us are just kind of assuming those things are done already. Um, And I think what would be most productive probably is coming up with an agreed strict, you know schedule or strategy for what problems we need

Yaron: you

Mark: to solve and then what problems we need to solve and you know having a schedule for how to do that but because right now we're we keep talking back and forth over each other and saying, oh we're gonna share ideas. We're gonna do this and and I think you know we need to have some structure maybe just back out exactly what we want first.

Richard: Yeah, maybe I have to things about Alexa and coming back to Gregory. So what I I completely see the the point of ux I just would say why not working with real proposals. So I have for instance. There is an RFC about a hybrid extension management. From April last year and so the tech home I think was was talking about this but the status is still it's in Exploration. And for me that is really crazy because all we are talking about is what is a what is a standard. Can he agree on a standard? This is about the status quo which will help so many people if we can say Okay composer we can on use composer in this in that way. And if for instance Wiki base and Wiki works and and quality box and data specs agree and say, yes, we will do this we set facts and I think that is something we can quickly discuss and say yes, we want to do this or no. We we reject this proposal and we cannot agree on that, but then something would be clear and

Mark: right

Richard: that's the way how I propose to go further further and Making concrete proposals say is that a way what we can do and coming back to Gregory? I completely agree with you that we have to talk about users in use cases. My problem is that it's for me sometimes like talking about like we have a saying like the blinds it's talking about the colors. I don't know if you have the same saying. Um, so I have actually no idea how my customers are using my so our software. The reason is that we are selling something for them. We give them semantic and some templates and have no idea what we are doing and if you don't Meet them again in a customers meeting. I would have no chance to see what they have produced in the meantime. So but this is what what we really have to know what we have to explore what what are the people what what does the people need? So one sentence of CRM is it's the same goes for me. I have no idea about the iso 9001 standards. I have it now here.

Yaron: Oh.

Richard: There's some thought.

Yaron: Oh really? I was hoping as hoping you'd be the

Richard: It's a paper. Yeah.

Yaron: iso 9001 guy actually because you

Richard: Sure, but what does it mean?

Yaron: mentioned on your website quite a bit. All right anyway.

Richard: Yeah. Yeah, it's it's it's a few there are a few sentences. So you need a knowledge base. Okay. Thank you.

Mark: So real quick, we're Richard.

Richard: 100 bucks for saying nothing. And and what are we doing with that what templates are needed and how are the workflows? I don't know. So I'm maybe we can find people who can teach us that.

Mark: So real quick Richard you mentioned for example, and I know this is in the weeds a bit, but you mentioned the composer thing the composer thing has been agreed to accepted. Mostly. Um, it's just resources getting the

Richard: You know.

Mark: those resources from the foundation. They're allocating that

Yaron: Oh.

Richard: Oh now we have loved.

Yaron: privilege we lost mark

Cindy: Oh, no.

Greg: Marquis Rose

Yaron: Okay while he's Frozen Can anyone explain the composer thing because I didn't know I don't know what he's talking about. So maybe this is a good opportunity to

Richard: it it's just only an example for what what I think it's a good idea I think working with

Yaron: Yeah.

Richard: Rfcs is a good way, but it would be if you more focus on that. I think we can push things I can share the link.

Yaron: Sure.

Richard: Cindy: Yeah, I can I can talk about it a little bit if that helps so.

Richard: Yeah.

Cindy: The idea of the RFC. Well, first of all, there was an RFC that said that was rejected for you. Okay think it's number is two digits something like 47 or something. years ago and is always the the one that's brought up by Foundation folks for when when extension developers want more support for adding composer or have a question about why composers not working for installing an extension? Um, and and the response is always. Oh, well, that was a directed. You can't use you know, it composers you for installing libraries. It's not free installing extensions. So this what this extension was was or what this RFC was was a attempt for codifying the fact that actually in many environments folks are using composer to to install not to enable but to install to get from packages or whatever Source they're using for because I know hello well has or blue spice has their own packet internal package manager for it's on that. So the idea for this was to say it is okay to use composer. These are the things that you should have in your composer.json file. To be considered, you know for your extension to correctly support composer based installation. These are things you should not do like for example automatically enable your extension when it's you know, using the composer Auto loader and you know actually have your sort of like semantic media with you used to do that that and it's still sort of does to some extent. Some of the code does get autoloaded and so you'll get Messages on pages saying you haven't enabled it at any rate. So the idea is of this RFC was to codify all of that and it got to the point where it was the techcom was. close to approving it, but one of the One of the provisions in there that perhaps should be Revisited was saying that that the Wikipedia extensions should be able should all be their extensions that are composer.json files. Should be annotated with the appropriate. composer metadata so that they could also be installed and so techcom. was hesitant to to approve that without without

Yaron: That's right.

Cindy: having appropriate resourcing for folks at the foundation to actually instrument those composer.json files. I think that you know, it's not much information, you know, the name the description whatever, you know, I think it may be the case that some of those extensions are not actually in packages so that I don't remember whether that was the sticking point. So at any rate, there's a certain amount of work to be done that techcom found felt should be done within the foundation, but there was no resourcing available for it and

Greg: You know what?

Cindy: And the way techcom works at this point is that rfcs cannot be approved unless the appropriate resourcing is in place. So I think that I think it's important that RFC make it through this process so that folks know how to Handle composer what the best practices are what should be done and if that resourcing cannot be resolved in the short term then perhaps that requirement that all of the Wikipedia. Extensions be annotated appropriately for composer should perhaps be pulled from the RFC in order to allow it to be. to progress

Richard: Yeah.

Greg: and I think what Cindy's talking about the the whole resourcing issue boil down to like composer local.json, which was a media Wiki development or wmf development that

Cindy: That's a debt separate issue.

Greg: even

Cindy: That's the composer merge plugin.

Greg: Right.

Cindy: and that that's a separate thing

Greg: Okay, so the separation

Cindy: because composer merge plugin is not actually maintained by anybody within the foundation at this point, even

Greg: right

Cindy: though it was written by the foundation and it's not compatible and it's not compatible with composer 2.0 which was recently released and

Greg: right

Cindy: And so you actually have to make sure you're running composer one not composer two in order to have that

Greg: Okay.

Cindy: work but there was apparently a volunteer who submitted a patch against composer merge plugin to make it work with composer to I think that patch is stalled. I'm not sure but that's a separate issue. That's not that's not holding back

Greg: Okay.

Cindy: the hybrid extension management RFC. What's holding it back is the foundation committing resources to instrument all of the composer.json files that are in the Wikipedia maintained extensions, and I although it'd be nice that they were all instrumented. I don't think that should be a requirement in RFC because we're not going to require that every extension that anybody creates must have Composer.json, so why would we require that the Wikipedia ones do so? so

Richard: Yeah.

Mark: Oh, look, it's Frank.

Cindy: that would be my suggestion.

Richard: Hi, Frank.

Cindy: Hey Frank.

Greg: Um, so just hi Frank and I I just want to take a this moment. I actually would be a great before that meetings over. I just wanted to say that I'm back kind of sort of some people know some people don't but the quality box development is kind of you know, I don't know where the future is going for Quality box, but I've joined pegasystems in Cambridge pegasystems as a as a full-time media Wiki developer. And so now I'm on the inside now now I'm a stakeholder from you know, like an organization that uses media Wiki

Richard: Yeah.

Greg: because big plans for media Wiki and the and the other funny thing is or interest very interesting thing is is that they before they hired me they have been engaged with Wiki base solutions for for months now deploying their big Wiki initiatives. So I'm I'm working with odd and Wiki base on a regular on a daily basis. Um and as it is I developer so I've Got A New Perspective and and more time and probably more resources than

Mark: Hey.

Greg: I ever had to to be a media Wiki stakeholder participant so just wanted to say

Richard: Oh sounds great. Congratulations.

Greg: yay.

Richard: Yeah. so it I didn't mean to to complain again about about composer questions. I know this is maybe this is some sort of statistic. Side of me. I know what triggers everybody it makes everybody crazy. But what I want to say basically is that we that could be a way how we can go further and for me. It's completely clear that we won't agree on. How will we install everything so so because there are different approaches. I think I'm fine with it. But what can we is it possible and I'm not a specialist. I'm not I'm not a scissor. So but is it possible to? to reduce barriers and if we agree at

Mark: you

Richard: least two or three of us already agree on specific. Questions, that would be already a great success for everybody. And and so maybe this is not The big Vision that we are on here. So I also want to have a New Perspective for media Wiki and clarification about the use cases and I think that is One part. It's the two sides of one coin. So we have to technical side and we have to use case side. And now we have Gregory who is who can tell us from the inside. What's going wrong?

Cindy: I have another use case example that. that that it could use clarification or be good to have people Converge on a solution right now. There is no single way to create a Wiki Farm. So having a single week video Wiki installation that has multiple media Wiki instances to serve by the same code and their suggestions on a Wiki page on media.org and ways to do it. I at miter created a way that I did it and Collaborated in the early days of Mezza so their solution is very very similar to what I had done at miter, but they're also other Solutions other ways that and there's no reason that there need to be, you know, infinite degrees of freedom and how you create a Wiki Farm. There should be a way that is supported in in creating multiple with Wiki multiple Wiki instances for you know, and you know the media Wiki Docker Dev, which is Adam shorland's Docker development environment has also a way I haven't looked at the details to see what you know how but it's it is definitely a different way from The way that Meza does it so it I think that that the software should have a single way to support Wiki farms. And this would be something that would be good. That would come out of this as well is coming up with an agreement on what this is people shouldn't have to anybody who's installing media Wiki and decides they want to have a Wiki Farm shouldn't have to be able to shouldn't have to figure out what they do to Apache what they do to you know, their local settings file to try and make it so that it supports multiple wikis. This should be something standard.

Richard: so now we can

Mark: So the the thing that a standard offers really is not it's not taking away choices. It's taken away decisions that have to be made.

Cindy: Decisions and work. Yeah.

Mark: You're right. And and if there's no

Richard: and

Cindy: because there's no real benefit to

Mark: made.

Cindy: One Way versus the other.

Mark: Right, if there's no decision to be made then that saves work. So we need to work on reducing number

Cindy: Yeah.

Mark: of decisions.

Lex: Yeah.

Cindy: Absolutely, I agree.

Richard: yeah. So but now we come back to a use case question. So I don't know if you know that. that atlassian has changed the license policy which

Mark: Yes.

Richard: means that we get many requirements

Cindy: Yeah.

Richard: by a request by by potential customers who are looking for foreign alternative to conference. So I know conference is famous for

Cindy: compost replacement

Richard: organizing everything in spaces. So which media Wiki is not so you have a different approach of that. We have namespaces, but they work different. So so my solution is now I say, okay. We have a Wiki Farm if you need spaces then okay, you can use a Wiki farm and create as many wikis as you want to and you can have your access right there and your groups and your different look and feel of whatever you want to but to be honest, it's completely different because so in conferences quite easy to make to make a spaces which in my opinion is a problematic approach in Sharing knowledge publicly. But so saying that is I have now a question. What is a good strategy? Should we go out and say okay media week is different. You have to learn just a bit or no. I have an approach for you if you just want to go to another Software which is open source, and you can have it on premises and okay, then we just rearranged it but you don't have to change your mind and you're settings and so but so what what should we do? And I would love to see or to hear what you guys are doing with so many wikis or your Wiki Farms. So maybe I always listen to you and say okay there are many Wiki Farms out there, but honestly, I have no idea why what you doing or what your customers are your users doing that and so maybe we can in one of the next sessions or within the Canasta meetings talk about sharing ideas about what what what the hell are you using? What what is a wreaking farm and how why why are we using that and how can we But what is our approach for sharing knowledge in this field? So because it's really problematic to have so many wikis and on the other hand, it's sometimes it's necessary because you have to separate. Knowledge and and groups and why not using namespaces for that? And so and so it's for me it would be important to to learn more about that.

Greg: Yeah, one of the one of the things that's really great about quality box and and the Mesa approach where there's like this whole inheritance and override capability where you can have a farm and then and it's really simple to create a new one right or I mean a new Wiki, but you can also individually select which wikis get which extensions and stuff. So it's literally becomes um, totally easy to just create a Wiki for like feature development. So if you if you've got a production Wiki and you're thinking about switching from Tiny mice Editor to visual editor or or whatever feature you're you're trying to do, you know, those things become difficult in a like in a static environment like, oh we're gonna be doing this on dev and then we're gonna when it's done we're gonna push it to to QA and then when that's tested we're gonna push it a production that that's really hard to do in in like a single environment, but if you can have a different Wiki that's got different extensions turned on then all of a sudden it becomes possible. So there's a use case for that.

Richard: Mm-hmm. Yeah.

Mark: You Frank. I saw your comment that you posted. Could you speak more about that the Safe Harbor minimum standards? I guess that's kind of what my thought is there is there's often. There's often requirements that people have oh it has to be off. It has to be certified this way or that way. And is that what you're saying it that these minimum standards could be certified in you know. These various ways.

Frank: Yes, look, that's one way to put it what I what I my thought is that. In a in a sector such as law it's practicing lawyers. I suspect that. There are a number of many Wiki instances that are off the radar. perhaps internal rookies for law firms or are are related sectors in government. Or that they may be limited in order to promote a broader adoption. Well, for example lawyers have not only an obligation to be familiar with that with the technology in some set in some jurisdictions. But even greater obligation to protect the information or clients. and one of the consistent comments You hear from many perspective users of media Wiki. Is that well, if you have a Wiki everybody has to edit. Or what are the security protections? In other words, is there any way you need to create a safe harbor? Where if someone in in law or government, there are similar sector can adopt. media Wiki without worrying about exposure to liability for on the grounds of trustworthiness. Is there some way to provide sort of a as a minimum Assurance or Safe Harbor that yes, this is safe. This meets your minimum obligations at least.

Mark: right, and and I think that that's the sort of thing we're talking about here is if we have standard ways of doing that then we can say yes this

Yaron: you

Mark: Meets, you know, it's easy to say it. It takes away decisions it if if there's decisions then there's insecurity and you know, you can make the wrong decision and have the wrong outcome. You want to have people something that you want to be able to produce. Give people something that they don't they can't make any decision or they won't make any decisions about they won't have to make any decisions about to have it act securely. so Yeah choices choices are evil. Um that that's my takeaway here.

Frank: Yes. and you know, they say in the NFL

Yaron: you

Frank: they say it's a copycat League. Well, let some some sectors are very by their very nature there are copycat because they're they want to they want to because someone else has been able to do it safely and there's some sort of assurance. It's it's that.

Mark: Yeah.

Frank: typical Point sort of a Tipping Point

Mark: you people are not people do not like to be innovative. um And and I I saw you roll your I had yarn when I said choices are evil. I I was kind of being making and provocative statement.

Yaron: Sure. Yeah. No, yeah. No, I I agree with you up to a point.

Mark: Um sure.

Yaron: Absolutely not that's a that's a big part of the the rationale behind the the whole project can ask the thing is, you know, once you have a true product in place and you're not just talking about media Wiki, you're talking about, you know, Canasta BPM or Acme CRM or whatever the name for these things is that's why Richard and I talked about this and we disagree about the importance of rebranding it but I think it's useful to to Rebrand. But anyway, whatever it is, you can all of a sudden you have a Spanx for talking for having a testimonials and

Mark: You know.

Yaron: all these little things screenshots, whatever else some sort of assurance that it'll that it'll match all the criteria that people are looking for

Mark: right

Yaron: that kind of product. I don't think we'll ever get to the point where we can provide legal Assurance. That's a whole actual legal area and even you know, even like Linux and so

Mark: well no, no that that

Yaron: forth. I don't think

Mark: That I don't think that's our goal. There's someone else's goal, you know, another vendor they would be able to take this work and say we provide this work with legal Assurance. So

Yaron: Yeah, okay. Sure. Yeah. Yeah.

Mark: Anyway, um, I have to go I don't know if anyone else has to go but I have to go so I'm giving up my leaving gives you all permission to leave as well because I'm so generous. Um

Richard: Yeah.

Mark: So I'll talk to y'all later.

Cindy: Good to

Mark: Bye.

Yaron: Okay then Mark.

Cindy: Happy New Year. Bye.

Richard: Okay.

Yaron: However, it's leaving.

Lex: well

Yaron: Okay. All right, wait, okay. I was still

Ike: but

Greg: Hey, oh shoot. I had a question for Lex. Does anyone know if you if you set up semantic, I'm sorry elasticsearch. If you set up elasticsearch and you want to index office documents, is it just a matter of adding the in-depth ingest attachment plugin for elasticsearch? Or is there some whole glue layer that you have to add with like media wikis Sirius search? They were no.

Yaron: Ike has experience with elasticsearch

Ike: I've never done anything that complicated.

Yaron: Okay.

Greg: I'm just trying to find out like like what do you need to do to if you upload Powerpoints and and Microsoft Word, you know documents. What does it take to get media Wiki to index those documents when when using elasticsearch?

Ike: I know that. I think elastic will index PDFs so I can't imagine too much.

Richard: Yes.

Ike: It's too problematic take other files, too.

Richard: So blue spices is doing that. So the elasticsearch implementation can index attachments and I have no

Greg: I know that's in.

Richard: idea. How maybe I can find out?

Greg: All because Rob will Robert mentioned he mentioned that the that the blue spice whatever it's called extended search or advanced search the blue

Richard: Yeah.

Greg: spice does it but I looked at the code base for that and it's huge and it's not it doesn't like hook into any serious search hook. to um, so it doesn't want to like it doesn't really jump into the process pipeline but instead it looks

Richard: Yeah.