 Hello. Hello. Can you hear me? Yes. Yes. Perfect. Hello. How's it going? Maybe next time which we can share this link with you. Yes. Yes. I'll share my phone. You want to be recording this video? Yeah. Yeah. I guess we'll record it, right? Yeah. Good. Okay. That's fine. Do let me know when you can read my phone. Hi, Kristin. Hey, how's it going? How's it going? It's going good, yeah. Oh, good. Okay, cool. Yeah. So I shared my screen. So, looking, can you see it? Yeah. Yeah, good. So, yeah. So I just wanted to go over a couple of things. Since this is the kickoff meeting, like, what are the, I've written it down in the meeting. So, I'll just go over some of the items and if time permits, you could just go over the design. Right? Yeah. So, first of all, we would like to finalize the days and times of the two meetings with the mentors per week. So, because Oleg said it's up to the team, according to them, like, how many days do they want to meet in a week? So we could definitely, yeah, we could definitely adjust that. So, what are your, what are your preferences? I mean, do you want to have it twice a week? Once a week? Please feel free to switch in. I think sometimes we see better success when we meet twice a week, because I know that, you know, you'll be iterating over stuff really quickly and it just gives you a chance to ask like questions twice. So, you know, you have, you know, you can work on things and then, you know, you'll work with them. It's like an easier chance just to sync up in person. If that works for you, I think twice a week is good. I don't know. I don't know who's a, it's a CD foundation. Yeah, really cool. Yes, I agree with that we can have two, twice a week. If we don't have too much things to discuss, we can short the meeting time. It will be a good chance to communicate frequently. So everyone, yeah, go ahead. We don't have to have it at, you know, but the same time twice a week so we can, we can move around times too. Okay, because we do put, I guess, one fixed time on the, I mean on the Jenkins calendar, so would it be fine that if we select one fixed time and then the other one could be moved around? Is that what you're suggesting? Yeah, go ahead. Oh, sorry, I was thinking like it's, you know, they don't have to be, you know, like, at 8am UTC Monday, 8am UTC Thursday or something. It can be, you know, 8am Monday, UTC Monday or like, you know, 3pm UTC Monday. They're 3pm Thursday. Yeah, it isn't sorry. That's kind of more what I was talking about. Yeah, I'd rather just have twice or rather just have, at the same time, it's easier for us to make commitment to show up but you just have to be at the same like physical time. Yeah, yeah, sure. No, I got it. Okay, so is it fine if I float doodle and you guys can, you know, vote for the times that you are comfortable with and then maybe we can select the maximum one among us. Yep. Yeah, so we'll have to add that once we decide the timings we'll add it to the Jenkins event calendar, the project page and this meeting. Yeah, of course, we've got to add this meeting notes to the page. So yeah, I'll do that. And I would be using this color scheme if you guys are I've just copied it from the last time. I guess it was a multi branch get lab source plugin. Yeah, they use the kind of done work in progress not started yet. And I think I have that already open here. Yeah, but I just put it at the side of the items so that I don't have to assign everything to myself. So I can just, you know, you can whenever you log into this document is easier for you to know what's been done and what's in progress and what's not started. So, once the meeting's done, I just put them down. I've given you edit access to the document to tell me if you can't edit anything. Cool. Yeah, apart from that, okay, so the next key point that I need to discuss is get introduced to key stakeholders and contributors in this area. So like mentioned, we need to this is an important step of the bonding period. So I drew up this mailing list. I think I'm not sure if you're a part of this discussion when the initial project idea came out. So this was the initial discussion that happened to put it in a meeting that you can have a look. This was the one. Yeah, we had a huge, I mean, quite a huge discussion on this as to what the issue is a huge thread, you don't have to read all of it. But yeah, these are kind of the stakeholders that were quite interested. One was Chris, he expressed a lot of interest in this. The other one was manual Ramon. And the third was, I think, Lee. Yeah, so Lee was another one. So there were quite a couple of stakeholders interested in this project idea. I'm not too sure exactly. How do we want to proceed? Do you want to send out a general statement in the mailing list introducing the stakeholders to the project so that if interested they could just join in or you want to send out an personalized email. I'm not sure that goes on. So if you guys could guide me on that, that would be amazing. Yeah, it would be great to make an announcement on the Jenkins developer mailing list. You may have seen that this project is already included into the Jenkins roadmap. And we consider it as an important project for the Jenkins community. So sending an announcement to the developer mailing list with introductions, etc. is totally reasonable. And you can also ping people in the developer mailing list thread, which we had during their initial discussion of this project. That's what I was thinking, because they're already interested in the thread, so they're going to be following updates and it's always good to just continue to say, hey, this was actually selected. This is working on. He can join our jitter channel if you would like, because that helps a lot too for this movie, because maybe they don't really attend meetings, but they can provide some asynchronous feedback. Yeah, okay. Okay, yep. Cool. I'll just add it here. Awesome. Cool. So, yeah, apart from that. It's all good. I am. Yeah, so yeah, the next thing was discussed. I'm not sure this point is as relevant now during the community bonding phase, but I seen the last year's project as well. And they discussed it during the, it was included as a project topic in the initial meeting. I'm not sure relevant it is now. But discuss with mentors about code reviews and PR. So the issue trackers, because I'm hoping that the project since the back end would be built in springboard or Java that's up for discussion still. But yeah, whether we should use how relevant it is to discuss it now you want to defer it for later. We'll discuss it now. Okay, cool. Yeah. So yeah, tell me your, so as since I'm the student I would be expected to drive this. But I'm comfortable with using both the GitHub issue tracker. I've seen a lot of discussions happening on the Jenkins mailing list as to whether the GitHub which there's been a lot of discussion on using just GitHub or using just I don't have very strong opinions on them, but if you're using GitHub then since both the code and issues can be kept in the same place. I think that's a good idea. What do you guys think Oh, you might be able to help with this a little bit more because I last last year we worked with or I worked on a project we use the JIRA. And I know it's easier to consolidate everything for using GitHub issues but I don't know if that's what would be preferred. Yeah, I can show my opinion. But yeah, I would prefer to let mentors and students to share their opinions first. Yeah, go ahead. Oh, Rick. Rick, do you have any have you worked with like the get out the shoes or the JIRA and I don't know if there's a preference. So we used JIRA in last last years, maybe recent years. But in my opinion, GitHub issue is a good choice. And also we can create a project in GitHub so we maybe try to use GitHub issue. That's where we can, we don't need to switch too many system or page, just focus on GitHub. I'm cool with that. I'm okay with that. Since it is easier to track, I, yeah. Maybe GitHub issue and GitHub project. Yeah, yeah. So a second, this recommendation. GitHub issue is quite convenient for these related projects. Why we use JIRA in Jenkins heavily is because we need to make changes across multiple projects, conference. Historically, GitHub was pretty weak about that. But now, yeah, even though it makes sense. And for the project, like the distribution will service, it's much easier to use GitHub issues. If you want to reference something in Jenkins due to use, you still can do that. Otherwise, you just have everything is related in your own repository. The only thing you will need to keep in mind that you will need to somehow manage access to your project dashboard. But assuming that Slading and other mentors will have right access to the repository, it shouldn't be a problem. For example, what we had to do with this configuration as code, we had to create a project on the organization level, instead of the repository level. But, but yeah, for this project, it shouldn't be a problem. So GitHub issues it is then. What about other projects? I mean, we get to five projects in this year. If only this project use GitHub issue and GitHub project, maybe we cannot get a full picture of the disk. So I can provide you some examples in a Windows service wrapper project we have already agreed to move forward with GitHub issues. In Jenkins X, most likely they will be using GitHub issues as well. And it's highly unlikely that they will be using Jenkins Jira. And for the projects is basically up to project contributors and maintainers to choose. So, personally, I expect that many projects will go forward with GitHub issues this year. Okay. Okay. Yeah, cool. Okay, so moving on to the next topic. Communication to org admins. What do we need like hosting new plugins, trainings, tech advisors. Since Jira isn't there, so would the opinion be that we'll be using GitHub project boards for it now? We're not using Jira? I have some, I feel some confused about new plugins. So do you think we need to create a new projects or new plugins or just a web project? I mean, not a plugin. I'm thinking it's a distribution service. It's not going to follow the normal plugin life cycle, right? Because it's not a plugin and won't plug into the Jenkins ecosystem, right? Yeah. It's going to be a separate project. So I don't think we would. I'm not sure how to go about the hosting. I've included my proposal since it's a bit different. I mentioned that there are health charts to launch services using the Jenkins infrastructure. I'm assuming it won't follow this part yet. I'm not sure we're going to go through this hosting plugin. Well, generally we go through this process anyway. Obviously, we don't apply the same checks if the repository isn't a plugin. So how we usually approach it for new projects. You create a repository skeleton in your own repository. And then once you're ready, we host it on Jenkins. So preferably to do it before the end of the community bonding phase, so that we have all permissions and other areas fixed before you start coding. But yeah, it shouldn't take long for arbitrary repository. Okay. Okay. We'll do this. Christian, any thoughts on that? Nope. I think this is something. It's okay. One question to you. Do you anticipate it to be a single repository? Or is there a chance you will need multiple repositories? I'm assuming since because this project will entail a front end, it's kind of the back end would be separate from the front end. Initially, I was thinking that it would be two different repositories and then it's easier to pack the JavaScript HTML and CS or whatever that we're going to use in one repo. And then the back end service in the other repo, so that they are quite modular and separate. But if that's what that's what the way I was thinking about it, but if there are any other suggestions as to having a benefit of having a single repository, I'm up to change as well. I don't think there are too many benefits on that because whatever you do, you already have custom work packages. Custom work packages is going to be a part of the back end. And most likely you will have to submit some fixes or patches to custom work packages during your project. So I wouldn't expect everything to be in a single repository. And it may also influence your decision about where you put the project. Right. I was thinking the same thing. And if you can always decide to get multiple parts together, but it might be easier for just trying to locate everything. Okay, so you're saying that we'll have multiple repositories? No, no, I'm saying you have one repository. Everything is kind of packed in there. You can have the multiple folders. Like if you want to be able to separate UI code, I don't think that it needs to be a whole other repository. At least in the beginning, because we can split it later if there is a strict need. But it would be better not to open engineer this stuff right now. Okay. Yeah, plus from me, if we don't have too much benefit from separate it to repository just to keep it into keep them in one repository. We just need to create two folders to separate them. Okay, cool. Do you think we need to create a workflow to about how to host a regular project? What do you mean a knowledge transfer? I mean, if if someone want to host their project into Jenkins there or how do they need to do? Well, it's pretty much like hosting plugins. So there are some minor differences, but you follow the same process. Right. Okay. Yeah, maybe we will need to update our documentation soon. We have just created a hosting team one week ago. And one of the responsibilities of hosting team would be to improve documentation, including to find the moving this hosting plugins week page to Jenkins.io and breaking it down to developer documentation pages. But in principle, it's the same. And moreover, it's quite straightforward for JSOC projects because JSOC projects already considered accepted. So it's not something we will be discussing feasibility and other things there. Okay. Okay. Yeah, cool. So, I think we'll discuss the hosting new plugins since it's a project will be following the similar workflow. We'll get that up before the coding phase starts. Apart from that, yeah, this number. So I guess we're not going to be using, I guess last year or like the entire JSOC team, I mean the JSOC projects use the Jira scrum, the Jira boards. So would they be following the same procedure this time around? I don't think so. I will create Jira boards for projects which need that. And other projects are welcome to follow their approach. For example, if you use GitHub project. Or if Jenkins X team, they will have a GitHub project as well. You can just stick to that project and reference it from your documentation. We will still create a Jira board for those who need that. But we won't be forcing that. Okay. So, is there any thoughts on that? I'm just listening to this because I think it's. Okay. So basically what you could do, you could create a GitHub board. Maybe one for all three phases or one per phase. As you decide. Yeah, for phases. Sorry. I was like, is it easier to use, if you don't want to create the board, is it easier to use tags so we can see everything that's happening. That's I guess projected. Does GitHub allow you to do that? I'm not as familiar with the GitHub. GitHub, you can use milestone for that. Okay. Because maybe it'd be easier to see everything together. Yeah. One query is milestones that there is no cross repository milestones. So if you want to create advanced queries, you will be responsible to manage milestones across multiple repositories. All right. Okay. That may help think a little better. So it's still not a big deal, but yeah. Is it easy to move? Sorry. This is just people aren't gonna think it has issues too. Is it easy to move things if, you know, we put too much work into a milestone, like just optimistically. Is it easy to move a task from or like from one board to the next? Yeah. Okay. Cool. I think that was amazing. Because it's really, you know, you get very, it's very easy to get very excited about because you're like, oh, I can do all these things. And maybe things take longer than you originally thought, or it's like you just put too much and it's just impossible to get it done. And if it's easy to translate it to the next board, then I think I just don't want to have to create work twice. That's what I'm trying to do. Yeah. You have contributed that. Okay, good. Okay, so should there be one board for the community morning, like an epic for the step to be done or could we just keep out that phase from the boards. I mean, not to say skip, but should we include it in the GitHub board? Or is that not needed? I don't, to me, I think we could keep it in the dark. I don't think we need it because I just be more focused on the code. Okay. Is that makes sense to everybody. Well, if you use GitHub project, GitHub project, you can put core tasks and non code tasks. Okay. Yeah. So core tasks can even have automation. So for example, GitHub issues, they can be linked to pull request pull request and they are to make it remote between stages. And whatever other things. But if you need, you can just add a task, which is not really blank code. And you can add the task, which also doesn't fit the GitHub issues. If you want to avoid putting tasks like write a blog post there. Okay. Yes. Okay. Do you want to say anything or then we can move on to the next topic, I guess. Okay. Okay. So trainings. I mean knowledge transfers or training sessions, I think that up to us. If I need anything, like maybe, I think last year there was one of those training sessions that Justin took for debugging in Java. So I do discussed in yesterday's gsoft. I mean, yes, not yesterday's the meeting on Wednesday that there will be common. There will be common knowledge transfer sessions like course, like creating a plugin or some sort. So I think that really is on demand. So if at all I need something that the team could have a training session on, then I could request it. Otherwise, that topic is really, is really personal, I guess. Yes. So, and specifically in your project guide for creating plugins won't really help with your objectives. So for example, if you want to have a code for custom work package. Firstly, there should be already recording somewhere. If you want to have a fresh recording together, we can organize that. Okay, it will be my one hour of shame, but I'm really ready to present this component. Well, I think it would be useful for the contributors because we get contributions for custom work package. This project was slightly abandoned by me during the past six months due to some issues non related to technical ones. But you're right now, I'm fully able to contribute the different patches. And if somebody else wants to contribute, I will definitely appreciate that. So doing the code if makes total sense. Okay, so maybe we could organize this. Yeah, just before the community bonding maybe ends while I'm preparing the design document. So I've included a link here. Yeah. Just second, I will create a doodle because we already started to do for another knowledge transfer. So she just copy a paste for me. So do you want to have it next week? Or is it fine if we do it later? I mean, I'm, I'm up to it. I mean, as long as it happens, don't really mind next week. Oh, so taking my schedule, maybe it's better to do it next week. Okay. Okay, so let's say so I do not commit to do it next week. I will send it for two weeks. Okay. Yeah, I'm just creating that. So you can continue the discussion. Yeah, you can create it in the chat in a few minutes. Okay, so trainings done. Take advices. I'm not too sure why this topic is they have just copied it from last year's community bonding to do list. I mean, the first meeting that they had. But yeah, the take advices, I guess that pertains to stakeholders of experts in the domain or whatever we are dealing with. So last year for the multi branch pipeline plugin for GitLab, I think it was because he was doing most of the reviewing. I'm that but I think in our case we already have rake or maybe customer package if at all you're making patches we have Olex so I guess those would be that and Christian obviously will be reviewing code as you. Yeah, that's in your book. Yeah, I think it's down here because these are the main components I'm not too sure about the front end part here. My JavaScript my sentence gears are okay. We have Felix as one of the advisors on maybe the front end part I'm not too sure if we can arrange that. He made a couple of comments to the proposal, but yeah, I'm not too sure of his availability during this period. I don't know anything specific. But definitely, once you have a first prototype, you can get feedback. Because, yeah, we have a lot of contributors with you are you X background. By the way, I put a link to doodle for customer package at PT. You can find it in the chat. Yes, I think we've discussed the last topic. Then you get a repository when the gent can see I all I think you put this on right not sure if we should hit it during the coding case. I think that's already answered it. It would be nice to do it before the community bonding case. So yep, I'm just taking this comment out since the questions already answered. Cool. Yeah, so that's about all of the. I mean that's about all of the topics that we have to cover in the kickoff meeting. Is it okay? Yeah, one more thing before you want to maybe designed out the zoom link. So I guess since it already has access to the CD foundation, but we might have conflict. So is this zoom going to be given to one of our mentors like maybe they could have a meeting. So there are some process issues I need to figure out. By coding face, we will have access for Rick. Well, for Rick, I believe I can share it right now because he has access to CD F zoom. I can access the CD from this zoom account and also access from the YouTube account. So I can upload the video. Yeah. Right. So the discussion was about Jenkins zoom account because we have a second zoom account which is specifically created for the Jenkins project. Because there is a continuous risk when you use the day of account that you run into a collision with another project. Because for Jenkins we can use Jenkins calendar and your advice to put your regular meeting there. But we cannot expect CDF to do the same. So we hit multiple issues with CDF account being clogged. And that's why my recommendation would be to switch to another zoom account. But I can share access with you. Okay. Do I need to send an email or something to request the Jenkins zoom account? Okay. No, for you. It's not needed. I will just forward it to you. Okay. Yeah. So I plan to have an official process for that. But since we do not have an official process, we will just forward it to you. And a very secure way, by the way. Okay. I will just send you an email. Okay. I would like to add the meeting you wanted to take as a calendar. You can send the text to me. Okay. Cool. Yeah. So apart from that, yeah, next step, I guess anything. Okay. So am I missing anything that you guys want to discuss? That's necessary for a kickoff meeting. I guess I've got almost everything. So anything you guys want to say or add. Any technical things that are missing? Okay. So I guess the thing that I was thinking about is if you're trying to determine what framework to use. And throughout like spring, spring boot. Yeah. I don't know really like, do you have like a preference for anything? No, like you would. Okay. I was like, I didn't know if like you were trying to learn like a, something new or like focus on like a Java based solution or anything. But yeah. Cause there's a lot of different things out there. Yeah. Yeah. Yeah. That was, that was when the project was announced. Okay. So I'm moving on to the next section. Sorry. Yeah. Well, that's exactly. Yeah. It's okay. Yeah. So the next one was the design doc. Oh. Code design document. So I decided to go with it. So that we all have technical details ironed out before the coding phase begins and we don't run into any unexpected glitches or turn. Yeah. Yeah. Obviously we can change certain directions here, but yeah. Yeah. Yeah. I was just thinking that it would be good. Yeah. To talk about this is that way, you know, you don't get stuck spending a lot of time during this period of time, like trying to figure out how to set things up. And then if we need to also like the technical mentor section, and like, we can always find. Yeah. We have, like, we all have experiences of one thing, but it's also like, you know, we're like, we can actually get to the point where we can actually get to the point where people might be interested in the perspective of, Hey, you know, this was an issue that I run into with this before. So that helps. We can help find technical mentors for that. Yeah. Sorry. That's kind of where I was going with that one. I was like, oh, we can pull in extra people or who might be interested, depending on what the. Yeah. Yeah. If you need technical advisors, we have people experienced with spring. If you want to try something new, for example, like a good framework, it has bridges to spring. Yeah. Again, we have some people for experience. And if you want to have a mentor to use experience with Quarkos, I may be able to help with that. Not me personally, but I know right people. Yeah. Okay. Yeah, definitely. So yeah. So then coming back to the question here. Yeah. So this was one of the discussion that we had initially when the project was announced, I think Rick mentioned Bo Land because he was very familiar with it. But then Oleg told us that it might be a bit like it's advisable to choose a certain language that didn't get a lot of community feedback. It's easier to code reviews and to deploy. So spring boot actually is, yeah, it's Java. We can actually have a Java based solution as well. But yeah, this was the reason we were thinking of spring boot was because it's just, I mean, it could easily integrate with the front end and it's almost just Java actually just with annotations and just the ease of deployment. And we have a lot of easy to spin up a server and, you know, have a container and stuff. So that's what that's the reason I wrote the Java spring boot. But yeah, I'm open to suggestions before we, yeah, before we begin. So yeah, just just throwing your ideas and add it to the list. I don't have one opinion. Rick. Not for me. Okay. Yeah. Yeah. So do you want us to stick? I mean, do you, you were saying that we could rather move to a Java based solution or spring boots? I'm just also trying to think of what would be the best way to be able to, people interested to be able to involve the community after the summer, right? Cause it's another thing to think for that the project doesn't just solve out. Yeah. Especially since it is important to. And we'll be continuing on the road map. So. I just sort of think of like at most. Like what would be best thing to be able to encourage. Usage. Or like continued development. And I think it might be, and. I don't know if it's like the. Java. I don't, I don't know. Like Rick. Like if there's an opinion of all, what would be able to encourage. Future development for this or like to be able to. Yeah. Slater's going to knock it. He's going to be well over the summer. Got this awesome project. And I was like, all right, like let's get other people here and like, continue to continue developing it or like finding new, like, Hey, it's out of new feature. What would be the best way to continue to encourage people to start developing it? I think. My advantage of a Java stack, which is not currently listed in the list. That you get access to libraries and tools we have already created. So for example, customer package that can be used as a library like installation manager. We can be used as a library. I'm not sure whether it's really needed for this project, but it's an advantage. So at the same time and go, yeah, there are already some libraries for that. For example, Rick is working on. And go is also a general purpose language now, which is quite popular. So if the team decides to choose go, I do not think it will be a major problem. Okay. So that's a reference providing definite answer. So as long as you do not create something in the white space, I'm fine. Yeah, definitely. Okay. Yep. So something in the community, something to encourage future developers. I didn't mean my name. So, so are we going to make a decision right now as we define the design document we're going to move on with it? Or do we play? Yep. I don't know if we need the, I just think it's something to keep in mind. We can get the design document and pick a, pick something later. Okay. Pick something later. I don't want to hold this up like sitting up here to like working on the find particularly, particularly the language for our first meeting. Okay. I just think it's something we should see. Like, all right. Yeah. It's like, it's really fun to learn something. Yeah. Like, Yeah. Yeah. It's fine. Yeah. Yeah. Exactly. Okay. So yeah. I think Rick, or do you have anything to say on this because you were the initial, initiated for this. So do you have any strong opinions on what kind of side we speak or move on? I think. I think. Yeah. Yeah. I think. Yeah. I think. Yeah. Yeah. I think a job is a. Pretty. Convenience. Not good. I agree with your proposal. About. This. This. Text. So yeah. Maybe decide. Yeah. As in when we finalize the technical details, you could come up with baby. Yeah. So it's the seller thing. So as Alexa just, if you use Java, then we have the liberty of using some of the most developed libraries and tools. Yeah. So we can stick with that. Yeah. So apart from that, so I not just started the design document, obviously for the next steps would be to believe the, as we decided the next meeting slots, we could finalize in view on this design document to reflect most of the work that we are going to be doing over the coming, coming weeks in the community bonding. If at all the design document gets over early, maybe we can start type for, for the first stage. So yeah. I think that that's the next step. Any other next steps or anything you want me to discuss before we finish it because we can move on to the next meeting. So yeah. Anything else. So, maybe we need to consider the localization for the you and stuff. I'm sorry localization, but I didn't get you. I mean, we should to support the multi-language from the U. Okay. We are multi language. Okay. Yeah. Yeah. Okay. Yeah. Yeah. Okay, we have multi language. Okay. Yeah. Cool. Yeah. That's a another thing that we need to consider because the initial problem is getting the UI generated as we, as Oleg suggested in previous meetings that we've had in the, the doc, the CDS. We still don't exactly know exactly from where exactly we're going to get all of the fields. So we could scale it in the map. So once we actually have that we can, you know, have a localization that I'll add that point since you mentioned. The localization of the UI. That's one thing in the detail. Cool. Yeah. So yeah, I just added a few components. So it'll have the user interface obviously and the backup service. So as I mentioned in the read me, we'll have a generation of a Docker which I hadn't included my proposal initially, but yeah, we'll have that now. The generation of the app file, the Docker file, the work and the desired storage of configuration to get the positive. Those are the main user stories. Apart from that, as in when the design documents gets fixed, we could just keep refining which is still a project community bonding. Yep. Anything else to add before we, before we wrap it up? Nothing. Thanks. Thanks for, thanks for the time I was sharing the doodle for the next meeting slots and you guys can choose. Okay. All right. Thanks. Thanks everyone for the time really appreciate it. Cheers gentlemen. Thanks so. Okay, thank you. Thanks. See y'all.