 Hello. Hello, everyone. Welcome to the GSOC weekly meeting. Today, we have regulars in CUP to talk about the incoming GSOC 2019. We have already applied to GSOC. We wait for the application feedback, but in the meantime, we still prepare to the... Just a second. I'll mute him. Okay. So, yeah, we just talked about the projects, try to get them over the fence and answer any kinds of questions from our students and mentors. So, that's the objective. I'll share my screen and here. Do you see my screen now? So, if anybody wants to join, there is a GitterChat, and in the GitterChat, you can find a link to this broadcast, so you can just join the participant link or we will post it in the YouTube and the results are linked to the meeting notes. So, we do not have specific topics in the agenda, but since we have new people on the call, let's do some introductions. Then, yeah, we can sync up on ongoing action items and, yeah, Kone and then project ideas review. Anything else to add to the agenda? Okay, I guess now. So, yeah, since we have several people, would you guys be interested to introduce yourself? Hello. Hello, everyone. I'm Sagar Alani and I joined the SIG Group, I think a month ago, but I was busy in my projects. So, for starters, I have read the Jenkins handbook and I have also developed one plugin using Baldung's blog post. So, I'm exploring Jenkins right now and I was interested in configuration as a code plugin and role strategy performance plugins. And so, I read the documentation about configuration as code. It says, I think I read it one week ago. So, it said we have to select some plugins which we can improve. So, is there any further talk on which plugins should we improve or I have to explore some plugins? Yeah, let's take a look at it later. I'll add it to the agenda so that we will discuss once we get to that. Plugins to improve. Okay, I add it to that. So, we also have Arnab on the call. Arnab, would you be interested to introduce yourself? Yeah. Hi, everyone. This is Arnab Bani. So, actually, I was a GSOC student last year and I had done my project under the INCF organization. So, the project was in Python and it was in the domain of computational biology and in the domain of... It was basically in the intersection of biology and coding basically. So, from a domain point of view, it was not something that was related to what Jenkins is all about, but it was a good GSOC experience and I completed the project successfully. So, now that I've graduated from college, I'm not allowed to be a GSOC student anymore. So, I won't be applying as a student this time, but this time there are two projects, the discard steps, the build steps project and like working on that plugin, that project and the other project which is probably the only project in the list which is in the windows environment, C-sharp and all that. So, those two projects are something that I found a little interesting. I haven't yet jumped into the code base. I haven't done a deep dive analysis yet, which I plan to do in the coming days. So, I'm planning to co-mentor those two projects and since this is my first time just giving an introduction, so currently I'm working as a software developer at Credit Suisse, which is a bank. I don't know if you've heard of it or not. Okay, thanks for the introduction and yeah, we also have Python project ideas in the review. We can talk about them later. Okay, and Martin, could you please introduce? Not Martin, but yeah, there is a student together with you. Yes, I'll pass him the mic. Yeah, okay, I'm Derek Hacklott. Like I said, I'm a student. I'm just in grade 12, applying for a university and I'm applying for software engineering and computer science. So, this is probably what you're doing is what I might be doing in the future. So, I want to see what you do. Thank you, Derek. Well, I'll just introduce myself quickly. My name is Martin and I'm a 4Gadmin on this program as well as a mentor of the Green Program. And we also have all other 4Gadmin. So, my name is Alek Ninazhev. We have Jeff Pierce on the call. We have Loi Chiang. And yeah, we also have Riko on the call who's a mentor for the GitLab SCM. So, again, we already introduced ourselves. So, yeah, maybe we could continue with the discussion unless we want to spend more time on introductions. What would you prefer? Okay, then let's move on. So, let's take a look at our action items. So, yeah, I added a config as code, also discard build steps. Then, yeah, we will have some other project ideas. Okay, actually, I will move it here. Okay, let's start from the action items. So, we have some action items, which open for a while. So, Martin, it seems you invited every mentor to the main mentor list, right? At least there may be a lot of messages about that. Yes, I did the invite from the Gitter Chat. My plan was to look at the list and see if everybody is signed up. And if not, I'll send reminders again. I think the next time I'll go with personal messages in Gitter. Since I don't have those demands. Okay, thank you. If you're a mentor and if you're not in the main list, let us know, we will add you or you can just request join me on yours. Then, now the action items. So, swag distribution in printing. So, my plan is to get everything delivered during February. If nothing gets delayed. Regarding special interest groups, hardware in the NDA Seq is published. It's ready. Embedded Seq is still on me, but we do not have project ideas for embedded space so far. So, it's not critical for JSOC. But, yeah, if somebody wants to have something specific to embedded, yeah, Martin, welcome to do that. And, JSOC is still open. Expense report, Jeff? Still not done. Okay. In the worst case, you can just donate it to Jenkins. But, yeah, I encourage you to expense it finally. Actually, to be honest, I was considering just doing that. So, why don't we say that that's the outcome? Yeah, we will just need to ask Kit to send you a thank you message after that. Okay. Yeah, and then what else do we have here? We had some Coini last week. I believe that all action items are all done. So, we got some clarity on multi-branch support for GitLab. Let's discuss it today since we have both mentors. And then, yeah, we still need to organize something for Docker things, but we started a new GitHub chat for Docker. So, I believe that everybody interested in this project will be moving there and they will be more focused to discussions. So, yeah, I think this action item is also done. And, yeah, what else did we have? Actually, that's it from last time, I believe. Am I missing any action items? Oh, yeah, I like opinion of folks about project application feedback. So, yeah, we have one week before the application deadline. Everything is in place, but if you want to propose improvements in the application, it would be better to do it now. So, please take a look at our application document and if you want to change something, especially if you're an org admin or a mentor, let us know. So, it's located here, GSoc 2019, and in the bottom, you can see application draft. So, this markdown document, and effectively you can just propose a pull request and once you do that, we will reflect it in our application. Yeah, Oleg, this is Lloyd. There was another item, I'm sorry, I have put it in the same paragraph as Docker has signed to Martin, was about balancing the mentors across projects and ideas for mentors not to be spread too thin. Martin said you'll give a thought on it. So, I have signed it to him in the Google doc. Okay, should we discuss it later too? Balancing mentors for this one. Okay, so we will think more about it. So, yeah, we can just discuss it today if we get to that. Martin, are you fine with that or do you want to take more time to process it? Well, I think when we get to the point where we have reviewed the student applications is when we're going to have to do the balancing. For now, it's just we have to keep all the project proposals going, you know, as students are asking questions, we just have to keep it going. I don't know of another way. Yeah, I do agree. So, for now, there should be no large traffic. So, yeah, this project idea requires some more time. And yeah, we get some student requests. So, yeah, that's nice. But it also requires mentors time. So, let's proceed to CoNA them. And then probably if there are more thoughts, we can just discuss it after the meeting. So, configuration as code plugins to improve. How many mentors do we have today on the call? Me and Martin, right? So, no other mentors for this project. So, just to answer this question, there is so there is our project ideas list and there is configuration as code compatibility project. So, in this project, okay, no, it should be fine. In this project, we have we don't have specific list of plugins. But what we do, we actually reference plugin compatibility dashboard is here. And there is a number of plugins which still need to be made compatible with JSOC. So, this configuration as code plugins. So, there are some major plugins, for example, here, let's take a look, for example, Gita plugin, Gradle plugin, Gary Trigger, they are not integrated. Also, some, there are some minor bits in other plugins. And moreover, there may be other plugins which are not compatible. So, that is a quick start. And actually, the quick start presumes that you can just, you could try several demos. And if you like this project idea, you can just take a look at existing plugins and see what is not compatible. So, yeah, we expect students to come up with their own list of plugins, though we can make some suggestions as mentors. So, Martin, from the top of your head, which plugins would you recommend to focus on? I would go with the most, the plugins that have the most installations. But off the top of my head, I know that there's been some progress on the external workspace manager, but it's not a very popular plugin. Yeah. So, we can just go to plugins drinking saio. And if you're interested, you can just open plugin and you see here, you can see number of installations. So, for example, this is something like seventh solvent, which is pretty high for a plugin. And yeah, we can take something else. We can take Mailer plugin, for example, but yeah, Mailer plugin is installed almost everywhere. So it's 200 solvent installations. And yeah, there are still some improvements possible here for jcask. Yeah, you can take plugins based on installation numbers or my recommendation would be to actually take plugins based on your own preferences. So if you're like particular area, for example, if you're interested in git stack, or if you're interested in AWS stack or something like that, you could just make a proposal around these stacks. So you can propose, I would like to work on plugins in, let's say, for Microsoft Asia. You just explore the plugins and find some issues there and provide a list of plugins you want to focus on. And it would be a really good starting point for project application. So, which area would you interest to use, Agar? Hello, Oleg. I think I will explore the quick start guide which you have given, which is on the document. And I am quite interested in, I think AWS. So I will explore the AWS space and see if I can make any improvements. Yeah. So for AWS, you can just, even just search for AWS shows quite a number of plugins. And I'm definitely sure that some of these plugins are not compatible with jcask. So how to discover them? One of the ways is actually to look at compatible Jenkins version numbers. Because if the version is low, for example, if it's something like 1532 or so, most likely the plugin uses alt APIs and it's much more likely that this plugin isn't compatible with jcask. So if you want to discover issues, it's one of the ways. You just take a look at this list, find plugins which you like, which you use. So if you use AWS Lambda, there is Lambda plugin, device farm, there is also plugin, et cetera, et cetera. So you take a look at these plugins, most likely you will see some incompatibilities. And yet it could be a good starting point. Okay, Oleg, I'll watch into it. Okay. So that's good. So Oleg, I wanted to discuss about something like about the list of projects, actually. So I was wondering if it would be a good idea to maybe, you know, in the projects page, if we have maybe an additional attribute for each of the ideas wherein maybe the senior contributors of the Jenkins team can decide which projects are maybe high priority, because some organizations have seen what they do is they write that for every project they write the priority, like is it a high priority project or a low priority project. So what happens is when the student application period opens and when there is a sudden inflow of a lot of students who are going through all the all the project ideas for many organizations. So sometimes when a student is confused between which idea to work on, and maybe there are multiple project ideas which are all like equally interesting to the student, then the student might, the student's decision to decide which project to work on might depend on that. So I don't know if it'll be a good idea to do that for Jenkins as well, but because like you said that there are many plugins and they all they are all like concerned with different stacks, like some are related to get some are related to AWS. So I don't know if it would be a good idea to do it, but yeah, so maybe you can think about it. Yeah, so Rankin projects is definitely a good idea. The problem is how to rank these projects, because yeah, one of the ways would be to just rank them by value to the community, but in the case of Jenkins, the value of community really depends on your use cases, because these cases may be completely different. So just using this criteria it would be extremely complicated. So yeah, we can potentially say that okay core features would be higher priority for the community than plugin features, but I would say that even in this list it doesn't seem to be fully correct. So yeah, if you have ideas how to rank these projects, it would be interesting to know. Okay, and another attribute which generally like again, like we don't have to do it just because some other organizations also do it, but another thing with some organizations I've noticed do is that so in the skills column, apart from the fact that so and so languages will be used in this project, sometimes they also write another thing if it will be a difficult project or if it will be a comparatively easier project to do. So I don't know, like you said, these things are a little complicated to decide because especially for the importance part like you said, what might be important for the community might not be important for someone who's using, you're not using that plugin. So it depends on the use case like you said. So yeah. Yeah, thanks for the feedback. So what do others think? So we discussed this topic in a slightly different way in the previous meeting and why my thoughts then and I think I relate to Martin because Oleg you had to step off the call and Arne wasn't part of the Jenkins mentorship yet was that we should prioritize in ensuring that students, all students interested in apply for a project can receive mentorship. So it's a slightly different way to think about it. Our primary interest is in building community as a highest priority and in doing that is to ensure that we have enough mentors for all the students in projects for GSOP and which means I don't think it's something we can immediately address tactically but it would be until later time when Martin says what we need to start balancing how mentors are distributed across project proposals from students. I know it's somewhat complicated and it's not the type of thing we can easily put onto the Jenkins IO website how other projects which is simply this priority high, priority low, priority medium and so on. For ours, we actually need to see the student applications in order to make that type of priority assignment. I think it makes sense. Yeah, so one of the simple ways to do that would be to just start the projects by the number of potential mentors. Well, it's something we could do easily. I am not 100% sure it, well in these projects number of mentors is probably the best criteria we could estimate without digging into the value to the community or project priorities because if there are more mentors, there are higher chances that this project is interesting to the community and that then it may be successful when and it may be scheduled when we do mentor balancing. Would it make sense if we just sort a project? I think we can do that as a first step of my concern is simply for yourself, Oleg and Martin you'll probably have to divide yourself using fractional numbers because you're spread across five or more projects for each of you. But I don't know the exact count. Yeah, in my case, yeah, since we have some ongoing discussions, I already built some preferences so I could remove myself from a few of these projects if you feel that there are too many mentors for me. Yeah, and the specific context where it came up was in a prior meeting, Benith asked he was interested in several projects and or recommendation which one he might want to pursue based on the community's priority. And my response to him was that both Andre and Justin are available as mentors but only for the Docker projects and since beneath how already been in conversation with him online about it, try continuing that one whereas the other projects I don't know at this time whether mentors would be available or not. So that's a specific example about this conversation. Yeah, so here we have potential mentors. So right now there is no strict commitment from mentors as well as there is no strict commitment from students. Now we try to ensure that the mentors understand and what means being a mentor. Yeah, if we have discussions with people who want to join this list to understand that they can really commit on that potentially. But yeah, I understand your point, Lloyd. But yeah, I'm not 100% sure how we could address that. I think it has to be a case by case basis. Yeah, for example, for me the problem that yeah, I'm listed in many projects because these projects are potentially interesting to me. And if there is a good application from students, then yeah, depending on the quality of applications, my preferences among these projects may differ. So I just state that I would consider to be a mentor in projects and that I am ready to be a contact point at this phase. That's why my name is not everywhere, but in many projects. I think it's okay, but yeah. So let's sort and projects by number of mentors is something we can do. It's easy to implement. What else can we do in order to improve the experience for students? Lloyd, if you propose removing mentors, so if they listed into many projects, it's probably something calls. We can do also. Sorry, your audio breaks. Yes, can you hear me now? Yes. Okay, so let's say when Jenkins is giving the application to Google. So for every project, the list of mentor also has to be given or is there a pool of mentors given and then the distribution can be liquid later on. Or is it that before the application, like before during the application period itself does Jenkins have to make it clear to Google who are going to be the mentors for which project? No, it's not needed. So it happens during the student selection phase. So before the student selection phase, we don't commit on potential on mentor teams. We expect to provide an approximate number of people who are interested to be mentors. And we have this number from this list. But we don't commit to provide marketing immediately because it just doesn't make sense. We can say that, okay, we have this project, for example, IDE coverage adapters. We may have a brilliant student application, and then everybody from the list wants to mentor that or maybe not. Maybe we can, we won't get applications at all and mentors from here will migrate to other projects. So right now, there is no committed mentor teams. Okay, so I think then the issue of balancing mentors, then don't you think that it shouldn't be much of an issue then? Because over the next month, as the, as we see, like, which projects are getting student attention and which products are not getting student attention. So accordingly, then maybe the balancing can be done, then like, will it be something to worry about now? Yeah, I just, that makes sense to me. Just when this initially came up in the previous office hour, it was more from the students' perspective of saying, they're all listed as potential mentors. I'm not quite sure which one I should proceed. And both Martin and I recommended that the most successful projects are ones that are driven by the students ensuring that the outreach to mentors results in a good working relationship. Yeah, that's right. Yeah. And also, I think during the proposal phase, what I've also noticed is that most of the successful projects are those in which, like well before the deadline, the students start working on their proposals and they have their draft reviewed multiple times by the community members. And they have multiple changes made to their proposal. And so that by the time the deadline comes, their proposal is almost perfect to be selected for that project. Yeah, that's also true. So our experience that all successful students had the reach out to us at least one month before the deadline. But yeah, anyway, mentor balancing happens a bit later. And we will be able to know more two weeks before the student application deadline. But the question last week was how to choose a project right now. I believe the best suggestion is like, well, whatever you like, this is the best area for you. Yes. And one last question. So let's say there are two students and let's say they both want to work on the same project. Then how do we reply to that? Like some students have this feeling that one student is already interested in one project. So some students, they feel a little apprehensive to approach mentors for that project again, because they think that someone else is already trying to get into this project. So sometimes they feel a little shy to approach mentors just because someone else has already approached mentors for that project. So if two students are interested in the same project, so how should we ask them to go forward with that? Yeah, so if two students are interested and we already have such cases, they are more than welcome to reach out to mentors. They are more than welcome to reach out to each other because JSOC is open source contribution and open source project experience for students. And collaboration with other stakeholders is a key thing there. So if they see that there are potential conflicts between proposals, et cetera, it's something they can figure out in the beginning. For example, if there are two students and if there are meetings set for the project, for example, we had a meeting for role strategy plugin this weekend and students can just join this meeting, they can join chats and discuss how they would approach that. So they can even work together to file proposals which do not compete with each other and which prevent conflicts so that potentially both projects may be selected. It's something totally possible for some projects, for others, it may be not possible. But yeah, JSOC is still, well, there are many project ideas, but there are much more students applying and some idea project ideas and some applications may not be accepted just because there is another beta application. The best way to prevent that is actually to reach out to the mentors earlier to start communicating in public channels and then you have much more time to figure it out how to prevent that. Because yeah, if you join the public discussions one week before the application deadline, most likely there is nothing what can be done at that point. If you start the discussion one month in advance, then there are much more opportunities to find a way to prevent the conflicts. Okay, I think that sounds good. Yeah, that's it from my end actually. Okay. Yeah, any other questions, comments? Yes, no? So should we spend some time to review project ideas? Okay, let's take a look what we have now. So this is our page. So we have a bunch of project ideas which are already published. Most of them, yeah, they're fine, though, yeah, encourage all mentors to communicate with students and maybe make some changes in the proposals. For example, there are many questions coming about how to start this particular project idea. And if you're a mentor, maybe it makes sense to explicitly put in the project idea for students. So we, for example, there are questions for discard build steps recently and maybe for other projects. So if you're a mentor, maybe adding such information would be helpful. For draft project ideas, we have some drafts here staged and some of them are under discussion. And we also have some project ideas which have been submitted recently. So what do we have? We have a proposal about freestyle to pipeline job converter. It has been submitted by Craig recently. Then we have plugin to manager CLI. It's also submitted as a pull request now. I just forgot to put the link here. Okay, yeah, so it's here. So these project ideas, yeah, they're both for publishing cause draft. And we also have machine learning project, which is also new. And probably we need to do something about that. So probably we should start from the top. So there was a question about discard build steps in Ubea onboarding. Have I put it on my own or has somebody edited it? Or like I put the line below that, but the newbie. Okay, maybe I was the one who edited it. So the question here is about getting started because in this particular project, there is no quick start guide. There is no newbie friendly issues specifically related to this project. And actually it would be great to have something. We have organization one, it's newbie friendly issues. But if it's possible to add some more information for students, it would be really helpful. Yeah, it's just an example of what I was talking about. Yes, so that was my project idea to start with. And I'm glad that is Arnab on the call, I think he is. Yeah, he is. Yeah, so this project, what's happened is I looked at it last night and the discard old build feature has progressed since I looked at it the last time and it can now discard artifacts separately from discarding builds. So essentially all the features that the features that were missing are starting to get into the core of Jenkins. So the proposal for the start build step, in my opinion, needs to be rewritten because of that. Okay, so it's not about starting the project from ground up anymore because some progress has already been made. Is that what you're saying? Yes. And I'm also saying that I describe the project as a step in the pipeline, but so much has been done in core that I don't think we need the step anymore to do this. We can just keep improving the core. Yeah, so maybe it makes sense to have a series of updates here. So for example, you could move the description back to Google Doc and work together with Arnab to update it to the current state. What do you think? Yes, that's what needs to happen. Yes. Arnab? Yeah. Okay. Yeah. So I look into it. Okay. Yes. Okay. Yeah. Maybe even moving back to draft, so that students do not get confused by the status. So should we do that? Yes. So for draft project IDs, it's still possible to apply to a draft. So it's not an end to the world, but yeah, it just indicates that there is an active discussion ongoing. The scope of such IDs may change significantly during the discussions until the first coding period starts, something like that. Okay. So the next topic was about this related projects. So Martin, what is the discussion here? So the discussion here is that Jesse provided feedback on how to write DSL-compatible plugins, pipeline DSL-compatible plugins, and he is adamant about not using the global variable facility. And so the plugin can only be pure pipeline steps that return simple objects. That is his recommendation. So when I'm writing, when I wrote the examples, I focused on making them pure steps. There's the discussion. There's been, you know, I've seen examples that you have proposed Oleg, and I'm not sure that I'm not sure that it agrees with what Jesse has said. So the implementation side, I'm not sure how to describe it anymore. Yeah. So just on the, I developed only a few Jenkins plugins for pipeline, but I was always using global variables and I do not feel that there are any issues with using them. I was following this discussion a bit, but well, personally, I do not think that it's a blocker. I still need to take a look why Jesse thinks that they shouldn't be used, but well, they are successfully used and they are successfully used in pipeline libraries. So on this page, you're looking at, there is a, the last, no, no, no, not at the bottom at the top in the description. It says, if at all possible, limit your plugins to implementing plain steps. So that's the last sentence of this paragraph. Well, maybe managing global variables may be a bit more complicated because they have context, et cetera. But yeah, it's reasonable guideline for pipeline developers because yeah, having a step and maintaining this step is generally more useful. But here, what we could do, of course, we could say that, yeah, we could just replace it by yeah, for example, would you mind if I just write here to map? Go for it. Okay, so we could just say, so something like that with client though. So you could say something like that first get so something like jobs, built-in for, for example, and it still returns object and it formally uses on the pipeline steps. Yeah, I have no strong cutting in there. I think that this one is also viable. So this with client call, is that the step or is that a global variable? It's a, well, it really depends on how you implement that. But generally, it's a step. It's a step which takes closure as a last argument. The thing that in Jenkins you can implement is it is a global variable because Groovy allows that. But generally, it's a step. Okay, I'm not sure I am completely clear, but I've never, yeah, I've never ventured on that side of the DSL other than, then using what already exists. So maybe it makes sense to discuss it a bit in the pipeline sick meeting. Because well, although I understand what is the purpose to keep the things simple, yeah, having global variable sometimes it's really helpful. Okay, we can, I can attempt, I can discuss the pipeline authoring scene. Okay, let's move on then. So we have a Github project idea. Actually, I wanted to lend it last week, but last week there was a bunch of comments from Jeff. So the proposal was just full of comments. Now they seem to be addressed. But my question to you guys is whether we are ready to publish it. So there's two things. I don't think that I think the metadata needs to be reformatted to the new template. It's still all at the top. So that's one thing. We don't have any newbie friendly issues. I'm not sure what they would be for this project. Yeah, so my ask would be to have either a quick start guide on newbie friendly issues. So if you can provide particular newbie friendly issues, you could provide a quick guide how to start with your project idea, for example, how to explore Github plugin and how to come up with the proposal. So quick start guide would be a replacement for newbie friendly issues. Do you know if we have examples of a quick start guide in other plugins? Yes, we do. Okay. So I put a quick start guide to all my proposals, unless I missed something. Oh, I still need to publish a photo strategy. But you can find my project ideas. Okay. So if you, Jeff and Rick, could come up with a decision here, I think we should publish it. The rest looks fine. Do you want to take a shot at it, Rick, or you want me to do it? Sorry. Are you on the call, Rick? Maybe not. I thought Rick was on the call, I guess not. He was on the call. I believe he's one of Mr. Jenkins. I'm not sure which one. Yeah, that's the problem when you log in with generic account. Okay, we'll work it out on the Gitter channel, I guess. Okay. So yeah, once you agree with each other, we publish this project idea. I think it's solid enough and it was in review for quite long. The other thing we could potentially do, we could send it out to the dev mailing list and see if there's any additional comments. I'm not sure if it's valuable at this point. I think the proposal seems pretty clear to me. I believe that Rick has already sent a message to the mailing list, though it may make sense to poke people in that mailing list. But yeah, I don't think it's a blocker for publishing. Okay. Okay. So should we move on? Yes. Yes. Okay. So what else do we have? So we have pipeline step documentation generated proposal. Again, after the review cycle, it looks solid. So I had a comments for you, Martin, about the Java doc, that Java doc is a bit disconnected from the project description. But yeah, I think that generally it's close to be published. Yes, I saw your comment about the Java doc. I find, okay, personally, I find the project proposal to be broad. So what I'm hoping is that the student is going to make a more make a specific proposal, which is directly with more concrete, with more concrete actions and objectives. Other ideas. So something like that, what we could do, for example, we could say that Java doc publishing or pipeline steps. Then, for example, we integrated here then the documentation of documentation to read the doc. And we can also say, for example, if we talk about Java doc generation for the link, okay, we will clean it up later for pipeline libraries. I'm not sure what pipeline libraries is. Sorry, you do not know what is pipeline library? I know what the pipeline library is, but what specific, what pipeline libraries are you specifically referring to here? I think you're talking about the steps, right? Yeah, so what I said that, for example, let's, a user may create a pipeline library like this one. And here you may see that there is a bunch of steps with some documentation in TXT, which is a bundle HTML, and also the readme's. So instead of that, it would be possible to generate Java doc for pipeline library. And actually, I already made an attempt to do that at some point. So yeah, it may be useful to have documentation generation for libraries, because libraries are what many users of script pipeline really use in pipeline. What do you think? So this would be for the pipeline library that you have shown on the screen, but also for other pipeline libraries? Yeah, right. So generated for pipeline libraries. Okay, so the generator would have to know where to find those other pipeline libraries? For user pipeline libraries. For user pipeline libraries? Yeah, so users create pipeline libraries and they want documentation for them. We don't need pipeline libraries for abstract pipelines in the web. At least I don't think so. That might be a whole separate, yeah, that's a different, like that's a good thing to put here. But I think that that might be like a whole different project. Yeah, right. It may be a separate project. Yeah, so that's actually good. So maybe like it's just something that maybe a student's more interested in doing that versus fixing the stuff on the website. But yeah, I think like that that entire effort might be like something completely different. But yeah, but we can add that. There are maybe other flowers of pipeline documentation, which could be submitted, and be submitted. Let's do some project ideas or something quite good. What I'm thinking here is that a lot of it will be in the student proposal. So the student, well, I guess the student is going to look at all of this. And, you know, if a proposal, if a student proposes to take on, let's say, 30% of what's in here and do it really well, and it's enough work for a whole whole program of four months, then I'm happy with it. It doesn't matter exactly what we wrote, it doesn't have to be. We give project ideas, we don't give project descriptions to copy paste. And it's intentional. So, guys, I have to drop again. But if you want, you can continue the discussion. Regarding this project idea, we could probably take it offline or discuss in detail at the next perhaps another sick meeting. Okay, so do you continue meeting? I have to drop off as well. I do as well. So, working week. Yeah, everybody has meetings this time. Okay, so, yeah, thanks a lot for participation to everyone. Any quick questions? Okay, then let's proceed in the chat. And, yeah, for the next meeting, I believe we should just stop 10 minutes before the deadline, and then we discuss other things and close down the meeting. Yeah, I just didn't know that I have a meeting now, but I do. Okay. Okay, so thank you. Yeah, then see you all. And thanks again. Any questions? Let's discuss them in Gitter. Thank you, everyone. Take care. Bye. Bye. Thanks, everyone. Bye.