 Thank you. So, first let me introduce myself for those who use Dom Lomé. My name, my name is Patrick Yousboot, so that's my email. If you want to tell me something, just send me an email. It's a bad joke. I'm a software developer. In general, I actually work for Blue Systems. We do KD stuff. Well, I've been doing KD stuff in KD for years now. Over 10 years, it's starting to feel like a really, really long time now. I was part of the KDP board report earlier because I'm part of the KDP board club. One thing that I think is especially important to remember is that nothing that I'm going to talk about this talk is because I am part of the board. Anyone can incubate the KDP project, we're going to talk about it, but it means right to me. Well, let's start from the beginning. So, if you're a soft person from the interwebs and think about how the project moves into KD, you will end up into... Well, this wiki page called the applications lifecycle that has this weird graph over here where projects go from playground to KD review. It looks complex, it's complex, but also it's not super helpful. But it kind of tells us where we're going to talk about. We're going to talk about the incubator part, which is the top on the top right. But there's other ways of becoming a KD project. And there's some concept of review, something you can try to remember. And then there's different places where your project will end up eventually. Then we include un-maintained in the end because we are thorough people, but it's not part of our expectations anyways. So we're going to talk about the KD incubator, which is something that... It's fairly new in KD. When I started in KD, we didn't have any concept. It's something that appeared... I wasn't part of the creation of the whole concept, so I'm trying to explain it as how I felt it and how I saw it, how many, right? But at some point there was this manifesto discussion that actually started to grow or what it intends, and actually it evolved into the goals of the KD vision and the KD vision. If you've been around, you've been hearing about this whole concept. But in general, if you go to the KD manifesto, what we're talking about is that the projects in KD need to help with the governance, they need to be free software, they need to be inclusive, everyone to be part of our project. We want to do innovation in innovative projects. We think it's important that the projects are shared among ourselves and we have an user focus or everything we create. It's for a person somewhere who is sitting with, well, a digital something device and he needs, well, our values, governance, that they like, right? This, maybe it's too abstract, but, well, didn't have enough coffee this morning. But in general, what the KD incubator is about is mostly being able to find a project that is existing and have this project join KD and be able to enjoy all of these concepts that we include in the manifesto. So in this room, who hasn't read the manifesto? All right, all right, let's try again. Who has not read the manifesto? Boom, I am disappointed and the lioness as well. The real reason why I wanted to do this presentation isn't itself, but I think that the incubation process is amazing. It's because it kind of feels like it's something that is there, feels kind of bureaucratic and you don't really know who is the incubation process. Actually, it's something that happened to me, like, I knew we had the manifesto, I knew we had this process, but then I knew people who wanted to join KD, their project was kind of in our orbit for a while. The first project I incubated was K Tech Lab. K Tech Lab is a project that is older than most unique products now. It's some project that when I was starting the university, it was already a thing and I even remember trying it back then. It had a creative meaning and we kind of probably see if it was a creative project. It was kind of a thing. I started talking to the developers and they were interested in being part of the KD community and, well, the things we do. But then I knew some of the incubators that there wasn't anyone. So after talking to a couple of people who I knew that had incubated, I realized that the right solution if I wanted these people to be able to join KD, these people and their project was to incubate the project myself and stop looking for incubation thought or something of the likes. Which is something that happens to us, right? We really start working on something, we get onboarded ourselves and then expect that the rest is, well, everything makes sense. But then in reality, what you find when you're developing or when you're working on the software you see that the big advantage is that everything is in the open so you can do it yourself, right? But then what they have to do, I had to learn how this works, right? So basically what we have to remember is that there's nothing, like there's no body of people doing it, but there has been a lot of people thinking about how the process had to work. We have these wiki, we can take a look at it so that at least you've seen it, explaining the whole process in a lot of detail. It's actually really fabulous. But you can get a good idea of what's going on. The actual interesting page when you start doing stuff is this one, incubated projects. So there's basically like four states of every project that they're going to have, but four states. First is candidates, so the idea is if a project wants to incubate themselves but they are incapable of finding somebody from PD to incubate them, then they can add themselves there and something magical is happening. Spoiler alert. So if you see somebody in the candidates' place, talk to them or see what's happening. It's something I have in the later slide, but something to remember very important about the incubation process is that it's about the people, right? The project itself, I mean, that's the actual bureaucratic part and actually it doesn't matter that much, right? I'm not sure it's a proper results project or a pre-support project, right? We will do that, that's fine, that's easy, right? It's a license, it's either or not, but the big deal here is to make sure people understand we are actually, people know who to talk to, they need to know they can't talk to people, right? It's about getting all of these people familiar with the process and telling them what, like, individuals say that they are already giving members that they already can start working as such, right? I was talking about how to start, so what we do is we copy this page into anyone. This is, of course, fill the blanks kind of thing because it's for a project that hasn't started. And we put it into one of the pages, like the rest, so as you see here, back here we have, for example, for KDN Live, we have the URL, it's incubators.project.kdnlive, so if we're incubating LibreOffice on YouTube, incubators.project.libreOffice, you would put the small page in it and then you would start filling stuff. We can even imagine how it would look. And we expect everything to be great because KDN Live is already a KDN project. If it's not, we can go bite whoever incubated them, but he did a very thorough job, as you can see here. The idea is that you will, as the sponsor, is the name that we use in the documentation. So as a sponsor, you will start filling, maybe, or starting into the list, start talking to the project members and seeing what you can do with them. Like I said, it's about incubating the people as well, so the project maintainer will have their own share of work to do. They will have to learn and agree to the manifesto. If they don't agree on the manifesto, they shouldn't become a KDN project. That's obvious, right? They should know their project. It's not like somebody going through the Internet can't find a random project that they know about and say, I'm going to move this project to KDN, right? Because we want to actually, like, have a healthy project in KDN. So they need to know their project. They need to know what's the license on their project. They need to know how it works. They need to know where people are talking, like mailing lists, IRC channels. Mailing lists is, for example, something that you would probably want to move into the KDN infrastructure. So the person moving this is the kind of thing they would need to have the credentials for the things they have. Also, the website is kind of stuff. Also, something I found that it's best not to be in a hurry. Like, the sponsorship can be in a hurry, the projects can be in a hurry. It's a process that doesn't need to happen in one day. It's fine if it happens in a month. In the end, it's a relationship that should stay set for the next few years at least, right? If they want to continue working on the project, they will do so for a few years, right? So it's not a matter of doing everything today. It's a matter of talking things through and letting everyone do their own thing. As a sponsor, something that I found very cool in the most important incubations is having calls with project maintainers. It's what ensures that the conversation is somewhat fluid. People from the project will often be maybe shy and not used to talking about something. So it's fine to have a more familiar medium. Of course, you're free to decide what to do if you don't like showing your face or showing your voice. Then you can do text or email or text or email or whatever. Having regular calls, though, works really well. One of the things that happens really commonly in the whole process is filling susatman tickets. So there are susatman tickets for the mailing list. Actually, the susatman is the actual people who do most of the work, right? They create the mailing list, they create the repos, they accept the user, the push privileges. They do all of this stuff, right? And actually, mostly what it means that you do between the different meetings is just telling them, well, now you create the mailing list, open the ticket, admin as a subscriber so that I see it. And when we meet next time, next week, next month or whatever, you, well, and you have this done, then we can start talking about what's next, right? I like to do things in parallel, right? But if you're waiting on the mailing list to be created, then maybe there's not enough stuff that needs to happen. When thinking about the presentation, I thought that probably three or five calls is what ends up being what we needed. Is there anyone here? I think you waited. They're all in Lucian's talk. You can talk to Aditya. I incubated this last moment. You can talk to Camilo. I incubated Favère. Or any other of the projects that have been incubated by other people who are otherwise nice, but not as handsome. Well, as them about our experience, I'm sure it would be useful for you, especially if you're interested in ever incubating something which you are, who wouldn't be interested in having morphers that were in our control. But yeah, overall, what we've been talking is mostly not about licenses, right? There's the licenses that are acceptable free, it's something that you need to understand and you will have to see, but it's not about, well, these whole process that we do to have projects actually end up becoming Katie's project. That's super boring and I agree. But it's also a process that we need, right? And it's not that we need it because there's clinical impedency for their code to be on our game, actually, like this part would just be quick. It's about having these people know what Katie is about and actually making sure that they're clean at the academy, which is something, I wasn't really successful at doing all of my QPs, but it's going to go all right. So if you're still feeling insecure, the kind of things that you would want to, well, see how it works and maybe try to make sure you understand the identity account, the git push permissions. For a git, there's a super good wiki we have in community.git.org. If you search for git's account, something, you will find it easily. It's something that it's very healthy, I think, to tell the incubated project to look into because there's really all of the information they're going to need. Also, it's not your job to tell or to teach them how to use gait. There's very good material on the interwebs about this kind of stuff. Maybe fabricator. It's something that you can put some kind of emphasis on. But actually, it's not really that much. My link to this website, but again, it's all about talking to sysadmin and being nice to them. And if there's problems on the sysadmin site, make sure that you are there to explain why it's happening. Like sysadmin, if they see someone from around them coming to them and telling them, give me my mail address, they will feel that it's weird but if you're part of the conversation, that's automatically fine instead. I don't think I'm forgetting something. But in general, the idea is that they should be able to just enjoy kitty to be part of all of the services that we provide to our community, all of the CI, the infrastructure, mailing list, websites, Promo as well. Actually, Promo is probably the last step of the incubation process. You made the project, you call it a kitty project. Now you need to make sure that the world knows it's a kitty project now. And well, we also, as Promo, we need to learn how to advertise it, see what's this project putting on the table and making sure that the world is going to enjoy it proper. But yeah, as I was saying, big, big parts are Promo, CI, minor is like one of the big problems that we're going to see when the project is finally in kitty, which takes us back to the first part of the slide is that the project ends up in this review process. The review should be fine because, well, in general, if the project is healthy, they won't have problems, and if they have problems, they will be fixed because it's healthy, but they will need to figure out where they want to be, which they usually prefer, or they actually usually use to doing their own releases because that's what you do for a note in the web. They have the option of becoming a kitty application project, so Albert will be releasing them or Christophe from time to time if it's a classical thing, and that classical thing. But in general, I think that everyone, I remember, that has been incubated, they've been self-releasing, eventually they end up letting Albert do the other thing, but that's just part of it. But the important part of the slide is that they will want to get binaries, right? They will eventually want to be on every distro, they will want to have window binaries. It's something that can be somehow handled in. Something you can remember from your project incubatees is that even though you've moved them down into the active projects in the incubation wiki, that doesn't mean that they cannot do anymore, they can just reach out to you and they have questions to tell you because, I don't know, there's scary people in the internet and you never know who you're gonna find. But if it's a friendly case, then it's always an answer a little bit. All right, so if there's any questions, probably that now it's a good thing. Well, that's a good question, I think they have the best answer. In general, I think that it's a lot of matter about knowing the people and well, creating this trust relationship. An important part about being a KDV project is the KDV is behind it, right? I think that this is an important part. KDV, those lawyers, if you ever have problems, you're gonna, we're gonna be able to figure the problems out together eventually. I think that this is an important part. But in general, it's a matter of seeing what their problems are and seeing if we can help them with them, if we can then, well, it's the kind of discussion we should be having. Another interesting thing is, as I always say, the binaries part, also translations, right? Like, when I started in KDV, I was working in the Algebra, it used to be a note in the Interwebs, like I was releasing titles every now and then and amazingly, people found it. Like, there was the first gesture that sounded, actually, I never understood why I did it or how did that happen. But then, as soon as my project was in KDV, it was automatically on every Leicestro, on Arx, and virtually on every, well, on a lot of languages that were translating. I think that this is something very powerful. There's certainly lots of very, like, if this project, for example, is speaking of that they have more or as many languages as we have, maybe they don't need us, right? But being able to create this kind of synergy just by being inside of KDV, I think that it's super powerful and certainly one of our best assets. I think there are more things that I don't think we're going to be able to do as long as we go to the projects. One of the things that the United States has been doing, and they don't have that already, there's no stations, there is C9, other than KD7 with C9, especially in most of the platforms where the projects play out. All of the development, really, on each platform, they said that we know, so we do realize that people know what we're called as Windows and that's where KDV goes. But not from this, I used to apply a very large number of additional projects who work on both platforms and have a position in the industry, and we can come back to this feeling that we're going to be able to get out of this kind of project. We're probably never going to incubate Adobe, but another point, KD projects get to have sprints sometimes if they're interested, but also be part of our fundraising exercises, right? They get to come to Academy and talk about their project and learn from other people who are interested slightly. I don't know, I haven't seen the limit, and I haven't ever seen a limit where we've had too many of them. On the other hand, we do have the manifesto. The line is definitely, do these projects follow the manifesto and the rules we have set? I think that this could be. If there are so many projects that are aligned with KD vision, that's great, it's not something we should be complaining about. Projects have failed. Projects have failed with others of innovation. We usually use if you are in any other system, in Github's system, we do get Seattle free although when we always have a government topic, we do get Seattle free and there are many projects that we can manage with Github. Well, you're not going to get the KD part of it, right? Github doesn't understand what Kayo is. And also translations you can say it gives you translation infrastructure but the actually important part of translation is not having translation software, it's having translators, right? That's actually the point I want to say that I think the value of my end of the year, of course, the value of the KD community is that in the value the thing that we can add and develop is not infrastructure or sky, it's actually translators, designers, problems and run-talking people about them, you know, which is still the same thing, right? When we're talking about how KD can do better CI, that Github is not because we're better than Github, it's because we know what our problems are and we're solving them when Github is not solving our problems. That's yes, but then that all applies to the same technologies that we're going to use. So as far as I knew the KD was a pretty bad project that perhaps we're a fighter away from the financial life and we didn't learn any other projects. So for those, then we don't have the kind of solution that we want. I don't think if you look at the list of projects that have been incubated like you maybe could learn, but the rest of the projects that are very similar to any KD project today, right? Also, KD Store is a different one, the rest they're busy, for less the same stock that we use. It's not really about bringing weird platforms. We know there's people who could be working with us like today, let's make sure that these people can work with us. We can extend that and make the circle bigger. So back to the last one of your questions because of the start part when we were not alone, we had really good interest to first, we had a dream that we would start a foundation for all of our jobs. And I think that these are the goals that we have to the CI learning of for all of these great activities to map out any active projects in the CI so that you can build it and build it. I'm happy that we're able to start making this I think that we're just to share with all of the departments in the way we're able to get to that KD applications on all of our products. And we're happy that we're able to start a foundation for all of the people on loan that we have now. It's been quite a search for that, and we chose but we'll just go back to this program and he will sit there. Yeah. So this one we have a call from the I can see that there's a call from the I can see that there's a call from the I can see that there's a call from the I can see that there's a call from the Somebody can correct me if I'm wrong but I don't really remember of a project that has become very bad for KD that we've had to kick out. We've had projects that they didn't compile anymore and we've said to put maintenance on maintenance but it's a different thing. I think it has a project. I think the reason we're going to do that is because it's a hard machine it's a really hard one we can't know what's up but we know they're maintaining it we can actually take it out that's the kind of thing that we have in the lines projects like that. In general I think it's more people losing interest in projects more than becoming evil because everyone who doesn't like this is evil. Alright, then thanks for coming and for all the questions Thank you